2026-08-24 · 규칙 심화 · 예상 읽기 시간 12분

Clash 사용자 규칙 설정 가이드: DOMAIN-SUFFIX·IP-CIDR·RULE-SET 매칭 순서

Clash 규칙 문법과 위에서부터 첫 번째로 일치하는 규칙이 적용되는 방식을 살펴봅니다. 사용자 규칙을 구독 규칙 앞뒤에 배치할 때의 차이도 설명합니다.

규칙 매칭 순서: 위에서 아래로, 일치하면 즉시 종료

특정 사이트를 직접 연결하도록 지정했는데도 프록시를 이용한다면, 규칙 종류를 잘못 선택한 게 아니라 앞쪽 규칙이 먼저 일치했을 가능성이 큽니다. Clash의 rules는 순서가 있는 목록입니다. 코어는 첫 번째 규칙부터 확인하다가 적용 대상과 일치하는 규칙을 찾으면 해당 규칙에 지정된 경로를 사용하며, 더 구체적인 규칙을 찾으려고 아래로 계속 진행하지 않습니다.

여기서 코어는 연결을 처리하고 트래픽을 분기하는 프로그램을 뜻합니다. Clash Meta는 이후 mihomo라는 이름으로 개발이 이어지고 있습니다. 클라이언트는 구독, 켜기·끄기, 연결 기록 등을 관리하는 인터페이스입니다. 아래 예시는 mihomo에서 자주 사용하는 YAML 설정을 기준으로 설명합니다. YAML은 들여쓰기로 계층을 표현하는 텍스트 형식입니다. 들여쓰기에는 공백을 사용하고 탭은 섞지 마세요.

구체적인 규칙이라고 우선순위가 자동으로 높아지지는 않습니다

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN,docs.example.com,DIRECT
  - MATCH,PROXY

docs.example.com에 접속하면 첫 번째 접미사 규칙이 이미 일치하므로 PROXY를 사용합니다. 두 번째 규칙이 더 구체적이어도 실행되지 않습니다. 문서 사이트를 직접 연결하려면 두 번째 규칙을 첫 번째 규칙보다 앞에 배치하세요.

이 글에서 PROXY는 예시 정책 그룹의 이름이며, 모든 설정에 기본으로 포함된 고정 키워드는 아닙니다. 현재 설정에 실제로 존재하는 정책 그룹 이름으로 바꾸고 대소문자와 공백도 정확히 맞춰 주세요. DIRECT는 내장 직접 연결 정책이고 REJECT는 내장 거부 정책이므로 그대로 사용할 수 있습니다.

DOMAIN과 DOMAIN-SUFFIX: 도메인 정확 일치와 접미사 일치

일반적인 규칙 형식은 ‘유형, 매칭 대상, 적용 정책’이며, 각 항목은 영문 쉼표로 구분합니다. 도메인 규칙에는 호스트명만 적고 https://, 경로, 쿼리 매개변수, 마지막 슬래시는 넣지 않습니다. 웹 주소에서 /account는 도메인에 포함되지 않습니다.

규칙 유형	예시	매칭 범위
DOMAIN	`DOMAIN,docs.example.com,DIRECT`	해당 호스트명만 매칭하며 하위 도메인은 포함하지 않습니다.
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,PROXY`	example.com 자체와 모든 단계의 하위 도메인을 매칭합니다.
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,PROXY`	도메인에 example이 포함된 연결을 매칭합니다. 접미사 규칙보다 범위가 넓습니다.

접미사 규칙은 도메인 경계를 기준으로 매칭합니다

DOMAIN-SUFFIX,example.com,PROXY는 example.com, api.example.com, a.b.example.com과 일치하지만 notexample.com과는 일치하지 않습니다. *.example.com으로 쓰거나 매칭 대상 앞에 점을 붙일 필요가 없습니다.

로그인 호스트만 직접 연결하려면 DOMAIN,login.example.com,DIRECT를 우선 사용하세요. 조직의 하위 도메인 전체를 같은 경로로 보내야 한다면 DOMAIN-SUFFIX를 사용합니다. 키워드 규칙은 넓은 범위의 매칭이 꼭 필요한 경우에 적합합니다. 모든 도메인 접미사 규칙을 대신해 사용하면 관련 없는 사이트까지 함께 분기될 수 있습니다.

