Clash 사용자 지정 규칙

규칙 우선순위: 먼저 매칭하고, 다음에 출구를 선택

Clash 규칙은 도메인의 구체성에 따라 자동 정렬되지 않습니다. 설정에 적힌 순서대로 위에서 아래로 확인하며, 일치하는 규칙을 찾으면 멈춥니다.정확한 도메인, 도메인 접미사, 규칙 세트 사이에 “정확한 규칙이 자동으로 우선한다”는 숨겨진 순위는 없습니다. 따라서 예외 규칙을 앞에, 일반 규칙을 뒤에, MATCH를 마지막에 두는 것이 가장 관리하기 쉽습니다.

두 단계로 나눠 이해해야 합니다. 규칙은 연결을 어떤 정책에 맡길지 결정하고, 정책 그룹은 실제로 어떤 출구를 사용할지 결정합니다. 규칙이 “업무 정책”에 연결했더라도 해당 그룹에서 현재 DIRECT를 선택했다면 연결은 직접 연결됩니다. 규칙이 적용되지 않은 것이 아니라 정책 그룹의 실제 선택이 예상과 다른 것입니다.

순서를 바꾸면 어떻게 될까?

rules:
  - DOMAIN-SUFFIX,example.org,업무 정책
  - DOMAIN,login.example.org,DIRECT
  - MATCH,업무 정책

login.example.org에 접속하면 첫 번째 접미사 규칙이 이미 일치하므로 두 번째 정확한 도메인 직접 연결 규칙은 실행되지 않습니다. 두 규칙의 순서를 바꾸면 로그인 하위 도메인이 먼저 DIRECT에 일치합니다. 여기서 “더 구체적”이라는 기준은 설정을 정리할 때 참고하는 순서일 뿐, 코어가 자동으로 규칙을 정렬하는 알고리즘은 아닙니다.

3단 구문과 도메인 매칭 범위

일반적인 규칙은 유형,매칭 값,대상 정책 형식입니다. 쉼표는 규칙의 각 필드를 구분하고, 줄 맨 앞의 하이픈은 YAML 목록 문법입니다. 둘을 혼동하지 마세요. 대상에는 기본 정책인 DIRECT, REJECT를 지정하거나, 설정에 이미 정의된 노드 또는 정책 그룹 이름을 지정할 수 있습니다.

도메인 규칙에 URL을 그대로 넣지 마세요

DOMAIN-SUFFIX 뒤에는 example.org를 입력해야 하며 https://example.org/path를 입력하면 안 됩니다. 프로토콜, 포트, 경로, 쿼리 매개변수는 도메인의 일부가 아닙니다. 일반 도메인 규칙으로 같은 사이트의 /video 경로만 프록시로 보내고 /account는 직접 연결하도록 나눌 수도 없습니다. HTTPS에서는 일반적인 트래픽 분기가 전체 URL 경로를 기준으로 하지 않습니다.

접미사 매칭은 도메인 레이블 경계를 따릅니다. example.org와 api.example.org는 위 접미사 규칙에 일치하지만 example.org.other.net은 일치하지 않습니다. 특정 도메인 계열에 같은 정책을 적용하려면 접미사 규칙을 우선 사용해 이름이 비슷한 사이트까지 잘못 매칭하는 일을 피하세요.

RULE-SET: 참조 위치가 우선순위

rule-providers는 규칙 출처를 선언하고, rules의 RULE-SET은 해당 규칙을 매칭 과정에 연결합니다. 규칙 파일만 내려받고 메인 규칙 목록에서 참조하지 않으면 트래픽 분기 효과가 자동으로 생기지 않습니다. 반대로 존재하지 않는 제공자 이름을 참조하면 설정을 불러오거나 규칙을 초기화할 때 오류가 발생할 수 있습니다.

mihomo 로컬 domain 규칙 세트 예시

아래는 파일을 사용하는 규칙 제공자 예시입니다. 경로는 코어의 작업 디렉터리를 기준으로 해석되며, 편집기에서 연 설정 파일의 위치를 기준으로 하지 않을 수도 있습니다. 데스크톱 클라이언트에서는 실제 작업 디렉터리부터 확인하세요. 예시의 “업무 정책”은 현재 설정의 proxy-groups 또는 노드 목록에 이미 정의되어 있어야 합니다.

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

rules:
  - DOMAIN,login.example.org,DIRECT
  - RULE-SET,work-domains,업무 정책
  - MATCH,업무 정책

다음은 rules/work-domains.yaml 파일의 내용입니다.

payload:
  - '+.example.org'
  - 'api.example.net'

이 domain 규칙 세트 형식에서 +.example.org는 루트 도메인과 하위 도메인을 포함하고, api.example.net은 정확한 도메인 하나를 뜻합니다. 첫 번째 로그인 도메인 예외가 RULE-SET보다 앞에 있으므로 여전히 우선 적용됩니다. 규칙 파일 안의 두 항목 순서를 바꿔도 이 외부 직접 연결 예외의 우선순위는 달라지지 않습니다.

