Clash Fake-IP에서 LAN·공유기 접속 막힐 때 우회·스니핑

Fake-IP와 LAN·공유기가 충돌하는 이유

Clash의 DNS enhanced-mode: fake-ip는 애플리케이션이 이름을 물었을 때, 실제 업스트림 확인 전에 가짜 IP(보통 198.18.0.0/16 대역)를 빠르게 돌려주는 방식입니다. 이렇게 하면 「DNS만 보고 나간다」는 류의 누수를 줄이고, 도메인 기준 규칙 매칭을 안정적으로 가져가기 쉽습니다. 그런데 처음부터 IP 주소만으로 접속하는 경우(예: 브라우저 주소창에 192.168.0.1 입력)나, mDNS·로컬 전용 이름(*.local, NAS 호스트명)은 Fake-IP DNS 응답과 무관하게 동작해야 하는데, 규칙이 사설 대역을 프록시 쪽으로 보내거나, Fake-IP 풀과 실제 목적지가 꼬이면 「같은 집 안」 주소인데도 연결이 실패하거나 타임아웃처럼 보일 수 있습니다.

또 한 축은 순수 IP로 붙는 TLS입니다. SNI 없이 IP만으로 연결하면 도메인 규칙을 적용하기 어렵고, 이때는 스니퍼(sniffing)로 TLS ClientHello에서 이름을 복원하거나, 아예 사설 대역은 DIRECT로 고정하는 편이 안전합니다. 원격 서버 타임아웃·TLS 오류가 섞여 보일 때는 연결 로그 가이드와 함께 보시되, 본문에서는 먼저 LAN·공유기 층을 분리합니다.

ℹ 용어: 이 글에서 우회는 「해당 트래픽을 프록시 노드로 보내지 않고 DIRECT(직접 연결)로 보낸다」는 뜻입니다. 클라이언트·코어 버전에 따라 YAML 키 이름이 조금 다를 수 있으므로, UI에서 동일 의미의 항목을 찾아 맞추면 됩니다.

흔한 증상: 192.168, NAS, 프린터, 관리 페이지

아래는 Fake-IP·글로벌 규칙 조합에서 자주 나오는 패턴입니다. 모두가 동시에 나타나지는 않습니다.

