1 为何 WSL2 与 Windows「各走各的」
WSL2 本质是跑在 Hyper-V 虚拟机里的 Linux 内核实例，默认通过虚拟网卡 NAT 访问外网；你在 Windows 里开的 Clash 系统代理，并不会自动「渗透」进 WSL 的进程环境。于是常见现象是：Edge 走了 127.0.0.1:端口，WSL 里却连不上同一个地址——因为在 WSL 里，127.0.0.1 指的是Linux 自己，不是 Windows 宿主机。
要让 apt、git、curl 走你在 Windows 上跑的 Clash，核心就两件事：一是找到从 WSL 能 ping 通、且 Clash 正在监听的那组「地址 + 端口」；二是分别按工具习惯写好代理（apt 用 Acquire::http::Proxy，多数命令行工具认 http_proxy / HTTPS_PROXY）。若再配合较新的 WSL 镜像网络，有时还能简化「本机互通」这一层，下文会分开说明。
若你尚未在 Windows 上装好图形客户端，可先对照《Clash Verge Rev Windows 安装教程》完成安装与基础开关，再回 WSL 侧继续。
2 Windows 侧：Clash 端口与 Allow LAN
在 WSL 里访问 Windows 上的 Clash，常见做法是使用宿主机在虚拟网段上的 IP（见下一节），因此 Clash 不能只监听 127.0.0.1，否则来自 WSL 的连接会被拒。请在客户端中确认：
- 混合端口或 HTTP 端口：记下你在用的端口号（例如
7890，以实际界面为准）。 - Allow LAN / 允许局域网：开启后，代理进程通常会监听
0.0.0.0:端口，WSL 才能从虚拟网卡 IP 连进来。 - 防火墙：若仍连接被拒绝，在「Windows 安全中心 → 防火墙 → 入站规则」中为该客户端放行对应端口（仅限你信任的网络环境）。
若你主要用 TUN 模式接管 Windows 本机流量，WSL 仍可能需要单独配置代理或路由；终端与 Docker 全走代理的体系化说明可见《Clash Verge Rev TUN 模式完全指南》，可与本文步骤组合使用。
3 在 WSL 里拿到宿主机 IP
默认 WSL2 NAT 模式下，Windows 宿主机在 WSL 路由表里通常表现为默认网关。在 Ubuntu 里可以用下面任一方式取得 IP（输出以你机器为准）：
ip route show | grep -i default | awk '{ print $3}'
另一种常见做法是查看自动生成的 /etc/resolv.conf 里 nameserver 一行：在不少 WSL 发行版中，该地址即指向宿主机 DNS 转发的 IP，往往与默认网关一致，可一并作为「连 Windows 服务」的候选地址。请以你当前文件内容为准，若微软后续变更生成规则，优先以 ip route 结果为准。
拿到 IP 后，假设为 172.24.160.1、Clash HTTP 混合端口为 7890，则 WSL 内可用的代理基址为 http://172.24.160.1:7890（协议选 http 指向 Clash 的 HTTP 入站即可，具体以客户端文档为准）。
127.0.0.1:7890，除非你做端口转发或镜像网络，否则连的是 Linux 本机，不是 Windows 上的 Clash。
4 镜像网络（Mirrored）是什么
从 Windows 11 的较新版本开始，WSL 支持实验性的镜像网络（mirrored networking）：让 WSL 与 Windows 在网络层面更「像同一台机器」，减少 NAT、端口映射带来的心智负担。启用后，部分场景下访问宿主机服务的方式会与经典 NAT 模式不同，甚至可能出现「与 localhost 互通」的行为差异——因此务必以你当前 Windows 与 WSL 版本文档为准做验证。
在 %UserProfile%\.wslconfig 中可配置（需重启 WSL 生效）：
[wsl2]
networkingMode=mirrored
启用镜像网络后，仍建议用 curl -v 实际探测：能否直连宿主机上的 Clash 端口、DNS 是否仍由 resolv 链正确下发。若行为与旧教程不一致，不要硬套「固定 IP」，以实测连通性为准。
5 配置 apt：Acquire 代理文件
apt 不会自动读取 shell 里的 http_proxy（除非你另行包装），推荐在 /etc/apt/apt.conf.d/ 下单独写一段，例如新建 95clash-proxy.conf（文件名可自定）：
Acquire::http::Proxy "http://YOUR_HOST_IP:7890/";
Acquire::https::Proxy "http://YOUR_HOST_IP:7890/";
将 YOUR_HOST_IP 换成上一节得到的宿主机地址。保存后执行 sudo apt update 观察是否仍报连接超时或 403。若你使用国内镜像源，源本身可走直连，但仍需保证解析与 TLS 握手路径符合你的规则——有时问题在 DNS 而非 apt 文件写错。
需要临时取消代理时，可注释上述两行或改为空串，再运行 apt，避免长期把公司内网源也强行送往海外节点。
6 Git、curl 与 shell 环境变量
对 git、curl、wget 以及多数遵循环境变量的 CLI，可在 ~/.bashrc 或 ~/.zshrc 中加入（同样替换 IP 与端口）：
export HOST_IP=$(ip route show | grep -i default | awk '{ print $3}')
export http_proxy="http://${HOST_IP}:7890"
export https_proxy="http://${HOST_IP}:7890"
# Optional: export ALL_PROXY="socks5://${HOST_IP}:7891" if SOCKS inbound is enabled若你在 Clash 中另行开启了 SOCKS 入站，可取消注释最后一行并把端口改成与客户端一致；否则只保留 HTTP 即可。Git 亦可单独设置：
git config --global http.proxy http://YOUR_HOST_IP:7890
git config --global https.proxy http://YOUR_HOST_IP:7890
使用动态获取的 HOST_IP 的好处是：宿主机虚拟网卡重启后 IP 变化时，重新打开 shell 即可刷新，不必手改多处配置文件。
7 DNS 与 resolv.conf 对齐
WSL 默认由系统自动生成 /etc/resolv.conf，其中 nameserver 往往指向宿主机侧的 DNS 转发。若 Clash 侧使用 FakeIP、自定义 DoH 或分流策略，可能出现「Windows 浏览器正常、WSL 内 dig/nslookup 异常」的错位感。处理思路是：
- 先确认现象是解析失败还是连接超时：解析失败优先查 resolv 与 Clash DNS 配置；连接超时更像路由或代理未生效。
- 需要固定行为时，可在
/etc/wsl.conf中关闭自动生成 resolv，并自建resolv.conf——这会提高维护成本，适合能自行承担风险的进阶用户。 - 更系统的 FakeIP、DoH 与防泄漏思路可参考本站《彻底防止 DNS 泄漏》，与 Windows 侧 Clash 配置一起对照。
若你发现 resolv.conf 在每次启动时被覆盖，优先查阅当前 WSL 版本关于 [network] 与 generateResolvConf 的官方说明，再决定是接受自动生成还是改为手动管理。
8 验证与常见报错
建议按顺序做最小验证，避免同时改太多变量：
- 在 WSL 内
ping宿主机 IP，确认二层连通（若禁 ping，可跳过，改用下一步）。 curl -v --proxy http://HOST_IP:7890 https://www.google.com（或你环境内可用的探测目标）确认 HTTP 代理链可用。sudo apt update，观察是否仍卡在「Connecting to」某域名。- 对照 Clash 日志，看来自 WSL 网段的请求是否命中规则、是否被直连或拒绝。
常见坑包括：未开 Allow LAN；防火墙拦截；宿主机 IP 变更后 apt 仍写死旧 IP；SOCKS 与 HTTP 端口混用；以及仅设置了环境变量却未配置 apt。按层排查通常能很快收敛。
127.0.0.1 不是 Windows；apt 要单独写 Acquire；CLI 多半认环境变量；DNS 不对先别怪节点。
9 总结
在 Windows 已运行 Clash 的前提下，让 WSL2 Ubuntu 稳定走宿主机代理，关键是接受「双网络栈」这一事实：先保证 Clash 对局域网开放监听，再在 Linux 内用正确的宿主机地址分别配置 apt、Git 与通用环境变量，最后把 DNS 与 resolv.conf 的表现和 Clash 的 DNS 策略对齐。需要时，再评估镜像网络能否简化拓扑。
相比在规则里盲目加域名，先把「地址是否可达、工具是否认代理、DNS 是否一致」三层理清，能少踩很多坑。长期要在多设备、多系统间统一体验，一款维护活跃、日志清晰的 Clash 系客户端会省大量时间——若你尚未使用本站推荐的发行版，不妨从 Windows 安装与下载入口开始补齐环境。
相比其他同类工具，Clash 系在规则可读性、日志与社区资料上的综合体验仍然更友好；把 Windows 客户端与 WSL 开发环境一起调顺之后，日常拉代码、装依赖会顺畅很多。
