점검 2026-04-12 · 약 16분

Clash Meta Sniffer 켠 뒤 HTTPS 오류? 인증서 건너뛰기와 도메인 제외로 단계별 수정

Clash Meta(Mihomo)에서 Sniffer(스니퍼)를 활성화한 뒤 브라우저나 일부 앱에서 갑자기 HTTPS 인증서 오류, 핸드셰이크 실패, 또는 특정 도메인만 열리지 않는 현상이 나타나는 경우가 있습니다. Sniffer의 역할은 HTTPS 업무 트래픽을 복호화하지 않고도 TLS ClientHello에서 SNI 등 정보를 읽어 내어, "IP만 보이는" 상황에서도 도메인 기반 분류 규칙이 제대로 작동하도록 하는 것입니다. 그러나 내부 처리 방식이 달라지면서 fake-ip, override-destination, 또는 일부 앱의 인증서 고정(Certificate Pinning) 정책과 서로 영향을 줄 수 있습니다. 이 글은 먼저 검증하고, 범위를 좁혀가는 순서로, skip-domain(스니핑 제외) 활용법, 인증서 검증 건너뛰기(skip-cert-verify) 를 고려해야 할 시점, 그리고 DNS 관련 점검과 연동하는 방법을 정리합니다.

Sniffer가 해결하는 문제

redir-host나 일부 TUN 환경에서는 연결이 커널 내부에서 '목적지 IP' 형태로만 나타날 수 있습니다. 규칙이 대부분 DOMAIN / DOMAIN-SUFFIX에 의존한다면, 호스트명이 없을 때 올바른 정책을 적용하기 어렵습니다. Sniffer를 켜면 코어가 TLS 트래픽에서 도메인 단서를 조기에 파악해, 규칙 엔진이 IP 추측이 아닌 실제 방문 사이트를 기준으로 판단할 수 있게 됩니다.

이것은 '중간자(MITM) HTTPS 복호화'와 다른 개념입니다. 표준 Sniffer는 핸드셰이크 메타데이터만 읽을 뿐 애플리케이션 평문을 보지 않습니다. 따라서 브라우저가 인증서와 도메인 불일치, 인증서 체인 오류를 표시할 때는 구분이 필요합니다. 스니핑·라우팅 재작성의 부작용인지, 업스트림 노드·시스템 시간·구독 TLS·대상 사이트 자체의 문제인지 먼저 확인해야 합니다.

핵심 개념 정리

Sniffer를 '연결에 호스트명 태그를 붙이는 모듈'로 이해하세요. 태그가 정확할수록 도메인 분류가 정확해집니다. 단, override-destination·DNS 매핑·클라이언트 자체 검증 로직과 충돌하면 일부 사이트에서만 오류가 나타납니다. 이 경우 전체를 끄기보다 제외 목록을 관리하는 것이 장기적으로 더 낫습니다.

전형적인 증상: Sniffer 관련 여부 판단하기

규칙을 수정하기 전에 먼저 '스위치 비교'를 해보세요. 동일한 노드·분류 상태에서 sniffer.enable만 토글하거나 GUI의 스니핑 스위치만 변경해 봅니다.

  • 일부 도메인만 오류가 나고 다른 사이트는 정상. Sniffer를 끄면 즉시 복구됩니다.
  • 뱅킹·공공 서비스·기업 VPN·일부 국내 앱이 프록시 환경에서 갑자기 로그인 불가. 로그에 TLS 관련 실패 또는 반복 재시도가 보입니다.
  • fake-ip 사용 중 Sniffer 활성화 후 정책 명중 변동 발생 (직접 연결해야 할 트래픽이 프록시를 타거나 그 반대).
  • override-destination을 켜자마자 문제가 급증한 경우 — 목적지 재작성이 대상 앱의 기대와 맞지 않는 신호입니다.

Sniffer를 꺼도 문제가 지속된다면, 먼저 《DNS 누출·fake-ip 점검》 경로로 되돌아가세요. dns.enhanced-mode·nameserver와 fallback·시스템/브라우저 DoH가 커널 DNS를 우회하는지 확인하는 것이 우선입니다.

1단계: 스니핑 제외 (skip-domain)

가장 안정적인 수정 방법은 Sniffer 전체를 끄는 것이 아니라, 알려진 민감 도메인이나 호환되지 않는 도메인을 스니핑 제외 목록에 추가하는 것입니다. 해당 연결이 스니핑 로직을 우회하게 되므로 목적지 파싱의 추가 간섭을 피할 수 있습니다. GUI에 따라 '스니핑 건너뛰기 도메인'·'Sniffer 제외' 등으로 표시되며, 내부적으로는 대부분 skip-domain 목록에 해당합니다.

일반적으로 와일드카드 후위 매칭을 지원하는데, 예컨대 +.example.com으로 서브도메인을 모두 포함할 수 있습니다. 구체적인 규칙은 사용 중인 Mihomo 버전 문서를 따르세요. 아래는 예시 구조입니다. 실제 YAML의 위치와 들여쓰기에 맞게 조정하세요.

# Illustrative sniffer block — align with your Mihomo version docs
sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443]
    QUIC:
      ports: [443]
  skip-domain:
    - '+.bank.example'
    - '+.internal.corp'
  force-dns-mapping: true
  parse-pure-ip: false
  override-destination: false

실무 조언: 긴 목록을 한꺼번에 붙여 넣지 마세요. 연결 로그에서 오류가 나는 사이트의 정확한 호스트명을 확인한 후, 도메인 항목을 1~3개씩 추가하고 설정을 리로드해 검증하세요. 안정되면 구독이나 템플릿에 포함된 기본 제외 항목을 합칠지 검토합니다.

어떤 도메인을 찾아야 하나

  1. 클라이언트 로그에서 실패한 요청의 SNI 또는 URL 호스트명을 필터링하세요.
  2. 브라우저 개발자 도구 '네트워크' 탭에서 인증서 오류 페이지의 메인 도큐먼트 요청 도메인을 확인하세요.
  3. 앱 내 WebView는 첫 페이지 도메인뿐 아니라 API 서브도메인도 함께 기록하세요.

override-destination과 fake-ip 연동

override-destination: true는 스니핑으로 얻은 도메인 정보로 연결 목적지를 재작성합니다. 복잡한 CDN이나 멀티 인증서 환경에서 분류 정확도를 높일 수 있지만, '클라이언트는 IP·특정 인증서 SAN으로 연결했다고 생각하는데 실제 경로는 다른 곳으로 유도됐다'는 혼선을 일으키기도 쉽습니다. 해당 옵션을 막 켰을 때 오류가 집중적으로 발생한다면 우선 false로 되돌린 뒤 기준선을 회복하고, 이후 각 정책 그룹에 세밀한 도메인 규칙이 필요한지 개별 평가하세요.

fake-ip와 Sniffer는 모두 '도메인 수준 규칙'을 활용하기 위한 수단이지만, 잘못 조합하면 DNS 해석 단계와 연결 단계가 일치하지 않는 문제가 생깁니다. DNS 전문 가이드와 마찬가지로 한 번에 하나의 변수만 바꾸세요. DNS 모드·nameserver를 고정한 뒤 Sniffer를 조작하거나, Sniffer를 끈 상태에서 DNS를 검증한 뒤 다시 Sniffer를 켜고 제외 목록을 추가하는 순서가 효과적입니다.

옵션 주요 장점 주요 위험
sniffer.enable TLS 도메인 보완, 도메인 분류 정확도 향상 일부 사이트가 스니핑 로직과 비호환
override-destination "IP만 보고 잘못 라우팅" 수정 일부 인증서 검증 가정과 충돌
fake-ip 규칙 조기 매칭, 빠른 응답 스니핑·Redir 스택 조합 시 정렬 필요

'인증서 검증 건너뛰기'를 고려하는 시점

커뮤니티에서 skip-cert-verify를 만능 해결책처럼 거론하지만, 이 옵션은 거의 항상 프록시 아웃바운드(기관 노드 또는 자체 호스팅 엔트리포인트)의 TLS 검증에만 영향을 줍니다. 비즈니스 사이트의 인증서를 수정하는 수단이 아닙니다. true로 설정하면 클라이언트가 노드와의 링크에 대한 인증서를 엄격하게 검증하지 않게 되므로, 가로채기나 위조된 엔트리포인트에 오연결될 위험이 커집니다. 단기 장애 점검이나 완전히 신뢰하는 폐쇄 환경에서만 사용해야 합니다.

올바른 순서는 이렇습니다. 먼저 인증서 체인이 온전한 노드나 포트로 교체하고, 로컬 시스템 시간을 확인하고, 회사 보안 소프트웨어가 TLS를 가로막지 않는지 확인하세요. 그 다음에야 단일 프록시 항목에서 skip-cert-verify: true를 임시로 켜서 가설을 검증합니다. 전체 템플릿에 이 옵션을 영구 적용하는 것은 피하세요.

