규칙이 안 먹는 것처럼 보일 때: 첫 매치가 전부다

Clash는 rules 목록을 위에서 아래로만 평가합니다. 조건에 처음 걸린 한 줄이 그 연결의 출구를 결정하고, 그 아래 줄은 해당 패킷에는 실행되지 않습니다. 「DOMAIN 규칙을 넣었는데 소용없다」는 글의 절반은 이 한 줄로 설명됩니다. 원격 번들 맨 아래에 DOMAIN-SUFFIX,example.com,PROXY를 붙였는데도 DIRECT로 나간다면, 그보다 위에 있는 RULESET, GEOIP, 또는 넓은 DOMAIN-KEYWORD가 이미 매치했기 때문입니다. 구독만 갈아엎기 전에 DOMAIN·RULESET·Provider가 어떻게 겹치는지 큰 그림은 Clash 규칙 분기 베스트 프랙티스와 함께 맞추면 스크린샷만 따라 한 순서 함정에서 빠져나오기 쉽습니다.

가져온 프로필은 사용자 스니펫보다 원격 목록을 먼저 합치는 경우가 많고, GUI는 구독 쪽 조각을 자동으로 앞에 붙이기도 합니다. 내가 수정한 줄보다 위에 삽입된 건 일단 「적대적으로」 의심하고, 중복을 줄이고, 깜빡하고 넓게 잡은 키워드가 어떤 CDN까지 삼켰는지 확인하고, 공격적인 기본값을 숨긴 거대 RULESET은 과감히 다듬습니다. 로그가 추측보다 빠릅니다—개인 정보 범위 안에서 로그 레벨을 잠깐 올린 뒤 재현 한 번 하고, 코어가 출력하는 규칙 식별자를 적어 두었다가 GEOIP 탓부터 하지 마세요.

MATCH는 보통 맨 아래(말단)

특수 매처 MATCH는 그보다 위에서 아직 잡히지 않은 연결을 모두 받습니다. 코어 버전에 따라 FINAL과 같은 말단 역할과 비슷하게 쓰이기도 합니다. MATCH가 더 좁은 규칙보다 위에 있으면 그 아래 줄은 실행되지 않는 「유물」이 됩니다. 자주 나오는 패턴은 MATCH가 모든 걸 특정 프록시 그룹으로 보내 버려 아래쪽에 두었던 DIRECT 예외가 영원히 안 먹는 경우입니다—MATCH를 진짜 맨 아래로 내리면 분기가 다시 예측 가능해집니다.

MATCH를 여러 줄 두는 건 프로필을 이어붙일 때 외에는 거의 도움이 안 되고 중복 FINAL만 헷갈리게 합니다. 위쪽에는 구체적인 규칙만 두고 MATCH는 하나로 단정 짓는 편이 낫습니다. YAML 주석으로 「MATCH는 맨 아래」 정도만 남겨 두면 나중에 mixin이 MATCH를 앞에 prepend하지 않도록 스크립트를 조심하기도 쉽습니다.

DOMAIN, GEOIP, IP-CIDR — 무엇이 먼저냐고?

호스트 이름 중심 매처(DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOSITE, 원격 RULESET 본문 등) 사이에는 키워드 종류보다 목록 안 순서가 우선입니다. 이름이 IP로 해석된 뒤에는 주소 기준 규칙(IP-CIDR, GEOIP, 코어 확장의 ASN류)이 같은 목록 순서대로 그 IP에 대해 평가됩니다.

GEOIP가 CN이 아니라고 했다면서 불만이라면, 먼저 도메인 규칙이 이미 위에서 가져갔는지 확인하고, GEOIP가 보고 있는 IP가 리졸버가 준 실제 목적지인지 fake-ip 같은 중간값이 아닌지 확인합니다. 특정 대역은 국가 태그와 무관하게 박아 두려면 의도적으로 IP-CIDR를 GEOIP보다 위에 두기도 하는데, 이때도 전체 목록에서의 순서가 전부입니다.

구독 RULESET 수만 줄은 종종 GEOIP CN DIRECT 같은 지름길보다 앞에 깔립니다—모든 경우에 문제는 아니지만 특정 CDN만 걸리면 재현됩니다. 이때는 통째로 삭제하기보다 필요한 줄만 위로 올리거나 예외만 앞에 두는 수술이 현실적입니다.

