WSL2 终端如何走 Windows Clash：镜像网络与 localhost 代理配置实测（2026）

1. 为什么 WSL2 里的 127.0.0.1 往往不是「Windows 上的 Clash」

WSL2基于虚拟化网络：Linux 发行版跑在轻量虚拟机里，通过虚拟网卡与 Windows通信。你在 WSL2 终端里访问 127.0.0.1或 localhost，握手落在该 Linux 实例的回环接口上，而不是 Windows 用户态里监听的端口。除非使用下文提到的镜像网络等特性改变了转发语义，否则「把代理写成 http://127.0.0.1:7890」在 WSL2 内通常只会去找 Linux 侧有没有进程监听 7890，与 Windows 上已打开的 Clash无关。这也是社区里反复出现「浏览器能翻，WSL2 里 curl 仍直连」的第一性原因：两套栈，两套回环。

因此，终端代理的正确心智模型是：在 WSL2 内显式指定「Windows 宿主机在当前网络拓扑下对 WSL2 可见的 IP」再加上 Clash的 mixed-port（或你单独拆出来的 HTTP 端口）。这与在 Windows 本机 PowerShell 里写 127.0.0.1不是同一套地址簿。先把命名空间对齐，再谈规则与策略组，否则会陷入「改 YAML 改到怀疑人生，其实包根本没进内核」的假象。

2. 传统 NAT 模式：宿主机 IP 从哪读（resolv.conf 与默认路由）

在未启用镜像网络的常见默认拓扑里，WSL2 往往通过一块虚拟网桥与 Windows 通信。/etc/resolv.conf里由 WSL 注入的 nameserver地址，在大量实测环境中恰好等于 Windows 宿主机在该虚拟网络上的 IP（用于 DNS 转发）。因此社区里最「短平快」的宿主机地址获取方式之一是读取该地址，再把它拼进 HTTP_PROXY。注意：这是经验性捷径而非微软文档对「宿主机 IP」的唯一定义，系统更新或网络模式变化时应重新验证。

另一条互补路径是看默认路由：ip route show default或 ip route | grep default给出的下一跳，常常与上述 DNS 服务器一致。两条命令交叉确认，可以避免某次发行版升级后 resolv.conf生成策略变化带来的单点误判。拿到形如 172.x.x.1的地址后，代理 URL 可写作 http://<该IP>:<mixed-port>。

# Example: discover Windows host IP seen from WSL2 (verify on your machine)
grep nameserver /etc/resolv.conf
ip route show default

若你在团队文档里固化脚本，建议同时打印日期与原始输出，避免「复制同事的 172 地址」在另一台笔记本上静默失效。不同机器、不同 VPN、不同 Hyper-V 虚拟交换机组合都会改变地址分配。

3. Windows 侧 Clash：mixed-port、监听地址与 allow-lan

仅有「WSL2 能 ping 通宿主机 IP」还不够：Clash必须在 Windows 上对该 IP 可达的接口监听你的入站端口。若 HTTP/mixed 只绑在 127.0.0.1，来自 WSL2 虚拟网卡的连接会被操作系统拒绝。常见做法是绑定到 0.0.0.0或在图形壳里开启 allow-lan（或等价「允许局域网连接」），使来自 WSL2 网段的 TCP 能到达 mixed-port。这与站内讲局域网共享 mixed-port 的专栏思路一致，只是请求来源从手机变成了 WSL2；若你对防火墙入站规则仍不熟，可顺读 allow-lan 与 Windows 防火墙把「本机回环」与「对子网开放」分清。

mixed-port允许在同一端口上处理 HTTP 代理与 SOCKS 类握手（视内核实现而定）。给 curl / apt / npm等配环境变量时，优先使用你能确认的 HTTP 代理端口；若你把 SOCKS 端口误填进只支持 HTTP CONNECT 的工具，会表现为握手阶段即失败。订阅与基础连通若仍异常，可先对照 订阅导入教程确认 Windows 侧日志干净，再在 WSL2 内测。

第一次在 Windows 11上安装图形客户端、厘清系统代理与 TUN 的差异时，也可并行参考 Verge Rev 首次配置：浏览器走系统代理≠WSL2 终端自动走代理，后者仍依赖本节所述入站可达性与下文环境变量。

