Claude 撞上下文回 400 丢正文；nginx 后日志 IP 全成 127.0.0.1
v8.0.36 起，Claude 以 model_context_window_exceeded 收尾时本地会回 400 并丢掉已生成的正文与 usage，修复只落到 dev；反代部署的站按默认配置会把日志来源 IP 记成 127.0.0.1，改一处 trusted-proxies 再重启即可。
这四个仓库在 17:00 之后的窗口里都没发新版本。
CLIProxyAPI 的 dev 多了一笔修复，仓库里多了两条报障和一张 PR。sub2api 有几条旧单在窗口内被顶起，codex-proxy 与 codex2api 零条目。
今晚真要动手的只有一件：反代的站要把日志里的来源 IP 找回来，改一处配置再加一次重启。其余几条用来判读你手上的日志，先确认自己踩在同一个版本上。
- CLIProxyAPI：v8.0.38，10-21 23:04 发布；dev 头 10-22 17:21。1
- sub2api：v0.2.17，10-16 12:41 发布；main 头 10-22 10:33。2
- codex-proxy：v2.1.20-beta.0543eaa，10-21 17:30 发布；dev 头 10-21 09:59。3
- codex2api：v3.1.1，10-17 05:46 发布；main 头 10-21 01:02。4
Claude 撞上下文窗口时，本地回 400，正文和 usage 一起丢
今天 11:22，fredcamaral 在 CLIProxyAPI 开了 #6861。5
触发条件是 Claude 以
stop_reason: model_context_window_exceeded 收尾。也就是生成把模型的上下文窗口填满了。非流式的结果是 HTTP 400。正文是
{"error":{"type":"invalid_request_error","code":"context_length_exceeded"}}。已经生成的文本、工具调用和 usage 一起被丢弃。代理内部照记这次用量，上游照扣，客户端什么也拿不到。
流式稍好一点：文本增量会先发出去，收尾补一个 error 事件，没有 finish_reason，也没有 usage 块。
这条从 v8.0.36 起就在。v8.0.35 的
claude_executor_execute.go 搜不到 context_length_exceeded，v8.0.36 起有。v8.0.37、v8.0.38 一路带着。你现在跑的 v8.0.38 是最后一个带它的发行版。
v8.0.38 里那段代码的注释把代价写明白了：
a request fault that is not retried on another credential。6
CLIProxyAPI v8.0.38
internal/runtime/executor/claude_executor_execute.go 第 413–431 行，米黄高亮为第 418–430 行：第 426 行把带 context_length_exceeded 的响应改写成 400。什么样的请求会撞上？Chat 客户端不传 max_tokens 时，翻译层会补一个默认值。7
这个默认值取模型登记表里的输出上限，函数是同一文件第 617 行的
defaultClaudeChatMaxTokensForModel。长会话里，输入加上这个上限会超过窗口。
Anthropic 把这条停因列在成功响应里，处置建议是当作被截断；OpenAI 的等价物是
finish_reason: "length"。8修复在 17:21 落到 dev：提交 c2dfec28，作者 Luis Pater，6 个文件 +102/−62。提交信息带
Closes: #6861。9改动落在三处。第一处是映射表。
dev 的
mapAnthropicStopReasonToOpenAI 第 317 行改成 case "max_tokens", "model_context_window_exceeded":，两种停因都回 length。10v8.0.38 同一函数第 339 行只有
case "max_tokens":。第二处是非流式的 finish_reason 守卫。
dev 第 499 行改成
toolCallsCount > 0 && finishReason != "length"。v8.0.38 第 526 行还是裸 if toolCallsCount > 0。差别出在被截断的工具调用上：v8.0.38 一律报
tool_calls，参数只有半截 JSON。这次改动照的就是他评论里给的写法。第三处是把 execute 里那段合成 400 整个删掉。
dev 分支
internal/translator/claude/openai/chat-completions/claude_openai_response.go 第 310–332 行，高亮为第 311–326 行：第 317 行已同时收 max_tokens 与 model_context_window_exceeded。Responses 那条保持原样。
dev 的
claude_openai-responses_response.go 第 1275 与 1681 行仍把这个停因写成 context_length_exceeded 错误对象。走 /v1/responses 的客户端还会看到它。11今晚能做的：让请求别撞窗口。Chat 客户端显式带 max_tokens，或先把上下文压下去。
撞上之后重试同样拿不到内容——400 被判成请求级故障，不会换凭证。
#6861 已经打了 Fixed 标签，状态仍是 open。这个组合在 CLIProxyAPI 里就是修复进了 dev、还没进发行版。
反代之后，请求日志里的 IP 全是 127.0.0.1
17:16，lxc911008 在 CLIProxyAPI 开了 #6879：用 nginx 做反代，请求日志里的 IP 全变成 127.0.0.1，之前是正常的。12
下面看的是 v8.0.38 的现状。
日志里并排写着三个字段。
client_ip 来自 requestClientIP()，只取 request.RemoteAddr 的 host 段。gin 的
c.ClientIP() 只在直连对端被信任时才读转发头，而 server.trusted-proxies 默认是空数组。注释写得很直：空列表表示不信任转发头，改这项要重启。14
v8.0.38
config.example.yaml 第 41–53 行，高亮为第 42–48 行：默认空列表、示例填法与「改完要重启」。nginx 同机部署时，
client_ip 永远是 127.0.0.1——这一列按设计就是直连地址。resolved_client_ip 和访问日志那一行也跟着退回直连地址。动作：在
server.trusted-proxies 填 nginx 的地址（同机填 127.0.0.1，或直接给网段），然后重启进程。做完之后
resolved_client_ip 与访问日志那一列才是真实来源 IP。历史日志要补真实来源，读 x_forwarded_for 那一列。配错也有信号。
internal/api/server.go 第 138 行会打一条 invalid trusted-proxies configuration; forwarded client IP headers will be ignored。同时它把信任列表置空。日志里出现这句，说明转发头根本没被读。
Codex 首字未出就被中断，会被判成上游失败
17:09 开的 CLIProxyAPI PR #6878 处理另一种误判。15
条件是 Codex 响应在产生任何输出前被中断。
收尾事件是
response.incomplete、incomplete_details.reason=interrupted、空 output、0 输出 token。四条都符合就返回 true。之后本地造一条
stream error: upstream terminated with incomplete empty response (0 tokens)。这张 PR 的改法只有四行：判定函数开头加一句，
reason == "interrupted" 直接返回 false，其余原因照旧。18
PR #6878 头分支
internal/runtime/executor/helps/codex_terminal_incomplete.go 第 27–54 行，高亮为第 28–48 行：第 38–41 行把显式 interrupted 排除出空响应判定。还没合并。用法是判读：日志里出现这条 0 token 的 stream error、而客户端那边其实是你自己点了中断，那就是这个判定在起作用。
它顺手把上游连接作废了，下一轮会换一条。
窗口里其余几条
- #6853（eaxeax，上期开的那张凭据身份守卫单）：17:18 与 17:38 各落一笔提交，现在 4 笔提交、5 文件 +666/−8、open、clean。两笔提交分别叫「同一 token 换了账号之后，忽略上一个账号的结果」与「把替换快照的干净起步补完」。19
- #6876（l-lesetong，16:57 开、17:00 补评论）：v8.0.38 上，codex 认证账号全部停用后，单用
AI providers里那条 codex 类型会回 503auth_unavailable: no auth available (…; last upstream error: session_blocked_by_cyber_policy: …)。20 报障人自己试出来的解法是：同一把 key 再建一条 openai 兼容 provider，又能正常调度。我核到的部分只有两处——no auth available出自scheduler.go第 683 与 699 行两条出口，括号里那句取自最后一个候选凭证的上游错误；session_blocked_by_cyber_policy在本仓源码里搜不到，是上游原文。21 - sub2api #8296（16:09 开）：报的是「代理返回 HTTP/2 数据帧，客户端却按 HTTP/1.1 解析」，贡献者 StarryKira 在 17:41 回了一句「Claude Code 就不支持 HTTP2」。22
上游与重置
Codex 重置还没落地。codex-reset.com 首页写今日 UTC 尚未重置，最近一次已验证的全局重置是 10-20 14:33（北京）。
累计 56 次全局、10 次 banked，节奏约每两天一次。25
opentherank 那边记的数是 64 次、中位间隔 3.1 天、最长 68 天。26
Tibo 那句「tomorrow before 10am PST」的目标点是北京 10-23 01:00 之前，眼下还没到点。
今晚的清单
- 反代部署的站：
server.trusted-proxies填 nginx 地址，重启。这是今晚唯一必须动的一处。 - Claude 走 Chat Completions 的长会话：让客户端显式带 max_tokens，或先压缩上下文；撞上 400 之后重试不会换号。
- 日志里出现 0 token 的 incomplete empty response、而客户端侧是自己中断的：按 #6878 那条判读，不用换凭证。
- 等：c2dfec28 进发行版，#6853 合并。
References
- 1CLIProxyAPI releases
github.com
- 2sub2api releases
github.com
- 3codex-proxy releases
github.com
- 4codex2api releases
github.com
- 5CLIProxyAPI issue #6861
github.com
- 6
- 7v8.0.38 claude_openai_request.go 第 61 行
github.com
- 8Anthropic 处理停因文档
platform.claude.com
- 9CLIProxyAPI 提交 c2dfec28
github.com
- 10dev 的映射表第 317 行
github.com
- 11dev 的 Responses 翻译第 1275 行
github.com
- 12CLIProxyAPI issue #6879
github.com
- 13
- 14v8.0.38 config.example.yaml 第 42–48 行
github.com
- 15CLIProxyAPI PR #6878
github.com
- 16
- 17
- 18PR #6878 的改动
github.com
- 19CLIProxyAPI PR #6853
github.com
- 20CLIProxyAPI issue #6876
github.com
- 21
- 22sub2api issue #8296
github.com
- 23OpenAI 状态页
status.openai.com
- 24Anthropic 状态页
status.anthropic.com
- 25codex-reset.com
codex-reset.com
- 26opentherank 的 Codex 重置追踪
opentherank.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.