ChatGPT 网页可用但 Codex 长任务持续断流

同一个账号、同一台电脑、同一个代理：ChatGPT 网页聊天流畅自如，Codex 一跑二十分钟的长任务就断在半路。这组对比很多开发者都遇到过，它反映的不是「代理坏了」，而是两种业务对连接的要求根本不同。网页聊天每轮交互是一次相对短的请求，偶尔断开可以无感重连；Codex 的长任务则需要一条流式连接持续存活几分钟到几十分钟，期间任何一次连接重置，都意味着任务中断或重跑。

换句话说，普通浏览容忍「偶尔断、快速恢复」，长任务要求「全程一次都不能断」。排查也就围绕「是谁掐断了这条长连接」展开——嫌疑人按出场频率排序：客户端的自动节点切换、跨境链路的连接重置、节点自身的稳定性。

关掉自动切换，固定单一节点

最常见的凶手在自家客户端里。url-test（自动测速）、fallback、负载均衡这类策略组会根据测速结果切换节点，而切换的瞬间，经由旧节点的连接全部作废——正在传输的流式响应随之中断。网页浏览感知不到这种切换，长任务却每次都被命中。

1. 在客户端里为 AI 工具的流量新建一个手动选择（select）策略组；
2. 组内只放两三个经过验证的稳定节点，日常固定用其中一个；
3. 若必须保留自动测速组，把测速间隔调长（如 30 分钟以上），并避免 AI 流量走这个组。

节点怎么挑，为 AI 工具选择节点的思路有系统性的展开：对长任务而言，丢包率和高峰稳定性的权重远高于延迟数字。

识别链路层的连接重置

固定节点后仍断流，就要看链路本身。跨境 TCP 长连接可能被中间设备盯上：连接存活时间过长、流量特征明显时被静默重置（RST），表现为输出突然停住、客户端无报错或仅有连接关闭记录。判断与应对：

• 打开客户端的连接面板，跑任务时盯住对应连接——断流瞬间该连接被关闭重建，而节点并未切换，即符合链路重置的特征；
• 换协议对照测试：把同样的任务分别在 Trojan/VLESS（TCP 系）与 Hysteria2（UDP 系）节点上各跑一次，基于 UDP 的协议不依赖单条 TCP 长连接，对这类重置的耐受性通常更好；
• 换端口、换入口的节点也值得一试，不同线路被干扰的程度差别很大。

检查超时与保活设置

长任务有个特殊阶段：模型长时间思考、工具静默执行时，连接上可能几十秒没有数据流动。空闲超时设置过短的环节会认为连接已死并主动关闭。

检查点	位置	建议
空闲超时	客户端/内核配置	放宽 TCP 空闲超时相关参数
Keep-Alive	内核配置（如 keep-alive-interval）	保持较短间隔的保活探测
本地代理链	终端里的 HTTP_PROXY 等	确认没有额外的本地代理层附加超时

改动一处就重跑一次任务验证，避免多处同时修改后无法归因。

评估节点本身的质量

以上都处理后仍不稳定，回到最朴素的可能：节点在高峰期丢包。丢包不仅拖慢速度，也会拖垮长连接——具体机制与节点延迟低但下载速度慢中分析的重传问题同源。另外注意节点切换带来的出口 IP 变化会触发部分服务端的会话校验，这也是固定节点的另一重理由，详见出口 IP 一致性对 AI 服务的影响。

验证结果

验证标准要贴近真实负载：连续跑两三个 15 分钟以上的长任务，全部完整跑完且流式输出无中断停顿，才算达标；只用网页聊天验证是不够的。同时在连接面板确认——任务期间对应连接自始至终是同一条，没有被重建过。如果断流频率从「每次必断」降到「偶发」，说明方向正确，剩余的偶发中断可以用任务拆分来兜底。