분류 규칙(rules)이 실제로 하는 일

Clash 계열 클라이언트는 연결 요청이 들어올 때마다 YAML 프로필의 rules: 목록을 위에서 아래로 한 줄씩 훑으며, 처음으로 참이 되는 조건에 맞는 정책 이름으로 트래픽을 넘깁니다. 여기서 말하는 정책은 곧바로 서버가 아니라, 대개 proxy-groups에 정의된 그룹 이름이거나 DIRECT·REJECT 같은 특수 값입니다. 그래서 「노드가 빠른데 왜 이 사이트만 느리지?」라는 질문의 상당수는, 생각보다 규칙 순서나 정책 이름 오타에서 답이 나옵니다.

초보 단계에서는 거창한 아키텍처보다, 좁은 예외를 위에 두고 넓은 기본값을 아래에 두는 습관을 들이는 것이 가장 큰 이득입니다. 예를 들어 사내 포털만 직결로 보내고 나머지는 기본 그룹으로 넘기고 싶다면, 사내 도메인 규칙을 GEOIP,CN,DIRECT 같은 넓은 규칙보다 먼저 배치해야 합니다. 반대로 순서만 뒤바뀌어도, 의도는 직결이었는데 먼저 매칭된 줄 때문에 전부 프록시로 나가거나 그 반대가 될 수 있습니다.

proxy-groups 이름과 규칙 끝단의 연결

규칙 한 줄의 마지막 필드는 항상 정책 식별자입니다. SELECT 타입 그룹 이름을 적으면 사용자가 GUI에서 고른 노드로 이어지고, URL-TEST나 FALLBACK이면 그룹 내부 로직이 자동으로 후보를 고릅니다. 중요한 점은 YAML에서 이름이 대소문자까지 포함해 완전히 같아야 한다는 것입니다. Proxy와 PROXY를 다른 문자열로 취급하는데, 한쪽만 바꾸면 해당 규칙 줄이 통째로 무시되거나 기본 경로로 떨어져 디버깅이 매우 어려워집니다.

GUI 클라이언트가 자동 생성한 프로필을 편집할 때는, 화면에 보이는 그룹 표시명과 YAML 내부 name: 필드가 다를 수 있으니 항상 텍스트의 name을 기준으로 규칙을 작성하세요. 처음부터 손으로 쓴다면, 그룹 수를 최소화하고 🚀 기본 같은 이모지 접두를 쓰기보다 ASCII 위주의 짧은 이름을 추천합니다. 팀과 공유할 때 복사·검색이 쉬워지고, 로그에 찍힐 때도 식별이 빠릅니다. 전체 문서 구조는 문서 허브의 튜토리얼과 맞춰 읽으면 흐름이 더 잘 잡힙니다.

규칙 한 줄의 골격: 타입, 인자, 정책

전통적인 classical 규칙은 대개 TYPE,인자,정책 형태의 쉼표 구분 한 줄입니다. 예를 들어 DOMAIN-SUFFIX,example.com,PROXY는 호스트 이름이 해당 접미사로 끝나면 PROXY 그룹으로 보냅니다. IP-CIDR는 CIDR 표기의 대역이 목적지 IP와 일치할 때 발동합니다. GEOIP는 GeoIP 데이터베이스를 참조하므로, 로컬에 데이터가 없거나 경로가 다른 코어 빌드에서는 기대와 다르게 동작할 수 있어 버전·문서를 함께 확인하는 편이 안전합니다.

# Example skeleton — replace group names with your profile
rules:
  - DOMAIN-SUFFIX,company.example,DIRECT
  - DOMAIN-SUFFIX,cdn.company.example,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위 예시에서 마지막 MATCH는 사실상 「그 밖의 모든 것」을 잡는 포괄 규칙입니다. 빠뜨리면 매칭되지 않은 트래픽이 남을 수 있고, 반대로 MATCH를 너무 위에 올리면 그 아래 줄은 영원히 실행되지 않습니다. 그래서 MATCH는 거의 항상 맨 아래, 그 직전에 지역·기본 분기를 두는 패턴이 보편적입니다.

자주 쓰는 타입을 상황별로 고르기

DOMAIN은 정확히 일치하는 호스트 한 개를 지정할 때 씁니다. API 엔드포인트처럼 호스트가 고정일 때 유리합니다. DOMAIN-SUFFIX는 하위 도메인 전체를 덮을 때 쓰고, 범위가 넓어지므로 서비스 구조를 조금이라도 알 때만 쓰는 것이 좋습니다. DOMAIN-KEYWORD는 문자열이 포함되면 매칭되어 오탐이 잦아, 운영 프로필에서는 신중해야 합니다. 테스트 전용 프로필에서만 쓰거나, 가능하면 더 구체적인 타입으로 바꾸는 습관이 장기적으로 시간을 아깁니다.

SRC-IP-CIDR처럼 출발지를 보는 타입은 가정용 단일 PC에서는 드물지만, 라우터나 게이트웨이에 Clash를 올린 팀 환경에서는 유용합니다. PROCESS-NAME은 특정 실행 파일만 분기하고 싶을 때 쓰는데, 플랫폼마다 지원과 정확도가 다르므로 공식 문서의 해당 절을 먼저 읽는 것이 좋습니다. 어느 타입을 쓰든 공통 전제는, 첫 매칭 이후의 줄은 읽히지 않는다는 점입니다.

순서 설계: 예외 → 중간 블록 → 기본값

