규칙 설정

Clash 라우팅 규칙 실전: 처음부터 쓸 만한 rules 설정 작성하기

구독에 내장된 규칙은 너무 대략적이거나 신경 쓰는 앱을 아예 포함하지 않는 경우가 많습니다. 이 글은 매칭 순서부터 시작해 자주 쓰는 규칙 타입을 알아보고, 규칙 세트로 유지보수 부담을 최소화하는 방법까지 다룹니다.

구독에 내장된 규칙이 부족한 이유

대부분의 구독에는 자체 라우팅 규칙이 포함되어 있어 흔한 국내 직접연결, 해외 프록시, 광고 차단 상황을 커버하며 일상적인 사용에는 대체로 충분합니다. 하지만 요구사항이 조금이라도 특수해지면—예를 들어 특정 국내 앱은 프록시를 타야 하거나, 특정 게임 클라이언트는 반드시 직접연결이어야 하거나, 광고 도메인을 직접 추가하고 싶은 경우—구독에 내장된 규칙은 보통 수정할 수 없습니다(구독을 갱신하면 덮어써지기 때문). 이때는 설정 파일에 직접 rules 항목을 추가해야 합니다.

대부분의 클라이언트는 구독 규칙과 사용자 정의 규칙을 분리해서 관리하는 기능을 지원합니다(예: Clash Verge의 "오버라이드"/"병합" 기능). 사용자 정의 규칙을 오버라이드 파일에 작성해두면 구독이 갱신되어도 여러분의 규칙이 사라지지 않습니다. 구체적인 방법은 각 클라이언트 문서를 참고하시고, 이 글에서는 규칙 자체를 어떻게 작성하는지만 다룹니다.

먼저 매칭 순서를 이해하고 규칙을 작성하세요

rules는 배열이며, Clash는 위에서 아래로 순서대로 하나씩 비교해서 첫 번째로 일치하는 규칙을 찾으면 그 규칙이 지정한 아웃바운드를 즉시 사용하고, 이후 규칙은 더 이상 확인하지 않습니다. 즉 규칙의 순서는 내용 자체보다 실수하기 쉬운 부분입니다—포괄적인 규칙을 앞에 두면 뒤에 있는 더 정밀한 규칙은 영원히 적용될 기회가 없습니다.

config.yaml YAML
rules:
  # 위에서 아래로 매칭, 하나라도 맞으면 중단
  - DOMAIN-SUFFIX,ad.com,REJECT
  - DOMAIN-SUFFIX,google.com,프록시
  - GEOIP,CN,DIRECT
  - MATCH,프록시          # 최종 처리, 반드시 마지막에 두어야 함

흔한 실수: GEOIP,CN,DIRECT(국내 직접연결)를 광고 차단 규칙보다 앞에 두는 경우입니다. 광고 도메인이 해석된 IP가 하필 국내 IP라면 "국내 직접연결"에 먼저 매칭되어 "차단" 규칙은 무용지물이 됩니다. 규칙을 작성할 때는 항상 더 구체적이고 우선 적용되어야 할 규칙일수록 더 앞에 둬야 한다는 점을 기억하세요.

자주 쓰는 규칙 타입 실전

규칙 타입은 수십 가지가 있지만, 일상적으로 충분한 건 아래 몇 가지뿐입니다. 사용 빈도 순으로 정리했습니다.

  • 도메인류: DOMAIN-SUFFIX / DOMAIN-KEYWORD / DOMAINDOMAIN-SUFFIX,google.comgoogle.com과 그 모든 하위 도메인에 매칭되는, 가장 흔히 쓰이는 방식입니다. DOMAIN-KEYWORD는 도메인에 특정 키워드가 포함되어 있으면 매칭되어 "이 단어만 들어가면 차단/프록시" 같은 상황에 적합하지만 오탐에 주의해야 합니다. DOMAIN은 완전히 일치하는 도메인만 매칭되어 가장 정밀하지만 가장 적게 쓰입니다.
  • GEOSITE: 도메인을 카테고리별로 묶어서 관리GEOSITE,youtube,프록시는 YouTube 관련 도메인 전체 묶음에 곧바로 매칭되어 하나씩 직접 작성할 필요가 없습니다. 규칙 세트 커뮤니티가 거의 모든 주요 웹사이트/앱의 도메인 분류를 이미 정리해두었기 때문에 DOMAIN-SUFFIX를 손으로 쓰는 것보다 훨씬 간편합니다.
  • GEOIP: IP가 속한 국가/지역별로 매칭GEOIP,CN,DIRECT는 거의 모든 설정 파일에 기본으로 들어가는 최종 처리 규칙 중 하나로, 국내 IP로 해석되는 요청은 직접연결로 보내 프록시 트래픽을 소모하지 않습니다.
  • IP-CIDR: IP 대역으로 정밀 매칭내부망 주소 대역(예: 192.168.0.0/16), CDN 고정 IP 대역 등에 적합하며, no-resolve 파라미터와 함께 사용하면 불필요한 DNS 해석 한 번을 건너뛰어 매칭 속도를 높일 수 있습니다.
