Self-hosted 4.34.x: MCP OAuth metadata returns internal ingress host as issuer

💬 Self Hosted Retool
, ,
1

Hi all,

We enabled the Retool MCP server on our self-hosted instance, but Claude Code can't complete the OAuth login: the authorization server metadata points to our internal ingress host instead of the public one.

Setup

  • Self-hosted Retool 4.34.9, Kubernetes (still the same after updating to the latest 4.34.x patch)
  • Traffic: nginx reverse proxy → Kubernetes ingress → Retool; Host and X-Forwarded-Host are passed through with the public host
  • Public host: retool-sandbox.example.com
  • Internal ingress host: retool.internal.example.com (not resolvable from client machines, not set in any of our env variables)
  • BASE_DOMAIN and OAUTH_MAIN_DOMAIN are set to the public host

Client error
SDK auth failed: getaddrinfo ENOTFOUND retool.internal.example.com

Discovery chain

  1. POST /mcp → 401
    www-authenticate: Bearer realm="mcp", resource_metadata="https://retool-sandbox.example.com/.well-known/oauth-protected-resource" :white_check_mark:
  2. GET /.well-known/oauth-protected-resource
    "authorization_servers": ["https://retool-sandbox.example.com"] :white_check_mark:
  3. GET /.well-known/oauth-authorization-server
    "issuer": "https://retool.internal.example.com", and authorize/token/register endpoints on the same host :cross_mark:

Setting HOST_HEADER_NAME=x-forwarded-host on the backend didn't change step 3.

Where does the backend take the issuer host from, and how do we make it advertise the public host? Is this a known issue?

Thanks!

2

Summary

On self-hosted Retool 4.34.x (Kubernetes), the Retool MCP server's OAuth authorization-server metadata (/.well-known/oauth-authorization-server) advertises the internal ingress host (retool.internal.example.com) as the issuer and in the authorize/token/register endpoints instead of the public host, so Claude Code's OAuth login fails with getaddrinfo ENOTFOUND despite BASE_DOMAIN and OAUTH_MAIN_DOMAIN being set to the public host and HOST_HEADER_NAME=x-forwarded-host having no effect.

AI Response

This matches a known self-hosted pattern where the MCP/agent services generate links from their own internal address rather than the configured public origin. The MCP server has a dedicated external-URL setting beyond BASE_DOMAIN/OAUTH_MAIN_DOMAIN: set the Helm value mcp.config.mcpServiceExternalUrl to the exact public origin (scheme + host, no trailing slash) and confirm it is propagated to the agent/sandbox proxy service that produces the metadata. Also verify the full set of new-app-builder/agent sandbox services are enabled, since the MCP server shares those prerequisites. If the issuer host still resolves internally after that, it points to the external origin not being applied to the generated metadata rather than a proxy header issue.

Sources

:bookmark: [Self-hosted] MCP upload using tool retool_start_prepared_import returns internal link
A directly parallel self-hosted 4.34.x report where the MCP server returns an internal Kubernetes cluster host instead of the public domain, and surfaces the mcp.config.mcpServiceExternalUrl setting that governs the externally advertised MCP URL.
:bookmark: Odd url when sending user invites or password reset - self hosted
A solved self-hosted thread corroborating the same base-URL misconfiguration class, where generated links used an internal host instead of the configured external domain.

The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a :heart:, :+1:, or :-1:. Or by marking this post as the "Solution"! Let us know if you have any feedback here. :rocket: