Clash 开 fake-ip 部分网站打不开？fake-ip-filter DNS

文章目录

一、先对齐现象：哪些情况像 fake-ip 问题

fake-ip 的核心行为是：在本地 DNS 查询阶段，对匹配规则的域名返回一段虚拟 IPv4 地址（常见为配置中的 fake-ip-range，例如 198.18.0.1/16 一类保留段），真正的域名到远端 IP 的解析往往延后到连接建立时由内核或代理完成。绝大多数网站因此更顺滑，但当某类应用或站点在「拿到假 IP 之后」仍坚持用自己的方式做二次解析、校验证书与 SNI、或依赖真实地理/运营商解析结果时，就会表现为只有几个站异常，而不是全网瘫痪。

读者自查时可对照下列现象：浏览器地址栏长时间空白或只显示加载动画；部分国内银行、政务、企业门户在开启代理后反而打不开；游戏启动器、语音或会议软件提示网络错误；HTTPS 页面弹出证书与域名不匹配；仅命令行或仅某一应用异常，而同一台机器上浏览器访问其他站正常。若你关闭 fake-ip（改为 redir-host 等）后问题立刻消失，则高度怀疑与假地址链路或过滤列表有关，而不是单纯「节点挂了」。

这与我们在 Perplexity 分流一文里提到的「规则分流之外还要核对 DNS、DoH 与 fake-ip」是同一类思路：先把域名解析异常从「规则写错」里剥离出来，再决定是改列表还是改 DNS。

二、对照实验：确认异常与 fake-ip 强相关

在动大配置之前，建议用最小对照锁定因果关系。第一步：仅针对出问题的主机名，在客户端日志或连接预览里观察解析结果是否落在 fake-ip-range 内。第二步：临时将 dns.enhanced-mode（或你所使用内核中的等价项）从 fake-ip 改为 redir-host，重载配置后复测同一 URL；若异常消失，即可认定问题链条与 fake-ip 行为相关，后续专注 fake-ip-filter 与 DNS。

第三步（可选）：保持 fake-ip，但让系统或浏览器绕过 Clash 的 DNS 做对比（例如仅在测试设备上临时指定公共 DNS）。若绕过后站点恢复，说明瓶颈在 Clash DNS 上游、劫持顺序或 fallback；若仍失败，则要回到规则、节点或嗅探层继续查。

小贴士：对照实验每次只改一个变量。同时改节点、规则和 DNS 会让日志无法解读，也容易误删有效配置。

三、fake-ip-filter：该让哪些域名走真实 IP

fake-ip-filter（在部分配置模板里也写作 fake-ip-filter 下的域名列表或与 nameserver-policy 组合使用）的作用是：对列表内的域名不使用 fake-ip，而返回真实解析结果。漏加一条，往往就意味着「这个域名在客户端眼里始终是假地址」，进而触发上文所述的各种兼容性问题。

建议优先纳入 filter 的类型

局域网与纯内网主机名，例如 *.local、路由器管理地址、NAS、打印机、公司内网门户；假 IP 无法对应你真正的二层/三层路径。
对证书校验极度敏感的服务：部分网银、支付、电子政务、零信任接入会在握手阶段绑定特定解析路径或证书钉扎，假 IP 容易造成握手失败或中间页无限跳转。
依赖真实 CDN 边缘调度的站点：少数站点在 DNS 层就需要得到「离你最近的」地址，若长期拿到固定假地址，可能表现为极高延迟或握手超时（视客户端实现而定）。
已知的直连或大陆优化域名：若你的规则将这些域名标为直连，但仍走 fake-ip，可能在「直连出站」与「假地址目标」之间出现语义不一致；将此类域名放入 fake-ip-filter 可减少边界情况。

配置示例（按你使用的内核字段为准）

下列片段仅示意结构，字段名请以 Mihomo / Meta 当前文档为准；合并订阅时注意不要重复整段 dns: 键。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.msftconnecttest.com"
    - "stun.*.*"
    - "+.srv.nintendo.net"
  # add hostnames that break with fake-ip below

实际操作时，请把出问题站点的主域名、登录跳转域、静态资源域与 WebSocket 域一并收集（开发者工具网络面板里可见），逐条加入 filter 后重载 DNS 或重启内核再测。若列表过长，可考虑用 geosite 或规则集批量覆盖，再对个别域名微调。

注意：fake-ip-filter 不是「广告过滤列表」。它的目标是兼容性，滥用会让 fake-ip 失去意义；应坚持「只加确认有问题的域名」。

四、DNS：nameserver、fallback 与解析顺序

