[BUG] claude.ai web custom connector shows "server configuration issue" while sending ZERO requests to a provably-healthy MCP server (cached verdict not cleared by remove + re-add)

[therealmojoe]

Summary

On claude.ai (web), a custom MCP connector that previously worked now shows "Connection issue — This connector has a server configuration issue. Contact the connector provider." The decisive finding: when the connector is added/re-added, claude.ai sends zero requests to the MCP server — no discovery, no DCR, no OAuth — and the error appears instantly. Meanwhile the same server at the same URL is provably healthy and is being used successfully, concurrently, by other MCP clients.

This looks like an account/URL-keyed cached negative verdict that is never re-validated and is not cleared by removing + re-adding the connector. The user-facing text blames the server, but no request ever reaches it.

Closely related to #228, #435, #379, #467.

Environment

• Client: claude.ai web, "Add custom connector (BETA)".
• Server: self-hosted, FastMCP OAuthProxy → WordPress OAuth Server, Streamable HTTP, behind Apache. Public URL: https://carbonguru.io/mcp.
• Timeline: the connector worked on claude.ai web until ~2026-06-10 (the issued OAuth token expired around then). Since, claude.ai web shows the "server configuration issue" error and never re-contacts the server.

The server is healthy — verified via three independent clients, same day

1. Claude Code CLI — claude mcp add --transport http <name> https://carbonguru.io/mcp → completes discovery + Dynamic Client Registration + authorization_code+PKCE, connects, and runs tools live (streaming analysis results).
2. ChatGPT CustomGPT — a separate OAuth client + REST surface on the same host authenticates and returns 200 (most recent action call minutes before filing).
3. Headless walk (curl / httpx) — full RFC 8414/9728 discovery is complete and valid; POST /register → 201 (DCR works); full authorization_code+PKCE → POST /token → 200; authenticated whoami/ping tool calls → 200.

The OAuth discovery document is complete and spec-compliant: includes jwks_uri, subject_types_supported, id_token_signing_alg_values_supported; PKCE S256; tokens RS256. CIMD is not advertised (clients use DCR).

claude.ai sends zero requests — measured

During a fresh re-add of https://carbonguru.io/mcp (OAuth Client ID/Secret left blank to force DCR), I monitored the server's reverse-proxy access log and the MCP app journal for ~2 minutes:

• Zero inbound requests from Anthropic infrastructure — no discovery, no /register, no /authorize, no /token, and no Anthropic source IPs in the access log.
• At the same moment, the server was actively serving a live Claude Code CLI session (streaming a real tool result).

So at one instant, on one URL, on one server: the Claude Code CLI client works, while the claude.ai web connector returns "server configuration issue" without making any network request to the server.

Steps to reproduce

1. Stand up a self-hosted MCP server with OAuth (e.g. FastMCP OAuthProxy). Connect it as a custom connector on claude.ai web (works initially).
2. Let the issued access token expire (or restart the server so the old token is no longer valid).
3. Open the connector on claude.ai web → it shows "Connection issue / server configuration issue."
4. Remove the connector, then re-add the same URL (leave OAuth Client ID/Secret blank → DCR).
5. Observe: the error appears instantly, and the server logs show no inbound request for the add attempt.

Expected vs. actual

• Expected: adding/re-adding a custom connector triggers a fresh discovery + registration + OAuth attempt against the server (as the Claude Code CLI does). If a prior verdict is cached, re-adding should re-validate by contacting the server.
• Actual: claude.ai serves a cached "broken" verdict, makes no network request, and shows a "server configuration issue" error that misattributes a client-side caching problem to the server. There is no in-product way to clear the verdict.

Impact

A self-hosted connector that is fully healthy and reachable by every other MCP client (Claude Code CLI, ChatGPT, MCP Inspector / curl) becomes permanently unusable on claude.ai web with no recovery path — and the misleading error sends developers debugging their (working) server.

Requests

1. On connector add/re-add, force a fresh discovery + DCR + OAuth network call to the server instead of returning a cached negative verdict.
2. Provide a way for users/developers to clear the cached connector verdict for a given URL/account (and/or expire it on a sane TTL).
3. Fix the misleading attribution: do not report "a problem with the connector's server" when no request was made to the server.

Happy to provide server-side logs, the discovery documents, or a live endpoint for testing.

[therealmojoe]

Update — new diagnostic narrows this to per-account connector state, with an Anthropic-side trace ID.

I ran a controlled test to determine whether the stuck verdict is keyed to the URL or to the account, and where the failure occurs.

