Clash Meta에서 Sniffer를 켰는데도 HTTPS 트래픽이 직행·오분기될 때: mihomo 로그로 SNI·복원 도메인을 읽고 고치기 (2026)

1. 왜 규칙이 맞는데도 HTTPS만 어긋나 보일까

대부분의 도메인 기반 규칙은 「이 연결이 어떤 호스트를 향한다」는 정보가 있어야 의미가 있습니다. 그런데 TLS 1.3 환경에서 중간 프록시가 없다면 애플리케이션 레벨에서는 암호화된 페이로드만 지나가고, 코어가 처음에 알 수 있는 것은 상대 IP 주소와 포트뿐인 경우가 많습니다. 그 상태에서 DOMAIN 규칙은 실행되지 않고, IP-CIDR나 GEOIP 계열만 남습니다. 사용자 입장에서는 「내가 example.com을 분명히 PROXY 그룹에 넣었는데 왜 DIRECT로 나가지?」가 되지만, 엔진이 본 것은 example.com이 아니라 CDN 쪽 공유 IP 묶음일 수 있습니다.

Sniffer는 이런 공백을 메우기 위해 TLS ClientHello에서 SNI 확장을 읽거나, 핸드셰이크 이후 인증서의 SAN(Subject Alternative Name)에서 이름을 뽑아 규칙 재평가를 트리거하는 경로입니다. 즉 「스니퍼 ON = 모든 HTTPS가 자동으로 올바른 도메인 규칙에 걸린다」가 아니라, 해당 연결에서 이름을 실제로 복원했는지가 관건입니다. 복원에 실패하면 예전과 똑같이 IP 기준으로만 판단하게 됩니다.

2. Sniffer가 하는 일과 켜졌다고 끝이 아닌 이유

프로필에서 sniffer 블록을 활성화했다면, 코어는 지정한 프로토콜(tls 등)에 대해 스니핑을 시도합니다. 다만 스니퍼도 물리 법칙을 어기지는 못합니다. 일부 앱은 비표준 TLS를 쓰거나, ClientHello를 난독화해 SNI를 숨기기도 합니다. 또 ESNI/ECH처럼 이름 자체를 암호화하는 기술이 개입하면 복원 난이도가 달라집니다. 설정에서 특정 포트·인터페이스·스니퍼 스킵 목록을 걸어 둔 경우에도, 사용자는 GUI에서 켰다고만 기억하고 실제 YAML에는 예외가 남아 있는 일이 잦습니다.

또 하나의 착시는 인증서상 도메인과 사용자가 기대하는 웹 호스트가 다를 때입니다. 예를 들어 브라우저 주소창에는 cdn.example.com으로 보이지만, 실제 TLS 인증서는 상위 CDNE 도메인을 담고 있어 규칙의 DOMAIN-SUFFIX가 기대한 접미사와 어긋날 수 있습니다. 이때는 규칙을 늘리기 전에 로그에 찍힌 복원 문자열을 먼저 확정하는 편이 빠릅니다.

# Example shape only; align keys with your mihomo / Clash Meta version docs
sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]

위 스니펫은 형태 예시일 뿐이며, 실제 키 이름·중첩 구조는 사용 중인 mihomo 버전 문서와 GUI가 생성한 YAML을 기준으로 맞춰야 합니다. 버전마다 스니퍼 옵션 이름이 조금씩 달라, 옛 예제를 그대로 붙여 넣다가 조용히 무시되는 경우도 있습니다.

3. mihomo 로그에서 Sniffer·SNI 흔적 찾기

진단의 중심은 「이 연결이 규칙 매칭 시점에 어떤 호스트 문자열을 들고 있었는가」입니다. 로그 레벨을 debug 또는 info로 올린 뒤 문제 사이트에 접속해 보고, 같은 타임스탬프 묶음만 따라가세요. 스니퍼가 개입하면 sniff·redir·rule match 주변에 복원된 이름이나 SNI 힌트가 붙는 경우가 많습니다. 아무리 규칙을 고쳐도 로그에 여전히 IP만 찍힌다면, 스니핑 자체가 실패했거나 스니퍼가 해당 트래픽 경로를 타지 않는 것입니다.

GUI의 실시간 연결 목록이 있다면, 엔진이 최종적으로 선택한 정책 그룹·아웃바운드 이름을 로그의 rule 힌트와 교차 확인하세요. 「내가 고른 노드」와 「실제 다이얼에 쓰인 노드」가 다르면, URL 테스트가 아니라 실트래픽 연결 기준으로 다시 봐야 합니다. 노드 지연 측정용 글과는 다른 축의 문제라, 혼동하지 않는 것이 좋습니다.

4. 복원된 도메인과 규칙 매칭이 엇갈리는 패턴

