codex 配置 梯子后仍连不上：CLI、桌面版与 Remote SSH 排查

更新于 2026-10-26 · peizhibang.com

简答：codex 配置 梯子时，先确认 Codex 实际运行端，再用带 User-Agent 的 GET 验证代理，随后检查 HTTPS/WSS 是否经过代理；

定义：这里的“codex 配置 梯子”是指为 Codex CLI、桌面版或远程开发环境配置 HTTP、HTTPS 或 SOCKS5 代理，并验证实际请求是否经过预期网络路径。

先试这一步：确认运行端、代理端口和实际请求路径

如果浏览器可以打开页面，但 Codex 仍提示登录超时、连接失败或反复重连，先不要立即改配置文件。第一步是确认 Codex 运行在哪里：本机终端、桌面版进程、WSL、容器，还是 VS Code Remote SSH 远程主机。代理必须配置在真正发起请求的进程或机器上。

在 macOS 或 Linux 中，先设置变量，再执行 GET 请求。这样可以避免同一行内设置变量后又读取旧值的问题：

export HTTP_PROXY="http://127.0.0.1:端口号"

export HTTPS_PROXY="http://127.0.0.1:端口号"

curl --proxy "$HTTP_PROXY" --user-agent "codex-proxy-check/1.0" --get --write-out "%{http_code}\n" --output /dev/null https://chatgpt.com/

这条命令使用 GET，只能证明指定代理可以完成一次 HTTPS 请求，不能单独证明 Codex 的 WebSocket 已经连通。若返回状态码且代理面板能看到对应连接，说明基础 HTTP 路径可用。

在 PowerShell 中执行以下命令，明确提取 StatusCode：

$proxy = "http://127.0.0.1:端口号"

$result = Invoke-WebRequest -Uri "https://chatgpt.com/" -Method Get -Proxy $proxy -UserAgent "codex-proxy-check/1.0"

$result.StatusCode

如果只想检查本机端口是否监听，可执行 Test-NetConnection 127.0.0.1 -Port 端口号。这个结果只代表端口可连接，不代表远程请求、TLS 或 WebSocket 成功。

三种方案怎么选：进程代理、系统代理与 TUN

Codex 的代理排查应按“范围最小优先”的顺序进行。先用进程级环境变量做对照，再测试 Codex 的系统代理开关，最后才把 TUN 作为透明路由变量。官方源码显示，Codex 的出站代理逻辑会区分 HTTP、HTTPS 和 Secure WebSocket，并可读取对应环境变量；Codex 出站代理实现还说明了系统代理、环境代理和直连之间的解析顺序。

当前官方配置说明将基础配置、进阶配置和完整参考分开维护，入口见Codex 配置文档。本文不把未经官方文档确认的 http_proxy 配置字段或第三方 API 中转地址写成通用方案；环境变量和系统代理的适用范围，也不能推断为所有桌面组件完全一致。

Codex CLI：用进程级代理完成最小验证

Codex CLI 在当前终端启动时，可以先使用进程级环境变量验证网络路径。HTTP 代理示例为：

export HTTP_PROXY="http://127.0.0.1:端口号"

export HTTPS_PROXY="http://127.0.0.1:端口号"

export ALL_PROXY="http://127.0.0.1:端口号"

codex

如果使用 SOCKS5，应确认当前客户端和请求库支持该协议，再将 ALL_PROXY 改为 socks5h://127.0.0.1:端口号。不要把 HTTP 端口和 SOCKS5 端口混用，也不要把控制端口当作代理端口。

Codex 官方出站代理实现对 Secure WebSocket 的环境变量读取顺序与 HTTPS 不完全相同：Secure WebSocket 会优先尝试 HTTPS_PROXY，再尝试 HTTP_PROXY 或 ALL_PROXY。因此只设置其中一个变量可能导致普通 HTTPS 和长连接表现不同，具体字段可在官方出站代理源码中核对。

CLI 的最小验证顺序是：先执行带 User-Agent 的 GET，再启动 Codex，最后查看代理面板是否出现同一时间段的目标连接。若 GET 成功但 Codex 没有对应记录，优先检查 Codex 是否在另一个 shell、容器或远程环境中运行。

