Clash 사용자 지정 규칙 설정: DOMAIN-SUFFIX, GEOIP, MATCH 우선순위

먼저 규칙 모드를 확인하고 우선순위를 조정하세요

구체적인 예외 규칙을 앞에, 범위가 넓은 규칙을 뒤에 배치하고 마지막에 MATCH로 나머지 연결을 처리하세요. Clash의 일반 규칙 목록은 위에서 아래로 확인하며, 규칙 하나와 일치하면 지정된 정책을 적용하고 더 정확한 규칙을 찾지 않습니다. 규칙이 더 구체적이라고 해서 자동으로 우선순위가 높아지는 것은 아닙니다.

수정하기 전에 클라이언트가 규칙 모드인지 확인하세요. 전역 모드에서는 일반 규칙 목록에 따라 연결 경로를 정하지 않으며, 직접 연결 모드로는 프록시 규칙을 검증할 수 없습니다. 클라이언트마다 메뉴 이름은 다를 수 있으므로 모드 선택 메뉴에서 ‘규칙’ 또는 ‘Rule’을 선택하고, 실행 중인 설정에서 mode: rule인지 확인하세요.

규칙, 정책, 실제 연결 경로 구분하기

규칙: 연결이 조건에 맞는지 판단합니다. 예를 들어 도메인이 example.com으로 끝나는지 확인합니다.
정책: 연결을 처리할 대상을 정합니다. 기본 제공 정책인 DIRECT, REJECT 또는 PROXY라는 정책 그룹을 사용할 수 있습니다.
실제 연결 경로: 정책 그룹에서 현재 선택한 노드 또는 직접 연결 항목입니다. PROXY에 일치해도 원격 노드를 거친다는 뜻은 아니므로 그룹 내 선택 항목을 확인해야 합니다.

여기서 PROXY는 사용자 지정 그룹 이름이며 모든 설정에 기본으로 포함된 정책이 아닙니다. 구독 설정의 그룹 이름이 ‘노드 선택’이라면 규칙 끝에도 해당 이름을 정확히 입력해야 합니다. 이름이나 대소문자가 다르거나 해당 그룹이 없으면 설정을 불러오지 못할 수 있습니다.

DOMAIN, DOMAIN-SUFFIX, IP 규칙 구분하기

대상 정보에 맞춰 규칙 유형을 선택하세요. 도메인 규칙은 웹사이트와 서비스별 연결 경로를 지정할 때, IP 규칙은 고정 주소와 로컬 네트워크, IP 위치를 기준으로 판단할 때 적합합니다. 일반적인 형식은 유형,매칭할 값,정책이며, 매칭할 값이 없는 MATCH는 필드가 두 개뿐입니다.

유형	규칙 예시	매칭 범위
DOMAIN	`DOMAIN,api.example.com,DIRECT`	입력한 도메인 전체와 일치
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,PROXY`	루트 도메인과 모든 하위 도메인에 일치
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,PROXY`	도메인에 지정한 문자열이 포함된 대상과 일치
IP-CIDR	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	지정한 IPv4 대역과 일치
GEOIP	`GEOIP,CN,DIRECT`	IP 데이터로 CN에 해당하는지 판단
MATCH	`MATCH,PROXY`	앞선 규칙과 일치하지 않은 연결 처리

도메인 필드에는 호스트 이름만 입력하세요

DOMAIN-SUFFIX,example.com,PROXY처럼 입력하고 https://example.com/path는 사용하지 마세요. 프로토콜, 경로, 쿼리 매개변수, 포트는 입력하지 않으며 *.example.com도 필요하지 않습니다. 접미사 규칙은 example.com과 www.example.com을 모두 포함하지만 문자열이 비슷하다는 이유로 notexample.com까지 매칭하지는 않습니다.

DOMAIN-KEYWORD는 더 넓은 범위에 적용됩니다. example이라는 키워드는 원하는 웹사이트와 무관한 도메인에도 매칭될 수 있습니다. 문자열 매칭이 꼭 필요할 때만 사용하세요. 웹사이트별 규칙에는 보통 정확한 도메인이나 도메인 접미사를 먼저 고려합니다.

IP-CIDR과 GEOIP 구분하기

