[yxxrn]

Problem

The OpenCode free-tier gate answers 403 FreeTierError when the request exits from an IP it has flagged. The transport itself succeeds, so the existing proxy-failure fallback in proxyAwareFetch never fires and every retry keeps leaving through the same flagged proxy pool — the lane stays 403 until a human rebinds the pool in the dashboard.

This is the failure mode users are hitting right now in #4983 (and the flip pattern reported in #4845): a configured pool whose egress IPs lose their reputation turns oc/* hard-403 with no automatic escape, while the identical request on the direct egress works.

Live measurement (same body, same headers, same minute, same machine)

egress	result
flagged pool (zone-isp_proxy3), 3 runs	403 FreeTierError ×3
direct (native IP), 3 runs	200 ×3
healthy pool (zone-isp_proxy2, the one 9router-go uses), 3 runs	200 ×3
any egress, body without the read/shell fingerprint tools	403 (the second gate layer — not touched by this PR)

Because the 403 arrives on a successful proxied response, the current catch-based fallback (Proxy failed, falling back to direct) is structurally blind to it.

Change

open-sse/utils/proxyFetch.js:

• After a proxied attempt returns 403, buffer the body and check for the FreeTierError marker. On a match, replay the request once on the direct egress (fetchWithTlsFallback(url, options, null)).
• strictProxy: true keeps its contract: the proxied response is returned as-is, never a replay (checked before the body is even consumed).
• A body already consumed by the first attempt (stream request bodies) cannot be resent — the original 403 is surfaced instead.
• If the direct replay itself fails, the original 403 is surfaced (never a transport error replacing a readable upstream answer).
• Non-gate 403s (any other error shape) are returned untouched with their original headers; streaming 2xx responses are never inspected — the new code only runs on status === 403.

Scope is intentionally narrow: the marker is OpenCode-specific, so no other provider can trigger the replay.

Verification

New tests/unit/opencode-freetier-direct-replay.test.js (5 cases):

1. proxied 403 FreeTierError → one direct replay → returns its 200 (asserts call order: dispatcher present → absent).
2. strictProxy: true → the 403 is returned, one fetch call, no replay.
3. proxied 403 with a non-gate body → returned untouched (headers preserved), no replay.
4. proxied 200 SSE stream → untouched, body not consumed, one call.
5. direct replay throws → the original 403 body is surfaced.

Results:

• This suite: 5/5 pass.
• Regression check on the existing proxy tests touching this file (strict-proxy-enforcement, qoder-proxy-replay, cursor-agent-strict-proxy): identical 6 failed / 8 passed with and without the patch (those failures are the pre-existing environment/red-test baseline documented in CLAUDE.md — missing root deps such as uuid), i.e. 0 pass→fail.

Security

No header manipulation, no credential or token handling, no new network targets: the replay goes to the same URL the caller requested, over the direct egress path that proxyAwareFetch already falls back to for transport failures. strictProxy stays fail-closed.

Refs #4983.

[MarcusHO929]

Withdrawn — correction after follow-up measurements (2026-10-20)

I withdraw my endorsement of #4987 as a root transport fix and the claim that this establishes a complementary DNS-plus-fallback solution. This correction concerns my comment only, not the author’s independent #4988 proposal.

Please do not treat the original text below as a current fix recommendation. I have withdrawn and am closing my local-DNS proposal #4987.

Follow-up measurements in this AdGuard setup showed a material side effect: with local DNS / numeric SOCKS targets, multiple pools could expose the same service-visible US egress; proxy-side DNS / domain targets exposed their respective distinct VPN egresses. We removed our locally hardcoded OpenCode DNS override and restored upstream 9router's original transport. The optional PR and the local hardcoded override were not the same implementation.

Earlier success/403 differences were time- and path-specific. They do not prove an upstream 9router DNS defect, a universal OpenCode fix, a Cloudflare WAF or load-shedding rule, or that our DNS override caused the IP-abuse flags. The exact server-side trigger and expiry remain unverified. Sorry for the earlier overstatement.

See #4987 for the full correction. No credentials or egress addresses are published here.

Superseded original comment — retained as history, not a current recommendation

Thanks for puting this together @yxxrn! This direct fallback is a great safety net when a proxy's egress IP genuinely loses its reputation or gets flagged by Cloudflare WAF.

I wanted to share our complementary findings from #4983 and #4987, as both PRs actually fit together really well:

Complementary findings on SOCKS proxies (#4987)

During our controlled tests on #4983 across 16 active SOCKS5 proxy pools, we found that many proxy rejections weren't caused by a permanently blacklisted proxy IP, but by SOCKS domain target addressing (remote DNS / ATYP 3):

• Sending opencode.ai as a domain target through the SOCKS tunnel resulted in 403 FreeTierError across all 16 pools.
• Resolving the destination address locally and sending the numeric IP through the exact same SOCKS proxy (while keeping original TLS SNI, HTTP Host, and certificate verification intact) turned all 16/16 pools back to 200 OK + complete streaming.
• Even the genuine, unmodified OpenCode CLI reproduced this exact split (403 over SOCKS with remote DNS, 200 direct or with local DNS).

How #4987 and #4988 complement each other

1. [Withdrawn] fix(proxy): add opt-in local DNS for SOCKS5 targets #4987 fixes the root transport path: With ?dns=local, SOCKS proxies avoid triggering the domain-routing 403 in the first place. This allows users who rely on proxy rotation or have strictProxy: true enabled to keep their traffic inside their configured proxy pools.
2. fix(opencode): replay a proxied 403 FreeTierError once on the direct egress (#4983) #4988 provides the graceful fallback: When a proxy IP is genuinely blacklisted/rate-limited by Cloudflare WAF (like datacenter IPs or overused egresses), this replay mechanism automatically rescues the request to direct egress (for non-strict proxy users) instead of leaving the lane dead.

Having both—a proper transport option so proxies can succeed (#4987), plus a direct replay fallback when an egress is truly burnt (#4988)—gives users the best of both worlds.

[luqman-v1]

LGTM: replays OpenCode 403 FreeTierError once on direct egress when the proxy IP is flagged, while properly respecting strictProxy configurations. Safe and well tested.