규칙 모드가 중요한 이유

Clash 계열 클라이언트를 쓸 때 대부분의 사용자는 Rule(규칙) 모드를 기본으로 둡니다. 이 모드는 config.yaml의 rules: 배열을 위에서 아래로 훑으며, 처음으로 참이 되는 조건에 따라 해당 트래픽을 DIRECT(직접 연결)나 특정 프록시 그룹 이름으로 넘깁니다. 규칙을 잘 짜 두면 국내 사이트는 국내 회선으로 두고, 해외 서비스만 우회하는 식으로 지연과 비용을 동시에 줄일 수 있습니다. 반대로 순서가 뒤섞이거나 GEOIP·DNS 설정이 어긋나면, 원치 않는 경로로 나가거나 특정 앱만 끊기는 현상이 반복됩니다. 아래에서는 규칙 엔진의 사고방식을 공유하고, 자주 쓰는 규칙 유형과 프록시 그룹을 실무 관점에서 묶어 보겠습니다. 클라이언트 설치·모드 개념은 Windows 튜토리얼과 함께 보면 흐름이 더 분명해집니다.

규칙은 위에서 아래로, 한 줄에 한 번만

가장 흔한 오해는 “모든 규칙이 동시에 적용된다”는 것입니다. 실제로는 선형 탐색입니다. 그래서 더 구체적이고 예외가 되어야 할 규칙을 위에 두고, 넓은 범위의 규칙(예: GEOIP로 국가 전체를 DIRECT)은 아래쪽에 두는 패턴이 안전합니다. 예를 들어 특정 도메인만 반드시 프록시를 타게 하려면, 그 DOMAIN-SUFFIX 줄을 GEOIP,KR 같은 넓은 규칙보다 먼저 두어야 합니다. 코어가 mihomo(구 Clash Meta)인 경우에도 이 기본 모델은 같으며, 확장 문법이 추가되더라도 “첫 매칭이 승리”라는 점은 유지되는 것이 일반적입니다. 코어 전환 시 호환성은 mihomo 마이그레이션 가이드에서 다룹니다.

규칙만 바꿔도 체감 속도가 달라집니다. 구독이 제공하는 기본 규칙 세트를 그대로 쓰더라도, 자주 쓰는 서비스 몇 개는 직접 예외 줄을 추가해 두면 디버깅이 쉬워집니다.

도메인 계열 규칙: 문자열 매칭의 뉘앙스

DOMAIN은 정확히 일치할 때, DOMAIN-SUFFIX는 접미사(서픽스) 기준으로 하위 도메인까지 포함할 때 씁니다. 예를 들어 DOMAIN-SUFFIX,google.com은 www.google.com과 mail.google.com 모두에 걸립니다. DOMAIN-KEYWORD는 문자열이 포함되면 매칭되므로 범위가 넓어지기 쉽고, 의도치 않은 사이트까지 잡을 수 있어 신중하게 써야 합니다. DOMAIN-REGEX는 강력하지만 잘못 쓰면 CPU 부담이 커질 수 있어, 꼭 필요할 때만 쓰는 편이 좋습니다. 실무에서는 구독이 제공하는 대형 리스트 위에, 본인이 자주 쓰는 서비스 몇 줄만 DOMAIN-SUFFIX로 덧씌우는 방식이 가장 관리하기 편합니다.

도메인 규칙이 동작하려면 애플리케이션이 연결을 시도할 때 이미 도메인 이름이 보이는 경우가 많습니다. 반면 DNS가 꼬여 IP만 먼저 잡히거나, 앱이 처음부터 IP로 붙는 경우에는 도메인 규칙이 건너뛰어질 수 있어, 그때는 아래에서 설명하는 IP-CIDR·GEOIP와 함께 설계해야 합니다. DNS와 규칙의 관계는 문서 개요의 DNS 섹션과 같이 읽으면 전체 그림이 잡힙니다.

IP-CIDR과 GEOIP: 국가·대역으로 잡기

IP-CIDR은 특정 대역을 DIRECT나 프록시로 보낼 때 씁니다. 사내망·스토리지 API처럼 고정 대역이 명확할 때 유용합니다. GEOIP은 GeoIP 데이터베이스에 따라 IP를 국가 코드로 분류한 뒤, 예를 들어 GEOIP,CN,DIRECT 또는 GEOIP,KR,DIRECT처럼 기본 회선을 정할 때 많이 씁니다. 여기서 중요한 점은 데이터베이스 버전과 경로입니다. 코어·클라이언트가 사용하는 GeoIP 파일이 오래되었거나 경로가 비어 있으면, 기대와 다른 국가로 분류되거나 규칙이 스킵될 수 있습니다. 최신 클라이언트는 자동으로 데이터를 받아 오기도 하지만, 수동으로 맞추는 환경이라면 주기적인 갱신이 필요합니다.

