Codex 属于持续与远程 AI 服务通信的开发工具：一次任务由几十到上百次模型请求与工具调用组成，全程依赖流式连接不中断。它对带宽几乎没有要求（每月几 GB 足够），对延迟的绝对值也不敏感，真正的门槛是丢包与连接连续性——晚高峰丢包超过 1%，或任务期间出口 IP 变化，任务就可能直接失败重来。
目录
Codex 的通信模型：不是「一问一答」
网页聊天是离散请求：发一条消息、收一条回复，中间断了刷新即可。Codex 完全不同——一次「重构这个模块」的任务会展开成一条持续的会话流：
- 客户端上传上下文（代码、目录结构）。
- 模型流式返回计划与代码差异。
- 工具调用（读文件、跑测试）→ 结果回传 → 模型继续。
- 循环几十次，直到任务完成。
整个过程可能持续 10–40 分钟，任何一个环节的连接中断都会让任务失败。这是它与 ChatGPT 网页对网络要求的本质差别，两者的逐项对比见 Codex 和 ChatGPT 对网络要求有什么区别。
三个指标的合格线
| 指标 | Codex 的要求 | 原因 |
|---|---|---|
| 带宽 | 几 Mbps 即可 | 传输内容是文本与差异 |
| 延迟 | 绝对值不敏感，波动 < 30% | 瓶颈在模型推理，不在往返 |
| 丢包 | 晚高峰 < 1% | 流式连接对重传窗口极敏感 |
丢包的测量方法与影响分级见 什么是丢包。
节点质量差的三种失败形态
stream error/ 任务中断：线路丢包，典型发生在 20:00–23:00 的中转线路上。- 反复要求登录或验证：节点 IP 共享严重，或任务期间自动切换了节点导致出口 IP 变化。
- 工具调用超时：延迟剧烈抖动，单次往返偶发性超过客户端超时阈值。
对应的排查流程见 Codex 长时间运行为什么容易掉线。
由此推导出的线路标准
- IEPL / IPLC 专线——绕开公网晚高峰拥塞，这是丢包 < 1% 的前提。
- 低共享 IP——减少验证与登录循环。
- 固定节点——把 OpenAI 域名固定到单一节点并关闭自动切换。
- 地区：美国优先，选择依据见 Codex 用什么节点最好。
完整的环境配置步骤（终端代理、TUN、验证方法）见 Codex 在国内怎么用；符合这些标准的服务商见 Codex 机场推荐。这套逻辑同样适用于 Claude Code 与 Cursor，横向差异见 AI 编程为什么更需要稳定网络。
常见问题
Codex 需要很大带宽吗？
不需要。Codex 传输的是文本、代码差异与工具调用结果，几 Mbps 就够；把预算花在线路稳定性上比花在带宽上有效得多。
延迟 250ms 会影响 Codex 吗？
几乎不会。美国节点 150–250ms 属于正常范围，Codex 的瓶颈是模型推理时间而不是网络往返。需要警惕的是延迟波动（时高时低），那通常意味着丢包。
为什么说丢包对 Codex 是致命的？
流式响应建立在一条持续连接上，丢包引起的重传超过容忍窗口时连接会被判定超时断开；网页聊天可以刷新重试，Codex 任务断开则前功尽弃。
怎么判断我的线路能不能跑 Codex？
晚高峰对节点连续 ping 100 次，丢包低于 1%、延迟波动小于 30%，再实际跑一个 10 分钟以上的任务验证，连续三天通过即可放心使用。