Clash Fake-IP 下局域网与路由器打不开？绕过与嗅探

为什么 Fake-IP 会影响局域网访问

Fake-IP 的本质，是让 Clash 在本地抢先回答 DNS 查询：对大量域名返回一段「池内」的假 IPv4（常见为 198.18.0.0/16 一类保留段），再由内核在真正发起连接时，把假地址还原成真实目标，从而配合规则做域名级分流。对公网站点这通常很顺手，但对局域网访问来说，只要解析或路由某一环仍把流量送进了代理栈，就可能出现「页面空白、连接重置、超时」——因为私网地址本不该走远端节点，也不该被错误地当成公网域名去做策略。

另一个常见混淆点：你在地址栏输入的是 192.168.1.1 这类纯 IP，此时根本没有域名可供 Fake-IP「还原」，问题更多出在规则是否把该连接标成直连、以及 TUN 是否把整包流量导进了内核。若你习惯用路由器厂商提供的域名（例如 router.xxx.com）打开后台，则又会同时涉及 DNS：该域名可能被错误地走了 Fake-IP，或需要列入 fake-ip-filter 以拿到真实内网地址。先分清自己是「纯 IP 访问」还是「域名访问」，后面两步（规则与 DNS）才不会改错地方。

ℹ 与站内其它文章的关系：若你关心透明代理整体原理，可先读 Clash TUN 模式深度解析；若断线表现为 timeout 或 TLS 报错，再结合从日志读懂 timeout 与 TLS 分层判断。本文只聚焦 Fake-IP 与内网这一高频组合。

第一步：用绕过规则让私网地址直连

无论使用 规则模式 还是全局，都建议在规则表靠前位置加入对私有地址段的直连（DIRECT）声明，避免任何「误匹配到 PROXY」的路径。IPv4 侧至少应覆盖 RFC1918 三段：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16；本机回环 127.0.0.0/8 建议同样直连；若环境中有链路本地或运营商内网段，可按需追加。使用 IP-CIDR 规则时，若该条不参与域名解析决策，应加 no-resolve，避免与后续基于域名的规则打架。

下面是一段示意结构（具体缩进与字段名以你所用的 Clash Meta / Mihomo 版本为准），请把它放在自定义规则中较前的位置，并确保不会被更宽泛的规则提前抢走：

rules — private IPv4 to DIRECT (example)

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  # ... your other rules

若你使用 IPv6 内网或 ULA，可视情况增加 fc00::/7、fe80::/10 等条目；双栈环境下漏配 IPv6 有时会表现为「偶发能开、偶发不能开」。另外，某些 NAS 或监控设备会使用多网段访问，只要目的地址落在私网范围内，都应走 DIRECT，而不是让策略组去选节点。

和「局域网共享代理」问题的边界

若你的诉求是「手机连电脑上的 HTTP/SOCKS 端口」，而不仅仅是本机访问路由器，请同时核对监听地址与防火墙，这与 Fake-IP 是不同层面的事；可参考 Clash 局域网共享与防火墙排查，避免把端口不可达误判成 Fake-IP。

第二步：DNS 与 fake-ip-filter

仅加 IP-CIDR 直连有时仍不够：当浏览器访问的是内网域名（例如路由器、NAS 提供的 DDNS 或 *.local 类名称）时，DNS 模块可能仍对该查询返回 Fake-IP 池中的地址，后续连接就会偏离真实内网路径。解决思路是让这些域名走「真实解析」——在 Meta / Mihomo 中通常通过 dns.fake-ip-filter（或等价列表）声明：不要对列表内域名使用 Fake-IP，而是按你配置的 nameserver 正常解析。

你可以将以下内容视为模板，按自家设备域名增删（厂商文档里一般会写默认域名或局域网主机名）：

dns — fake-ip-filter example (YAML fragment)

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '*.home.arpa'
    - 'router'
    - 'tplinkwifi.net'
    - 'miwifi.com'
    # Add your NAS DDNS or router domain here

fake-ip-range 若与局域网或 VPN 网段冲突，应改到不重叠的保留段，否则会出现难以归因的「随机断连」。改完 DNS 相关段落之后，建议重启核心并在客户端里观察：解析结果是否已变为真实私网地址。若仍异常，可打开调试日志确认 DNS 请求是否仍走了 Fake-IP 分支。

⚠ 注意：fake-ip-filter 只能解决「域名被错误 Fake 掉」这一类问题；若目标本身就是公网域名但你需要强制直连，应使用 DOMAIN / GEOSITE 等规则配合 DIRECT，不要指望单靠 DNS 列表解决所有分流意图。

第三步：嗅探（sniffing）何时需要、怎么写

在 TUN 模式或部分透明转发场景里，内核最初拿到的可能只是「目标 IP + 端口」，没有域名信息；此时基于域名的规则可能无法命中，连接会被送到错误的策略组。嗅探（Sniffing）的作用是在 TLS、HTTP 等协议里尝试恢复主机名，让后续规则能按「域名意图」分流。对内网而言，嗅探常用于：你用 IP 打开某台设备，但希望某条基于域名的规则仍能一致生效；或 HTTPS 页面依赖 SNI 与证书域名一致时，辅助内核还原出正确的主机名。

