WSL2 走不通 Windows 上的 Clash？
检查 localhost 转发与 DNS 逐步排查

一、为何在 WSL2 里填 127.0.0.1 常无效

WSL2 运行在轻量级虚拟机与虚拟网卡构成的网络命名空间里，127.0.0.1 指向的是这台 Linux 环境自己的回环接口，而不是你正在运行 Clash 的 Windows 宿主机。因此，把 http_proxy 写成 http://127.0.0.1:7890 时，流量只会尝试连接 WSL 内部的 7890 端口；若你没有在 Linux 里再跑一份监听在 7890 的代理，连接会失败或表现为「代理开了像没开」。

网上部分旧教程提到「从 Windows 转发 localhost 到 WSL」，那是另一套机制（例如特定版本下的 localhost 转发 行为），与「让 WSL 主动连宿主机上的 Clash」不是同一件事。最稳妥的做法是：始终使用从 WSL 视角能路由到的宿主机地址，再配合你在 Windows 客户端里为 混合端口（Mixed Port） 配置的监听范围。

若你已在 Windows 浏览器里验证 Clash 正常，而 WSL 仍不通，请先放下「换节点」的冲动，按本文顺序检查：宿主机 IP → 端口监听 → 防火墙 → DNS。这与我们在 Windows 上混合端口与局域网 一文里强调的「监听地址 + 入站放行」思路是一致的，只是对端从手机换成了 WSL2。

二、拿到 Windows 宿主机在 WSL2 中的可达地址

从 /etc/resolv.conf 读取 nameserver

在默认的 WSL2 网络模型下，系统生成的 /etc/resolv.conf 里通常有一条 nameserver，其地址往往对应Windows 在「WSL 虚拟网卡」上的接口 IP。对许多用户来说，把这个 IP 当作「宿主机地址」去填代理主机名，即可访问运行在 Windows 上的 Clash 混合端口。你可以在 WSL 中执行 grep nameserver /etc/resolv.conf 查看当前值。

请注意：若你曾手动改过 WSL 的 DNS 或使用了自定义 resolv.conf，该文件可能与默认行为不一致；升级 Windows 或切换 WSL 版本后，宿主机侧 IP 也可能变化。排障时建议每次先重新确认这一地址，而不是沿用几个月前记在笔记里的数字。

其他获取方式与稳定性

在较新的 Windows 版本中，还可通过文档推荐的方式解析「Windows 主机」主机名（具体名称随发行版与 Windows 版本而异，请以 Microsoft 官方 WSL 网络文档 为准）。无论用哪种方法，核心目标只有一个：得到从 WSL2 发包能到达、且 Windows 防火墙允许入站的那张网卡上的地址。

三、对齐 Clash 在 Windows 上的监听与防火墙

即使你已经拿到了正确的宿主机 IP，若 Clash 在 Windows 上只监听 127.0.0.1，来自 WSL 虚拟网卡的入站连接仍会被拒绝。需要在客户端或配置中允许在所有接口上监听混合端口（常见表述为 0.0.0.0、bind-address: '*' 或「允许局域网 / Allow LAN」类开关，具体以你所用的 Mihomo 内核与 GUI 为准）。

修改后务必重载配置或重启内核，并在 Windows 侧用「资源监视器」或 netstat 类工具确认混合端口已绑定到 0.0.0.0 或等价范围，而不是仅 127.0.0.1。

第二层是 Windows Defender 防火墙：来自 WSL 的流量对 Windows 而言属于入站。若未为 Clash 主程序放行，或缺少针对该 TCP 端口的入站规则，会出现超时。可按「允许应用通过防火墙」为客户端可执行文件勾选专用/公用网络，必要时在高级安全设置中为混合端口添加 TCP 入站允许规则。更细的步骤可与上文提到的 混合端口与防火墙 教程对照操作。

快速自测：在 WSL2 中执行 curl -v -x http://宿主机IP:混合端口 https://www.example.com（将地址与端口替换为你的实际值）。若此处仍失败，先不要动 DNS，优先解决「TCP 能否建立到 Clash」。

四、在 WSL2 中配置 HTTP/SOCKS 环境变量

命令行工具普遍认 http_proxy、https_proxy、all_proxy（大小写变体视 shell 而定）。在代理 URL 中应写完整的主机与端口，例如 http://172.x.x.x:7890，其中主机部分使用上一节得到的宿主机 IP，端口与 Windows 上 Clash 的混合端口一致。

