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.enable이 true인지, 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-ip와 redir-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 설정도 한 번에 정리하는 편이 좋습니다.
로그로 검증하는 짧은 절차
- 문제가 나는 스트리밍 앱만 켜고, 코어 로그에서 해당 세션의 스니핑된 호스트·적용된 규칙 이름을 확인합니다.
- 호스트가 비어 있으면 Sniffer 포트·프로토콜·override부터 다시 봅니다.
- 호스트는 있는데 규칙이
GEOIP·IP-CIDR쪽이면 규칙 순서를 수정합니다. - 도메인 규칙인데도 엇나가면 DNS 모드와
fake-ip-filter를 의심합니다.
주의: 타인이 제공한 구독·규칙 세트는 악성 아웃바운드로 바뀔 수 있습니다. 출처를 신뢰하고, 로그에 이상한 도메인이 보이면 즉시 중단하세요. 스트리밍 지역·약관을 우회하는 구성은 해당 서비스 정책과 현지 법률을 준수해야 합니다.
마무리
정리하면, Clash Sniffer는 도메인 기반 규칙을 살리는 도구이지만, 스위치 한 번으로 끝나지 않고 override-destination·규칙 순서·DNS fake-ip와 세트로 맞춰야 스트리밍·앱 트래픽이 기대한 경로로 갑니다. 한 항목만 고치고 나머지를 그대로 두면 같은 증상이 반복되기 쉽습니다.
같은 범주의 도구들과 비교해 보면, Mihomo 생태계는 스니퍼·DNS·TUN을 한 프로필에 묶어 다룰 수 있어 튜닝 여지가 큽니다. GUI에서 항목을 바꾼 뒤에는 반드시 프로필이 저장·재로드됐는지 확인하고, 필요할 때만 YAML을 직접 편집하는 식으로 부담을 줄일 수 있습니다.
지금 환경에 맞는 클라이언트로 바로 점검해 보시려면 Clash를 무료로 다운로드한 뒤, 최신 Mihomo 커널과 함께 위 순서대로 Sniffer·DNS·규칙을 맞춰 보시길 권합니다. 설정이 한 줄씩 들어맞을 때 스트리밍 분기도 안정적으로 따라옵니다.