先记录版本和网络模式

Windows PowerShell 中查看；旧版 WSL 可能不支持 --version
wsl --version
wsl --status
wsl -l -v

确认目标发行版运行在 WSL2，并从 Windows 用户目录的 .wslconfig 查看是否设置 networkingMode。没有显式设置时，还需结合当前 WSL 版本和官方默认行为判断。Microsoft 文档将 NAT 与 mirrored 分开说明；镜像网络适用于 Windows 11 22H2 及以上且使用兼容版本的 WSL。不要只根据教程发布日期推断本机已经支持。

先在 Windows 上用实际 HTTP 或 mixed 端口访问目标。如果 Windows 本机代理还不能用，应先处理客户端。下面的 7890 只是例子；SOCKS 端口不能按 HTTP 使用。

NAT 模式：Linux 的回环地址通常不是 Windows 宿主

WSL 的 Bash 中读取默认网关，再做一次显式代理测试
wsl_proxy_host=$(ip route show default | awk '{print $3; exit}')
printf '%s\n' "$wsl_proxy_host"
curl --proxy "http://${wsl_proxy_host}:7890" \
  --connect-timeout 8 --max-time 20 -I https://example.com

这是默认 NAT 场景的宿主入口定位方法，先检查输出是否为预期地址。空值、额外 VPN 路由或特殊网络应先查路由，不要把命令硬套到 mirrored。开启 DNS tunneling 后，/etc/resolv.conf 里的 nameserver 可能是 DNS 隧道地址，不应将它当作通用宿主代理地址。

若 Windows 客户端只监听 127.0.0.1，来自 NAT 虚拟网卡的访问可能进不去。按客户端说明配置可被 WSL 到达的受限监听，并仅允许 WSL 所需来源通过防火墙。虚拟网段可能变化，需要重新核对。不要直接把代理永久绑定所有网卡并关闭防火墙；不便安全开放时，考虑受支持的镜像网络或在 WSL 内使用自己的客户端。

镜像网络：先用 localhost 验证，再决定是否自动继承

Microsoft 文档说明，mirrored 模式下 WSL 可通过 127.0.0.1 访问 Windows 服务；该说明不等于 ::1 也受到相同支持。先做显式 curl 测试，仍失败时检查监听、系统防火墙及 Hyper-V 防火墙，不要立即改 DNS。

符合版本条件时，将这些键合并进已有 .wslconfig 的 [wsl2] 段
[wsl2]
networkingMode=mirrored
autoProxy=true

不要覆盖文件里已有的内存、处理器或其他配置，也不要重复创建冲突段。autoProxy 让 WSL 使用 Windows 的 HTTP 代理信息，并不是把全部 Linux 流量变成 VPN；应用是否使用这些信息、PAC 是否适配仍需实测。仅想测试 mirrored 时可先只改 networkingMode，把自动代理留到下一轮，以免一次变更多项。

先使用单次参数，避免把错误写进所有终端

初次排障优先使用 curl --proxy。它成功后，再按 Git、包管理器或应用官方说明配置持久代理。不要一开始就在 .bashrc 里堆积 HTTP_PROXY、ALL_PROXY 和多套地址；旧变量可能持续覆盖新配置。检查现有变量时只在本地查看，完整 URL 可能包含认证信息。

错误优先核对
Connection refused宿主地址、端口和监听接口
连接超时路由与防火墙是否允许 WSL 来源
Could not resolve proxy代理地址本身无法解析
代理可达但目标失败Windows 客户端规则、节点或目标服务
显式 curl 成功，Git 仍失败Git 自己的配置、变量与 HTTPS/SSH 区别

验收和回退

重新打开终端，重复真实 Git 或下载操作，再验证 Windows 与 WSL 的直连目标、内部域名和 Docker 仍正常。若新模式引入问题，恢复备份的 .wslconfig，保存工作后重启 WSL；同时撤销本次添加的监听、允许规则和持久环境变量。不要删除发行版来修复一个代理入口问题。