Cursor / Codex 网页能开，终端 npm、GitHub、OpenAI API 还是超时怎么办？

很多人排查 AI 工具网络时会卡在一句话上：“浏览器明明能打开 ChatGPT，为什么 Cursor 终端、Codex CLI、npm install、git clone、OpenAI API 还是超时？”答案通常不是账号，也不是模型，而是浏览器、终端、远程 VPS、Docker 容器并没有走同一个网络出口。

🧭 为什么网页能开，终端还是不通

浏览器能打开 ChatGPT，只能说明“浏览器这一层”大概率通了。终端里的 npm、git、curl、Docker、Codex CLI 可能使用完全不同的网络配置。

• 浏览器可能走了代理扩展或系统代理，但终端没有读取这些配置。
• Cursor / VS Code 的界面能联网，不代表项目终端走同一个出口。
• Remote SSH 里打开的终端是在 VPS 上执行，本地代理不会自动带过去。
• Docker 容器有自己的网络，宿主机通不代表容器通。
• OpenAI API 返回 HTTP 状态码和 TCP 超时是两类问题，排查方向完全不同。

🧪 先按症状判断问题层级

不要一上来就换机场、换 VPS、重装 Node。先按层级排查，通常 10 分钟内就能知道问题卡在哪一层。

📍 第一步：确认你在哪台机器执行命令

这是最容易被忽略的一步。Cursor 内置终端、VS Code Remote 终端、SSH 终端、WSL 终端、Docker 容器终端，执行位置可能完全不同。先确认命令到底跑在哪里。

  # 本地或远程终端都先执行
hostname
whoami
pwd

# Linux / macOS / VPS
uname -a

# Windows PowerShell
$PSVersionTable.PSVersion

如果你在 Remote SSH 里打开项目，`npm install` 实际发生在远程 VPS 上。本地 Clash、Mihomo、Surge、Hiddify 是否开启，对远程 VPS 的终端通常没有直接影响。

🌐 第二步：检查终端出口 IP 和 DNS

浏览器看到的 IP 和终端看到的 IP 不一致时，后面的排查都要以终端为准。先测出口，再测 DNS。

  # Linux / macOS / VPS
curl -4 ipinfo.io
curl -6 ipinfo.io
nslookup api.openai.com
nslookup github.com
nslookup registry.npmjs.org

# Windows PowerShell
curl ipinfo.io
Resolve-DnsName api.openai.com
Resolve-DnsName github.com
Resolve-DnsName registry.npmjs.org

• 如果终端出口还是本地运营商 IP，说明终端没有走代理或远程机没有配置出口。
• 如果 IPv4 通、IPv6 不通，后面要重点看 IPv6。
• 如果 DNS 解析很慢或返回异常，先换到可信 DNS 或让代理客户端接管 DNS。
• 如果远程 VPS 出口国家和你预期不同，先去 VPS 后台和 IP 检测工具确认机房与 ASN。

🔌 第三步：检查代理环境变量

多数 CLI 工具会读取环境变量里的代理配置，但不同工具支持程度不同。先看当前终端里到底有没有代理变量。

  # Linux / macOS / VPS / WSL
env | grep -i proxy

# Windows PowerShell
Get-ChildItem Env: | Where-Object { $_.Name -match 'proxy' }

# Windows WinHTTP 代理
netsh winhttp show proxy

如果你只是临时排查，可以给当前终端窗口设置代理。端口要换成你本机代理客户端实际监听的端口，常见是 `7890`、`7897`、`1080`，但不要照抄。

  # Linux / macOS 临时代理，仅当前终端生效
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:7890

# Windows 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:7890"

设置后重新执行 `curl ipinfo.io` 和 `curl -I https://api.openai.com/v1/models`。如果出口变了，说明问题就在终端代理层。

📦 第四步：单独排查 NPM 和 Git

npm 和 git 经常有自己的代理配置，哪怕终端环境变量正常，工具级配置也可能被旧代理、错误端口或公司代理污染。

  # NPM 连通性和配置
npm ping
npm view react version
npm config get registry
npm config get proxy
npm config get https-proxy

# GitHub HTTPS 连通性
git ls-remote https://github.com/openai/openai-node.git HEAD
git config --global --get http.proxy
git config --global --get https.proxy
git config --show-origin --get-regexp "http.*proxy|https.*proxy"

如果看到旧端口、旧代理地址、公司代理地址，先清理再测试。不要长期保留已经失效的全局代理配置。

  # 如果旧代理已经失效，先清掉
npm config delete proxy
npm config delete https-proxy
git config --global --unset http.proxy
git config --global --unset https.proxy

# 如确实需要给 npm / git 单独指定代理，再设置成当前有效端口
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

