WSL代理连不上怎么办？Windows浏览器正常，Ubuntu却无法联网
FunMeGo VPN 按小时计费的VPN 随用随退 了解服务WSL代理连不上，Windows浏览器却正常，先确认你用的是WSL 1还是WSL 2，再检查网络模式和代理监听地址。WSL 2采用NAT时，Linux里的127.0.0.1通常指向它自己，不能直接当作Windows代理地址。
这篇处理Ubuntu等WSL发行版访问Windows上的HTTP或混合代理端口失败。先做单条请求对照，通了再处理环境变量；不要求一开始就改DNS、开TUN或重装发行版。
记录版本和当前代理端口
在Windows的PowerShell里查看：
wsl --version
wsl --list --verbose第二条输出可区分发行版的VERSION是1还是2。前一条不受支持时，保留提示并核对安装方式；它与发行版内的Ubuntu版本不是同一项。微软命令说明列出了这些查询入口。
再到代理客户端查看实际端口及类型。本文用7890作占位值，需要换成自己的HTTP或混合端口；只有SOCKS端口时，应按对应协议测试，不能给它硬套HTTP写法。端口区别可参考代理设置方法。
若已设置.wslconfig，记录其中的网络选项。文件里写了镜像模式，也不等于当前实例已按它启动；应结合启动提示和实际连接验证，保留可能的回退信息。
根据网络模式选择Windows地址
微软网络文档区分了WSL 2默认NAT与镜像网络：前者访问Windows服务通常用主机地址，镜像模式支持从Linux通过127.0.0.1访问Windows服务。
| 当前情况 | 代理地址怎么选 | 还要检查什么 |
|---|---|---|
| WSL 2默认NAT | 当前Windows主机在WSL侧的地址 | 代理是否接受该接口连接 |
| WSL 2镜像网络 | 可先用127.0.0.1做对照 | 当前模式是否实际生效、端口是否正确 |
| WSL 1 | 按其网络与代理实际配置测试 | 不照搬WSL 2 NAT网关方案 |
| 远程服务器或另一个容器 | 使用那里可达的代理地址 | localhost指向的环境已经不同 |
默认NAT下，在WSL终端运行：
ip route show default查看默认路由中的via地址，并按微软说明将它用于该模式的Windows主机连接测试。不要照抄别人的172.x.x.x示例，它可能随环境变化；也不要不看网络模式，固定把/etc/resolv.conf中的DNS地址当成代理主机。
先测试监听，再测试网页
在Windows PowerShell中用Get-NetTCPConnection核对代理端口监听：
Get-NetTCPConnection -State Listen -LocalPort 7890 |
Select-Object LocalAddress,LocalPort将端口替换成实际值。只监听127.0.0.1时，NAT里的主机地址连接可能进不来；若客户端明确提供适用于该场景的监听设置，再按文档调整。微软网络说明也提醒远程地址连接需要服务接受相应接口。
把代理监听到所有接口，可能让局域网其他设备也能访问它。需要放行时，应限制到必要接口或WSL来源范围，用完恢复；不要把关闭整个防火墙当成固定步骤。若客户端没有合适的监听能力，保留这个限制，选择受支持的网络方案。
在WSL中给单次curl显式指定代理。下面第一条用于已确认的镜像模式，第二条用于NAT，其中主机地址必须自行替换：
curl -v --connect-timeout 5 --max-time 20 --proxy http://127.0.0.1:7890 --noproxy "" https://example.com/
curl -v --connect-timeout 5 --max-time 20 --proxy http://WINDOWS_HOST_IP:7890 --noproxy "" https://example.com/选择符合当前模式的一条，网址可换成你实际需要访问的页面。5秒和20秒是本次诊断的等待上限，不是协议故障门槛；--noproxy ""只在该条测试中覆盖代理排除规则。curl官方参数说明列出了对应行为。
按失败阶段继续查
| 输出或结果 | 下一步 |
|---|---|
| 连接代理地址就被拒绝 | 核对端口、监听地址及代理是否启动 |
| 连接代理地址超时 | 核对主机地址、实际模式和针对该连接的防火墙规则 |
| 已连接代理，CONNECT阶段失败 | 看代理响应、认证与目标访问能力 |
| 隧道建立后出现证书错误 | 检查证书链、系统时间与实际目标，不关闭验证 |
| 显式代理成功，原命令失败 | 检查原程序的环境变量和代理排除设置 |
网页返回200也可能来自直连。这里要看详细输出是否先连到指定代理，以及后续是否成功建立请求。单条curl成功，只验证这次HTTP请求，不保证Git、包管理器或Docker已使用同一配置。
可以在相同WSL窗口核对原程序的代理设置，后续步骤见curl环境变量与NO_PROXY排查。不要为了让测试通过，直接把所有代理变量永久写进启动文件。
镜像网络适合时再改配置
如果你的Windows 11为22H2或更新版本，且安装的WSL支持镜像网络，可以评估使用它。先备份Windows用户目录里的.wslconfig，在现有[wsl2]节中合并需要的选项，不要覆盖其他内存、内核设置：
[wsl2]
networkingMode=mirroredautoProxy是另一项功能，用于读取Windows的HTTP代理信息；它不能保证每个程序都支持代理，也不能修好错误端口。设置位置和支持条件见高级配置说明。
保存WSL中的任务，停止相关开发进程后，在PowerShell运行wsl --shutdown再重新打开发行版。该命令会终止所有运行中的发行版及WSL 2虚拟机，也可能影响依赖它的开发工具，不能在任务未保存时随手执行。
重新启动后，再用127.0.0.1做同一请求对照。失败时恢复备份并按相同方式重新启动，而不必继续叠加DNS、TUN和端口转发设置。接管范围的区别，可参考TUN与系统代理说明。
常见问题
WSL使用Windows代理，为什么localhost连不上？
先看是不是WSL 2 NAT。在这种模式下，Linux自己的回环地址与Windows服务入口不同，还需要Windows代理接受对应接口上的连接。
检测到localhost代理但未镜像，需要重装WSL吗？
先核对版本、实际网络模式、代理监听和一条显式请求。这个提示不足以证明发行版损坏，也不值得直接删除或重装。
WSL代理设置好后，所有命令都会走代理吗？
不会因此自动保证。不同程序读取代理的方式不同；先验证连接路径，再分别检查Git、包管理器等实际使用的配置。
开TUN就能解决WSL代理问题吗？
取决于客户端、路由及WSL网络环境。它不能代替监听地址和实际请求验证，已有显式代理方案可用时，不必同时增加另一套接管设置。