桌面版：系统代理有效，不代表每条 WebSocket 都已接管

桌面版通常包含多个进程或组件，浏览器界面、应用服务和长连接不一定采用完全相同的网络路径。官方配置源码显示，respect_system_proxy 是单数形式的功能键，用于让 Codex-owned clients 尊重主机系统代理设置；Codex 配置实现同时把该设置映射到出站代理策略。

如果要测试该开关，先备份用户配置文件，再确认已有 [features] 表中没有重复定义：

[features]

respect_system_proxy = true

修改后完全退出桌面版并重新打开。不要只关闭窗口，也不要直接用网上模板覆盖整个 config.toml。如果当前版本不识别该字段，日志中可能出现配置被忽略、连接仍为 DIRECT 或 WebSocket 超时等现象；这时应撤销改动，改用进程级环境变量或 TUN 做对照。

官方仓库中的公开问题报告记录过桌面版长连接与其他组件采用不同代理路径的案例，但它们属于特定版本、系统和网络环境下的报告，不能当作所有桌面版的固定行为。遇到 1006、open_timeout 或反复 reconnecting，应同时查看 Codex 日志和代理连接面板，而不是只看浏览器是否正常。

WebSocket 怎么排查：不要用普通网页成功代替长连接验证

目前最稳妥的可复现方法不是用普通网页结果推断 WebSocket，而是让 Codex 发起真实连接，并同时观察客户端日志与代理面板。官方出站代理源码明确把 ws、wss 映射到对应的 HTTP、HTTPS 代理解析路径，因此排查重点是目标连接是否进入了预期代理，而不是只看页面能否打开。

1. 先记录时间：记下启动 Codex、出现错误和重试的大致时间，不要把 Cookie、令牌或完整认证链接复制到日志。
2. 再看 Codex 日志：查找 1006、open_timeout、connection reset、proxy_407、tls_error 或 invalid_proxy_config 等关键词。
3. 再看代理面板：确认对应 HTTPS/WSS 连接不是 DIRECT，并记录实际使用的策略组；若完全没有记录，说明请求未到达该代理。
4. 最后做环境变量对照：只设置 HTTP_PROXY、HTTPS_PROXY 和必要的 ALL_PROXY，完全重启 Codex，再比较错误是否变化。

未经认证的 curl GET 不能完成 Codex WebSocket 的等价验证；如果需要更低层的测试，应使用当前客户端或开发环境支持的 WebSocket 工具，并避免把账号认证信息放入命令行、脚本或截图。

WSL 与 VS Code Remote SSH：代理要配置在远程运行端

如果 Codex 在 WSL、容器或 VS Code Remote SSH 远程主机中运行，本机桌面代理和本机终端变量不会自动成为远程进程的代理。先在 VS Code 远程终端执行以下检查：

which codex

env | grep -i proxy

curl --user-agent "codex-proxy-check/1.0" --get --write-out "%{http_code}\n" --output /dev/null https://chatgpt.com/

如果远程环境没有代理变量，先确认远程主机是否能访问代理监听地址。远程主机上的 127.0.0.1 指向远程主机自己，不是本地电脑。需要复用本地代理时，应使用受控的 SSH 端口转发或在远程主机配置可访问的代理出口，并限制监听地址和访问范围。

VS Code Remote SSH 中，扩展宿主也可能运行在远程主机。只在本地终端设置变量，通常不能改变远程扩展宿主的网络路径。正确顺序是：确认远程运行端、在远程端做 GET、观察远程代理日志，再启动 Codex 或扩展。

认证目录、令牌、Cookie 和完整回调链接不要通过公开网盘、聊天群或未加密脚本传递。本文只讨论网络路径和连接排查，不提供绕过账号验证、修改认证流程或规避平台限制的方法。

配置文件、API 地址与“免梯中转”：先分清代理和服务端点

很多搜索结果会把“设置代理”和“修改 API 地址”混在一起。两者不是同一件事：代理改变的是网络连接路径，API 地址改变的是请求目标服务。把一个 URL 写进 OPENAI_BASE_URL 或配置文件，并不会自动让桌面版 WebSocket、CLI 或远程扩展都使用该地址。