GEOIP 국가 오판과 DNS·Fake-IP

GEOIP는 로컬 MaxMind 호환 DB와 목적지 IP를 비교합니다. 데이터가 오래되었거나 순서를 착각하면 결과가 엇나갑니다. YAML부터 손보기 전에 대륙 트래픽이 예상과 다르게 나갈 때는 Clash GEOIP·mmdb·GeoSite 교체·검증 순서로 지오패키지를 갱신했는지 확인하는 편이 빠릅니다.

다른 축은 DNS입니다. fake-ip는 스니핑으로 실제 IP가 드러나기 전까지 잠깐 다른 주소풀처럼 보일 수 있고, 레이어가 어긋나면 GEOIP도 함께 흔들립니다. 라우터·LAN 접근 문제와 비슷한 맥락은 Fake-IP·LAN·라우터 우회 글과도 연결해 보세요. nameserver, fallback, fake-ip-filter가 정렬되어 있어야 GEOIP 단독 조정만으로는 안 되는 증상이 줄어듭니다—단계는 Clash Meta DNS(nameserver·fallback·fake-ip-filter) 가이드와 함께 보시면 좋습니다.

IPv6 이중 스택은 GEOIP 바이너리와 무관하게도 증상을 키웁니다. A 레코드만 가정하고 AAAA 경로가 다르면 규칙만 만져서는 안 맞습니다. 병렬 확인은 Clash IPv6 이중 스택·DNS 직결 규칙 글과 같이 두는 편이 안전합니다.

전략군(정책 그룹)과 규칙 단계 구분

규칙 단계에서 결정되는 것은 「어느 전략군 이름으로 넘길지」이고, 그 안에서 노드를 고르는 단계와 혼동하면 안 됩니다. url-test가 낙관적으로 다른 업스트림만 고르고 있으면 GEOIP 오판처럼 보이기도 하는데, 규칙 로그가 정상이라면 선택기 쪽을 의심합니다. 지연 측정·폴백 구성은 Clash 전략군과 url-test·fallback 조정에서 따로 다룹니다.

프록시 체인이나 실패 시 다른 출구로 넘어가는 설정은 평범한 RULE 줄 아래 숨어 있다가 지연 프로브만 깜빡일 때까지 안 보일 때도 있습니다.

RULESET Provider와 묵시적인 우선순위

원격 RULESET은 URL에서 받아 로컬 캐시(Mihomo 계열에서 SQLite 등)에 펼쳐 지지만, 펼친 뒤에는 태그가 가리킨 위치에 일반 규칙과 같이 박힙니다. 구독 작성자가 맨 위에 두었다면 사용자가 아래쪽에 GEOIP 지름길을 넣어도 앞쪽 거대 RULESET이 이미 결정해 버린 것입니다.

자동 재생성 파이프라인을 검증할 수 있다면 예외 블록만 아래가 아니라 위로 올리거나, 문제 CDN apex만 좁게 DOMAIN-SUFFIX로 앞당기는 방법이 있습니다. 유지보수 부담과 교환입니다. 게임 목록처럼 순해 보이는 카테고리가 SaaS API와 같은 가장자리를 함께 잡아먹지 않았는지도 확인합니다.

업스트림 구독이 월요일 갱신되며 순서가 바뀌면 mixin만으로는 증상이 갑자기 납니다. 업그레이드 후에는 평탄화된 YAML을 한 번 덤프해 MATCH 근처 경계가 어떻게 바뀌었는지 비교해 두면 회귀 추적에 도움이 됩니다.

RULESET 자체를 잠깐 꺼 보고 증상이 사라지는지 보는 실험도 가능하지만, 라이선스·재배포 조건은 업스트림 안내를 따릅니다.

순서 바꾸기와 검증 절차

