本文目录
浏览器正常、终端却没有连接记录，和请求已经出现、域名规则却不生效，需要改的不是同一项设置。前者看流量如何进入客户端，后者核对实际域名、解析结果与规则；节点或服务本身失败也不能靠扩大接管解决。分清这些情况，才知道何时用虚拟网卡、何时只为一个内部域名设例外。
系统代理与 TUN 怎样接管应用流量？
开启系统代理时，Clash 把本地代理地址写进操作系统，愿意读取这项设置的应用再把 HTTP、HTTPS 请求发到该端口。浏览器通常会使用它，终端工具、游戏和部分桌面应用可能不使用；系统代理本身也不能统一接管 UDP。
TUN 创建虚拟网卡，通过系统路由让更多 TCP、UDP 连接进入 Mihomo。它解决“这个进程没有走本地代理端口”的问题，但不会改变节点可用性、规则顺序或服务端返回的 403。
两种入口的核心差别
| 项目 | 系统代理 | TUN |
|---|---|---|
| 谁决定进入 Clash | 应用是否读取系统设置 | 系统路由与虚拟网卡 |
| UDP | 通常不接管 | 可以进入 TUN，仍取决于节点和配置 |
| 系统权限 | 修改代理设置 | 还需虚拟网卡、服务或网络扩展权限 |
| 回退 | 关闭代理开关即可 | 关闭 TUN，并等待路由和接口撤回 |
- 应用发起连接浏览器、终端、游戏或后台服务
- 系统代理或 TUN决定这条流量能否进入内核
- 规则与 DNS保留域名并决定直连或代理
- 实际出口DIRECT、代理节点或拒绝
系统代理或 TUN 负责把流量送入内核，之后走直连还是代理节点，仍由规则、DNS 结果和策略组共同决定。
用 Connections 判断应用是否需要 TUN
用同一动作做前后对照
固定 Profile、Rule 模式和节点
避免入口测试被自动切换或配置更新干扰。
只开系统代理
在目标程序里重复一个固定动作。
查看 Connections
若请求已经出现，说明它已进入客户端，继续查看规则和日志。
无记录时再开 TUN
重做同一动作，比较是否出现新连接。
TUN 后新连接出现并成功，说明它补上了接管范围。两种入口下都能看到请求，却同样 timeout，问题应放在节点、DNS 或目标网络，而不是继续切换入口。
auto-route、出口网卡与 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:53域名规则失效时，检查 DNS 是否进入 Mihomo
DNS 把域名转换成连接使用的地址。如果解析请求绕过 Mihomo，内核可能只看到 IP，无法按预期匹配域名规则；解析结果也可能与代理出口不一致，导致首页能开、图片失败或连接时好时坏。
dns-hijack 把匹配的 DNS 流量交给 Mihomo 内部 DNS，但并非在所有系统上自动生效：Windows、macOS 无法自动劫持发往局域网 DNS 服务器的查询，要核对实际系统 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 上游和日志 |
redir-host 与单域名 fake-ip-filter 例外
有些企业软件、局域网服务或设备发现功能会直接使用 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 与企业内网分别适合哪种方式？
按使用场景选择
| 使用场景 | 建议起点 | 理由 |
|---|---|---|
| 主要是网页和遵循系统代理的桌面软件 | 系统代理 | 权限少、容易关闭、连接路径清楚 |
| 终端、游戏启动器没有 Connections 记录 | 应用代理或 TUN 对照 | 补上不读取系统代理的进程 |
| 需要处理 UDP 的应用 | TUN | 系统代理无法统一接管 UDP |
| 企业内网、虚拟机和复杂局域网 | 系统代理起步 | 先保留原路由，再逐项验证 TUN 排除范围 |
| 某域名规则走错 | 任一已有入口 + 修规则 | 入口扩大不会改变第一条命中规则 |
选择不是永久的。日常只需浏览器时可以关闭 TUN，回到系统代理；需要特定程序时再开启。切换后都用原目标动作和 Connections 验证，而不是只看开关颜色。
关闭 TUN、恢复系统代理与处理残留端口
若刚开 TUN 就全断，先关闭 TUN，保留原 Profile 与节点。系统代理恢复，说明故障在虚拟网卡、路由或 TUN 的 DNS；系统代理也失败，再回到节点和配置。不要直接使用操作系统的网络重置，它会清掉更多无关设置。
关闭客户端后网页仍打不开时，检查系统代理是否残留在 127.0.0.1 的旧端口；清除后，用本来可直连的目标验证恢复。