실무에서 가장 많이 쓰는 패턴은 세 층입니다. 첫째 층은 LAN·사내·결제·은행처럼 반드시 직결이어야 하는 좁은 예외입니다. 둘째 층은 지역·광고 차단·악성 IP 등 구독 규칙 세트나 GEOIP로 넓게 덮는 영역입니다. 셋째 층은 남은 전부를 잡는 MATCH입니다. 중간 층을 rule-provider로 쪼개고 싶다면 Rule Providers·RULE-SET 가이드를 이어서 읽으면, 같은 순서 논리를 유지한 채 파일만 나눌 수 있습니다.

규칙을 추가할 때는 「이 줄이 앞줄들에 가려지지 않는가?」를 매번 자문하세요. 특히 GEOIP,CN,DIRECT를 상단에 두고 해외 스트리밍 예외를 아래에 두면, 스트리밍 호스트가 중국 CDN을 탈 때 의도치 않게 직결로 떨어질 수 있습니다. 이런 증상은 DNS가 fake-ip 모드일 때 더 헷갈리므로, DNS 관련 설정은 TUN·DNS 가이드와 함께 보는 것을 권장합니다.

바로 복사해 실험해 볼 최소 스니펫

아래는 학습용으로만 쓰세요. 그룹 이름과 도메인은 반드시 본인 프로필에 맞게 고칩니다. 핵심은 좁은 규칙이 위에 있다는 점과, 마지막에 MATCH로 누수를 막는다는 점입니다.

# Learning example — verify names against your proxy-groups
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    proxies:
      - node-a
      - node-b
    url: http://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,internal.corp,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,PROXY

no-resolve 옵션이 붙은 규칙은 DNS 조회를 미루거나 생략하는 계열에서 의미가 있으므로, 코어 문서에서 해당 타입의 옵션 표를 꼭 대조하세요. 잘못 붙이면 오히려 매칭이 꼬일 수 있습니다.

로그로 검증하는 짧은 절차

규칙을 고친 뒤에는 실제 접속 한 번이 로그 한 줄보다 느릴 때가 많습니다. 클라이언트가 제공하는 규칙 히트 로그에서 (1) 어떤 규칙 이름이 선택됐는지, (2) 최종적으로 어느 그룹·노드로 나갔는지를 확인하세요. 기대와 다르면 그 규칙보다 위에 있는 줄 중 하나가 먼저 참이 된 것입니다. 브라우저 개발자 도구의 네트워크 탭에서 호스트명을 확인한 뒤, 그 문자열이 DOMAIN 계열과 맞는지, IP 기준 규칙을 쓰려면 해석된 IP가 무엇인지까지 좁혀 가면 재현 속도가 빨라집니다.

한 번에 여러 줄을 붙여 넣기보다, 세 줄 단위로 저장하고 재시작하는 식의 작은 배치가 롤백에 유리합니다. Git 등으로 프로필을 버전 관리해 두면, 어느 커밋에서 순서가 바뀌었는지도 추적하기 쉽습니다.

Clash Premium·Mihomo 등 코어마다 지원 타입·옵션 이름이 조금씩 다릅니다. 인터넷 예제를 붙여 넣기 전에, 지금 설치된 바이너리 버전의 공식 문서 한 페이지만 대조하는 습관이 오류를 크게 줄입니다.

분류 규칙은 개인 정보 보호, 회사 보안 정책 준수, 가족 네트워크의 악성 사이트 차단처럼 정당한 목적에 쓰일 때 가치가 큽니다. 타인의 네트워크나 서비스 약관, 현지 법령을 위반하는 우회 목적으로 활용해서는 안 됩니다. 공용 템플릿을 가져올 때도 출처와 갱신 주체를 확인하고, 민감한 환경이라면 Rule Provider URL까지 신뢰도를 검토하세요.

다음 단계: 규모가 커지면 모듈로 쪼개기

규칙이 수십 줄을 넘기 시작하면, 한 파일에 모두 적는 대신 rule-provider로 나누는 편이 유지보수에 유리합니다. 이 글에서 다룬 순서와 정책 이름 연결이라는 골격은 그대로 유지한 채, 본문에서는 RULE-SET,이름,정책 한 줄로 거대한 목록을 참조하게 됩니다. 아직 수동 규칙이 수십 줄 이하라면, 지금 구조를 손으로 익혀 두는 것만으로도 이후 마이그레이션이 훨씬 수월해집니다.

정리

사용자 정의 분류 규칙의 핵심은 세 가지입니다. 첫째, 위에서 아래로 첫 매칭만 적용된다는 실행 모델을 머릿속에 그려 둘 것. 둘째, 규칙 끝에 적는 문자열이 실제 proxy-groups 이름과 정확히 일치하는지 끊임없이 확인할 것. 셋째, 좁은 예외를 위에, 넓은 GEOIP·기본 MATCH를 아래에 두는 층형 설계를 습관화할 것입니다. 이 세 가지만 지켜도 「왜 이 사이트만 이상하지?」라는 질문의 상당 부분을 스스로 해결할 수 있습니다.

비슷한 범주의 도구들을 비교해 보면, Clash 계열은 규칙 표현이 읽기 쉽고 커뮤니티 예제도 풍부해 처음 손대기에 부담이 적은 편입니다. GUI로 시작했다가도 YAML 한 구석만 열어 순서를 바꿔 보는 경험이 쌓이면, 이후 TUN 전환이나 Meta 코어로 옮길 때 심리적 장벽이 낮아집니다.

설치 파일은 여러 채널이 있지만, 실행 파일을 받는 주 경로로는 검증된 배포 페이지를 쓰는 것이 안전합니다. 규칙을 손보다가 클라이언트를 재설치해야 할 때도 같은 곳에서 버전을 맞추면 재현이 쉽습니다.

Clash를 무료로 내려받고 규칙 기반 분류를 직접 이어가기