Streaming Webhook Failures Behind Traefik: Diagnosing n8n's MCP Server Trigger JSON Errors

Problem profile and likely root causes

When short responses succeed but longer streaming responses fail with "error parsing json response from mcp server," the proxy layer (Traefik) is often the culprit. Traefik can buffer responses, impose read/idle timeouts, or mishandle chunked transfer encoding - all of which can truncate or delay streamed JSON and cause parsing failures at the client or server.

Technical checks and remediation

First, inspect Traefik logs and increase relevant timeouts: readTimeout, responseHeaderTimeout, and idleTimeout. Disable or tune response buffering for the /mcp route so streaming payloads are passed through immediately. Ensure Traefik is configured to support HTTP/1.1 chunked transfer or HTTP/2 as required by your MCP client. Validate that headers like Content-Length or Transfer-Encoding are preserved and that proxy buffering (e.g., nginx-like proxies) isn't enabled.

n8n-side adjustments

Confirm n8n webhook and MCP node settings are correct: webhook path, trust proxy settings, and webhook response modes. If using single-replica EasyPanel, verify resources and increase request body size limits if your payloads are large. For persistent issues, route MCP traffic directly to an internal port or use sticky sessions and disable connection pooling that could interfere with long-lived streams.

Business implications and recommended actions

Streaming webhook reliability is critical for real-time integrations. For leadership: prioritize staging tests of streaming workloads when deploying reverse proxies, codify proxy configurations as part of deployment templates, and include end-to-end monitoring for webhook latency and truncation. If self-hosting becomes brittle, evaluate managed alternatives or a dedicated ingress designed for streaming traffic.