Test: stood up a second path (/mcp-v2) on the same healthy server/host, then attempted to add it as a fresh custom connector from the affected account, while capturing at the server's network layer (tcpdump, filtered to Anthropic's egress range) and the reverse-proxy access log.

Result: the affected account's add produced a different client error after ~15s — Couldn't reach the MCP server … reference: ofid_7194fc6e6406c60c — and zero packets reached the server (both tcpdump and the Apache access log show 0 for the attempt). The server's network is fully open (cloud security-group 443 ingress = 0.0.0.0/0; no host firewall or fail2ban rule), so there is no drop point — the requests never left Anthropic's infrastructure for this host.

Controls (rule out server/network):

• A different, fresh account completed the full OAuth flow against a different-host instance of the same server build minutes earlier: POST /register 201 → /authorize → /token 200 → authenticated tool calls, from Anthropic's 160.79.106.x.
• The affected connector's host was reachable by Anthropic (returning 401 on the post-expiry token) through 2026-06-18, then went silent — i.e. it stopped being contacted, not blocked (we verified no network/firewall change).
• The server itself: discovery docs complete, POST /register → 201 (DCR works), full authorization_code+PKCE verified headlessly and via Claude Code CLI.

Conclusion: the stuck state is account-scoped (and host-keyed), not URL-keyed. A brand-new URL on the same host, from the affected account, is dropped before any request is sent — so a fresh-URL workaround cannot help. The server and network are provably healthy; the failure is entirely in claude.ai's per-account connector state for this host. This matches the "stuck, no in-app recovery" behavior in #54710 (remove + re-add does not clear it).

Asks:

1. Is there a way to clear/reset the cached connector verdict for an account + host? The affected account can't recover via remove + re-add, and a fresh URL on the same host is short-circuited before a request is sent.
2. ofid_7194fc6e6406c60c should show, on your side, why the mcp-proxy sends zero packets to this host for this account, when the host is reachable, healthy, and connects fine from a fresh account.

Happy to provide the server-side captures, timestamps, or a live endpoint for testing.

[therealmojoe]

Additional Anthropic-side identifiers for the failure (from the claude.ai flow URL + error UI, affected account).

The failing connector flow surfaces these handles:

• Failure step: step=start_error — the flow fails at the start step, i.e. before discovery → registration → authorize → token. This is exactly consistent with the server seeing zero packets: the flow never advances to a step that would contact the MCP server.
• Connector record (claude.ai-internal): server=9e4649ac-c601-48dd-beb7-424a59794214 — the affected account's connector object whose state appears wedged.
• Operation/flow trace IDs (two separate attempts):
  • flow_id=ofid_c734ffa669ef7590 (from the connectors URL, …&step=start_error&flow_id=ofid_c734ffa669ef7590)
  • ofid_7194fc6e6406c60c (from the in-app "Couldn't reach the MCP server … share this reference with support" error)
• The claude.ai web app also beacons this client-side to your Datadog RUM intake (browser-intake-us5-datadoghq.com, US5), if that's a useful extra correlation point.

Summary: this is a start_error on connector record 9e4649ac… for the affected account — a flow-initiation failure, pre-server — not a server or network condition (server healthy; cloud SG 443 ingress 0.0.0.0/0; a fresh account connects to the same build on another host; zero inbound packets for the affected account at the network layer). What's needed is to clear/reset that connector record's state (or fix whatever makes start error for it): remove + re-add does not recover it, and a fresh same-host URL is short-circuited before a request is sent.

[therealmojoe]

Reproduced on a second connector record — confirms this is account-scoped, not a single poisoned connector.

A subsequent retry on the affected account produced the same start_error on a different connector record:

…/customize/connectors?&server=762ab7ce-1afd-4321-b73a-119290a092a3&step=start_error&flow_id=ofid_2e1fe3ee81beff98

