本文记录一台实际 Windows 11 主机的排障过程。它不是“所有 TUN 蓝屏都这样修”的万能答案；核心方法是：先读转储确认致错驱动，再只改与证据相符的一段网络链路。

结论先说

这次蓝屏并不是 Wintun 本体直接崩溃，也不是“Clash 不兼容 Windows”。两个 0xD1 minidump 都落在相同的收包路径：

rt640x64.sys (Realtek RTL8125B)
  → NDIS → tcpip / WFP → UDP → afd

rt640x64.sys 是 Realtek 2.5GbE 网卡驱动。TUN 模式会显著增加转发和 UDP 收包压力，从而触发该驱动路径中的非法内存访问。处理方式是保留 Clash、Wintun、VMware 和 Hyper-V 配置，只针对物理网卡关闭有问题的 UDP 卸载与节能特性，再重启网卡验证。

本次已实施的修复
关闭 UDP IPv4/IPv6 Checksum Offload、Green Ethernet、Gigabit Lite、Power Saving Mode、Selective Suspend；有线网络重新连通，DNS、ICMP、HTTPS 均通过复测，修改后没有产生新的 BugCheck。

说人话就是

代理开启TUN之后，网络流量变多、路径更复杂，尤其是 UDP 包。

此时的 Realtek 网卡驱动 rt640x64.sys 在 “接收网络数据” 时出了差错，把坏数据交给了 Windows 网络系统。Windows发现内核内存可能写坏，只能立刻蓝屏自保。

解决的方案：关闭了网卡里容易出问题的“硬件加速收包”和省电功能。

为什么这个方案能解决问题？

因为蓝屏发生在 Realtek 网卡“把收到的数据交给 Windows”的那一刻。

默认情况下，网卡会自己做一些加速工作：

  • UDP 校验和卸载：网卡硬件自己校验、标记数据包。
  • Green Ethernet / Gigabit Lite：为了省电，动态调整链路工作方式。
  • 选择性挂起：空闲时让网卡进入低功耗状态。

这些功能本身通常没问题，但 TUN 会让 UDP 转发、收包频率和网络路径更复杂。你的 Realtek 驱动在这种组合下疑似错误处理了网 卡提供的数据缓冲区，Windows 后续访问它时发现内存不对，于是蓝屏。

关闭后，关键变化是：

  • UDP 校验等工作交还给 Windows 网络栈处理；
  • 网卡不再频繁切换省电/性能状态；
  • Realtek 驱动走更保守、更简单的收包路径。

相当于原来让网卡“又收包、又加速、又省电”，现在让它只负责稳定收包。性能可能损失一点点、功耗稍高，但通常能换来稳定性。

1. 现象与环境

项目 实际情况
系统 Windows 11 Pro，Build 26200
代理 Clash Verge / verge-mihomo.exe，Windows 服务 clash_verge_service
TUN 驱动 Wintun 0.14，Microsoft WHCP 签名有效
物理网卡 Realtek Gaming 2.5GbE Family Controller（RTL8125B）
主板 MSI MAG B560M MORTAR（MS-7D17）
网卡驱动 rt640x64.sys，10.79.50.1003，文件时间 2025-10-03
现象 一开启或使用 TUN，就可能蓝屏并自动重启

系统在 2026-09-02 至 2026-09-03 留下了三份小型转储。两次是 0x000000D1（DRIVER_IRQL_NOT_LESS_OR_EQUAL）；另一次是 0x0000007F，其可用栈同样从 tcpip 开始，说明前面的内存破坏已经让后续转储难以完整展开。

Windows 事件日志中的三次蓝屏时间线与 BugCheck 代码
图 1：根据 System 事件 1001 与 Minidump 文件时间整理。三次崩溃都发生在 TUN 排障期间。

2. 不要只看蓝屏码：必须看 minidump

0xD1 的意思是某个驱动在过高 IRQL 下访问了无效或分页内存。它只能说明“内核驱动出错”，不能说明“就是代理驱动出错”。

先确认最近的转储和系统事件：

