先验证基础代理链路，再检查 TUN 权限、路由和解析。一次只改变一个设置，并保留原始网络状态。
建立一个能解释结果的对照
先保存当前配置，在自己的设备上关闭 TUN，用浏览器通过系统代理访问一个稳定站点。如果系统代理也失败，先处理内核、配置或节点；如果它正常，而 TUN 开启后才失败，排查重点才是虚拟网卡与接管链路。
再说明症状范围：是 TUN 无法开启、开启立即断网，还是浏览器正常而某个应用仍直连。记录当前操作系统、客户端和内核版本，以及是否同时使用其他 VPN。不同症状对应不同层级，不能都用更换协议栈解决。诊断期间不同时启用多种新的网络工具。
确认内核具备所需权限
Windows 上若日志提示服务异常或内核未通过安全检查，先看当前运行方式。官方常见问题 说明，普通用户权限下的 Sidecar 运行方式无法使用 TUN；服务模式会检查内核和安装路径的权限。开关无法保持启用时，应先解决运行权限，而不是修改 DNS。
使用官方安装包及推荐位置，按该版本官方说明修复服务。若设备受组织管理，请让管理员检查权限。不要给所有用户完全控制权限，也不要跳过服务的安全检查。其他平台同样需要对应的网络管理权限，安装和服务步骤应使用该平台文档。
检查流量入口和出口网卡
TUN 启用后，访问目标并观察连接记录。没有记录时，检查实际生效配置中的 TUN 路由设置与排除范围；有记录但连接失败时，进一步检查出口。Mihomo 的 auto-route 用于自动添加接管路由，auto-detect-interface 用于选择出口网卡，其效果仍取决于设备网络环境。
无线、有线、虚拟机和 VPN 网卡同时存在时，自动选择的出口可能不符合预期。先记录哪些网卡正在使用，暂时退出自己启用的其他 VPN 后复测。不要随意删除虚拟网卡，它可能由虚拟机或工作网络使用；需要手动指定出口时，核对文档和接口名称。
把 DNS 问题与接管问题分开
如果流量进入了 TUN，但日志大量出现域名解析失败，应转向 DNS 配置。Mihomo 的 dns-hijack 可把匹配的 DNS 请求交给内部解析模块，但不能假定所有系统和应用的解析都遵循同一路径。浏览器自带的加密 DNS 也可能改变解析路径。
检查 DNS 上游是否可达、内网域名是否有专用解析策略，以及规则是否把内网请求送往外部节点。不要从网上整段复制 DNS 模板覆盖原配置。若仅一个应用失败，先记录该应用的代理与解析行为，再考虑按需调整；不要把局部故障当成全机 TUN 故障。
小范围验证后决定保留哪种方式
恢复后依次验证浏览器、一个原本不遵循系统代理的应用和需要使用的内网资源。确认连接记录符合预期，再重启客户端复测。若这些场景都稳定，停止继续更换栈、MTU 或严格路由选项。内核文档的可选值会随版本变化，应核对当前版本，保留默认参数作为起点。
若无法定位，回到已验证可用的接入方式，整理 TUN 开关前后的日志差异、网卡情况和最小复现步骤。出现服务权限错误时读启动服务排查；出现解析失败时读 DNS 排查。提交材料前删除订阅令牌、节点密码和内网敏感域名。
相关问题
开启 TUN 就能让所有软件走代理吗？
是否接管取决于路由、排除设置、平台行为以及其他网络工具。即使请求进入内核，规则也可能选择直连，因此要看连接记录。
应该一直使用哪一种 TUN 栈？
没有适用于所有版本和设备的固定答案。优先采用当前客户端推荐配置，只有可复现的兼容问题才做单变量对照。
资料与适用范围
本文以原创步骤解释操作思路，不声称已经在所有设备和版本上实测。菜单名称、默认值与兼容条件可能随版本变化，请结合当前项目说明核对。
需要修正内容？请阅读反馈与纠错，不要公开完整订阅或账户凭据。
