外观
Clash 的 Fake-IP 与 Redir-Host 怎么选？从 DNS 解析原理到常见兼容问题
很多人在 Clash 的 DNS 设置里见过 fake-ip、redir-host，也可能遇到过“打开网页正常，但某个 App 无法登录”“游戏或投屏设备找不到”“切换 TUN 后局域网异常”等情况。它们看起来像是节点问题，实际上经常与 DNS 增强模式有关。
这篇文章不要求你一开始就修改配置，而是先解释两种模式分别做了什么、为什么会影响软件联网，再给出一套以稳定为目标的选择和排查方法。对于大部分普通用户来说，理解这些概念后，往往能少走很多“换节点、重装客户端、反复更新订阅”的弯路。
先理解：DNS 不只是“把网址变成 IP”
当你访问一个网站或打开一个 App 时，设备通常先要询问 DNS：“这个域名对应哪个 IP 地址？”例如，应用需要访问某个服务域名，DNS 返回一个真实 IP，设备再向该 IP 建立连接。
在未使用代理时，这个过程很直观：
- 应用发起域名查询；
- DNS 返回真实 IP；
- 应用连接该真实 IP；
- 系统根据默认网络路径发送数据。
但代理客户端需要解决一个关键问题：后续这条连接究竟该走代理、还是直连？
如果客户端只看到 IP，有时就难以准确判断它最初对应哪个域名。尤其是一台 IP 上可能承载多个网站，或服务使用 CDN、动态调度时，仅凭 IP 分流并不可靠。因此，Clash 的 DNS 模块会用不同方法尽可能保留“域名与连接之间的关系”。fake-ip 和 redir-host，就是两种不同的处理策略。
Fake-IP：给域名分配一个“内部临时地址”
Fake-IP 可以理解为：Clash 不立刻把真实 IP 直接交给应用，而是从一个专用的保留地址段中，为这个域名分配一个临时、虚拟的 IP。
例如，应用查询 example.com 时，Clash 可能返回一个类似 198.18.x.x 的地址。这个地址并不是真实服务器地址，而是 Clash 在本机维护的一条映射记录：
- 虚拟 IP →
example.com example.com→ 后续应匹配的规则和代理策略
当应用尝试连接这个虚拟 IP，Clash 能反查出原始域名，再依据规则决定直连、代理或交给某个代理组处理。真正建立外部连接时，客户端仍会处理到目标服务所需的真实地址。
Fake-IP 的优点
第一，域名分流通常更稳定。
因为 Clash 持有虚拟 IP 和域名的对应关系，所以即使后续连接表面上只出现 IP，规则系统仍有较大机会识别其原始域名。这对于依赖域名规则集、CDN 服务较多的网站和应用较有帮助。
第二，对 TUN 或透明代理环境更友好。
在 TUN 模式下，系统流量会更完整地进入 Clash 处理链路。Fake-IP 便于客户端识别和还原流量归属，因此常被用作此类场景的默认选择。
第三，减少某些应用自行解析带来的分流混乱。
部分应用会进行并发连接、缓存 DNS 结果或直接按 IP 访问。Fake-IP 并不能解决一切问题，但在常规网页与应用访问中，往往能让规则命中更一致。
Fake-IP 的局限
它的核心特点也是它可能带来兼容问题的原因：应用拿到的并不是真实 IP。
少数软件、硬件或局域网服务会对返回 IP 有特殊预期，例如：
- 某些游戏联机、语音或旧版客户端；
- 投屏、智能电视、智能家居设备发现；
- NAS、路由器、打印机等内网域名服务；
- 企业内网、公司 VPN 使用的私有域名；
- 对 IP 地址做校验、记录或局域网广播协作的软件。
这些场景中，如果程序把虚拟 IP 当作真实可直连地址使用，或者绕过了 Clash 的预期处理路径，就可能出现“能解析却连不上”“设备发现失败”“偶尔正常、偶尔失效”等现象。
Redir-Host：返回真实 IP，但尽量保留域名信息
redir-host 的思路更接近传统 DNS：查询域名时，Clash 向上游 DNS 获取真实结果，并将真实 IP 返回给应用。
与此同时，Clash 会在内部缓存“某个域名曾解析到哪些 IP”。当连接进入客户端后，它再尝试根据缓存把 IP 关联回域名，进而套用域名规则。
因此，Redir-Host 的特点可以概括为：给应用真实 IP，再由 Clash 尽力回忆这个 IP 对应的域名。
Redir-Host 的优点
兼容性通常更直观。
由于应用获得的是真实 IP，一些不理解虚拟地址的设备和软件更容易正常工作。若你主要遇到局域网设备、投屏发现、某些游戏或企业内网工具在 Fake-IP 下异常，Redir-Host 是值得优先尝试的替代方案。
对排查问题更容易理解。
使用网络抓包、查看系统连接或检查路由器记录时，看到的是目标服务的真实 IP，而不是一段本地虚拟地址。对希望逐步学习网络排障的用户来说，这一点较直观。
Redir-Host 的限制
它并不是“绝对更稳定”，只是取舍不同。
一个 IP 可能同时对应多个域名，尤其是在 CDN、云服务和共享托管环境中。此时客户端即使知道某个 IP 曾被某域名解析过，也未必能百分之百判断当前连接属于哪个域名。DNS 缓存过期、应用使用自带 DNS、连接建立速度过快等情况，也会降低关联成功率。
所以在复杂分流规则、透明代理或全设备接管场景中，Redir-Host 有时会出现规则识别不够准确的问题。表现可能是某些域名规则偶发失效，或者同类服务中有少量连接没有按预期走代理。
两种模式怎么选：先按使用场景判断
不需要为了“高级”而选择 Fake-IP，也不必因为某个教程推荐 Redir-Host 就长期固定使用。可以按照下面的优先级判断。
场景一：电脑或手机日常上网，以网页和常见 App 为主
优先使用 Fake-IP。
这是因为日常访问更依赖域名分流，Fake-IP 通常更有利于让规则保持一致。若没有遇到明确异常，不建议频繁切换 DNS 增强模式；每次切换都可能导致缓存变化，让问题变得更难判断。
场景二：开启 TUN，希望尽可能接管系统流量
通常仍建议先使用 Fake-IP。
TUN 的价值在于让不遵循系统代理的软件也能被接管，而 Fake-IP 在识别域名、交给规则系统判断方面更有优势。请同时注意将局域网地址、私有域名和必要的内部服务纳入排除策略，避免内网请求被错误送入代理路径。
场景三：投屏、局域网发现、NAS、打印机或企业内网异常
优先检查 Fake-IP 过滤规则；如果无法改善，再尝试 Redir-Host。
这里有一个常见误区：一遇到局域网故障就直接关闭 DNS 或切全局模式。这样可能暂时“看起来恢复了”，但会失去正常分流能力，也无法确认真正原因。更合理的顺序是：先排除对应内网域名，其次确认局域网 IP 不走代理，最后才考虑切换增强模式。
场景四：只想尽量少折腾，遇到问题能快速恢复
可以从 Redir-Host 开始，但要接受规则精度可能略受影响。
如果设备较多、网络环境复杂、你更看重传统兼容性而不是精细化分流，Redir-Host 是偏保守的选择。之后若发现特定网站或 App 未按规则运行，再结合日志和规则逐项处理。
Fake-IP Filter 是什么，为什么不能乱填
在使用 Fake-IP 时，常会看到 fake-ip-filter 或“Fake-IP 过滤列表”。它的作用是：让名单中的域名不要返回虚拟 IP，而是按更传统的方式解析真实 IP。
它适合处理那些明确与 Fake-IP 不兼容的域名，例如某个企业内部域名、家庭路由器的本地域名、特定设备发现服务使用的域名。不同客户端的界面名称略有不同，但核心逻辑一致。
一个简化示例：
dns:
enhanced-mode: fake-ip
fake-ip-filter:
- '*.lan'
- '*.local'
- 'router.local'
- '+.internal.example'上面的内容只用于理解格式，不应不加判断地照搬到现有订阅中。特别要注意以下几点：
- **不要把常用公共域名大面积加入过滤。**这会削弱 Fake-IP 的域名识别优势，可能造成规则命中变差。
- **不要把
*作为过滤项。**这相当于让 Fake-IP 基本失去作用。 - **优先针对故障域名做最小化添加。**确认是哪个域名导致问题，再加入对应条目。
- **修改后清理 DNS 缓存并重启相关应用。**否则应用可能仍在使用旧结果，导致你误判配置是否生效。
出现“某个 App 不能用”时，正确排查顺序
DNS 模式相关问题最怕一次改动太多。建议按以下顺序操作，每做一步都重新测试同一个问题，确认变化。
1. 先确认是应用问题，还是整体网络问题
在同一网络下测试：浏览器是否能打开其他网站？同一服务的网页版是否正常？切换 Wi-Fi 和移动网络后现象是否一致？
如果所有网站都无法访问，重点应放在节点、系统代理、TUN、网络本身或证书问题上，而不是立即修改 Fake-IP。
2. 查看 Clash 的连接或日志记录
打开客户端的连接列表或日志页面，启动出问题的 App，观察是否出现相关域名、目标地址、命中规则和最终代理组。
如果能看到域名，却命中了意外规则，问题更可能是规则顺序或规则集；如果只有 IP、没有可识别的域名，则 DNS 增强模式、应用自带 DNS 或缓存可能是排查方向。
3. 先清缓存，再单独切换增强模式
关闭出问题的应用，清理客户端 DNS 缓存；必要时重新连接网络或重启客户端。然后只把 fake-ip 改为 redir-host，其他配置不要同时调整。
若问题立即稳定消失，说明该应用或该网络环境可能对虚拟 IP 不够兼容。接下来可决定长期使用 Redir-Host，或回到 Fake-IP 并为相关域名增加精确过滤项。
4. 检查应用是否绕过了系统 DNS
一些浏览器、即时通信工具、游戏和安全软件可能启用自带 DNS、加密 DNS 或内置网络模块。它们不一定完全遵循系统的 DNS 设置，因此可能让 Clash 的域名映射和规则判断变得不完整。
这不意味着必须关闭所有安全功能，而是要避免多个 DNS 接管机制互相冲突。排查时可暂时关闭其中一项进行对比，确认问题来源后再决定保留方案。
一套适合普通用户的稳定配置思路
不论使用哪种客户端，配置时都可以遵循以下原则：
- 日常使用优先开启 Clash 自己的 DNS 管理，不要让多个代理扩展、浏览器 DNS、系统 VPN 同时重复接管；
- 以 Fake-IP 作为默认方案，只有出现明确兼容问题时再处理；
- 对局域网、私有地址和内部域名保持直连，避免把家庭或办公网络资源错误送入代理；
- 遇到故障时一次只改一个变量：节点、规则、DNS 模式、TUN 开关应分开测试；
- 保存可用配置副本。修改前导出当前配置或记录关键开关，出现问题才能快速恢复。
另外，DNS 上游地址、规则策略和增强模式是三个不同层面。换 DNS 不一定能解决 Fake-IP 兼容性问题；切换节点也不一定能修复域名映射错误。把问题拆开看，排障效率会高很多。
总结：没有“最好”，只有更适合当前网络的选择
Fake-IP 的重点是更好地保留域名信息，适合大多数以规则分流、TUN 接管和日常网络访问为主的环境；Redir-Host 的重点是返回真实 IP，面对少数特殊应用、局域网设备或内部网络时，兼容性往往更直接。
如果你没有遇到问题，维持客户端默认且稳定的 DNS 配置即可；如果只在某个软件、设备或网络环境下异常，不要急着重装或更换全部配置。先通过日志确认连接情况，再清缓存、单独切换模式，最后才为确定的域名加入最小范围的过滤规则。
掌握这套思路后，Fake-IP 与 Redir-Host 就不再是配置页里难懂的英文选项，而是两种可以根据实际需求灵活选择的网络处理方式。