Clash Meta Sniffer: HTTPS 도메인 분류 (2026)

왜 로그에는 IP만 보이고 규칙이 빗나갈까

브라우저 주소창에는 도메인이 보여도, 프록시 코어가 보는 첫 연결 정보는 “어느 IP의 몇 번 포트로 TCP를 열었는가”에 가깝습니다. HTTPS는 그 위에서 TLS를 올리고, 그 안의 SNI(Server Name Indication)에 접속하려는 호스트 이름이 실립니다. 스니퍼를 끈 상태에서는 코어가 이 이름을 규칙 단계에 넘기지 못해 IP·GEOIP 쪽으로만 판단이 기울기 쉽습니다. 그 결과 DOMAIN-SUFFIX,example.com,PROXY 같은 줄을 넣어 두어도, 실제 매칭 단계에서는 “example.com이 아니라 알 수 없는 IP”로만 보이는 상황이 생깁니다.

반대로 말하면, 스니퍼가 이름을 복원해 주면 같은 rules 배열이라도 DOMAIN·GEOSITE·RULE-SET이 의도대로 작동할 여지가 커집니다. 다만 스니퍼는 만능이 아니며, 클라이언트·서버·중간 장비 설정에 따라 SNI가 비어 있거나 QUIC 경로만 타는 등 예외가 있습니다. 그런 경우에는 PROCESS-NAME으로 발신 프로세스를 묶거나, DNS 쪽 의존도를 조정하는 식으로 보완합니다.

1전제: RULE 모드, 트래픽이 코어를 통과하는지

스니퍼는 “코어가 연결의 첫 패킷을 볼 수 있을 때” 의미가 있습니다. 시스템 프록시만 켠 브라우저와 달리, 일부 앱은 프록시를 무시하고 직접 나갑니다. 실무에서는 TUN이나 클라이언트가 제공하는 전역 캡처 경로를 켠 뒤 문제를 재현하는 경우가 많습니다. TUN 튜토리얼에서 OS별 활성화·권한을 마친 뒤 이 글의 YAML을 적용하세요.

mode는 rule이어야 도메인·지역 기반 줄이 평가됩니다. 글로벌/직결만 쓰는 동안은 스니퍼를 켜도 체감이 거의 없을 수 있습니다. 또한 DNS가 시스템·공유기·별도 앱에 분산되면 FakeIP와 실제 응답이 엇갈려 “규칙은 맞는데 현상만 이상하다”가 됩니다. 이때는 Meta 코어 DNS 유출 방지 가이드의 점검 순서를 먼저 맞추는 편이 안전합니다.

주의: 스니퍼는 트래픽 일부를 해석하는 기능이라, 프라이버시·보안 정책이 엄한 환경에서는 사용 여부를 내부 규정과 맞춰야 합니다. 또한 코어 버전에 따라 키 이름·기본값이 조금씩 다를 수 있으니, 사용 중인 Mihomo 릴리스 노트를 함께 확인하세요.

2Sniffer가 하는 일: TLS·QUIC·HTTP에서 이름 얻기

요약하면, 스니퍼는 연결 초기에 지나가는 바이트에서 호스트 힌트를 뽑아 규칙 엔진에 넘깁니다. 대표적으로 TLS의 ClientHello에 실리는 SNI, HTTP의 Host 헤더, 환경에 따라 QUIC 초기 패킷의 관련 필드를 다룹니다. 이름이 확보되면 DOMAIN 계열 규칙이 “IP만 보이던 연결”에도 적용될 수 있습니다.

이름이 안 보이는 대표 사례는 순수 IP로만 접속하는 클라이언트, 일부 QUIC 경로, 중간에서 SNI를 가리는 환경 등입니다. 이때는 스니퍼만으로는 부족하고, DNS 정책·프로세스 규칙·앱 설정 변경을 함께 봐야 합니다.

3설정 파일에 sniffer 블록 넣기

프로필 최상위(보통 port·mixed-port 근처)에 sniffer 블록을 둡니다. 아래는 개념을 잡기 위한 스케치이며, 실제 키·기본값은 사용 중인 코어 버전 문서를 따르세요.

# Sketch — merge into your real profile; keys may vary by Mihomo version
sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443]
  # Optional tuning (names differ by version — verify in official docs):
  # force-dns-mapping: true
  # parse-pure-ip: true
  # override-destination: false

enable: true가 핵심입니다. sniff 아래에는 프로토콜별로 “어떤 포트에서 초기 패킷을 볼지”를 적습니다. 443이 아닌 포트로 HTTPS를 쓰는 사내 서비스가 있으면 TLS 포트 목록에 포함해야 합니다. 반대로 불필요하게 넓은 포트 범위를 잡으면 해석 부담만 늘 수 있으니, 운영 환경에 맞게 좁히는 것이 좋습니다.

팁: GUI 클라이언트는 같은 옵션을 토글과 입력란으로 노출합니다. YAML을 직접 편집할 때는 들여쓰기·콜론 위치를 한 번에 맞추고, 저장 후 설정 재로드가 실패하지 않는지부터 확인하세요.

4FakeIP·fake-ip-filter와 같이 보기