예시 코드 YAML
rules:
  # 내부망 주소는 직접연결, no-resolve로 DNS 해석 건너뛰기
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # 도메인 카테고리로 한꺼번에 매칭
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,netflix,프록시
  # 최종 처리: 국내 IP는 직접연결, 나머지는 프록시
  - GEOIP,CN,DIRECT
  - MATCH,프록시

규칙이 너무 많고 길다면? RULE-SET으로 규칙 세트 불러오기

차단해야 할 광고 도메인이 수백 개라면 rules 배열에 그대로 적어 넣으면 설정 파일이 극도로 비대해지고 재사용도 어렵습니다. 이럴 때는 rule-providers(규칙 세트)를 사용해서, 대량의 규칙을 별도의 파일/구독 링크에 두고 설정에서는 RULE-SET 한 줄로 참조하면 됩니다.

config.yaml YAML
rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/reject-list.txt"
    path: ./rule_providers/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,프록시
  • behavior는 규칙 세트 파일의 내용 형식을 결정합니다: domain(도메인 목록), ipcidr(IP 대역 목록), classical(거의 모든 타입을 지원하는 완전한 규칙). 세 가지는 작성 방식이 서로 다릅니다.
  • interval은 규칙 세트를 구독처럼 주기적으로 자동 업데이트해주므로, 광고 도메인 목록이 갱신되어도 설정을 수동으로 고칠 필요가 없습니다.
  • 커뮤니티가 관리하는 흔한 규칙 세트(예: 광고 차단 목록, 주요 스트리밍 서비스 도메인 목록)는 대부분 그대로 가져와서 쓸 수 있어 처음부터 직접 정리할 필요가 없습니다.

규칙 세트 내용 자체의 상세한 형식(세 가지 behavior를 각각 어떻게 작성하는지)은 문서 영역의 《규칙 세트 내용》을 참고하세요. 여기서는 반복해서 다루지 않습니다.

실전: "광고 차단 + 국내 직접연결 + 특정 앱 프록시" 설정 구성하기

앞에서 다룬 여러 규칙 타입을 조합하면 대부분의 사람에게 필요한 일상적인 설정 골격을 만들 수 있습니다.

config.yaml YAML
rules:
  # 1. LAN / 내부망 주소, 직접연결, 해석 건너뛰기
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # 2. 광고 차단, 규칙 세트, 최우선 순위
  - RULE-SET,reject,REJECT

  # 3. 특정 앱/사이트는 반드시 프록시로(국내 규칙보다 앞에 두어야 함!)
  - PROCESS-NAME,SomeApp.exe,프록시
  - GEOSITE,netflix,프록시
  - GEOSITE,youtube,프록시

  # 4. 국내 도메인/IP는 직접연결
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT

  # 5. 최종 처리: 나머지는 모두 프록시로
  - MATCH,프록시

3단계(지정 앱/사이트를 프록시로)는 반드시 4단계(국내 직접연결)보다 앞에 있어야 합니다. 순서가 반대라면 해당 도메인이 국내 IP 대역으로 해석되는 순간 4단계의 GEOIP,CN,DIRECT에 먼저 걸려버려 프록시 규칙은 영원히 적용될 기회가 없습니다.

자주 묻는 질문

규칙을 수정한 후 클라이언트를 재시작해야 하나요?

대부분의 클라이언트는 설정 핫 리로드를 지원합니다(보통 "설정 다시 불러오기" 또는 "Reload"라고 부름). 저장한 후 버튼 한 번만 누르면 바로 적용되며 클라이언트 전체를 재시작할 필요는 없습니다. 수정 사항이 적용되지 않는다면 잘못된 파일을 수정한 게 아닌지 확인해보세요(구독 규칙과 오버라이드 규칙은 서로 분리되어 있습니다).

규칙이 많으면 프록시 속도가 느려지나요?

규칙 매칭 자체는 순수한 메모리 연산으로, 수백 개의 규칙을 매칭하는 데 걸리는 시간은 보통 마이크로초 단위라 체감 지연은 거의 없습니다. 실제 체감 속도에 영향을 주는 건 DNS 해석과 노드 자체의 네트워크 품질이지 규칙 개수가 아닙니다.

추가한 IP-CIDR 규칙이 적용되지 않는 이유는 뭔가요?

가장 흔한 원인은 순서 문제입니다—앞쪽에 더 포괄적인 규칙(예: MATCH나 범위가 더 넓은 GEOIP)이 이미 먼저 매칭되고 있는 경우입니다. 컨트롤 패널의 "규칙" 페이지에서 해당 IP/도메인을 검색해서 실제로 어느 규칙에 매칭되는지 확인하면 보통 한눈에 문제를 찾을 수 있습니다.

더 알아보기

다 배우셨나요? Clash를 설치해서 직접 사용해보세요

모든 플랫폼의 설치 파일을 한곳에서 받을 수 있으며, 추천 태그를 따라 선택하면 실수할 일이 없고 몇 분이면 바로 사용할 수 있습니다.

다운로드 페이지로 이동
#규칙설정 #RULE-SET #라우팅실전
블로그 목록으로 돌아가기
Clash 클라이언트 다운로드모든 플랫폼 설치 파일, 지금 바로 시작