先判断:重连不一定都是代理问题
不少用户遇到过这个场面:Codex 界面卡在“正在重新连接 3/5 + 正在思考”,反复重连,迟迟没有输出。
这类问题可能由网络不可达、本地代理未生效、DNS、客户端状态或服务端异常引起。如果当前网络必须通过 Clash、v2ray 等本地代理访问 OpenAI,可以优先检查 Codex 进程是否继承了正确的代理设置。
思路:把重复的端口探测固化成 Skill
配置代理环境变量并不复杂,麻烦的是不同代理客户端和不同配置使用的端口不一样。Clash/Mihomo 可能使用 mixed-port,v2ray/Xray、sing-box 则可能分别提供 HTTP 和 SOCKS 入站;用户也可能修改过默认端口。因此,不能把 7890、1080 或 10808 当成已经探测到的结果。
可以利用 Codex 的 Skill 机制,把“检查本地代理、确认协议和端口、安全更新环境变量”固化成一套流程。以后只要说一句“配置一下本地代理”,Codex 就会按规则检查,而不是直接猜端口。
这个 Skill 会做四件事:
- 检查现有的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXY 环境变量;
- 识别正在运行的本地代理客户端,例如 Clash/Mihomo、v2ray/Xray、sing-box、NekoRay、Shadowsocks;
- 结合活动配置和本地监听端口确认代理协议:优先使用真正的 mixed-port,否则分别记录 HTTP 和 SOCKS 端口;
- 在写入工作区 .codex/.env 前展示变更;如果证据不足,就询问用户,不写入猜测值。
需要注意:如果当前 Codex 已经完全卡死、无法执行本地操作,Skill 不能在同一个卡死任务中“自救”。此时应先恢复或重启 Codex,必要时手动提供代理端口,再调用 Skill 完成配置。
安装步骤
第一步,创建 Skill 目录:
第二步,在目录中创建 SKILL.md,写入以下内容:
第三步,重启 Codex,让它重新发现 Skill。
使用
在目标项目目录中启动 Codex,然后输入:
如果探测到的是确认可用的 mixed-port,结果可能类似:
如果 HTTP 和 SOCKS 使用不同端口,则必须分别填写:
其中:
HTTP_PROXY / HTTPS_PROXY 让 HTTP 和 HTTPS 请求通过本地 HTTP 代理;
ALL_PROXY 使用 SOCKS 代理兜底。socks5h:// 中的 h 表示由代理端完成域名解析;
NO_PROXY 让本机回环地址绕过代理,避免访问本地服务时被错误转发。
验证与排错
HTTP 代理可以这样验证:
SOCKS 代理可以这样验证:
如果请求收到了远端 HTTP 响应,例如 401、403 或其他状态码,通常说明代理链路已经到达目标服务器,但不代表 API 鉴权或业务请求已经成功。连接超时、连接被拒绝或 DNS 失败,则说明链路仍有问题。
如果 Codex 重启后仍然无法联网,按这个顺序排查:
- 先确认是不是代理问题:检查其他网络请求和 OpenAI 服务状态,不要把所有重连都归因于本地代理;
- 检查代理客户端是否运行:客户端没有启动时,对应端口自然不会监听;
- 检查协议和端口:
mixed-port 可以同时用于 HTTP 和 SOCKS,协议单一的端口不能混用;
- 检查配置是否真的被加载:写入
.codex/.env 不等于当前 Codex 版本一定读取它,应检查进程实际继承的环境变量或该版本支持的配置入口;
- 检查写入范围:Skill 应只更新四个代理变量,保留其他变量、注释、换行和文件权限;
- 检查重启时机:已经运行的进程通常不会自动获得后来写入的环境变量,需要重新启动。
小结
这个 Skill 的价值不是替用户猜一个常见端口,而是把“识别客户端、确认协议、核对端口、预览写入、验证链路”变成可重复执行的流程。
它能解决的是本地代理配置问题,不是所有 Codex 重连问题。把边界说清楚,自动化才真正可靠。