Cursor、GitHub Copilot 网络配置指南：编辑器与终端代理设置、连接超时排查

Cursor 和 GitHub Copilot 的网络问题，九成不是节点选得不对，而是代理没有被对应的进程读到，或者 TLS 链路被中间设备拦截。典型症状就是那句经典的矛盾：浏览器打得开 GitHub，编辑器里的补全一直转圈。

原因在于，桌面编辑器里其实同时跑着好几个独立的网络主体：编辑器主进程、扩展宿主进程、内置终端里的 Shell、以及你在终端里调用的 git / npm / pip。它们各有一套读取代理的规则，配漏一处就出问题。

这类工具对网络有什么要求？

延迟敏感，带宽不敏感

代码补全是典型的高频小请求，每次只有几 KB，但一天可能发起上千次。端到端延迟每增加 100 ms 都能明显感觉到「跟不上手速」。所以选节点时应该优先看延迟和抖动，不必追求大带宽，也不需要家宽 IP。

需要稳定的长连接

对话式的代码生成同样走流式返回，中转线路如果对空闲连接设置了较短的超时，会表现为生成到一半停住。这与 Claude 的断流问题 是同一类原因。

域名分散，规则要写后缀

认证、遥测、模型接口、扩展市场往往分布在不同子域上。只放行主站域名，很容易出现「登录成功但补全无响应」的半通状态。

对出口地区不挑剔

和 ChatGPT、Gemini 不同，这类开发工具通常不做地区封锁，日本、新加坡、美国西海岸都可以，选延迟最低的即可。各地区参考延迟见 机场节点延迟多少算正常。

常见报错与原因对照表

编辑器侧怎么配？

VS Code 和 Cursor 共用同一套设置项。打开命令面板搜索 Preferences: Open User Settings (JSON)，加入：

{
  "http.proxy": "http://127.0.0.1:7890",
  "http.proxySupport": "on",
  "http.proxyStrictSSL": true,
  "http.noProxy": [
    "localhost",
    "127.0.0.1",
    "::1",
    "192.168.0.0/16",
    "*.internal.company.com"
  ]
}

几个字段的含义：

• http.proxy：编辑器主进程和大部分扩展使用的代理地址，改完需要完全退出重启。
• http.proxySupport：设为 on 时让扩展也走这个代理；设为 override 会强制覆盖扩展自身的代理逻辑，个别扩展不兼容时改回 on。
• http.proxyStrictSSL：保持 true。设为 false 会关闭证书校验，是很多教程里的错误建议。
• http.noProxy：本地和内网地址一定要排除，否则本地调试会全线失败。

如果代理需要认证，地址写成 http://用户名:密码@127.0.0.1:7890 的形式。

终端侧怎么配？

通用环境变量

大多数命令行工具会读取这三个变量，写进 ~/.zshrc 或 ~/.bashrc：

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
export NO_PROXY=localhost,127.0.0.1,::1,192.168.0.0/16,*.local

需要随手开关的话，定义两个函数更方便：

proxy_on() {
  export HTTP_PROXY=http://127.0.0.1:7890
  export HTTPS_PROXY=$HTTP_PROXY
  export NO_PROXY=localhost,127.0.0.1,::1
  echo "proxy on"
}
proxy_off() {
  unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
  echo "proxy off"
}

Windows PowerShell 下对应写法：

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

各工具的独立配置

环境变量管不到的部分，需要单独设置：

# Git（只对 HTTPS 方式的仓库生效）
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
# 只给 GitHub 走代理，国内镜像保持直连
git config --global http.https://github.com.proxy http://127.0.0.1:7890

# npm / pnpm
npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

# pip（写进 ~/.pip/pip.conf 或命令行临时指定）
pip install --proxy http://127.0.0.1:7890 包名

# Go
go env -w GOPROXY=https://proxy.golang.org,direct

SSH 方式克隆仓库走的是 22 端口，普通 HTTP 代理管不到，需要在 ~/.ssh/config 里指定：

Host github.com
  HostName github.com
  User git
  ProxyCommand nc -X connect -x 127.0.0.1:7890 %h %p

GitHub 本身访问慢、克隆速度低的问题另有一套优化方法，见 GitHub 访问慢怎么解决。

证书错误怎么处理？

出现「无法验证首个证书」时，按这个顺序排查：

1. 确认是否处于被解密的网络。公司、学校网络常部署 HTTPS 中间人设备，此时所有站点的证书颁发者都会变成该机构的根证书。
2. 把根证书加入系统信任库。macOS 用钥匙串访问导入并设为始终信任；Windows 导入到「受信任的根证书颁发机构」。
3. 给 Node 单独指定。编辑器内置 Node 有时不读系统库：

export NODE_EXTRA_CA_CERTS=/path/to/corp-root-ca.pem

4. 检查客户端的自签证书。开启 MITM 或 HTTPS 解析功能的代理客户端会生成自己的根证书，同样需要安装并信任。

逐项排查流程

按顺序做，每步只改一处：

1. 确认基础连通。终端里 curl -I https://github.com 能否返回，不能就先解决代理本身，参考 Clash 开启后无法上网。
2. 确认编辑器是否走代理。开发者工具的网络面板或扩展日志里看请求是否发出、卡在哪一步。
3. 区分主进程和扩展进程。扩展市场能加载但补全不行，说明是扩展宿主的代理没生效，重点检查 http.proxySupport。
4. 检查排除列表。本地服务同时挂掉就是 NO_PROXY 配漏了。
5. 检查证书链。有证书类报错优先处理证书，其他配置再对也没用。
6. 最后再换节点。确认配置无误后，如果只是慢，换低延迟节点；如果频繁重置，换线路类型。

使用习惯上的几点建议

• 给开发工具单独一个策略组，固定节点，关闭自动切换，避免长请求中途换出口。
• 公司设备遵守公司策略。企业网络里的中间人设备和访问限制是管理要求，绕过它可能违反内部规定，遇到限制应走 IT 支持渠道。
• 把代理配置写进 dotfiles，换机器时不用重新摸索一遍。
• 区分开发代理和日常代理。日常浏览可以用自动选择，开发工具用固定节点，两者互不干扰。