在 WSL 里配代理，最气人的一幕：Windows 上代理好好的，WSL 里 curl 却直接超时。原因很简单——WSL2 跑在一个虚拟网卡后面，和宿主机网络是隔离的，你在 WSL 里写的 127.0.0.1 指的是 WSL 自己，根本到不了 Windows 上的代理客户端。
插图来源：Storyset
方法一：直连宿主机 IP（最常用）#
WSL2 里可以通过一个特殊的地址访问宿主机。在 WSL 终端里执行：
cat /etc/resolv.conf看到的 nameserver 那一行，一般就是宿主机的虚拟网卡地址。然后把代理环境变量指向它：
export http_proxy="http://<宿主机IP>:7890"
export https_proxy="http://<宿主机IP>:7890"端口换成你 Windows 客户端实际监听的端口。Linux 环境变量的完整讲究可以看这篇一次讲清。
缺点：宿主机 IP 重启后可能会变，隔段时间要重新看一眼。可以写个小脚本自动从 resolv.conf 里取，放到 .bashrc 里。
方法二：镜像网络模式（一劳永逸）#
新版 WSL 支持 mirrored 网络模式，打开后 WSL 和宿主机共享网络栈，localhost 就是互通的，直接写 127.0.0.1 就行。
在 Windows 用户目录下建一个 .wslconfig 文件：
[wsl2]
networkingMode=mirrored保存后在 PowerShell 里 wsl --shutdown 再重进 WSL 生效。这是最省心的方案，配一次永久有效。
方法三：客户端开 TUN 模式#
如果你的 Windows 客户端支持 TUN 模式（原理见 TUN 和系统代理的区别），开了之后 WSL 的流量会被 TUN 直接接管，连环境变量都不用配。不过 TUN 模式接管的是一整台机器的流量，V2RayN 的教程里有相关设置的入口。
验证与排错#
配完之后，在 WSL 里跑这两条验证：
curl -v https://www.google.com
env | grep -i proxy第一条看请求是不是真的走了代理（看连接的 IP 是不是代理地址），第二条确认变量生效了。如果 curl 通了但 git 不通，八成是 git 自己的代理配置覆盖了环境变量，去查 git config --global http.proxy。
还有个经典坑：Windows 客户端开了"局域网共享"但 WSL 连不上。这种情况先确认 Windows 防火墙有没有放行客户端的监听端口，防火墙弹窗点允许一次就行。
进阶：只让 WSL 走代理，不影响 Windows#
有些人的需求反过来：Windows 本机要直连，只有 WSL 里开发需要代理。这时候别在 Windows 客户端开全局/TUN，就让客户端正常监听本地端口，WSL 里配环境变量指向它。Windows 本机的流量完全不受影响，WSL 里该走的走，两边互不干扰。
选哪个#
- 怕麻烦、WSL 版本新：直接上方法二，镜像网络模式
- 不想动 WSL 配置：方法一，写个脚本自动取 IP
- 整个 Windows 都想无感代理：方法三 TUN
三种方法我都长期用过，目前主力是镜像网络模式，配完就忘。配完之后如果发现部分网站打不开，先别怀疑代理，看看是不是 DNS 的问题——WSL 的 DNS 解析走的是自己的 resolv.conf，和 Windows 不是一套，必要时手动指定 DNS 试试。客户端的基础配置逻辑可以对照这篇总览，原理相通。