FakeIP 모드는 응답을 빠르게 돌려 주기 위해 로컬에 가짜 주소를 주는 쪽에 가깝습니다. 이때 애플리케이션이 실제로 붙는 대상과 규칙 엔진이 보는 “이름 정보”가 어긋나면, 도메인 규칙이 기대와 다르게 보일 수 있습니다. 스니퍼는 그 간극을 줄이는 도구 중 하나이지만, fake-ip-filter에 넣은 이름·대역과 스니퍼가 복원한 이름이 충돌하지 않는지도 함께 봐야 합니다.

정리하면, DNS 가이드에서 말한 “업스트림 일관성”과 스니퍼의 “연결에서 이름 복원”은 서로 보완 관계입니다. 한쪽만 고치고 다른 쪽을 무시하면 여전히 로그에 이상한 IP만 남습니다. DNS 가이드의 체크리스트와 이 글을 같은 순서로 적용해 보세요.

5규칙 순서: DOMAIN을 쓰려면 위쪽에 둘까

Clash 계열은 rules를 위에서 아래로 평가합니다. 스니퍼가 이름을 채워 준 뒤에도, 그보다 위에 있는 IP·GEOIP 줄에 먼저 걸리면 도메인 규칙까지 도달하지 않습니다. 반대로 너무 광범위한 DOMAIN-KEYWORD를 위에 두면 의도치 않은 트래픽까지 한꺼번에 잡힐 수 있습니다.

실무에서는 (1) 디버깅 중인 소수 호스트에 대한 좁은 DOMAIN-SUFFIX을 (2) 광역 RULE-SET보다 위에 두고, (3) 마지막에 MATCH로 수습하는 패턴이 흔합니다. 팀에서 프로필을 공유한다면 주석으로 “스니퍼 전제 도메인 예외” 구역을 나누어 두면 몇 달 뒤에도 원인 추적이 쉬워집니다.

6TUN·DNS 하이재크와의 정렬

TUN을 켜면 DNS 쿼리도 코어 쪽으로 모이게 할 수 있는 경우가 많습니다. 이때 스니퍼로 복원한 이름과 DNS가 돌려준 IP가 서로 다른 타임라인을 가지면, 브라우저 캐시·OS 캐시 때문에 체감이 엇나갈 수 있습니다. 문제가 반복되면 “한 번에 변수 여러 개”를 바꾸지 말고, DNS 옵션 하나·스니퍼 토글 하나·규칙 블록 하나씩 바꾸며 로그를 비교하세요.

원격 서버에서만 코어를 돌리는 경우에는 Docker 배포 글의 포트·볼륨 전제와 맞는지도 확인합니다. 데스크톱과 서버는 같은 스니퍼 YAML이라도 데이터 경로가 달라 체감이 다를 수 있습니다.

7검증: 연결 로그·Yacd로 이름이 보이는지

설정을 저장한 뒤에는 추측하지 말고 연결 로그를 봅니다. 문제의 사이트에 실제로 접속을 시도한 다음, 해당 행에 호스트명이 채워졌는지·어떤 규칙 줄이 선택됐는지를 확인합니다. GUI가 없다면 external-controller와 웹 패널을 쓰는 방법이 있습니다. 브라우저에서 빠르게 훑으려면 Mihomo·Yacd 패널 가이드를 참고하세요.

로그에 여전히 IP만 보인다면, (1) 스니퍼가 꺼져 있거나 (2) 해당 포트가 sniff 범위 밖이거나 (3) 클라이언트가 SNI 없이 붙는 경로인지 순서대로 의심합니다. 한 가지씩 좁혀 가면 원인 문장이 짧아집니다.

한계와 대안

SNI가 없는 연결: 순수 IP 접속이면 도메인 규칙 자체가 성립하지 않을 수 있습니다.
프로토콜·포트 예외: 비표준 포트 HTTPS는 TLS 포트 목록에 포함되어야 스니퍼가 볼 수 있습니다.
앱별 우회: 도메인 대신 “어느 프로그램이 보냈는가”가 더 중요하면 PROCESS-NAME 글이 더 직접적입니다.
정책·규정: 스니퍼는 패킷 초기를 해석하는 기능이므로, 조직 정책상 사용이 제한될 수 있습니다.

정리

Clash Meta·Mihomo에서 HTTPS 트래픽이 IP로만 보여 DOMAIN·GEOSITE 규칙이 빗나갈 때, Sniffer는 TLS·QUIC·HTTP에서 호스트 힌트를 복원해 규칙 엔진과 맞추는 실전 도구입니다. 전제는 분명합니다. RULE 모드에서 트래픽이 코어를 통과하고, TUN 등 데이터 경로가 준비되어 있으며, DNS·FakeIP 설정과 서로 모순되지 않을 것. 이 위에 sniffer.enable과 sniff 포트를 맞추고, rules 배열에서 순서를 의도에 맞게 두면 같은 구독 규칙이라도 체감이 달라집니다.

설치 패키지는 릴리스 직링크보다 사이트 다운로드 허브에서 고르는 편이 플랫폼·빌드 혼선이 적습니다. 오픈소스 저장소는 신뢰·이슈 확인용으로 두고, 아래 링크에서 클라이언트를 받아 스니퍼 설정을 바로 시험해 보세요.

→ Clash 클라이언트를 무료로 내려받아, Meta 코어와 Sniffer로 HTTPS 도메인 분류를 정리해 보세요

Clash Meta(Mihomo) Sniffer(스니퍼) 켜기: HTTPS에서 도메인 분류 규칙을 살리는 단계별 가이드 (2026)