Clash YAML 규칙 분기 완전 가이드 2026: 정책 그룹·Rule Providers

전역 프록시가 아니라 규칙 분기를 써야 하는 이유

많은 초보 사용자가 Global에 가깝게 모든 트래픽을 한 노드로 보냅니다. 그러면 국내 쇼핑·뱅킹·포털까지 해외를 한 바퀴 돌아 지연이 커지고, 일부 사이트는 해외 IP를 비정상으로 보고 차단하기도 합니다. 반대로 Direct만 고정하면 해외 서비스가 막히거나 느려집니다.

Rule 모드는 요청마다 도메인과 IP를 보며 «이건 집 회선으로», «이건 프록시 그룹으로»라고 나눕니다. 설정 파일 안에서는 rules 배열의 각 줄이 한 번에 하나씩만 평가되며, 위에서 아래로 읽다가 처음 맞는 줄이 최종 정책이 됩니다. 그래서 순서를 잘못 쓰면 의도와 다른 노드로 나가거나 DIRECT가 안 되는 문제가 생깁니다.

Clash Meta(미호모)는 Rule Providers, 더 세밀한 정책 그룹, 스크립트형 확장 등으로 규칙을 크게 키우지 않고도 유지할 수 있게 돕습니다. 코어 자체에 대한 설치·업데이트는 미호모 코어 업그레이드 가이드를 참고하세요.

한 줄 요약 규칙 분기는 «목록의 순서가 곧 우선순위»입니다. 가장 자주 맞출 항목을 위에, 포괄적인 MATCH는 맨 아래에 두세요.

규칙은 어떻게 적용되나: 첫 매칭 원칙

각 규칙 줄은 대략 TYPE,ARGUMENT,POLICY 형태입니다. TYPE이 요청과 맞으면 그 줄의 POLICY가 선택되고, 그 아래 줄은 무시됩니다. 예를 들어 같은 도메인에 대해 DOMAIN-SUFFIX로 DIRECT를 주고, 그 아래에서 같은 접미사를 다시 프록시로 보내도 위쪽이 먼저 매칭되면 아래는 실행되지 않습니다.

실무에서는 (1) 반드시 직접 가야 하는 도메인, (2) LAN·로컬호스트, (3) 구독에서 받은 노드 이름을 묶은 정책 그룹, (4) 지역·IP 대역, (5) 마지막에 전부를 받는 MATCH 순으로 쌓는 경우가 많습니다. MATCH는 반드시 필요하며, 보통 «남은 모든 요청»을 사용자가 고른 기본 그룹(예: 자동·PROXY)으로 보냅니다.

정책 이름에 쓸 수 있는 것

POLICY 자리에는 DIRECT, REJECT, 단일 프록시 이름, 또는 proxy-groups에 정의한 그룹 이름이 올 수 있습니다. 오타가 나면 코어가 시작조차 못 하거나 해당 줄에서 오류가 납니다. 그룹 이름은 한글을 쓸 수 있지만, 편집기·백업 호환을 위해 영문·숫자 위주로 짓는 편이 안전합니다.

정책 그룹(proxy-groups): 사용자 경험을 설계하는 단계

proxies 목록은 실제 노드(서버)의 나열이고, proxy-groups는 그 노드들을 묶어 선택·자동 점검·고정 백업 등으로 동작하게 만드는 레이어입니다. 규칙 줄에서는 보통 그룹 이름을 가리키므로, «어떤 상황에 어떤 그룹을 쓸지»를 먼저 설계하는 것이 YAML을 읽기 쉽게 만듭니다.

유형	역할	언제 쓰나
`select`	사용자가 UI에서 하나를 고름	국가별·용도별 수동 전환
`url-test`	지연 시간 측정 후 가장 빠른 노드 선택	일반적인 «자동» 그룹
`fallback`	순서대로 시도하다 살아 있는 것을 사용	안정성 우선
`load-balance`	부하 분산	대역폭·세션 분산(클라이언트 지원 필요)
`relay`	체인 연결	다중 홉이 필요한 경우

url-test·fallback에는 보통 url(테스트용 HTTP 요청 주소), interval(초 단위 갱신 주기)을 함께 적습니다. 테스트 URL은 너무 무겁지 않은 엔드포인트를 쓰는 것이 좋고, 특정 국가만 열리는 주소는 오탐을 부를 수 있습니다.

최소 예시: 수동 선택과 자동 그룹

proxy-groups:
  - name: "수동"
    type: select
    proxies:
      - "자동"
      - "DIRECT"
      # 실제 proxies 항목 이름을 이어서 나열
  - name: "자동"
    type: url-test
    proxies:
      - "노드 A"
      - "노드 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