Get-ChildItem "$env:SystemRoot\Minidump" -Filter '*.dmp' |
  Sort-Object LastWriteTime -Descending |
  Select-Object Name, Length, LastWriteTime

Get-WinEvent -FilterHashtable @{
  LogName = 'System'; Id = 41, 1001, 6008
  StartTime = (Get-Date).AddDays(-30)
} | Sort-Object TimeCreated -Descending |
  Select-Object TimeCreated, Id, ProviderName, Message

然后用 WinDbg 打开转储，先执行：

!analyze -v
kv
lmvm rt640x64

这次最新的 0xD1 转储中，崩溃表面位置是 afd!memcpy，但不能把 afd.sys 当成元凶。继续往下看调用栈，能看到 rt640x64+0x104226 在 NdisMIndicateReceiveNetBufferLists 之后把一个有问题的收包链交给 NDIS；TCP/IP、WFP、UDP 与 AFD 只是之后才碰到已损坏的数据。

WinDbg 收包调用栈摘录，显示 rt640x64.sys 进入 NDIS、tcpip、WFP、UDP 和 AFD 路径
图 2：实际 WinDbg 输出的关键栈帧摘录。为阅读清晰转成静态终端图；地址和模块名保持原始输出。

第二份 0xD1 转储重复出现完全相同的关键段：rt640x64.sys → NDIS → tcpip/WFP → UDP。两份独立转储重复命中同一第三方驱动，才足以把排查重点从 Wintun 移到 Realtek 收包链。

3. 先做只读盘点，避免错误“修复”

Get-NetAdapter -IncludeHidden |
  Select-Object Name, InterfaceDescription, Status, LinkSpeed, DriverInformation

Get-NetAdapterBinding -Name 'Ethernet 2' |
  Where-Object Enabled |
  Select-Object DisplayName, ComponentID, Enabled

Get-NetAdapterAdvancedProperty -Name 'Ethernet 2' -AllProperties |
  Select-Object DisplayName, DisplayValue, RegistryKeyword, RegistryValue

本机还存在 VMware Bridge 和 Hyper-V 虚拟交换相关组件。它们确实让 NDIS 链更复杂，但没有出现在已确认的致错栈中。因此本轮不卸载 VMware、不关闭 Hyper-V、不执行 netsh winsock reset、也不删除 Wintun。网络重置常常会制造新变量，却不能修好底层网卡驱动已经提交的坏数据。

4. 最小化修复：关闭 Realtek 的高风险卸载与节能项

此次故障在 UDP 收包 / NDIS 指示路径中出现。关闭 UDP checksum offload 后，校验工作改由 Windows 网络栈完成，不再让 RTL8125B 的硬件卸载路径参与；关闭 Green Ethernet、Gigabit Lite、省电和选择性挂起，则避免链路省电状态在高频 TUN 流量时切换。

代价是极少量 CPU 占用和省电能力，换来稳定性。对于本机 1Gbps 实际链路，这是合理取舍；如果日后换了稳定驱动，可逐项恢复测试，而不要一次全部打开。

执行前注意
以下命令需要管理员 PowerShell，并会让有线网络短暂断开。请确认当前不是通过这台机器的远程桌面或 SSH 在操作；若是，先准备其他管理通道。

4.1 记录原设置

$adapter = 'Ethernet 2'   # 改成 Get-NetAdapter 显示的实际名称
Get-NetAdapterAdvancedProperty -Name $adapter -AllProperties |
  Select-Object DisplayName, DisplayValue, RegistryKeyword, RegistryValue |
  Format-Table -AutoSize

本次还导出了实际网卡的注册表配置。这个 0010 是当前机器的设备序号，不要照抄到其他电脑：

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\0010" `
  "$env:USERPROFILE\Desktop\Realtek-before-TUN-fix.reg" /y

4.2 应用修复并重启网卡

$adapter = 'Ethernet 2'   # 按本机实际名称修改
$properties = @(
  '*UDPChecksumOffloadIPv4', '*UDPChecksumOffloadIPv6',
  'EnableGreenEthernet', 'GigaLite', 'PowerSavingMode', '*SelectiveSuspend'
)

