夜雨聆风
点击蓝字 关注我们
1
你是不是也遇到过这种情况：
明明浏览器能正常打开网页，代理软件也开着，结果一启动 Codex，界面里却反复提示：
reconnecting 1/5reconnecting 2/5reconnecting 3/5……
直到 5/5
很多人的第一反应都是：
“完了，是不是 Codex 坏了？”
“是不是账号有问题？”
“是不是又要重装一遍？”
但真相往往没那么复杂。
它不是坏了。很多时候，它只是没走你本机的代理。
这类问题，看起来像软件故障，本质上却常常只是一个很小的网络配置细节。偏偏就是这个细节，最容易卡住新手。
今天这篇，我们就把这件事彻底讲明白。
2
先说结论：浏览器能上网，不代表 Codex 能联网
这句话特别重要。
很多人会默认认为：
“我浏览器都能打开网页了，说明网络肯定没问题，那 Codex 连不上一定是它自己的锅。”
其实不是。
因为浏览器和 Codex，很多时候压根不是走同一条网络路径。
浏览器可能用了这些东西：
系统代理
浏览器插件代理
PAC 规则
TUN 模式
但 Codex 是一个从终端里启动的命令行程序。
它能不能联网，往往取决于：
启动它的那个终端进程，有没有拿到正确的代理环境变量。
也就是说：
你电脑“有代理”，不等于 Codex“正在用代理”。
3
为什么它会一直显示“5次重连”？
当 Codex 连续出现 reconnecting 1/5 到 5/5，通常说明一件事：
它正在尝试连接服务，但连接一直失败。
而这类失败，在很多本地环境里，最常见的原因之一就是：
Codex 启动时，没有带上代理。
所以这类报错最容易误导人的地方就在这里：
表面看像是软件抽风，
实际上更像是“终端没有把代理传给它”。
这就是为什么有些人浏览器一切正常，Codex 却死活连不上。
不是网络彻底断了。
而是 Codex 这个进程没有走到该走的出口。
4
真正有效的修法，不是重装，而是先做一次“临时代理验证”
很多人一遇到这种问题，就开始：
重装软件
改全局代理
切换各种代理模式
到处翻配置文件
怀疑账号、怀疑节点、怀疑人生
但更稳的办法，其实只有一个：
先在当前终端里，临时把代理设上，再启动 Codex。
为什么推荐“临时验证”？
因为它有三个好处：
改动最小
验证最快
成功后能立刻锁定原因
假设你的本地代理地址是：
http://127.0.0.1:10808那就这样试。
Windows PowerShell
$env:HTTP_PROXY="http://127.0.0.1:10808"$env:HTTPS_PROXY="http://127.0.0.1:10808"codex
Windows CMD
set HTTP_PROXY=http://127.0.0.1:10808set HTTPS_PROXY=http://127.0.0.1:10808codex
macOS / Linux
export HTTP_PROXY=http://127.0.0.1:10808export HTTPS_PROXY=http://127.0.0.1:10808codex
如果这样一启动，Codex 不再重连，基本就说明问题已经找到了：
不是 Codex 坏了，而是之前启动它的终端，没有带代理。
5
为什么不建议一上来就改全局？
因为很多人不是修问题，而是在“制造更多变量”。
一旦你直接去改全局代理、改系统设置、改规则、改脚本，后面出了问题，你反而很难判断到底是哪一步造成的。
正确姿势应该是：
先用临时命令验证假设，再决定要不要长期固化。
这个思路非常适合新手，因为它不会把系统搞乱，也不会让排障越弄越复杂。
说白了就是一句话：
先证明这条路能走通，再考虑把它铺平。
6
最容易踩的坑，不是不会配，而是“配了但没生效”
这里有个特别常见的误区：
你以为自己已经设置好了代理，实际上 Codex 根本没拿到。
比如这些场景都很常见：
你在 A 终端里设了代理，却在 B 终端里启动了 Codex
你开了浏览器代理，但命令行程序并不会自动继承
你代理软件是规则模式，终端流量没有被接管
你抄了别人的端口，但你的本地端口根本不是
10808
你该填的是 http://，却写成了别的协议
所以排查这类问题时，关注点别放在：
“我有没有开代理？”
而要放在：
“启动 Codex 的这个进程，到底有没有真的走代理？”
7
如果你用的是 Clash、v2rayN、sing-box，还要注意一件事
很多本地代理工具开着，并不代表所有程序都会自动联网。
尤其是命令行工具，经常会出现一种情况：
浏览器正常，CLI 工具异常。
如果你使用的是带 TUN 模式的代理工具，那么在某些配置下，开启 TUN 后，终端程序也可能恢复正常。
这也是为什么有人会说：
“我开全局就好了。”
“我开 TUN 就不重连了。”
这并不奇怪。
但从排障角度来说，最推荐普通用户先做的，还是那一步：
在当前终端里临时设置代理变量，直接验证。
因为它最直观，也最不容易误判。
8
如果设了代理还是不行，下一步别猜，直接看信息
如果你已经设置了 HTTP_PROXY 和 HTTPS_PROXY，Codex 还是连不上，那就别继续盲猜了。
先把这些信息整理出来：
你用的操作系统
你用的终端类型
你的代理软件名称
你的代理地址和端口
当前是否开了规则 / 全局 / TUN
你设置了哪些环境变量
运行 Codex 后看到的完整报错
你还可以先自查一下，代理变量是否真的在当前终端里生效。
PowerShell
echo $env:HTTP_PROXYecho $env:HTTPS_PROXY
macOS / Linux
echo $HTTP_PROXYecho $HTTPS_PROXY
如果输出为空，那答案就很明确了：
Codex 启动时，确实没有拿到代理。
9
这类问题最该记住的一句话
很多人卡在这里，不是因为不会配置，而是因为少了一个关键认知：
电脑能上网，不等于 Codex 这个进程能上网。
这句话，几乎能解释一大半“浏览器正常、工具异常”的问题。
所以以后再看到 reconnecting 1/5 到 5/5，先别急着重装，也先别急着判死刑。
优先检查代理。
尤其是检查：
代理有没有传到启动 Codex 的那个终端里。
10
给新手的最短操作版
如果你只想要一个最省事的方法，直接照下面做。
PowerShell 用户
$env:HTTP_PROXY="http://127.0.0.1:10808"$env:HTTPS_PROXY="http://127.0.0.1:10808"codex
macOS / Linux 用户
export HTTP_PROXY=http://127.0.0.1:10808export HTTPS_PROXY=http://127.0.0.1:10808codex
能正常连上，就说明方向对了。
后面你再决定要不要把它写进脚本、终端配置，或者做成一键启动方案。
11
最后总结
Codex 反复 5 次重连，很多时候不是软件坏了，而是：
启动它的那个进程，没有走本机代理。
最稳的处理顺序是：
确认本地代理软件正在运行
确认代理地址和端口正确
在当前终端临时设置
HTTP_PROXY / HTTPS_PROXY
再启动 codex 验证
验证成功后，再考虑长期配置
如果这篇内容帮你少踩了一个坑，欢迎顺手点个赞和喜欢吧~
求点赞
求分享
求喜欢
