ARTICLE · 1092937
我差点把 Codex 卸载了,结果发现问题根本不在 Codex
我是懒猫。
前段时间，我差点把 Codex 卸载了。
不是因为它不好用，而是因为它突然开始一直卡在：
正在思考……
等了一会儿，没反应。
再等一会儿，还是没反应。
然后变成：
正在重新连接……
这时候，一个程序员的第一反应通常不是“让我冷静分析一下”，而是：
这玩意是不是又出问题了？
于是，一场原本只想花十分钟解决的问题，最后硬是让我折腾了半天。
而这一折腾，也让我重新认识了一件事：
很多看起来像软件出问题的问题，最后可能根本不是软件本身的问题。
01｜一开始，我以为只是 Codex 抽风
最近我一直在用 Codex 帮我处理一些代码。
正常情况下，把需求告诉它之后，它会开始分析，然后修改代码或者给出解决方案。
但那天不一样。
我输入内容之后，它就一直停在那里：
正在思考……
等了半天，没有结果。
接着：
正在重新连接……
然后又回到：
正在思考……
循环往复。
看到这里，我第一反应就是：
是不是 Codex 出问题了？
于是我开始尝试重新打开、重新连接，甚至考虑重新安装。
毕竟程序员排查问题的经典流程之一就是：
重启一下试试。
02｜重新折腾了一遍，问题还是存在
重新启动之后，问题没有明显改善。
这时候我开始意识到：如果只是 Codex 临时异常，重启之后应该至少会有一些变化。
于是，我开始换一个方向：
网络。
这个时候，我注意到了 Mac 上的代理设置。
03｜127.0.0.1:7890 到底是什么？
我的 Mac 当时配置了本地代理，其中一个地址是：
127.0.0.1:7890如果你平时不怎么接触代理，这串东西看起来可能有点懵。
其实可以简单理解成：
Codex → 本地代理 → 互联网 → 目标服务其中，127.0.0.1 代表的是：
你自己的电脑。
而 7890 是本地代理程序监听的端口。
所以，如果某个应用通过这个代理访问网络，它实际上可能会先把请求交给运行在自己电脑上的代理程序。
这时候问题就来了：如果代理配置、代理软件或者网络链路其中一环出现问题，应用层面看到的可能只是“连接失败”。
于是我开始检查 Mac 的代理设置。
配图说明：解释 Codex → 本地代理 → 互联网 → 目标服务的请求链路。
04｜我把 Mac 的代理设置翻了个底朝天
打开：
系统设置 → 网络 → Wi‑Fi → 详细信息 → 代理
可以看到 HTTP、HTTPS、SOCKS 等代理配置。
当时我的配置中出现了类似：
127.0.0.17890看到这里，我突然意识到：之前排查 Codex 的时候，我一直在盯着 Codex 本身，却忽略了它的网络请求可能还经过了另外一层。
这就有点像：
你发现外卖一直没送到，然后一直怀疑骑手。
结果最后发现：
小区大门根本没开。
05｜端口能通，不代表一切都正常
当然，看到 127.0.0.1:7890，不能直接认定代理就是罪魁祸首。
我先做了一个基础测试：
curl -I https://api.openai.com --proxy http://127.0.0.1:7890如果返回 HTTP/1.1 200 Connection established，只能说明本地代理端口至少能够建立连接。
但这并不等于：
Codex 一定使用了同一套代理配置；
代理一定能稳定访问所有目标服务；
TLS、DNS、认证和长连接都没有问题。
这也是排查网络问题时很容易踩的坑：
一个测试成功，只能证明这一条路径在这一刻成功过。
不能直接把它当成“整个系统都没问题”。
06｜最后，我把排查范围从“软件”扩大到了“链路”
后来我重新检查了代理软件是否正在运行、监听端口是否一致、系统代理是否和应用实际使用的代理一致，也分别尝试了关闭代理和切换网络。
排查到这里，我才真正把问题拆开来看：
应用有没有发出请求？↓请求有没有进入代理？↓代理能不能连接目标服务？↓连接是否能稳定保持？当你这样一层一层往下看，原本一句“Codex 怎么又不动了”，就变成了几个可以验证的小问题。
配图说明：展示“应用有没有发出请求、请求经过哪些环节、当前现象能证明什么”三个排查问题。
07｜写在最后
这次经历给我的最大提醒是：
不要太早给问题下结论。
看到“正在重新连接”，不一定是软件坏了；看到端口能通，也不代表整条链路都正常。
很多问题真正的答案，可能藏在你一开始根本没注意到的地方：代理、证书、DNS、权限，或者只是某个服务恰好没有启动。
所以，下次再遇到类似问题，我大概不会第一时间卸载软件了。
我会先问自己三个问题：
请求有没有发出去？
请求经过了哪些中间环节？
我现在看到的现象，究竟能证明什么？
毕竟，程序员的电脑里，最容易被误判的东西，往往不是代码。
而是那些“看起来一直都在正常工作”的配置。
我是懒猫，这里是 懒猫搞开发。
下次见。
本文记录的是一次排查思路，不代表所有“正在重新连接”都由代理导致。具体原因仍需结合日志、网络环境和应用配置判断。