이런 증상이면 이 순서를 먼저 의심하세요

전역적으로 인터넷이 끊긴 것이 아니라, 몇몇 HTTPS 사이트만 간헐적으로 타임아웃하거나 인증서 오류가 납니다. 스트리밍·앱 스토어·특정 API만 유독 느리고, 같은 도메인이라도 리전별 CDN에 따라 들쭉날쭉합니다. 설정을 손본 시점이 «스니핑을 켰다», «override-destination을 true로 바꿨다», «Fake-IP와 함께 TUN을 켰다»와 겹치면 본문의 여섯 단계가 특히 잘 맞습니다.

이 패턴은 단순 노드 품질 문제와 달리, 규칙이 참인 줄 알았는데 실제 매칭 문자열이 다른 레이어에서 바뀐 상태로 나타나기 쉽습니다. 그래서 체감 증상만으로는 «DNS가 나쁘다» 또는 «노드가 망가졌다»로 단정하기 어렵고, 로그에 찍힌 목적지와 규칙 줄을 한 세트로 묶어 봐야 합니다.

스니핑·목적지 재작성·Fake-IP가 만나는 지점

스니핑은 암호화된 트래픽에서 호스트 이름을 복원해, 원래는 IP만 보이던 연결에도 도메인 기준 규칙을 적용할 수 있게 해 줍니다. 편하지만, 여기에 override-destination이 켜져 있으면 «규칙 판단용 이름»이 아니라 실제 다이얼 목적지까지 바뀔 수 있습니다. Fake-IP 모드에서는 클라이언트가 먼저 가짜 주소를 받고 코어가 나중에 이름을 붙이는 흐름이 섞이므로, 화면의 주소창·DNS 조회 결과·코어 내부 문자열이 서로 어긋난 채로 디버깅이 시작되는 경우가 많습니다.

정리하면 세 축입니다. 첫째, 무엇을 기준으로 규칙을 매칭했는지. 둘째, 실제 outbound 연결이 어디로 나갔는지. 셋째, 그 두 정보가 스니핑 이후에 일치하는지. 세 번째가 어긋나면 일부 도메인만 특이하게 깨지거나 CDN 선택만 엉킵니다. YAML 설계 전반은 YAML 규칙 분기 가이드에서 다루고, 여기서는 스니핑 스택과의 교차점만 깊게 파고듭니다.

1단계: 재현 한 번으로 고정하고 로그 창을 연다

문제 도메인 하나를 정해, 브라우저 탭 하나 또는 앱 한 번 실행만으로 같은 실패를 내세요. 동시에 브라우저 확장 스니펫·별도 VPN·시스템 Secure DNS를 잠시 끄면 변수가 줄어듭니다. 코어의 log-level를 짧게만 info 이상으로 올리고, 연결이 생길 때마다 목적지 호스트·스니핑 결과·matched rule이 함께 보이는지 확인합니다.

목표는 장기 로깅이 아니라 실패 직후 연속된 몇 줄입니다. 스크린샷이나 텍스트로 남겨 두면 나중에 YAML 줄번호와 대조하기 좋습니다. 모바일 빌드는 발열을 감안해 같은 절차를 더 짧게 반복하세요.

실무 팁 같은 URL을 «프록시 경유»와 «코어를 잠깐 끈 상태»에서 각각 열어 차이를 확인하면, 문제가 스니핑·재작성 축인지 단순 라우팅 축인지 빠르게 갈립니다.

2단계: override-destination부터 끄고 증상이 사라지는지 본다

스니퍼 블록에서 override-destination을 false로 두거나, 클라이언트 GUI에 동일 의미의 스위치가 있다면 꺼 보세요. 재시작 후 같은 재현 절차를 밟았을 때 문제가 사라지거나 크게 줄면, 원인 후보는 «이름은 맞는데 실제 다이얼 목적지가 바뀌며 규칙·인증서·SNI가 어긋난 것» 쪽으로 좁혀집니다.

설정 예시는 빌드별 키 이름이 조금씩 다르지만, 개념적으로는 아래와 같이 재작성만 분리해 생각하면 됩니다.

sniffer:
  enable: true
  # Keep sniffing for rule hints; disable destination rewrite first
  override-destination: false

이 단계에서 좋아졌다면, 다시 켤 필요가 있는지부터 판단합니다. 불가피하게 켜야 한다면 어떤 포트·프로토콜 범위에서만 켤지, 특정 도메인은 스니퍼 예외로 뺄지(클라이언트가 지원할 때)를 다음 단계와 함께 설계합니다.

3단계: Fake-IP·fake-ip-filter·DNS 동기화 점검

enhanced-mode: fake-ip를 쓰는 프로필이라면, 스니핑으로 복원한 이름과 DNS 모듈이 기대하는 흐름이 같은지 확인합니다. 로컬 도메인·사내망·캐스트 이름이 가짜 응답에 잡히면 이후 TLS 이름과 충돌합니다. fake-ip-filter(또는 이에 해당하는 예외 목록)에 문제 호스트나 상위 접미사를 넣어 재현이 바뀌는지 시험해 보세요.

DNS 서버를 여러 개 섞어 쓰거나 nameserver-policy로 도메인마다 다른 리졸버를 태우는 경우, 한쪽에서는 정상 이름이 다른쪽에서는 다른 CDN 대상을 주는 식으로 «부분 실패»가 증폭됩니다. 이때는 모드를 바꾸기보다 문제 호스트만 예외로 빼는 접근이 회귀 리스크가 적은 경우가 많습니다. DNS 모드 전환 자체가 목표라면 Fake-IP 대 redir-host 글의 체크리스트와 함께 한 변수만 바꿔 비교하세요.

