wsl与clash代理

这几天重置了网络配置，导致WSL的网络代理出了问题，这里记录一下。

配置与问题表现

软件环境：

WSL2+Clash代理

WSL代理配置：

在wsl的~/.zshrc文件中配置如下：

export hostip=$(cat /etc/resolv.conf |grep -oP '(?<=nameserver\ ).*')
alias setss='export all_proxy="http://${hostip}:7890";'
alias unsetss='unset all_proxy'

第一行是为了获取host的ip地址，使用echo $hostip命令，结果如下：

(base) ➜  ~ echo $hostip
172.18.192.1

这个ip也可以在host上的powershell，使用ipconfig命令看到：

以太网适配器 vEthernet (WSL):

   连接特定的 DNS 后缀 . . . . . . . :
   本地链接 IPv6 地址. . . . . . . . : fe80::724b:8b1e:885b:a9de%57
   IPv4 地址 . . . . . . . . . . . . : 172.18.192.1
   子网掩码  . . . . . . . . . . . . : 255.255.240.0
   默认网关. . . . . . . . . . . . . :

第二行表示使用setss快捷命令可以使用host上的代理。

此时我们执行命令setss，表示激活代理。

Clash配置

clash开启系统代理和局域网连接（allow lan），并且设置端口为7890。

测试存在问题

curl -vv http://www.google.com                                                                                                                                      
* Uses proxy env variable all_proxy == 'http://172.18.192.1:7890'                                                                                                               
*   Trying 172.18.192.1:7890...

使用curl命令尝试连接google发现wsl使用了代理，但是curl失败，始终在尝试连接，也就是说代理没有走通。

问题分析

wsl的代理过程可以分为以下步骤：

1. WSL 发起请求： 在 WSL 里执行 curl，由于设置了环境变量 all_proxy=http://172.18.192.1:7890，WSL 知道要把数据包发往宿主机的 7890 端口。

2. 防火墙“安检”： 数据包到达 Windows 宿主机大门口。Windows 防火墙查看规则库，发现7890端口有入站规则，匹配成功，放行。

3. Clash)接手： 数据包终于进屋了，监听在 7890 端口的代理软件收到了请求。因为它开启了 “Allow LAN”，它接受了来自wsl的连接，然后通过代理服务器把请求转发到互联网。

从curl命令的结果来看，wsl的代理配置没有问题，也就是说第一步WSL 发起请求没有问题。那么问题发生在第二步：防火墙。

wsl可以看成是host局域网的一个机器，所以当wsl需要靠host代理时，需要先把数据包发往宿主机的 7890 端口，在这一步被防火墙的入站规则拦住了。

解决方法

打开powershell，使用命令新建入站规则：

# 只允许 172.16.0.0/12 网段访问该端口 
Set-NetFirewallRule -DisplayName "WSL Proxy Port" -RemoteAddress 172.16.0.0/12

也可以手动加入入站规则：

1. 打开防火墙设置：

   • win+r打开运行窗口，输入 wf.msc，点击确定打开“高级安全 Windows Defender 防火墙”。

2. 创建规则：

   • 在左侧窗格点击“入站规则”。
   • 在右侧操作窗格中，点击“新建规则…”。

3. 规则向导配置：

   • 规则类型： 选择“端口”，点击下一步。
   • 协议和端口： 选择“TCP”，并在“特定本地端口”中填写要开放的端口号（例如7890），点击下一步。
   • 操作： 选择“允许连接”。
   • 配置文件： 勾选“域”、“专用”和“公用”（建议默认全选，或根据网络环境选择）。
   • 名称： 为规则命名（如“WSL Proxy Port”），点击完成。
4. 安全起见，想要设置入站ip，可以在属性-作用域设置。

配置结果如下图：

再次测试-成功了