IP-CIDR은 주소가 특정 대역에 포함되는지 직접 확인하고, GEOIP는 커널이 불러온 IP 위치 데이터를 사용합니다. GEOIP는 대상 IP의 위치만 판단하며, 웹페이지 내용이나 도메인 등록 국가, 접속한 사용자의 위치를 기준으로 삼지 않습니다. 중국어 사이트라도 해외 CDN을 사용하면 GEOIP,CN에 매칭되지 않을 수 있습니다.

IPv6 대역에는 IP-CIDR6 규칙을 사용하세요. 예: IP-CIDR6,fc00::/7,DIRECT,no-resolve. IPv4 예외만 추가한 뒤 같은 서비스의 IPv6 연결도 동일한 경로를 이용할 것이라고 단정하지 마세요.

첫 번째 일치 규칙 기준으로 예외와 기본 규칙 배치하기

구체적인 충돌 사례를 살펴보겠습니다. api.example.com은 직접 연결하고 나머지 example.com 하위 도메인은 프록시로 연결하려는 경우, 정확한 도메인 예외를 접미사 규칙보다 앞에 둬야 합니다.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

api.example.com에 접속하면 첫 번째 규칙과 일치해 DIRECT가 선택됩니다.
www.example.com에 접속하면 첫 번째 규칙에는 일치하지 않고 두 번째 규칙에 일치해 PROXY로 전달됩니다.
다른 도메인에 접속하면 IP 위치를 계속 확인합니다. CN 조건에 해당하면 직접 연결됩니다.
앞의 모든 규칙에 일치하지 않으면 마지막 MATCH 규칙이 PROXY로 전달합니다.

앞의 두 규칙 순서를 바꾸면 접미사 규칙이 먼저 api.example.com을 처리하므로 정확한 도메인 규칙은 실행되지 않습니다. MATCH를 첫 번째에 두면 더 명확합니다. 뒤에 있는 일반 규칙은 모두 매칭 기회를 잃습니다.

불러올 수 있는 최소 설정으로 이름 확인하기

아래 설정은 구성 요소 간 관계를 보여주기 위한 것으로 원격 프록시 노드는 포함하지 않습니다. PROXY를 참조할 수 있도록 같은 이름의 선택 그룹을 만들고 임시로 DIRECT만 넣었습니다. 따라서 규칙이 이 그룹에 일치해도 최종 연결은 직접 연결됩니다. 실제로 사용할 때는 구독에 이미 포함된 노드와 정책 그룹을 유지하세요.

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mixed-port: 7890은 여기서 로컬 HTTP/SOCKS 혼합 프록시 포트를 뜻하며 규칙 매칭 조건이 아닙니다. 클라이언트가 다른 포트를 사용한다면 테스트 시 실제 수신 포트를 기준으로 하세요. 기존 설정을 수정할 때 최상위 rules:를 두 번 추가하지 말고 원래 목록을 수정하거나 클라이언트의 병합 기능을 사용하세요.

GEOIP, DNS, no-resolve의 관계 이해하기

먼저 명확한 도메인 규칙을 적용하고, IP 기준 판단이 필요한지 검토하세요. 연결에 도메인만 있고 사용할 수 있는 대상 IP가 없으면 IP 규칙이 DNS 조회를 유발할 수 있습니다. 자주 쓰는 도메인 예외를 GEOIP보다 앞에 두면 연결 경로를 명확히 하고 불필요한 IP 판단도 줄일 수 있습니다.

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

이 옵션을 지원하는 IP 규칙 끝에 no-resolve를 추가하면 해당 규칙을 확인하기 위해 도메인을 직접 조회하지 않습니다. 연결에 사용할 수 있는 IP가 이미 포함되어 있다면 이를 기준으로 판단할 수 있습니다. 시스템 DNS를 끄거나 이후 처리 과정에서 해당 연결이 절대 조회되지 않도록 보장하는 옵션은 아닙니다.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

이 설정은 no-resolve가 없는 설정과 결과가 다를 수 있습니다. 대상 IP가 아직 없으면 이 옵션이 붙은 GEOIP가 일치하지 않아 요청이 MATCH까지 넘어갈 수 있습니다. 조회를 줄이겠다는 이유로 모든 IP 규칙에 이 매개변수를 기계적으로 추가하지 마세요.

도메인 정보가 커널에 전달되지 않으면 도메인 규칙은 매칭할 수 없습니다