behavior와 파일 내용의 형식을 맞추세요

• behavior: domain: 도메인 매칭 항목을 입력합니다. DOMAIN-SUFFIX,example.org,업무 정책처럼 3단으로 된 규칙을 그대로 넣으면 안 됩니다.
• behavior: ipcidr: 192.168.0.0/16과 같은 IP 네트워크 대역을 입력합니다. 도메인 목록이 아닙니다.
• behavior: classical: DOMAIN-SUFFIX,example.org 같은 규칙 표현식을 입력할 수 있습니다. 출구 정책은 외부의 RULE-SET에서 지정하므로 각 payload에 반복해서 추가하지 않습니다.

원격 제공자를 사용하려면 다운로드 주소, 업데이트 설정, 쓰기 가능한 로컬 저장 위치도 올바르게 설정해야 합니다. 업데이트 성공은 출처에서 데이터를 가져왔다는 뜻일 뿐, 내용 형식이 behavior와 일치한다는 보장은 아닙니다. 문제를 점검할 때는 “마지막 업데이트 시간”이 바뀌었는지만 보지 말고 제공자 로드 로그와 매칭 기록을 함께 확인하세요.

규칙 배치: 예외, 일반 규칙, 기본 규칙

아래는 메인 규칙 목록의 예시이며 전체 구독 설정 파일은 아닙니다. 앞에서 정의한 work-domains 제공자와 “업무 정책”이 이미 있다고 가정합니다. 기존 설정에 적용할 때는 원래의 rules 목록을 수정하고, 파일 끝에 같은 이름의 최상위 키를 다시 만들지 마세요.

mode: rule

rules:
  - DOMAIN,login.example.org,DIRECT
  - DOMAIN-SUFFIX,example.net,업무 정책
  - RULE-SET,work-domains,업무 정책
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,업무 정책

이 예시는 도메인 정책을 사설 IP 규칙보다 앞에 배치해, 확인된 업무 도메인에 업무 정책을 우선 적용합니다. “모든 사설 주소를 먼저 직접 연결”하는 것이 목적이라면 사설 IP 규칙을 앞으로 옮기세요. 다만 대상 IP를 그 시점에 알고 있는지, DNS 확인이 허용되는지도 고려해야 합니다. 규칙 순서는 실제 정책 선택을 반영하는 것이며 모든 네트워크에 맞는 고정 목록은 없습니다.

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

IP-CIDR 끝의 no-resolve는 해당 IP 규칙과 매칭하기 위해 도메인 조회를 새로 시작하지 않는다는 뜻입니다. 연결의 대상 IP를 이미 알고 있다면 네트워크 대역을 판별할 수 있습니다. 도메인만 있고 사용할 수 있는 대상 IP가 없다면 이 규칙은 자체 매칭을 위해 별도로 조회하지 않습니다. 브라우저의 DNS 조회를 차단하거나 mihomo의 DNS 모듈을 끄는 옵션은 아닙니다.

위 IPv4 사설망 예시만으로 모든 로컬 네트워크 상황을 처리할 수 있는 것은 아닙니다. IPv6 대상에는 IP-CIDR6를 고려해야 하고, 로컬 네트워크의 단일 레이블 호스트 이름에는 로컬 DNS도 관련됩니다. TUN 제외 경로는 트래픽 가로채기 계층의 설정이므로 몇 개의 DIRECT 규칙만으로 모든 로컬 트래픽이 가상 네트워크 인터페이스를 우회한다고 단정할 수 없습니다.

MATCH를 앞에 두면 뒤의 규칙이 적용되지 않습니다

MATCH에는 필터 조건이 없으므로 목록 첫 줄에 놓으면 이 목록으로 들어온 모든 연결을 처리합니다. 뒤에 있는 규칙은 문법이 올바르더라도 적용될 기회가 없습니다. 일반적으로 마지막에 기본 규칙을 하나만 두고 어떤 정책으로 연결할지 명확히 지정하세요. 기본 규칙이 없을 때의 암묵적인 동작에 기대어 설정이 의도대로 작동하는지 판단하지 마세요.

Clash 사용자 지정 규칙이 적용되지 않을 때 점검 순서

