典型现象：不是「规则没写直连」，而是解析先错了
在 enhanced-mode: fake-ip 下，内核会对「需要参与规则匹配的域名查询」返回一段本地虚拟地址（常见为 198.18.0.0/16）。浏览器或系统拿到这段地址后，会以为目标在「内核虚构出来的网段」里；对公网站点，后续连接由内核接管并映射回真实域名，体验往往正常。
但局域网与 mDNS语义不同：你希望拿到的是 192.168.x.x、10.x.x.x 或链路本地地址，而不是 198.18.x.x。一旦 NAS 或网关主机名被发了 FakeIP，应用会朝错误网段发起连接，表象就是「突然连不上路由器、群晖后台、打印机页」。此时在 rules 里写再多 DIRECT 也可能救不回来，因为DNS 阶段已经偏离了内网预期。
与 DNS 总览、防泄漏策略的关系，建议对照 Meta 内核 DNS 防泄漏：FakeIP、DoH、DoT 完整配置：那篇讲「整条 DNS 栈怎么收紧」，本篇讲「哪类名字不要进 FakeIP 池」。
1fake-ip-filter 做什么、不做什么
在 Meta 的 dns 配置中，fake-ip-filter 是一个例外列表：被匹配的查询不会拿到 FakeIP，而是按你在 nameserver、fallback、nameserver-policy 里定义的路径去做真实递归解析。它解决的是「名字该不该进 FakeIP 池」，不是「连上之后走代理还是直连」——后者仍由 rules 与策略组决定。
因此，正确姿势是：先用 fake-ip-filter 让内网相关主机名恢复可信解析结果，再确保对应流量在规则里走 DIRECT 或合适的局域网策略。若你同时关心「手机走电脑代理」等拓扑，可顺带阅读 Clash Verge Rev 混合端口与局域网步骤，避免把「解析问题」误判成「端口没开」。
匹配形态：后缀、通配与 geosite
列表中常见写法包括：普通域名、带 * 的通配、以及以 +. 前缀表示的「后缀级」规则（与订阅模板习惯一致，具体以你当前内核版本说明为准）。部分规则集也支持通过 geosite: 引入一整类私有或直连域名，适合与机场模板合并时集中维护，但仍建议保留一小段「自家 NAS、路由器专用名」的手写条目，避免全家模板升级时把冷门内网名冲掉。
2可复制的基础 dns 骨架
下面是一段教学用骨架：突出 fake-ip-filter 位置，其余字段请按你的网络与订阅合并结果裁剪。若与机场远程配置冲突，以「能启动 + 内网可访问」为优先，再用覆写层逐步收紧。
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- localhost
- "+.localhost"
- "+.msftconnecttest.com"
- "+.msftncsi.com"
- "router.asus.com"
- "repeater.asus.com"
- "tplinkwifi.net"
- "routerlogin.net"
- "stun.*.*"
- "stun.*.*.*"
nameserver:
- tls://dot.pub
fallback:
- tls://dns.google
fallback-filter:
geoip: true
geoip-code: CN
说明：*.local 覆盖 mDNS 常见命名；*.lan 覆盖部分路由器与旧设备默认域；若干厂商 captive portal / 管理域名在示例中列出，实际请以你设备说明书为准增补。若公司内网使用 *.corp.example.com 这类固定后缀，务必整后缀加入，否则财务系统、Git 内网也会间歇性「解析对、路由错」或反过来。
3「直连域名」要不要全部塞进 filter？
社交模板里常看到把 geosite:cn 或大量「国内直连域名」放进 fake-ip-filter 的做法，意图是让大陆站点拿到真实 IP，减少 CDN 调度与 FakeIP 组合时的怪异现象。它有一定道理，但列表过大时会带来两点成本：解析路径变复杂、与 fallback-filter 的交互更难排查。
更稳妥的工程化做法是：优先保证「必须拿到真实局域网语义」的名字进 filter；其余直连诉求优先用 rules 的 DOMAIN / DOMAIN-SUFFIX 与 nameserver-policy（让特定后缀走指定上游）组合解决。若你发现只有个别大陆域名在 FakeIP 下异常，再考虑最小增量加入 filter，而不是一次性「全家桶」拷贝。
4核对 fake-ip-range 与内网网段
若你把 fake-ip-range 改成了与办公室网段重叠的地址块，即使 fake-ip-filter 写得再全，也可能出现路由层面的混淆。默认 198.18.0.0/15 一类段与家庭 192.168.0.0/16 通常不冲突，但若你曾手动改过 range，请回头对照一次。
5TUN、劫持与验证顺序
在 TUN 与 dns-hijack 场景下，DNS 查询路径更长，排错时建议固定顺序：① 确认查询确实进入内核 DNS；② 在日志或调试面板看该域名是否仍返回 198.18.x.x；③ 若仍返回 FakeIP，检查 fake-ip-filter 写法与合并顺序；④ 若已是真实私网 IP，再查 rules 是否把流送进代理组。TUN 前置条件见 Clash Verge Rev TUN 模式完整开启教程。
直连纯 IP访问（例如在地址栏输入 192.168.1.1）通常不触发「域名 → FakeIP」这条链；若纯 IP 仍异常，多半不是 fake-ip-filter 能单独解决的，应检查 TUN 栈、系统路由或浏览器 HTTPS 仅域名策略。
提示：企业或校园网若对 DNS 有强制重定向，盲目加长 filter 或劫持范围可能导致「能解析但合规告警」；与网管策略冲突时，应以组织规定为准。
关于 GitHub：Mihomo / Meta 内核的源码与变更记录在 GitHub 公开，便于核对字段语义；这与「在哪下载已签名的桌面客户端」是两条线。若需对照实现细节可自行访问仓库；日常获取安装包仍建议通过 本站下载页。
小结
Clash Meta 下保留 FakeIP 的同时修复内网访问，关键是认清 fake-ip-filter 管的是「哪些域名不要拿假地址」。把 *.local、*.lan、路由器与 NAS 常用名、单位内网后缀放进列表，再与 DNS 分流和 DIRECT 规则联动验证，比一刀切改 redir-host 或关 DNS 模块更可控。
相比在论坛里复制大段不明出处的列表，用支持 Meta 的图形客户端把 dns 段与连接日志对照修改，出了问题也更容易复盘：你能明确区分是「仍进了 FakeIP」还是「解析对了但规则送错组」。
相比其他同类工具，Clash 系列在「DNS、规则、TUN 同一套配置语境」里可观测性更强，长期维护成本更低；把 FakeIP 与 filter 调顺之后，日常翻墙与内网管理可以并存。