같은 순서로 재현할 수 있게 진행합니다.

  1. 실효 규칙 순서 덤프. mixin까지 합쳐진 최종 YAML을 내보냅니다. GUI만 보면 뒤에 붙은 조각을 놓치기 쉽습니다.
  2. MATCH·FINAL류 위치 확인. 더 좁은 규칙 아래에 말단 하나만 두었는지 확인합니다.
  3. RULESET 가로막음 조사. 의심되는 Provider를 잠깐 끄거나 예외만 위로 올립니다.
  4. 좁은 예외 삽입. 같은 흐름을 잡아먹는 거친 GEOIP 묶음보다 DOMAIN·IP-CIDR 예외를 앞에 둡니다.
  5. 코어 리로드. RULESET 캐시 조각이 남아 예전 순서를 참조하지 않게 합니다.
  6. 로그로 확인. 같은 요청을 한 번 더 재현하고 매치된 규칙 문자열과 전략군이 기대와 같은지 봅니다.

로그가 손실 대신 TLS·타임아웃 위주라면 라우팅이 아니라 전송 계층일 수 있습니다—순서와 함께 Clash 연결 로그 timeout·TLS 해석도 참고하세요.

YAML 옆에 「2026-04-29 CDN RULESET 충돌로 GEOIP CN 위치 변경」처럼 한 줄 메모를 남겨 두면 자동 병합 후에도 회귀 원인을 찾기 쉽습니다.

IP-CIDR이 GEOIP 직관을 덮어쓸 때

사내 대역(10.0.0.0/8), 분할 터널 VPN, RFC1918 등을 무조건 DIRECT로 두려고 IP-CIDR를 넣었다면 역시 순서가 중요합니다. 그보다 위에 CDN을 넓게 잡는 프록시 RULESET이 있으면 GEOIP 태그와 무관하게 먼저 매치되어 「GEOIP가 배신했다」처럼 보입니다.

반대로 초거대 CSP 대역을 좁은 IP-CIDR로 고정하면 결정적 출구를 만들 수 있지만 BGP 변동과 표가 오래되면 더 나쁜 고착을 만들 수도 있습니다. 트레이스와 표를 주기적으로 맞춥니다.

GEOSITE 묶음과 손으로 쓴 DOMAIN 줄

커뮤니티 GEOSITE 카테고리는 호스트 이름을 크게 묶습니다. 체크박스만으로는 실제 문자열 결합 순서가 안 보일 때가 많아, 짧은 DOMAIN 예외보다 위에 거대 블록을 두면 RULESET 때와 같은 충돌이 납니다.

거시 번들을 켤 때마다 삽입 인덱스를 머릿속으로 펼쳐 보고, MATCH 말단이 의도치 않게 밀렸는지 확인합니다.

Clash 바깥의 DNS 필터와 답이 다르면 터널 안 GEOIP 결과만 만져도 안 맞습니다. 권위 응답을 따로 확인합니다.

대표 엔드포인트 몇 개를 정해 두고 지연을 비교하면 QUIC처럼 TCP만 보던 습관에서 빠져나오기 쉽습니다.

외부 지원을 받을 때는 타임라인과 규칙 ID가 적힌 링크를 남겨 재현 비용을 줄입니다.

맺음말

「규칙을 무시한다」는 불만 대부분은 순서 문제—MATCH 위치, 거대 RULESET이 커스텀 줄을 가리는 문제—or GEOIP와 오래된 지오 데이터·DNS fake-ip가 섞인 증상으로 좁혀집니다. 추측 대신 로그를 잠깐 켜고, 좁게 순서만 바꾸고, 깨끗이 리로드하는 반복이 구독 URL만 바꾸는 것보다 빨리 보상됩니다.

TUN처럼 스택 전체를 가리는 모드에서는 설정 할 일이 늘어도 「위에서 첫 매치」 원리는 같습니다.

합쳐진 순서가 한눈에 보이고 어떤 줄이 매치됐는지 로그에 이름이 찍히는 빌드를 쓰면 같은 디버깅이 훨씬 짧아집니다.

순서와 지오 데이터를 함께 맞추면 우회 편법을 덜 끌어안아도 분기가 깔끔해집니다.

정책상 허용된 범위 안에서만 설정을 바꾸고 검증하세요.

→ 설치 패키지는 GitHub 릴리스보다 한곳에서 받는 편이 낫습니다: 공식 페이지에서 Clash 무료로 받고 병합된 규칙 순서와 리로드 주기부터 맞춰 보세요.