IP-CIDR와 no-resolve: 대상 IP 주소에 따라 트래픽 분기

IP-CIDR은 IPv4 대상 주소 범위와 매칭합니다. CIDR은 ‘주소와 접두사 길이’를 함께 표시하는 방식입니다. 예를 들어 192.168.50.0/24는 192.168.50.0부터 192.168.50.255까지의 주소 범위를 뜻하며, 마지막에 적힌 주소 하나만 매칭하는 것이 아닙니다. 단일 IPv4 주소는 /32로 표시할 수 있습니다.

rules:
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR,10.20.30.40/32,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,PROXY

위 예시의 IP-CIDR6은 IPv6에 사용합니다. 세 주소 범위는 작성 방법을 보여 주는 예시일 뿐이므로 실제 로컬 네트워크 범위에 맞게 조정하세요. 특히 지나치게 넓은 주소 범위를 직접 연결 목록에 넣으면 원래 프록시로 접속하려던 연결까지 영향을 받을 수 있습니다.

no-resolve는 DNS를 끄는 옵션이 아닙니다

DNS는 도메인을 IP 주소로 변환하는 과정입니다. 도메인은 있지만 대상 IP를 아직 얻지 못한 연결에서는 IP 규칙의 일치 여부를 판단하기 위해 DNS 조회가 발생할 수 있습니다. 끝에 no-resolve를 붙이면 이 규칙을 확인하는 용도로만 도메인을 새로 조회하지 않습니다. 연결에 이미 사용할 수 있는 대상 IP가 있다면 규칙은 여전히 매칭될 수 있습니다.

따라서 no-resolve는 클라이언트 전체의 DNS를 끄지도 않고, 특정 도메인을 자동으로 프록시 우회시키지도 않습니다. 특정 사이트를 항상 직접 연결하려면 먼저 도메인 규칙을 작성하고, 특정 사설망 주소 범위를 직접 연결하려면 IP 규칙을 작성하는 편이 일반적입니다. 도메인을 가져오는 방식, DNS 모드, 스니핑 설정에 따라 코어가 확보하는 정보가 달라집니다. 문제를 확인할 때는 브라우저 주소창만 보지 말고 연결 세부 정보를 확인하세요.

RULE-SET: 규칙 집합을 참조해도 순서는 바뀌지 않습니다

RULE-SET은 규칙 제공자(rule-provider)를 참조합니다. 제공자는 도메인이나 주소 목록을 불러오고, rules의 참조 항목은 해당 목록과 일치하는 연결에 적용할 정책을 결정합니다. 집합 이름, 제공자 유형, 파일 내용이 서로 맞아야 합니다. 참조 한 줄만 붙여 넣는다고 집합이 자동으로 만들어지지는 않습니다.

로컬 도메인 집합 예시

아래는 기존 설정에 병합해서 사용하는 설정 조각이며, 단독으로 실행할 수 있는 완전한 구독 설정이 아닙니다. 먼저 기존 설정에 PROXY라는 정책 그룹이 있는지 확인한 다음 제공자와 규칙을 각각 해당 최상위 항목에 병합하세요.

rule-providers:
  work-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work-domains.yaml

rules:
  - DOMAIN,login.example.com,DIRECT
  - RULE-SET,work-domains,PROXY
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,PROXY

그다음 코어가 사용하는 작업 디렉터리에 rules/work-domains.yaml을 만드세요. 상대 경로는 클라이언트가 실제로 사용하는 코어 작업 디렉터리를 기준으로 하며, 설치 디렉터리와 다를 수 있습니다. 파일 내용은 다음과 같이 작성할 수 있습니다.

payload:
  - 'example.com'
  - '+.example.org'

이 도메인 집합에서 example.com은 해당 도메인을 뜻하고, +.example.org는 example.org와 그 하위 도메인을 뜻합니다. 제공자의 behavior가 domain이므로 여기에 넣는 것은 도메인 매칭 항목입니다. DOMAIN-SUFFIX,example.org,PROXY처럼 작성하면 안 됩니다.

domain, ipcidr, classical의 차이

