适用场景：你在 本机 VSCode 需要代理（例如使用claude模型等），但通过 Remote-SSH 连接的远程 Linux 服务器并没有本地代理。VSCode Server/Copilot 在远端仍然尝试走 127.0.0.1:7890，导致联网失败、Copilot 激活失败。

---

现象与日志

远端 ~/.vscode-server 的日志出现：

Error: Failed to establish a socket connection to proxies: PROXY 127.0.0.1:7890
GitHub Copilot could not connect to server. Extension activation failed
[LanguageModelAccess] LanguageModel/Embeddings are not available without auth token

并能看到：

Can't use the Electron fetcher in this environment.
Using the Node fetcher.

这说明 VSCode Server（Node 侧）在 远程服务器 上试图走 127.0.0.1:7890 的代理；但这个 127.0.0.1 指的是 远程机器的本地地址，不是你笔记本/台式机的本地地址，自然连不上。

---

TL;DR（一分钟快修）

你需要 区分本机与远端的代理配置：

• 本机 VSCode（GUI）继续走代理：http.proxy = http://127.0.0.1:7890

• 远端 VSCode Server 不走代理：在「远端设置」里把 http.proxy 设为空字符串

步骤：

1. 连接到远程后，打开命令面板 → Preferences: Open Remote Settings (JSON)，写入：

{
  "http.proxy": "",
  "http.proxyStrictSSL": false
}

2)（可选）在远端 shell 里清理代理环境变量：

unset http_proxy https_proxy all_proxy

1. 重启远端 VSCode Server（断开重连即可；如需彻底重置可执行 rm -rf ~/.vscode-server，但会触发重装，谨慎使用）。

---

心智模型：为什么会这样？

• VSCode Remote-SSH 会在 远程服务器 上启动一个 VSCode Server（Node 环境）。

• 远端的 127.0.0.1 仅代表 远端自身，不是你的本机。

• 如果远端环境变量或 VSCode 远端设置里指定了 http.proxy=http://127.0.0.1:7890，但远端并没有启动对应代理服务，所有网络请求（包括 Copilot 登录、嵌入获取）都会失败。

---

复现与定位

1) 检查远端的代理环境变量

