我在 WSL 中用 VS Code Remote 时,GitHub Copilot 突然抽风了:对话没输出,终端里报 fetch failed,连模型名都显示不出来。检查 Copilot Chat 的输出面板,一眼看到 proxies 相关的错误——又是代理惹的祸。
VS Code 有个选项叫 http: Use Local Proxy Configuration,默认是开启的。它会直接把宿主机(Windows)的代理设置同步到 WSL 环境里。问题就出在这儿:如果代理软件跑在宿主机本机,配置里写的代理地址通常是 127.0.0.1。但在 WSL 内部,127.0.0.1 指向的是 WSL 自己,不是宿主机,当然连不上。
正确的做法是先拿到宿主机的 IP:
hostip=$(ip route show | grep -i default | awk '{ print $3}')
echo $hostip
我的环境里输出是:
172.25.48.1
这样一来,WSL 里访问宿主机的代理就得用 172.25.48.1:端口 才行。总结一下网络逻辑:
- WSL 2 / VS Code Remote → 宿主机监听在某个端口
- 默认代理 IP 是 127.0.0.1 → 在 WSL 中指向自身 → 连接被拒
- 查询
ip route show | awk '{ print $3}'拿到宿主机 IP (172.25.48.1) - 将代理指向这个 IP,流量才能正确转发到宿主机
知道原因后,解决办法也很直接。如果网络能直连,最简单的就是关掉 http: Use Local Proxy Configuration 这个选项,一了百了。
要是必须走代理,关掉那个选项后还得额外配一下。StackOverflow 上有一个方案(copilot is not working is WSL remote connection?),把 Copilot 的设置改成 "GitHub.copilot": [ "ui" ],让它只在宿主机 UI 层跑。这个办法确实能通,但代价不小:Copilot 完全跑在宿主机上,Agent 模式就废了,改不了 WSL 里的文件,几乎成了摆设。
我更常用的办法是让 WSL 自己正确代理。写了个脚本,自动拿到宿主机 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="${PROXY_HTTP}"
export 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


