You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A request with stream:true deterministically ends in response.failed:
{"type":"upstream_error","code":"upstream_reset","message":"Upstream stream terminated unexpectedly: The socket connection was closed unexpectedly."}
Identical on every run. Via the ChatGPT client it surfaces as 502 upstream_server_error, failureStage=protocol-prelude, disconnecting after ~336ms.
Expected behaviour
The upstream SSE stream should stay alive — at least no worse than a direct curl, which streams DeepSeek /responses end-to-end without errors.
Root cause in my environment: Clash (Mihomo) fake-ip DNS returns 198.18.0.0/15 for api.deepseek.com, and OpenCodex's direct connection to the fake IP got its upstream SSE socket killed.
Workaround: set an explicit outbound proxy on the deepseek provider in config.json:
"proxy": "http://127.0.0.1:7897"
(per #2037 this arms the allowBenchmarkAddresses opt-in, so the hostname rides the proxy CONNECT instead of the fake IP)
After that, the minimal stream:true repro returns a complete SSE stream — no more upstream_reset.
Note: my provider already had "allowPrivateNetwork": true, which alone was not sufficient; the explicit proxy is what fixed it.
Activity
cybertingzhen commentedon Sep 28, 2026
Update: worked around it locally.
Root cause in my environment: Clash (Mihomo) fake-ip DNS returns 198.18.0.0/15 for api.deepseek.com, and OpenCodex's direct connection to the fake IP got its upstream SSE socket killed.
Workaround: set an explicit outbound proxy on the deepseek provider in config.json:
"proxy": "http://127.0.0.1:7897"
(per #2037 this arms the allowBenchmarkAddresses opt-in, so the hostname rides the proxy CONNECT instead of the fake IP)
After that, the minimal stream:true repro returns a complete SSE stream — no more upstream_reset.
Note: my provider already had "allowPrivateNetwork": true, which alone was not sufficient; the explicit proxy is what fixed it.