앱이 IP에 직접 연결하거나 암호화된 DNS 조회를 자체적으로 수행할 수 있습니다. 이 경우 연결 기록에 원래 도메인이 표시되지 않을 수도 있습니다. TUN이 네트워크 트래픽을 처리한다고 해서 모든 요청의 도메인 정보가 보존되는 것은 아닙니다. Fake-IP 매핑이나 스니핑 기능을 올바르게 설정하면 조건에 따라 도메인 정보를 복원할 수 있지만 모든 프로토콜에서 복원된다고 가정해서는 안 됩니다.

먼저 연결 상세 정보에서 호스트 이름과 대상 IP를 확인해 커널이 실제로 파악한 정보를 확인하세요.
다음으로 DNS 요청이 예상대로 커널에 전달되는지 확인하세요. 앱과 시스템이 각기 다른 경로로 DNS를 조회하지 않도록 합니다.
마지막으로 DNS 또는 스니핑 설정을 조정하세요. 도메인 정보가 없는 문제를 도메인 규칙을 계속 추가해 가리는 방식으로 해결하지 마세요.

rule-providers로 규칙 파일 분리하기

여러 번 관리해야 하는 규칙은 별도 파일에 넣고 RULE-SET으로 불러오세요. rule-providers는 규칙 출처를 선언하고 rules에서 참조하는 위치는 우선순위를 결정합니다. 제공기만 선언하고 참조하지 않으면 해당 규칙은 분류에 자동으로 적용되지 않습니다.

기본 설정에서 로컬 규칙 집합 선언하기

아래 예시는 mihomo에서 지원하는 로컬 파일 제공기를 사용하며, 파일 경로는 커널 작업 디렉터리를 기준으로 해석됩니다. 클라이언트가 별도의 설정 디렉터리를 사용할 수 있으므로 먼저 커널 작업 디렉터리를 확인한 다음 rules/local-direct.yaml을 만드세요.

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - DOMAIN,api.example.com,PROXY
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

규칙 파일에는 매칭 조건만 작성하기

아래 내용을 앞서 지정한 경로에 저장하세요. classical 형식에는 도메인과 IP 대역 등의 규칙 조건을 넣을 수 있습니다. 각 규칙에 최종 정책을 다시 지정할 필요는 없습니다. 기본 설정의 RULE-SET,local-direct,DIRECT에서 정책을 지정했기 때문입니다.

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,intranet.example.net
  - IP-CIDR,192.168.0.0/16,no-resolve

이 순서에서는 api.example.com이 기본 설정의 정확한 도메인 규칙에 먼저 일치해 PROXY로 전달되고, 나머지 규칙 집합 조건에 해당하는 연결은 DIRECT로 처리됩니다. RULE-SET을 맨 앞에 두면 규칙 집합의 접미사 조건이 API 도메인을 먼저 처리합니다.

behavior: domain, ipcidr, classical은 각각 파일 형식이 다르므로 선언만 바꾸고 호환되지 않는 파일 내용을 그대로 둘 수 없습니다. 다른 사람이 만든 규칙 집합을 사용할 때는 형식, 경로, 커널 지원 여부를 확인한 뒤 다시 불러오고 로그를 살펴보세요. 원격 제공기는 다운로드 및 업데이트 상태에도 영향을 받습니다. 다운로드에 실패했다면 규칙 순서가 잘못됐다고 단정하지 말고 제공기부터 점검하세요.

연결 기록으로 규칙 충돌 찾기

같은 대상으로 새 연결을 만든 다음 ‘일치한 규칙, 정책 경로, 실제 연결 경로’ 세 가지를 기록하세요. 페이지가 열리는지만 보고 규칙이 작동하는지 판단하지 마세요. 캐시, 기존 연결, 정책 그룹 선택 때문에 결과가 달라지지 않은 것처럼 보일 수 있습니다.