• New connector-record id server=762ab7ce-1afd-4321-b73a-119290a092a3 — distinct from the earlier 9e4649ac-c601-48dd-beb7-424a59794214.
• Same step=start_error; new flow/op trace ofid_2e1fe3ee81beff98.
• Server-side, again zero packets reached the host for this attempt (Apache access log and a tcpdump scoped to Anthropic's egress range both show 0).

So the start_error is not tied to one poisoned connector entry — it reproduces across multiple connector records on the same account (and, per the earlier evidence, across two different hosts: carbonguru.io and dev.carbonguru.io). That points squarely at account-level connector state: re-adding / renaming / a new URL each create a fresh record that hits the same pre-discovery start_error before a packet is sent. A fresh account connects fine to the same server build, which isolates it further.

Ask is unchanged: please reset the affected account's connector state (and/or surface why start errors for it).

Handles gathered for this account so far:

• Connector records: 9e4649ac-c601-48dd-beb7-424a59794214, 762ab7ce-1afd-4321-b73a-119290a092a3
• Flow/op trace ids: ofid_c734ffa669ef7590, ofid_2e1fe3ee81beff98, ofid_7194fc6e6406c60c

[therealmojoe]

Update — root cause re-framed: this is NOT a per-URL cached "broken" verdict.

We stood up a parallel MCP service on a brand-new URL (https://carbonguru.io/mcp-v2, a separate process on :8091, same backend code) specifically to test the cached-verdict theory. Results:

• A fresh claude.ai account + the fresh /mcp-v2 URL (neither of which can hold any cached state) still fails with "Couldn't connect to the server. Check that the URL points to a valid MCP server," after a ~10-second hang, and with zero requests reaching our server (no 160.79.x in our Apache access log or the service journal).
• The server is provably healthy: POST /mcp-v2/register → 201, correct OAuth/discovery metadata, and it serves Claude Code CLI, ChatGPT/CustomGPT, and the MCP Inspector fine (all from non-mcp-proxy IPs).
• The identical flow against https://dev.carbonguru.io/mcp-v2 (different IP, 208.113.132.15) connects end-to-end from your mcp-proxy 160.79.106.x — register → authorize → token → tools/list, captured in our logs minutes earlier.
• Our prod IP 208.113.164.218:443 is reachable from 15 datacenter locations worldwide and from residential connections. The only vantage it is dark from is your mcp-proxy ranges.
• Timeline: your mcp-proxy reached our prod IP normally through 18 Jun 2026 (last hit 18/Jun 23:19 UTC, all 401 after our OAuth token died on the 10 Jun cutover), then went completely silent.

A fresh URL + fresh account producing zero server contact plus a ~10s timeout rules out a URL/account cache and narrows it to one of two things:

1. Network reachability — your mcp-proxy egress IPs (160.79.106.0/24) cannot open a TCP connection to 208.113.164.218:443. We are filing this with our host in parallel (suspecting an abuse null-route triggered by the post-10-Jun 401 retry storm from your proxy against that IP). The ~10s hang on a brand-new URL is consistent with a connection attempt being blackholed, not an instant cached error.
2. A domain-scoped state on your side for carbonguru.io (the subdomain dev.carbonguru.io is unaffected by whatever this is).

Questions:

• Can your mcp-proxy infrastructure currently open a TCP connection to 208.113.164.218:443?
• Is there any account- or domain-scoped state for carbonguru.io that survives connector remove/re-add and applies across different accounts?

[therealmojoe]

Update — packet capture rules out MTU and our host; the SYN dies upstream.

We ran a packet capture on the prod instance during fresh connector attempts, and engaged our host (DreamHost) in parallel.

• tcpdump on the instance (ens3, 208.113.164.218), filtered to your mcp-proxy range (160.79.106.0/24) + "fragmentation-needed" ICMP, during repeated fresh connection attempts: ZERO packets over a 10-minute window — not a single SYN, no ICMP. The instance never sees anything from your proxy.
• This rules out a path-MTU/PMTUD black hole: a SYN is ~60 bytes and passes any MTU; an MTU hole would show the handshake completing and then a large segment lost + a frag-needed ICMP — we see none of that, not even the initial SYN.
• Our host (DreamHost) checked their firewall and logs and reports no block on these ranges on their side.
• The connector attempt still hangs ~10 s then errors (latest ref ofid_7375b6583951775f) — consistent with your proxy sending a SYN that gets no response (silently dropped in path), not an instant client-side cache and not a RST.

Net: the drop is upstream of our host — in transit between your network and ours, or on your side. Our instance is otherwise healthy and reachable: 208.113.164.218:443 answers from 15 global datacenter probes + residential, and your mcp-proxy reaches our other instance 208.113.132.15 (dev, same /21 block) fine — only 208.113.164.218 is dark to 160.79.x. (We also tried to test a different IP, but our host's OpenStack policy blocks tenants from re-IPing an instance.)

Request: could someone run a traceroute / MTR (TCP, port 443) from your mcp-proxy egress (160.79.106.x) toward 208.113.164.218, and share where the path dies? A side-by-side trace to the working 208.113.132.15 would pinpoint the exact hop — it's the one piece neither we nor our host can see from our side.

[therealmojoe]

Update — reproduced from an independent Google Cloud host (no Anthropic involved). This is network reachability, not connector state.

To remove any doubt about account/URL/connector state, I ran the test from a generic Google Cloud Shell session (egress 34.138.76.214, AS396982 Google LLC) — Anthropic's mcp-proxy is GCP-hosted, so this is the same network vantage your proxy connects from, with none of your app, account, or connector code in the path.

Raw TCP connect to :443, from Google Cloud:

208.113.164.218 (prod):  TCP :443  -> TIMEOUT after 10s  (UNREACHABLE)
208.113.132.15  (dev):   TCP :443  -> CONNECTED (TLS starts; only a cert-name mismatch)

And a TCP traceroute from the same Google Cloud host:

• to .218: dies one hop past the Cloud Shell gateway, never reaches DreamHost — SYN unanswered.
• to .132.15: Google edge (142.250.x) -> Lumen (4.x) -> DreamHost edge (208.113.156.209) -> destination reached, 0% loss.

What this establishes:

• The failure is a real, network-layer, IP-specific reachability problem — a bare TCP SYN from Google Cloud to 208.113.164.218 gets no response. It is not a cached verdict, account-scoped connector state, or a wedged connector record (every such theory above is moot — a generic GCP host with no Anthropic involvement fails identically).
• It is scoped to the prefix 208.113.164.0/22 (our prod IP). The other prefix 208.113.128.0/21 (the dev IP .132.15) is reachable from the same Google Cloud vantage — so Google can reach DreamHost generally, just not this prefix.
• The drop is upstream of DreamHost's firewall (their firewall/logs are clean; the packets do not reach their edge), consistent with a transit-level blackhole/null-route on this /32 rather than a firewall rule.

Ask: this is reachability from Google Cloud to 208.113.164.218, so the diagnosis/fix is network-level, not connector-level. (1) Can someone confirm or escalate the GCP egress route to 208.113.164.218 (vs the working 208.113.132.15)? (2) Please note a fresh URL/account cannot help — already demonstrated — so the in-app "remove and re-add" guidance is a dead end for this case. We are pursuing a prefix reassignment with our host (DreamHost) in parallel, and will report which side clears it.

[localden]

Thank you for taking the time to report this.

We traced all four reference IDs (ofid_7194fc6e6406c60c, ofid_c734ffa669ef7590, ofid_2e1fe3ee81beff98, ofid_7375b6583951775f; Jun 22, between 04:33 and 17:59 UTC). Every connection attempt from claude.ai to your server was reset during the TLS handshake, before any HTTP byte was exchanged. The initial MCP probe, the OAuth protected-resource and authorization-server metadata lookups, and the fallback client-registration attempt all failed the same way, so the "server configuration" error you saw is that connection failure surfacing in the UI, not an actual OAuth or MCP problem.

The TCP connection opens and then the handshake is reset after a few seconds. On a standard HTTPS port this is almost always one of:

1. A firewall, WAF, CDN bot rule, or hosting-provider block in front of the host that resets TLS from cloud or datacenter IP ranges. Claude's connector traffic originates from 160.79.104.0/21 (AS399358); your server needs to accept inbound HTTPS from that range.
2. The DNS A/AAAA records pointing at something that is not actually serving (a parked record, an old load balancer, or a placeholder).
3. An incomplete or mismatched TLS certificate or listener.

Once the host is reachable over TLS from the public internet, claude.ai will connect without issue. Closing as a server-side reachability issue; if you fix reachability and still see a failure, please reopen with a fresh reference ID and we will re-trace.

[therealmojoe]

Closing the loop — resolved on our side. We migrated the MCP server to a new host on a different IP/prefix, and from the new IP claude.ai's connector completes OAuth + tool calls on both /mcp and /mcp-v2. Thanks for the trace.

One correction for the record, for the next person who sees "server configuration issue": in our case the failure mode was not a TLS-handshake reset. A packet capture on the instance showed zero inbound SYNs from the connector range, and an independent reproduction from a Google Cloud host timed out (no response), with the SYN dropped in transit before reaching the host's provider edge — a silent in-transit drop / blackhole specific to that single destination IP and to datacenter source networks (residential sources reached the same IP fine). The hosting provider confirmed no block on their side and normal prefix announcement, consistent with a transit/path-level drop on that /32 — most likely an automated abuse mitigation triggered by a burst of failed inbound attempts ~a week earlier.

Diagnostic tip: if the connector shows "server configuration issue," capture inbound traffic on the server. No SYNs arriving + a client-side timeout (not a reset) ⇒ suspect an IP-specific in-transit blackhole, not an OAuth/TLS/server fault — and moving the endpoint to a fresh IP/prefix resolves it.