MCP connections return 503 DNS cache overflow from sandbox egress proxy (web/mobile)

Adding a CLI repro that contradicts the issue body's claim that \"Claude Code desktop CLI is unaffected (bypasses the sandbox proxy and connects directly).\"

Repro

• Environment: Claude Code CLI on macOS (Darwin 25.2.0), CLAUDECODE=1, CLAUDE_CODE_ENTRYPOINT=cli, version 2.1.119.
• Workload: A Python integration-test harness (uv run scripts/run_tests.py --tier long --env prod --workers 4) that fires parallel requests.post calls. ~40 tests over ~10 minutes.
• Failure: Intermittent 503 Service Unavailable with body DNS cache overflow on outbound HTTPS calls.

Two different upstreams, identical failure body

The same 503 body comes back from two completely unrelated services within the same run:

503 Server Error: Service Unavailable for url: https://studio.trelis.com/api/v1/file-stores/upload-url
    Response: DNS cache overflow

503 Server Error: Service Unavailable for url: https://e6244e0984ca77b967b1ecea6ce35eda.r2.cloudflarestorage.com/trelis-internal/...
    Response: DNS cache overflow

Confirmed origin-side that neither service emits this:

• studio.trelis.com resolves directly to a Hetzner static IP (no Cloudflare/CDN in front). The string DNS cache overflow is not in our codebase or our nginx container, and origin nginx/app logs show zero 503s during the failure windows.
• R2 doesn't emit a plaintext 18-byte DNS cache overflow body either.

Frequency and severity

Recurring on the test cron, getting more severe with parallelism:

| Date | Tests failing with this 503 | Workers |
|---|---|---|
| 2026-04-17 | 16 | 4 |
| 2026-04-21 | 3 | 4 |
| 2026-04-22 | 30/40 | 4 |
| 2026-04-24 | 5 | 4 |

Severity tracks parallelism + run length. Sibling tests on the same endpoint pass moments later, so the cache clears within seconds.

Real-world cost

We spent multiple sessions diagnosing this as a server-side issue (and shipped a closed-then-reopened-then-closed PR + a closed-as-duplicate-of-#716 issue) before noticing the failure body literally never appears in our infra logs. The error is opaque to both humans and to the agent because:

1. The 503 is indistinguishable from a real upstream 503 — the agent reasonably assumes our server / R2 returned it.
2. There's no header (x-deny-reason, custom server, etc.) flagging the response as sandbox-originated.

Concrete asks

1. Disambiguate the body. Prefix with something like claude-code-sandbox: DNS cache overflow so users / agents can grep their way out of the misdiagnosis.
2. Either raise the cache size or surface a per-process resolver. Reproduces at --workers 4 with mostly-stable hostnames (the R2 account-ID subdomain is constant — it's not a unique-hostname flood).
3. Surface to the agent as a structured tool-result hint. A system reminder when the sandbox proxy short-circuits an HTTP call would prevent the agent from drilling into the wrong layer.

For traceability: we closed our internal investigation as Trelis-LTD/studio#827 (not_planned) and Trelis-LTD/studio#863 (PR closed) once we identified this as the sandbox proxy.

Same issue for me. It appears intermittent as some earlier requests in the same session run worked.

Note I am running in a Claude Code cloud env that has full network access.

Here's the result of me responding to the Claude Code Routine session and asking it to test Google as well:

$ curl -sS -i -X GET https://www.google.com -w "\n\nDNS_TIME:%{time_namelookup}s\nTOTAL_TIME:%{time_total}s\nREMOTE_IP:%{remote_ip}\n"

HTTP/2 503 
content-length: 18
content-type: text/plain
date: Mon, 27 Apr 2026 10:18:09 GMT

DNS cache overflow

DNS_TIME:0.003412s
TOTAL_TIME:5.061237s
REMOTE_IP:74.125.202.113

I got the same problem on web sandboxed with turso urls outside mcp. Can't really see a clear pattern, except that it does not seem to affect more well known hosts. Otherwise the issue would be more well known.

edit: for me, all runs since 30 April have been stable. This is for requests to turso

Adding to this - we have also observed this exact error on multiple occasions. Seems to come and go.
Some days are particularly bad, we're unable to get requests through maybe 80%+ of the time.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

I haven't noticed the issue in over a month, so wondering if Anthropic actually fixed it and decided not to say something

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.