为什么路由器上 mihomo 配置为 stack: system 时， WSL2 间歇性无法通过代理上网？

[Danswerme]

mihomo 配置

• tun: enable
• stack: system
• mihomo 代理模式: 非大陆 IP 都走代理
• WSL 网络: NAT

网络故障现象

• 宿主机 Windows 可以正常通过代理访问国外网站
• 宿主机上部署的 WSL2 间歇性无法访问国外网站，国内网站正常访问

抓包日志

• 路由器防火墙内可以看到 WSL2 发出的包一直处于syn sent状态
• 通过 tcpdump 抓包，可以看到 mihomo 收到了 WSL2 的请求，也通过 tun 转发了 syn ，但是没有 ack 回包

解决方案

和 ChatGPT 沟通后，它建议我将 mihomo 配置中的 stack 由 system 切换到 gvisor ，修改此配置后，WSL2 网络故障恢复正常。

疑问

ChatGPT 告诉我， stack: system 模式下，mihomo 依赖操作系统内核维护 TCP 连接上下文，所以请求来自 WSL2 （经过 Windows 的 NAT ）时，在某些情况下，系统内核会丢弃回包，导致 WSL2 无法通过代理上网。

而 gVisor 是用户态协议栈，自己维护连接状态、重发机制、窗口大小、NAT 表等，所以它能正常处理来自 WSL2 的请求。

我的疑问：WSL2 的 NAT 状态是由宿主机 Windows 维护的，对于 mihomo 来说，无论是 WSL2 还是宿主机的请求，来源地址都是宿主机的 IP ， 为什么 mihomo 会出现无法正常处理 WSL2 回包的情况？

恳请对这一现象了解的 V 友能够解答一二。

[Thymolblue]

同样的问题，前几个月在内核更新到 0.46.110 后解决了。感觉 OpenClash 并不会完全执行配置文件的内容，有一些自动的 override 导致配置异常。另外我通过 Android 手机开启 Clash Meta For Android ，再通过热点做透明代理，即使使用旧内核 WSL 也不会有网络问题。

[fengyaochen]

openclash 越更新越烂，现在还不如 passwall 好用

[Danswerme]

@Thymolblue
@fengyaochen 我没使用 openclash ，用的 mihomo 裸核 + webUI ，我待会更新下 mihomo 内核版本试试。

[anbabubabiluya]

其实就是兼容性问题吧，非 gvisor 堆栈 ipv6 还有问题呢，官方文档默认也是 gvisor

[Danswerme]

@anbabubabiluya 那我就继续使用 gvisor 吧，虽然有人说 gvisor 性能略低，但是在 x86 力大砖飞的情况下也不成问题。

[MYDB]

@fengyaochen 哪里烂？有问题要么提 issue ，要么提 pr ，不会根据自己需求配置，纯伸手当然烂了

[fengyaochen]

@MYDB 老版本能用就行了，等不能用了再说

[daisyfloor]

这个问题折腾了我几个月，你遇到的问题大概和我一样，我做个总结吧。

最不折腾的是终极解决办法是：

Clash 的 TUN 模式+wsl2 的镜像网络模式 networkingMode=mirrored ，并且还要进行 2 个设置：
- Clash 的 TUN 配置中，mtu 要设置，数值<=1500,否则会出现网络缓慢或者时好时坏不能用的状况；
- Clash 的 TUN 配置中，启用严格路由：strict-route: true ，避免 DNS 泄露

这样配置后，在可靠的 TUN 网络下，wsl2 自己（如 apt update 或者 curl ）和 docker 引擎（如镜像拉取，容器网络请求）都可以正常无感知使用代理。

[daisyfloor]

@daisyfloor 补充下 8#的回复，我的 tun 用的是 stack: mixed