远程服务器跑 Codex 总超时？教你一招排查代理配置的坑

在平时折腾服务器部署 AI 应用的过程中，你是否遇到过这种诡异的情况：

博主 Lid 的头像

• 本地跑 Codex 好好的，丝滑流畅。
• SSH 连上远程服务器，配置了代理，终端里 curl -I www.google.com 一切正常。
• 结果一启动 codex-app，死活起不来，或者直接提问就提示 request time out。

明明网络没问题，为什么应用就是“连不上网”？今天就来聊聊这个经典的环境配置坑，帮你排查原因并解决问题。

网络检测示例图片

问题初现：网络通了，应用却挂了

首先，我们得还原一下故障现场。博主 Lid 遇到的问题非常有代表性。

在服务器上，为了访问 OpenAI 或 Codex 的服务，大家通常会设置环境变量来指明代理路径，比如：

export HTTPS_PROXY=http://127.0.0.1:7897
export HTTP_PROXY=http://127.0.0.1:7897

设置完后，我们在终端测试：

curl -I www.google.com

如果返回 HTTP/1.1 200 OK，很多人第一反应就是：“网络通了，不是我防火墙的问题。”

然而，当你满怀信心地启动 codex-app，它却在初始化模块或者请求 API 时直接超时 crashing。这不禁让人抓狂：凭什么 curl 能跑，我的 Python/Node 应用就不能跑？

核心原因：127.0.0.1 的“假象”

问题的根源通常出在 127.0.0.1 这个 IP 地址上。

1. 代理软件的监听地址

大多数代理软件（如 Clash、V2Ray 等）默认为了安全，只监听 127.0.0.1（即 Localhost）。这意味着，只有从本机发起的请求才能被代理软件接收。

2. 应用运行环境的差异

当你在终端输入 curl 命令时，你当前的 Shell 会话确实属于“本机”环境，所以它能通过 127.0.0.1:7897 把流量扔给代理软件。

但是，codex-app（或任何后端服务）在某些运行环境下，可能会将其网络请求识别为来自不同的回路，或者 Docker 容器内部，甚至在某些复杂的子进程中解析 127.0.0.1 时出现了地址绑定的偏差。如果应用试图连接 127.0.0.1:7897 而代理软件严格限制只接受特定uid的连接，或者应用容器内并没有 7897 这个端口（ Docker 极常见的情况），连接自然就超时了。

解决方案：三招教你搞定

既然知道是代理监听的问题，解决办法就有很多种。我们从最简单的到最稳健的依次尝试。

方案一：修改代理监听地址为 0.0.0.0（最推荐）

想让服务器上所有的应用（包括 Docker 容器、子进程等）都能顺畅使用代理，最简单的方法是修改代理软件的配置。

• Clash/V2Ray 配置修改：找到配置文件中的 mixed-port 或 allow-lan 选项。
  • 将监听地址从 127.0.0.1 改为 0.0.0.0。
  • 或者开启 allow-lan: true。
• 重启代理软件。

注意安全：开启 0.0.0.0 意味着局域网内其他人也能连上你的代理端口。如果服务器是公网 IP，务必设置防火墙规则（如 iptables 或 ufw），只允许本机访问该端口，或者设置认证（用户名密码）。

修改完代理配置后，环境变量可以保持不变，或者显式指定为服务器内网 IP（如果需要）。

方案二：针对 Docker 容器的特殊处理

如果你是在 Docker 容器里跑 codex-app，那么容器里的 127.0.0.1 指的是容器自己，而不是宿主机。

这时候你需要使用 host.docker.internal（部分 Docker 版本支持）或者宿主机的实际局域网 IP（例如 172.17.0.1 或 192.168.x.x）。

环境变量应修改为：

export HTTP_PROXY=http://172.17.0.1:7897
export HTTPS_PROXY=http://172.17.0.1:7897

启动 Docker 容器时记得加上 --network host 模式也是一种偷懒但有效的解法，但这会牺牲容器网络的隔离性，酌情使用。

方案三：利用 ProxyChains-NG（通用大法）

如果应用本身不支持读取 HTTP_PROXY 环境变量，或者你想强制某些流量走代理，可以使用 proxychains。

1. 安装：apt install proxychains 或 yum install proxychains-ng。
2. 编辑配置文件 /etc/proxychains4.conf，在最后添加：

   [ProxyList]
   http 127.0.0.1 7897
   socks5 127.0.0.1 7890
   

3. 使用方式：

   proxychains codex-app start
   

这样就能强行把 codex-app 发出的 TCP 流量注入到代理通道里。

总结

遇到“终端能上网，应用就超时”的问题，不要慌。90% 的情况都是因为 127.0.0.1 的局限性或者 Docker 网络隔离导致的。

排查思路梳理：

1. 确认代理软件是否允许局域网连接（allow-lan 或 0.0.0.0）。
2. 确认应用是在宿主机跑还是在容器里跑？容器里必须用宿主机 IP。
3. 检查防火墙是否拦截了应用发出的出站请求。

希望这篇“避坑指南”能帮你救活那个红红的报错窗口，让 AI 工具在服务器上乖乖干活。如果你还有其他奇葩的网络报错，欢迎留言讨论！