foreach ($property in $properties) {
  Set-NetAdapterAdvancedProperty -Name $adapter `
    -RegistryKeyword $property -RegistryValue '0' -NoRestart
}
Restart-NetAdapter -Name $adapter -Confirm:$false

不同厂商 INF 暴露的属性名不一定一致。若某一项报“找不到”，不要凭猜测改注册表；用前面的 Get-NetAdapterAdvancedProperty -AllProperties 查到对应的 RegistryKeyword 后，只处理与实际显示项一致的项目。

修复后 Realtek 网卡高级属性已禁用，并且 1.1.1.1、DNS 和 HTTPS 连通的检查结果
图 3：修复后实测。网卡保持 Up / 1Gbps，UDP 卸载和节能项目均为 Disabled，HTTPS 连接成功。

5. 验证不是“命令执行成功”，而是数据路径真的恢复

Get-NetAdapter -Name 'Ethernet 2' |
  Select-Object Name, Status, LinkSpeed, DriverInformation
Test-Connection 1.1.1.1 -Count 3
Test-NetConnection www.cloudflare.com -Port 443 -InformationLevel Detailed
Get-WinEvent -FilterHashtable @{
  LogName = 'System'; Id = 1001; StartTime = (Get-Date).AddMinutes(-10)
} | Select-Object TimeCreated, Message
检查项 结果
物理链路 Ethernet 2 为 Up，协商 1Gbps
IP 连通性 1.1.1.1 三次响应约 2–3ms
DNS + TLS www.cloudflare.com:443 解析成功、TCP 成功
新 BugCheck 网卡重启及检查期间没有新的事件 1001

接着重新打开 Clash Verge 的 TUN，并做一段持续的真实流量测试，例如网页浏览、视频、下载或代理 UDP 流量。只有 TUN 已经连续运行一段时间且没有新增 BugCheck 1001 / minidump，才能说这个修复在自己的环境中成立。

6. 如果仍然蓝屏，按这个顺序继续

  1. 先保留新转储。 不要立刻网络重置或卸载一堆软件；先复制 C:\Windows\Minidump\*.dmp，用 WinDbg 对比新的 kv 栈。
  2. 检查是否仍是 rt640x64.sys。 若仍是，优先从 MSI 主板支持页或 Realtek 官方渠道安装 / 回退 RTL8125B 驱动，然后每次只改变一个变量。
  3. 临时解除 VMware Bridge 对物理网卡的绑定再测。 这会影响虚拟机的桥接网络，所以只在不使用桥接 VM 时做，且不应作为第一步。
  4. 只在转储指向 Wintun 或代理过滤驱动时，才重装 Clash / Wintun。 本次证据并不支持把 Wintun 当作首要元凶。
  5. 不要用 Driver Verifier 作为随手的“修复工具”。 它适合在可恢复环境中逼出有问题的第三方驱动，配置错误反而会让系统难以启动。

7. 回滚方法

如果关闭卸载后产生了明确的性能回退，可从导出的 .reg 备份恢复，或在“设备管理器 → 网络适配器 → Realtek → 高级”中把项目改回原值。推荐一次只恢复一个项目，每次都在 TUN 真实流量下观察。

Get-NetAdapterAdvancedProperty -Name 'Ethernet 2' -AllProperties |
  Where-Object RegistryKeyword -in @('*UDPChecksumOffloadIPv4', '*UDPChecksumOffloadIPv6')

复盘：这次排障真正解决了什么

TUN 开启后 UDP / 转发负载上升
        ↓
RTL8125B 驱动 rt640x64.sys 在 NDIS 收包路径出错
        ↓
tcpip / WFP / UDP / AFD 接到损坏的网络缓冲链
        ↓
0xD1 蓝屏
        ↓
关闭硬件 UDP 卸载与节能状态切换，保留其余网络配置
        ↓
链路、DNS、HTTPS 恢复；进入 TUN 稳定性观察期

以后遇到“某个软件一开就蓝屏”，最有价值的不是猜软件冲突，而是问：转储里第一个可疑的第三方内核模块是谁，它是否在多份独立转储中重复出现？