1. 스니퍼가 HTTPS·규칙에 개입하는 이유
Clash의 스니퍼(스니퍼·Sniffer)는 이상한 이름으로 들어온 암호화 TLS 연결을 보고, Client Hello·QUIC·HTTP/2·기타 힌트로부터 도메인명을 복원하려는 기능입니다. DNS가 fake-ip를 쓰고 있을 때, 연결에 실린 목적지가 가짜 IP뿐이면 규칙 엔진이 호스트를 알기 어려운 경우가 있고, 이 때 스니퍼가 분기(어떤 프록시로 보낼지)를 돕는 역할을 합니다. 덕분에 일상적인 HTTPS 사이트는 도메인 기반 Rule이 더 잘 먹지만, 일부 은행·정부·기업은 TLS 구현, 인증서 핀(고정), 중간 캐시, 클라이언트 인증서(뮤추얼 TLS), SNI/ALPN 민감도, 혹은 프록시가 목적지를 “덮어쓰는” 동작과 맞지 않는 경우가 있어, 스니퍼를 켠 뒤에만 페이지는 뜨는데 로그인만 실패하거나 인증서가 낯선 주체로 보이는 식의 증상이 나기도 합니다.
또 override-destination(또는 동등한 옵션)이 켜져 있으면, 엔진이 스니퍼가 복원한 호스트를 바탕으로 연결 목적지를 바꾸려 할 수 있어, 멀티 도메인·다중 SNI 환경에서 예민한 앱·포털과 충돌할 수 있습니다. 필드명은 사용 중인 커널(예: Meta/Mihomo) 문서를 꼭 확인하십시오.
이 글의 전제는 “스니퍼를 끄면(또는 문제 도메인에서만 끄면) 증상이 사라지는지”로 인과를 먼저 고정하는 것입니다. 그 뒤에야 노드·구독 품질을 다루는 것이 시간을 덜 씁니다. TLS handshake timeout·SNI를 다룬 글과는 보완 관계이며, 여기서는 스니퍼·도메인 예외에 집중합니다.
2. 대조 실험: 스니퍼 on/off
가장 먼저 한 번에 한 가지만 바꿉니다. (1) 클라이언트 UI나 설정에서 sniffer: enable: false로 전체 스니퍼를 끄고 설정을 다시 로드하거나, (2) 사용 중인 앱이 “스니퍼”를 별 토글이 있으면 그것만 끕니다. 그런 뒤 같은 브라우저·같은 프로필로 문제 사이트를 다시 열어 봅니다. 스니퍼 off만으로 정상이면, 원인은 스니퍼가 관여한 연결 쪽이 크고, 이후는 도메인 예외로 나머지 사이트에 필요한 스니퍼는 유지하는 방향이 합리적입니다.
off로도 그대로면, 동일 PC에서 fake-ip, DNS, TUN, 다른 VPN, 기업 SSL 검사(프록시)가 동시에 겹치는지 fake-ip·DNS 트러블슈팅 글의 순서로 먼저 층을 나누는 것이 낫습니다. “스니퍼만”의 문제는 아닐 수 있습니다. 반대로 off 후 나아지면, 아래 skip-domain에 집중하세요.
3. 도메인 단위: skip·제외(분 도메인)
스니퍼를 전부 끄지 않고 문제를 일으키는 호스트만 제외하려면, 사용 중인 커널이 제공하는 스니퍼용 도메인 제외 목록을 씁니다. Meta/Mihomo 계열에서는 흔히 sniffer.skip-domain 또는 skip-sni류의 필드(문서·버전별 명칭 확인)에 접미사·와일드카드를 넣습니다. 로그인 리다이렉트, 정적·API 서브도메인, FIDO·공동인증 콜백이 따로 떨어지는 은행·정부는 여러 호스트를 열 수 있으므로, 개발자 도구 네트워크 탭이나 Clash/Mihomo 로그로 실제 연결 SNI/호스트를 모아 한 줄씩 추가하는 편이 안전합니다.
목록에 넣기 전에
- 뿌리·서브 둘 다 필요한지:
+.접두가 의미를 갖는 경우가 많아, 팀에서 쓰는 정확한 문법을 보고 쓰세요(복사·붙여넣기 실수로 예외가 안 먹는 경우가 많습니다). - IP 직접 지정만 쓰는 앱/전용 클라이언트는, 스니퍼가 아니라 라우팅·DIRECT 층을 먼저 보아야 합니다.
- 퍼블릭 PC·희한한 인증서는 “스니퍼” 이전에 기관 정책일 수도 있으니, 스니퍼 off 대조로만 결론 내리는 것이 좋습니다.
4. 설정 예시(스니퍼 블록,구조)
아래는 구조 이해용 예시이며, 키 이름·하위 키는 사용 중인 Meta/Mihomo 앱의 최신 문서와 클라이언트 UI가 생성한 YAML을 기준으로 맞추십시오. 중복 sniffer: 블록이 있으면 합쳐지지 않는 경우가 많으니, 한 블록으로 정리합니다.
# Example structure; align keys with your kernel docs
sniffer:
enable: true
override-destination: false
# skip-domain: (names vary by version)
skip-domain:
- '+.example-bank.co.kr'
- '+.go.kr'
sniff:
TLS:
ports: [443, 8443]
# QUIC, HTTP/2, etc. — enable only if you need themoverride-destination이 true인 경우 HTTPS 이상이 늘어날 수 있어, 우선 false로 두고 재현이 남는지 봅니다. 포트·프로토콜(QUIC) 스니퍼는 꼭 필요할 때만 켜고, 443 TCP만으로도 분기가 될 땐 범위를 좁힌다는 원칙이 은행·정부·내부망 쪽에서 덜 흔들립니다. 실제 최적 조합은 케이스마다 다르므로, 로그 한 줄씩 확인하며 늘이거나 줄이세요.
6. 검증 절차(재현·로그·한 번에 한 단계)
예외를 넣은 뒤에는 설정 리로드·필요 시 클라이언트 재시작을 하고, 같은 URL로 다시 로그인 흐름을 밟아 봅니다. (1) Clash·Mihomo 로그에서 문제 연결이 스니퍼 경로를 탔는지, (2) 해당 스트림이 skip 목록에 잡혔는지, (3) 여전히 fake-ip를 품은 질의가 있는지 확인합니다. 모바일 앱 전용 은행은 시스템 VPN/TUN과 앱 자체의 프록시 설정이 다를 수 있으니, 웹뱅킹과 앱을 구분해 적습니다. 마지막으로, 공공·정책 사이트는 접속 시간·지역 제한이 있을 수 있어, 스니퍼와 무관한 403/차단과 혼동하지 않도록 시간대·출구 국가를 메모에 남깁니다.
이상이 정리되면, 문서·메모에 “어떤 도메인·어떤 이유(스니퍼 skip / fake-ip-filter / DNS 정책)로 예외를 뒀는지”를 적어 두면 구독·클라이언트를 바꿔도 같은 함정을 덜 밟습니다. 사이트 문서의 기본 모드·DNS 설명과 함께 읽으면, 팀·가족에게 짧은 체크리스트로 전달하기도 쉬워집니다.
보안·운영 메모(일반)
본인 자산·인증·납부를 다루는 HTTPS는 스니퍼를 끄는 것만이 전부는 아닙니다. 공식 URL·공식 앱을 쓰고, 이상한 인증서는 계속 뜨면 사이트를 의심하기보다 환경(프록시·SSL 검사·악성 확장)을 먼저 봅니다. Clash 스니퍼는 편의·분기를 위한 옵션이고, 은행/공공은 그 편의보다 호환·안정이 우선인 경우가 많으므로, 필요한 도메인에만 좁힌다는 기준을 유지하는 것이 좋습니다.
7. 요약
Clash에서 스니퍼(스니퍼·Sniffer)를 켠 뒤 은행·정부/공공·기업 인증류만 HTTPS가 이상하면, 전체를 끄기 전에 도메인 단위로 스니퍼를 끄거나 skip-domain에 넣는 쪽이 실무에 잘 맞습니다. 대조 실험으로 스니퍼 on/off·override-destination을 확인하고, fake-ip·DNS와 겹을 보이면 fake-ip 글과 함께 점검하십시오. 남는 증상은 TLS·SNI·노드 쪽을 연관 글로 이어집니다.
Clash·Mihomo는 규칙·DNS·스니퍼를 조합해 멀티 사이트를 한꺼번에 다루는 데 강하고, 예외를 좁고 명확히 쌓아 두면 매일 쓰는 프록시와 금융/공공이 같이 잘 맞는 경우가 많습니다.