1. 机制解剖：虚拟映射池 vs 真实解析转发
理解两种模式的技术差异有助于从底层掌握网络流向：
### 1. Fake-IP 机制（推荐）
- 本地内核接管 DNS 查询后，从 `198.18.0.1/16` 地址池分配一个虚拟虚构 IP 骗过本地操作系统；
- 优点：彻底免除了客户端等待 DNS 解析的往返耗时，彻底阻断本地运营商对 UDP 53 的阻断嗅探；
- 痛点：部分对真实 IP 有严格要求的网络应用（如严格校验 IP 网段的主机联机游戏、旧版 Java 程序）可能会出现网络不识别。
### 2. Redir-Host 机制（历史过渡方案）
- 本地内核接管 DNS 查询后，必须先在后台真实查询出该域名的真实 IP，记录到 NAT 映射表后，再将真实 IP 返回给操作系统；
- 缺点：每次访问新网站都必须承受 50~300ms 的远程 DNS 查询延迟，且极易因国内中间人污染导致拿到错误 IP；
- 现状：由于性能差且配置繁琐，原版 Clash Premium 已废弃该模式，Mihomo 虽保留兼容但不推荐作为默认主力。
💡 现代操作系统与现代浏览器全面支持并在 Fake-IP 下运行得更加流畅。
2. 兼容性痛点排查：联机游戏与私有服务
在某些小众场景下，Fake-IP 可能会引发异常：
### 痛点 1：主机平台（Switch / PS5 / Xbox）联机 NAT 报错
- **原因**：部分游戏（如《喷射战士》、《怪物猎人》）在建立 P2P 房间时，会将本地获取到的「Fake-IP（198.18.x.x）」上报给对战撮合服务器，其他玩家尝试连接该虚拟私有 IP 时必然超时；
- **解决**：在软路由网关中，将任天堂或索尼对战服务器域名加入 `fake-ip-filter`。
### 痛点 2：家庭内网 NAS 与本地 Windows 共享（SMB）
- **原因**：访问 `nas.local` 时拿到 198.18 虚拟 IP，导致 SMB 客户端无法找到局域网设备；
- **解决**：将 `*.local` 与 `*.lan` 全部放行，走真实局域网解析。
yaml
# 生产级 fake-ip-filter 避坑放行白名单配置
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
# 局域网服务与主机发现
- "*.lan"
- "*.local"
- "*.internal"
- "localhost.ptlogin2.qq.com" # 微信与 QQ 网页快捷登录
# 联机游戏与主机对战服务 (必须还原真实 IP 建立 P2P)
- "+.stun.*.*"
- "+.stun.*.*.*"
- "*.nintendo.net"
- "*.nintendowifi.net"
- "*.xboxlive.com"
- "*.playstation.net"
# 常见公共测速平台
- "*.speedtest.net"3. 内存与 LRU 淘汰算法优化机制
由于 Fake-IP 是由内核在内存中维护的一个哈希映射表（IP <-> 域名），如果在爬虫采集或高频扫描网络的环境下，产生数以百万计的临时子域名，是否会导致虚拟 IP 耗尽或内存爆炸？
Mihomo 内核对此进行了深度工程优化：
- **LRU（最近最少使用）自动淘汰**：地址池采用环形复用机制，当 65,534 个虚拟 IP 用满后，内核自动回收最早未被活跃访问的映射槽位；
- **TTL 智能保活**：只要连接仍保持活跃，映射条目永远锁存，彻底避免长连接会话 IP 错位。
❓ 常见疑问与排查步骤
用浏览器抓包插件看到请求地址全是 198.18.x.x 正常吗？
完全正常。这说明 Fake-IP 正在完美生效。内核会在数据包真正发送至远程代理节点前，在底层透明还原成正确的域名目标。
Redir-Host 模式在什么时候还有必要开启？
仅在极少数环境下的路由器旁路网关调试、或某些需要配合旧版 iptables 真实目标重定向的古董嵌入式系统上才有必要使用。
清理电脑本地 DNS 缓存会影响 Fake-IP 吗？
在 Windows 执行 `ipconfig /flushdns` 会清理系统的 DNS 缓存，再次访问时系统会重新向 Mihomo 查询并拿到新的 Fake-IP，完全不会破坏代理功能。