stream disconnected before completion: stream closed before response.completed #2138

likeaixxx · 2026-03-11T09:58:07Z

likeaixxx
Mar 11, 2026

想请问一下这个该如何去修改
工具是v6.8.51版本.
部署在日本的云服务器上, 域名解析用的是cloudflare.
使用docker compose部署和nginx在同一个docker网络服务

nginx配置是

server {
    listen       443 ssl;
    listen  [::]:443 ssl;

    ....证书

    location / {
        client_max_body_size 1024m;
        proxy_pass http://cpa:8317/;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Connection "";
        proxy_redirect off;
        proxy_buffering off;
        proxy_request_buffering off;
        proxy_cache off;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        send_timeout 3600s;
        chunked_transfer_encoding on;
        tcp_nodelay on;
        add_header X-Accel-Buffering no always;
        add_header Cache-Control "no-cache" always;
    }
}

codex 配置:

personality = "pragmatic"
sandbox_mode = "workspace-write"
web_search = "live"

model_provider = "cliproxy"
model = "gpt-5.4"
model_context_window = 1000000
model_auto_compact_token_limit = 900000
# model = "gpt-5.3-codex"
model_reasoning_effort = "xhigh"

[features]
collaboration_modes = true
steer = false
unified_exec = false
apps = false

[model_providers.cliproxy]
base_url = "https://xxxxxxxx/v1"
name = "cliproxy"
wire_api = "responses"
# env_key = "cliproxy"

现象是, 每次请求cpa的时候会出现两次
stream disconnected before completion: stream closed before response.completed
第三次就正常了.
cpa这里请求次数也不会增加. 但是是能看到nginx和cpa有请求日志的.
不太清楚这个该如何处理.

Answered by luispater

Mar 14, 2026