在 Clash Meta / Mihomo 系配置中，嗅探相关段落常见为 sniffer（字段名随版本略有差异）。下面是一段结构性示例，用于说明「开启嗅探 + 对常见端口嗅 TLS/HTTP」的写法；请与你当前内核文档核对键名与默认值：

sniffer — Meta-style example (verify against your version)

sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
    HTTP:
      ports: [80, 8080-8880]
  skip-domain:
    - '+.example.com'

对内网设备，若你希望完全不走嗅探（减少不必要的解析开销或避免误判），可通过 skip-src-ip / skip-dst-ip（若你的版本支持）跳过私网源或目的地址段，把嗅探主要留给公网 HTTPS。具体键名请以你所用版本的官方 Wiki 为准。若嗅探开启后反而出现异常，优先检查是否与某条「全局嗅探覆盖」冲突，再尝试收窄端口或域名跳过列表。

客户端能力与内核版本会影响菜单位置与是否暴露嗅探选项；若你刚换发行版，可先读如何选择适合自己的 Clash 客户端，避免在旧版界面上找不存在的开关。

TUN 与系统代理场景下的差异

系统代理模式下，只有遵循系统代理的应用会把流量交给 Clash，许多本地服务、局域网扫描工具可能根本不经过代理，此时你看到的「路由器打不开」往往更单纯，多半是规则或 DNS。开启 TUN 后，系统级流量被虚拟网卡接管，私网访问也必须依赖正确的直连规则与路由排除，否则整包可能被送往远端。若你在同一台机器上同时折腾过 TUN、系统代理与企业 VPN，还要留意路由表优先级是否把内网又绕了一圈。

实践上建议：先在不启用 TUN 的情况下验证「仅规则 + DNS」能否恢复内网访问；再打开 TUN 做二次验证。这样一旦异常，可以快速判断是「全局接管」引入的问题，还是 Fake-IP 本身。更多 TUN 细节仍以 TUN 深度一文为准，本文不再重复栈实现细节。

路由器后台与 HTTPS 证书提示

许多新款路由器管理页强制 HTTPS，且使用私有证书或自签名证书。浏览器出现「不安全」或拦截提示时，这与 Clash 无必然关系，但若中间经过了错误代理或嗅探改写，也可能放大证书告警。确认直连已生效后，再决定是否在浏览器里临时信任该证书或改用 HTTP 管理口（若厂商仍提供）。企业或校园网环境下，另需区分强制门户（Captive Portal）与 Fake-IP：认证页未通过前，部分请求会一直失败，这与内网规则是两类问题。

若仅在某一浏览器内核下无法打开，可换一个浏览器或关闭「HTTPS 仅模式」类插件做对照。打印机、扫描仪类页面往往仍使用 HTTP，相对不容易遇到证书链问题，但若设备通过主机名访问，仍要回到上一节的 DNS 与 fake-ip-filter。

排查清单与延伸阅读

按下面顺序执行，可以少改无关变量，尽快恢复局域网访问与路由器后台。

区分访问方式是纯 IP还是域名，后者必须检查 DNS 与 fake-ip-filter。
在规则表前部为 RFC1918 私网段配置 DIRECT，IP-CIDR 搭配 no-resolve 避免副作用。
确认 fake-ip-range 不与现有局域网、VPN 网段重叠。
在 TUN 模式下复查：直连规则是否仍优先于其它 PROXY 规则，必要时暂时简化策略组做对照。
需要按域名分流且连接仅有 IP 信息时，再考虑开启或调整嗅探，并配合跳过列表缩小影响面。
仍无法归因时，结合连接日志看是 DNS、dial 还是 TLS 层失败。
通用选项与界面差异可参考常见问题中与 DNS、模式相关的条目。

把私网直连、DNS 真实解析与嗅探补全域名三件事分开理解，Fake-IP 与内网之间的冲突就不难拆。相比盲目关闭 Fake-IP 或整段退回 Redir-Host，有选择地加规则与过滤列表，往往能在保留公网体验的同时，让 NAS、打印机和路由器管理页恢复稳定。

结语

Clash Fake-IP 的设计目标并不是妨碍局域网访问，而是与绕过规则、DNS 过滤和（在 TUN 下）嗅探协同工作。当你按顺序补齐私网直连、域名真实解析，并在确实需要时再打开嗅探，大多数「开了 Fake-IP 就进不了路由器」的案例都能落地到可解释的配置变更，而不是靠重装或换节点碰运气。

相比把选项藏得很深的工具，一款能把 DNS 模式、Fake-IP 范围与规则优先级展示清楚、并兼容 Meta 系内核特性的客户端，会让你在调整内网直连时少踩坑。若你也在意长期可维护性，值得选界面与内核版本都跟得上生态演进的产品。

→ 立即免费下载 Clash，开启流畅上网新体验，在理顺 Fake-IP 与内网规则之后，用更直观的方式管理分流与 DNS。

Clash Fake-IP 模式下局域网与路由器后台打不开？绕过规则与嗅探配置步骤