1 TUN·FakeIP를 켰는데도 HTTPS만 엉뚱한 정책 그룹으로 가는 이유
Clash 계열 규칙은 대부분 도메인을 전제로 작성됩니다. DOMAIN-SUFFIX, GEOSITE 등은 코어가 접속의 호스트명을 알 때 비로소 의도대로 매칭됩니다. 그러나 TUN·투명 프록시, 특히 FakeIP를 쓰면 첫 라우팅 판단 시점에는 목적지가 IP(가짜 풀 주소 포함)로만 보이는 경우가 많습니다. TLS에서는 ClientHello 안의 SNI에 호스트명이 실리는데, 코어가 너무 이른 단계에서 IP 위주로 한 번 결정해 버리면 도메인 규칙이 뒤늦게 등장해 「도메인 규칙을 썼는데 일부 HTTPS만 직접 연결·다른 노드로 간다」는 현상이 납니다.
이는 「노드가 느리다」「URL-Test가 틀렸다」와는 다른, 정보가 나타나는 순서 문제입니다. 사이트 내《DNS 유출 방지: Meta DoH + FakeIP》는 해석 측에서 FakeIP·DoH를 정리합니다. 본문은 TLS 측에서 보완하여, 규칙에 필요한 도메인이 아직 없고 연결이 IP로만 보일 때 Clash Meta Sniffer로 핸드셰이크에서 실제 호스트명을 되살리는 흐름을 설명합니다.
2 Sniffer가 읽는 것: TLS SNI, HTTP Host, QUIC
Sniffer(스니퍼)는 Mihomo / Clash Meta에서 지정 포트의 아직 복호화하지 않아도 되는 첫 부분을 파싱해 TLS SNI, 평문 HTTP Host, 환경에 따라 QUIC 관련 정보를 뽑아 규칙에 쓸 호스트명으로 연결합니다. HTTPS 중간자 공격(MITM)이 아니라 핸드셰이크 메타데이터만 읽으며, 페이로드는 건드리지 않습니다. 구독·룰셋을 대신해 주지는 않고, 「라우팅 시점에 도메인이 비어 있다」는 틈을 메웁니다. 노드 자동 선택은《Clash URL-Test·Fallback》글과 함께 이해하면 레이어가 나뉩니다.
3 최소 설정: sniffer: 블록과 포트
설정 루트(dns:, proxies:와 동일 레벨)에 sniffer:를 두고 enable: true 후 sniff: 아래에 TLS·HTTP 등 프로토콜별 포트를 선언합니다. 브라우저 위주라면 TLS 443이 중심입니다. Mihomo 버전마다 필드명이 조금씩 다를 수 있으니 업그레이드 뒤에는 반드시 구성 검증을 돌리세요.
skip-domain에는 스니핑을 건너뛸 호스트를 넣습니다. IoT·사내망 등 호환 문제가 있는 도메인을 제외하면 불필요한 재시도를 줄일 수 있습니다. force-dns-mapping은 FakeIP와 강하게 연결되므로 DNS 섹션만 바꾸지 않고 Sniffer만 켜면 로그가 엇갈릴 수 있습니다.
sniffer:
enable: true
sniff:
TLS:
ports:
- 443
- 8443
HTTP:
ports:
- 80
- 8080-8880
skip-domain:
- '+.lan'
force-dns-mapping: true
parse-pure-ip: false리로드 후 로그에서 파싱 오류가 없는지, 문제 사이트 연결에 호스트명이 찍히는지 확인하세요. 효과가 없으면 실제 트래픽이 목록에 없는 비표준 HTTPS 포트를 쓰는지 먼저 의심합니다.
4 override-destination: 스니핑 결과로 목적지 덮어쓰기
SNI를 읽었다고 해서 곧바로 도메인으로 최종 라우팅이 다시 계산되는 것은 아닙니다. override-destination(또는 동일 기능 플래그)이 켜져 있어야 스니핑한 이름으로 DOMAIN 규칙과 HTTPS 분할·프록시 그룹 선택이 맞물립니다. 꺼 두면 로그에만 나오고 출구는 그대로인 경우가 생깁니다.
문제 사이트 하나만 골라 로그를 보며 켜고 끄는 식으로 검증하고, 게임·금융 앱과 충돌하면 해당 도메인을 skip-domain에 넣거나 일시적으로 끕니다. OS 프록시 예외·LAN 바이패스는 「Clash에 들어오느냐」이고, override는 「규칙이 IP를 보느냐 도메인을 보느냐」입니다.
5 DNS·FakeIP·redir-host와의 정렬
DNS는 「이름을 어떤 IP로 풀 것인가」, Sniffer는 「이 연결이 TLS에서 무엇이라고 이름을 올리는가」를 다룹니다. FakeIP 필터·DoH 업스트림이 어긋나면 SNI는 맞는데 캐시·해석이 흔들리는 것처럼 보일 수 있습니다. fake-ip-filter, nameserver-policy, fallback을 손볼 때는 Sniffer 변경과 한 번에 한 축만 바꾸고 기록해 두세요.
redir-host 모드에서도 도메인 규칙을 쓰면 Sniffer는 여전히 유용합니다. 같은 사이트·같은 노드에서 Sniffer와 override만 번갈아 켜고 로그의 정책 매칭을 비교하면 원인 분리가 쉽습니다. 시스템 프록시를 무시하는 프로세스는《Clash Verge Rev TUN 모드》로 터널에 먼저 넣어야 합니다. 코어에 도달하지 않는 트래픽은 Sniffer 이전의 문제입니다.
6 자주 하는 실수
- 포트 누락: 비표준 HTTPS 포트면 TLS 스니퍼가 동작하지 않습니다.
- 규칙 순서: 앞선
IP-CIDR·넓은MATCH가 먼저 잡으면 도메인 규칙에 닿지 않습니다. - ECH 등: SNI가 안 보이면 DNS·엔드포인트 쪽으로 돌아가야 합니다.
- skip-domain 과다: 제외가 많을수록 수정이 안 되는 호스트가 늘어납니다.
- Meta가 아닌 코어: 스니퍼 필드를 무시하는 포크도 있습니다.
7 정리
Clash Meta Sniffer는 FakeIP 등으로 연결이 처음에 IP로만 보일 때 TLS SNI 등 메타데이터를 되살려 HTTPS 분할과 프록시 그룹이 도메인 규칙과 맞도록 돕습니다. override-destination과 DNS·fake-ip-filter·DoH를 함께 맞춰야 루프가 닫힙니다. URL-Test 글은 「어느 노드로 보낼지」, 본문은 「규칙이 보는 이름이 맞는지」를 담당합니다.
GUI 클라이언트는 리로드와 로그 확인이 편합니다. 설치 파일은 사이트 다운로드 페이지를 이용하세요. 운영용 프로필은 수정 전 YAML 백업을 권장합니다.
Sniffer와 DNS 중 한 가지만 바꾸고 현상을 기록해 두면 공항·룰셋이 바뀐 뒤에도 원인 추적이 빨라집니다.