# 登录到远程 Linux
printenv | grep -i proxy
# 或者更彻底一点
grep -IinH 'proxy' /etc/environment ~/.bashrc ~/.zshrc /etc/profile /etc/profile.d/* 2>/dev/null || true

若看到类似：

http_proxy=http://127.0.0.1:7890
https_proxy=http://127.0.0.1:7890
all_proxy=socks5://127.0.0.1:7890

那就是远端在强制走一个 并不存在 的本地代理。

2) 检查 VSCode 的远端设置

连接远端后，打开 Remote Settings (JSON)，查看是否设置了 http.proxy。
远端配置文件通常位于：

~/.vscode-server/data/Machine/settings.json

（用编辑器打开确认是否写了 http.proxy、http.proxySupport、http.proxyStrictSSL 等。）

3) 做一次连通性自检

# 不经代理直连 GitHub API（用来判断是否需要代理）
curl -I https://api.github.com

# 如果远端其实也需要代理，测试代理是否可用（只有当远端真的有代理在 127.0.0.1:7890 监听时才会成功）
curl -x http://127.0.0.1:7890 -I https://api.github.com

• 直连可达 → 远端不需要代理，关掉代理配置即可。

• 直连不可达 → 远端也需要代理：要么在远端部署代理，要么让远端指向一个 可达的 代理地址（见下文「方案 C」）。

---

解决方案（从易到难）

方案 A（推荐）：本机走代理，远端不走

目标：只在远端关闭 VSCode 的代理，让远端直连外网；本机保持代理不变。

1. 本机 VSCode 的 settings（仍然保持）：

{
  "http.proxy": "http://127.0.0.1:7890",
  "http.proxyStrictSSL": false
}

1. 连接远端后，打开 Remote Settings (JSON)，写入：

{
  "http.proxy": "",
  "http.proxyStrictSSL": false
}

这会覆盖远端的代理设置，让 VSCode Server/扩展在远端直接联网。

1. 清理远端环境变量（如果之前设置过）：

# 临时清理（当前会话有效）
unset http_proxy https_proxy all_proxy

# 永久清理：在 ~/.bashrc 或 ~/.zshrc 注释掉相关 export 行，然后
sed -i.bak '/http_proxy\|https_proxy\|all_proxy/d' ~/.bashrc ~/.zshrc 2>/dev/null || true
# 重新加载
source ~/.bashrc 2>/dev/null || source ~/.zshrc 2>/dev/null || true

1. 重启远端 VSCode Server（断连再连即可；或执行）：

# 温和重启：杀掉 server 进程，自动重启
pkill -f vscode-server || true

# 彻底重置（会触发重新下载，慎用）
# rm -rf ~/.vscode-server

方案 B：只清理远端环境变量（简单粗暴）

如果你没有在 VSCode 远端设置里显式配置 http.proxy，只需要把 远端 shell 的代理环境变量清掉即可（同上 unset + 编辑 ~/.bashrc/~/.zshrc）。
对许多场景已足够。

方案 C（高级）：远端也需要代理 → 提供 可达 的代理

如果远端机器位于受限网络环境，确实需要代理，有两个可行方向：

1. 在远端部署代理（如 clash、sing-box、v2ray），监听 127.0.0.1:7890 或其他端口：

   • 确认代理可用：

     curl -x http://127.0.0.1:7890 -I https://api.github.com
     

2. 让远端复用你本机的代理：

   • 在你本机的代理软件开启 局域网共享（监听 0.0.0.0），记下本机局域网 IP（例如 192.168.1.10:7890）。

   • 在远端将 http.proxy 指向 http://192.168.1.10:7890（此时要求远端能访问你的本机 IP；跨公网通常不现实/不安全）。

   • 远端设置示例（Remote Settings）：

     {
       "http.proxy": "http://192.168.1.10:7890",
       "http.proxyStrictSSL": false
     }
     

注意：公网跨机复用个人代理并不安全，也常常不可达；生产环境建议在远端就地部署代理或使用企业网关。

---

验证清单

1. 远端直连可用？

curl -I https://api.github.com

1. VSCode 远端设置中 http.proxy 是否为空字符串（或干脆没有该字段）？

2. 远端 shell printenv | grep -i proxy 是否 无输出？

3. 重新连接 Remote-SSH 后，查看 输出 → GitHub Copilot 面板，是否还报 Failed to establish a socket connection to proxies: PROXY 127.0.0.1:7890？

---

常见坑位

• “127.0.0.1 等于我的本机”：错。远端的 127.0.0.1 永远指向 远端本机。

• 本机设置同步到远端：VSCode 的「设置同步」并不会把你的系统代理自动变成远端可用的代理；远端需要单独配置。

• 把远端整个 ~/.vscode-server 删掉：可以一键“洗白”，但会触发重新下载，动作很重。优先考虑修改设置/变量并重启服务。

• 只关 http_proxy 忘了 https_proxy/all_proxy：三个都要关。

---

一键修复脚本（远端执行）

仅适用于“远端不需要代理”的场景。它会：清理环境变量、删除可能的代理设置、备份并修改远端 VSCode 设置。

#!/usr/bin/env bash
set -euo pipefail

echo "[1/5] 清理环境变量（当前会话）"
unset http_proxy https_proxy all_proxy || true

echo "[2/5] 永久移除 shell 代理（~/.bashrc, ~/.zshrc）"
for f in ~/.bashrc ~/.zshrc; do
  if [ -f "$f" ]; then
    cp -f "$f" "$f.bak.$(date +%s)"
    sed -i '/http_proxy\|https_proxy\|all_proxy/d' "$f"
  fi
done

echo "[3/5] 关闭 VSCode 远端 http.proxy"
SETTINGS="$HOME/.vscode-server/data/Machine/settings.json"
mkdir -p "$(dirname "$SETTINGS")"
if [ -f "$SETTINGS" ]; then
  cp -f "$SETTINGS" "$SETTINGS.bak.$(date +%s)"
fi
# 写入最小配置（保留已有配置可用 jq 合并，这里直接覆盖为简化）
cat > "$SETTINGS" <<'JSON'
{
  "http.proxy": "",
  "http.proxyStrictSSL": false
}
JSON

echo "[4/5] 重启 VSCode Server"
pkill -f vscode-server || true

echo "[5/5] 验证直连 GitHub API（仅测试）"
curl -sI https://api.github.com | head -n 1 || true

echo "完成：请在 VSCode 里断开并重新连接 Remote-SSH。"

如果你本机 VSCode 远端设置里还有其它自定义项，建议用 jq 合并，而不是覆盖写入；上述脚本为“快速修复”版本。

---

结语

• 根因：远端 Linux 没有本地代理，却被配置为走 127.0.0.1:7890。

• 最佳实践：把本地与远端的代理设置分离——本地继续走代理，远端直连（或为远端单独提供可达的代理）。

• 关键动作：在 Remote Settings (JSON) 中把 http.proxy 设为空字符串，并清理远端代理环境变量。