Copilot 在 WSL 中无法连接的常见原因
在使用 VS Code Remote - WSL 开发时，很多开发者会遇到 GitHub Copilot 无法登录、对话无响应或显示 fetch failed 的情况。这通常不是插件本身的问题，而是网络代理配置在跨平台环境下的冲突导致的。
现象排查
如果你遇到以下情况，大概率是代理路径错误：
- Copilot Chat 对话框没有输出内容。
- 状态栏提示
fetch failed或连接超时。 - 模型名称列表无法加载。
查看 Copilot Chat 的 Output 面板，如果看到与 proxies 相关的报错，基本可以确定是 WSL 中的 VS Code 调用了宿主机的代理设置，但目标地址指向了错误的回环地址。
核心问题分析
VS Code 的远程开发功能默认会尝试继承宿主机的代理配置。当你在宿主机（Windows）上运行代理软件时，它通常监听在 127.0.0.1。
但在 WSL 环境中，127.0.0.1 指的是 WSL 虚拟机自己，而不是你的 Windows 宿主机。因此，WSL 发出的请求会被拦截在自己内部，无法到达宿主机的代理端口，导致连接被拒绝。
要解决这个问题，WSL 必须知道如何访问宿主机的网络接口。你需要查询宿主机的 IP 地址，通常是一个类似 172.x.x.x 的地址。
ip route show | grep -i default | awk '{ print $3 }'
执行后你会得到类似 172.25.48.1 的输出。这就是 WSL 访问宿主机代理的正确地址。
解决方案
方案一：关闭本地代理继承（推荐）
如果你的网络环境允许直连，或者不需要全局代理，最简单的方法是修改 VS Code 设置，禁用对本地代理配置的继承。
在 VS Code 设置中搜索 http: Use Local Proxy Configuration，将其取消勾选。这样 WSL 环境将不再尝试使用宿主机的代理设置，通常能直接恢复 Copilot 的连接。
方案二：配置正确的代理 IP
如果你必须使用代理，则需要手动指定宿主机的 IP 地址。除了手动修改 VS Code 设置外，更灵活的方式是通过脚本在 WSL 命令行中动态配置环境变量。
下面是一个自动化的 Shell 脚本，它能获取宿主机 IP，并根据需要开启或关闭代理变量，同时配置 Git 的全局代理。
#!/bin/sh
hostip=$(ip route show | grep -i default | awk '{ print $3 }')
wslip=$(hostname -I | awk '{print $1}')
port=7890
PROXY_HTTP="http://${hostip}:${port}"
PROXY_SOCKS5="socks5://${hostip}:${port}"
set_proxy() {
export http_proxy="${PROXY_HTTP}"
export HTTP_PROXY=
https_proxy=
HTTPS_proxy=
ALL_PROXY=
all_proxy=
git config --global http.https://github.com.proxy
git config --global https.https://github.com.proxy
}
() {
http_proxy
HTTP_PROXY
https_proxy
HTTPS_PROXY
ALL_PROXY
all_proxy
git config --global -- http.https://github.com.proxy
git config --global -- https.https://github.com.proxy
}
() {
resp=$(curl -I -s --connect-timeout 5 -m 5 -w -o /dev/null www.google.com)
[ = ];
}
[ = ];
set_proxy
[ = ];
unset_proxy
[ = ];
test_setting