Copilot 在 WSL 中无法使用的原因与解决
在使用 VS Code Remote - WSL 开发时，经常会遇到 GitHub Copilot 无法连接的情况。这通常不是插件本身的问题，而是网络代理配置在宿主机与 WSL 环境之间传递时产生的冲突。
常见报错现象
如果你发现以下情况之一，大概率是代理设置导致的：
- 对话没有输出，光标一直转圈。
- 终端或状态栏显示 "fetch failed"。
- 模型名称无法加载显示。
查看 Copilot Chat 的输出面板，通常会看到与 proxies 相关的错误信息。这是因为默认情况下，VS Code 远程连接 WSL 时会继承宿主机的本地代理设置。
核心问题分析
问题的关键在于代理地址的解析。如果你在宿主机上运行了代理程序（如 Clash、V2Ray 等），它通常监听在 127.0.0.1。当 VS Code 将这一配置传递给 WSL 内部时，WSL 会尝试访问自己的 127.0.0.1，而不是宿主机的 IP，导致连接被拒绝。
要解决这个问题，你需要找到宿主机的局域网 IP，并让 WSL 通过这个 IP 访问代理端口。
在 WSL 终端中执行以下命令获取宿主机 IP：
hostip=$(ip route show | grep -i default | awk '{ print $3}')
echo $hostip
假设输出为 172.25.48.1，那么 WSL 中的请求应该指向这个 IP 而非 127.0.0.1。
解决方案
方案一：关闭本地代理继承
如果不需要全局代理，或者可以通过其他方式直连，最直接的方法是关闭 VS Code 的本地代理继承选项。
在 VS Code 设置中搜索 http: Use Local Proxy Configuration，将其取消勾选。这样 WSL 环境就不会强制使用宿主机的代理设置。
方案二：配置正确的代理地址
如果必须使用代理，且需要保持功能完整（例如 Copilot 的 Agent 模式能修改 WSL 文件），则需要在 WSL 内部配置指向宿主机 IP 的环境变量。
注意：网上有些方案建议将 Copilot 完全限制在宿主机运行，但这会导致无法直接编辑 WSL 内的文件，体验较差，不建议采用。
自动化代理脚本
为了方便管理，可以编写一个 Shell 脚本来自动获取宿主机 IP 并设置环境变量。以下脚本支持开启、关闭和测试代理状态。
#!/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)
[=200];
}
[=]
set_proxy
[=]
unset_proxy
[=]
test_setting
