Environment

• OpenClaw version: 2026.4.14
• OS: macOS 26.3 (arm64), Mac mini
• Node.js: v22.22.2
• Network: Mainland China, traffic routed through VPN/proxy (Quantumult X)

Problem

The openai-codex provider (chatgpt.com/backend-api) is completely unusable when accessed from mainland China through any proxy node. Cloudflare returns 403 with cf-mitigated: challenge header, blocking all requests before they reach ChatGPT backend.

Root Cause

Cloudflare detects Node.js native fetch TLS fingerprint (JA3/JA4) as non-browser traffic and triggers a JS Challenge. This happens regardless of:

• Proxy node location (tested Japan 94.177.131.104, Canada 23.132.28.49, multiple IPs)
• Request headers (even with full browser User-Agent and Sec-CH-UA headers)
• OAuth token validity (token valid with 200+ hours remaining)
• Transport mode (both HTTP/SSE and WebSocket get 403)

Key evidence: Using Python cloudscraper library (which mimics Chrome TLS fingerprint) with the same proxy and same OAuth token returns 200 OK successfully. This confirms the issue is purely TLS fingerprint-based detection.

Error Messages Observed

1. LLM request failed: DNS lookup for the provider endpoint failed. — misleading; actually Cloudflare 403 HTML response
2. Authentication failed with an HTML 403 response from the provider. — Cloudflare challenge, not auth failure
3. LLM request failed: network connection error. — timeout variant
4. blocked URL fetch (url-fetch) target=https://chatgpt.com/backend-api/responses reason=Blocked hostname or private/internal/special-use IP address — SSRF guard blocks VPN fake-DNS IPs (e.g. 198.x.x.x from Loon/QX)

Additional Context

• Related issue: [Bug]: openai-codex error classification: actual 403/rate-limit shown as 'DNS lookup failed' #64092 (error classification for 403)
• Related PR: fix(agents): classify Cloudflare/CDN HTML error pages as transport failures #67642 (classify Cloudflare HTML error pages)
• The SSRF guard blocking fake-DNS IPs (issue Images not passed to Claude CLI - only path reference in text #4 above) is a separate but compounding problem. Setting request.allowPrivateNetwork: true resolves that layer, but the Cloudflare TLS fingerprint block remains.

Workaround

Deploy a local Python reverse proxy using cloudscraper to bypass Cloudflare TLS fingerprint detection:

1. Install cloudscraper:

   python3 -m venv /tmp/cftest && /tmp/cftest/bin/pip install cloudscraper

2. Run a local HTTP reverse proxy (port 18792) that forwards requests to chatgpt.com/backend-api via cloudscraper with Chrome TLS fingerprint emulation.

3. Configure OpenClaw to route openai-codex through the local proxy:

   {
     "models": {
       "providers": {
         "openai-codex": {
           "baseUrl": "http://127.0.0.1:18792",
           "models": [],
           "request": {
             "allowPrivateNetwork": true
           }
         }
       }
     }
   }

4. Restart gateway: openclaw gateway restart

Suggested Fix

Consider one of:

1. Add browser-like TLS fingerprint emulation to the openai-codex provider HTTP client (e.g. via undici with custom TLS settings or a bundled tls-client)
2. Provide a built-in request.tlsProfile option (e.g. "chrome") for providers that need Cloudflare bypass
3. Document this limitation and the workaround for users behind proxies/VPNs in regions where Cloudflare challenges are triggered