Works in Claude Code but not claude.ai

If your server's access log shows nothing at all during the Connect attempt

1. 1 Expect no traffic at all from a rejected name. Claude resolves the hostname and validates the result before it makes any request, rejecting private, carrier-grade NAT, loopback, and link-local addresses, any mix of public and non-public answers, and a hostname with no A record from public DNS. Connectors are IPv4-only, so an AAAA-only host has nothing to dial.
2. 2 Publish the server on a globally routable IPv4 endpoint: a host with a public IP, a public reverse proxy, or a tunnel. An Anthropic MCP tunnel doesn't close this gap for claude.ai — the docs state that tunnels created through the Console are not available as connectors in claude.ai, and reach Claude Managed Agents and the Messages API only.
3. 3 Then collect the reference id. It starts ofid_ and appears in the error toast and in the page URL; file it with your server URL and your server-side access logs on the anthropics/claude-ai-mcp tracker. It is what lets Anthropic trace the exact failure server-side, and reference ids expire, so report soon after the failure.

.../settings/connectors?step=start_error&flow_id=ofid_d32594c73257a651

If the public record points into your cluster's network, or your ingress has a source-IP allowlist

1. 1 Check what address your public zone publishes. networking.gke.io/load-balancer-type: "Internal" on a GKE Service creates a load balancer that, per Google's docs, only clients in the same VPC network or a network connected to it can reach — so if that address is what the zone publishes, claude.ai resolves it, sees a non-routable answer, and stops before sending anything.
2. 2 Point the public record at an internet-facing ingress and keep the internal name for in-cluster callers. Verify with dig +short A from outside your network, not from a pod and not from a laptop on the VPN.
3. 3 Add 160.79.104.0/21 to whichever source-IP allowlist applies. nginx.ingress.kubernetes.io/whitelist-source-range sets the allowed client IP source ranges as a comma-separated CIDR list, and ingress-nginx documents that an annotation on an Ingress rule overrides any global restriction — so miss it and the MCP and OAuth paths never reach your pod. Don't treat that allowlist as authentication: the range is shared by every Anthropic customer.

If Cloudflare Access or a WAF rule sits in front of the hostname

1. 1 Look for 403 or 429 responses in your edge or CDN logs that your application didn't generate, especially during a Connect attempt. That is the only reliable tell: a WAF rule, a bot-management rule, and a rate limiter all answer before your application does, and all three look identical from claude.ai. Cloudflare Access in front of the hostname is a different failure with the same toast — it authenticates browser sessions, and that shape has its own page in the related errors on this page.
2. 2 Add a Bypass policy for Anthropic's outbound range using an IP-range selector, which takes CIDR notation: 160.79.104.0/21. Cloudflare documents Bypass as disabling Access enforcement for traffic matching the rule, and that bypassed requests are not logged — so it removes your only gate on that path, and the MCP route needs its own authentication afterwards.
3. 3 Don't plan on a service token instead. That needs Claude to send CF-Access-Client-Id and CF-Access-Client-Secret, and claude.ai's request-header authentication is in beta and gated on contacting Anthropic, accepts at most four headers, and restricts names to a reviewed allowlist of standard authentication and routing headers such as authorization, x-api-key, and x-auth-token.

If a WAF web ACL, security group, or network ACL sits in front of your load balancer

1. 1 Create an IP set holding 160.79.104.0/21 and reference it from a rule with an Allow action, ordered ahead of the blocking rules. A web ACL whose default action is Block, or a managed rule group that reads an unattended client as a bot, answers before your target group does. In the console rule builder the Request option to choose is Originates from an IP address in; in the API the statement is IPSetReferenceStatement. AWS WAF supports every IPv4 and IPv6 CIDR range except /0, and one IP set holds up to 10,000 addresses or ranges.
2. 2 Check the security group and any network ACL as well. A group scoped to your corporate ranges drops the connection with no HTTP response at all, which claude.ai reports with the same string and which leaves nothing in your WAF logs to find.
3. 3 If the listener also carries an authenticate-oidc action, treat that as a separate failure with the same toast — a browser redirect an MCP client can't follow. It has its own page in the related errors on this page.

If the URL you registered redirects — apex to www, region routing, or a vanity domain to a CDN

1. 1 Expect the apex URL to be a redirect rather than an endpoint. Vercel recommends the www subdomain as the primary domain with a redirect from the non-www domain to it, and its docs say that if someone visits your domain with or without the www prefix, Vercel attempts to redirect automatically — so the apex URL a developer naturally pastes into the connector dialog is the redirect.
2. 2 Read the other error string as this cause. Standard HTTP client security behavior drops the Authorization header on a cross-host redirect, so the redirect target receives an unauthenticated request, returns 401, and the connection fails with "Authorization with the MCP server failed".
3. 3 Register the URL the server actually listens on, not one that redirects to it. curl -sI the registered URL: if the status is a 3xx and the Location names another host, that target is the URL to register. Region routing and vanity-domain-to-CDN redirects behave the same way.

If your authorization server is Microsoft Entra ID and the token request fails with AADSTS9010010

1. 1 Read this on the other toast: Anthropic documents it under "Authorization with the MCP server failed", because the MCP endpoint was reachable and the token request is what failed. Entra is rejecting the resource value Claude sends, sometimes surfaced as invalid_target. Claude sets resource to your MCP server URL including the path, and Entra issues a token only when that value is listed as an Application ID URI on the app registration representing your protected API. The default api://{client-id} URI alone is not enough.
2. 2 In the Entra admin center open the API's app registration — not the client's, if they are separate — and under Expose an API add your MCP server URL as an additional Application ID URI (identifierUris in the manifest). The value must match exactly, including the path, without a trailing slash.
3. 3 If your server validates the audience through Azure App Service Authentication, add the API app's Application (client) ID and its api:// URI to the allowed token audiences — the Allowed token audiences setting, not Allowed client applications, which is a different list. And where the client and the API are separate registrations, confirm the client has an admin-consented API permission for the scope your API exposes.

If the MCP server genuinely cannot be published to the public internet

1. 1 Accept that a claude.ai connector needs a public origin in front of the private server. claude.ai has no private path into your network, and Anthropic's own MCP tunnels don't provide one: they are a research preview, and the docs state that tunnels created through the Console are not available as connectors in claude.ai.
2. 2 Put the gateway there: one public HTTPS route per upstream MCP server, reaching a server that exists only inside your VPC or on bare metal over the Zuplo secure tunnel. The tunnel service dials out from inside your network, so nothing is exposed to the internet and no inbound firewall rule is opened.
3. 3 Let it answer the discovery half of this error too. For its MCP routes the gateway is both the OAuth 2.1 resource server and the authorization server, publishing an RFC 9728 protected resource metadata document per route and RFC 8414 authorization-server metadata both gateway-wide and per route — so there is no cross-host authorization server for a WAF to block.

Something else

Whatever sits in front of your server, the branch is the hop, and there are only four. Nothing on your network saw the request: the name you registered resolves to something Anthropic won't dial, so fix the public record or publish a routable IPv4 endpoint. Something answered before your application did: find the 403 or 429 in the edge logs and allowlist 160.79.104.0/21 on that component, or exempt the MCP and OAuth paths from the rule. The request arrived without its credential: your URL redirects to another host, so register the target instead. The MCP endpoint answered but discovery didn't: return a 401 carrying WWW-Authenticate: Bearer resource_metadata="…", or serve /.well-known/oauth-protected-resource/<your-mcp-path> on the origin, and remember that discovery requests to a cross-host authorization server arrive from the same egress range — so a WAF in front of your identity provider breaks the connection even when your MCP server is perfectly reachable.