Clash Verge Rev 开启 TUN 后 WSL2 请求阻塞怎么排查

WSL2 使用 mirrored 镜像网络时，Clash Verge Rev 开启 TUN 后，可能出现第一次网页请求成功、后续请求一直等待的情况。相关反馈中，TUN 设置界面已经显示 MTU 为 1500，但用户称在 Merge 中再次写入同一数值后恢复。这个现象需要比较最终配置，不能只凭界面数值认定参数未生效。

涉及环境

原报告未验证 AutoBuild，也没有提供异常与恢复时的完整配置对照。因此不能推断所有 WSL2 环境或最新稳定版都有相同问题。

第一步：固定测试条件

记录客户端与 WSL 版本、当前订阅、TUN 协议栈和 MTU。先保存正在运行的 WSL 任务，避免排查过程中重启或网络切换中断工作。

在 WSL 终端对同一可访问目标连续执行几次有限时请求，例如：

curl --max-time 15 -I https://www.microsoft.com/

HTTP 响应说明本次请求已完成；超时只说明在 15 秒内未完成，不能单凭超时定位到 MTU。分别记录 TUN 开启与关闭时的结果，并确认 Windows 宿主机访问同一目标是否正常。关闭 TUN 后，WSL 是否仍经过代理取决于其自身代理环境，比较时也要记录这一差异。

第二步：核对实际运行配置

进入“订阅”，打开“查看运行时订阅”，检查最终 tun 段，重点记录 mtu、stack、auto-route 等值。界面显示值、保存到文件的值以及内核实际使用的值，需要分别核对。

若异常时最终配置已经是 mtu: 1500，不要直接认定再次写入 1500 就能修复。保存扩展还可能触发配置重新生成与加载，现有反馈没有把这些因素分开。

服务模式用户还应保留对应服务内核的加载日志，确认查看的是当前生效订阅，而非旧文件。反馈时只提供相关脱敏字段，不上传完整订阅或节点认证信息。

第三步：需要时做最小覆写对照

确认已备份扩展配置后，可按原反馈做一次对照。进入目标订阅的“扩展覆写配置”，在现有 tun 对象中补充：

tun:
  mtu: 1500

已有 tun 时只合并 mtu 子字段，不新建第二个同名顶层键，也不覆盖原来的整个扩展。保存并重新应用订阅后，再检查最终运行配置中的值。具体入口见Merge 覆写教程 。

保持节点、协议栈和网络模式不变，重复第一步的连续请求。记录“配置值是否变化”“是否发生重新加载”和“请求是否恢复”。该步骤是对照检查，不保证恢复；如果值没有变化但连接恢复，也不能仅凭这一结果证明根因就是 MTU。

无改善时如何撤回

恢复之前备份的扩展；原来为空则恢复为空对象 {}。重新应用订阅，核对运行配置，再将 TUN 恢复为排查前的状态。

维护者曾建议比较其他 TUN 协议栈或 WSL NAT 模式，但讨论中没有证明这些建议解决了原报告。应先完成当前配置的取证；需要比较时一次只改一项，并保留原配置以便恢复。不要同时更换内核、升级预览版 WSL、修改网络模式和 DNS，否则无法判断结果来自哪一步。

当前进展

截至 2026 年 11 月 15 日，该问题已关闭，但未给出针对这一路径的已确认稳定版修复。另一名用户表示其 2.5.8 环境中界面 MTU 能进入运行配置，这与原报告的恢复反馈并不等价，也不能替代故障现场的配置对照。

继续复现时，按日志导出教程 保留异常与恢复时段的记录。若 Windows 宿主机本身也断网，可另按TUN 网络排查 检查。

参考：Issue #8265 、Mihomo TUN 参数 。