Cursor / Codex 在 Windows、WSL、Remote SSH 里网络不一致怎么办？

很多小白第一次用 Cursor、Codex CLI、WSL 或 Remote SSH 时，会遇到一种很绕的问题：浏览器能打开 ChatGPT，Cursor 聊天也能用，但终端里的 npm、GitHub、OpenAI API、Docker 还是超时。不要急着重装工具，先确认“命令到底在哪个环境里执行”。

✅ 先给结论：多数问题不是 Cursor 坏了

Cursor、Codex CLI、WSL、Remote SSH、Docker 看起来都在同一台电脑上，但网络层可能完全不同。

• 浏览器可能走系统代理，但 PowerShell 没走。
• Windows 代理通了，WSL 里不一定通。
• Remote SSH 终端是在 VPS 上跑，不是在本地电脑上跑。
• Docker 容器不会自动继承宿主机代理。

所以排查顺序不是“换节点、重装工具、重启电脑”，而是：执行位置 -> 出口 IP -> DNS -> 代理变量 -> 单个工具配置。

📍 第一步：确认命令到底在哪里执行

先别看错误，先看命令在哪。很多人把 Remote SSH 里的报错当成本地网络问题，越修越乱。

  # Windows PowerShell：确认当前机器和 PowerShell 版本
hostname
whoami
$PSVersionTable.PSVersion

# WSL：确认你进入的是哪个 Linux 发行版
wsl.exe -l -v
hostname
whoami
pwd

# Linux / Remote SSH / VPS：确认命令是否在远程执行
hostname
whoami
pwd
uname -a

如果 `hostname` 显示的是 VPS 主机名，那你改本地 Windows 代理通常没用；如果显示的是 WSL 发行版，说明你要在 WSL 里单独检查代理和 DNS。

🌐 第二步：比较 Windows、WSL、Remote 的出口 IP 和 DNS

同一个命令，在 Windows、WSL、Remote SSH 和 Docker 里各跑一次。只要出口 IP 不一样，就说明它们走的不是同一条网络。

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

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

小白只需要先看三件事：出口国家/地区是否符合预期、DNS 是否能解析、是否只有某个环境失败。

🔌 第三步：检查代理变量有没有带过去

很多代理客户端只帮浏览器或系统代理生效，终端工具未必读取。先查看当前环境有没有代理变量。

  # Windows PowerShell：看当前窗口代理变量
Get-ChildItem Env: | Where-Object { $_.Name -match 'proxy' }
netsh winhttp show proxy

# WSL / Linux / VPS：看当前终端代理变量
env | grep -i proxy

如果变量为空，可以先用临时代理测试，不要一上来就写进系统环境变量。

  # 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"

# WSL / Linux：只给当前终端临时设置
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

端口 `7890` 只是常见示例，要以你代理客户端实际监听端口为准。测试通过后，再决定是否长期写入 shell 配置。

🧩 四个高频场景怎么修

🧪 npm、GitHub、OpenAI API 单独不通怎么办

浏览器通不等于 npm、git、API 都通。把它们分开测，才能知道是哪一个工具配置有问题。

  # npm
npm ping
npm view react version
npm config get registry
npm config get proxy
npm config get https-proxy

# GitHub
git ls-remote https://github.com/openai/openai-node.git HEAD
git config --global --get http.proxy
git config --global --get https.proxy

# OpenAI API：不带 Key 也能判断 DNS / TLS / 网络是否到达 API
curl -i https://api.openai.com/v1/models

• `npm ping` 不通，先看 npm registry 和 npm proxy。
• `git ls-remote` 不通，先区分 HTTPS 失败还是 SSH 端口失败。
• `curl -i https://api.openai.com/v1/models` 能返回 HTTP 状态，说明网络至少能到 API。

🐳 Docker 容器里不通怎么办

Docker 是最容易误判的一层：宿主机能联网，容器仍然可能 DNS 失败、代理为空或访问不到宿主机代理端口。

  # 宿主机能通，不代表容器能通
docker run --rm curlimages/curl:latest https://ipinfo.io
docker run --rm curlimages/curl:latest -I https://api.openai.com/v1/models

# Docker Desktop 常见写法：容器访问宿主机代理
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

Windows Docker Desktop 常用 `host.docker.internal` 访问宿主机；Linux 服务器上则要按实际网络和 Docker daemon 代理配置处理。

🚫 不要这样修

📋 小白排查清单

如果你照着清单跑完，通常能把问题缩小到某一层：Windows、WSL、Remote SSH、Docker、npm、git 或 API 权限。能定位到层级，就已经解决了一半。

📚 资料来源

• Microsoft WSL 文档
• VS Code Remote SSH 文档
• Docker daemon proxy 文档
• npm config 文档
• Git config 文档

➡️ 下一步行动