因此，无法核实来源的中转地址不应写入 Codex 配置，也不应把配置文件当作代理替代品。若目标只是让官方 Codex CLI 通过可控网络出口访问，优先使用进程级代理、系统代理或经确认的 TUN 路由；若目标是 API 开发，再单独按照官方 API 文档核对端点和认证方式。

最后核对：按日志位置和错误类型收敛问题

1. 代理无记录：检查 Codex 实际运行端、代理监听地址、端口协议和环境变量是否注入到正确进程。
2. GET 失败：先修复代理本身，不要继续修改 Codex 配置；确认 HTTP 代理端口不是控制端口。
3. GET 成功但 WebSocket 超时：检查 HTTPS_PROXY、ALL_PROXY、系统代理开关和代理面板中的 WSS 路由。
4. 出现 407：检查代理认证配置，不要把代理用户名、密码写入公开日志。
5. 出现 TLS 或证书错误：不要关闭证书校验；确认代理链路是否进行 TLS 检查，以及当前系统是否信任所需证书。
6. 本地登录回调失败：将 localhost、127.0.0.1 和 ::1 保留为本地直连例外，避免把回调请求送入远端代理。
7. TUN 后恢复：只说明透明路由捕获了此前未正确代理的连接，不代表必须长期启用 TUN；先记录规则命中情况，再决定是否保留。

CLI 的独立日志可通过官方文档说明的 RUST_LOG 和 log_dir 获取；相关说明见Codex 安装与日志文档。桌面版则应优先查看应用自身日志目录或诊断面板，并结合代理客户端连接记录判断请求是否真的经过代理。

完成排查后，至少应保留四项结果：Codex 运行端、代理协议和端口、GET 测试结果、WebSocket 日志与代理面板是否同时出现目标连接。这样才能区分“代理不可用”“Codex 没使用代理”和“普通 HTTPS 成功但长连接失败”。

常见问题

codex 配置 梯子后为什么浏览器能用，Codex 还是连不上？

浏览器可能使用系统代理，而 Codex 进程没有继承系统代理或环境变量。先确认 Codex 实际运行端，再设置 HTTP_PROXY、HTTPS_PROXY 做 GET 对照；若 GET 成功但仍重连，继续检查 WebSocket 是否在代理面板中显示为代理连接。

Codex CLI 应该设置 HTTP_PROXY 还是 ALL_PROXY？

HTTP 和 HTTPS 请求优先分别设置 HTTP_PROXY、HTTPS_PROXY；ALL_PROXY 可作为其他协议或回退路径。使用 SOCKS5 时必须确认客户端支持，再使用 socks5h:// 地址，不能把 HTTP 端口和 SOCKS5 端口混用。

开启 TUN 后 Codex 恢复，是否说明必须一直开 TUN？

不一定。TUN 只能说明透明路由捕获了此前未正确代理的连接。应先检查进程级变量、respect_system_proxy、WebSocket 规则和本地回调直连例外，再决定是否长期启用。

Codex WebSocket 出现 1006 或 open_timeout 怎么排查？

先看 Codex 日志，再看代理客户端连接面板，确认目标 HTTPS/WSS 连接不是 DIRECT；随后核对 HTTPS_PROXY、ALL_PROXY、系统代理和证书链。普通 GET 成功不能证明 WebSocket 一定成功。

VS Code Remote SSH 中 Codex 为什么不使用本地代理？

因为 Codex 或扩展宿主通常运行在远程主机，本地终端变量不会自动传递。应在远程终端确认 which codex、代理变量和 GET 结果，再配置远程代理或受控 SSH 转发。

修改 config.toml 或 OPENAI_BASE_URL 能替代代理吗？

不能直接等同。代理改变连接路径，API 地址改变请求目标；只有官方文档明确支持的 API 工作流才应配置自定义端点，未知中转地址、认证方式和数据处理情况未核实，不建议写入配置。

相关阅读

• 日志与错误排查
• Windows 客户端配置
• macOS 客户端配置
• DNS 与 TUN 配置
• 系统代理
• TUN 模式

参考资料

1. Codex 配置文档
2. Codex 出站代理实现
3. Codex 配置与系统代理开关实现
4. Codex 安装与日志文档
5. Codex 桌面版长连接代理问题报告