WSL2 里 Git 和 npm 不走代理？与 Windows 共用 Clash 的分步设置（2026）
在 Windows 上浏览器已经能顺畅走 Clash，但一进 WSL2 终端，Git clone、npm install 要么直连失败，要么根本「像没开代理」。根因往往不是订阅坏了，而是网络命名空间不同：127.0.0.1 在 WSL 里指向 Linux 虚拟机自己，而不是你 Windows 宿主机上监听的 mixed／HTTP 端口；再加上命令行工具默认不读取 Windows 的「系统代理」开关，必须显式给环境变量或工具配置。本文与站内侧重「Win11 本机首次安装」的Clash Verge 首次配置、以及「手机共用电脑代理」的局域网与防火墙文互补，专门讲 WSL2 ↔ Windows 双环境与 Git／npm 命令行代理怎么对齐；请仅在合法合规前提下使用。
读完本文你能独立完成什么
你可以按固定顺序完成：确认 Windows 侧 Clash 在 WSL 能访问到的地址上监听（必要时理解 127.0.0.1 与宿主机 IP 的差异）；在 WSL2 内用可靠方法取出宿主机 IPv4；为当前 shell 或持久化配置 http_proxy／https_proxy／all_proxy 与 no_proxy；分别核对 Git 与 npm（及常见包管理器）是否仍需要额外 git config 或 npm config；最后用 curl、克隆小仓库、安装小包做对照验收，并知道 DNS、fake-ip 与 Windows「混合网络／镜像网络」变更时该查哪一层。
根因：为什么「Windows 开了 Clash，WSL2 里却像没代理」
第一，WSL2 是独立虚拟网卡上的 Linux。你在 Windows 资源管理器里看到的「本机」与 WSL 里的「本机」不是同一套回环接口：在 WSL 里访问 127.0.0.1，连的是 Linux 发行版自己，而不是 Windows 上 Clash 监听的端口（除非你做端口转发或特殊桥接）。因此网上很多教程写「代理填 127.0.0.1:7890」在纯 WSL2 场景下常常不成立，表现为 Git／npm 仍然直连或连接被拒绝。
第二，Windows「设置为系统代理」主要影响 Windows 用户态里读系统代理的应用，而大多数 Linux 命令行工具默认看的是环境变量或自身配置，不会自动同步你在 Clash 客户端里点的那个开关。第三，即便出口走通了，DNS 解析路径不一致也会让你误以为「代理没生效」：例如解析结果被污染、或内核 fake-ip 与应用程序解析顺序不匹配，都会出现「浏览器正常、终端异常」的割裂感。需要同时核对 Clash 连接日志与 WSL 内解析结果。
第一步：确认 Windows 侧 Clash 监听地址与端口
在 Windows 上打开 Clash 系客户端（如 Clash Verge Rev / Mihomo），记下实际生效的 mixed-port 或 HTTP 代理端口。若你仅在高级配置里看到 127.0.0.1 监听，而 WSL 需要通过宿主机局域网地址访问，请对照客户端是否允许「绑定到所有接口」或等价 YAML 顶层 allow-lan: true 与合适的 bind-address 语义——与手机共用电脑代理时是同一类问题，细节可参考允许局域网与防火墙入站一文：WSL2 访问 Windows 端口在效果上接近「另一张网卡上的客户端连入」，若只监听回环，Linux 侧无法连上。
同时确认 Windows Defender 防火墙没有拦掉来自 WSL 虚拟网段指向该端口的入站连接；若你曾在「公用网络」profile 下只放行「专用」，也会出现「偶发能连、换 Wi‑Fi 又不行」。完成本步后再进入 WSL，避免在端口未对 Linux 可达时反复改 Git 配置。
第二步：在 WSL2 中获取 Windows 宿主机 IPv4
常见做法之一：查看 /etc/resolv.conf 中的 nameserver，在默认 WSL 配置下它往往指向Windows 宿主机在虚拟交换机上的地址，可作为 HTTP 代理的「主机名」使用（以你机器实际文件为准，若被自动生成覆盖，改用下文备用法）。备用法：在 Windows PowerShell 执行 ipconfig，找到「vEthernet (WSL)」或相关虚拟适配器的 IPv4；或在 WSL 内用 ip route show default 观察默认网关指向哪一跳，通常即宿主机侧可达地址。
新版 Windows 11 若启用「混合网络（mirrored）」等模式，宿主机地址表现可能与旧文档不同；若你发现 resolv.conf 与路由表读出的地址不一致，以能 ping 通且能 telnet／nc 到代理端口的那一侧为准。把该 IPv4 记为下文中的 WIN_HOST，不要继续把 127.0.0.1 当作 Windows 上的 Clash，除非你确认已做等价转发。
第三步：在 WSL 内设置代理环境变量（先当前会话，再考虑持久化）
假设 mixed 端口为 7890（请替换为你的真实端口），在 bash／zsh 可先用：
export HOST_PROXY="http://WIN_HOST:7890"
export http_proxy="$HOST_PROXY"
export https_proxy="$HOST_PROXY"
export all_proxy="$HOST_PROXY"
export no_proxy="localhost,127.0.0.1,::1"其中 WIN_HOST 换成上一步得到的 IPv4。no_proxy 用于让访问本机服务时不绕弯；若你还有公司内网段或容器网段，应一并追加，避免内网 Git／私有 registry 误走代理。验证用 curl -I https://www.google.com 或你环境允许的测试地址，观察是否仍超时。
持久化可写入 ~/.bashrc／~/.zshrc，但建议把「是否启用代理」做成开关函数，防止日常访问国内源也被强行送代理。另一种思路是在仅开发用的项目目录用 direnv 之类工具加载环境，降低全局副作用。
第四步：Git——环境变量之外还要不要 git config
对 HTTPS 远程，现代 Git 多数会尊重 http_proxy／https_proxy；若仍异常，可显式设置：
git config --global http.proxy http://WIN_HOST:7890
git config --global https.proxy http://WIN_HOST:7890需要取消时：
git config --global --unset http.proxy
git config --global --unset https.proxy若你使用 SSH（[email protected]:...），HTTP 代理环境变量不会自动让 SSH 走同一端口；SSH 需 ProxyCommand 搭配 nc 或 connect 等，或改用 HTTPS 远端。对 GitHub 域名分流与最小规则集，可对照开发者 GitHub 分流实测一文，先保证 Windows 侧 Clash 规则本身能覆盖 github.com、githubusercontent.com 等主机，再回 WSL 查终端侧是否命中。
第五步：npm、pnpm、yarn 与 registry
npm 读取环境变量通常即可；若你曾写过全局 proxy，可用 npm config list 检查是否与当前 WIN_HOST 一致。典型设置：
npm config set proxy http://WIN_HOST:7890
npm config set https-proxy http://WIN_HOST:7890若走国内镜像（如 npmmirror），有时反而应关闭 npm 级代理，只让「访问外网 registry 或 tarball」时启用，避免镜像域名被多余地送出国再绕回。安装失败时务必展开日志看实际下载 URL：卡在 GitHub Release、S3、或私有仓时，往往是另一类主机名未进规则，而不是 npm 本身「坏了」。
pnpm、yarn 多数继承 shell 环境变量；如仍有边缘行为，分别查官方文档中的 HTTPS_PROXY 支持与配置优先级。核心原则不变：先保证 TCP 能连到 WIN_HOST:PORT，再谈 registry 与 lockfile。
第六步：DNS、fake-ip 与「解析看起来对但连不上」
Clash 侧若启用 fake-ip，设计目标是由内核在连接阶段接管解析；若应用程序先自行解析再连，可能出现不一致。若在 WSL 内你用 dig／getent 看到的结果与 Clash 日志中的目标主机不匹配，应回到 Windows 侧核对 DNS 与嗅探相关设置，并参考站内 Clash Meta 嗅探与例外、以及订阅与规则类 FAQ。
WSL2 的 /etc/resolv.conf 若被自动管理，可能在某些更新后改写上游 DNS；当你怀疑「解析走了意外路径」，可对比 Windows 与 WSL 对同一域名的解析结果，并结合 Clash「连接／日志」里显示的最终路由与规则命中行，避免只改代理不重查 DNS。
第七步：混合网络、防火墙与公司策略
Windows 11 持续推进 WSL 网络模型演进，部分功能会改变默认网关、NAT、以及 localhost 共享的语义；当你升级系统后原本可用的脚本失效，先查发行说明再改脚本，而不是盲目改回 127.0.0.1。若设备处于公司托管环境，组策略可能限制环回或虚拟网卡通信，表现为 WSL 无法访问宿主机端口——这属于管理边界问题，需要与 IT 政策对齐。
对照排查清单（建议按顺序勾）
（1）Windows 浏览器访问目标站点是否正常，Clash 日志是否显示规则命中。（2）WSL 内 nc -vz WIN_HOST 7890（端口替换）是否通。（3）当前 shell 的 http_proxy 是否已 export。（4）Git 远端是 HTTPS 还是 SSH；SSH 是否误用了 HTTP 代理思路。（5）npm 是否指向意外 registry／是否混用镜像与代理。（6）DNS 与 fake-ip 是否打架。（7）防火墙 profile 是否覆盖当前网络类型。
安全与合规提醒
把 Clash 监听扩展到非回环地址时，请意识到同一信任网络内的其他设备也可能尝试连接；在公共网络应及时收回或关闭允许局域网能力。勿在截图或 Issue 中泄露订阅链接与令牌。请遵守当地法律与服务条款，本文仅描述在自有设备上的网络调试思路。
小结
WSL2 与 Windows 共用 Clash 的关键，是先把「127.0.0.1 不是同一个本机」说清楚，再用宿主机可达 IP + 正确端口统一 Git、npm 与环境变量；随后用连接日志与简单网络探测分层验收，而不是反复重装发行版。与站内 Windows 首次安装、局域网放行、GitHub 分流等文章连读，可以覆盖从「桌面浏览器」到「Linux 命令行」的完整开发链路。
若你尚未在 Windows 上把 Clash 客户端跑通，建议先完成系统代理与 TUN 的基础选型，再回本文对接 WSL2。相比零散论坛片段，使用维护活跃的客户端、从本站下载页获取安装包并配合使用教程建立固定排错顺序，长期成本更低。规则型代理在可观测性与分流精度上仍具优势；当你需要在 WSL 终端里稳定拉代码与装依赖时，按本文对齐地址与工具配置即可明显减少「明明开了代理却完全不走」的困惑。→ 立即免费下载 Clash，开启流畅上网新体验。