Clash Sniffer가 안 먹힐 때: mihomo 스트리밍 도메인 인식과 규칙 수정 절차

왜 Sniffer를 켰는데도 스트리밍 규칙이 어긋날까요?

Clash Sniffer(Mihomo·Clash Meta 계열에서 통칭해 sniffer 또는 sniff 설정으로 표현)는 TLS·QUIC 등 연결에서 도메인 이름을 복원해, 처음에는 IP만 보이던 흐름을 DOMAIN-SUFFIX 같은 도메인 규칙에 걸 수 있게 돕는 기능입니다. 그런데 설정에서 스위치만 켠 뒤에도 스트리밍·OTT 앱이 여전히 잘못된 프록시 그룹으로 가거나, 아예 DIRECT·MATCH에 떨어진다고 느껴지는 경우가 많습니다.

이 글에서는 “Sniffer 자체”를 축으로 ① 스니퍼 활성화와 포트, ② 목적지 덮어쓰기(override destination), ③ 규칙 우선순위, ④ DNS 모드와 fake-ip를 한 줄씩 맞추는 순서를 제시합니다. TUN 전체 설명은 TUN 모드 가이드를, 규칙 문법의 큰 그림은 규칙 분할 가이드와 함께 보시면 흐름이 잡힙니다. 사이트 전체 목차는 문서·튜토리얼에서도 확인할 수 있습니다.

Sniffer가 해 주는 일과 한계

프록시 코어가 연결을 맨 처음 받을 때, 목적지가 순수 IP로만 잡히면 DOMAIN·DOMAIN-SUFFIX 규칙은 원칙적으로 매칭할 근거가 없습니다. 이때 Sniffer는 TLS ClientHello의 SNI, HTTP의 Host, QUIC 초기 패킷 등에서 호스트명을 읽어 “이 연결은 사실 이 도메인이다”라고 라벨을 붙입니다. 그 결과, 같은 IP를 쓰는 CDN 뒤에 있어도 스트리밍 전용 DOMAIN-SUFFIX 줄을 타게 할 수 있습니다.

한계도 분명합니다. 앱이 ECH 등으로 SNI를 가리거나, 비표준 포트·내부 전용 프로토콜만 쓰면 스니핑이 비어 있을 수 있습니다. 또 Sniffer는 DNS 해석 결과와 규칙 엔진이 서로 다른 이름을 들고 있을 때(특히 fake-ip 모드) 혼선을 키우기도 해서, 아래 DNS 절을 함께 봐야 합니다.

참고: 커널이 구버전이면 Sniffer 동작과 호환 키 이름이 다를 수 있습니다. 장기적으로는 Mihomo·Clash Meta 업그레이드 가이드에 맞춰 최신 안정 버전을 쓰는 것이 안전합니다.

1단계: sniffer 블록이 실제로 켜졌는지

프로필 YAML에서 sniffer.enabletrue인지, GUI라면 해당 토글이 저장됐는지 먼저 확인합니다. sniff 하위에 TLS·QUIC·필요 시 HTTP 포트 범위가 빠져 있으면, 실제 앱이 쓰는 포트가 스니핑 대상에 없어 무시될 수 있습니다. 스트리밍은 대부분 443·UDP 443(QUIC)이 중심이지만, 일부 환경에서는 추가 포트가 열립니다.

아래는 Mihomo 계열에서 자주 쓰이는 형태의 예시 스니펫입니다. 구독이 덮어쓰는지 여부에 따라 최종 병합 결과를 꼭 확인하세요.

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports:
        - 443
  force-dns-mapping: true
  parse-pure-ip: true

force-dns-mapping·parse-pure-ip는 버전에 따라 기본값이 다를 수 있어, 공식 문서와 릴리스 노트를 함께 보는 것이 좋습니다. 설정 후에는 대시보드나 로그에서 해당 연결이 스니핑된 호스트명으로 표시되는지 확인합니다.

2단계: override-destination과 스트리밍

스니핑으로 호스트명을 알아낸 뒤에도, 코어가 여전히 “처음에 잡힌 IP 목적지”만으로 라우팅을 계속하면 규칙 매칭이 기대와 다를 수 있습니다. 이때 override-destination(또는 스니퍼·인바운드 설정에 따라 동일 의미의 옵션)을 켜면, 스니핑된 도메인을 기준으로 규칙 재평가가 일어나기 쉽습니다.

일부 클라이언트는 TLS·HTTP 스니프 항목마다 이 값을 개별 지정합니다. 스트리밍만 문제이고 웹은 정상일 때, 해당 프로토콜 블록의 override-destination만 조정해 보는 방식이 실무에서 자주 쓰입니다.

sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
      override-destination: true
    QUIC:
      ports: [443]
      override-destination: true

팁: “스니핑은 되는데 규칙 이름이 여전히 IP 기반이다”라면 override 쪽을 의심하고, 반대로 지연·호환 문제가 생기면 일시적으로 끄고 비교 실험을 하세요.

3단계: DOMAIN-SUFFIX 규칙 위치와 스트리밍 전용 그룹