4단계: 규칙 리스트에서 DOMAIN보다 앞선 줄이 없는지 본다

스니핑 덕분에 도메인 이름이 살아나도, 리스트 상단의 IP-CIDR·GEOIP·RULE-SET이 먼저 성립하면 아래쪽 DOMAIN 줄은 실행되지 않습니다. 사용자는 «스니핑을 켰으니 DOMAIN 규칙이 먹을 것»이라 기대하지만, 엔진 관점에서는 이미 IP 단계에서 종료된 것입니다.

Rule Provider가 로컬 스니펫보다 앞에 붙어 있거나, 원격 세트가 갱신되며 순서가 밀린 경우도 같은 증상을 냅니다. 로컬 예외를 유지하려면 클라이언트의 prepend·append 규칙이나 프로필 합치 순서 문서를 확인하세요. 규칙 줄의 실제 매칭 결과는 matched rule·FINAL 로그 글의 절차로 고정하는 것이 가장 빠릅니다.

5단계: 로그에서 목적지 재작성·매칭 줄을 한 줄로 묶어 읽기

연결 로그에 스니핑 관련 문구나 목적지 교체 흔적이 있는지 찾아보세요. 빌드마다 표기가 다르지만, 핵심은 «스니핑으로 어떤 호스트를 읽었는지»와 «그 결과 어떤 정책 그룹 줄에 매칭됐는지»를 같은 타임스탬프 그룹으로 묶는 것입니다. matched rule이 기대와 다르면 YAML 검색어로 그 줄을 역추적하고, 기대와 같은데도 접속이 깨지면 outbound 경로·인증서·UDP 차단을 의심합니다.

TUN 모드와 시스템 프록시 모드를 바꿔 가며 로그가 달라지면, 문제가 규칙보다 앞선 경로 선택에 있을 수 있습니다. 이때는 TUN·시스템 프록시 트러블슈팅과 병행해 동일 재현을 유지하세요.

6단계: 최소 구성으로 회귀 확인한 뒤 하나씩 되살린다

원인 후보가 여럿일 때 한 번에 여러 스위치를 켜면 나중에 무엇이 효과였는지 기억하기 어렵습니다. 예를 들어 (A) override-destination만 끈 상태에서 통과하는지 확인한 다음, (B) 필요한 경우에만 포트 범위를 줄인 스니핑으로 되돌리고, (C) 그다음에만 fake-ip-filter를 추가하는 식으로 단계를 나눕니다.

안정된 베이스라인을 확보한 뒤에는, 운영 편의를 위해 다시 켜야 하는 옵션만 좁혀 넣으세요. 문서화된 작은 스니펫을 Git이나 메모에 남기면 구독 갱신 후에도 같은 회귀를 빠르게 잡을 수 있습니다.

로그·설정 패턴별 빠른 대응

관찰 우선 조치
override-destination 끄면 즉시 정상 재작성 범위 축소·도메인 예외·스니핑 포트 한정 후 재활성 검토
matched rule은 원하는데 브라우저만 실패 실제 다이얼 SNI·인증서·분 앱 우회·HTTP/3 경로 점검
DOMAIN 규칙이 있는데 FINAL까지 내려감 상단 IP·GEOIP 선점·Rule Provider 순서·호스트 문자열 불일치
Fake-IP 전환 후에만 발생 fake-ip-filter·로컬 이름·내부 DNS와 스니핑 결과 교차 확인

자주 묻는 질문

override-destination을 끄면 스니핑이 무용지물인가요?

아닙니다. 이름을 읽어 규칙에 참조하는 기능과 목적지를 바꾸는 기능은 분리할 수 있습니다. 우선 재작성만 끄고 증상 변화를 보는 것이 진단 비용 대비 효과가 큽니다.

Fake-IP만 redir-host로 바꾸면 항상 해결되나요?

늘 그런 것은 아닙니다. 환경에 따라 내부망 이름 해석이 더 까다로워질 수 있어, DNS 모드 단독 변경보다 예외 목록과 재작성 스위치를 함께 보는 편이 안전합니다.

로그 도메인과 주소창이 다르면 무엇을 믿나요?

코어가 매칭에 사용한 호스트 문자열을 우선합니다. CDN·리다이렉트·HTTP/3 때문에 표면 호스트와 SNI가 다를 수 있습니다.

정리

스니핑과 override-destination은 Fake-IP·DOMAIN 규칙과 겹칠 때 «일부만 깨짐»이라는 형태로 나타나기 쉽습니다. 재작성부터 끄고 재현을 줄인 뒤, DNS 예외와 규칙 순서를 로그의 matched rule과 맞춰 가면 원인이 규칙 자체인지 스니핑 스택인지 빠르게 갈립니다. 설계 레벨의 규칙 작성은 별도 가이드에 맡기고, 이 페이지는 현장에서 변수를 줄이는 순서에 집중했습니다.

플랫폼별 클라이언트 진입점은 ClashNote 다운로드 페이지에서 비교할 수 있습니다. 구독 프로필을 갱신할 때마다 원격 Rule Provider가 바뀌므로, 한 번 맞춰 둔 로컬 예외 스니펫을 상단에 유지하는 패턴이 회귀 방지에 도움이 됩니다.

→ Clash 무료로 다운로드하고, 스니핑·DNS·규칙을 같은 도구로 단계적으로 맞춰 보세요.

동일한 YAML이라도 스니핑 옵션 하나로 체감이 달라지는 것은 흔합니다. 재현 로그 한 줄을 습관처럼 남겨 두면 이후 튜닝 시간을 크게 줄일 수 있습니다.