Custom OAuth connector: "Authorization with the MCP server failed" — token exchange succeeds server-side, /mcp-server/http never called afterward (recurring, 3 ofid refs, reproduces with proxy removed entirely)

## Summary
A self-hosted n8n MCP connector (OAuth 2.1 + Dynamic Client Registration) added to claude.ai as a custom connector fails with:

> Authorization with the MCP server failed. You can check your credentials and permissions. If
> this persists, share this reference with support: `ofid_...`

Server-side logs show the entire OAuth handshake completing cleanly every time — discovery, DCR,
authorize redirect, and token exchange all succeed — but claude.ai's client never makes a
follow-up authenticated request to the MCP endpoint with the token it just received. Recurred
repeatedly across 2+ weeks with 3 different ofid references, identical behavior each time, and
reproduces even with the reverse proxy removed entirely from the equation (see "Ruled out"
section below).

## Environment
- MCP server: self-hosted n8n v2.26.4, OAuth 2.1 + RFC 7591 DCR, `https://n8n.8889091.xyz/mcp-server/http`
- Client: claude.ai web (custom connector)
- Discovery: /.well-known/oauth-authorization-server + /.well-known/oauth-protected-resource, both 200

## References
- ofid_50c65b95fd34904f (2026-07-21)
- ofid_7aaf3379a6d0fc78 (2026-08-04)
- ofid_56237154bf01a97b (2026-08-04)

## Evidence (nginx access log, UTC)
Every attempt:
```
POST /mcp-server/http -> 401 (expected, pre-auth)
GET /.well-known/oauth-protected-resource/mcp-server/http -> 200
GET /.well-known/oauth-authorization-server -> 200
POST /mcp-oauth/register -> 201 (client A)
POST /mcp-oauth/register -> 201 (client B, ~1-3s later — registers TWICE per attempt)
GET /mcp-oauth/authorize?...redirect_uri=https%3A%2F%2Fclaude.ai%2Fapi%2Fmcp%2Fauth_callback... -> 302
POST /mcp-oauth/token -> 200 (valid token issued)
[ ... nothing ... ]
~14s later: entire register->authorize->token sequence restarts with a NEW client_id, discarding
the just-issued token.
```
`/mcp-server/http` is never called again after the initial pre-auth 401 probe, in any attempt.

## Ruled out
- Reverse-proxy SSO (Authelia) — tested both enabled (with correct bypass rules) and fully
disabled — identical failure both ways.
- Redirect URL allowlist — confirmed https://claude.ai/api/mcp/auth_callback present/used correctly.
- CrowdSec — 0 active decisions.
- Cloudflare legacy firewall rules — 2 present, both paused.
- Cloudflare Bot Fight Mode — tested on and off live (watching origin logs in real time during
retry) — identical failure either way.
- Direct external test through Cloudflare's edge with a python-httpx-matching UA (matches
claude.ai's own backend) returns clean 200 on discovery — not blocked/challenged anywhere.
- **nginx / reverse-proxy behavior, specifically** — stood up a second, completely independent
resource-server path for the *same* n8n instance: Cloudflare Tunnel → Traefik → n8n, with nginx
entirely removed from the chain (no nginx-proxy-manager, no Authelia). Added that URL as a new
connector and retried live while watching both the Traefik access log and n8n's own application
log. Identical failure reproduced: Traefik's log shows every `POST /mcp-server/http` returning
`401` (never once authenticated), while n8n's log shows `Consent approved` firing **twice** during
that single retry (two separate valid tokens successfully issued), neither ever used. Same
discard-and-restart pattern. This rules out nginx/reverse-proxy behavior as a contributing factor
entirely — the identical n8n instance, reachable through a totally different proxy stack, hits the
same bug.

No 403s, no WAF blocks, no proxy interference at any hop we can observe, on either proxy stack
tested. Token issued successfully every time.

## Expected behavior
After successful token exchange, an authenticated request to /mcp-server/http using the obtained token.

## Actual behavior
Token is discarded; claude.ai shows the authorization-failed error and silently restarts the
entire OAuth flow with a new client rather than using/retrying with the token it has. This holds
regardless of what reverse proxy (or none) sits in front of the origin server.

Happy to provide full raw log lines or reproduce live if useful for triage.