Codex 加速的核心不是把测速软件的数字调到最高，而是让 Codex 实际使用一条稳定、低抖动、可切换的网络路径。最短的可行方案是：在代理客户端中确认本地 HTTP 或 SOCKS 监听端口，给 Codex CLI 设置正确的 HTTP_PROXY、HTTPS_PROXY，再用 curl 和 Codex 的状态信息验证；桌面端或 IDE 若没有继承终端变量，则需要重启应用并检查其环境配置。
本文把“机场”作为订阅型代理服务的俗称，只讨论合法授权的网络连接和系统代理配置，不提供节点链接、账号共享或绕过组织网络策略的方案。服务商线路、OpenAI 产品政策和当地法律都可能变化，购买前请自行核对条款与隐私说明。
Codex 加速先分清三层代理
很多“代理已打开但 Codex 仍超时”的问题，是把下面三层混在了一起：
| 层级 | 作用 | 常见开关或配置 |
|---|---|---|
| 代理客户端 | 连接订阅节点，提供本地监听端口 | Clash、mihomo 或其他合规客户端的 HTTP/SOCKS 端口 |
| 操作系统代理 | 让浏览器和读取系统代理的软件自动使用客户端 | Windows 手动代理、macOS 网络代理开关 |
| Codex 进程代理 | 让 CLI、桌面端或 IDE 把请求发到本地代理 | HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 或应用配置 |
打开第一层不代表第三层已经生效。浏览器能访问，也不代表从 Finder、开始菜单或 IDE 启动的 Codex 能读取同一组环境变量。配置时要分别验证“端口在监听”“系统代理已开启”“Codex 进程确实拿到变量”。
机场推荐：2026 年优先筛选什么线路
这篇文章不列固定品牌榜单。机场的入口、出口和负载会调整，今天的排名不能替代你自己的测试。更适合 Codex 的服务，应同时满足下面这些条件。
有备用入口，而不是只有一个节点
至少准备两个不同入口或地区，最好能在同一地区切换不同线路。单节点套餐一旦遇到维护、拥塞或出口封锁，Codex 的长连接就会一起中断。服务商应公开流量、倍率、并发数、限速、退款和故障公告规则。
看长连接和抖动，不只看下载峰值
Codex 会持续接收模型输出，短时间下载速度高并不能证明长连接稳定。试用时在白天和晚高峰各做几轮测试，记录连接建立时间、连续输出是否中断、重连次数和代理日志中的错误。若一个节点延迟略高但长连接不掉线，实际体验可能优于峰值速度更高的节点。
线路标签必须能被日志验证
“IEPL”“BGP”“专线”“低延迟”都是服务商的线路描述，不是 Codex 客户端给出的认证结果。挑选时看服务商是否说明入口、出口、协议和故障切换方式，再用实际日志比较不同线路。不要因为一个标签就支付长期套餐。
隐私和账号安全优先于所谓免费
不要把 OpenAI API Key、ChatGPT Cookie、SSH 私钥或企业代码交给代理服务。来源不明的客户端、根证书和远程控制脚本也不应安装到工作电脑。需要代理的只是网络请求，服务商不应要求你交出 Codex 登录凭据。
第一步：在代理客户端确认本地端口
打开你的代理客户端，找到本地监听设置，记录 HTTP、混合端口或 SOCKS5 端口。例如：
HTTP / Mixed: 127.0.0.1:7890
SOCKS5: 127.0.0.1:7891端口只是示例，必须以客户端当前页面显示的值为准。先用下面命令确认端口确实能转发请求：
curl -I --connect-timeout 10 --proxy http://127.0.0.1:7890 https://api.openai.com返回 401、403 或 404 不一定表示网络失败，说明 HTTP 请求可能已经抵达服务端。需要重点排查的是连接超时、DNS 失败、TLS 握手失败、502 和 504。如果代理端口拒绝连接，先修客户端或节点，不要修改 Codex 配置。
第二步：配置 Windows 系统代理与 Codex CLI
方案 A：设置当前 PowerShell 会话
只想测试本次 Codex，可以在同一个 PowerShell 窗口执行：
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5://127.0.0.1:7891"
codex关闭这个窗口后变量就会消失，适合确认问题是否来自代理继承。
方案 B：写入用户环境变量
确认端口长期不变后，可以在“系统设置 > 系统 > 关于 > 高级系统设置 > 环境变量”中新增用户变量。变量名使用大写 HTTP_PROXY、HTTPS_PROXY，值填写本地代理地址。修改后要彻底退出并重新打开 Codex、终端和 IDE，旧进程不会自动刷新环境变量。
方案 C：开启系统手动代理
Windows 的“设置 > 网络和 Internet > 代理”中打开手动代理，填写 127.0.0.1 和客户端 HTTP 端口。系统代理适合浏览器和多数桌面软件，但并不能保证 Codex CLI 或所有开发工具都读取它，所以仍应使用命令行测试。
第三步：配置 macOS、Linux 与桌面端
macOS/Linux 终端
在 zsh、bash 或其他 shell 中使用：
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7891"
codex如果只需要让一次命令走代理，也可以写成：
HTTP_PROXY="http://127.0.0.1:7890" \
HTTPS_PROXY="http://127.0.0.1:7890" \
codexmacOS 系统设置
在“系统设置 > 网络 > 当前网络 > 详细信息 > 代理”中，根据客户端提供的端口勾选 HTTP、HTTPS 或 SOCKS 代理。系统代理只影响愿意读取 macOS 代理设置的软件；遇到 CLI 不生效时，优先回到终端变量和 curl --proxy 测试。
Codex App 和 VS Code 扩展
OpenAI 的 Codex 配置文档提醒：桌面应用和 IDE 扩展可能不会继承 shell 环境变量；修改环境配置后需要重启应用。对于版本支持的环境，可以在用户目录的 ~/.codex/.env 保存环境变量，例如：
HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890这不是所有版本都保证支持的全局代理入口。保存后完全退出 Codex App 或 VS Code，再新建会话验证；如果仍不生效，就从已设置变量的终端启动 CLI，或按企业 IT 的统一代理方案处理。
HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY 怎么选
优先使用 HTTP 代理监听器
许多本地客户端的 HTTP 代理监听器本身没有 TLS，因此变量值通常写成 http://127.0.0.1:端口。HTTPS_PROXY 表示“HTTPS 请求通过哪个代理发送”，不代表代理地址一定要写成 https://。如果监听器是普通 HTTP，却写成 https://127.0.0.1:7890，常见结果是代理 URL scheme 错误或反复断开。
SOCKS5 只在客户端和工具都支持时使用
ALL_PROXY=socks5://127.0.0.1:7891 可以作为备用，但不同工具对 SOCKS5、DNS 解析和 UDP 的支持不同。排错时先用 HTTP 代理跑通 Codex，再尝试 SOCKS5；一次不要同时更改端口、协议和节点。
设置 NO_PROXY 避免本地地址绕路
如果本地开发服务、内网域名或公司地址不应经过代理，可以按需设置：
export NO_PROXY="127.0.0.1,localhost,.local"不要把 OpenAI 域名加入 NO_PROXY，否则请求会绕过代理。企业网络的域名例外应由管理员提供，避免凭经验大范围填写。
第四步：验证 Codex 是否真的完成加速
用三条命令建立基线
codex --version
curl -I --connect-timeout 10 https://api.openai.com
curl -I --connect-timeout 10 --proxy http://127.0.0.1:7890 https://api.openai.com前两条用于比较直连和代理路径，第三条用于确认指定端口可用。不要只看浏览器页面；把响应时间、状态码和发生时间记录下来，换线路时使用相同测试条件。
在 Codex 中查看状态
使用 CLI 时打开 /status，观察当前模型提供方、登录状态和版本信息。官方文档也建议在修改配置或环境变量后重启桌面端和 IDE，再开启新会话。若 /status 正常但请求仍断开，继续看代理日志中的长连接和重连记录。
先规则模式，后全局或 TUN
如果代理客户端支持规则模式，先用规则模式验证 OpenAI 相关域名是否进入预期节点。全局模式和 TUN 会改变更多系统流量，适合确认路径后再启用。出现所有网站都变慢、DNS 混乱或退出客户端后没网，先关闭 TUN 和系统代理，恢复基础网络。
常见错误与对应处理
| 错误表现 | 可能原因 | 处理顺序 |
|---|---|---|
Connection timed out |
端口未监听、节点拥塞、DNS 或出口不可达 | 先测本地端口，再换备用线路 |
Proxy URL scheme not supported |
把普通 HTTP 监听器写成了 https:// |
改为客户端实际提供的协议 |
| 浏览器正常，CLI 超时 | CLI 没继承系统代理 | 用终端 export 后启动 Codex |
| CLI 正常，桌面端超时 | App/IDE 没有读取 shell 变量 | 重启应用，检查 ~/.codex/.env 是否被当前版本读取 |
| 请求中途断开 | 长连接抖动、WebSocket 或服务端波动 | 查状态页、代理日志和晚高峰表现 |
| 开启 TUN 后全网异常 | 路由、DNS 或权限冲突 | 关闭 TUN，恢复普通系统代理 |
排错时一次只改一个变量。换机场、换协议、开 TUN、改 DNS 同时发生，就无法判断真正的原因。
安全和合规检查
- 代理订阅只从你能核验身份、条款和退款规则的服务获取。
- 不安装陌生服务商要求的根证书、远程控制软件或修改系统安全策略的脚本。
- 不把 API Key、ChatGPT Cookie、SSH 私钥和企业代码放入订阅备注、截图或工单。
- 企业和学校网络先询问管理员，个人代理不能替代组织的访问控制。
- 使用前确认当地法律、公司政策、学校网络规则以及 OpenAI 账户条款。
常见问题
Codex 加速一定要买机场吗？
不一定。如果你的公司、学校或家庭网络已经提供合法可用的 HTTP/SOCKS 代理，直接配置本地端口即可。购买订阅服务只是其中一种网络出口方案，不能保证 Codex 永久可用。
系统代理开了，为什么 Codex 还是没有加速？
系统代理只影响读取系统设置的软件。CLI 可能需要 HTTP_PROXY 和 HTTPS_PROXY，桌面端或 IDE 还可能需要重启后才能读取用户环境配置。先用 curl --proxy 验证端口，再测试 Codex。
HTTPS_PROXY 必须写成 https:// 吗？
不必须。它通常指向本地 HTTP 代理监听器，例如 http://127.0.0.1:7890。只有当你的代理监听器明确提供 TLS 代理服务时，才使用 https://。
Codex CLI 和 Codex App 能共用一套代理吗？
可以尝试共用同一个本地端口，但两者的启动方式和环境继承可能不同。CLI 从终端启动通常更容易确认变量；App 需要重启并检查它是否读取用户环境配置。
机场节点应该选择 IEPL、BGP 还是直连？
不要只按名称选择。对 Codex 更重要的是长连接成功率、抖动、丢包、备用入口和故障公告。用相同设备、相同时间段和相同命令测试，比线路标签更有参考价值。
总结
2026 年给 Codex 做加速，建议按“客户端端口 → 系统代理 → Codex 进程变量 → 长连接验证”的顺序配置。机场推荐应建立在短周期实测、备用线路、隐私条款和协议兼容性上，而不是固定榜单。先用 HTTP 代理跑通 CLI，再处理桌面端继承、SOCKS5、TUN 和规则分流；每次只改一个变量，连接问题才容易定位。