1. 트래픽이 코어에 전달되는지 확인하세요. 시스템 프록시, 앱 프록시 또는 TUN이 가로채는 연결만 규칙과 매칭될 수 있습니다. 시스템 프록시를 사용하지 않는 프로그램은 도메인 규칙을 추가해도 자동으로 Clash를 거치지 않습니다.
2. 현재 사용 중인 설정을 확인하세요. 클라이언트의 “구독” 또는 “설정” 화면에서 선택된 항목을 확인한 다음 실행 모드가 규칙 모드인지 확인하세요. 메뉴 이름은 클라이언트마다 다르므로 특정 클라이언트의 설정 경로를 모든 제품에 그대로 적용하면 안 됩니다.
3. 실제로 로드된 규칙 순서를 확인하세요. 구독 병합, 오버라이드, 스크립트로 인해 사용자 지정 규칙이 MATCH 뒤에 추가될 수 있습니다. 편집 화면에서 보이는 위치가 최종 실행 설정의 위치와 다를 수도 있습니다.
4. 이름과 들여쓰기를 확인하세요.업무 정책과 업무 프록시는 서로 다른 이름이며, 제공자 키도 글자까지 정확히 일치해야 합니다. YAML은 공백으로 들여쓰기하고 탭은 사용하지 마세요.
5. 새 연결을 만든 뒤 확인하세요. 이미 연결된 HTTP/2, HTTP/3 또는 WebSocket은 기존 출구를 계속 사용할 수 있습니다. 설정을 적용한 다음 해당 연결을 닫거나 대상 앱을 재시작하고 다시 테스트하세요.
6. 매칭된 규칙과 실제 출구를 함께 확인하세요. 연결 세부 정보에서 대상 호스트, 규칙 유형, 규칙 내용, 정책 경로를 확인하세요. 출구 노드가 바뀐 것만으로는 예상한 규칙에 매칭됐다고 볼 수 없습니다.

먼저 프록시 포트를 명시적으로 거치는 테스트를 해 보세요

현재 설정에서 mixed-port: 7890을 사용하는 것이 확인됐다면 아래 명령으로 HTTP 프록시를 통해 요청을 보낼 수 있습니다. 7890은 예시 포트이며 모든 클라이언트가 사용하는 고정 포트가 아닙니다. 실제 설정에 맞춰 사용하세요. -q는 사용자의 curl 설정 파일을 무시하며, --noproxy ""는 환경 변수에 설정된 우회 목록이 테스트에 영향을 주지 않도록 합니다.

curl -q --noproxy "" --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  --head https://example.org/

이 명령은 문제를 좁히기 위한 테스트 연결을 만들 뿐, 성능 측정 결과를 제공하지 않습니다. 요청에 실패하면 프록시 포트 연결 거부, DNS 오류, 출구 연결 실패, 원격 HTTP 응답을 구분해서 확인하세요. 한 번의 시간 초과만으로 규칙 문법이 잘못됐다고 판단하면 안 됩니다. 응답 페이지의 상태 코드도 규칙 매칭 기록을 대신할 수 없습니다.

curl은 올바른 규칙에 매칭되는데 브라우저에서 같은 도메인에 접속해도 연결이 표시되지 않는다면, 브라우저가 프록시를 사용하는지, 기존 연결을 재사용하는지, 다른 확장 프로그램이 트래픽을 가로채는지 먼저 확인하세요. DNS 캐시는 대상 주소에 영향을 줄 수 있지만 “캐시 비우기”가 트래픽 가로채기 방식과 실행 설정 점검을 대신해서는 안 됩니다.

구독 업데이트와 규칙 관리

구독이 생성한 설정을 직접 수정하면 다음 업데이트 때 원격 내용으로 덮어써질 수 있습니다. 클라이언트가 지원하는 오버라이드, 병합 또는 스크립트 기능을 사용해 몇 가지 예외 규칙을 로컬에 보관하는 편이 안전합니다. 구체적인 방식은 클라이언트마다 다르지만, 확인할 점은 두 가지입니다. 사용자 지정 규칙이 남아 있는지, 그리고 일반 규칙과 MATCH보다 앞에 배치되어 있는지 확인하세요.

수정할 때마다 대상 하나씩 확인하세요

• 먼저 정확한 도메인으로 확인하세요: DOMAIN 규칙 하나를 사용해 규칙이 적용되는지와 정책 이름이 유효한지 확인한 뒤 필요에 따라 접미사 규칙으로 범위를 넓히세요.
• 그다음 규칙 세트로 옮기세요: 단일 규칙이 정상 작동하는 것을 확인한 뒤 behavior에 맞는 파일에 넣으세요. 이렇게 하면 문법 문제와 규칙 출처 문제를 구분하기 쉽습니다.
• 마지막으로 예외를 처리하세요: 로그인이나 사내 네트워크 같은 예외를 이를 덮어쓸 수 있는 일반 규칙보다 앞에 배치하세요. 중복 규칙을 계속 추가하는 대신 순서를 정리하세요.
• 업데이트 후 다시 확인하세요: 최종 규칙 목록을 다시 열고 예외 도메인 하나와 일반 도메인 하나에 각각 새 연결을 만들어 매칭 규칙과 출구를 확인하세요.

Clash 사용자 지정 규칙은 개수가 중요한 것이 아니라 매칭 범위, 목록 순서, 출구의 의미가 서로 맞는지가 중요합니다. 먼저 트래픽이 코어에 전달되는지 확인하고, 최종 규칙 위치를 살핀 뒤, 정책 그룹의 선택을 확인하면 노드를 계속 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다. 특정 클라이언트의 트래픽 가로채기와 설정 가져오기는 클라이언트 사용 가이드를 참고하고, 규칙 유형과 코어 기능은 프로토콜 안내서에서 확인하세요.