스니퍼가 a.example.com을 복원했는데 규칙에는 DOMAIN-SUFFIX,example.com만 있고 더 위쪽에 광범한 GEOIP나 MATCH가 먼저 걸리는 경우가 있습니다. Clash Meta 계열은 규칙을 위에서 아래로 평가하므로, 사용자가 「맞게 썼다」고 느끼는 줄이 실제로는 도달하지 않을 수 있습니다. 특히 공용 규칙 세트를 여러 소스에서 이어 붙이면, 생각보다 위쪽에 DIRECT를 강제하는 넓은 조건이 숨어 있습니다.

반대로 GEOSITE 카테고리에 들어 있다고 해서 항상 원하는 그룹으로 가지는 않습니다. 카테고리 정의는 데이터베이스 버전에 따라 변하고, 실제 접속 호스트는 목록에 없는 엣지 도메인일 수 있습니다. 이때는 로그로 확인한 FQDN을 기준으로 DOMAIN 한 줄을 추가하는 편이 데이터베이스 전체를 믿는 것보다 안전합니다.

5. DNS·fake-ip·DoH 누수와의 교차 검증

HTTPS 분기 문제를 볼 때 DNS는 항상 같이 봐야 합니다. fake-ip를 쓰면 애플리케이션이 받은 IP와 실제 업스트림이 붙는 IP가 달라 보여, 로그만으로 혼란이 생깁니다. 스니퍼가 도메인을 복원해 주면 규칙은 안정되지만, DNS 단계에서 이미 다른 출구로 질의가 새 나가면 체감 증상은 비슷하게 「엉뚱한 노드」로 느껴질 수 있습니다.

브라우저가 보안 DNS(DoH)로 직접 해석해 버리면, 코어의 DNS 모듈과 결과가 갈라집니다. 이때는 Clash만 만지작거려도 증상이 그대로인 경우가 많습니다. 스트리밍·AI 글에서 자주 나오는 누수 점검 루틴을 그대로 이어 붙이면 좋고, Windows 구독 갱신 글에서 다룬 것처럼 로그에 DNS 타임아웃이 먼저인지도 확인하세요.

6. QUIC(HTTP/3)·다중 경로·예외 앱

최신 브라우저는 기본적으로 QUIC(HTTP/3)을 선호합니다. UDP 기반 경로는 TCP TLS 스니핑과 다른 코드 경로를 타기 때문에, TCP 443만 스니핑하도록 좁혀 둔 프로필에서는 「일부 자원만 DIRECT」처럼 보일 수 있습니다. 실험적으로 QUIC을 끄거나, 프로필에서 UDP 관련 분기·스니퍼 범위를 문서와 맞춰 조정해 보는 A/B가 현장에서 흔합니다.

또한 일부 앱은 인증서 고정이나 자체 네트워크 스택을 써서 시스템 프록시를 우회합니다. 이런 앱은 Clash가 아무리 똑똑해도 「앱 밖」에서 돌아가며, TUN으로만 잡히는 경우도 있습니다. 반대로 TUN을 켰는데도 특정 프로세스만 빠져 나간다면, 분할 모드·예외 목록·다른 VPN과의 충돌을 의심합니다.

7. TUN·시스템 프록시·프로세스 규칙과의 정렬

시스템 프록시만 켠 상태에서는 UWP·일부 데스크톱 앱이 프록시를 무시할 수 있습니다. TUN은 그 구멍을 메우는 대표 수단이지만, TUN 자체가 DNS·스택 옵션과 맞물려 예상과 다른 출구를 만들기도 합니다. 원리 정리는 TUN 모드 가이드를 참고하고, 음성·UDP가 섞인 앱은 Discord·TUN 글의 관점과 겹쳐 읽으면 이해가 빨라집니다.

프로세스명 규칙을 쓰는 경우, 스니퍼가 복원한 도메인과 프로세스 조건을 동시에 만족해야 하는 배치인지도 확인하세요. 조건이 AND로 겹치면 한쪽만 맞아서 실패하는 그림이 나옵니다.

8. 한 번에 적는 점검 체크리스트

현장에서 시간 대비 효과가 좋은 순서를 묶으면 다음과 같습니다. (1) 로그 레벨을 올리고 문제 사이트를 한 번 재현한다. (2) 같은 시각대에 스니퍼·SNI·복원 도메인 흔적이 있는지 본다. (3) 복원된 문자열이 규칙의 어느 줄에 먼저 걸리는지 위에서 아래로 추적한다. (4) DNS·fake-ip·브라우저 DoH를 교차로 끄고 비교한다. (5) QUIC·UDP 경로를 의심해 A/B한다. (6) 시스템 프록시만·TUN만 등 최소 구성으로 줄여 본다. (7) 다른 VPN·필터·백신 HTTPS 검사와의 충돌을 제거한다.

이 루틴을 통과하면 「규칙은 맞는데 안 먹는다」는 말이 「도메인 정보가 없었다」 또는 「도메인은 맞는데 더 위 규칙이 먼저였다」처럼 재현 가능한 문장으로 바뀝니다. 이후에는 프로필을 감으로 흔들기보다, 로그에 찍힌 FQDN을 기준으로 최소 변경만 하는 습관이 유지보수 비용을 줄입니다.