domain: 집합 항목을 도메인 매칭 문법으로 작성하며 도메인 목록에 적합합니다.
ipcidr: 집합 항목은 IP 주소 범위입니다. 예: 192.168.50.0/24.
classical: 집합 항목을 규칙 유형과 매칭 조건으로 작성합니다. 예: DOMAIN-SUFFIX,example.org. 적용 경로는 바깥쪽 RULE-SET에서 지정하므로 각 집합 항목 뒤에 정책 그룹을 추가하지 않습니다.

원격 제공자를 사용하려면 URL, 업데이트 간격 등의 설정도 필요합니다. 구독에 포함된 원격 집합을 사용할 때는 먼저 정상적으로 불러왔는지 확인한 다음 매칭 순서를 점검하세요. 파일 다운로드 실패, 형식 오류, 집합 이름 오타는 앞선 규칙이 먼저 일치하는 문제와는 별개입니다.

사용자 규칙은 구독 규칙 앞과 뒤 중 어디에 둘까요?

구독을 업데이트하면 설정이 다시 생성되는 경우가 많습니다. 다운로드한 YAML을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 클라이언트에서 제공하는 영구 오버라이드나 규칙 병합 기능을 사용하는 편이 안전합니다. 오버라이드는 구독 원본과 별도로 변경 사항을 저장한 뒤, 활성화할 때 코어 설정에 합치는 기능입니다.

클라이언트마다 메뉴 이름, 병합 방향, 스크립트 인터페이스가 다릅니다. ‘추가 완료’라는 표시만 보고 규칙이 적용됐다고 판단하지 마세요. 최종 적용 설정에서 규칙이 앞에 추가됐는지, 끝에 추가됐는지, 아니면 전체가 교체됐는지 확인해야 합니다. 기본적인 화면 사용법은 사용 안내서를 먼저 참고하세요.

권장 순서: 예외 규칙은 앞에, 집합은 중간에, 기본 규칙은 마지막에

rules:
  # 사용자 지정 예외: 우선 적용
  - DOMAIN,docs.example.com,DIRECT
  - DOMAIN,blocked.example.net,REJECT

  # 기존 구독 규칙: 아래는 위치만 표시
  - DOMAIN-SUFFIX,example.com,PROXY
  - RULE-SET,work-domains,PROXY
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

  # 앞에서 일치하지 않은 연결을 마지막으로 처리
  - MATCH,PROXY

MATCH는 기본 규칙이므로 매칭 대상을 지정하지 않습니다. 여기까지 도달한 연결은 모두 해당 규칙의 정책을 사용합니다. 클라이언트가 사용자 규칙을 기존 MATCH 뒤에 추가하면 해당 규칙은 실행되지 않습니다. 사용자 규칙을 앞쪽에 추가하거나 최종 기본 규칙 앞에 삽입하세요. 같은 항목을 반복해서 추가하는 것은 해결책이 아닙니다.

규칙이 적용되지 않을 때: 연결 기록을 단계별로 확인

규칙을 수정한 뒤 설정을 다시 불러오고, 대상 앱의 기존 연결을 종료한 다음 새 요청을 보내세요. 브라우저는 이미 연결된 세션을 재사용할 수 있습니다. 기존 연결은 규칙이 바뀌어도 새 경로로 자동 전환되지 않는 경우가 많습니다. 테스트할 때 규칙을 한두 개씩만 바꾸면 결과를 비교하기 쉽습니다.

활성 설정과 모드를 확인하세요. 현재 어떤 구독 설정이 활성화되어 있는지, 동작 모드가 규칙 모드인지 확인합니다. 활성화되지 않은 설정을 편집해도 현재 트래픽에는 영향을 주지 않습니다.
트래픽이 코어로 전달되는지 확인하세요. 클라이언트의 ‘연결’ 화면을 열고 대상 도메인이나 IP를 검색합니다. 기록이 없다면 시스템 프록시, 앱 자체 프록시, TUN이 트래픽을 가져오는 범위를 먼저 확인하세요.
일치한 규칙을 확인하세요. 연결 세부 정보에서 규칙 유형, 규칙 내용, 정책 체인을 찾아보세요. 클라이언트마다 항목 이름은 다를 수 있지만 실제로 어떤 규칙이 일치했는지 확인하는 것이 핵심입니다.
최종 설정의 규칙 순서를 확인하세요. 범위가 넓은 접미사 규칙이나 집합이 일치했다면 더 구체적인 예외를 그 앞에 배치하세요. MATCH가 일치했다면 규칙 내용과 제공자가 실제로 매칭되는지 확인합니다.
적용 경로가 예상과 맞는지 확인하세요. PROXY가 일치했다는 것은 해당 정책 그룹으로 전달됐다는 뜻일 뿐입니다. 그룹에서 현재 DIRECT를 선택했다면 최종 연결은 직접 연결입니다.
구독을 한 번 업데이트한 뒤 다시 테스트하세요. 사용자 규칙이 남아 있는지, 위치가 바뀌지 않았는지 확인합니다. 이 과정에서 ‘임시 수정은 적용됐지만 업데이트 후 사라짐’ 문제를 찾아낼 수 있습니다.