보안 주의

인증서 검증 건너뛰기는 '사이트를 신뢰하게 만드는' 것이 아닙니다. 프록시 노드까지의 구간 검증만 우회합니다. 비즈니스 사이트의 HTTPS는 여전히 브라우저가 검증합니다. 브라우저가 인증서 오류를 계속 표시한다면 사이트 자체·시스템 루트 인증서·악의적인 HTTP 인터셉터 여부를 확인하세요.

GUI 클라이언트에서 설정하는 방법

Clash Verge, OpenClash, 각 Windows 프론트엔드마다 Sniffer 노출 정도가 다릅니다. 일부는 스니핑 전체 스위치·TLS/QUIC 포트·제외 목록을 제공하고, 일부는 원시 설정 파일을 직접 수정해야 합니다. 어떤 방식이든 단일 진실 소스를 유지하세요. '덮어쓰기 YAML'과 '구독 병합 스니펫'에 sniffer를 중복 정의하지 마세요. 예상치 못한 순서로 덮어씌워질 수 있습니다.

TUN이나 Meta 커널이 처음이라면 먼저 《Clash for Windows 설치 가이드》 또는 《Clash Verge Rev macOS》로 기초를 잡은 뒤 Sniffer를 추가하세요. 그렇지 않으면 '드라이버·권한 문제'를 스니핑 문제로 오해하기 쉽습니다.

자주 묻는 질문

Sniffer를 켜자마자 거의 모든 HTTPS가 빨간 오류

전체적인 네트워크, 시스템 시간, 또는 구독 노드 TLS 문제일 가능성이 높습니다. 먼저 Sniffer를 끄고 비교해 보세요. 여전히 모두 빨간 오류라면 노드 가용성과 포트를 확인하고, 로컬 보안 소프트웨어의 HTTPS 스캔 여부를 점검하세요.

특정 앱만 안 되고 브라우저는 정상

인증서 고정(Certificate Pinning) 또는 앱 자체 검증 로직일 가능성이 큽니다. 해당 앱 관련 도메인에 skip-domain을 추가하거나, 그 앱 트래픽이 DIRECT로 스니핑 스택을 우회하도록 규칙을 구성하세요.

HTTP/3 / QUIC 오류

QUIC 스니핑을 설정한 경우 TLS 분기와 각각 비교해 보세요. 일부 네트워크 환경에서는 UDP 443이 속도 제한되거나 차단되어 핸드셰이크가 완료되지 않아 '인증서 오류'처럼 보일 수 있습니다.

뱅킹·공공 앱 로그인 실패

이들 앱은 대부분 인증서 고정을 사용합니다. 해당 도메인을 skip-domain에 추가하거나, 더 나아가 해당 앱 트래픽 전체를 DIRECT 정책으로 분류하는 것이 깔끔한 해결책입니다. 로그에서 SNI를 확인해 정확한 도메인을 찾은 뒤 최소 범위로 추가하세요.

실무 체크리스트

  1. 오류가 나는 사이트의 정확한 호스트명과 오류 메시지를 기록합니다 (스크린샷 + 로그).
  2. Sniffer 스위치만 바꾼 A/B 비교로 인과관계를 확인합니다.
  3. 해당 사이트에 skip-domain(또는 동등한 GUI 항목)을 추가하고 소량씩 검증합니다.
  4. override-destination·fake-ip·DNS를 동시에 변경했는지 점검합니다.
  5. 노드를 가리키는 단일 프록시에서만 skip-cert-verify를 단기 시험하고, 확인 후 제거하거나 노드를 교체합니다.

유지보수 가능한 클라이언트로 복잡도 수렴하기

Sniffer는 Meta 계열 커널의 고급 기능입니다. 도메인 분류 정확도를 크게 높여주지만, 호환되지 않는 소수 대상에 대해서는 작고 명확한 제외 목록을 관리하는 것이 바람직합니다. '스니핑 스위치·제외 목록·DNS 모드'를 자신의 설정 노트에 기록해 두세요. 커널을 업그레이드하거나 GUI를 교체할 때 빠르게 복원할 수 있습니다.

Clash를 무료로 다운로드하고 쾌적한 인터넷을 경험하세요

고급 기능, 계층별 점검

Sniffer는 TLS 도메인 분류를 더 정확하게 합니다. HTTPS 오류 시 스니핑 제외와 DNS 정렬을 먼저 시도하고, 인증서 검증 건너뛰기는 신중하게 사용하세요.

Clash 다운로드