Clash 분기가 자꾸 엉뚱한 노드로 갈 때: 로그 matched rule과 FINAL 매칭을 여섯 단계로 검증하기

이럴 때 이 순서가 맞습니다

대표적인 패턴은 다음과 같습니다. 규칙 모드를 쓰고 있는데 특정 도메인만 «항상 글로벌 그룹»으로 나가거나, 반대로 «직결로 빠져야 할 CDN»만 유독 프록시 노드를 탄다고 느낄 때입니다. GUI에서 정책 그룹 이름은 맞아 보이는데 속도나 지역 판별 결과만 어긋나면, 실제 매칭 줄과 사용자 인터페이스가 서로 다른 레이어를 가리키고 있을 가능성이 큽니다.

또 하나의 함정은 DNS입니다. 이름은 원하는 규칙으로 묶였지만 해석 결과의 IP가 상단의 GEOIP나 IP-CIDR에 먼저 걸리면 체감상 «도메인 규칙이 먹히지 않는다»고 보입니다. 이때도 로그의 최종 규칙 이름을 기준으로 역추적하는 편이 빠릅니다. 해석 경로와 fake-ip 조합은 fake-ip·redir-host 점검 글과 함께 보세요.

먼저 짚고 갈 오해 두 가지

첫째, «규칙 파일에 문자열이 존재한다»와 «그 트래픽이 그 줄에 매칭된다»는 같지 않습니다. 리스트는 위에서 아래로 평가되고, 한 줄이라도 먼저 성립하면 아래 줄은 실행되지 않습니다. 둘째, matched rule은 종종 정책 그룹 이름까지만 적히고, 그 그룹 안에서 어떤 단일 노드가 선택됐는지는 별도 필드나 다음 줄 로그를 봐야 할 수 있습니다. 그래서 여섯 단계 중 절반은 «규칙 줄 자체»보다 «그 줄이 가리키는 proxy-groups 정의」를 펼치는 데 쓰입니다.

1단계: 로그 레벨 올리고 출력 창 고정하기

사용 중인 빌드가 Clash Premium·미호모·안드로이드 포크 등 무엇이든, 공통 준비는 «연결 단위로 라우팅 결과가 보이게 만들 것»입니다. 대개 코어 설정의 log-level를 debug 또는 info로 두고, 데스크톱 GUI라면 로그 패널을 연 상태에서 재현합니다. 로그가 파일로만 남는 환경이라면 회전 용량을 잠깐 넉넉히 두거나, 테스트 후 레벨을 되돌려 디스크 사용을 줄이세요.

여기서 목표는 장시간 전수 로깅이 아니라 문제 도메인 하나를 새로 열었을 때 연속된 몇 줄만 확보하는 것입니다. 브라우저 탭 하나·앱 한 번 실행만으로 재현된다면 그 순간을 노립니다. 모바일은 배터리와 발열을 고려해 디버그 레벨을 짧게 유지하는 편이 좋습니다.

2단계: matched rule 한 줄을 있는 그대로 적어두기

연결이 일어난 직후 로그에 나오는 규칙 식별자를 그대로 메모합니다. 이름은 사용자 정의 문자열일 수도 있고 Rule Provider가 붙인 접두사일 수도 있습니다. 중요한 것은 GUI에서 보는 한글 별칭이 아니라 YAML 상의 그룹 이름·규칙 태그와 일치하는지 여부입니다.

여기까지 왔으면 이미 반은 진단입니다. 왜냐하면 «어디로 보냈다고 생각했는지»가 아니라 «코어가 실제로 선택한 줄이 무엇인지」가 확정되기 때문입니다. 같은 이름이 두 번 등장하지 않도록 로컬 스니펫과 원격 세트를 합친 최종 규칙 리스트도 한 번 스크롤해 보세요.

3단계: YAML에서 그 규칙 줄을 찾아 위아래 순서 읽기

메모해 둔 이름으로 검색합니다. 해당 줄의 타입(DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP 등)과 목적지 정책 그룹을 확인하고, 그 위에 무엇이 있는지가 곧 우선순위입니다. 특히 대형 GEOIP 블록과 국내 전용 스니펫이 섞여 있으면, 후자가 더 아래에 있을 때 영영 도달하지 못합니다.

Rule Provider를 쓰면 파일 편집기에서 보는 순서와 런타임 순서가 다를 수 있습니다. 클라이언트가 프로필을 합치는 순서를 확인하고, 로컬 예외를 반드시 상단에 두고 싶다면 해당 클라이언트 문서의 «prepend-append」「priority」 같은 키워드를 확인하세요. 설계 원칙 전반은 YAML 규칙 분기 완전 가이드에서 자세히 다룹니다.

4단계: FINAL(MATCH)이면 위쪽 전부가 빗나간 것

로그가 FINAL 또는 MATCH를 가리키면, 의미는 단순합니다. 규칙 배열에서 포착 규칙이 하나도 없었다는 뜻입니다. 이때 해야 할 일은 새 줄을 아래에 덧붙이는 것이 아니라 왜 위쪽이 실패했는지를 역추적하는 것입니다. 대표적인 경우는 다음과 같습니다.

