self-hosted n8n MCP connector fails: DCR fails despite valid registration endpoint + wrong authorize path with manual client ID"

### MCP server URL or name

https://n8n-nh.duckdns.org:48443/mcp-server/http

### How are you connecting to this server?

From a custom connector URL I entered manually

### Where does the issue occur?

When pressing the Connect button

### When did you last reproduce this?

2026-09-09

### Browser and OS

Chrome

### Describe the issue

## Bug Description

Connecting a self-hosted n8n Instance-Level MCP server (Preview) as a Custom Connector fails in two distinct ways, despite the server being fully spec-compliant (verified manually via curl at every step).

## Setup

- **MCP server**: n8n Instance-Level MCP (Preview)
- **Reverse proxy**: Caddy, behind DuckDNS (`n8n-nh.duckdns.org:48443`)
- **MCP server URL**: `https://n8n-nh.duckdns.org:48443/mcp-server/http`
- **Transport**: streamable-http
- **Client registration type**: Dynamic Client Registration (DCR)

## Server-side verification (all passed)

1. **`/healthz`** → `200 OK`, `{"status":"ok"}`
2. **MCP initialize request** (POST to `/mcp-server/http`) → `401 Unauthorized` with correct `WWW-Authenticate` header:
```
WWW-Authenticate: Bearer realm="n8n MCP Server", resource_metadata="https://n8n-nh.duckdns.org:48443/.well-known/oauth-protected-resource/mcp-server/http"
```
3. **Protected Resource Metadata** (RFC 9728) → `200 OK`, valid JSON with correct `authorization_servers`
4. **Authorization Server Metadata** (RFC 8414) at `/.well-known/oauth-authorization-server` → `200 OK`, valid JSON:
```json
{
"issuer": "https://n8n-nh.duckdns.org:48443",
"authorization_endpoint": "https://n8n-nh.duckdns.org:48443/mcp-oauth/authorize",
"token_endpoint": "https://n8n-nh.duckdns.org:48443/mcp-oauth/token",
"registration_endpoint": "https://n8n-nh.duckdns.org:48443/mcp-oauth/register",
"revocation_endpoint": "https://n8n-nh.duckdns.org:48443/mcp-oauth/revoke",
"token_endpoint_auth_methods_supported": ["none", "client_secret_post", "client_secret_basic"],
"code_challenge_methods_supported": ["S256"]
}
```
5. **Manual DCR test** (POST to `registration_endpoint`) → `201 Created` with a valid `client_id` returned:
```
HTTP/2 201
{"client_id":"ba62b9cf-421a-4e69-9d3c-387c671b4752", ...}
```

Also ruled out during troubleshooting:
- NAT hairpinning (confirmed reachable from an external network, not just LAN)
- HTTP/3 / `Alt-Svc` header interference (removed via `servers { protocols h1 h2 }` in Caddy — confirmed header no longer present; issue persisted)
- Rate limiting (confirmed sufficient quota remaining on both the registration and general endpoints)

### Error details

```shell
## Bug 1 — Automatic DCR flow fails despite a fully working registration endpoint

With no OAuth Client ID entered (default flow), clicking **Connect** in Claude fails immediately with:

> Registrierung beim Anmeldedienst von n8n fehlgeschlagen. Du kannst es erneut versuchen oder eine OAuth Client ID in den Connector-Einstellungen hinzufügen.

Reference IDs reproduced across multiple attempts, including after all server-side fixes above:
- `ofid_f613a95e7b4b3259`
- `ofid_93228167821f2ed1`
- `ofid_217a9825dc9164a2`

Since the manual `curl` POST to the exact same `registration_endpoint` succeeds with `201`, this points to a client-side failure in Claude's DCR flow rather than a server misconfiguration.

## Bug 2 — With a manually entered Client ID, Claude uses the wrong authorization path

As a workaround, the `client_id` obtained from the manual DCR test above (`ba62b9cf-421a-4e69-9d3c-387c671b4752`) was entered manually in the connector's Advanced Settings (OAuth Client ID field, no secret, since `token_endpoint_auth_method: "none"`).

Clicking **Connect** now redirects to:

https://n8n-nh.duckdns.org:48443/authorize?response_type=code&client_id=ba62b9cf-...&redirect_uri=https...

This returns a `404 Error` — because the authorization server's actual `authorization_endpoint`, as advertised in its own metadata (see step 4 above), is:

https://n8n-nh.duckdns.org:48443/mcp-oauth/authorize

Claude appears to fall back to a hardcoded `/authorize` path relative to the connector's base URL instead of using the `authorization_endpoint` value from the previously-fetched Authorization Server Metadata document.
```

### Expected behavior

- Bug 1: DCR should succeed against a spec-compliant `registration_endpoint`, matching the behavior of a manual `curl` POST to the same URL.
- Bug 2: When a manual Client ID is supplied, Claude should still use the exact `authorization_endpoint` (and `token_endpoint`) paths from the discovered Authorization Server Metadata, not a hardcoded `/authorize` relative to the server's base URL.

### Additional context

Server-side setup was verified working end-to-end using `curl` for every step of the OAuth discovery, protected resource metadata, authorization server metadata, and dynamic client registration flow. Happy to provide further logs or repro details if useful.