Why Fake-IP Breaks Local and Router Access

In fake-ip mode, Clash’s DNS module answers application queries with addresses carved out of a configurable pool—commonly something like 198.18.0.0/16—instead of returning the true A/AAAA records your LAN would use. The design goal is elegant: every outbound connection is tagged with metadata Clash understands, so domain rules, policy groups, and fallback logic stay coherent even when upstream DNS is encrypted or split. The side effect is equally predictable. Anything that was supposed to resolve to 192.168.0.0/16, 10.0.0.0/8, or 172.16.0.0/12 may never surface as those RFC1918 addresses at the moment the socket is built, which breaks assumptions baked into browser tabs, printer portals, and cheap router landing pages that only listen on the LAN.

Router administration URLs are an especially confusing case because many vendors publish friendly hostnames that resolve to private addresses through ordinary DNS when the proxy is off. Under Fake-IP, the friendly name might still map into the synthetic range for a while, or the connection might be classified before the kernel path matches what you expect. NAS boxes and IP cameras often ship with HTTPS on odd ports; without the correct server name inside the TLS ClientHello, your DOMAIN-SUFFIX lines never fire, and the packet falls through to a generic proxy policy that cannot reach RFC1918 peers. That is where sniffing enters: it recovers hostnames from cleartext HTTP, TLS SNI, and certain QUIC stacks so routing decisions can use names again instead of only raw IPs.

If you are also running TUN mode, the interaction stack is deeper. TUN pulls traffic at Layer 3; Fake-IP shapes DNS; rules decide policy; sniffing rebuilds semantic information the IP layer lost. Our TUN mode deep dive walks the architecture—pair that mental model with the bypass patterns below and you will spend less time blaming “the subscription” for what is fundamentally a local-routing problem.

ℹ Principle: Fake-IP is a DNS strategy, not a substitute for RFC1918 reachability. You still need explicit DIRECT paths for private ranges and, for name-based rules on encrypted traffic, sniffing that exposes the hostname to the rule engine.

Bypass Private IPv4: Rules You Can Paste

The most reliable first layer is to send all non-public IPv4 space straight out the physical interface. Clash evaluates rules from top to bottom; place these lines above broad catch-alls such as GEOIP or MATCH. The following fragment is intentionally conservative: it covers typical home LAN segments, carrier-grade NAT corners you might see on tethering, and link-local quirks that occasionally surface in misconfigured captive portals.

rules — RFC1918 and common LAN bypass (YAML) 
rules:
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,169.254.0.0/16,DIRECT
  - IP-CIDR,100.64.0.0/10,DIRECT

Some users prefer a shorter notation via a rule-provider that tracks private CIDRs from a maintained list; that scales better on teams. For a single machine, six IP-CIDR lines are easy to audit in place. If your NAS or printer sits on an unusual subnet—say an isolated VLAN at 10.20.30.0/24—extend the list deliberately rather than widening masks blindly; over-broad DIRECT exceptions can accidentally punch holes in policies you meant to keep under policy routing.

IPv6 adds another wrinkle. If your LAN uses ULA or global IPv6 for management interfaces, mirror the same philosophy with IP-CIDR6 entries for fc00::/7, fe80::/10, and your own prefix if you publish one. Many home users still run IPv4-only on router GUIs; if you are IPv6-only on a segment, test with ping -6 and watch whether Clash logs show the flow as domestic direct traffic. For broader policy design—when to stack GEOIP with domestic providers—our rules and routing best practices article complements these LAN-specific lines without turning your profile into an unreadable spreadsheet.

Rule Order, MATCH, and When DIRECT Wins

A frequent mistake is tucking RFC1918 bypasses below a GEOIP,cn line or a subscription-driven MATCH that sends “everything else” to a remote node. Clash does not magically prioritize “obvious LAN” traffic; the first matching rule wins. If your catch-all proxy sits above private CIDR lines, you will still observe timeouts that look like DNS failures even though the real issue is policy order. Move LAN exceptions up, then keep your regional and domain rules, then finish with MATCH.

Another subtle case is split intranet DNS. Some enterprises resolve internal hostnames to RFC1918 addresses only when the resolver is on VPN or office Wi-Fi. If your profile forces all DNS through Clash while Fake-IP is on, verify that internal suffixes either appear in fake-ip-filter (covered later) or resolve consistently through a resolver that knows your campus split-horizon zones. Otherwise you will chase “proxy slowness” when the resolver never handed Clash a meaningful mapping in the first place. The FAQ section on connectivity and DNS explains how resolver choice and rule-based tools interact—worth reading if you mix corporate VPN names with home LAN devices on one laptop.

GEOIP private shortcuts

Meta-class cores often ship a built-in GEOIP,private style shortcut that expands to the same private ranges. Syntax varies slightly between forks; consult your core’s documentation for the exact token. When available, it keeps the ruleset compact, but explicit CIDR lines remain excellent for transparency in tutorials because they show up identically in screenshots across versions.

Sniffing: Hostnames for TLS, HTTP, and QUIC

After IP-level bypasses, the next failure mode is name-based. Suppose you wrote DOMAIN-SUFFIX,local,DIRECT for Bonjour-style names, or you rely on vendor domains like routerlogin.net. Under TLS, the first meaningful identifier is often the Server Name Indication in the ClientHello. If Clash never extracts that SNI, your domain rules do not run, and the flow rides whatever default policy you set for “unknown TCP,” which might still be a remote proxy that cannot reach RFC1918 peers.

Sniffing solves that by parsing protocols where hostnames appear in cleartext: plain HTTP Host headers, TLS ClientHello SNI, and in supported stacks, QUIC Initial packets. Enable it according to your core’s schema—typically a top-level sniffing map with per-protocol toggles and an override destination option so the reconstructed hostname participates in routing.

