我和 GPT 折腾半天的网络问题，被 Codex 半小时解决了
原本只是想让 AI 帮我写点代码，结果一个晚上都在帮 AI 修网络。更离谱的是，最后把问题修好的，还是 Codex 自己。
事情发生在 2026 年 10 月 14 日。
那天我遇到一个很烦人的问题：Codex 动不动就重连，偶尔干脆罢工。 明明 FlClash 开着，其他国外网站也能访问，偏偏 ChatGPT 和 Codex 不太听话。
我找 GPT 一起排查。我们从 VPN 线路聊到校园网，从代理规则折腾到 Windows 沙盒，甚至一度觉得问题已经摸到系统底层了。后来我让 Codex CLI 自己检查一下。她花了大约半小时，把真正影响主链路的地方找了出来，还写了一份事故复盘。
这篇不是标准答案式的教程。我想把怎么走弯路、怎么推翻猜测、最后又是怎么验证修复都记下来，给未来可能再踩坑的自己留个底。
先说明一点：严格说，Codex 背后也是 GPT 模型。这里说的「GPT」是网页里的聊天助手，Codex 是命令行里能自己动手的 agent——同一条血脉，两种用法。所以这次真正比的不是两个模型谁更强，而是「只动嘴」和「能动手」的差别。
01 / 一切从校园网开始
最开始，我怀疑 VPN 不稳定。
我的环境大概是这样：
| 项目 | 当时的情况 |
|---|---|
| 系统 | Windows 11 |
| 网络 | 校园网；手机热点用于对照测试 |
| 代理客户端 | FlClash，规则模式，监听 127.0.0.1:7890 |
| Codex CLI | 0.162.1 |
| Codex Desktop | 26.1007.9446.0 |
| FlClash TUN | 未开启 |
最奇怪的现象是：同一台电脑、同一个代理节点，连手机热点能用，连校园网就出问题。
更奇怪的是，校园网下开着代理，X 等网站都能打开。也就是说，既不是校园网彻底断网，也不能简单说“代理节点死了”。
我们先做了一个非常朴素的测试：把 FlClash 从规则模式切到全局模式。
结果，ChatGPT 网页立刻恢复了，Codex 的响应似乎也顺畅了不少。
这一刻我差点以为破案了。
02 / 第一次修好：原来网页分流没配全
接着我们把 FlClash 升级，并检查了规则覆写。
当时的表现很有代表性：在规则模式下，ChatGPT 页面可以打开，自己发出去的消息也看得见，但 GPT 的回复显示“无法加载此回复”；一切回全局模式，回复又正常了。
这提醒我们：一个网页能打开，不代表它依赖的所有请求都走通了。
于是，我们把 OpenAI 相关域名补进了 DOMAIN-SUFFIX 分流规则，让它们走选定的代理组，而不是错误地直连。排查时涉及的域名包括：
chatgpt.com
openai.com
oaistatic.com
oaiusercontent.com
oaistatsig.com
这一步之后，ChatGPT 网页在 FlClash 规则模式下也能正常显示回复了。
这里有个小坑：当时订阅本身带有名为“ChatGPT”的策略组，但新增规则实际指向的是“节点选择”。策略组叫什么，与某条规则实际把流量送到哪里，是两回事。 排障时要看生效的规则和实际出站，而不能只看组名。
网页修好了，我本来以为 Codex 也会一起恢复。
可惜，事情并没有这么简单。
03 / 越查越深：TLS、Schannel，还有一个 Bad access
Codex 的网络诊断依然可能报 TLS 握手或证书校验失败；WebSocket 也曾经超时，只能退回 HTTPS 连接。
为了弄清楚代理究竟有没有工作，我们从普通 PowerShell 测了这条命令：
curl.exe -I -v --max-time 20 --proxy http://127.0.0.1:7890 https://chatgpt.com/
有一次测试里，FlClash 正常接收了 CONNECT，TLS 也成功建立，最后返回 HTTP 403，并带有 Cf-Mitigated: challenge。
这个 403 不等于 TLS 失败。 它至少说明请求已经走过代理和 TLS，到了服务端的安全验证环节。对于命令行 curl，收到 Cloudflare 挑战并不奇怪。
但另外一些测试又出现了 Windows Schannel 错误：
SEC_E_NO_CREDENTIALS (0x8009030e)
随后我们在 Codex 沙盒里测试同一个本地代理地址，却得到：
connect to 127.0.0.1 port 7890 ... failed: Bad access
curl: (7) Failed to connect
于是，我们一度把注意力全放在 Windows 沙盒的网络限制上，还测试过另一个沙盒实现 MXC。它能正常启动，但那轮独立测试同样无法访问本机代理端口。
现在回头看，这些测试并没有白做，但我们犯了一个重要的判断错误：
沙盒里运行的
curl连不上127.0.0.1，不等于 Codex 主进程访问模型服务也必然失败。
这两条网络路径不能混为一谈。我们看见一个真实错误，却太快把它当成了整场事故的根因。
04 / 转折：让 Codex 自己查自己
折腾到这里，我干脆让 Codex CLI 自己检查网络。
结果，她没继续追着沙盒跑，而是先把直连、代理、TLS 实现、证书信任和进程环境变量拆开，一项项做对照。
她的初始诊断里有几行非常关键：
proxy env vars: none
respect system proxy: disabled
network.provider_reachability: fail
network.websocket_reachability: warning
invalid peer certificate: UnknownIssuer
这意味着：Windows 系统代理虽然已经指向 FlClash，Codex 的某些进程却未必会自动继承它；即使连上了代理，Codex 使用的 TLS 证书信任路径也可能不认当前证书链。
她又用 Python 的 OpenSSL 路径做对照测试。结果，经过相同的 FlClash 代理，访问 chatgpt.com 和 example.com 时，TLS 1.3 连接与证书校验均可成功。
这个对照很重要：它说明不能简单把锅甩给代理节点或校园网。至少在这些测试条件下，代理链路是可以正常建立 TLS 连接的；故障更集中在 Codex 的代理继承与 CA 信任方式。
说真的，看到这里，我和 GPT 之前围着 Bad access 抓耳挠腮的画面，突然就有点好笑了。
05 / 真正的修复：代理变量 + Windows CA 证书包
最后的修复并没有像我一开始担心的那样，关闭防火墙、禁用 TLS 校验，或把 Windows 沙盒直接拆掉。
她主要做了两件事。
第一件：让 Codex 明确知道代理在哪里。
为当前 Windows 用户持久化了这些代理环境变量：
HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890
ALL_PROXY=http://127.0.0.1:7890
NO_PROXY=localhost,127.0.0.1
第二件：让 Codex 使用一份可读取的 CA 信任包。
她从现有 Windows ROOT 和 CA 证书存储中导出证书，整理成 PEM 文件，再通过 CODEX_CA_CERTIFICATE 告诉 Codex 使用它。
CODEX_CA_CERTIFICATE=<本机 Windows CA PEM 文件路径>
需要特别说明：这里是导出本机已有证书供 Codex 使用，不是给 Windows 导入一张来历不明的新根证书，更不是关闭证书验证。
再次执行 codex doctor --json 后，结果发生了变化：
network.provider_reachability: ok
ChatGPT inference URL: reachable (HTTP 405)
desktop assets CDN: reachable (HTTP 200)
network.websocket_reachability: ok
handshake result: HTTP 101 Switching Protocols
其中 HTTP 405 是探测方法不被接口接受，但说明已到达服务端；HTTP 101 则表示 WebSocket 升级握手成功。
后来检查 Codex Desktop 的真实日志，还看到重启后 130 次模型请求返回 HTTP 200。这比“诊断绿了”更有说服力：确实有真实任务请求成功。
那一刻，才算真正摸到了问题的主体。
06 / 修好了还不算：我们又给她出了一份审查清单
既然她写了事故复盘，我和 GPT 又把报告过了一遍，还整理了一份“最终复核意见”给她。
这次复核不再追求所有指标都变绿，而是追问：
- WebSocket 握手成功，能否代表长任务不会中途断流？
- 当初沙盒内的
Bad access是否依旧存在，会不会影响 Python、npm、Git 等工具？ - Windows 完整重启后，代理变量和 CA 文件还能否生效？
- CA 包里到底信任了哪些证书？
- 用户级代理变量会不会误伤别的开发工具？
她还真的逐项检查了，而且没有硬把结果写成“全部完美”。
复核报告里有几处特别值得记住：
| 项目 | 最终复核的发现 |
|---|---|
| 核心模型通信 | Provider、HTTPS、WebSocket 握手与真实模型请求已恢复 |
| 本地数据库 | 外部只读完整性检查正常；先前有沙盒环境下的检查误报 |
| 沙盒代理访问 | 当前受限环境未再复现旧 Bad access，但不能据此保证所有沙盒命令都正常 |
| CA 包 | 共 82 个证书块、81 个不同指纹，其中 10 个已过期，包含一些本机软件相关证书 |
| Git | 默认 Schannel 仍有异常；指定 OpenSSL 与 CA 包后可以连通 |
| 全局代理变量 | FlClash 关闭后可能影响命令行工具；校园网内网地址也可能被误送去代理 |
这里我尤其佩服她的一点：承认问题还存在边界，比强行宣告完美更可靠。
比如 CA 包目前能用，但它并不是理想的最小信任集合；比如 Git 仍有自己的 Schannel 兼容问题；比如 WebSocket 握手成功，也不意味着可以证明“连续运行一小时零断流”。
最后，我又补做了 Windows 整机重启验证，也顺利通过。至于长时间任务的持续稳定性，我更愿意留给后续真实使用继续观察，而不是在文章里提前写成已完成的测试。
07 / 这次我真正记住的几件事
第一，别把“网站能打开”当成“所有请求都正常”。
ChatGPT 页面能加载，回复却加载不出来，就是最直观的例子。看实际连接与分流，比一句“VPN 没问题”靠谱得多。
第二，先区分路径，再谈根因。
普通 PowerShell、Codex 沙盒命令、Codex CLI 诊断和 Codex Desktop 主进程，不一定走同一套网络配置。某个环境里的 Bad access 很重要，但不能跨环境直接下结论。
第三，别用降低安全性来换一次表面的成功。
网络异常时，关闭 TLS 验证、禁用防护、直接移除沙盒限制，可能会让错误消失，却把真正的问题藏起来。这次修复保留了 TLS 校验和必要的沙盒边界。
第四，“修好”需要可验证的证据。
握手状态码、真实请求日志、重启后的持久性，甚至修复留下的副作用，都比一句“现在好像挺快的”更有价值。
第五，AI 也会在排障中走弯路。
GPT 陪我做了不少有效的对照，也曾在沙盒方向上过度投入；Codex 自己排查时，找到了更关键的代理与证书问题。两者并不是谁永远正确，而是不同的思路放在一起，最后有了更清楚的答案。
尾声
这次折腾，从“是不是该换个 VPN”开始，到最后留下了两份相当完整的技术报告。
回头看，我甚至有点庆幸一开始没直接重装系统，也没胡乱去改 Windows 的证书安全设置。我们绕过不少弯路，但每一步至少让问题的轮廓更清晰了一点。
现在，校园网 + FlClash 规则模式可以正常使用 ChatGPT；Codex 的主要通信链路恢复了，Windows 重启验证也已经通过。剩下的长时间稳定性和少数工具兼容问题，留作后续维护。
我终于可以把时间花回真正想做的事情上，而不是继续给开发工具修网络。
那天晚上，我本来只是想让 AI 帮我写代码。
结果最后，AI 帮我修好了让它自己无法工作的网络。
记录依据：2026-10-14 的实际排查过程，以及《Codex 网络事故复盘》《Codex 网络事故最终复核报告》。文中的证书与代理配置仅用于说明本次故障，不建议不加检查地直接照搬到其他电脑。