平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“Codex重新连接卡顿的原因与解决做法”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。
0x00 教程内容
在这个场景下，前段时间用 Codex（ChatGPT 桌面端内置的 Codex），每次发起对话前都要先刷一串重连提示，我一度以为是模型在思考，后来才发现是代理问题。根因很直接：Codex 默认直连、不走系统代理，在需代理才能上网的环境里，直连必然失败，于是反复重试后才回退到代理。
在这个场景下，本文的修法对 Codex CLI 与 ChatGPT 桌面端内置的 Codex 都适用，设置文件均为 ~/.codex/config.toml。
在这个场景下，修法只有一行设置。下面按“现象 → 修法 → 补全设置 → 细节 → 原理”的顺序讲清楚：
- 0x01 问题现象
- 0x02 解决方法
- 0x03 设置项不存在怎么办
- 0x04 几个容易忽略的细节
- 0x05 原理解释
0x01 问题现象
采用 Codex 时，每次发起对话，在出结果之前都会反复提示：
Reconnecting 1/5
Reconnecting 2/5
Reconnecting 3/5
Reconnecting 4/5
Reconnecting 5/5
短则等几十秒，长则要等上几分钟才出答案，很影响采用体验。
0x02 解决方法
以 Mac 为例，只需三步：
- 在这个场景下，打开 Finder（访达），按快捷键
Shift + Command + G，输入路径~/.codex/config.toml，打开该文件。 - 在
[features]设置段下添加一行：
[features]
respect_system_proxy = true
- 保存
config.toml，随后重启 ChatGPT（Codex）。
从实现思路看，再次对话，就不会再出现 Reconnecting 的提示，只会显示 Thinking，而且答案很快就出来了（几乎秒出）。
0x03 设置项不存在怎么办
上面的方法默认 config.toml 里已经有 [features] 段。如果没有，按下面两种情况处理。
情况一：config.toml 存在，但里面没有 [features] 段
直接把下面两行追加到文件末尾即可：
[features]
respect_system_proxy = true
注意：
[features]是 TOML 的段落标题，整个文件里只能出现一次。如果文件里已经有一行[features]，只需在它下面加respect_system_proxy = true，不要重复写段落头。
情况二：~/.codex 目录或 config.toml 文件根本不存在
先在终端里新建目录和文件，再用文本编辑器打开：
mkdir -p ~/.codex
touch ~/.codex/config.toml
open -e ~/.codex/config.toml
落到代码里，随后写入内容保存。一个完整的最小 config.toml 就只有这两行：
[features]
respect_system_proxy = true
0x04 几个容易忽略的细节
true 必须小写。 它是一个布尔值，等号两边不需加引号。
已有其它设置也不用动。 如果 config.toml 里已经有模型、登录等其它设置，保持原内容不动，把 [features] 段加在文件末尾即可，不影响其它段落。
Windows 路径相同。 Windows 用户路径是 C:Users<你的用户名>.codexconfig.toml，改法完全一致。
保存后必须重启。 实际处理时，改完重启 Codex 才会生效，重启后对话应直接显示 Thinking，不再出现 Reconnecting 提示。
0x05 原理解释
落到代码里，问题的根源在于代理上网。Codex 正常逻辑是直连 OpenAI 的服务（默认不走代理），但在需代理才能上网的环境里，直连必然失败。
于是每次请求都要经历：连接失败 → 等待超时 → 自动重试，反复 5 次之后才切换到代理方式连接成功。所以看到的 Reconnecting 1/5 到 5/5，同时不是大模型在“认真思考”，而是在反复尝试重建 WebSocket / HTTP 长连接。
新增的 respect_system_proxy = true 设置，意思是让 Codex 不要直连，直接读取系统的代理设置。该选项是 Codex 近期版本才加入的能力，默认关闭；旧版本可能没有此设置项，建议先升级客户端再改。
修改前（直连模式）：
请求 → 连接失败 → 等待 → 重试 → 等待 → 重试 → 等待 → 重试 → 等待 → 重试 → 成功
修改后（代理模式）：
请求 → 代理 → OpenAI → 立即建立连接 → Thinking → 输出答案
核心就是省掉了所有网络重试的等待时间，所以响应速度明显提升。
0xFF 总结
结合项目来看，Codex 反复 Reconnecting 不是模型在思考，而是代理网络下直连失败后的重试。在 ~/.codex/config.toml 的 [features] 段加一行 respect_system_proxy = true，让 Codex 走系统代理，重连提示消失、响应几乎秒出。
一行设置，十秒搞定。
从实现思路看，总的来说，Codex适合结合实际项目边做边理解。先抓住核心思路，再逐步补上细节和边界处理，最后效果会更稳定，也更容易复用。