[BUG] Claude apps gateway SSRF guard bypasses HTTPS_PROXY by connecting to resolved IP, breaking deployments behind HTTP proxies

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude apps gateway cannot start in environments where outbound internet traffic is routed through a corporate HTTP proxy (HTTPS_PROXY / HTTP_PROXY) and the container has no direct internet access (private subnet, no NAT gateway).

At startup, the gateway SSRF guard resolves the OIDC issuer hostname to an IP address, then opens a TCP connection directly to that IP, bypassing HTTPS_PROXY entirely. The connection never reaches the proxy and is dropped at the network level. The task crashes immediately with exit code 1 and loops indefinitely.

What Should Happen?

Claude apps gateway cannot start in environments where outbound internet traffic is routed
through a corporate HTTP proxy (HTTPS_PROXY / HTTP_PROXY) and the container has no direct
internet access (private subnet, no NAT gateway).

At startup, the gateway SSRF guard resolves the OIDC issuer hostname to an IP address, then
opens a TCP connection directly to that IP, bypassing HTTPS_PROXY entirely. The connection
never reaches the proxy and is dropped at the network level. The task crashes immediately with
exit code 1 and loops indefinitely.

Error Messages/Logs

{"ts":"2026-07-01T08:13:12.369Z","evt":"config.load","path":"/etc/claude/gateway.yaml"}
[gateway] 2026-07-01T08:13:12.768Z info waiting for migration lock
claude gateway: connect ECONNREFUSED 52.31.6.XX:443

52.31.6.XX is a raw IP of cognito-idp.eu-west-1.amazonaws.com — the gateway resolved the hostname then connected directly to the IP, bypassing HTTPS_PROXY.

Steps to Reproduce

1. Deploy Claude apps gateway on ECS Fargate (or any container runtime) in a private subnet

with no direct internet access (no NAT gateway)

1. Set HTTPS_PROXY / HTTP_PROXY environment variables pointing to a corporate HTTP proxy
2. Configure gateway.yaml with an OIDC issuer reachable via the proxy (e.g. Amazon Cognito

https://cognito-idp.eu-west-1.amazonaws.com/<pool-id>)

1. Start the gateway — it crashes immediately

Note: the bug is not specific to Cognito — any OIDC issuer will trigger the same behavior
since it is the SSRF guard that bypasses the proxy, not the issuer itself.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.198

Platform

AWS Bedrock

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

The SSRF guard documentation states:

"resolves DNS, blocks link-local and cloud-metadata addresses, and pins the connection to the resolved IP"

Pinning to the resolved IP is a valid SSRF mitigation, but it should not bypass the proxy transport. The expected implementation would be:

1. Resolve DNS
2. Validate the resolved IP (SSRF check)
3. Route the actual TCP connection through the proxy using the original hostname as the CONNECT target

Why standard workarounds are not viable:

| Attempted workaround | Result |
|---|---|
| HTTPS_PROXY configured | Ignored — gateway connects to raw IP directly |
| *.amazonaws.com in NO_PROXY | Connection goes direct, blocked (no NAT) |
| Whitelist raw OIDC provider IPs | Not viable — IPs rotate frequently |

This affects any enterprise deployment behind a corporate proxy without direct internet access — a very common topology for production workloads.