GEOIP 규칙은 편하지만 맨 아래 쪽에 두는 경우가 많습니다. 그 위에 DOMAIN 기반 예외를 충분히 두지 않으면, “이 사이트만 직접” 같은 요구가 생길 때마다 목록 전체를 읽기 어려워집니다. 또한 GEOIP, ! 같은 부정 형태(지원 여부는 코어·버전 확인)를 쓰는 템플릿도 있는데, 가독성과 이식성을 위해 팀 내에서는 한 가지 스타일로 통일하는 것이 좋습니다.

프록시 전략 그룹: selector, url-test, fallback, load-balance

규칙 줄의 끝에는 DIRECT, REJECT, 또는 프록시 그룹 이름이 옵니다. 그룹은 proxy-groups:에서 정의하며, 타입에 따라 동작이 완전히 다릅니다. selector는 사용자가 UI에서 노드를 고르는 전형적인 “수동 선택” 그룹입니다. url-test는 지정한 URL에 대해 지연을 재고 가장 빠른 노드를 고릅니다. 간격·용 tolerance·테스트 URL은 구독 품질과 목적에 맞게 조정해야 하며, 너무 짧은 간격은 불필요한 부하를 일으킵니다. fallback은 순서대로 시도하며 살아 있는 첫 노드를 쓰는 패턴에 가깝고, 안정성을 우선할 때 선택됩니다. load-balance는 트래픽을 여러 노드에 나누는데, 해시 방식 등 세부 옵션은 코어 문서를 따라야 합니다.

실무 팁으로는, “메인 우회”용으로 url-test나 fallback 그룹 하나를 두고, 규칙에서는 그 그룹 이름만 반복해서 쓰면 유지보수가 쉽습니다. 지역별로 다른 노드 풀이 필요하면 selector를 여러 개 두고 규칙에서 각각 다른 그룹을 가리키면 됩니다. relay 체인은 노드를 순차 연결하는 고급 패턴으로, 지연이 늘어나기 쉬우므로 필요할 때만 쓰는 것이 좋습니다. 

# Example structure (illustrative; adjust to your core version)
proxy-groups:
  - name: "Auto"
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: "http://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,example.com,Auto
  - GEOIP,LAN,DIRECT
  - GEOIP,KR,DIRECT
  - MATCH,Auto

베스트 프랙티스: 유지보수 가능한 설정

첫째, 규칙과 그룹 이름을 짧고 일관되게 짓습니다. 둘째, 구독이 갱신될 때마다 덮어쓰이는 부분과 사용자가 덧붙이는 rules를 파일 분리나 주석으로 구분해 두면 업데이트 시 충돌이 줄어듭니다. 셋째, DNS가 fake-ip인지 redir-host인지에 따라 “도메인이 보이는지 / IP로만 가는지”가 달라지므로, 규칙이 기대대로 안 먹을 때는 DNS 블록을 함께 점검합니다. 넷째, 보안상 REJECT나 광고 필터 규칙을 쓸 때는 오탐으로 업무 사이트가 막히지 않도록 테스트 환경에서 먼저 검증합니다.

규칙을 과하게 늘리면 매 연결마다 비교 횟수가 늘어납니다. 불필요한 DOMAIN-KEYWORD·거대한 REGEX 남발은 피하고, 가능하면 공식 리스트·커뮤니티에서 검증된 세트를 기반으로 삼으세요.

정리

규칙 분류는 한 번 완성해 두면 매일 체감되는 영역입니다. GeoIP와 도메인 규칙, 프록시 그룹 타입을 각각의 역할에 맞게 배치하면, 같은 구독이라도 지연과 안정성이 달라집니다. 유사한 도구들과 비교했을 때 Clash 계열은 이런 선언적 YAML로 흐름을 한눈에 보게 만든다는 점에서 여전히 강점이 있습니다. 설정을 바꾼 뒤에는 클라이언트 로그에서 실제로 어떤 규칙에 매칭됐는지 확인하는 습관을 들이면, 문제가 생겼을 때 원인을 빠르게 좁힐 수 있습니다.

여러 기기에서 같은 정책을 쓰고 싶다면, 한 플랫폼에서 검증한 규칙 세트를 기준으로 다른 OS용 클라이언트에 옮겨 가며 미세 조정하는 방식이 효율적입니다.

→ Clash 공식 클라이언트 무료 다운로드 — 위에서 정리한 규칙·그룹 개념을 바로 적용해 볼 수 있도록, Windows·macOS·모바일 등 환경에 맞는 패키지를 한곳에서 받을 수 있습니다. 설치 후에는 Rule 모드에서 프록시 그룹만 바꿔 가며 체감 차이를 비교해 보세요.