sniffing — Meta-style example (adjust to your core version) 
sniffing:
  enable: true
  sniff:
    HTTP: { ports: [80, 8080-8880], override-destination: true }
    TLS: { ports: [443, 8443], override-destination: true }
  force-domain:
    - '+.routerlogin.net'
    - '+.tplinkwifi.net'
  skip-domain:
    - 'Mijia Cloud'
    - '+.apple.com'

The force-domain and skip-domain lists are powerful: they let you insist on sniffing for vendor portals that misbehave unless SNI is honored, or exclude chatty Apple and IoT endpoints that generate noise. Start minimal—only add force entries when you confirm a specific admin UI still misses domain rules in logs. For QUIC-heavy clients, confirm whether your build supports QUIC sniffing; if not, temporarily test the same site with QUIC disabled in the browser to separate protocol issues from routing issues.

Sniffing is not a privacy feature; it is a traffic-classification aid. Treat override-destination as a scalpel: enabling it globally can have side effects on rare split-DNS setups. Validate with short experiments, then keep the narrowest force list that restores your router page. If log lines still confuse you after enabling sniffing, the vocabulary section in our connection logs and TLS troubleshooting guide helps map symptoms to concrete settings instead of guessing.

⚠ Note: Some embedded devices use certificate pinning or nonstandard TLS ports. If SNI is absent or encrypted early, even perfect sniffing cannot recover a hostname—fall back to IP-CIDR bypasses and direct IP bookmarks for those appliances.

DNS: fake-ip-filter and Local Hostnames

DNS is half of the Fake-IP story. Alongside rules and sniffing, maintain a fake-ip-filter (sometimes described as “skip fake-ip for these names”) that lists LAN and portal hostnames which should receive real responses from your designated nameservers. Typical entries include *.lan, *.local, your NAS DDNS suffix, and the router brand domains you actually type in the address bar.

dns — fake-ip with filter skeleton (YAML) 
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'tplinkwifi.net'
    - 'routerlogin.net'
    - 'myrouter.local'
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - https://dns.google/dns-query

The exact keys differ slightly between Clash Premium, Meta, and downstream GUIs; always mirror what your client exported when it generated the baseline profile. The intent is stable: tell the DNS stage, “do not hand out synthetic addresses for these names,” so the OS stack sees authentic RFC1918 targets that align with your IP-CIDR bypasses. If you skip the filter but keep aggressive remote nameservers, you may still get wrong answers for split-horizon names—pair filtering with a resolver policy that forwards local suffixes to your router or Pi-hole when needed.

When debugging, temporarily switch a single test machine to redir-host or disable Fake-IP only on that profile clone. If LAN sites instantly return while Fake-IP is off, you have confirmed the diagnosis without arguing about upstream nodes. That A/B test is faster than editing twenty unrelated proxy groups. For choosing a GUI that exposes DNS and sniffing clearly, see how to choose a Clash client—transparent panels reduce the trial-and-error loop when you flip between modes.

TUN, System Proxy, and Double-Proxy Pitfalls

Running TUN alongside Fake-IP means the OS routing table already sends most traffic toward the tunnel interface. Your RFC1918 DIRECT rules still matter, but so does interface selection: some stacks need auto-detect-interface and sane strict-route settings to avoid asymmetry where return packets leak around the tunnel. If LAN TCP works for pings but browser HTTPS to the router stalls, capture whether the flow is classified as domestic direct in logs; if not, sniffing or DNS filtering is still missing—not the tunnel MTU.

System proxy configurations (HTTP/SOCKS without TUN) interact differently: applications that bypass the system proxy entirely will not show up in Clash unless they honor environment variables or you move to TUN. Conversely, a browser pointed at Clash while Fake-IP is on may still succeed for LAN if your bypass rules precede proxy forwarding—just remember extension-based proxies and per-app overrides can split traffic in ways the core never sees. Keep one mode dominant during testing to avoid “it works in Firefox but not Chrome” mysteries that are really two different proxy chains.

Verify: Logs, Ping, and Browser Checks

Work through verification in small steps so you know which layer you fixed.

  1. Baseline connectivity: With Clash paused, open the router page and a NAS bookmark. Confirm hardware and cabling are sound before touching YAML.
  2. IP bypass sanity: Enable Clash with only the RFC1918 IP-CIDR lines inserted near the top. Retry the same URLs. If raw IPs like http://192.168.1.1 work but names fail, prioritize DNS filter entries next.
  3. Sniffing on: Toggle sniffing with conservative ports, retry HTTPS portals. Read the live log: you should see domain fields populated for TLS flows.
  4. DNS filter: Add the specific failing hostname to fake-ip-filter, reload, retest. Watch for cached DNS in the OS—flush or short TTLs during tests.
  5. Regression guard: Ensure subscription updates or remote rule providers did not prepend new rules above your LAN exceptions—pin order in your editor if your GUI reorders blindly.

Document the final working trio: the exact CIDR lines, the sniffing block, and the three to five DNS filter entries that mattered. Future you—and anyone sharing your profile—will thank you when a vendor firmware update changes a portal hostname slightly.

Wrap-Up

Fake-IP trades transparent DNS semantics for routing power; LAN and router access fails when that trade collides with RFC1918 reality. Fixing it is procedural: private-range DIRECT rules first, sniffing for TLS hostnames second, DNS fake-ip-filter third, then TUN and client-mode sanity checks. Compared with opaque one-click tools that hide DNS mode entirely, a maintained client with readable YAML lets you treat home network access as engineering work with a checklist—not superstition.

→ Download Clash for free and experience the difference once your bypass, sniffing, and DNS filters line up with how you actually browse at home.