TUN 路由环路的本质，是客户端发往代理服务器的连接，又被系统送回客户端自身。连接不断重复进入相同处理链，可能表现为网络突然不可用、连接数量异常或资源占用上升。修复要区分被代理的业务流量与客户端自己的出站流量。
先认识两条不同的路径
应用流量进入虚拟接口后，由客户端选择出口，再经真实网卡连接代理或目标。虚拟接口负责接收需要处理的流量，物理接口负责真正发送。若第二步又被默认路由送进第一步，就没有形成通向外部网络的完整路径。
接管默认路由并非必然产生环路。成熟实现会通过接口选择、路由排除、标记或平台机制区分自身连接。问题常发生在手动规则与自动规则叠加、同时启用多个 VPN、接口切换后选择失效，或从旧配置迁移时保留了不适用的设置。
核验时的 mihomo TUN 文档提供自动路由以及接口相关能力，但具体可用项受平台与版本影响。不能把另一系统上的完整配置直接复制过来，也不能只根据“支持 TUN”推断其自动排除策略完全一致。
环路的线索与其他故障不同
环路可能导致反复出现相同节点地址、连接建立次数快速增长，或者启用虚拟接口后立即失联。普通 DNS 错误则可能停在解析阶段，证书错误发生在安全连接验证阶段。先观察日志停在哪个环节，比不断更换节点更有价值。
需要注意，资源占用高并不独有于环路，大量下载、规则加载和日志输出也会造成类似现象。只有结合路由与重复连接证据，才应把环路列为重点假设。不要根据任务管理器的一张截图就认定原因。
示例情境中，电脑原来使用无线网络，后来接入有线网络，但客户端仍绑定已失效的接口。此时表现可能是出站失败，而不是严格意义的环路。检查真实默认出口与客户端选择是否一致，能够避免用错误标签指导修复。
建立可撤销的检查顺序
先保存日志和配置，确认有本地管理能力，再暂时停止虚拟接口接管，检查基础网络是否恢复。若基础网络仍失败，就应先处理接入问题。若停止接管后立即恢复，说明故障与接管配置有关，但还不能确定是哪条路由导致。
接着只启动一个负责接管的客户端，暂停其他 VPN 或同类工具进行对照。涉及企业设备时应按组织规则操作，不擅自关闭必要安全组件。记录实际运行的进程与虚拟网卡名称，避免只关闭界面却保留后台服务。
然后核对系统默认出口、客户端接口选择和代理节点地址的可达路径。优先采用当前版本支持的自动机制，不要先手工添加大量永久路由。手工规则如果必须存在，应写明目标、作用和删除方法，并保证在退出客户端后不会破坏基础网络。
排除范围必须足够精确
代理节点的连接需要避开自身接管，但这不等于把所有外网地址都排除。过宽的排除会让本应处理的业务直接出去，表面上恢复访问，实际分流要求却失效。因此修复后必须检查普通业务仍然进入客户端。
节点使用域名时，地址可能变化。一次性排除某个解析结果，可能只在当前有效。应查明客户端是否支持对自身出站选择接口或其他稳定机制，而不是依靠不断手动更新地址。还要考虑一个域名存在多个地址的情况。
局域网排除是另一类需求。保留打印机、路由器管理入口和本地存储的可达性，能为故障恢复留下通道，但它不是修复公网节点环路的替代方案。两种规则应分开注释，方便日后审查。
验证不能只看图标变绿
恢复以后，观察新连接是否完成，是否仍有重复进入，资源使用是否趋于稳定。依次测试本地资源、直连业务和代理业务，确认修改没有绕过原本策略。对于双栈网络，另一地址族也需要单独检查。
再做一次受控网络切换或客户端重启，确认自动路由可以重新建立。若只能在特定启动顺序下工作，就应记录先后依赖，继续查找问题，而不能认为已经彻底解决。退出客户端后基础网络也应正常，这是回退能力的重要部分。
准备反馈时，保留路由摘要、虚拟接口名称、内核版本和异常时间，隐藏节点凭证及订阅。只提供必要的目标地址与重复连接片段，不上传包含所有访问记录的完整日志。这样既方便定位，也减少无关信息。
如果节点域名解析自身存在循环，阅读加密解析引导；如果另一地址族仍异常，使用双栈验证清单。路由环路排查的重点始终是证明出口真正离开了入口，而不是让所有流量都绕开客户端。
远程维护时尤其需要谨慎。若当前管理会话本身依赖待修改的客户端，关闭接管可能立即失去控制。应先安排本地人员或另一条已验证的管理通道，再进行变更；只有口头承诺可以恢复，却没有可执行入口，不算具备回退条件。
参考资料
- mihomo TUN 配置，核验日期：2026-10-15。
- sing-box 路由配置，核验日期：2026-10-15。