요청 세 번으로 규칙 순서를 확인하는 방법

앞서 나온 도메인 예시를 기준으로 docs.example.com에 접속하면 정확한 도메인 규칙이 일치해 직접 연결되어야 합니다. api.example.com에 접속하면 접미사 규칙이 일치해 PROXY를 사용해야 합니다. 다른 규칙에 걸리지 않는 대상은 MATCH에 도달해야 합니다. 이 도메인들은 규칙 관계를 설명하기 위한 예시입니다. 실제 테스트에는 접속 가능하고 용도를 확인한 도메인을 사용하세요.

한 페이지에서 로그인, 이미지, 동영상, API 등 여러 호스트에 요청을 보낼 수도 있습니다. 메인 사이트에만 규칙을 설정해도 모든 리소스가 같은 경로를 사용하는 것은 아닙니다. 페이지는 열리지만 이미지가 로드되지 않는다면 먼저 연결 기록에서 실패한 리소스의 도메인을 찾고, 정확한 규칙을 추가할지 접미사 범위를 넓힐지 결정하세요.

자주 묻는 규칙 관련 질문

DOMAIN-SUFFIX와 IP-CIDR이 동시에 일치하면 어느 규칙이 우선하나요?

일반적으로 규칙 목록에서 앞에 있는 항목이 우선합니다. ‘도메인이 IP보다 항상 우선한다’는 고정 원칙은 없습니다. 연결에 판단에 필요한 도메인이나 IP 정보가 있는지, no-resolve가 해당 규칙을 위한 DNS 조회를 막고 있는지도 확인해야 합니다. 명확한 도메인 예외를 앞에 두면 이해하고 관리하기 쉽습니다.

TUN으로 전환해도 사용자 규칙이 필요한가요?

트래픽 분기 방식에 따라 필요할 수 있습니다. TUN은 가상 네트워크 인터페이스로 트래픽을 가져오는 방식이지, 새로운 규칙 우선순위 체계가 아닙니다. 트래픽이 코어로 들어오면 규칙 모드에서는 여전히 규칙 순서에 따라 정책을 선택합니다. 특정 로컬 네트워크 대상에 연결조차 되지 않는다면 라우팅, TUN 제외 범위, 방화벽도 함께 확인하세요.

REJECT 규칙을 설정했는데 웹페이지가 차단되지 않는 이유는 무엇인가요?

먼저 해당 도메인이 앞쪽 규칙에서 허용됐는지 확인하고, 페이지가 다른 리소스 도메인을 사용하거나 기존 연결을 재사용하는지도 살펴보세요. REJECT는 실제로 해당 규칙과 일치한 연결에만 적용되며 웹페이지 제목을 기준으로 서비스 전체를 식별하지 않습니다. 수정한 뒤 연결을 새로 만들고 연결 세부 정보의 매칭 기록을 기준으로 확인하세요.

규칙을 관리할 때는 목적이 분명한 예외만 필요한 만큼 유지하세요. 변경할 때마다 ‘무엇을 매칭하는지, 어떤 정책으로 보내는지, 어디에 두는지’를 기록한 다음 연결 기록으로 검증합니다. 트래픽 가로채기, 규칙 매칭, 정책 그룹의 최종 경로를 나눠서 확인하면 대부분의 ‘규칙을 작성했는데 달라진 게 없음’ 문제를 구체적인 단계에서 찾아낼 수 있습니다.