[MarcusHO929]

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

I am withdrawing this proposal and the recommendation to use local DNS as an OpenCode 403 fix. Please do not merge this PR on the basis of my earlier diagnosis.

Later controlled checks in the same AdGuard SOCKS setup showed that local resolution / a numeric SOCKS target could lead multiple configured pools to the same service-visible US egress. With proxy-side DNS / a domain SOCKS target, the checked pools exposed their respective distinct VPN egresses. This was also reproduced by explicitly comparing socks5:// and socks5h:// with fresh trace URLs. No IP addresses, account details or credentials are included here.

We have removed the locally installed, hardcoded OpenCode DNS override and restored the byte-identical original 9router 0.5.104 transport. A local SOCKS/HTTPS regression check confirms domain addressing, original Host/SNI, and certificate verification. Follow-up checks with the restored installed transport showed the expected distinct pool egresses.

Important qualifications:

• The hardcoded local override was our local modification, not upstream 9router's default behavior. This PR itself was opt-in and retained proxy-side DNS by default; it should not be confused with that local override.
• Earlier successful responses were time- and path-specific observations, not evidence that local DNS repaired an upstream 9router defect or a general OpenCode access policy.
• We have not established that the DNS change caused any IP-abuse flag. We have not established the gateway's trigger, thresholds or expiry time.
• My earlier attribution to Cloudflare WAF, load-shedding or a guaranteed combination of DNS and fallback fixes was not demonstrated and is withdrawn.

I am closing my PR without merging. Other authors' fallback proposals are independent and are not being withdrawn by this correction. Sorry for the overstatement in the earlier diagnosis.

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

Summary

Add an opt-in local DNS mode for SOCKS5 proxy URLs:

socks5://127.0.0.1:1080?dns=local

Unparameterized URLs and ?dns=remote retain the existing remote/proxy-DNS behavior. This is a transport option, not a provider identity/header change or a hardcoded OpenCode exception.

Related: #4983, especially the controlled observations in #4983 (comment) .

Why

In an existing AdGuard SOCKS setup, the same OpenCode request returned 403 with the hostname sent as a SOCKS domain target, but 200 when the destination was resolved locally and its numeric address sent through the same SOCKS proxy. HTTP request data, Host/SNI and verified TLS identity were held constant. Numeric IPv4 and IPv6 both worked; the exact gateway-internal routing rule remains unknown.

The locally scoped workaround restored all 16 existing pools with strictProxy:true. This PR generalizes the DNS choice as an explicit per-proxy URL option rather than silently changing DNS for all users or special-casing OpenCode.

The actual PR source was also smoke-tested against the affected existing SOCKS proxy with identical synthetic request data: remote mode -> 403, local mode -> 200 / OK / completed stream. This does not claim to fix every OpenCode 403 or the separate GLM 429 Endpoint is unavailable.

Changes

• Add a shared DNS-aware dispatcher factory for model transport and dashboard proxy tests.
• For socks5: ... ?dns=local, resolve with the system resolver and pass the IPv4/IPv6 result to the existing SOCKS tunnel implementation; retain the original HTTP origin, TLS SNI and certificate hostname.
• Keep remote DNS as the default. Separate DNS-mode URLs already have separate dispatcher cache keys.
• Bound waiting for local DNS to five seconds; skip lookups for IP literals.
• Reject invalid/duplicated/non-SOCKS DNS mode options as configuration errors instead of silently falling back to direct access.
• Require Undici >= 7.30.1 for the exported SOCKS5 dispatcher used here. SOCKS5 remains experimental in Undici.
• Document opt-in use, DNS privacy, existing Strict Proxy / STRICT_SSL behavior and cancellation limits.

Security / compatibility notes

• Opt-in local DNS exposes destination lookups to the local/system resolver rather than the proxy resolver. It can change split-DNS/routing results. Use a dedicated pool entry if only one provider needs this behavior.
• No new proxy addresses, credentials, provider headers/fingerprints, destination IP constants or disabled TLS checks.
• Existing non-strict direct fallback and TLS fallback policies are unchanged. Enable Strict Proxy if failed proxy requests must not be retried directly.
• The lookup deadline bounds the dispatcher's wait, not the underlying OS DNS operation. Cancellation prevents target HTTP delivery, but an already pending lookup may still complete and initiate a SOCKS handshake.
• No migration, default behavior change or production installation modification is required by this PR.

Tests

• Red -> green regression for local numeric SOCKS targets versus remote domain targets.
• 26/26 targeted tests pass:

  cd tests
  npm test -- unit/socks-proxy-dns.test.js unit/strict-proxy-enforcement.test.js unit/qoder-proxy-replay.test.js

• Real local SOCKS + HTTPS fixtures exercise TLS trust/hostname, original Host/SNI, IPv4/IPv6, IP literals, percent-encoded proxy credentials, DNS failure/timeout, caller cancellation, cache-mode separation, model transport and dashboard proxy tests. No external service is needed for these tests.
• ESLint on changed JavaScript files: pass.
• npm run build: pass (optional better-sqlite3 binding unavailable with lifecycle scripts disabled; supported node:sqlite fallback used).
• Full suite run in isolated HOME/DATA_DIR without inherited credentials: 3599 passed / 90 failed / 93 pending. Unmodified master at 87a74e1, using the same installed dependencies and conditions: 3589 passed / 90 failed / 93 pending. Exact failed-case and failed-file sets match; no new failures. That full current run preceded the last two IPv6/IP-literal additions; the final 26-test targeted run includes them.
• Independent read-only review: no remaining concrete blockers after addressing alias consistency, tracked documentation and precise DNS/cancellation wording.

The full suite is not green on the unmodified baseline either; I am not presenting this as a clean full-suite pass.