Skip to content

Codex 项目使用时的网络要点:长任务稳定性与断连处理 ​

Codex 项目使用时的网络要点,首先是连接要持续很久,这是和聊天最大的区别。节点晚高峰丢包、出口 IP 轮换、客户端自动切换节点,任何一个都会让跑到一半的任务报错。所以项目使用阶段选节点看稳定性,而不是延迟。

Codex 本身的功能用法以官方文档为准,本文只讲网络层面的要点。

速读要点

  • 长任务三个要求:连接不断、出口 IP 不变、相关域名全走代理
  • 每隔固定时间失败一次是出口轮换;只在晚上失败是丢包
  • 固定一个主节点一个备用,手动切换,不用自动选择

Codex 项目使用时的网络要点:长任务的三个要求 ​

  1. 连接不断。 一次任务可能持续几分钟到几十分钟,中间断一次就要重来。丢包率要低,晚高峰尤其重要。
  2. 出口 IP 不变。 会话与来源 IP 关联,部分机场节点多出口轮换,几分钟换一个 IP,任务就会被判定异常。
  3. 相关域名全部走代理。 规则模式下 API 域名、认证域名、静态资源域名可能不在同一条规则里,漏一个就会出现奇怪的部分失败。

长任务断连的原因与处理 ​

现象原因处理
任务跑几分钟后超时节点丢包高换专线或低丢包节点
每隔固定时间失败一次出口 IP 轮换换单出口节点
刚开始就失败,网页正常终端没走代理设 HTTPS_PROXY 或开 TUN
部分功能正常部分失败规则漏域名临时切全局对比,补规则
只在晚上失败晚高峰拥堵换线路或错峰

判断出口 IP 是否轮换:在终端里连续执行几次 curl ifconfig.me,IP 变了就是多出口节点。

短任务、长任务、批量任务的要求差别 ​

任务类型持续时间首要指标可放宽
单轮问答、小修改几秒到一分钟延迟丢包、单出口
跨文件重构、跑测试几分钟到半小时单出口、丢包延迟
批量脚本、无人值守一小时以上丢包、连接数不限延迟

一个常见过程:白天用普通中转节点跑任务一切正常,晚上 21 点后每隔七八分钟任务就报连接重置。连续 curl ifconfig.me 发现 IP 在两个地址间轮换,再看客户端策略组是「自动测速」。改手动固定单出口后晚上仍偶尔超时,再换到专线节点才稳定。两步分别对应出口轮换与丢包,顺序不能反。

术语小注:连接重置(ECONNRESET)多与出口变化或中间设备掐断有关;超时多与丢包、节点拥堵有关;fetch failed 是两者都有可能的笼统报错,按时段规律区分。

规则分流的注意点 ​

  • 让终端走代理后,所有终端流量都经过节点,包括国内源的下载。可以在客户端规则里把国内域名设为直连,终端流量会跟随规则。
  • 不要开「自动选择最低延迟」「故障自动切换」,这两个功能在长任务中会导致出口变化。
  • 开 TUN 模式的,确认 TUN 的规则模式和系统代理一致,避免两套规则冲突。

详见TUN 与代理模式。

节点选择建议 ​

  • IEPL/IPLC 专线节点优先,晚高峰丢包明显低于普通中转。
  • 美国或日本的原生 IP、单出口节点。
  • 延迟 300ms 以内即可,重点看连续运行半小时不断。
  • 固定一个主节点和一个备用节点,主节点出问题手动切换,不要让客户端自动切。

推荐机场 ​

常见问题 ​

任务输出一半停住? ​

流式连接断开。换稳定节点,参考API 超时排查。

白天正常晚上频繁失败? ​

典型晚高峰丢包,见晚高峰变慢。

要不要为 Codex 单独买专线? ​

高频使用、任务时间长的值得,偶尔用普通线路也够。

下一步 ​

相关阅读 ​

本站内容仅供参考,部分链接含推广说明,详见各优惠页。关于本站