浏览器能够正常联网，Codex 却持续重连；终端里设置了代理，桌面端仍然没有响应。浏览器与 Codex 不一定使用同一请求进程和代理配置，因此浏览器联网正常不能证明 Codex 的模型请求可达。重连也可能由认证、限流或服务故障引起，不能仅凭提示判定为代理问题。

下面分别说明桌面端、CLI、VS Code 与远程环境的配置方法，并给出代理是否生效的检查步骤。

## 1. Codex 代理地址怎么填？分清两种入口

为 Codex 配置代理，需要获取代理地址、端口，以及服务支持的协议。代理入口可以是本机运行的代理工具，也可以是远程代理服务器。

### 使用本机代理工具

在工具设置中查看 HTTP 或 mixed（混合）监听端口，并确认服务正在运行。代理工具与 Codex 请求进程运行在同一系统时，地址通常写为：

```text
http://127.0.0.1:实际端口
```

`7890`、`7897` 等端口只是常见示例，配置时以工具实际显示的值为准。

### 使用远程代理服务器

在资源管理页面获取代理 IP、端口及认证信息。下图展示这些参数的位置，实际地址和认证信息已隐藏。

![远程代理参数查看位置](https://developer.qcloudimg.com/http-save/yehe-12868122/f346be27083be2c03425f12a59f18555.png)

远程 HTTP 代理的地址格式为：

```text
http://代理服务器地址:实际端口
```

需要用户名和密码认证时，支持该认证方式的客户端可使用：

```text
http://用户名:密码@代理服务器地址:实际端口
```

用户名、密码作为 URL 的 userinfo 字段时需要分别进行 URL 百分号编码，例如 `@` 编码为 `%40`、`#` 编码为 `%23`；不要对整条 URL 编码。使用 IP 白名单认证时，按服务要求添加当前连接代理的出口 IP。真实认证信息不要放进截图或文章。

**页面显示的 IP 和端口不足以判断代理协议。**使用下文的 HTTP 代理配置前，需要确认该资源支持 HTTP CONNECT；纯 SOCKS5 端口不能直接套用 `http://`。认证支持还取决于客户端版本和代理要求的认证方式，不能仅凭地址格式判断兼容性。

### 地址正确，还需要验证连接

访问 HTTPS 目标时，HTTP 代理地址仍可使用 `http://` 开头：客户端通过 CONNECT 建立隧道，目标 HTTPS 连接在隧道内进行 TLS 握手。注意，`http://` 表示客户端到代理这一跳本身没有代理层 TLS；代理认证信息不受目标站点 TLS 保护。

代理是否适用于 Codex，需要通过后文的端口检查、HTTPS 转发测试和 Codex 实际请求确认。资源页面显示“使用中”，不代表 Codex 已经连接成功。

另外，`127.0.0.1` 指向运行请求进程的系统自身。Codex 的请求进程位于 WSL、SSH 远程服务器或容器中时，应使用该环境实际可达的代理地址。

## 2. 使用系统代理配置

使用支持该字段的客户端版本。当前官方文档提供实验性配置 `features.respect_system_proxy`，默认关闭。Windows、macOS 上可让原生 Codex 运行时为自身请求读取系统代理/PAC。

在用户级 `config.toml` 的现有 `[features]` 区域中添加或修改：

```toml
[features]
respect_system_proxy = true
```

已有 `[features]` 时合并字段，不要创建重复表头。用户级默认位置：

| 系统 | 默认文件 |
| --- | --- |
| Windows | `%USERPROFILE%\.codex\config.toml` |
| macOS / Linux | `~/.codex/config.toml` |

设置了 `CODEX_HOME` 时，以对应配置目录为准。这个开关不能通过项目目录中的 `.codex/config.toml` 启用。单位统一管理设备也可能由系统配置或 `managed_config.toml` 提供默认值。

这条路线要求操作系统已经配置好可用的代理。远程代理资源不会因打开 Codex 开关而自动写入系统设置；需要显式填写远程地址时，可查看第三、四节。确认系统代理指向可用服务，保存后完全退出并重新打开客户端。

这个开关只覆盖运行时自身支持的请求客户端，不等于浏览器、插件、MCP、终端命令的全部流量都会采用相同代理。Linux 不具备文档描述的 Windows/macOS 原生代理发现路径，显式环境变量更便于控制。

`features.system_proxy_fallback` 默认开启，但官方描述的回退范围是受支持的登录、云配置请求，不能把它解释成所有模型 WebSocket 请求的通用修复。

在当前 Windows 客户端中，可通过「设置 → 配置 → 用户配置 → 打开 config.toml」进入配置文件。下图展示配置入口：

![image.png](https://developer.qcloudimg.com/http-save/yehe-12868122/7cf8c9e2678540f5ceb5c660097deefc.png)

客户端版本信息如下。本机界面显示为 ChatGPT，标注 Powered by Codex & OWL：

![当前客户端版本信息](https://developer.qcloudimg.com/http-save/yehe-12868122/d8666fd8e0175e560694a66a7f28bc80.jpg)

## 3. 配置 `.env`，检查桌面端是否加载

`.env` 是可尝试的环境变量文件方案，但当前官方环境变量文档没有承诺所有桌面端版本都会自动加载它。只有客户端启动流程支持加载该文件时，其中的代理变量才会进入请求进程；文件存在不等于配置已经生效。系统代理的正式配置步骤见上一节，CLI 的显式环境变量步骤见下一节。

该方案尝试在 Codex 用户配置目录放置 `.env`：默认配置目录对应 Windows 的 `%USERPROFILE%\.codex\.env`，macOS/Linux 的 `~/.codex/.env`。这只是候选加载位置，不代表当前桌面端已承诺读取该文件。使用自定义配置目录时，核对当前客户端实际使用的目录，不能只凭另一个终端的环境推断。

完全退出 Codex，用编辑器打开已有 `.env`；不存在时创建文件。保留其他条目，更新代理键，不要把整个文件覆盖成示例内容，实际联网效果仍取决于客户端版本和代理环境。

```dotenv
HTTP_PROXY="http://<代理地址>:<实际HTTP端口>"
HTTPS_PROXY="http://<代理地址>:<实际HTTP端口>"
NO_PROXY="localhost,127.0.0.1,::1"
```

已有 `NO_PROXY` 时，保留原值并按需要追加上述回环地址，不要直接覆盖。需要账号密码的 HTTP 代理，在客户端支持该认证方式时，可将两个代理变量的值都写为 `http://用户名:密码@代理地址:端口`；用户名和密码中的特殊字符需要分别进行 URL 百分号编码，并确认客户端支持服务要求的认证方式。不要对整条 URL 编码，也不要把真实认证信息放入截图、文章或命令历史。

尖括号及其中的文字均为占位符，代理地址替换为实际主机名或 IP，端口替换为 1–65535 的数字。本机代理工具通常填写 `127.0.0.1`；远程代理填写实际服务器地址。文件名应为 `.env`，而不是 `.env.txt`；该文件使用环境变量格式，不加 `[proxy]`、`export` 或 TOML 表头。

无需为了凑齐变量强行添加 `ALL_PROXY`。已有 `ALL_PROXY`、大小写代理变量或旧端口时，检查是否冲突；保留本机原有的内网代理例外规则。Linux/macOS 的变量名区分大小写，需要检查大小写两套值是否指向不同入口。

需要比较显式环境变量与系统代理时，可以在启用该开关的同一配置来源中，将 `respect_system_proxy` 改为 `false`。受管理的配置可能不允许本地覆盖；这个操作也不会关闭前文所述的 `system_proxy_fallback`。

保存文件后完全退出客户端，确认没有旧后台实例继续承接请求，然后重新打开。仅关闭窗口或新建对话，不足以证明进程已重新读取环境。如果请求仍未走预期代理，不要反复改写同一个 `.env`；改用第二节系统代理配置，或使用能够向实际请求进程传递环境变量的启动方式。

## 4. 给 CLI 设置当前进程代理

下面的命令要求已安装 Codex CLI，且 `codex --version` 能正常返回版本。它们适用于 HTTP 或支持 HTTP CONNECT 的 mixed 入口。本机代理填写 `127.0.0.1`，远程代理填写服务器地址。需要账号密码的代理应按上一节处理认证，下面交互示例不要求输入密码。

PowerShell：

```powershell
$codexProxyHost = (Read-Host '输入代理主机名或 IP，不含 http:// 和端口').Trim()
$codexProxyPort = [int](Read-Host '输入 HTTP/mixed 端口')
if ([string]::IsNullOrWhiteSpace($codexProxyHost)) { throw '代理地址不能为空' }
if ($codexProxyPort -lt 1 -or $codexProxyPort -gt 65535) { throw '端口范围应为 1–65535' }
$codexProxyHostForUrl = $codexProxyHost
if ($codexProxyHost.Contains(':') -and -not $codexProxyHost.StartsWith('[')) {
    $codexProxyHostForUrl = "[$codexProxyHost]"
}
$codexProxyUrl = "http://${codexProxyHostForUrl}:$codexProxyPort"
$codexTcpTest = Test-NetConnection -ComputerName $codexProxyHost -Port $codexProxyPort
if (-not $codexTcpTest.TcpTestSucceeded) { throw '代理 TCP 端口不可达，请检查地址、端口和网络' }
$env:HTTP_PROXY = $codexProxyUrl
$env:HTTPS_PROXY = $codexProxyUrl
if ([string]::IsNullOrWhiteSpace($env:NO_PROXY)) {
    $env:NO_PROXY = 'localhost,127.0.0.1,::1'
} else {
    $env:NO_PROXY += ',localhost,127.0.0.1,::1'
}
codex
```

`TcpTestSucceeded: True` 只说明代理端口能建立 TCP 连接，不证明代理协议正确、上游可达或模型调用成功。IPv6 地址在 URL 中需要方括号，在上面的主机输入提示中填写不带方括号的地址。

macOS/Linux 的 Bash：

```bash
printf '输入完整 HTTP 代理地址（http://地址:端口，不含账号密码）：'
read -r codex_proxy_url
codex_proxy_pattern='^http://(\[[0-9A-Fa-f:]+\]|[^/:@[:space:]]+):([0-9]{1,5})$'
if [[ "$codex_proxy_url" =~ $codex_proxy_pattern ]] && (( 10#${BASH_REMATCH[2]} >= 1 && 10#${BASH_REMATCH[2]} <= 65535 )); then
  export HTTP_PROXY="$codex_proxy_url"
  export HTTPS_PROXY="$codex_proxy_url"
  export NO_PROXY="${NO_PROXY:+$NO_PROXY,}localhost,127.0.0.1,::1"
  codex
else
  printf '地址格式错误，请填写实际 HTTP 代理地址。\n' >&2
fi
```

以上 CLI 示例配置不带账号密码的 HTTP 入口。远程资源需要认证时，应使用客户端支持的认证方式；返回 HTTP 407 时检查认证信息与兼容性，不要把它当作模型登录失败。

这些命令影响当前终端环境及随后从中启动的子进程，不会自动传给已经运行的桌面端或 IDE。关闭该终端会结束该 shell 的临时环境；已经启动的子进程仍保留启动时继承的环境，磁盘上的 `.env`、系统代理及已有后台运行时不会因此自动恢复或重载。

如果当前 CLI 将请求交给已有后台运行时处理，新的终端变量未必会传入该后台进程。使用 `codex --help` 检查当前版本支持的前台运行或运行时重启方式，并在正确的启动环境中重启；不要结束不明进程，也不要照搬其他版本的后台管理命令。

## 5. 处理 VS Code、WSL 与远程开发

VS Code 集成终端中的 `export` 只影响该终端及其子进程，不会反向更新已经运行的扩展宿主。

本地扩展可以在完全退出 VS Code 后，使用已设置 HTTP_PROXY/HTTPS_PROXY 的终端运行 `code .`。关闭其他 Code 实例，避免命令复用旧进程。该步骤解决的是进程环境继承，实际效果仍需在扩展中发送请求验证。

Remote SSH、WSL 与容器需要确认 Codex 后端运行在哪一侧。配置放在后端实际使用的主目录或配置目录，并保证那个环境能够连接代理。Windows 上安装的 CLI 版本与扩展附带的 CLI 版本也可能不同，不能用一个版本的测试替代另一个。

远程服务器需要借用本机 HTTP 代理时，可以通过受控的 SSH 反向转发提供回环入口，例如：

在本机的独立终端中建立隧道。下面以本机 HTTP 代理监听 `127.0.0.1:7890`、远端使用 `17890` 为示例；执行前将两个端口和 `user@server` 替换为实际值。端口 `17890` 必须在远端可用。

```bash
ssh -N -o ExitOnForwardFailure=yes -R 127.0.0.1:17890:127.0.0.1:7890 user@server
```

保持该终端运行。在另一个 SSH 会话中，使用第四节的 CLI 配置步骤，代理地址填写 `127.0.0.1`，端口填写隧道的远端端口（示例为 `17890`）。不要在运行中的 `ssh -N` 进程里继续粘贴环境变量命令。

服务器须允许相应转发，隧道运行期间端口才有效。`ExitOnForwardFailure=yes` 用于发现初始转发建立失败，不能保证后续上游始终可达。服务器策略还须允许将转发端口限制在回环地址；核对远端实际监听位置，不把代理开放到公网。本机代理需要认证时，隧道不会替你完成或取消代理认证。

WSL 的 NAT、镜像网络及自动代理设置会改变主机可达方式。连接 Windows 代理时，用当前网络模式下可达的地址验证，不把 `/etc/resolv.conf` 的 DNS 地址固定当作宿主代理地址。

更新 Codex 扩展后重新检查代理配置。避免直接修改扩展附带的二进制文件或注入 NODE_OPTIONS，这类改动容易在扩展更新后失效。

## 6. 代理可达仍报错，按错误处理

| 现象或错误 | 操作方向 |
| --- | --- |
| Connection refused / OS 10061 | 检查服务是否启动、端口是否正确、回环地址是否属于同一个环境 |
| Timeout / OS 10060 | 核对代理连接日志、目标分流、上游连通性和防火墙策略 |
| Could not resolve host / DNS resolution failed | 区分无法解析代理主机与无法解析目标域名；检查对应环境的 DNS 和代理解析行为 |
| HTTP 407 | 检查用户名、密码、URL 编码及支持的认证方式；HTTP 407 是代理认证，不是 OpenAI 登录失败 |
| certificate verify failed / unknown issuer | 配置可信 CA，检查代理或网关的 TLS 检查证书链 |
| SOCKS 错误、协议握手失败 | 核对纯 SOCKS 与 HTTP/mixed 端口，升级到包含相关修复的受支持版本 |
| WebSocket 握手失败、持续重连 | 检查 HTTP CONNECT/WSS 长连接是否被代理或网关中断；使用显式 HTTP 代理路线验证 |
| Codex 能回复，但 pip、git 或脚本联网失败 | 单独检查命令环境与沙箱网络策略；模型通道和命令通道分别验证 |
| 仅登录失败或出现 401/403/429 | 结合认证、账户权限、配额、服务状态及实际响应来源检查，不据状态码直接认定代理故障 |

企业网关使用私有 CA 时，官方支持：

```powershell
$env:CODEX_CA_CERTIFICATE = 'C:\certs\company-ca.pem'
codex
```

```bash
export CODEX_CA_CERTIFICATE='/path/to/company-ca.pem'
codex
```

使用出口 IP 白名单认证的代理，还需要确认当前请求出口已加入白名单；网络切换后出口地址可能变化。不要把购买页面显示“使用中”当作当前机器已通过认证。

CA 文件必须来自可信管理员或网络环境。官方说明该变量用于 HTTPS、登录及 WebSocket；同时设置时，Codex 使用 `CODEX_CA_CERTIFICATE`，未设置它时才回退到 `SSL_CERT_FILE`。桌面端还需要在其实际启动环境中获得变量。不要使用 `NODE_TLS_REJECT_UNAUTHORIZED=0` 或关闭 TLS 校验处理此问题。

TUN 可以覆盖未读取显式代理的流量，但效果受路由、DNS、规则和排除项影响，不承诺开启即修好；它也不用于证明 `.env` 已生效。TUN 是否涵盖桌面端与 WSL 等环境，应分别验证。使用显式代理能够完成请求时，无需额外启用 TUN。

配置参考中的 `model_providers.<id>.supports_websockets=false` 属于传输选择，不是代理地址配置。`wire_api="responses"` 不会单独关闭 WebSocket。网络代理设置无需改动模型服务的 base_url 或认证方式。

## 7. 验证代理确实生效

分三层检查：

1. 代理入口：本机或远程代理的 TCP 端口可达。
2. 代理转发：使用真实 HTTP 入口测试 HTTPS，并在代理日志确认有相应请求。
3. Codex 请求：重启后发起一轮文本请求及一轮本地工具调用，结合对应时间的连接日志检查完成状态、是否反复重连。

下面使用独立的 `curl.exe`，不使用 PowerShell 的 `curl` 别名。执行 `curl.exe --version` 确认已安装且可用；命令不存在时，需要安装可信来源的 curl 或在已有 curl 的环境中测试。

在第四节设置了 `$codexProxyUrl` 的同一个 PowerShell 窗口中执行以下探测。需要认证时，仅测试不带凭据的地址可能返回 407；这不等于服务没有启动。

```powershell
curl.exe --proxy $codexProxyUrl --noproxy "localhost,127.0.0.1,::1" --connect-timeout 10 --max-time 20 -I -v https://auth.openai.com/
```

`-v` 用于查看 CONNECT 与 TLS 的过程；分享输出前隐藏认证头和其他敏感信息。`--noproxy` 在这次探测中将绕过列表限定为回环地址，避免目标域名被已有绕过规则直接放行。

401、403 或其他 HTTP 返回不能单独证明配置成功；CONNECT 成功且 TLS 完成也不等于已经验证带认证的模型 WebSocket。代理日志需关联目标、时间与进程，系统中其他程序的同域连接不能代替 Codex 证据。

选择无需外网、无需读取敏感信息的工具任务进行测试。模型能完成本地文件读取，说明该次本地工具调用链可工作，但不能证明 pip、git、浏览器或 MCP 的外网请求已走代理。这些工具的联网能力需要分别测试。

需要更多 CLI 日志时，交互式 CLI 支持显式日志目录：

```powershell
$env:RUST_LOG = 'debug'
codex -c 'log_dir="./.codex-log"'
```

```bash
RUST_LOG=debug codex -c 'log_dir="./.codex-log"'
```

上述日志命令需要在第四节设置过代理的同一个终端中运行，并在交互式 CLI 完全退出后启动。`codex exec` 的日志输出方式不同，不套用 TUI 日志文件的说明。调试完成后恢复原来的 `RUST_LOG` 值；原来未设置时，PowerShell 使用 `Remove-Item Env:RUST_LOG -ErrorAction SilentlyContinue`，Bash 使用 `unset RUST_LOG`。截图只保留错误类型、时间及必要网络信息，隐藏令牌、请求正文和个人路径。


## 8. 让 Codex 辅助检查配置的提示词

可以把下面的提示词交给仍能正常响应的 Codex：

> 请检查这台电脑上 Codex 的代理配置。确认当前使用的是桌面端、CLI 还是 IDE 后端，记录版本、实际配置目录和现有代理来源。仅检查代理相关条目，不读取或输出认证令牌、订阅地址或其他凭据。使用本机工具时检查 HTTP/mixed 监听地址和端口；使用远程资源时确认服务端地址、协议及认证方式，不猜测端口。给出系统代理与显式 HTTP 代理两条路线的差异，选择与本机匹配的一条。需要修改配置时备份相关文件、保留无关条目和已有内网例外，避免重复键与重复 TOML 表头；不要修改 provider 地址、降低证书校验或扩大沙箱权限。完成端口和 HTTPS 转发检查，说明桌面端或后台运行时的重启步骤。区分“配置已写入”“代理可达”“Codex 请求已成功”三个结果，尚未验证的部分明确列出。

Codex 已经完全无法连接时，这段提示本身不能自动执行，需要手动按前述步骤配置，或由仍可联网的受信任工具协助。

## 总结

Codex 代理配置的关键，在于让实际发起请求的进程读到正确地址，并验证请求经过了预期链路。系统代理、环境变量和远程运行环境各有作用范围；端口能连接、网页能打开与模型能持续完成请求，也对应不同验证结果。把配置位置、代理协议和客户端重启这几项对齐，排查就有明确落点。


浏览器能够正常联网，Codex 却持续重连；终端里设置了代理，桌面端仍然没有响应。浏览器与 Codex 不一定使用同一请求进程和代理配置，因此浏览器联网正常不能证明 Codex 的模型请求可达。重连也可能由认证、限流或服务故障引起，不能仅凭提示判定为代理问题。

Codex 代理怎么设置？桌面端、CLI 配置与生效验证一次讲清

Codex 代理怎么设置？详解桌面端系统代理与 .env 配置、CLI 环境变量，以及 VS Code、WSL 和远程开发的配置差异，附端口检查、证书处理、常见报错排查与代理生效验证步骤。

人工智能

Codex连接失败并非浏览器正常即代表配置有效，需区分桌面端、CLI与远程环境，确认代理协议（HTTP CONNECT），配置正确的HTTP_PROXY/HTTPS_PROXY，检查认证、端口可达性及服务状态，并验证模型请求实际通过预期链路。

日志文件

代码解释

服务器

WebSocket

防火墙

Windows

ChatGPT

路由

容器

Linux

MacOS

热销域名限时优惠，新客首年免费！


domain

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Codex 代理怎么设置？桌面端、CLI 配置与生效验证一次讲清-腾讯云开发者社区-腾讯云

Codex 代理怎么设置？桌面端、CLI 配置与生效验证一次讲清

Codex 代理怎么设置？桌面端、CLI 配置与生效验证一次讲清

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