Codex 一直 Reconnecting：网页能开、客户端连不上怎么排查

网页端打开正常，编辑器或命令行里的 Codex 却卡在 Reconnecting... waiting for network，紧接着抛出 Connection failed: error sending request，重试十几次也进不去——这个组合很容易让人误判成账号被封或者服务整体故障。实际上，绝大多数情况下账号和服务都没问题，断掉的是客户端那条需要持续保持的连接。

值得先说明的是，浏览器里能刷开页面，和 Codex 客户端能正常工作，验证的并不是同一件事。网页加载是一串短请求，拿到 HTML 就结束；Codex 这类编码助手在会话期间要保持流式输出、心跳和工具调用往返，连接要挂很久。中间只要有一环不擅长处理长连接，网页照常、客户端就一直重连。

先分清两种「连不上」

排查之前先看报错文案，不同文案指向完全不同的方向：

把「客户端连不上」和「模型满载」混为一谈，是最常见的排查误区——前者花时间改网络配置才有用，后者改什么都没用，只能错峰或换模型。

为什么网页能开，客户端却一直在重连

按出现频率从高到低，大致是这几类：

代理对长连接不友好。 很多代理节点对短请求处理得很好，但连接一旦挂久了就会被中间设备回收，或者在协议握手阶段超时。表现就是网页秒开、客户端反复掉线。同一账号换个节点就恢复，是这类问题最典型的特征。

全局 TUN 模式与虚拟网卡打架。 TUN 模式接管全部流量，遇到 WSL、Docker、VPN 这类自带虚拟网卡的环境时，容易出现路由环路、端口占用或网卡假死。此时系统看起来有网，实际新建连接失败。

WSL 与 Windows 之间的代理地址不通。 WSL2 默认是独立的 NAT 网络，Windows 上的代理客户端通常只监听本地回环地址，WSL 里访问不到宿主机的这个监听。桌面客户端访问 WSL 内项目时尤其容易遇到，换成在 Windows 原生目录下运行就正常——这类「换个运行位置就好了」的现象，本质是两边的网络栈和路径解析不同，而不是账号问题。

系统时间偏差或证书校验失败。 时间偏差过大时 TLS 握手会被拒绝，报错往往也是笼统的请求失败。

本机缓存或旧配置残留。 早期设过的代理环境变量没清理，和新配置冲突。

排查清单：从网络层往应用层走

按顺序做，每一步都能排除掉一批可能，不要一上来就换节点乱试。

1. 确认基础连通性

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' --max-time 15 https://chatgpt.com/

返回 200 且耗时正常，说明 DNS 和 TLS 这一段没问题，问题在长连接或客户端配置。返回超时或证书错误，就先修网络层。

2. 单独测试长连接会不会中途断

从客户端日志里找到实际请求的地址，用 curl 主动拉一段时间：

curl -N -v --max-time 60 <日志中的请求地址>

如果前几秒正常、随后连接被对端或中间设备重置，基本可以判定是代理掐长连接，换节点或换协议即可。

3. 检查环境变量是否互相打架

env | grep -iE 'proxy|no_proxy'

留意有没有残留的旧代理地址，以及 NO_PROXY 是否把目标域名误加进了白名单。命令行工具普遍会读 HTTP_PROXY / HTTPS_PROXY，具体支持范围以官方文档为准。

4. 逐层剥离代理

先临时关掉 TUN 或全局模式，改成只让 Codex 走代理（进程级分流），其他流量直连。如果这样能稳住，说明是全局接管引起的冲突，而不是代理本身不可用。这一步往往比换节点更有用。

5. WSL 场景单独处理

在 WSL 里确认能否访问宿主机的代理端口，把地址换成宿主机的实际 IP：

ip route show default | awk '{print $3}'
# 用上一步得到的地址替换，端口以实际配置为准
export HTTPS_PROXY="http://<宿主机IP>:<端口>"

较新的 Windows 版本支持镜像网络模式，可以让 WSL 直接复用宿主机的网络栈，配置成本更低。如果改完仍然不通，最省事的做法是直接把项目放在 Windows 原生目录下运行，绕开这层间接访问。

6. 校准时间并清理旧配置

timedatectl status        # Linux / WSL
w32tm /resync             # Windows

时间偏差明显就先同步，再重启客户端。顺手检查配置文件里有没有历史遗留的代理或自定义端点。

几种代理路线的取舍

如果只是偶尔掉一次，重连能自己恢复，不必折腾。如果每次都是跑几分钟就断，优先怀疑节点对长连接的处理能力，其次才是 TUN 冲突。

几个容易踩的坑

• 不要为了「精准分流」去装来路不明的专用代理工具。 这类工具通常需要接管系统代理甚至安装网络驱动，权限很高，来源和二进制不可验证就等于把整台机器的流量交出去。真有分流需求，用主流代理客户端自带的进程规则功能就够了。
• 不要用共享或代登录的账号绕过限制。 违反服务条款，账号随时可能被停用，排查成本远高于自己配好网络。
• 不要无脑循环重试。 如果是服务端容量问题，高频重试只会让排队更糟，等一会儿或换一个模型更实际。
• 改完配置要彻底重启客户端，有些进程只在启动时读一次代理设置。
• 留意运营商或公司网络侧的干扰，换一个网络环境（比如手机热点）对比一下，能快速判断是本地还是链路问题。

需要长期在线运行时

如果 Codex 只是偶尔用来问答，上面这些排查做完基本够用。但如果要让它长时间挂着跑重构、批量任务，本地环境的不确定性就会被放大：家宽抖动、代理节点被回收、笔记本合盖休眠、WSL 网络重置，任何一项都会让长任务中断。

这种情况下，除了把本地网络和代理调稳，另一个可选的思路是把运行环境搬到网络条件更可控的地方——例如整台 Mac mini 放在新加坡机房、按月租用、远程连接使用的方案，本地只负责写代码，长任务在远端持续跑，掉线重连的干扰会小很多。这不是必需项，本地网络本来就稳定的话完全没有必要。

小结

Reconnecting 这类报错的关键，是先确认「断在哪一层」：网页能开只证明短请求通，长连接能不能撑住要单独验证。排查顺序建议固定为——基础连通性、长连接存活、环境变量冲突、代理模式与 WSL 网络、系统时间，最后才是换节点。区分清楚「本地连不上」和「模型容量满」，能省掉一大半无效折腾。涉及具体客户端版本、代理配置项和网络模式的细节，以官方最新说明为准。