Custom connector: zero inbound requests on Connect, already on port 443 (not the #521 cluster's cause)

### MCP server URL

https://seths-macbook-air.tailf8e648.ts.net:443/mcp/REDACTED-see-ofid-refs-below

### Where does the issue occur?

When pressing the Connect button

### Transport used

streamable-http

### Client registration type

Dynamic Client Registration (DCR)

### SSE only: Does your server return the expected status code for POST requests?

Not applicable (my server does not use SSE)

### When did you last reproduce this?

2026-08-14, ~6:45 AM PDT (multiple attempts between ~6:14 AM and 6:45 AM PDT)

### Browser and OS

Chrome (latest) on macOS 26.6

### Describe the issue

Clicking "Connect" on my custom connector produces "Couldn't register with [server]'s sign-in service" (or later "Couldn't connect to the server. Check that the URL points to a valid MCP server"), but my server's access logs show zero incoming requests from the attempt — not even the unauthenticated MCP initialize probe or a /.well-known/ discovery request. This is not the #125 pattern (OAuth completing but the post-auth handshake failing); nothing reaches the server at all.

### Issue details

```shell
Error IDs from the toast: ofid_80c8619026a80dad and ofid_0af87aaaf12625f1 (two separate attempts, same result).

Server hostname is a Tailscale Funnel domain (`*.tailf8Error IDs from the toast: ofid_80c8619026a80dad and ofid_0af87aaaf12625f1 (two separate attempts, same result).

Server hostname is a Tailscale Funnel domain (`*.tailf8e648.ts.net`), publicly reachable on standard port 443 (confirmed via `tailscale serve status --json`: `"TCP": {"443": {"HTTPS": true}}`). Steps taken to verify the server itself is not at fault:

1. Full manual OAuth flow via curl (register -> authorize with PKCE -> token exchange -> authenticated MCP initialize call) succeeds end-to-end and returns a valid session.
2. Anthropic's own WebFetch tool (in a Claude Code session, a different Anthropic-infra code path than the connector broker) successfully reached /.well-known/oauth-authorization-server on the same host on port 443 and got the correct JSON back, and that request appeared in my server's access log immediately.
3. /.well-known/oauth-protected-resource/ (RFC 9728 path-aware form, since my resource URL has a path component) returns correct metadata.
4. Removing and re-adding the connector from scratch (in case of stale cached capability info) did not change the outcome.
5. Unauthenticated POST to the MCP endpoint correctly returns 401 with a WWW-Authenticate: Bearer ... resource_metadata="..." header per the MCP Authorization spec.

IMPORTANT: I found #521 (and its cluster #227/#214/#374/#526) after initially writing this up. It has an identical symptom and was root-caused to the connector broker only dispatching to port 443. That is NOT my situation — I'm already confirmed on port 443 externally (not 8443/10000, the other two Funnel-supported ports), and both my curl and WebFetch tests above used plain https:// URLs with no port suffix. So this looks like either a distinct bug from the #521 cluster's port issue, or the fix for that cluster has a narrower definition of "port 443" than what Tailscale Funnel presents. Flagging in case it's worth triaging alongside that cluster rather than as fully unrelated.

Stack: hand-implemented OAuth 2.1 authorization server (single-user, auto-approving /authorize since there's no real login page) on top of the official Python mcp SDK's streamable_http_app(), served via uvicorn behind Tailscale Funnel, kept alive via a macOS launchd LaunchAgent.e648.ts.net`), publicly reachable on standard port 443 (confirmed via `tailscale serve status --json`: `"TCP": {"443": {"HTTPS": true}}`). Steps taken to verify the server itself is not at fault:

1. Full manual OAuth flow via curl (register -> authorize with PKCE -> token exchange -> authenticated MCP initialize call) succeeds end-to-end and returns a valid session.
2. Anthropic's own WebFetch tool (in a Claude Code session, so a different Anthropic-infra code path than the connector broker) successfully reached /.well-known/oauth-authorization-server on the same host on port 443 and got the correct JSON back, and that request appeared in my server's access log immediately.
3. /.well-known/oauth-protected-resource/ (RFC 9728 path-aware form, since my resource URL has a path component) returns correct metadata.
4. Removing and re-adding the connector from scratch (in case of stale cached capability info) did not change the outcome.
5. Unauthenticated POST to the MCP endpoint correctly returns 401 with a WWW-Authenticate: Bearer ... resource_metadata="..." header per the MCP Authorization spec.

IMPORTANT: I found #521 (and its cluster #227/#214/#374/#526) after initially writing this up. It has an identical symptom and was root-caused to the connector broker only dispatching to port 443. That is NOT my situation — I'm already confirmed on port 443 externally (not 8443/10000, the other two Funnel-supported ports), and both my curl and WebFetch tests above used plain https:// URLs with no port suffix. So this looks like either a distinct bug from the #521 cluster's port issue, or the fix for that cluster has a narrower definition of "port 443" than what Tailscale Funnel presents. Flagging in case it's worth triaging alongside that cluster rather than as fully unrelated.

Stack: hand-implemented OAuth 2.1 authorization server (single-user, auto-approving /authorize since there's no real login page) on top of the official Python mcp SDK's streamable_http_app(), served via uvicorn behind Tailscale Funnel, kept alive via a macOS launchd LaunchAgent.
```

### Expected behavior

Given every documented discovery/transport requirement is met and independently verified via curl and WebFetch, and the server is already on port 443, I expected claude.ai to at least attempt a request (e.g. GET /mcp or a well-known discovery endpoint) and proceed with the DCR/OAuth flow.

### Logs from your server

```shell
Access log around the two connector attempts (client_id/timestamps redacted where they'd reveal the real path; only my own curl/WebFetch tests appear — nothing from a claude.ai/Anthropic connector IP at any point):

INFO: [my-tailnet-ip]:0 - "GET /.well-known/oauth-authorization-server HTTP/1.1" 200 OK <- WebFetch, succeeded
INFO: [my-tailnet-ip]:0 - "GET /.well-known/oauth-protected-resource/mcp/ HTTP/1.1" 200 OK <- my own curl test
INFO: [my-tailnet-ip]:0 - "POST /mcp/ HTTP/1.1" 401 Unauthorized <- my own curl test (expected, unauthenticated)
INFO: [my-tailnet-ip]:0 - "POST /register HTTP/1.1" 201 Created <- my own curl test (manual OAuth flow)
INFO: [my-tailnet-ip]:0 - "GET /authorize?...&resource=https%3A%2F%2F%2Fmcp%2F HTTP/1.1" 302 Found <- my own curl test
INFO: [my-tailnet-ip]:0 - "POST /token HTTP/1.1" 200 OK <- my own curl test
INFO: [my-tailnet-ip]:0 - "POST /mcp/ HTTP/1.1" 200 OK <- my own curl test, authenticated, succeeded

(No entries at all corresponding to either "Connect" click in the claude.ai UI, despite two separate attempts minutes apart.)
```

### Additional context

Area: MCP Connector (adding/managing servers). MCP Server: custom server (self-hosted, Python `mcp` SDK, Streamable HTTP transport, own OAuth authorization server), not from the Connectors Directory. Happy to share sanitized server code, the un-redacted URL, or additional logs privately on request.