Windows浏览器可以访问网页，WSL里的apt、curl却超时，这并不矛盾。Windows应用和WSL中的Linux进程使用不同的代理配置来源；在WSL 2传统NAT网络中，Linux还运行在轻量虚拟机网络里，localhost、DNS和防火墙边界都可能不同。
一、先确认WSL版本与网络模式
使用wsl --status和wsl -l -v记录当前版本与发行版。WSL 1与WSL 2网络实现不同，较新的WSL还支持镜像网络等选项。不要从几年前的固定IP教程直接复制命令，应以当前Windows、WSL版本和实际配置为准。
二、127.0.0.1到底指向哪里
| 位置 | 127.0.0.1通常表示 | 注意事项 |
|---|---|---|
| Windows应用 | Windows本机 | 代理必须监听相应接口 |
| WSL 1 | 与Windows网络集成较深 | 仍需验证服务监听与防火墙 |
| WSL 2 NAT模式 | Linux虚拟环境自身 | 访问Windows服务常需宿主机地址 |
| 镜像网络 | 行为更接近共享网络 | 受版本与配置影响，需实测 |
如果Windows代理只监听127.0.0.1，WSL 2通过宿主机地址访问时可能被拒绝。是否允许局域或虚拟网卡访问应由管理员根据安全需求配置，不能盲目改成监听所有接口。
三、WSL里代理通常配置在哪里
Linux命令行工具常读取HTTP_PROXY、HTTPS_PROXY、ALL_PROXY和NO_PROXY，也可能有自己的配置文件。可先在当前Shell临时设置占位代理做验证，确认后再决定写入用户配置、发行版系统配置或特定服务。不要把真实密码提交到dotfiles仓库。
四、Windows系统代理为何不等于WSL代理
Windows系统代理主要供支持相应系统接口的Windows应用读取。WSL中的apt、Git、Python和Node运行在Linux用户空间，通常使用环境变量或工具配置。Windows多种代理入口差异见Windows系统、WinHTTP与应用代理。
五、如何找到Windows宿主机地址
传统WSL 2 NAT环境中，可从当前默认路由或系统提供的网络信息动态判断宿主机网关，但该地址不应硬编码为永久值。还要确认代理服务监听该地址对应的接口，并由Windows防火墙只允许必要来源。网络模式变化后应重新验证。
六、DNS失败为什么看起来像代理失败
代理主机名本身需要解析；使用HTTP代理访问目标时，目标DNS可能由客户端或代理处理，取决于协议和工具。若连代理域名都解析不了，请先查WSL的/etc/resolv.conf来源、公司VPN、DNS策略和网络模式，而不是继续修改代理账号。
七、NO_PROXY应包含哪些地址
常见候选包括localhost、回环地址、WSL内部服务、公司内网域名和宿主机服务，但应按实际需要逐项加入。不同工具对CIDR、IPv6、端口和域名后缀的支持不同。范围过大会让外部访问直连，范围过小会把内部请求交给代理。
八、systemd服务为什么不读取Shell变量
WSL启用systemd后，服务由服务管理器启动。你在终端export的变量不会自动进入已运行服务。应为具体服务使用drop-in或EnvironmentFile，修改后执行daemon-reload并重启该服务。可参考systemd服务代理配置。
九、Docker Desktop与WSL又多一层
Docker Desktop可能与WSL集成，但Docker守护进程、构建步骤和容器运行环境仍是不同层。WSL终端中的curl成功，不代表容器能联网；容器镜像拉取成功，也不代表构建RUN命令拥有代理变量。
分层方法见Docker构建与容器代理区别。
十、安全设置不要忽略监听范围
- 不要为了WSL访问把无认证代理暴露到所有网卡；
- 通过防火墙限制虚拟网络或本机来源；
- 不在Shell历史、脚本和截图中保留密码；
- 对公司内网目标使用精确绕过规则；
- 网络模式切换后重新检查监听与访问控制。
十一、排查顺序
- 记录Windows、WSL版本及网络模式；
- 确认代理服务监听地址和端口；
- 在WSL内测试DNS与到代理的TCP连接；
- 再测试407、CONNECT和TLS；
- 分别验证Shell、systemd服务与容器；
- 核对IPv4、IPv6和NO_PROXY路径；
- 重启WSL或相关进程后清理临时配置。
十二、结论
WSL代理配置的关键是理解宿主机、Linux环境和容器之间的网络边界。先确认版本与模式，再处理localhost、监听地址、DNS和服务环境，远比硬编码一个“宿主机IP”可靠。