위에서 수동 그룹이 자동을 하위로 포함하면, 사용자는 UI에서 «자동 알고리즘으로 갈지, 직접 DIRECT로 갈지»를 고를 수 있습니다. 구독이 수십 개 노드를 넣어 주면 자동의 proxies 목록이 길어지므로, 지역별로 select를 나누는 식으로 단순화하기도 합니다.

rules 섹션에서 자주 쓰는 매칭 유형

미호모 문서와 커뮤니티 예제에서 반복되는 키워드 위주로 정리했습니다. 전부를 외울 필요는 없고, 로그에 찍힌 도메인·IP를 보고 어떤 타입을 쓰면 정확한지 고르면 됩니다.

DOMAIN — 정확히 일치하는 전체 도메인 한 개.
DOMAIN-SUFFIX — 접미사 일치(서브도메인 포함에 유리).
DOMAIN-KEYWORD — 도메인 문자열에 키워드 포함 여부(과매칭에 주의).
GEOIP — GeoIP 데이터베이스로 국가 코드 판별. GEOIP,CN 형태로 국내 트래픽을 DIRECT로 보내는 패턴이 흔합니다.
IP-CIDR 및 IP-CIDR6 — 특정 대역을 직접·프록시로 보냄. DNS가 가짜 IP를 쓰는 환경에서는 도메인 규칙과의 관계를 함께 봐야 합니다.
SRC-IP-CIDR — 소스 IP(특정 기기만 다른 정책).
PROCESS-NAME — 프로세스 이름(일부 데스크톱 클라이언트).
MATCH — 여기까지 왔다면 무조건 지정한 정책.

DOMAIN-KEYWORD는 편하지만 짧은 영단어를 쓰면 엉뚱한 사이트까지 걸립니다. 가능하면 DOMAIN-SUFFIX로 좁히거나 Rule Providers에 모아 두는 편이 낫습니다.

규칙 줄 예시

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - DOMAIN-SUFFIX,corp.internal,DIRECT
  - GEOIP,CN,DIRECT
  - GEOIP,private,DIRECT
  - MATCH,수동

위 예에서 국내·사설·로컬은 먼저 직접 연결하고, 나머지는 수동 그룹(앞서 만든 select)으로 넘깁니다. 실제 프로필에는 스트리밍·메신저 전용 그룹을 추가로 끼워 넣는 경우가 많습니다.

Rule Providers: 긴 규칙 목록을 URL로 관리하기

차단 목록·지역별 라우팅 세트처럼 수천 줄이 넘는 규칙을 rules에 직접 붙여 넣으면 파일이 비대해지고 diff도 어렵습니다. Rule Providers는 원격 YAML/텍스트를 받아 로컬에 캐시하고, 코어가 이를 규칙 소스로 합칩니다. 커뮤니티에서 공개한 리스트를 구독하거나, 자체 Git 저장소에 규칙만 올려 두고 URL로 불러올 수 있습니다.

설정 블록에는 보통 type: http(원격 URL), path(로컬 저장 경로), interval(갱신 주기), behavior(classical / domain / ipcidr 등 코어 버전에 따름)이 등장합니다. behavior는 내부 인덱싱 방식과 맞추는 옵션이므로, 제공자 문서나 예제와 동일하게 맞추는 것이 안전합니다.

선언 예시

rule-providers:
  my-rules:
    type: http
    behavior: classical
    url: "https://example.com/rules/clash.txt"
    path: "./rules/my-rules.yaml"
    interval: 86400

rules:
  - RULE-SET,my-rules,자동

이렇게 하면 원격 세트에 있는 모든 줄이 한꺼번에 자동 그룹으로 보내집니다. 다른 그룹으로 보내고 싶으면 마지막 인자만 바꾸면 됩니다. 여러 Rule Provider를 쓸 때는 어떤 목록이 먼저 적용될지를 rules 배열 순서로 조정하세요.

신뢰할 수 있는 소스만 Rule Provider URL은 제3자가 규칙을 바꿀 수 있습니다. 가능하면 체크섬·고정 태그·자체 미러를 쓰고, 이상한 리다이렉트가 없는지 주기적으로 확인하세요.

실무 패턴: 국내 직접·해외 프록시·예외 도메인