server {
    listen 80;
    listen 443 ssl http2;
    listen [::]:443 ssl;
    server_name hostname;

    ssl_certificate cert.crt;
    ssl_certificate_key cert.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    underscores_in_headers on;

    location / {
        proxy_pass http://codex_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_request_buffering off;
        proxy_next_upstream off;
        proxy_ssl_verify off;
        proxy_connect_timeout 30s;
        proxy_send_timeout 3600s;
        proxy_read_timeout 3600s;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
  …

View full answer

likeaixxx · 2026-03-11T10:29:30Z

likeaixxx
Mar 11, 2026
Author

已解决, AI给的nginx配置是responses/sse的配置, 我改成了websocket的配置后测试暂时未发现问题

0 replies

likeaixxx · 2026-03-12T09:54:04Z

likeaixxx
Mar 12, 2026
Author

。。还是不行，没招了

0 replies

luispater · 2026-03-14T18:23:34Z

luispater
Mar 14, 2026
Maintainer

server {
    listen 80;
    listen 443 ssl http2;
    listen [::]:443 ssl;
    server_name hostname;

    ssl_certificate cert.crt;
    ssl_certificate_key cert.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    underscores_in_headers on;

    location / {
        proxy_pass http://codex_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_request_buffering off;
        proxy_next_upstream off;
        proxy_ssl_verify off;
        proxy_connect_timeout 30s;
        proxy_send_timeout 3600s;
        proxy_read_timeout 3600s;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

你试试

3 replies

likeaixxx Mar 15, 2026
Author

还是不太行，我用AI分析了一下Nginx和cpa的日志：

这份 cpa 日志把问题基本定位清楚了：短响应不是 nginx 截断出来的，而是 CLIProxyAPI 自己就在应用层很快返回了 ⁠200。你 nginx 里那两类请求，一类是 ⁠5~8s 的大响应，一类是 ⁠0.3~0.5s / 0.7~1.2s 的小响应；而 cpa 日志里刚好也有对应的两类：⁠5.991s、⁠8.287s 和 ⁠337ms、⁠514ms。这说明“异常请求”在到 nginx 之前就已经变成短 200 了，所以主嫌疑已经从 nginx 转到了 CLIProxyAPI 自身或它所选中的上游 credential / proxy / provider 路径。 
从你贴的 cpa 日志看，短响应那两次分别是 ⁠Use API key ... for model gpt-5.4，而不是 OAuth；长响应里既有 API key 也有 OAuth。这很像 不同 key 命中了不同上游行为，而 CLIProxyAPI 本身又支持多 key、轮询路由，以及每个 API key 单独配置 ⁠proxy-url，所以很可能是某几个 key 或其对应的上游代理路径返回了“很短但仍是 200”的响应，客户端才会报 ⁠stream closed before response.completed。   
还有一个关键点：这个项目的 ⁠request-retry 只会在 ⁠403/408/500/502/503/504 时重试，不会重试 200。所以一旦某个上游返回的是“短小但合法的 200”，CLIProxyAPI 会直接把它透传出去，不会帮你兜底重试成正常长流，这和你现在看到的现象完全一致。  
我现在更倾向于两个方向。第一，某些 Codex key 本身返回了非预期但 200 的短结果；第二，某些 key 绑定了单独的 ⁠proxy-url，那条上游链路把流式请求变成了短 200。因为项目明确支持“全局代理”和“每 key 单独代理”，而你的日志又显示请求确实在轮到不同 key。你先不要再盯 nginx，先核对这几个短请求对应的 key 有没有单独代理、是否都走同一个出口、是否都指向同一个 ⁠base-url。  
配置层面还有两个值得立刻试的点：这个项目文档里 ⁠streaming.keepalive-seconds 默认是关闭的，⁠bootstrap-retries 也默认关闭；如果客户端或中间链路对流式首包/空闲比较敏感，建议先开成例如 ⁠keepalive-seconds: 15、⁠bootstrap-retries: 1。不过要注意，这更偏向“增强流稳定性”，不能解释你现在这种固定短 200 模式；它更像是辅助优化，不是主因修复。  
另外，这个项目最近版本里出现过和“最终事件 / 流处理”相关的修复，比如 ⁠fix(claude): prevent final events when no content streamed，以及流扫描缓冲区相关修复。虽然那条 release note 写的是 Claude，不是 Codex，但至少说明这个项目近期确实在修 streaming/final-event 这类问题；如果你不是最新版本，优先升级。 
所以当前最像的结论是：你的异常并不是 nginx 把一个正常长流切断，而是 CLIProxyAPI 某些请求路径本来就返回了短 200；Codex Desktop 把这种“没有完整完成事件的 200”识别成 ⁠stream closed before response.completed。 先查这两个短请求对应的具体 key、是否带独立 ⁠proxy-url、项目版本号，再看升级和关闭该 key 的单独代理后是否恢复正常。  
如果你愿意，我下一条可以直接给你一份 CLIProxyAPI 的最小排查清单，专门针对：⁠gpt-5.4、多 key、per-key proxy、⁠/v1/responses 流式返回。

这个是nginx日志

root@arm:~# tail -f -n 10 nginx/log/access.log
172.69.63.235 - - [15/Mar/2026:06:23:51 +0000] "POST /v1/responses HTTP/2.0" 200 179874 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=2.000 uct=0.001 uht=0.624 urt=2.000 ua="172.21.0.3:8317" us="200" ub="180594" sent="180883" reqid="6ace4236661c93c1410fa934f5d71f6e"
172.71.100.191 - - [15/Mar/2026:06:23:54 +0000] "POST /v1/responses HTTP/2.0" 200 221782 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=7.465 uct=0.001 uht=0.990 urt=7.465 ua="172.21.0.3:8317" us="200" ub="223323" sent="223763" reqid="25f596819378d933575657bb453c1df0"
172.71.100.191 - - [15/Mar/2026:06:24:02 +0000] "POST /v1/responses HTTP/2.0" 200 219950 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=7.122 uct=0.000 uht=4.058 urt=7.122 ua="172.21.0.3:8317" us="200" ub="221443" sent="221877" reqid="acca5823795934d9d5878be9f21ebe5d"
172.69.63.235 - - [15/Mar/2026:06:24:05 +0000] "POST /v1/responses HTTP/2.0" 200 1330 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=0.992 uct=0.001 uht=0.992 urt=0.993 ua="172.21.0.3:8317" us="200" ub="1802" sent="1592" reqid="4771381722dfb76785388a70ada610a8"
172.71.100.191 - - [15/Mar/2026:06:24:07 +0000] "POST /v1/responses HTTP/2.0" 200 1726 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=0.725 uct=0.000 uht=0.724 urt=0.724 ua="172.21.0.3:8317" us="200" ub="2238" sent="2015" reqid="69bd90b92e16cbd2d0831e5270f4b3cd"
172.70.234.23 - - [15/Mar/2026:06:24:14 +0000] "POST /v1/responses HTTP/2.0" 200 227361 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=5.879 uct=0.001 uht=0.596 urt=5.879 ua="172.21.0.3:8317" us="200" ub="229178" sent="229522" reqid="2e38a5c6af02a2ab954e5980a39e884f"
172.71.100.191 - - [15/Mar/2026:06:24:40 +0000] "POST /v1/responses HTTP/2.0" 200 232872 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=6.673 uct=0.001 uht=2.491 urt=6.673 ua="172.21.0.3:8317" us="200" ub="234965" sent="235573" reqid="2b1112b6587e35f249f2f3348f1cf5c6"
172.70.234.24 - - [15/Mar/2026:06:25:34 +0000] "POST /v1/responses HTTP/2.0" 200 1330 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=1.205 uct=0.001 uht=1.205 urt=1.206 ua="172.21.0.3:8317" us="200" ub="1802" sent="1592" reqid="2783fb9095f4fc638067a2263f9a9f2a"
172.71.100.191 - - [15/Mar/2026:06:25:36 +0000] "POST /v1/responses HTTP/2.0" 200 1726 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=0.535 uct=0.000 uht=0.534 urt=0.535 ua="172.21.0.3:8317" us="200" ub="2238" sent="2006" reqid="979010feeda3d1897e81487dc047bdfc"
172.69.63.234 - - [15/Mar/2026:06:25:44 +0000] "POST /v1/responses HTTP/2.0" 200 234563 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=6.788 uct=0.000 uht=0.681 urt=6.789 ua="172.21.0.3:8317" us="200" ub="236680" sent="237066" reqid="1b188c6cbf048207d97d1d33c075a938"
172.71.100.191 - - [15/Mar/2026:06:26:02 +0000] "POST /v1/responses HTTP/2.0" 200 224843 "-" "Codex Desktop/0.115.0-alpha.11 (Mac OS 26.3.1; arm64) unknown (Codex Desktop; 26.311.21342)" "150.230.6.254" rt=6.419 uct=0.000 uht=1.051 urt=6.420 ua="172.21.0.3:8317" us="200" ub="226597" sent="227085" reqid="2a3c5d413d54910fd6401386ea601e8c"

这个是cpa的日志

2026-03-15 14:30:33] [aa61b93d] [debug] [conductor.go:2745] Use API key sk-3...6160 for model gpt-5.4
[2026-03-15 14:30:33] [--------] [debug] [apply.go:289] thinking: applying config for user-defined model (skip validation) provider=codex model=gpt-5.4 mode=level budget=0 level=medium
[2026-03-15 14:30:39] [aa61b93d] [info ] [gin_logger.go:93] 200 |        5.991s |   150.230.6.254 | POST    "/v1/responses"
[2026-03-15 14:30:40] [2c30127f] [debug] [conductor.go:2745] Use API key sk-o...fZVb for model gpt-5.4
[2026-03-15 14:30:40] [--------] [debug] [apply.go:289] thinking: applying config for user-defined model (skip validation) provider=codex model=gpt-5.4 mode=level budget=0 level=medium
[2026-03-15 14:30:40] [2c30127f] [info ] [gin_logger.go:93] 200 |         337ms |   150.230.6.254 | POST    "/v1/responses"
[2026-03-15 14:30:41] [483a80b4] [debug] [conductor.go:2745] Use API key sk-u...q89H for model gpt-5.4
[2026-03-15 14:30:41] [--------] [debug] [apply.go:289] thinking: applying config for user-defined model (skip validation) provider=codex model=gpt-5.4 mode=level budget=0 level=medium
[2026-03-15 14:30:42] [483a80b4] [info ] [gin_logger.go:93] 200 |         514ms |   150.230.6.254 | POST    "/v1/responses"
[2026-03-15 14:30:43] [c2a2fc49] [debug] [conductor.go:2748] Use OAuth provider=codex auth_file=codex-4dd3e11f-like.aiquan@gmail.com-team.json for model gpt-5.4
[2026-03-15 14:30:43] [--------] [debug] [apply.go:289] thinking: applying config for user-defined model (skip validation) provider=codex model=gpt-5.4 mode=level budget=0 level=medium
[2026-03-15 14:30:51] [c2a2fc49] [info ] [gin_logger.go:93] 200 |        8.287s |   150.230.6.254 | POST    "/v1/responses"

看起来像nginx请求后， cpa很快就给nginx返回了一个什么，但是codex不认识这个东西。
版本：

root@arm:~# docker images
REPOSITORY               TAG       IMAGE ID       CREATED        SIZE
eceasy/cli-proxy-api     latest    83f0b1b22143   2 days ago     45.4MB
nginx                    latest    8d8e80999f5f   4 days ago     181MB

likeaixxx Mar 15, 2026
Author

nginx 配置

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name xxx;
    ssl_certificate     /home/ssl/fullchain.cer;
    ssl_certificate_key /home/ssl/xxx.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    underscores_in_headers on;
    location / {
        client_max_body_size 50m;
        proxy_pass http://cpa:8317/;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_request_buffering off;
        proxy_next_upstream off;
        proxy_ssl_verify off;
        proxy_connect_timeout 30s;
        proxy_send_timeout 3600s;
        proxy_read_timeout 3600s;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

likeaixxx Mar 15, 2026
Author

这个配置只是会短暂的报两次错误，其实是可以用的。而且失败的请求并不会计算到cpa的请求次数内。

likeaixxx · 2026-03-18T10:44:07Z

likeaixxx
Mar 18, 2026
Author

nonstream-keepalive-interval: 0
streaming:
  keepalive-seconds: 15   # Default: 0 (disabled). <= 0 disables keep-alives.
  bootstrap-retries: 1    # Default: 0 (disabled). Retries before first byte is sent.

我在 cpa的配置中把这几个打开了. 暂时没出现错误了. 😂

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

stream disconnected before completion: stream closed before response.completed #2138

Uh oh!

{{title}}

Uh oh!

Replies: 4 comments 3 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

stream disconnected before completion: stream closed before response.completed #2138

Uh oh!

likeaixxx Mar 11, 2026

Replies: 4 comments · 3 replies

Uh oh!

likeaixxx Mar 11, 2026 Author

Uh oh!

likeaixxx Mar 12, 2026 Author

Uh oh!

luispater Mar 14, 2026 Maintainer

Uh oh!

likeaixxx Mar 15, 2026 Author

Uh oh!

likeaixxx Mar 15, 2026 Author

Uh oh!

likeaixxx Mar 15, 2026 Author

Uh oh!

likeaixxx Mar 18, 2026 Author

likeaixxx
Mar 11, 2026

Replies: 4 comments 3 replies

likeaixxx
Mar 11, 2026
Author

likeaixxx
Mar 12, 2026
Author

luispater
Mar 14, 2026
Maintainer

likeaixxx Mar 15, 2026
Author

likeaixxx Mar 15, 2026
Author

likeaixxx Mar 15, 2026
Author

likeaixxx
Mar 18, 2026
Author