平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“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 为例，只需三步：

1. 在这个场景下，打开 Finder（访达），按快捷键 Shift + Command + G，输入路径 ~/.codex/config.toml，打开该文件。
2. 在 [features] 设置段下添加一行：

[features]
respect_system_proxy = true

3. 保存 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适合结合实际项目边做边理解。先抓住核心思路，再逐步补上细节和边界处理，最后效果会更稳定，也更容易复用。