摘要：CLI 一个任务要持续几十分钟、来回请求多次，网页端能忽略的轻微丢包在这里会变成中途断开。处理顺序是换低丢包专线、开 TUN、避开晚高峰的中转节点。
一分钟速查
- 换专线节点：选 IEPL/IPLC 专线的美国、日本、新加坡节点。
- 开 TUN 模式：避免子进程或新窗口漏走代理。
- 避开中转：中转节点晚高峰更易拥塞。
- 固定节点：关自动测速切换，任务中断连会直接断。
处理步骤
换专线节点
选 IEPL/IPLC 专线的美国、日本、新加坡节点。
开 TUN 模式
环境变量只对当前终端生效，Codex 的子进程或新开窗口可能漏掉代理，TUN 在系统层接管。
避开高倍率与中转
中转晚高峰更拥塞，高倍率节点资源也紧张。
固定节点
关闭客户端自动测速切换，任务进行中切换会直接中断。
观察时段
只在晚上 20-23 点频繁断开，是晚高峰拥塞，换专线或错峰跑长任务。
如何确认是丢包问题
在同一终端持续 ping 当前节点服务器，或用客户端自带的延迟测试反复测几次。延迟忽高忽低、测试时偶尔超时，基本可确认线路不稳。换一个节点后问题消失，就说明原来的节点不适合 CLI。
为什么 CLI 比网页更挑节点
网页对话单次请求短，偶尔丢包会被重试掩盖；Codex CLI 执行任务时连接持续时间长、交互次数多，丢包一旦累积就表现为中断或超时。同一个节点可能网页够用、CLI 不够用。
关于 Codex 断连的 3 个误区
- 「网页能用 CLI 就能用」——CLI 是长连接，对丢包敏感得多，要单独验证；
- 「断了就是 Codex 服务挂了」——先查节点丢包和自动切换，多数是本地网络问题；
- 「延迟越低越好」——CLI 更看丢包率，低延迟高丢包照样频繁断连。