TUN 模式在干什么#

普通代理模式（系统代理 / HTTP 代理）只接管明确配置了走代理的应用。TUN 模式不一样 —— 它在系统里创建一张虚拟网卡，然后把默认路由抢过来：

1
正常状态：
2
  0.0.0.0/0  →  192.168.1.1  via  WLAN      (metric 25)  ✓ 生效
3
  0.0.0.0/0  →  10.0.0.1     via  Clash-TUN (metric 5)   ✗ 被压制
4

5
TUN 启动后：
6
  0.0.0.0/0  →  10.0.0.1     via  Clash-TUN (metric 5)   ✓ 现在生效
7
  0.0.0.0/0  →  192.168.1.1  via  WLAN      (metric 25)  ✗ 还在表里，但不承载流量

Windows 同时只会用一条默认路由（多条时按 metric 取最小）。TUN 的目标就是把这条唯一的名额抢走，这样才能做到”全局代理”。

但图书馆的 WLAN 有一个特殊之处#

家里的 Wi-Fi 连上就是通的。学校图书馆的 WLAN 不是 —— 它通常要过 802.1X（企业级认证） 或 Portal（网页认证）。这个过程有几个硬性要求：

问题的本质：“物理上关联成功”和”能上网”之间，还隔着一个必须依赖默认路由的认证阶段。 而 TUN 恰好在这个阶段把默认路由拿走了。

具体的死法有几种，通常几个一起#

把上面压缩成一句话：

TUN 模式假设”你已经能上网了”。而图书馆的 WLAN 假设”你还没认证完”。两个假设互相打架。

还有一个更隐蔽的：DNS 死锁。TUN 模式通常会把 DNS 也劫持到隧道内的公共 DNS（1.1.1.1 / 8.8.8.8）。而隧道要建连，得先能解析出口服务器的域名 —— 解析请求被送进一个还没建好的隧道。配置不讲究的客户端就会一直卡在这里反复重试。

WARNING

成熟客户端一般会维护一份 bypass 列表，把出口服务器 IP 和内网网段排除在隧道之外，避免自噬。这份列表配得好不好，直接决定你会不会遇到”自己把自己套进去”。

坑 1：默认 72 小时后任务被杀掉#

是真的。

Task Scheduler 的 ExecutionTimeLimit（“如果任务运行时间超过此时间，则停止任务”）默认值是 PT72H，也就是 72 小时。文档里的原话是”如果未指定该值，默认使用 72 小时”。

一个开机常驻的任务 —— 比如 VPN 客户端 —— 跑满三天就会被系统主动干掉，而且：

• 日志里只记一句”任务因超出时间限制而终止（任务已完成）”
• 不会弹任何提示
• 你不会意识到是计划任务干的

改法：PT0S = 不限时。

1
<ExecutionTimeLimit>PT0S</ExecutionTimeLimit>

坑 2：拔电源会停任务#

也是真的，而且是两个独立的开关。

任务计划程序创建任务时，GUI 里默认勾着「如果计算机使用电池电源，则停止任务」。这个勾选会写出两个 XML 节点：

1
<DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>  <!-- 电池上干脆不启动 -->
2
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>          <!-- 运行中拔电就杀掉 -->

两个默认都是 true。表现是：笔记本拔掉电源线的那一瞬间，VPN 客户端进程被计划任务管理器直接结束。

改法：两个都置 false。

1
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
2
<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>

等价的 cmdlet 写法：

1
New-ScheduledTaskSettingsSet `
2
  -ExecutionTimeLimit ([TimeSpan]::Zero) `
3
  -AllowStartIfOnBatteries `
4
  -DontStopIfGoingOnBatteries `
5
  -MultipleInstances IgnoreNew

TIP

我本机这个任务的 XML 里这两个坑都已经改过来了（PT0S + 两个 false）。所以如果你现在遇到的是我之前那个症状 —— 图书馆连不上网但别的地方正常 —— 那就不是这两个默认值的问题，回到第一节的路由抢占去看。

顺带第三个坑：IdleSettings#

有些任务里还会看到这一段：

1
<IdleSettings>
2
  <Duration>PT10M</Duration>
3
  <WaitTimeout>PT1H</WaitTimeout>
4
  <StopOnIdleEnd>true</StopOnIdleEnd>
5
  <RestartOnIdle>false</RestartOnIdle>
6
</IdleSettings>

它的含义是「仅当计算机空闲至少 10 分钟时才启动任务」，加上「一旦不空闲就停止」。只有 <RunOnlyIfIdle>true</RunOnlyIfIdle> 时才生效 —— 默认是 false，所以一般无害。

但如果你哪天在 GUI 里手滑勾上了「仅当计算机空闲时才启动任务」，拔电源断网这种玄学问题就又能重现了。

它不只对 Wi-Fi 触发#

EventID 10000 是任何网络配置建立都会触发，包括：

• 有线网
• 手机 USB 网络共享
• VPN 自己那张虚拟网卡重连
• Docker / WSL2 虚拟交换机

所以完全可能出现”VPN 自己断了 → 触发 10000 → 计划任务又去启动 VPN → 反复重启”。

想严格只认 Wi-Fi，把动作改成调一个脚本做判断：

1
$wifi = Get-NetAdapter | Where-Object { $_.Status -eq 'Up' -and $_.NdisPhysicalMedium -eq 9 }
2
if ($wifi) { Start-Process 'C:\Program Files\YourVPN\YourVPN.exe' }

NdisPhysicalMedium -eq 9 就是 Native 802.11。

事件日志通道必须处于启用状态#

Microsoft-Windows-NetworkProfile/Operational 默认是开的。但如果被组策略关掉或者日志被清空过，触发器会静默失效 —— 任务状态显示 Ready，永远不触发，也没有任何错误提示。

验证：

1
wevtutil gl Microsoft-Windows-NetworkProfile/Operational | Select-String enabled