Windows 上做开发，WSL2 几乎是标配。它提供接近原生的 Linux 环境，Docker、Git、Node.js、Python 都能在里面跑。但很多人装好 快连 之后发现一个尴尬的问题：Windows 侧的浏览器已经能访问外网了，WSL2 里的 git clone 却一直超时，npm install 卡在下载依赖，pip install 报连接错误，Docker 拉镜像更是纹丝不动。
原因不复杂：WSL2 虽然跑在 Windows 上，但它是一个独立的虚拟机，拥有自己的虚拟网卡和网络栈。Windows 的系统代理设置，WSL2 里的程序默认是看不到的。快连接管的是 Windows 的网络，WSL2 被隔离在另一层，除非你显式地把代理配置传给 WSL2 里的各个工具，否则它们会直接走物理网络，连不上就是必然结果。
本文把 WSL2 的代理链路从头讲清楚，从找到 Windows 主机 IP，到配置 Git、npm、pip、Docker 四类工具，再到常见失败的排查，一步步打通。
一、先理解 WSL2 的网络隔离
WSL2 本质上是一个轻量级 Hyper-V 虚拟机。它和 Windows 主机之间通过一个虚拟交换机通信，Windows 主机在 WSL2 看来是一个"外部"网络上的机器，有一个虚拟 IP。默认情况下，WSL2 的流量走 NAT 出去，和 Windows 主机共享物理网卡，但不共享代理设置。
这意味着两件事。第一，快连在 Windows 上开的本地代理端口，WSL2 里的程序默认不知道。第二，WSL2 要访问这个端口，必须用 Windows 主机在 WSL2 网络里的 IP，而不是 127.0.0.1。
在 WSL2 里执行 cat /etc/resolv.conf，可以看到 nameserver 后面跟着一个 IP，这个 IP 通常就是 Windows 主机的虚拟网关地址。也可以用 ip route | grep default 查看默认网关，那个地址就是 Windows 主机在 WSL2 网络里的入口。
把下面这条命令记下来，后面配置都会用到：
拿到这个 IP 之后，加上快连在 Windows 上监听的本地代理端口，就构成了 WSL2 访问代理的完整地址，形如 http://172.x.x.x:端口号。
二、确认快连的监听地址与端口
还有一个前提容易被忽略：快连默认可能只监听 127.0.0.1，也就是只允许本机访问。WSL2 从虚拟网卡过来，源地址不是 127.0.0.1，会被拒绝。
需要在快连客户端的设置中，把"允许局域网连接"打开，或者把监听地址从 127.0.0.1 改为 0.0.0.0。不同版本的界面名称略有差异，通常叫"允许局域网访问""允许其他设备连接"或"监听地址"。打开之后，WSL2 才能通过虚拟网关 IP 访问到快连的代理端口。
同时记下快连的本地代理端口号。在设置界面的"代理设置"中可以查看，通常是 HTTP 代理端口和 SOCKS 端口各一个。后面配置工具时，HTTP 类工具用 HTTP 端口，需要 SOCKS 的工具用 SOCKS 端口。
安全提醒：把监听地址改为 0.0.0.0 后，同一局域网内的其他设备也可能访问到这个代理端口。如果使用的是公共 WiFi，建议只临时开启，用完改回 127.0.0.1，或者在 Windows 防火墙中限制来源 IP。
三、在 WSL2 中设置全局代理环境变量
最简单的方式是通过环境变量。很多命令行工具会读取 http_proxy、https_proxy、all_proxy 这几个环境变量，自动把请求发往代理。
添加后执行 source ~/.bashrc 使其生效。用 curl -I https://www.google.com 测试，如果返回 200 或 301，说明代理通了。
环境变量的优点是通用，大多数工具都认。缺点是它只对读取环境变量的程序有效，有些工具不读，需要单独配置。另外，环境变量在每次新开终端时都需要重新加载，写进 ~/.bashrc 可以避免手动设置。
四、Git 的代理配置
Git 读取环境变量，但更稳妥的做法是直接写进 Git 配置。这样即使环境变量没加载，Git 也能走代理。
配置完成后，用 git clone 一个 GitHub 仓库测试。如果仍然超时，检查 Git 是否使用了 SSH 协议（git@github.com:... 这种形式），SSH 协议不走 http.proxy，需要按上面的方式单独配置。
需要取消代理时，执行 git config --global --unset http.proxy 和 git config --global --unset https.proxy 即可。
五、npm 与 yarn 的代理配置
npm 和 yarn 都支持代理配置，命令略有不同。
配置后执行 npm config get proxy 确认写入成功。测试时可以跑 npm view react version，如果能返回版本号，说明代理生效。
如果使用了国内镜像源（如淘宝源），请求本身不需要代理，反而可能因为走代理而变慢。这种情况下可以只对需要访问外网的包启用代理，或者临时切换回官方源再测试。
六、pip 的代理配置
pip 读取环境变量，也可以在命令行中显式指定。如果已经设置了 http_proxy 和 https_proxy，pip 通常能自动使用。
pip 的代理配置有个细节：如果代理地址里包含特殊字符，需要做 URL 编码。另外，pip 使用 HTTPS 源时，代理必须是 HTTP 或 HTTPS 代理，SOCKS 代理需要额外安装 pysocks 才能支持。
七、Docker 的代理配置
Docker 是 WSL2 开发环境里最容易卡住的一环，因为它有两层：Docker 客户端和 Docker 守护进程。拉取镜像的行为由守护进程发起，所以代理要配置在守护进程上，而不是客户端。
如果使用的是 Docker Desktop for Windows，配置入口在 Docker Desktop 的设置里，找到"Resources - Proxies"，填入代理地址。注意这里填的是 Windows 主机能访问的地址，通常是 http://127.0.0.1:端口号，因为 Docker Desktop 的守护进程跑在 Windows 侧。
如果是在 WSL2 内直接安装的 Docker Engine，需要给 dockerd 配置代理。创建或编辑 /etc/systemd/system/docker.service.d/http-proxy.conf，写入：
保存后执行 systemctl daemon-reload 和 systemctl restart docker。用 docker pull hello-world 测试，能拉下来就说明配置成功。
NO_PROXY 那一行很重要。如果不排除 localhost 和 127.0.0.1，本地容器之间的通信也会走代理，可能导致容器网络异常。
八、配置方式对比
| 工具 | 配置位置 | 是否读取环境变量 | 备注 |
|---|---|---|---|
| curl / wget | 环境变量 | 是 | 最简单，改环境变量即可 |
| Git（HTTPS） | git config | 是 | 建议显式配置，避免环境变量丢失 |
| Git（SSH） | ~/.ssh/config | 否 | 需要 ProxyCommand 单独配置 |
| npm / yarn | npm config / yarn config | 部分 | 建议显式配置 |
| pip | 环境变量或 pip.conf | 是 | SOCKS 需 pysocks 支持 |
| Docker | 守护进程配置 | 否 | 必须配置在守护进程，不是客户端 |
九、常见失败原因与排查
配置完发现还是不通，按以下顺序排查。
原因一：快连没有允许局域网连接
表现是 WSL2 里 curl 报连接被拒绝。回到快连设置，确认"允许局域网连接"已开启，监听地址不是仅 127.0.0.1。开启后重启快连客户端。
原因二：Windows 防火墙拦截
Windows 防火墙默认可能阻止来自虚拟网卡的连接。在"允许应用通过防火墙"中，确认快连客户端在专用网络和公用网络下都勾选。或者临时关闭防火墙测试，确认是防火墙问题后再添加规则。
原因三：Windows 主机 IP 变了
WSL2 的虚拟网关 IP 在每次重启后可能变化。如果之前配置的 IP 是硬编码的，重启后就会失效。所以建议每次在 ~/.bashrc 中用 ip route 动态获取，而不是写死一个固定 IP。
原因四：代理端口填错
HTTP 代理和 SOCKS 代理的端口不同，配置时容易混用。Git、npm、pip 一般用 HTTP 代理端口；需要 SOCKS 的工具（如某些 SSH 配置）要用 SOCKS 端口。对照快连设置界面逐一核对。
原因五：工具的配置优先级覆盖
某些工具会优先读取自己的配置文件，忽略环境变量。比如 npm 如果配置了国内镜像源，可能不认 https_proxy。这时需要显式修改工具自己的配置，而不是只靠环境变量。
十、常见问题解答
Q1：为什么 Windows 浏览器能上网，WSL2 里就不行？
WSL2 是独立虚拟机，不继承 Windows 的系统代理设置。需要在 WSL2 内单独配置代理，指向 Windows 主机的虚拟网关 IP 和快连的代理端口。
Q2：能不能在 WSL2 里也装一个快连客户端？
技术上可行，Linux 版客户端可以在 WSL2 中运行。但 WSL2 的 systemd、TUN 设备支持取决于版本，配置比在 Windows 侧复杂。更推荐的做法是 Windows 侧运行快连，WSL2 通过代理链访问，稳定且维护成本低。
Q3：配置后 WSL2 能上网，但 Docker 容器里不行？
Docker 容器有独立的网络命名空间，不继承宿主机的环境变量。需要给 Docker 守护进程配置代理，或者在运行容器时通过 -e 参数传入代理环境变量。持久化方案是配置 ~/.docker/config.json 中的 proxies 字段。
Q4：每次重启 WSL2 都要重新配置吗？
环境变量写在 ~/.bashrc 中会自动加载，不需要重复配置。但 Windows 主机 IP 可能变化，所以获取 IP 的命令要写进 ~/.bashrc，每次启动时动态获取，而不是写死。
Q5：WSL2 的代理配置会影响 Windows 吗？
不会。WSL2 内的环境变量和工具配置只作用于 WSL2 内部，不影响 Windows 侧。两边是独立的。如果你还没有安装 Windows 侧客户端，可以从快连下载页获取最新版本。
十一、总结
WSL2 的代理配置，难点不在命令本身，而在理解"WSL2 是独立虚拟机"这个前提。快连在 Windows 上工作，WSL2 默认看不到它的代理端口。打通的关键是三件事：让快连允许局域网连接、获取 Windows 主机的虚拟网关 IP、把代理地址传给 WSL2 里的各个工具。
Git、npm、pip、Docker 四类工具的配置各有细节，但思路一致：显式配置优先于环境变量，守护进程类工具要在守护进程侧配置。配置完成后，建议逐个测试，确认每个工具都真正走了代理，而不是碰巧能连上。
如果你还没有安装快连，可以前往官网的客户端下载页面获取对应版本。安装后先在 Windows 侧确认代理正常工作，再按本文步骤打通 WSL2，开发环境的网络问题基本就能一次解决。更多关于代理模式、端口排查和连接诊断的内容，可以在技术博客的其他文章中继续了解。