若某些工具只走 SOCKS，可额外设置 all_proxy=socks5://宿主机IP:端口，并确认 Clash 该端口对 SOCKS 协议开放（混合端口通常同时兼容 HTTP 与 SOCKS，以实现细节仍取决于内核与配置）。

建议把导出语句写入 ~/.bashrc 或 ~/.zshrc，并用 source 重新加载。使用 apt 时，部分环境还需配置 Acquire::http::Proxy 等 APT 专用项；若仅依赖环境变量无效，可查阅当前发行版文档中关于代理的章节。

git 除环境变量外，也可使用 git config --global http.proxy 指向同一地址。保持「主机 = 宿主机 IP、端口 = 混合端口」这一约定，可避免与浏览器侧「系统代理指向 127.0.0.1」混用时的认知错位。

五、DNS 与 systemd-resolved：解析仍失败时查什么

当 TCP 代理已通，但访问域名时出现「Could not resolve host」或间歇性解析失败，问题多半落在 DNS 路径上。WSL2 内的请求可能经 systemd-resolved、resolv.conf 指向的上游，再到 Windows；而 Clash 在 Windows 上又可能使用 fake-ip、DoH 或直连指定 DNS。任一环不一致，都会表现为「IP 能 curl，域名不行」。

先区分现象

• 对纯 IP 的 HTTPS 请求成功，对域名失败：优先查 Linux 侧解析与是否误把不可达的 DNS 写进 resolv.conf。
• 浏览器在 Windows 正常，WSL 内失败：常见是 WSL 仍使用失效的 nameserver，或 Clash 的 DNS 监听未对来自虚拟网卡的查询开放。

可操作方向

在 Ubuntu 等使用 systemd-resolved 的发行版上，可用 resolvectl status 查看当前 DNS 与路由。若你明确希望域名解析也经 Clash，需要保证查询最终能到达 Windows 上 Clash 所监听的 DNS 端口（具体端口与是否开启「劫持」式 DNS 以你的配置为准），且防火墙同样放行该端口的入站（若从 WSL 访问）。

另一思路是：在 WSL 内暂时指定公共 DNS 做对比测试，判断问题是「出网」还是「仅 Clash DNS 策略」。对比时请注意隐私与合规，测试完成后改回符合你安全策略的设置。

若你同时开启了 Clash 的 TUN 模式，Windows 侧路由与 DNS 可能被全局接管，表现会与「仅系统代理 + WSL 环境变量」完全不同。此时建议结合 TUN 与路由防火墙排查 一文，先确认 Windows 本机网络健康，再回到 WSL 侧验证。

六、镜像网络、端口转发与 TUN 场景的补充说明

微软在较新的 Windows 预览与部分稳定渠道中为 WSL 提供了镜像网络（mirrored networking）等实验性或可选网络模式，可能改变 localhost 语义与包路径。若你启用了此类选项，请以当前 Windows 版本文档为准重新验证「宿主机地址 + 端口」是否仍适用上文默认假设。

少数用户会在 Windows 侧手动配置端口转发，把 Windows 某个端口映射到 WSL 内部服务；这与「WSL 访问 Windows 上的 Clash」方向相反，配置时不要搞反。若你使用第三方防火墙或企业安全软件，还可能在 WSL 虚拟接口上叠加策略，需要与安全策略管理员确认。

长期维护方面，建议将「当前宿主机 IP、混合端口号、是否 Allow LAN」记在本地笔记模板中，每次大版本升级 Windows 或更换 Clash 客户端后按清单重跑一遍 curl 与 apt update 测试，可显著减少重复排障时间。

七、小结

在 WSL2 里让 apt、curl、git 走 Windows 上的 Clash，关键是接受一个事实：localhost 在两侧不是同一个对象。把代理主机从 127.0.0.1 换成宿主机在 WSL 网络中的可达地址，并把 Windows 上 Clash 的混合端口监听范围与防火墙入站对齐后，绝大部分「连不上」会消失。剩余问题再集中看 DNS 与 systemd-resolved，以及是否与 TUN 全局模式叠加。

相比零散搜索碎片答案，按「连通性先于解析、宿主机先于节点」的顺序排查，能更快定位层级。Clash 生态在规则分流与多平台客户端上的一致性较好，把 Windows 作为出口、WSL 作为开发环境是常见组合；理顺网络边界后，日常更新依赖与克隆仓库会稳定得多。

若你尚未在 Windows 上安装或希望使用维护活跃的客户端，可从本站获取安装包并导入订阅，再按本文与 配置文档 完成混合端口与 DNS 的基础设置。

→ 立即免费下载 Clash，开启流畅上网新体验