한국 사용자에게 흔한 구성은 다음과 같습니다. 국내 포털·은행·공공은 GEOIP,KR로 직접 연결하거나, 더 세밀하게는 도메인 규칙을 앞에 두고 나머지를 DIRECT로 묶습니다. 중국·일본 등 다른 지역을 함께 쓰는 환경이라면 GEOIP 줄을 그에 맞게 추가하면 됩니다. 글로벌 서비스는 프록시 그룹으로 보내고, 회사 VPN이나 사내망은 IP-CIDR로 먼저 빼 줍니다.

스트리밍 전용 노드가 있다면 DOMAIN-SUFFIX로 해당 서비스 도메인만 별도 select 그룹에 연결합니다. 이때 스트리밍 규칙을 GEOIP보다 위에 두어야 합니다. 그렇지 않으면 «이미 국내 IP로 보인다»며 DIRECT로 떨어져 재생 규제에 걸릴 수 있습니다.

구독 프로필을 그대로 쓰면서 사용자 규칙만 덧붙이려면, 클라이언트의 «사용자 규칙」「프로필 머지」 기능을 활용하는 방법도 있습니다. 문구는 제품마다 다르지만, 원리는 사용자 규칙이 구독 규칙보다 우선하도록 합치는 것입니다. 자세한 UI 동작은 도움말과 사용 중인 앱 설명을 함께 보세요.

DNS와 규칙: 같이 봐야 하는 이유

규칙이 도메인 기준이라면, 먼저 DNS로 IP를 알아내는 과정이 있습니다. fake-ip 모드를 쓰면 브라우저가 본 IP와 코어가 매칭에 쓰는 정보가 달라 보일 수 있어, «도메인 규칙이 왜 안 먹지?» 같은 혼란이 생깁니다. DNS 설정(dns 섹션)에서 enhanced-mode, nameserver/fallback 체인, 도메인별 DNS 분기 등을 규칙과 함께 설계해야 합니다.

실무 팁으로는, 문제가 될 때는 코어 로그에서 실제로 매칭된 규칙 이름과 DNS 해석 결과를 함께 확인하고, IP-CIDR 규칙이 예상보다 먼저 매칭되지 않는지 점검합니다. DNS 전용으로 더 깊은 글이 필요하면 기술 칼럼의 다른 주제를 기다려 주세요.

자주 나는 실수와 점검 순서

첫째, 그룹 이름 불일치입니다. rules에 적은 이름이 proxy-groups·proxies에 없으면 로드 오류입니다. 둘째, 순서 뒤바뀜입니다. 넓은 DOMAIN-KEYWORD를 위에 두면 세밀한 예외가 영원히 적용되지 않습니다. 셋째, GEOIP 데이터베이스 미설치·구버전으로 국가 판별이 틀리는 경우입니다. 넷째, Rule Provider URL이 깨졌는데도 캐시만 보고 있다가 규칙이 오래된 채로 남는 경우입니다.

점검은 (1) 코어 로그와 프로필 검증, (2) 테스트 사이트에 대해 어떤 줄이 선택되는지 확인, (3) 구독·Provider 갱신 시간 확인 순이면 대부분 원인을 좁힐 수 있습니다.

REJECT 남용 주의 광고 차단을 REJECT로 몰아넣기 쉽지만, 오탐 시 앱이 멈춘 것처럼 보일 수 있습니다. 차단 목록도 Rule Provider 하나로 모아 두고, 문제가 생기면 해당 Provider만 끄기 쉽게 정리하세요.

마무리

규칙 분기는 한 번 잘 짜 두면 일상에서는 거의 손대지 않아도 됩니다. 핵심은 매칭 순서와 정책 그룹 이름의 일관성, 그리고 긴 목록은 Rule Providers로 빼서 버전 관리하는 습관입니다. 비슷한 GUI라도 규칙 편집기·머지 방식이 달라 혼란이 올 수 있는데, 이때는 «코어가 읽는 최종 YAML 한 장」을 기준으로 생각하면 디버깅이 빨라집니다.

다른 도구들은 메뉴 구조만 다를 뿐, 안정적으로 구독을 불러오고 규칙을 합치며 미호모 코어를 최신으로 유지하는 경험이 크게 다르지 않습니다. 반복 설정에 시간을 쓰기보다, 검증된 클라이언트에서 프로필 한 번 맞춰 두는 편이 장기적으로는 더 편한 경우가 많습니다.

→ Clash 무료 다운로드 — 여러 플랫폼용 클라이언트를 한곳에서 받고, 규칙·구독·코어를 한 화면에서 다루기 쉬운 구성으로 시작해 보세요.

미호모 설치·코어 교체 절차는 코어 업그레이드 가이드와 함께 보면 흐름이 이어집니다. 추가로 다루길 원하는 주제가 있으면 기술 칼럼을 참고해 주세요.