공유기 관리(http://192.168.0.1 등)가 열리지 않거나, 열렸다가 인증·리다이렉트에서 끊긴다.
NAS 웹 UI·SMB 이름(nas.local)이 간헐적으로만 되거나, 한쪽 프로토콜만 실패한다.
네트워크 프린터·스캐너 검색이 안 되거나, AirPrint 유사 환경에서만 문제가 난다.
브라우저는 되는데 앱만 안 되거나, 그 반대 — 규칙·스니핑·DNS 중 하나가 앱별 경로에 다르게 걸린 경우다.

증상만으로는 「Fake-IP 한 가지」로 단정하기 어렵습니다. 자주 묻는 질문에서도 말하듯, 시스템 프록시/TUN/규칙 모드가 겹치면 같은 URL이라도 경로가 달라질 수 있습니다. 다음 절부터는 설정을 층으로 나눕니다.

1단계: 사설 대역·로컬 이름을 DIRECT로 고정

가장 먼저 할 일은 RFC1918 사설 IPv4와 링크 로컬, 그리고 자주 쓰는 로컬 전용 이름을 규칙 상단에서 DIRECT로 보내는 것입니다. 이렇게 해야 공유기·NAS·프린터가 「프록시 출구」로 잘못 붙는 일을 줄일 수 있습니다. 구체적인 키 이름은 프로필에 따라 rules: 또는 rule-providers:와 조합합니다.

rules 예시 — 사설·로컬 우선 DIRECT (순서는 위에서 아래로 매칭)

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - 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
  - IP-CIDR,169.254.0.0/16,DIRECT,no-resolve
  - GEOIP,private,DIRECT,no-resolve
  # ... 이후에 일반 DOMAIN-SUFFIX, GEOIP, MATCH 등

no-resolve는 IP 기반 규칙에서 불필요한 DNS 조회를 줄이기 위한 표기로, 코어 버전에 따라 생략·기본 동작이 다를 수 있습니다. IPv6를 쓰는 홈 네트워크라면 fe80::/10 등 링크 로컬·ULA 대역도 DIRECT에 추가하는 것을 검토하세요.

DOMAIN-SUFFIX로 local을 넣은 예는 mDNS·일부 NAS 전용 이름에 도움이 될 수 있으나, 기업 내부 도메인과 충돌하지 않는지 확인해야 합니다. 도메인·국가·분류 규칙을 한꺼번에 정리하는 관점은 규칙 라우팅 가이드와 함께 보는 것이 좋습니다.

fake-ip-filter로 Fake-IP 풀에서 제외하기

Fake-IP 모드에서는 특정 도메인·접미사를 실제 DNS로 해석하도록 빼 두는 것이 안전합니다. 그렇지 않으면 로컬 전용 이름이 가짜 IP로 매핑되어, 브라우저가 아닌 서비스가 기대와 다르게 동작할 수 있습니다. Mihomo/Clash Meta 계열에서는 dns.fake-ip-filter·유사 항목으로 표현합니다.

dns 섹션 예시 (핵심만)

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.home.arpa"
    - "router"
    - "time.windows.com"
  nameserver:
    - dhcp://system
    - https://dns.google/dns-query

fake-ip-filter에 넣을 목록은 환경마다 다릅니다. 공유기가 myrouter 같은 짧은 호스트만 쓰는 경우도 있으니, 실제로 쓰는 NAS·프린터·IoT 이름을 몇 개 더 넣는 것이 실전에서 유효합니다. DHCP·ISP가 제공하는 내부 도메인 접미사가 있다면 그것도 후보입니다.

스니퍼(sniffing): 순수 IP·TLS에서 도메인 되살리기

애플리케이션이 도메인 없이 IP로만 연결하면, 규칙 엔진은 도메인 기반 규칙을 적용하기 어렵습니다. 이때 sniffer가 TLS ClientHello의 SNI, HTTP Host 등에서 이름을 복원해 내부적으로 도메인 매칭을 가능하게 합니다. 공유기·NAS 웹 UI가 HTTPS이고 IP로 접속하는 습관이 있다면 특히 유용합니다.

sniffer 예시 (Meta/Mihomo 스타일)

sniffer:
  enable: true
  sniff:
    TLS: { ports: [443, 8443] }
    HTTP: { ports: [80, 8080-8880] }
  force-domain:
    - "+.internal"
  skip-domain:
    - "+.lan"
    - "+.local"
  parse-pure-ip: true

parse-pure-ip는 이름 그대로 순수 IP 연결에서도 스니핑을 시도할지 여부와 관련된 옵션으로, 코어 버전에 따라 키 이름·기본값이 다를 수 있습니다. 스니퍼는 CPU를 조금 쓰고, 일부 앱과 충돌 보고가 있을 수 있으니 필요할 때만 켜고, skip-domain으로 로컬 이름을 제외하는 편이 안전합니다.

스니퍼를 켠 뒤에도 증상이 남으면, 규칙이 MATCH 이전에 GEOIP/DIRECT를 충분히 넣었는지, DNS가 구독 제공자와 충돌하지 않는지 다시 봅니다. TUN 전체 캡처 환경에서는 경로가 더 복잡하므로 TUN 모드 심화 글의 DNS·라우팅 절을 참고하세요.

규칙 순서·GEOIP·MATCH와의 관계

Clash 계열은 위에서 아래로 첫 매칭이 적용되는 경우가 많습니다. 그래서 IP-CIDR로 사설을 DIRECT에 넣었는데도, 그보다 위에 있는 DOMAIN-KEYWORD나 광범위한 MATCH가 먼저 걸리면 의도와 다르게 프록시로 나갈 수 있습니다. 특히 구독에서 가져온 RULE-SET이 앞쪽에 있으면, 로컬 우회 규칙을 그보다 위에 두었는지 확인하세요.

GEOIP,private,DIRECT,no-resolve는 편리하지만, 데이터베이스 경로·업데이트가 맞지 않으면 기대와 다르게 동작할 수 있습니다. 사설 대역은 IP-CIDR로 명시하는 편이 재현성이 높습니다. 마지막 MATCH는 보통 PROXY나 SELECT 그룹으로 두는데, LAN 문제를 끝까지 남기고 싶지 않다면 앞 단계에서 사설·로컬을 충분히 처리했는지 다시 점검합니다.

TUN 모드·시스템 프록시와 함께 쓸 때

TUN을 켜면 시스템 전체 트래픽이 가상 인터페이스로 모입니다. 이때도 exclude-route·bypass·auto-route 계열 옵션으로 사설 대역을 OS 라우팅에서 빼는 구성이 필요할 수 있습니다. 클라이언트가 GUI로 「로컬 네트워크 바이패스」를 제공한다면 함께 켜고, 그래도 안 되면 YAML에서 라우트 예외를 확인합니다.

반대로 시스템 프록시만 쓰는 경우에는 일부 앱이 프록시를 타지 않아 「LAN만 된다/만 안 된다」가 갈릴 수 있습니다. 증상이 앱마다 다르면, 우선 규칙만이 아니라 어떤 경로로 나가는지부터 나누어 보는 것이 좋습니다.

⚠ 보안: 공유기·NAS 관리자 페이지는 항상 최신 펌웨어·강한 비밀번호·가능하면 HTTPS·관리 포트 제한을 권장합니다. 이 글은 합법적으로 소유하거나 관리 권한이 있는 장비에 한해 적용하세요.

실무 체크리스트

rules 상단에 사설 IP 대역·로컬 이름을 DIRECT로 두었는가.
dns.fake-ip-filter(또는 동등 항목)에 집 안에서 쓰는 접미사·호스트를 넣었는가.
스니퍼가 필요하면 켜고, 로컬 이름은 skip-domain 등으로 제외했는가.
RULE-SET·MATCH 순서 때문에 LAN 규칙이 묻히지 않았는가.
TUN 사용 시 라우트 예외·클라이언트 바이패스를 함께 검토했는가.
그래도 원격 쪽 의심이 남으면 로그 글로 넘어갈 타이밍인가.

마무리

Clash Fake-IP는 인터넷 쪽 도메인 분기에는 강력하지만, 사설 IP·로컬 이름은 그대로 두면 오히려 길을 잃기 쉽습니다. DIRECT 규칙으로 대역을 먼저 고정하고, fake-ip-filter로 DNS 해석 경로를 정리한 뒤, 필요 시 sniffing으로 순수 IP·TLS 흐름에 이름을 붙이면 — 같은 증상이라도 「규칙 한 줄」로 끝나는 경우가 많아집니다. 설정을 손볼 때마다 한 가지씩만 바꾸고, 연결 로그로 기대한 경로로 나갔는지 확인하는 습관을 들이면 재시도 시간을 크게 줄일 수 있습니다.

Clash 계열 클라이언트는 코어 옵션을 얼마나 읽기 쉽게 보여 주느냐에 따라 같은 YAML이라도 실수 빈도가 달라집니다. 규칙·DNS·TUN을 한 화면에서 다루기 쉬운 빌드를 쓰면, LAN 우회와 인터넷 프록시를 번갈아 테스트할 때 부담이 줄어듭니다.

→ Fake-IP와 LAN 우회를 정리한 뒤, Clash를 무료로 받아 프로필을 한곳에서 맞춰 보세요.

Clash Fake-IP 모드에서 192.168·NAS·공유기 관리 페이지가 안 열릴 때: 우회 규칙과 스니핑(sniffing) 설정