首页/文章/AI Playground

Codex 使用 respect_system_proxy 跟随 Windows 系统代理

太阳作者太阳
原创内容采用 CC-4.0 协议发布，转载请注明出处
CodexWindows代理PowerShellClash Verge

Codex 使用 respect_system_proxy 跟随 Windows 系统代理

我在 Windows 上用 Clash Verge，系统代理已经配好，想让 Codex 也跟着走。需要在配置里加上这一行：

[features]
respect_system_proxy = true

保存并重新启动 Codex 后，我查了进程连接：两个 Codex 进程都连到了 127.0.0.1:7897，也就是本机 Mihomo 的代理端口。配置开关是开了，实际连接也接入了代理。

这次检查是在 2026 年 10 月 19 日。独立 CLI 为 0.163.0，桌面应用包为 26.1013.4894.0，包内 CLI 为 0.163.0-alpha.10.2。后面的命令和结果都来自这套环境。

配置放在哪里

本机的个人配置文件在：

C:\Users\<用户名>\.codex\config.toml

找到已有的 [features] 段，加入 respect_system_proxy = true；如果还没有这个段，再连同段名一起添加。注意放在 [features] 内，别写进后面的子表，也别重复创建同名段。

修改后完全退出 Codex，再重新打开。我这次通过重启加载配置，没有测试热切换。

CLI 还可以临时开启：

codex --enable respect_system_proxy

本机 codex --help 说明，--enable &lt;FEATURE&gt; 等价于 -c features.&lt;name&gt;=true，只用于这次启动。平时从桌面图标打开 Codex，直接改配置文件更方便。

代理地址在哪里填

respect_system_proxy 只接受 true 或 false，代理地址仍由 Windows 系统设置提供。本机由 Clash Verge 写入的地址是：

127.0.0.1:7897

用 PowerShell 查看：

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

本机输出为 ProxyEnable = 1、ProxyServer = 127.0.0.1:7897，AutoConfigURL 为空。这里用的是固定地址，没有测试 PAC、代理认证或其他操作系统。

如果想关掉系统代理，只给 Codex 单独填一个 IP 和端口，这个开关办不到。它依赖系统代理设置；其他遵循系统代理的软件也可能受这份设置影响。

先看功能状态，再看实际连接

在 PowerShell 中查看代理相关功能：

codex features list | Select-String 'proxy'

这次独立 CLI 输出为：

network_proxy          experimental       false
respect_system_proxy   under development  true
system_proxy_fallback  stable             true

这里的 under development 表示功能仍在开发中。true 只能说明这次 CLI 读到了开启状态，桌面端是否已加载，还得看它自己的进程。

我分别检查了桌面应用内置的 CLI 和终端里的 CLI，代理相关状态一致。两者的版本却不一样，所以排查时最好先看清终端调用的是谁：

Get-Command codex | Select-Object Source
codex --version

再查 Codex 的已建立连接：

$codexProcessIds = @(Get-Process -Name codex -ErrorAction SilentlyContinue |
  Select-Object -ExpandProperty Id)

Get-NetTCPConnection -State Established -ErrorAction SilentlyContinue |
  Where-Object { $_.OwningProcess -in $codexProcessIds } |
  Select-Object OwningProcess, LocalAddress, LocalPort, RemoteAddress, RemotePort

当时两个 Codex 进程共有九条已建立连接，远端都是 127.0.0.1:7897。这个端口由 Mihomo 监听，说明这些连接确实接入了本地代理。

至于每条连接访问什么域名、命中什么规则、最终走哪个节点，要到代理软件里继续查。这次也没有做开关前后的对照，不能排除其他代理机制的作用。

网络延迟怎样测

连接路径确认后，我用 curl.exe 指定同一个代理地址，向 Codex 服务发了三次不带登录信息的 GET 请求：

1..3 | ForEach-Object {
  curl.exe --silent --show-error --output NUL `
    --proxy http://127.0.0.1:7897 `
    --connect-timeout 8 --max-time 15 `
    --write-out 'code=%{http_code} tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n' `
    https://chatgpt.com/backend-api/codex/responses
}

三次首字节耗时约为 637 ms、481 ms 和 582 ms，平均 567 ms。都收到了 HTTP 405 响应，说明请求能到达服务端；登录和真实模型调用没有在这一步测试。

再加上 --noproxy '*'，让 curl 不使用显式 HTTP 代理，三次都在约五秒后连接超时。这个参数不会绕过 TUN 等透明转发，测量时仍要留意机器的网络环境。

这次代理链路的响应在半秒左右，但模型生成速度还受服务端处理影响，不能拿它换算 token/s。curl 在这里手动指定了代理，也没有经过 respect_system_proxy 的读取流程；判断 Codex 是否接入代理，仍要看进程连接。

与 network_proxy、HTTP_PROXY 的区别

另一个名字相近的实验功能是 network_proxy。OpenAI 的配置参考说明，它为沙箱命令启动网络代理，支持按域名限制联网；这套限制不覆盖网页搜索、Apps、MCP 等托管工具。

其中，proxy_url 和 allow_upstream_proxy 的定义也容易看错：features.network_proxy.proxy_url 是 Codex 自己的 HTTP 监听地址，默认 http://127.0.0.1:3128；allow_upstream_proxy 才涉及转接环境变量指定的上游代理。不能把监听地址直接改成 Clash 的 127.0.0.1:7897，当成上游代理使用。

HTTP_PROXY、HTTPS_PROXY 可以给读取这些环境变量的进程指定代理。不过，在 PowerShell 里用 $env:HTTPS_PROXY = "…" 设置变量，只影响当前终端及其子进程。从开始菜单打开的桌面应用未必能读到它。

我这次只保留了系统代理和 respect_system_proxy = true，network_proxy 仍为 false，也没有修改系统级或用户级代理环境变量。

连接异常时回退

如果升级后出现连接异常，可以先关闭开关，重启 Codex，再查连接和报错：

[features]
respect_system_proxy = false

关闭后还要重新查连接。本机的 system_proxy_fallback 仍是开启的，环境变量和其他代理机制也可能继续起作用，不能看到 false 就认为已经直连。

图片生成、网页搜索、MCP、浏览器工具和子进程的流量，这次没有逐项检查。本文能确认的是：在这套 Windows 环境里，开启配置后查到的 Codex TCP 连接都接入了本地 Mihomo。