4. WSL2 终端代理：HTTP_PROXY、apt、Git、npm 与环境持久化

绝大多数命令行工具会识别 HTTP_PROXY、HTTPS_PROXY，不少还会认 ALL_PROXY与 NO_PROXY。在交互式 shell 里可临时导出；若要长期生效，写入 ~/.bashrc、~/.zshrc或 systemd user 环境前，务必确认宿主机 IP 是否会变——固定写死有时不如在登录时动态解析。企业内网与私有 Registry 域名应加入 NO_PROXY，避免私有流量被送到公网节点。

# Example: session exports (replace HOST_IP and PORT)
export HTTP_PROXY=http://HOST_IP:7890
export HTTPS_PROXY=http://HOST_IP:7890
export ALL_PROXY=http://HOST_IP:7890
export NO_PROXY=localhost,127.0.0.1,::1

APT在部分版本上除环境变量外，还支持 Acquire::http::Proxy等独立配置；若你发现仅 curl走代理而 apt仍直连，需要对照发行版文档补齐 Acquire 段。Git的 HTTPS 远程通常尊重代理变量；SSH 协议远程则不会自动走 HTTP 代理，除非你额外配置 ProxyCommand或改用 HTTPS URL。npm/yarn/pnpm多数继承环境变量，但企业私服与证书问题仍会单独踩坑，这与「是否到达 Clash」无关，却常伪装成代理失效。

5. 镜像网络 mirrored：.wslconfig 与 localhost 行为变化

微软为 WSL2提供了镜像网络（mirrored / networkingMode=mirrored）类能力（具体键名与可用性随 Windows 与 WSL 版本而演进，请以你当前版本文档为准）。启用后，网络语义会向「更像与宿主机共享同一视角」的方向靠拢，部分场景下在 WSL2 内访问 localhost可以触达 Windows 上监听的端口——这与经典 NAT 模式下「127.0.0.1 仅指 Linux 自身」形成鲜明对照。也正因为如此，网上会出现两种看似矛盾的教程：一种教你用 resolv.conf里的地址，另一种写「直接 127.0.0.1」——二者可能对应不同网络模式与版本，而不是谁绝对错误。

实操建议：先确认你是否启用了镜像网络，再选择地址策略。若处于镜像模式且实测 curl http://127.0.0.1:<port>能打到 Windows 上的 Clash入站，则环境变量可以相应简化；若否，则回退到「宿主机 IP + mixed-port」这条更通用的路径。升级 Windows 大版本或 WSL 内核后，建议在变更后重跑一次最小连通性测试，不要依赖半年前的截图。

6. DNS 与 resolv.conf：何时需要与 Clash DNS 对齐

即便 TCP 代理已通，若域名解析路径与 Clash内核的 DNS、Fake-IP 策略不一致，仍会出现「IP 能访问、域名全挂」或「规则明明写了却进错组」的现象。/etc/resolv.conf在 WSL2 中常被自动管理：指向 Windows 转发器或特定上游。若 Windows 侧 Clash使用 fake-ip，而 WSL2 内解析绕开了内核 DNS 管线，你会在日志里看到与浏览器不一致的解析结果。

排查时建议对比三条信息：WSL2 内 dig或 nslookup看到的地址、Windows 侧 mihomo连接日志里的目标、以及浏览器访问同一域名时的行为。若仅 WSL2 异常，优先怀疑解析链而非节点质量。需要全局理解 Fake-IP 与 TUN 关系时，可结合站内 TUN 模式说明建立上下文，再回来看 WSL2 是否应显式指向某上游或保持与宿主机一致的转发路径。

7. 与「Docker 走宿主机 Clash」专栏的差异

站内已有 Docker 容器走宿主机 Clash一文：其核心是 Linux 容器网络命名空间与宿主机之间的端口映射、host.docker.internal或 docker0 网关等议题。本文聚焦 WSL2与 Windows这对组合：宿主机仍是 Windows，但客户端跑在微软虚拟化的 Linux 里，地址获取与 镜像网络开关更关键；Docker 场景则更多面对 bridge、Compose 与 BuildKit 的环境变量分层。两者都常用 HTTP_PROXY，但「宿主机是谁、从子系统如何到达」的答案不同，不宜混用教程里的 IP 与主机名。

8. 连不通时的有序排查清单