GitHub 还要区分 HTTPS 和 SSH：`git clone https://...` 和 `git@github.com:...` 走的协议不同。公司网络、校园网或部分 VPS 可能会限制 22 端口，必要时改用 HTTPS 或 GitHub 的 SSH over HTTPS 方案。

🤖 第五步：排查 OpenAI API / Codex CLI

OpenAI API 的排查要先分清“网络没到”和“API 层报错”。超时、DNS 错误、TLS 握手失败是网络问题；`401`、`403`、`429`、`500` 这类 HTTP 状态码说明请求已经到达服务端，下一步看认证、权限、额度、模型和请求代码。

  # 不带 API Key：能返回 HTTP 状态，说明 DNS / TLS / 网络至少走到 OpenAI API
curl -i https://api.openai.com/v1/models

# 带 API Key：只在自己的终端执行，不要截图、不要提交日志
curl -i https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY"

• `curl` 直接超时：优先查终端代理、DNS、IPv6、VPS 出口和公司网络。
• 返回 `401`：通常说明网络已通，但认证缺失、Key 错误或 Header 没带上。
• 返回 `403`：可能是权限、区域、项目或策略限制，需要结合官方错误信息判断。
• 返回 `429`：看速率限制、额度、并发和账单，不要继续换节点。

Codex CLI 运行在终端环境里，排查逻辑跟 OpenAI API、GitHub、NPM 是同一条线：先确认命令在哪台机器跑，再确认这台机器的出口和代理。安装、登录、参数和认证方式以 OpenAI Codex 官方文档为准，教程里不要把某个版本的命令写成永久事实。

💻 第六步：排查 Cursor / VS Code 远程环境

Cursor 或 VS Code 的 UI 能联网，不代表项目终端也能联网。尤其使用 Remote SSH 时，终端是在远程 VPS 上运行。

  # 在 Cursor / VS Code 的终端里执行，确认终端到底在哪
hostname
pwd
curl ipinfo.io
env | grep -i proxy

# 如果是 Remote SSH，这些命令看到的是远程 VPS 环境，不是本地电脑

如果 `curl ipinfo.io` 显示的是 VPS IP，那就不要继续改本地代理；应该去检查 VPS 的网络、DNS、IPv6、代理、Tailscale / WireGuard 或服务商线路。反过来，如果终端显示本地出口，就继续检查本地代理客户端和环境变量。

🐳 第七步：排查 Docker 和容器网络

Docker 是另一个常见分界线。宿主机 `curl` 能通，不代表容器内能通；容器可能需要独立 DNS、代理变量或 Docker daemon 代理配置。

  # 宿主机检查
docker version
docker info

# 容器内检查 DNS 和出口
docker run --rm curlimages/curl:latest -I https://api.openai.com/v1/models
docker run --rm curlimages/curl:latest https://ipinfo.io

# 给一次性容器传代理变量
docker run --rm \
  -e HTTP_PROXY=http://host.docker.internal:7890 \
  -e HTTPS_PROXY=http://host.docker.internal:7890 \
  curlimages/curl:latest -I https://api.openai.com/v1/models

如果你的项目在容器里调用 OpenAI API，最终要在容器内验证 API 连通性。只测宿主机不够。

🧷 第八步：TLS、证书、时间和 IPv6

当 DNS 正常、代理也正常，但仍然握手失败或偶发超时，要看系统时间、证书链、IPv6 和网络中间设备。

  # 检查系统时间
date
timedatectl status

# 分别强制 IPv4 / IPv6 测试
curl -4 -I https://api.openai.com/v1/models
curl -6 -I https://api.openai.com/v1/models

# 看 TLS 握手细节，输出较长，主要观察证书和连接阶段
curl -vI https://api.openai.com/v1/models

• 系统时间偏差太大，会导致 TLS 证书校验失败。
• IPv6 质量差时，域名优先走 IPv6 可能导致超时，可以先强制 `curl -4` 对比。
• 公司代理、安全软件、校园网网关可能做 TLS 检查，表现为证书异常或握手失败。
• 不要用关闭证书校验来掩盖问题，正式开发环境要把根因找出来。

🛠️ 常见修复方案

⚠️ 不要这样修

🧭 站内推荐路径

如果你只是想临时修好一个命令，按上面的层级排查就够了。如果你希望长期稳定使用 AI 开发工具，建议按下面的站内路径补齐。

📚 资料来源

• OpenAI API 错误码文档：用于区分认证、限速、服务端错误和网络超时的排查方向。
• OpenAI Codex CLI 官方文档：用于核对 Codex CLI 的官方入口和终端使用边界。
• npm config proxy 文档：用于核对 npm 的 proxy / https-proxy 配置项。
• Git config http.proxy 文档：用于核对 Git HTTP(S) 代理配置。
• VS Code Remote Development 排错文档：用于远程开发环境故障排查入口。
• Docker daemon proxy 文档：用于核对 Docker 守护进程代理配置。