1. rules의 적용 범위와 기본 문법
rules는 설정 파일 최상위에 정의하는 순서가 있는 목록으로, 연결을 어떤 정책에 전달할지 결정합니다. 노드를 만들거나 속도를 측정하는 기능은 없습니다. 규칙 오른쪽에는 내장 정책인 DIRECT, REJECT를 입력하거나, 설정에 이미 등록된 프록시 노드 또는 정책 그룹 이름을 입력할 수 있습니다. 이름은 공백과 대소문자까지 정확히 일치해야 합니다.
이 문서는 Clash Nyanpasu에서 mihomo 코어를 사용하는 일반적인 규칙 모드를 기준으로 설명합니다. Clash 코어마다 지원하는 확장 규칙이 다를 수 있으므로 설정을 옮길 때는 먼저 클라이언트의 코어 정보나 시작 로그에서 실제 코어를 확인하세요. 아래의 기본 도메인 규칙은 트래픽 분기 원리를 이해하는 데 도움이 되지만, 모든 코어가 동일한 고급 필드를 지원한다고 단정할 수는 없습니다.
모드를 확인한 다음 필드를 편집하세요
- Rule 모드:
rules목록에 따라 연결의 경로를 결정합니다. 이 문서에서 다루는 모드입니다. - Global 모드: 전역 정책을 사용하며 일반적인
rules목록에 따라 트래픽을 분기하지 않습니다. - Direct 모드: 트래픽을 직접 연결로 처리하므로 프록시 분기 규칙을 테스트하는 데 사용할 수 없습니다.
YAML의 mode: rule은 규칙 모드를 뜻합니다. 클라이언트 인터페이스에서 실행 모드를 전환할 수도 있으므로 현재 실행 상태도 함께 확인하세요. 시스템 프록시와 TUN은 어떤 트래픽이 코어로 들어갈지 결정하며 규칙 우선순위를 바꾸는 설정은 아닙니다. 코어에 들어오지 않은 연결은 규칙을 추가해도 자동으로 처리되지 않습니다.
mode: rule
rules:
- DOMAIN,portal.example.com,DIRECT
- DOMAIN-SUFFIX,example.org,노드 선택
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,노드 선택2. 자주 쓰는 규칙 유형과 필드 위치
일반 규칙은 보통 '유형, 매칭 대상, 적용할 정책' 순서로 작성합니다. MATCH에는 매칭 대상이 필요하지 않습니다. 일부 IP 규칙에는 no-resolve를 추가할 수 있습니다. 인수는 영문 쉼표로 구분하고, 목록 항목 앞에는 하이픈과 공백을 붙이세요. 들여쓰기는 공백으로 통일하고 Tab은 사용하지 마세요.
| 유형 | 예시 | 매칭 기준 |
|---|---|---|
DOMAIN | DOMAIN,api.example.com,DIRECT | api.example.com이라는 완전한 도메인만 매칭합니다. |
DOMAIN-SUFFIX | DOMAIN-SUFFIX,example.com,DIRECT | 기본 도메인과 모든 하위 도메인을 매칭합니다. |
DOMAIN-KEYWORD | DOMAIN-KEYWORD,example,노드 선택 | 도메인에 특정 문자열이 포함되어 있는지 확인합니다. 매칭 범위가 넓습니다. |
IP-CIDR | IP-CIDR,10.0.0.0/8,DIRECT,no-resolve | IPv4 주소 대역을 매칭합니다. |
IP-CIDR6 | IP-CIDR6,fc00::/7,DIRECT,no-resolve | IPv6 주소 대역을 매칭합니다. |
GEOIP | GEOIP,CN,DIRECT | 대상 IP가 지리 데이터베이스에서 어떤 항목으로 분류되는지 기준으로 판단합니다. |
RULE-SET | RULE-SET,business,노드 선택 | business라는 이름의 규칙 제공자를 참조합니다. |
MATCH | MATCH,노드 선택 | 앞선 규칙에 매칭되지 않은 연결을 처리합니다. |
도메인 규칙에는 URL 경로를 입력하지 않습니다
DOMAIN의 매칭 대상은 호스트 이름이지 전체 URL이 아닙니다. https://api.example.com/login이 아니라 api.example.com으로 작성해야 합니다. 일반적인 도메인 규칙으로는 같은 호스트의 /login과 /images를 구분할 수 없습니다. HTTPS 요청의 경로도 일반 도메인 기반 트래픽 분기 조건으로 바로 사용할 수 없습니다.
DOMAIN-SUFFIX,example.com은 example.com과 a.example.com을 매칭하지만, 문자열이 비슷하다는 이유로 notexample.com을 매칭하지는 않습니다. 반면 DOMAIN-KEYWORD는 문자열 조건이라 범위가 넓어지기 쉽습니다. 따라서 일반적으로 명확한 도메인 예외 규칙 뒤에 배치해야 합니다.
3. 규칙 우선순위: 위에서부터 확인해 첫 번째 매칭 적용
일반 규칙 목록에는 '도메인 규칙이 IP 규칙보다 항상 우선한다'거나 '더 구체적인 규칙이 자동으로 먼저 적용된다'는 정렬 기능이 없습니다. 코어는 목록 순서대로 확인하며 처음 매칭된 규칙의 정책을 적용하고, 그 아래 규칙으로 덮어쓰지 않습니다. 구체적인 규칙을 넓은 범위의 규칙보다 앞에 두어야 예외로 제대로 작동합니다.
rules:
- DOMAIN,api.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,노드 선택
- MATCH,노드 선택api.example.com: 첫 번째 규칙에 매칭되어 직접 연결됩니다.www.example.com: 첫 번째 규칙은 매칭되지 않고 두 번째 규칙에 매칭되어 '노드 선택'으로 전달됩니다.example.net: 앞의 두 규칙에 매칭되지 않아 세 번째 규칙이 처리합니다.
두 번째 규칙을 첫 번째 규칙보다 위로 옮기면 api.example.com이 먼저 접미사 규칙에 매칭되어 원래의 직접 연결 예외가 적용되지 않습니다. 마찬가지로 MATCH를 목록 맨 위에 두면 뒤에 있는 일반 규칙은 매칭될 기회가 없습니다.
권장 규칙 정렬 순서
- 명확한 예외: 별도 처리가 필요한 완전한 도메인, 내부 서비스 또는 특정 기기 조건
- 로컬 네트워크 대상: 실제 네트워크 환경에 맞는 사설 주소 대역을 지정해 내부 서비스가 프록시를 거치지 않도록 합니다.
- 서비스별 규칙: 구체적인 도메인 접미사, 서비스별 규칙 세트, 의도적으로 설정한 차단 규칙
- 넓은 범위의 분류: 예를 들어 GEOIP에 따른 직접 연결 규칙
- 최종 기본 규칙: 알 수 없는 트래픽의 경로를 지정하는
MATCH규칙 하나
이 정렬 방법은 관리 편의를 위한 것이며 코어가 강제하는 고정 순서는 아닙니다. 특정 서비스 도메인을 반드시 프록시로 연결해야 한다면 해당 IP가 지리 데이터베이스에서 CN으로 분류되더라도 서비스 규칙을 GEOIP,CN,DIRECT보다 앞에 두세요.
4. IP-CIDR, GEOIP와 no-resolve
IP-CIDR,192.168.0.0/16,DIRECT는 192.168.0.0부터 192.168.255.255까지의 IPv4 주소를 포함합니다. IPv4 주소 하나만 처리하려면 /32, IPv6 주소 하나만 처리하려면 /128을 사용할 수 있습니다. 주소 대역은 실제 필요에 맞게 지정해야 하며 모든 사설 주소를 하나의 서비스 규칙으로 취급해서는 안 됩니다.
연결 대상이 도메인이면 IP 규칙의 매칭을 위해 도메인 조회가 필요할 수 있습니다. no-resolve를 추가하면 해당 규칙을 위해 도메인 조회를 새로 요청하지 않습니다. 연결에 사용할 수 있는 대상 IP가 이미 있으면 주소 매칭은 계속할 수 있습니다. 이 옵션은 클라이언트 전체의 DNS를 끄거나 모든 DNS 요청을 건너뛰는 기능이 아닙니다.
rules:
- DOMAIN,intranet.example.com,DIRECT
- 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
- GEOIP,CN,DIRECT
- MATCH,노드 선택내부 도메인으로 확인된 대상을 앞에 따로 배치한 이유는 no-resolve가 붙은 주소 규칙만으로는 도메인에 해당하는 내부 IP를 판단할 수 있다고 보장할 수 없기 때문입니다. GEOIP는 대상 IP를 데이터베이스 기준으로 분류하며 페이지 내용, 도메인 등록 국가 또는 서버 브랜드를 기준으로 하지 않습니다. CDN 주소와 데이터베이스 업데이트에 따라 결과가 달라질 수도 있습니다.
5. RULE-SET과 rule-providers 함께 사용하기
규칙이 많다면 매칭 조건을 규칙 제공자에 넣고 RULE-SET으로 참조할 수 있습니다. rule-providers는 데이터 출처와 형식을 정의하고, rules는 매칭 순서에서의 위치와 매칭 후 적용할 정책을 정합니다. 제공자 이름을 정의하는 것만으로 트래픽 분기에 자동으로 포함되지는 않으므로 rules에서 참조해야 합니다.
로컬 domain 규칙 세트 예시
아래 예시는 mihomo의 로컬 파일 제공자를 사용합니다. 설정 파일에서 지정한 경로에 해당 규칙 세트 파일을 넣으세요. 상대 경로는 실행 시 작업 디렉터리를 기준으로 하므로 다운로드한 파일의 위치만 보고 실제 경로를 판단해서는 안 됩니다. 클라이언트 로그에서 실제 파일을 읽은 경로를 확인할 수 있습니다.
rule-providers:
business:
type: file
behavior: domain
format: yaml
path: ./rules/business.yaml
rules:
- DOMAIN,health.example.org,DIRECT
- RULE-SET,business,노드 선택
- GEOIP,CN,DIRECT
- MATCH,노드 선택./rules/business.yaml의 내용은 다음과 같습니다. domain 유형에서는 +.example.org가 해당 도메인과 하위 도메인을 매칭합니다. domain 유형 목록에 DOMAIN-SUFFIX,example.org,노드 선택처럼 완전한 규칙 행을 그대로 넣지 마세요.
payload:
- '+.example.org'
- 'api.example.net'behavior: domain: 도메인 매칭 표현식을 사용합니다.behavior: ipcidr: IP 주소 대역을 사용합니다.behavior: classical: 해당 코어가 지원하는 규칙 조건을 사용합니다. 예를 들어DOMAIN-SUFFIX,example.org를 입력하며 일반적으로 항목에 적용할 정책은 지정하지 않습니다.
세 가지 behavior를 임의로 섞어 사용하면 안 됩니다. 원격 제공자는 다운로드, 업데이트, 캐시도 고려해야 하므로 문제를 진단할 때는 먼저 제공자가 정상적으로 로드됐는지 확인한 후 규칙 우선순위를 살펴보세요. 규칙 세트에 수천 개의 항목이 있더라도 메인 목록에서의 우선순위는 해당 RULE-SET 행의 위치에 따라 결정됩니다. 앞쪽 규칙에 이미 매칭된 연결을 다시 처리하지는 않습니다.
6. 구독 규칙 유지 및 덮어쓰기 확인
원격 구독을 업데이트하면 설정이 다시 생성될 수 있습니다. 다운로드한 YAML을 직접 수정하면 이번에는 적용되더라도 다음 업데이트 때 변경 사항이 사라지는 경우가 많습니다. 원본 구독은 유지하고 개인 규칙은 클라이언트에서 지원하는 로컬 덮어쓰기, 병합 또는 스크립트 처리 단계에 추가한 뒤 최종 적용 순서를 확인하는 편이 안전합니다. 설정 메뉴의 이름은 클라이언트 버전에 따라 다를 수 있으므로 '구독 텍스트 저장'을 지속적으로 유지되는 덮어쓰기와 같은 의미로 보면 안 됩니다.
- 현재 정상 작동하는 설정을 백업하고 선택한 Profile, 모드, 정책 그룹 이름을 기록합니다.
- 프로필 관리에서 실제로 사용 중인 설정인지 확인합니다. 활성화되지 않은 사본만 편집하지 않도록 주의하세요.
- 먼저 명확한 도메인 규칙 하나를 추가하고 기존의 넓은 범위 규칙보다 앞에 배치합니다.
- 실행 중 생성된 설정에서
rules가 하나만 있는지 확인하고 첫 번째 규칙, 규칙 세트 참조, 마지막MATCH를 점검합니다. - 구독을 한 번 업데이트한 뒤 규칙이 유지되는지, 순서가 바뀌었는지 다시 확인합니다.
병합 도구에 따라 목록을 대체하거나, 뒤에 추가하거나, 앞에 삽입할 수 있습니다. 텍스트에 새 규칙이 보인다는 것만으로 적용됐다고 볼 수 없습니다. MATCH 뒤에 추가된 규칙은 설정에 존재해도 매칭될 수 없습니다. 스크립트 덮어쓰기도 실행 성공 여부만 확인하지 말고 출력 결과를 점검하세요. YAML 구조와 필드 설명은 YAML 설정 가이드를 참고하세요.
7. 사용자 규칙이 적용되지 않을 때 점검 순서
문제를 확인할 때는 동일한 대상 호스트와 정책 그룹 선택을 유지하고 한 번에 조건 하나만 바꾸세요. 연결 패널에 표시되는 '매칭 규칙', '대상 정책', '실제 프록시 경로'는 서로 다른 정보입니다. '노드 선택'에 매칭됐다는 것은 해당 그룹에 연결을 전달했다는 뜻일 뿐이며, 그룹 안에서 DIRECT를 선택했다면 실제 연결은 직접 연결입니다.
| 증상 | 먼저 확인할 항목 | 조치 |
|---|---|---|
| 연결 패널에 대상 요청이 표시되지 않음 | 앱 트래픽이 코어에 들어오는지 | 시스템 프록시, 앱 프록시 또는 TUN 라우팅을 확인하고 먼저 트래픽 진입 경로를 해결합니다. |
| 범위가 넓은 기존 규칙에 매칭됨 | 사용자 규칙의 실제 순서 | 구체적인 예외 규칙을 기존 규칙보다 앞에 옮기고 덮어쓰기가 뒤에 추가된 것은 아닌지 확인합니다. |
| 정책을 찾을 수 없다는 알림 | 규칙 오른쪽에 입력한 그룹 이름 | 현재 설정에 등록된 그룹 이름을 정확히 복사하고 공백, 대소문자, 설정 전환 여부를 확인합니다. |
| RULE-SET 로드 실패 | 제공자 이름, 경로, behavior | 시작 로그와 파일 형식을 확인합니다. 트래픽을 테스트하기 전에 로드 오류부터 해결하세요. |
| 수정한 뒤에도 이전 정책이 적용됨 | 기존 연결이 재사용되고 있는지 | 대상 연결을 종료하고 새 요청을 시작합니다. 이미 열린 장기 연결을 새로 고치는 것만으로는 충분하지 않습니다. |
| 구독 업데이트 후 규칙이 사라짐 | 변경 사항이 생성된 파일에 저장됐는지 | 지속적으로 유지되는 덮어쓰기로 옮기고 업데이트 후 최종 설정을 확인합니다. |
최소한의 테스트 방법
- 실행 모드가 Rule인지 확인하고 선택한 설정이 적용됐는지 확인합니다.
- 실제 테스트 도메인에
DOMAIN규칙을 하나 추가하고 목록 앞부분에 배치합니다. - 설정을 저장하고 적용합니다. 파싱 오류가 있으면 백업을 복원하고 변경 사항을 더 추가하지 마세요.
- 해당 대상의 기존 연결을 종료한 뒤 다시 접속합니다.
- 연결 상세 정보에서 대상 호스트, 매칭 규칙, 정책 그룹, 실제 연결 경로를 확인합니다.
- 결과를 확인한 뒤 접미사 규칙이나 규칙 세트로 확장하고, 매칭되지 않을 때 적용되는 기본 경로도 다시 테스트합니다.
규칙 관리의 핵심은 세 가지입니다. 트래픽이 실제로 코어에 들어오는지, 매칭 조건이 연결 정보와 일치하는지, 대상 규칙이 이를 덮어쓰는 규칙보다 앞에 있는지 확인해야 합니다. 먼저 정확한 도메인으로 재현 가능한 결과를 확인한 다음 IP 분류와 규칙 세트를 추가하면 여러 항목을 한꺼번에 수정하는 것보다 원인을 찾기 쉽습니다. Profile, 정책 그룹, TUN의 개념은 용어 가이드를 참고하세요.