我在 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