即便 fake-ip-filter 已正确，若 DNS 段本身不稳定，仍会出现「偶发打不开」「仅移动网络不行」等现象。建议按链路自上而下检查。

nameserver 是否可达

确认 Clash 配置的 DoH/DoT/UDP DNS 在你当前网络下未被拦截。企业网、校园网或运营商有时会干扰非标准端口或特定 DoH 主机名，表现为间歇性解析失败。可临时换成另一组上游做 A/B，观察问题是否随上游切换而消失。

fallback 与 fallback-filter

当主上游返回被污染或异常结果时，fallback 是否会被触发、fallback-filter 的 geoip 与域名列表是否合理，决定了你是否会在 fake-ip 场景下拿到错误大陆或错误线路的解析前置信息。若你曾从模板复制过一份很激进的 fallback-filter，建议对照官方示例逐项理解后再裁剪。

nameserver-policy 与分域上游

对境内站点与境外站点混用时，用 nameserver-policy 把特定后缀交给指定 DNS，往往比全局单一上游更稳。这与 WSL2 与 DNS 排查一文里强调的「解析路径分层」一致：先保证查询能到达正确上游，再谈 fake-ip 是否启用。

现象	优先检查项
仅特定域名异常	是否应加入 `fake-ip-filter`；该域名的 CNAME 链是否在规则集里被遗漏
换网络环境后恢复	DNS 上游是否被当前网络劫持或限速；DoH 主机名是否被阻断
证书错误或 SNI 相关日志	嗅探是否误伤；是否在 TUN 下与系统证书策略冲突（见下一节）

五、嗅探与证书：何时收窄或暂时关闭

嗅探（sniffer） 用于在流量已经加密时，根据 TLS Client Hello 等信息尝试还原域名，以便规则模块在「看不到明文 Host」时仍能分流。它与 fake-ip 常常同时开启，二者叠加后，若嗅探范围过大或某一嗅探实现与目标站点握手特性不兼容，可能出现证书警告、连接被中间重置、HTTP/2 或 QUIC 降级异常等现象。

排查顺序建议：先在日志中确认异常连接是否经过嗅探路径；再将嗅探限定在需要的协议或端口（例如仅对特定入站或仅 TCP 443），排除误嗅探；若仍无法解释，可短暂关闭嗅探做对照——若关闭后站点恢复，则优先收窄嗅探规则，而不是盲目关闭 fake-ip。

部分桌面客户端会把「自动嗅探」与「系统代理 / TUN」绑定，修改后记得重启系统代理服务或虚拟网卡，避免旧进程仍按上一版行为工作。

六、与 TUN、系统代理及其他客户端叠加

当 TUN 模式 与 fake-ip 同时启用时，系统路由表、默认 DNS 与 Clash 内部 DNS 可能形成双环依赖**：系统认为 DNS 在本地某一地址，而 Clash 又在等应用发起连接后才完成远端解析。此类问题在表现上与「单纯 fake-ip」相似，但修法往往在路由排除、绕过大陆、DNS 劫持开关等层面。建议结合 TUN 与路由防火墙排查一文，先确认 TUN 未造成全局断流或回环，再回到本文的 filter 与 DNS 列表。

若机器上还运行其他 VPN、企业安全代理或「加速器」，多个虚拟网卡争抢优先级时，也可能出现仅少数域名走错栈。此时可在出问题的应用内关闭「独立代理」或调整顺序，确保只有一条明确的出口路径。

长期维护上，建议把「已加入 fake-ip-filter 的域名及原因」记在本地笔记里：是证书问题、内网解析还是 CDN 调度。下次升级订阅或更换客户端时，可避免重复踩坑。

七、小结

Clash fake-ip 能显著改善多数场景下的连接建立速度，但少数网站打不开往往不是节点单点故障，而是 fake-ip-filter 未覆盖、DNS 上游与 fallback 不稳，或嗅探与 TLS 行为叠加后的兼容性问题。按「对照实验 → 补 filter → 查 DNS → 收窄嗅探 → 核对 TUN」的顺序排查，通常能在不牺牲整体体验的前提下定点修复。

相比反复搜索零散片段，把每一次异常域名记录下来并归入上述某一类，你的配置会越维护越稳。若你希望从一份可信渠道获取客户端与基础模板，可先阅读本站配置文档，再导入订阅并按本文检查 DNS 与 fake-ip 段。

相比其他同类工具，Clash 系列在规则、DNS 与多模式协同上文档与社区实践都较丰富；理顺 fake-ip 与真实解析的边界后，日常浏览与开发工具的稳定性都会明显提升。

→ 立即免费下载 Clash，开启流畅上网新体验