트래픽 처리 확인: 클라이언트의 연결 목록을 열고 접속을 한 번 시도하세요. 해당 연결이 보이지 않으면 규칙을 더 수정하기 전에 시스템 프록시, 앱 프록시 또는 TUN 설정을 확인하세요.
모드 확인: 규칙 모드인지 확인하고 수정한 설정이 실제로 활성화되어 있는지 확인하세요.
첫 번째 일치 규칙 확인: 연결 상세 정보나 로그에서 규칙 유형과 매칭 내용을 확인하고 기본 설정 또는 규칙 집합에서 해당 규칙의 위치를 찾으세요.
정책 경로 확인: 그룹에서 현재 선택된 항목을 확인하세요. 예를 들어 PROXY에 일치해도 그룹에서 DIRECT를 선택했다면 실제로는 직접 연결됩니다.
연결 다시 만들기: 설정을 저장하고 다시 불러온 다음 테스트 대상의 기존 연결을 끊고 다시 시도하세요. 기존 연결은 규칙을 업데이트해도 보통 자동으로 연결 경로가 바뀌지 않습니다.

지정한 로컬 포트로 테스트하기

혼합 프록시가 127.0.0.1:7890에서 실제로 요청을 받고 있다면 아래 명령으로 해당 포트를 거쳐 요청할 수 있습니다. 실제로 확인하려는 서비스를 테스트 대상으로 선택하세요. 여기서 예시로 든 예약 도메인은 명령 형식을 보여줄 뿐, 실제 회선 성능을 나타내지 않습니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

SOCKS를 통해 테스트하면서 도메인 처리를 프록시에 맡기려면 socks5h를 사용하세요. 로컬에서 먼저 DNS를 조회하는 테스트 방식과 도메인 정보가 다르게 전달될 수 있으므로 결과를 비교할 때 사용한 프로토콜을 기록하세요.

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

현상	먼저 확인할 항목	조치
모든 연결이 MATCH에 일치함	MATCH 위치, 대상에 도메인이 있는지, 앞선 규칙이 로드됐는지	기본 규칙을 마지막에 두고 실행 설정과 연결 정보를 확인하세요
정확한 도메인 예외 규칙이 적용되지 않음	앞에 배치된 접미사, 키워드 또는 RULE-SET 규칙	구체적인 예외를 이를 포함하는 규칙보다 앞에 두세요
프록시 그룹에 일치했지만 직접 연결됨	정책 그룹에서 현재 선택한 항목과 중첩된 정책 경로	원하는 연결 경로를 선택한 뒤 새 연결을 만드세요
설정을 다시 불러오지 못함	YAML 들여쓰기, 정책 이름, 규칙 집합 경로와 형식	오류 로그에서 문제 필드를 찾고 사용 가능한 설정을 복원한 뒤 하나씩 수정하세요

구독 업데이트 후에도 사용자 지정 규칙 유지하기

클라이언트가 공식 지원하는 영구 덮어쓰기, 병합 또는 사용자 지정 규칙 기능을 우선 사용하세요. 구독을 내려받으며 생성된 설정을 직접 편집하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 클라이언트마다 메뉴 이름과 처리 절차가 다르므로 해당 기능이 원본 설정을 수정하는지, 새 설정을 생성하는지, 일회성 실행 결과만 편집하는지 먼저 확인하세요.

편집기뿐 아니라 최종 실행 설정도 확인하기

삽입 위치 확인: ‘규칙 앞에 추가’는 구체적인 예외에 적합합니다. MATCH 뒤에 추가한 규칙은 매칭될 기회가 없습니다.
배열 처리 확인: 병합 방식에 따라 rules에 규칙을 추가하기도 하고 목록 전체를 대체하기도 합니다. 먼저 테스트 규칙 하나로 동작을 확인하세요.
이름 유지 여부 확인: 구독 업데이트로 정책 그룹 이름이 바뀌면 로컬 규칙도 함께 수정해야 존재하지 않는 정책을 참조하지 않습니다.
제공기 상태 확인: 기본 설정의 참조, 제공기 파일, 경로가 모두 유효해야 합니다. 하나라도 누락되면 설정을 불러오지 못할 수 있습니다.

한 번에 한 가지 규칙 유형만 수정하고 수정 전후에 사용할 수 있는 설정을 각각 보관하세요. 먼저 정확한 도메인 하나를 검증한 다음 도메인 접미사나 규칙 집합으로 범위를 넓히세요. 이렇게 하면 ‘규칙이 일치하지 않음’, ‘잘못된 정책에 일치함’, ‘연결 경로 자체에 연결할 수 없음’을 구분하기 쉽고 구독 업데이트 후에도 다시 확인하기 편합니다.