Critical Network Bug: MCP Client Fails to Connect in Queue Mode Despite Successful 'curl' from Worker to Main Container

Questions
1

Hello n8n team,

I am facing a persistent "Could not connect to your MCP server" error when using an MCP Client node in a queue mode setup. We have performed an exhaustive troubleshooting process and have confirmed that the underlying Docker network is functioning correctly, which points to a potential bug in the MCP Client node itself.

Environment:

  • **Hosting:** Hostinger KVM VPS
  • **n8n Version:** latest (running in Queue Mode)
  • **Setup:** Full 6-container stack (traefik, postgres, redis, n8n-main, n8n-worker, n8n-webhook) deployed via a canonical docker-compose file on a custom bridge network.

Problem Description:

  • An AI Agent workflow running on an n8n-worker container uses an MCP Client sub-node.
  • An MCP Server Trigger node runs in a separate workflow on the n8n-main container.
  • The MCP Client is configured with the correct internal service URL: http://n8n-main:5678/.../sse
  • The connection always fails with "Could not connect to your MCP server".

Diagnostics Performed (Evidence of working network): We have definitively proven that the inter-container network communication IS WORKING:

  • **DNS Resolution:** docker exec n8n-worker nslookup n8n-main successfully resolves to the correct internal IP of the n8n-main container.
  • **MTU Check:** A ping test with a 1500-byte packet (ping -M do -s 1472) from the worker to the main container succeeds with 0% packet loss.
  • **CRITICAL EVIDENCE:** Running a curl test from within the worker container to the main container SUCCEEDS:
    • Command: docker exec n8n-worker-1 curl -v http://n8n-main:5678
    • Result: A successful "HTTP/1.1 200 OK" response is received.

Conclusion: The underlying Docker network is fully functional. The worker container can resolve and establish a TCP connection to the main container. However, the n8n MCP Client node fails to make the exact same connection.

This strongly suggests the issue is not with the infrastructure but with the n8n application's HTTP client or the MCP node's specific implementation within the queue mode architecture.

Could you please provide insight into why the MCP node would fail where a standard curl command succeeds?

Thank you.