mcp-proxy.anthropic.com returns 502 after initial handshake — tool calls never reach backend server

Resolved 💬 2 comments Opened Apr 2, 2026 by aforamenta Closed May 10, 2026

Summary

Cloud-configured remote MCP servers (type claudeai-proxy) become unusable after the initial connection. The /mcp reconnect handshake succeeds (initialize, tools/list), but all subsequent tools/call requests fail with 502 Bad Gateway from mcp-proxy.anthropic.com. The requests never reach the backend server.

Environment

  • Claude Code running in VS Code devcontainer (Fedora Linux)
  • Remote MCP server: FastMCP (Python mcp[cli]>=1.26.0) with stateless_http=True
  • Server exposed via Tailscale Funnel (HTTPS, public)
  • Server is streamable-http transport, listening on port 8900

Reproduction

  1. Configure a remote MCP server through claude.ai (cloud connector)
  2. /mcp → reconnect succeeds (initialize + tools/list work)
  3. First tools/call502 Bad Gateway from Cloudflare (mcp-proxy.anthropic.com | Host: Error)
  4. All subsequent calls → same 502
  5. /mcp reconnect → works again, but next tool call → 502 again

Evidence that the backend server is healthy

We exhaustively tested the server directly (bypassing mcp-proxy.anthropic.com):

| Test | Result |
|------|--------|
| HTTP/1.1 sequential (5 calls) | 5/5 pass |
| HTTP/2 sequential (5 calls) | 5/5 pass |
| HTTP/2 concurrent (5 calls) | 5/5 pass |
| Full OAuth flow + session + 5 tool calls | 5/5 pass |
| Fresh connection per request (5 calls) | 5/5 pass |
| Rapid-fire (no delay) | 5/5 pass |

Server access logs confirm: the 502'd tool calls never arrive at the backend. The last log entry is the successful tools/list from the handshake. The proxy dies internally before forwarding.

Cloudflare error details

mcp-proxy.anthropic.com | 502: Bad gateway

You (Browser): Working
Lisbon (Cloudflare): Working  
mcp-proxy.anthropic.com (Host): Error

This indicates the proxy backend itself crashes/errors — Cloudflare can reach it, but the backend returns an error before it even connects to our server.

What we tried (no effect)

  • Switching from stateless_http=True to stateful mode (returns Mcp-Session-Id) — same 502
  • Increasing uvicorn timeout_keep_alive to 120s — same 502
  • Enabling access logging — confirmed requests don't reach server
  • Both HTTP/1.1 and HTTP/2 from the server side — no difference

Expected behavior

tools/call requests should be forwarded by mcp-proxy.anthropic.com to the backend server, just like initialize and tools/list are during the handshake.

Workaround

Local .mcp.json config with type: streamable-http connecting directly to the server URL works flawlessly. But this config is ignored when running through the claude.ai web/bridge connection — only cloud-configured servers appear.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