~ curl -vv http://www.google.com
* Uses proxy env variable all_proxy == 'http://172.18.192.1:7890'
*   Trying 172.18.192.1:7890...
* Connected to 172.18.192.1 (172.18.192.1) port 7890 (#0)
> GET http://www.google.com/ HTTP/1.1
> Host: www.google.com
> User-Agent: curl/8.1.1
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
......

关于入站规则设置

1. 指定RemoteAddress

前面的新建入站规则命令指定了-RemoteAddress 172.16.0.0/12。

这是因为一旦打开了allow lan，理论上互联网上的任何人都能通过你的公网 IP 访问你的 7890 端口。当然，现实中，有两道防线：

第一道防线：路由器的 NAT 墙（默认拦截）

这是最关键的一层。大多数人家里的电脑并不直接暴露在互联网上，而是躲在路由器后面。

• 入站流量的逻辑： 当互联网上的某人尝试连接 你的公网IP:7890 时，这个请求首先到达你的路由器。
• 路由器的反应： 路由器查了一下自己的“转发规则表（Port Forwarding）”。如果没有发现你手动设置过“将 7890 转发到电脑 A”的规则，路由器会认为这是一个非法或无用的入站请求，直接将其丢弃。
• 结果： 流量连你电脑的边都碰不到。

第二道防线：Windows 防火墙（之前的设置）

假设你是个硬核用户，直接把网线插在电脑上拨号（拥有公网 IP），或者你在路由器上开了 DMZ/全端口转发，流量终于来到了你的 Windows 门口。

这时候，你之前运行的那条命令就成了救命稻草：

Set-NetFirewallRule -DisplayName "WSL Proxy Port" -RemoteAddress 172.16.0.0/12

• 匹配规则： 防火墙看到请求来自某个互联网 IP（比如 223.x.x.x）。
• 检查准入规则： 它对比你设定的 RemoteAddress。
  • 规则要求：必须来自 172.16.0.0/12（内部私有网段）。
  • 实际情况：来自外部公网。
• 动作： 拒绝连接。

2. 为什么用 /12 这个数字

根据 RFC 1918 标准，全球规定的“B 类私有保留网段”就是 172.16.0.0 到 172.31.255.255。

• WSL 的特性： 每次你重启电脑或重启 WSL，它的虚拟 IP 都会在 172.x.x.x 这个大池子里随机变动。
• 为什么要给 /12： 如果你只给一个精确的 IP（比如 /32），下次 WSL 变了 IP，你的代理就断了。如果你给 /12，就相当于告诉防火墙：“只要是来自这 100 万个私有地址之一的请求，统统放行。”

3. 为啥用curl而不是ping

在wsl设置 all_proxy="http://172.18.192.1:7890" 时，它是应用层协议：只能引导 TCP 和 UDP（且需要软件支持）流量。

而Ping 是网络层协议： 它使用的是 ICMP。ICMP 根本没有端口（Port）的概念，所以它完全无视 7890 端口。所以ping 命令会直接绕过你的代理设置，按照 WSL 的默认路由，通过 Windows 的网络共享直接向外发包。

同样的之前设置的入站规则也对ping命令无效，想要对ping生效，需要新建入站规则时指定协议为ICMP。

关于clash

1 Allow Lan做了什么？

Allow LAN 是 Clash 的一个“开放准入”开关。

如果你关闭它，Clash 就是一个自闭的程序，只听命于这台电脑自己；如果你开启它，Clash 就会变成一个局域网服务，张开双臂迎接来自其他设备的请求。

1. 核心变化：监听地址的转换

这是技术上最直观的变化：

• 关闭 Allow LAN 时： Clash 只监听 127.0.0.1（回环地址）。
  • 效果： 只有你这台电脑上的浏览器、软件发起的请求，Clash 才会理睬。外界发来的包，网络协议栈会直接拒收。
• 开启 Allow LAN 时： Clash 会监听 0.0.0.0（全网卡地址）。
  • 效果： 无论是本机，还是来自 WSL (172.x.x.x)、手机、甚至同局域网的另一台电脑，只要请求发往这台电脑的 7890 端口，Clash 都会接收并处理。

2. 为什么你的 WSL 必须开启它？

虽然 WSL 2 跑在你的电脑里，但在网络架构上，它被视为局域网中的另一台机器。

1. 身份隔离： WSL 的 IP 是 172.x.x.x，而 Windows 本机在 WSL 看来是 172.18.192.1。
2. 跨网访问： 当你在 WSL 里执行 export all_proxy=http://172.18.192.1:7890 时，流量是从一个虚拟网段（WSL）跨越到另一个网段（Windows）。
3. 如果关闭 Allow LAN： Clash 只看 127.0.0.1，它会觉得：“你这个来自 172.18.x.x 的请求是谁？我不认识，滚出去。”
4. 开启后： Clash 看到请求，发现自己正在监听 0.0.0.0（即全网通），于是愉快地接下了这笔单子。

3. Allow LAN 开启后的安全防线

你可能会担心：开启了 Allow LAN，岂不是谁都能蹭我的代理了？

这就是为什么我们之前要配置 Windows 防火墙 的原因。它们分工如下：

• Clash (Allow LAN)： 决定了“我愿不愿意接待外客”。
• Windows 防火墙： 决定了“我准不准外客走到 Clash 面前”。

如果你开启了 Allow LAN，但防火墙里限制了 RemoteAddress 172.16.0.0/12，那么：

• WSL 的请求：防火墙准入 $\rightarrow$ Clash 愿意接待 $\rightarrow$ 成功代理。
• 同 Wi-Fi 舍友的请求：防火墙拦截 $\rightarrow$ 连 Clash 的面都见不到 $\rightarrow$ 无法蹭网。

2 Clash TUN模式

在 Windows 宿主机上，Clash（或 Meta）接管流量的方式通常有2种，它们的作用层级各不相同：

1. 第一种：系统代理模式（System Proxy）

这是最传统、最轻量的方法。

• 原理： 当你勾选“System Proxy”时，Clash 会告诉 Windows 操作系统：“请把所有的 HTTP/HTTPS 流量都发到 127.0.0.1:7890 这个端口。”
• 局限性： 这种方式只对尊重系统代理设置的软件有效（比如 Chrome、Edge、Spotify）。
• 流程：
  1. 浏览器发起请求。
  2. 浏览器检查系统设置，发现代理服务器是 127.0.0.1:7890。
  3. 浏览器把请求打包发给 Clash。
  4. 注意： 终端（CMD/PowerShell）默认不走这个代理，这就是为什么你常发现网页能开，但 git clone 却很慢。

2. 第二种：TUN 模式（虚拟网卡模式）

• 原理： Clash 会在 Windows 里创建一个虚拟网卡（类似 Tailscale会自动建立虚拟网卡一样）。
• 流程：
  1. Clash 修改系统的路由表，把所有原本要发往物理网卡（WLAN）的流量全都强行引流到这个虚拟网卡中。
  2. 所有的流量（不管是浏览器的、游戏客户端的、还是 ping 命令）都会先经过 Clash 核心。
  3. Clash 根据规则判断：
     • 如果是国内网站 $\rightarrow$ 直接发给物理网卡出去。
     • 如果是国外网站 $\rightarrow$ 加密后发给代理节点。
• 优势： 真正的“全局代理”，不需要软件手动设置，流量在网络层（IP 层）就被截获了。

3 wsl+clash 完整网络流程

整个往返流程串起来：

• 去程： WSL $\xrightarrow{7890}$ Clash (加密) $\xrightarrow{12345}$ 路由器 (NAT) $\xrightarrow{54321}$ 代理服务器
• 回程： 代理服务器 $\rightarrow$ 路由器 (NAT) $\xrightarrow{54321}$ 12345端口的Clash (解密) $\xrightarrow{7890}$ WSL