Clash 계열은 위에서 아래로 첫 매칭이 이깁니다. GEOIP,CN나 광범위한 IP-CIDR가 먼저 나오면, 스트리밍용 DOMAIN-SUFFIX,example.com,STREAM이 아래에 있어도 도달하지 못합니다. Sniffer로 도메인이 살아났다면, 해당 DOMAIN·DOMAIN-SUFFIX 줄을 스트리밍·해외 전용 정책이 필요한 위치로 끌어올리세요.

복사해 프로필에 맞게 그룹 이름만 바꿔 쓸 수 있는 규칙 예시입니다(STREAM은 사용자 정의 프록시 그룹 이름으로 가정).

rules:
  - DOMAIN-SUFFIX,netflix.com,STREAM
  - DOMAIN-SUFFIX,nflxvideo.net,STREAM
  - DOMAIN-SUFFIX,akamaihd.net,STREAM
  - DOMAIN-SUFFIX,googlevideo.com,STREAM
  # ... 중략: 국내·LAN DIRECT 등 ...
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

실제 서비스는 CDN·인증 호스트가 여러 개라, 한 줄만 넣고 끝내기 어렵습니다. 연결 로그에 찍힌 호스트를 보며 DOMAIN-SUFFIX를 보강하는 방식이 가장 확실합니다. OTT별로 묶은 글이 필요하면 Disney+ 분할 규칙 가이드처럼 서비스별로 도메인 축을 참고할 수 있습니다.

4단계: DNS 모드 — fake-ipredir-host

fake-ip 모드는 빠른 체감과 캐시 이점이 있지만, Sniffer·도메인 규칙과 엮이면 “DNS로는 A 레코드가 가짜 IP인데, 스니핑 이름은 다른 호스트” 같은 불일치가 생기기도 합니다. 이때는 fake-ip-filter에 스트리밍 관련 도메인을 넣어 실제 IP로 해석되게 하거나, 문제가 반복되면 일시적으로 redir-host 위주로 바꿔 원인을 가르는 방법이 있습니다.

핵심은 “규칙 엔진이 최종적으로 어떤 문자열(도메인·IP)을 들고 매칭하는가”를 로그로 확인하는 것입니다. dns.enhanced-mode·nameserver·fallback이 과도하게 느리면 앱이 먼저 붙어 버려 스니핑 타이밍과 어긋날 수도 있으니, DNS 전용으로 안정적인 업스트림을 쓰는 것도 함께 점검합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.netflix.com"
    - "+.nflxvideo.net"

fake-ip-filter 항목은 서비스·앱에 맞게 조정해야 하며, 위 목록은 예시입니다. 국내 ISP DNS만 쓰는 단말과 Clash DNS를 동시에 쓰는 환경에서는 이중 해석으로 규칙이 흔들릴 수 있으니, 시스템 DNS·프라이빗 DNS 설정도 한 번에 정리하는 편이 좋습니다.

로그로 검증하는 짧은 절차

  1. 문제가 나는 스트리밍 앱만 켜고, 코어 로그에서 해당 세션의 스니핑된 호스트·적용된 규칙 이름을 확인합니다.
  2. 호스트가 비어 있으면 Sniffer 포트·프로토콜·override부터 다시 봅니다.
  3. 호스트는 있는데 규칙이 GEOIP·IP-CIDR 쪽이면 규칙 순서를 수정합니다.
  4. 도메인 규칙인데도 엇나가면 DNS 모드와 fake-ip-filter를 의심합니다.

주의: 타인이 제공한 구독·규칙 세트는 악성 아웃바운드로 바뀔 수 있습니다. 출처를 신뢰하고, 로그에 이상한 도메인이 보이면 즉시 중단하세요. 스트리밍 지역·약관을 우회하는 구성은 해당 서비스 정책과 현지 법률을 준수해야 합니다.

마무리

정리하면, Clash Sniffer는 도메인 기반 규칙을 살리는 도구이지만, 스위치 한 번으로 끝나지 않고 override-destination·규칙 순서·DNS fake-ip와 세트로 맞춰야 스트리밍·앱 트래픽이 기대한 경로로 갑니다. 한 항목만 고치고 나머지를 그대로 두면 같은 증상이 반복되기 쉽습니다.

같은 범주의 도구들과 비교해 보면, Mihomo 생태계는 스니퍼·DNS·TUN을 한 프로필에 묶어 다룰 수 있어 튜닝 여지가 큽니다. GUI에서 항목을 바꾼 뒤에는 반드시 프로필이 저장·재로드됐는지 확인하고, 필요할 때만 YAML을 직접 편집하는 식으로 부담을 줄일 수 있습니다.

지금 환경에 맞는 클라이언트로 바로 점검해 보시려면 Clash를 무료로 다운로드한 뒤, 최신 Mihomo 커널과 함께 위 순서대로 Sniffer·DNS·규칙을 맞춰 보시길 권합니다. 설정이 한 줄씩 들어맞을 때 스트리밍 분기도 안정적으로 따라옵니다.