WSL2 连不上 Windows 代理？NAT、镜像网络与 autoProxy 排查

Windows 浏览器能上网，WSL2 中的下载却失败，先确认 WSL2 用的是 NAT 还是镜像网络。NAT 模式下，Linux 中的 127.0.0.1 通常不能直接代替 Windows 宿主机地址；镜像模式则支持使用 IPv4 回环地址访问 Windows 服务。随后检查代理端口、监听范围、autoProxy 和具体应用，不要先重装发行版。

作者：小仓 · 资料核对日期：2026-10-05

本文讨论 WSL2 访问 Windows 中已经运行的代理服务。WSL1、独立 Linux 主机和 Docker 容器不是相同环境，不能把一种环境的地址直接复制给另一种。

第一步：记录版本与网络模式

在 Windows PowerShell 中执行：

wsl --version
wsl --list --verbose

前者显示 WSL 组件版本，后者帮助确认发行版使用 WSL1 还是 WSL2；两条命令都不会修改网络。若旧环境不支持某个参数，先看 wsl --help，不要把“不认识选项”当成代理错误。Microsoft WSL 基本命令

再检查 Windows 用户目录里的 .wslconfig 是否设置了 networkingMode。它是 WSL2 的全局配置，Linux 发行版里的 /etc/wsl.conf 有不同作用范围。文件内容也需要结合实际启动状态和版本判断，不能只看到一行设置就认定已经生效。WSL 配置文件及作用范围

Microsoft 目前说明，镜像网络需要 Windows 11 22H2 或更高版本及支持相关选项的 WSL 环境；不要给 Windows 10 直接照抄镜像配置，也不必为一次故障同时切换网络模式与 DNS。镜像网络的支持条件

第二步：按网络模式找 Windows 代理入口

已核对的模式	WSL2 访问 Windows 服务时先查什么	常见误区
NAT	Windows 在该虚拟网络中的宿主机地址	直接复制 Windows 的 127.0.0.1
mirrored 镜像网络	可用 127.0.0.1 核对 Windows 入口	把 IPv6 ::1 当成同样支持
其他模式或存在回退	按安装版本文档确认实际拓扑	只根据默认模式猜地址

在 NAT 模式的 Linux 终端中，运行只读命令 ip route show default，核对默认路由中 via 后的网关地址。Microsoft 用这条路径说明 WSL2 看到的 Windows 宿主机地址；有多个路由或 VPN 时，要确认使用的是哪条，不能盲目取第一行。从 WSL 访问 Windows 服务

同时在 Windows 代理客户端核对协议、实际监听端口和允许的连接来源。NAT 下连接宿主机地址可能需要服务接受来自相应虚拟网络的连接；应按客户端文档限定范围，而不是为了省事关闭防火墙或把入口开放给所有网络。

为什么不直接复制 resolv.conf 的 nameserver？

DNS tunneling 可以改变 WSL 内看到的解析服务地址。这个地址负责解析，不应自动当作 Windows 代理监听地址。把 DNS 查询路径和访问宿主机服务的路径分开，可以避免反复试错。WSL DNS tunneling

第三步：在 Linux 里做一次明确的请求

下面是支持 HTTP 的本机入口示例，须在 WSL Linux 终端执行。镜像模式先核对回环地址；NAT 模式把它换成已确认的宿主机地址。7890 也要换成真实端口。

proxyUrl='http://127.0.0.1:7890'
curl -q --proxy "$proxyUrl" --noproxy 'localhost,127.0.0.1' --head --connect-timeout 10 --max-time 20 https://example.com

-q 放在首个参数，跳过默认 curl 配置；--proxy 明确本次入口；绕过列表只保留回环目标，减少宽泛 NO_PROXY 干扰。连接最多等待 10 秒，整体最多 20 秒。示例网站用于演示，排查时应使用相同的实际目标。curl 参数说明

结果	下一步检查
本地入口连接被拒绝	地址、端口、服务运行与监听范围
一直等待超时	Windows／Hyper-V 防火墙及实际接入路径
出现目标 HTTP 响应	再验证原下载程序和真实任务
只有证书校验报错	系统时间、Linux 信任库与具体证书错误

响应头测试成功不证明大文件下载或所有应用正常。不要用关闭证书校验来掩盖问题，也不要把 Windows 浏览器的证书结果当成 Linux 工具的结果。

怎样避免把入口错误当成节点错误？

先核对客户端是否收到这次请求，再看它记录的目标和失败阶段。若客户端没有相应记录，优先查 WSL 到 Windows 的地址、监听与防火墙；若已经收到请求，再检查客户端规则和远端连接。日志未记录也可能是记录功能没有开启，不能只凭空白日志下结论。

Windows 侧测试与 WSL 侧测试应使用同一目标、同一代理协议和同一端口，并记下时间。浏览器可能有缓存、扩展或自己的代理设置，不能只用“页面以前打开过”代替这次对照。确认一次路径后再恢复原下载任务，观察原错误是否消失。

第四步：区分 autoProxy 与应用支持

autoProxy 用于让 WSL 使用 Windows 的 HTTP 代理信息，不能据此认定任意程序都会支持所有代理协议。满足功能条件的环境可在 .wslconfig 的现有 [wsl2] 部分核对：

[wsl2]
autoProxy=true

不要重复添加相同节或覆盖原有配置。先保留当前网络模式，只检查这一项；单次 curl 成功而原程序失败时，再读那个程序的代理说明，核对大小写变量、绕过规则和独立配置。autoProxy 与高级设置

修改 .wslconfig 后，需要让 WSL 虚拟机重新启动以应用设置。保存 Linux 工作和相关任务后，可在 PowerShell 执行 wsl --shutdown；它会终止所有运行发行版和 WSL2 虚拟机，不是只重开当前终端。随后重新进入发行版，核对有效设置并重复同一测试。配置生效与关闭命令

常见问题与记录

系统代理、autoProxy 和 TUN 是否等价？

它们涉及不同接入方式。要验证请求是否进入客户端、走哪个出口，不能只看一个开关；可参考本站规则、全局与 TUN 的区别。

能否一次设置所有终端程序？

不同工具的支持不完全一致。先建立一次可解释的请求，再逐个验证真正使用的程序；HTTPS Git 的独立设置可参考终端代理排查。

记录 Windows／WSL 版本、发行版类型、网络模式、代理地址与协议、单次错误及原程序结果。分享时删除代理密码和账户信息，保持每轮只改一个条件。