• 트래픽이 이미 IP 기준으로 평가되어 도메인 규칙 단계까지 도달하지 않음
• 작성한 스니펫과 실제 접속 호스트명이 미묘하게 다름(리다이렉트·서브도메인·API 게이트웨이)
• 프로필이 여러 단계로 합쳐지며 로컬 수정이 예상보다 아래로 밀림

FINAL 줄 자체가 가리키는 정책 그룹도 확인하세요. 그 그룹이 전역 프록시 선택이라면 모든 미매칭 트래픽이 거기로 모입니다. 의도가 다르다면 FINAL 목적지와 위쪽 규칙 밀도를 다시 조정해야 합니다.

5단계: 정책 그룹 타입·중첩 순서 펼치기

matched rule이 특정 그룹 이름으로 끝났다면, 다음 파일 위치는 proxy-groups입니다. 그룹 타입이 select라면 사용자가 UI에서 고른 노드가 로그의 최종 outbound와 같아야 정상입니다. url-test·fallback·load-balance류는 코어가 주기적으로 또는 장애 시 다른 멤버를 고릅니다. 여기서 멤버가 또 다른 그룹 이름이면 한 번 더 펼쳐야 합니다.

중첩이 깊어질수록 «규칙은 맞는데 노드만 바뀐다»는 보고가 나옵니다. 로그에 나온 그룹 이름마다 YAML 블록을 따라 내려가 마지막이 단일 proxy 이름인지 확인하세요. relay 체인은 의도치 않은 지연·경로가 되기도 하므로, 디버깅 중에는 단순한 단일 선택 구조로 잠시 단순화해 비교하는 방법도 있습니다.

IPv6나 듀얼 스택 때문에 IP 규칙만 먼저 타는 패턴은 IPv6·듀얼 스택 분기 글과 겹칩니다. FINAL만 반복된다면 DNS와 IP 규칙 축을 함께 의심하세요.

6단계: 한 변수만 바꿔 재현·회귀 줄이기

원인 후보가 여러 개일 때 한 번에 둘 이상 바꾸면 나중에 무엇이 효과였는지 기억하기 어렵습니다. 예를 들어 (A) 문제 도메인만 로컬 스니펫 맨 위로 올린다 → 로그가 원하는 줄로 바뀌는지 본다 → (B) 그다음에만 Rule Provider 갱신 주기를 조정한다,처럼 단계를 쪼갭니다.

테스트할 때는 가능하면 같은 클라이언트·같은 프록시 모드(규칙/글로벌)·같은 DNS 설정을 유지하세요. TUN 모드와 시스템 프록시 모드를 번갈아 켠 결과가 다르다면 경로 문제가 규칙보다 앞선 레이어에 있는 경우가 많습니다. 데스크톱 환경에서는 TUN·시스템 프록시 트러블슈팅 순서와 병행하면 시간을 줄일 수 있습니다.

로그 패턴별 빠른 대응

자주 묻는 질문

로그에 matched rule은 나오는데 화면에서 고른 노드와 다릅니다.

그룹 이름까지 맞다면 다음은 그룹 내부입니다. select형인지 자동 선택형인지 구분하고, 멤버가 다른 그룹을 가리키면 한 단계씩 펼쳐 최종 단일 노드까지 따라가 보세요.

FINAL만 찍히면 규칙이 무시되는 건가요?

무시된다기보다 위쪽 어떤 줄과도 매칭되지 않았다는 뜻입니다. 도메인 규칙을 추가했는데도 그렇다면 더 위 줄이 이미 소진했거나, 평가 단계가 도메인이 아닌 것부터 시작했을 가능성을 의심합니다.

디버그 로그를 켠 채로 두어도 되나요?

장시간은 비추입니다. 디스크·프라이버시·모바일 발열을 고려해 진단 구간만 열고 닫으세요.

정리

Clash 분기 디버깅에서 가장 강력한 단서는 여전히 로그입니다. matched rule으로 실제 줄을 고정하고, FINAL이면 위쪽 전체 리스트를 다시 읽으며, 마지막으로 정책 그룹 순서와 중첩을 펼치면 «규칙이 안 먹는다»는 말이 정확히 어디에서 비롯됐는지 분리할 수 있습니다. 문법과 유지 보수 패턴은 별도 가이드와 세트로 두고, 이 페이지는 검증과 재현에 집중하는 편이 학습 비용이 적습니다.

플랫폼별 클라이언트와 설정 진입점을 한곳에서 비교하려면 ClashNote 다운로드 페이지를 참고하세요. 규칙 설계를 함께 다듬을 때는 기술 칼럼 목록에서 DNS·TUN·YAML 주제를 이어서 읽으면 흐름이 자연스럽게 이어집니다.

동일하게 규칙을 적었는데도 현장마다 결과가 다른 것은 구독 세트와 DNS 환경 차이 때문입니다. 한 번 확보한 matched rule 스크린샷은 나중에 프로필을 갱신했을 때 회귀 비교 자료로도 쓸 수 있습니다.