本文目录
系统代理等应用主动交流量，TUN 在系统网络层接住流量
开启系统代理时，Clash 把本地代理地址写进操作系统，愿意读取这项设置的应用再把 HTTP、HTTPS 请求发到该端口。浏览器通常会使用它，终端工具、游戏和部分桌面应用可能不使用；系统代理本身也不能统一接管 UDP。
TUN 创建虚拟网卡，通过系统路由让更多 TCP、UDP 连接进入 Mihomo。它解决“这个进程没有走本地代理端口”的问题，但不会改变节点可用性、规则顺序或服务端返回的 403。
两种入口的核心差别
| 项目 | 系统代理 | TUN |
|---|---|---|
| 谁决定进入 Clash | 应用是否读取系统设置 | 系统路由与虚拟网卡 |
| UDP | 通常不接管 | 可以进入 TUN，仍取决于节点和配置 |
| 系统权限 | 修改代理设置 | 还需虚拟网卡、服务或网络扩展权限 |
| 回退 | 关闭代理开关即可 | 关闭 TUN，并等待路由和接口撤回 |
- 应用发起连接浏览器、终端、游戏或后台服务
- 系统代理或 TUN决定这条流量能否进入内核
- 规则与 DNS保留域名并决定直连或代理
- 实际出口DIRECT、代理节点或拒绝
入口只负责接住流量。真正走哪个出口，仍由规则、DNS 结果和策略组共同决定。
判断入口，只看原来失败的程序有没有连接记录
用同一动作做前后对照
固定 Profile、Rule 模式和节点
避免入口测试被自动切换或配置更新干扰。
只开系统代理
在目标程序里重复一个固定动作。
查看 Connections
若请求已经出现，入口没有缺失，继续读规则和日志。
无记录时再开 TUN
重做同一动作，比较是否出现新连接。
TUN 后新连接出现并成功，说明它补上了接管范围。两种入口下都能看到请求，却同样 timeout，问题应放在节点、DNS 或目标网络，而不是继续切换入口。
auto-route、interface 和 stack 共同决定数据怎么穿过虚拟网卡
Mihomo 的 auto-route 用来把流量路由到 TUN，auto-detect-interface 用来识别真实出口网卡。stack 可选 system、gvisor 或 mixed 等实现；默认值能覆盖目标应用时，不需要为了“更快”随意更换。
从 Wi-Fi 切到热点后突然没网，可能是出口网卡变化；只有 system 或 mixed 在某台电脑被防火墙拦，才针对内核进程调整防火墙。Windows 的 strict-route 还可能影响 VirtualBox 等虚拟网络，使用虚拟机时要单独验证。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53DNS 覆写要把解析请求送进同一条判断路径
应用先把域名解析成地址，再建立连接。如果 DNS 请求绕过 Mihomo，内核可能只看到 IP，域名规则无法按预期工作；也可能得到与代理出口不匹配的解析结果，表现为首页能开、图片失败或同一服务时好时坏。
dns-hijack 用来把匹配的 DNS 流量交给 Mihomo 内部 DNS。它并非在所有系统和所有来源上自动生效：Windows、macOS 无法自动劫持局域网其他设备的 DNS，请求来自路由器或手机时要单独配置；Android 私人 DNS也会绕过普通劫持路径。
- Connections 有域名且规则正确
- DNS 与嗅探至少提供了可用于规则判断的信息。
- 只看到 IP，域名规则不命中
- 检查 DNS 是否进入 Mihomo，以及应用是否使用加密 DNS。
- IP 能访问，域名报解析错误
- 重点比较系统 DNS、Mihomo DNS 和当前网络。
Fake-IP 的作用是保留域名关系，不是凭空加速
在 fake-ip 模式下，Mihomo 先向应用返回一段保留地址，并在内部保存“这个假地址对应哪个域名”。应用连接该地址时，内核可以恢复原域名，较早做 DOMAIN、DOMAIN-SUFFIX 和 RULE-SET 判断。
这种方式不会让 DNS 自动变快，也不会改变远程节点质量。某些局域网服务、设备发现、企业软件或直接校验 IP 的程序可能不兼容，需要按具体域名加入 fake-ip-filter，或在验证后选择其他 DNS 增强模式。
Fake-IP 常见结果
| 表现 | 解释 |
|---|---|
| 系统查询得到保留地址 | 可能是正常的 fake-ip 映射，不代表域名被劫持 |
| Connections 能显示原域名 | 映射帮助内核按域名规则判断 |
| 某个内网域名在 fake-ip 下失败 | 把准确域名排除并让内部 DNS 解析 |
| 所有网站都慢 | 不能仅凭 fake-ip 下结论，继续看节点、DNS 上游和日志 |
需要真实 IP 的应用，用 redir-host 或准确的 Fake-IP 例外
有些企业软件、局域网服务或设备发现功能会直接使用 DNS 返回的真实地址，不适合拿到 Fake-IP。此时可以让整份配置使用 redir-host，也可以只把明确不兼容的域名加入 fake-ip-filter；前者改变所有域名的解析方式，后者影响范围更小。
redir-host 更接近普通 DNS，应用直接拿到上游返回的真实 IP；代价是 Mihomo 不一定像 Fake-IP 那样早地保留域名映射，域名规则识别还会受客户端、缓存与嗅探设置影响。不要因为一个内网域名失败就把全站切换，先做单域名例外。
需要真实 IP 时怎么选
| 场景 | 更合适的处理 | 验证结果 |
|---|---|---|
| 只有一个企业内网域名失败 | 加入准确的 fake-ip-filter，并使用内部 DNS | 返回内网真实 IP，连接命中 DIRECT |
| 一类应用普遍不兼容 Fake-IP | 用 redir-host 做单独配置对照 | 应用恢复，公网域名规则仍能正确命中 |
| NAS、打印机使用固定私有 IP | 保留私有网段 DIRECT | 访问不再绕到代理策略 |
| 不知道哪个域名不兼容 | 先从 Connections 与 DNS 日志找目标 | 确认对象后再加例外，不使用大范围通配 |
DNS 排查需要保留一个不变的请求
遇到域名问题，固定节点和请求，先记录当前 enhanced-mode、上游 DNS 与错误。只改一个变量做对照：例如把某个明确不兼容的内部域名加入 fake-ip-filter，或临时切换 Android 私人 DNS 状态。结果有变化，再保留这项改动。
no such host / DNS lookup failed
检查上游 DNS 可达性和请求是否进入 Mihomo。
局域网域名失效，公网域名正常
保留内部 DNS 路径，并为准确域名设置直连或 Fake-IP 排除。
切网络后才解析异常
比较两张网络的 DNS、IPv6 和出口接口，不要先换所有节点。
域名规则始终显示 MATCH
查看内核是否拿到域名，以及更宽规则是否提前命中。
浏览器用户从系统代理开始，需要 UDP 或补漏再用 TUN
按使用场景选择
| 使用场景 | 建议起点 | 理由 |
|---|---|---|
| 主要是网页和遵循系统代理的桌面软件 | 系统代理 | 权限少、容易关闭、连接路径清楚 |
| 终端、游戏启动器没有 Connections 记录 | 应用代理或 TUN 对照 | 补上不读取系统代理的进程 |
| 需要处理 UDP 的应用 | TUN | 系统代理无法统一接管 UDP |
| 企业内网、虚拟机和复杂局域网 | 系统代理起步 | 先保留原路由，再逐项验证 TUN 排除范围 |
| 某域名规则走错 | 任一已有入口 + 修规则 | 入口扩大不会改变第一条命中规则 |
选择不是永久的。日常只需浏览器时可以关闭 TUN，回到系统代理；需要特定程序时再开启。切换后都用原目标动作和 Connections 验证，而不是只看开关颜色。
断网时按 TUN、DNS、系统代理的顺序撤回
若刚开 TUN 就全断，先关闭 TUN，保留原 Profile 与节点。系统代理恢复，说明故障在虚拟网卡、路由或 TUN 的 DNS；系统代理也失败，再回到节点和配置。不要直接使用操作系统的网络重置，它会清掉更多无关设置。
若关闭客户端后网页仍打不开，检查系统代理是否残留在 127.0.0.1 的旧端口。清掉残留后应恢复直连。选择可以落到实际结果上：系统代理负责浏览器，TUN 接住原来漏掉的进程，DNS 模式让目标域名稳定命中预期规则。哪一层没有带来需要的结果，就不要长期保留。