查询一个域名，结果出现198.18开头的地址，很容易让人以为网站迁移到了陌生的服务器。在Mihomo Fake-IP模式下，这个结果可能只是核心分配的虚拟映射。它的意义是保留域名与后续连接之间的对应关系，不是展示远端服务器实际位于哪里。
198.18地址不是远端位置
fake-ip-range 设置用于映射的地址范围。应用取得虚拟地址后，相关连接需要回到能够理解该映射的核心，才能根据域名和策略继续处理。它不是用户的真实公网出口IP，也不是网站的真实公网IP，更不能被当作测量服务器地理位置的依据。
因此，单独把Fake-IP地址交给绕开核心的应用或另一台设备，未必可以正常访问。同一域名在不同时间也可能关联不同映射；不要将一次解析结果写死到长期使用的外部配置里。先阅读DNS处理机制，明确实际采用的增强模式和查询入口。
两种模式如何处理域名
enhanced-mode: fake-ip 对适用查询返回映射地址，核心保留域名线索。redir-host 则以真实解析结果处理DNS请求。两者改变的是DNS处理行为，而不是简单切换一个“更快”的服务器；远端连接是否可用还取决于实际出口、策略和网络条件。
需要区分应用收到的DNS答案、核心为了连接进行的解析以及最终连接目标。日志中的地址属于哪一步，应结合连接类型判断。不能保证所有应用在两种模式下都表现一致，也不能把所有解析失败都归因于Fake-IP。
过滤项与过滤模式要一起看
fake-ip-filter 的含义需要结合 fake-ip-filter-mode。在 blacklist 模式中，匹配域名不使用Fake-IP；whitelist 模式改变匹配含义；rule 模式使用规则形式指定处理方式。不要从不同模式的示例里直接拼接内容。
dns:
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter-mode: blacklist
fake-ip-filter:
- '*.lan'这里仅演示黑名单模式中的过滤关系；实际域名是否匹配、上游能否解析，仍需在当前环境验证。规则并不自动创建局域网DNS记录，也不会让所有不兼容应用立即恢复。只对已定位的域名缩小处理范围，避免把全部域名加入过滤。
缓存与应用兼容性怎么验证
修改模式后，系统、浏览器、应用与核心都可能保留不同层的缓存。先确认活动配置已经加载，再使用同一个查询名称、同一个指定DNS入口对照响应。浏览器自带的安全DNS可能绕过系统设置；已有长连接也可能延续旧路径。可按DNS查询路径检查方法逐层记录，避免把缓存差异误认为配置失效。
如果只有一个应用异常，记录它是否直接使用IP、是否使用独立DNS以及错误发生在解析还是连接阶段。比较单个域名的过滤前后表现，比无差别关闭Fake-IP更能说明原因。改变地址池前先检查与现有路由或其他虚拟网络是否重叠。
把局域网问题留在正确的层
打印机发现失败与普通公网域名解析并不相同。名称过滤可能影响某个查询的处理，但mDNS组播、设备子网和防火墙仍有各自的条件。遇到本地设备异常，参考局域网访问与mDNS先比较设备IP直连和自动发现，再决定是否调整过滤规则。保留修改前的配置，让每次对照都可以回退。
