Clash 사용자 규칙 설정 방법: DOMAIN-SUFFIX, IP-CIDR 및 규칙 우선순위

규칙 한 줄의 구조: 유형, 매칭 조건, 아웃바운드 정책

Clash 사용자 규칙은 설정 파일의 rules 목록에 작성합니다. FlClash에서 mihomo 코어를 사용하면 요청 정보를 바탕으로 규칙을 차례대로 확인하고, 일치하는 규칙이 나오면 지정된 정책으로 연결합니다. 먼저 수정할 설정이 클라이언트에서 선택되어 있는지 확인하고, 아웃바운드 모드를 「규칙」으로 설정하세요. 전역 모드와 직접 연결 모드에서는 일반 규칙 목록에 따라 트래픽을 분기하지 않습니다.

대부분의 규칙은 규칙 유형,매칭 조건,아웃바운드 정책의 세 부분으로 구성됩니다. 각 부분은 영문 쉼표로 구분하며, YAML 목록 항목은 하이픈과 공백으로 시작합니다. 다음은 기존 설정에 추가할 수 있는 규칙 예시입니다.

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

DOMAIN은 유형으로, 도메인 전체를 정확히 매칭합니다. login.example.com은 조건이고, DIRECT는 직접 연결을 뜻합니다.
REJECT는 연결을 거부하는 정책입니다. 두 번째 줄은 차단 예시이므로 실제 설정 전에 차단할 도메인 범위를 확인하세요.
no-resolve는 네 번째 항목에 넣는 선택적 옵션으로, 관련 IP 규칙에 사용합니다. 정책 이름이 아닙니다.
MATCH는 최종 규칙입니다. 매칭 조건이 없으므로 두 부분으로만 구성됩니다.

DOMAIN과 DOMAIN-SUFFIX: 도메인 정확히 일치 및 접미사 매칭

로그인 주소나 API, 다운로드 도메인 하나만 처리하려면 DOMAIN을 사용하세요. 기본 도메인과 모든 하위 도메인을 포함하려면 DOMAIN-SUFFIX를 사용합니다. 두 규칙 모두 브라우저 주소창의 전체 URL이 아니라 호스트 이름을 매칭합니다.

규칙	매칭되는 호스트 이름	범위
`DOMAIN,api.example.com,DIRECT`	`api.example.com`	하위 도메인은 포함하지 않음
`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com`、`api.example.com`	기본 도메인과 하위 도메인
`DOMAIN-KEYWORD,example,DIRECT`	호스트 이름에 example이 포함된 도메인	범위가 넓어 관련 없는 서비스까지 영향을 받을 수 있음

도메인 규칙에는 프로토콜, 경로, 포트를 입력하지 않습니다

https://api.example.com:8443/v1/status에 접속하더라도 도메인 규칙의 매칭 값은 전체 URL이 아니라 api.example.com입니다. 접미사를 나타내려고 규칙에 *.example.com을 쓰지 마세요. DOMAIN-SUFFIX,example.com,DIRECT를 사용하면 됩니다.

특정 포트만 처리하려면 DST-PORT를 고려할 수 있습니다. 예를 들어 DST-PORT,8443,DIRECT는 도메인과 관계없이 대상 포트가 8443인 요청과 일치합니다. 도메인과 포트를 모두 제한해야 한다면 사용 중인 mihomo 버전의 논리 규칙 문법을 확인하세요. 일반적인 3단 규칙에 두 조건을 임의로 이어 붙여서는 안 됩니다.

도메인을 확인할 수 있어야 규칙이 매칭됩니다

HTTP 프록시나 SOCKS를 통해 도메인으로 요청이 전달되면 코어에서 호스트 이름을 확인할 수 있는 경우가 많습니다. TUN이 연결을 가로채면 대상 IP만 먼저 확인될 수 있으며, 도메인을 복원할 수 있는지는 DNS 모드, 매핑 기록, 스니핑 설정에도 달려 있습니다. 연결 상세 정보에 IP만 표시된다면 새 도메인 규칙이 바로 적용되지 않을 수 있습니다. 먼저 클라이언트가 실제로 인식한 대상 정보를 확인하세요.

IP-CIDR과 no-resolve: 주소 범위 및 DNS 조회 시점

IP-CIDR은 IPv4 주소 범위에, IP-CIDR6은 IPv6 주소 범위에 사용합니다. CIDR에서 슬래시 뒤 숫자는 프리픽스 길이입니다. 192.168.50.0/24는 192.168.50.0부터 192.168.50.255까지 포함하고, 192.168.50.10/32는 IPv4 주소 하나만 매칭합니다. 포트 범위를 뜻하는 표기가 아닙니다.

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

위 IPv6 규칙은 로컬에서 할당되는 ULA 주소에 흔히 쓰이는 fd00::/8을 포함합니다. 특정 네트워크 대역의 예시일 뿐, 완전한 사설망 직접 연결 목록은 아닙니다. 실제 환경의 로컬 네트워크, VPN, 원격 근무용 네트워크 대역에 맞게 조정하세요. 프록시나 전용 터널로 접속해야 하는 주소까지 모두 직접 연결로 처리하지 않도록 주의해야 합니다.

no-resolve의 정확한 의미

요청에 도메인은 있지만 대상 IP를 아직 얻지 못한 경우, IP 규칙은 대상 주소가 네트워크 대역에 포함되는지 판단하기 위해 DNS 조회를 시작할 수 있습니다. no-resolve를 추가하면 해당 규칙은 IP 매칭을 위해 DNS 조회를 직접 시작하지 않습니다. 요청에 대상 IP가 이미 있다면 매칭은 계속 가능합니다.

DNS를 끄거나 연결 전체에서 도메인을 더는 조회하지 않는다는 뜻은 아닙니다.
앞선 규칙에서 이미 조회가 시작됐거나 DNS 매핑 또는 인바운드 연결을 통해 대상 IP가 제공됐을 수 있습니다.
도메인을 DNS 조회한 결과로 IP 대역 규칙에 매칭하려는 경우 이 옵션을 넣으면 뒤에 있는 규칙으로 넘어갈 수 있습니다.

따라서 로컬 네트워크 주소 규칙에는 대역 매칭을 위해 외부 도메인을 추가 조회하는 일을 줄이도록 no-resolve를 함께 쓰는 경우가 많습니다. DNS 조회 결과를 바탕으로 분류하려는 규칙이라면 이 옵션이 정말 필요한지 먼저 확인하세요.

규칙 우선순위: 위에서 아래로 확인하고 처음 일치하는 규칙 적용

Clash는 도메인 길이나 네트워크 대역 크기에 따라 규칙을 자동 정렬하지 않습니다. 일반 규칙은 설정 목록을 위에서 아래로 검사하며, 처음 일치한 규칙의 정책을 적용합니다. 더 구체적인 규칙도 순서가 뒤라면 앞의 포괄적인 규칙에 가려질 수 있습니다.

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - MATCH,DIRECT

이 목록에서는 login.example.com이 첫 번째 규칙에 먼저 매칭되어 직접 연결됩니다. cdn.example.com은 두 번째 규칙에 매칭되어 차단되고, 나머지 요청은 마지막 직접 연결 규칙으로 넘어갑니다. 앞의 두 규칙 순서를 바꾸면 로그인 도메인도 접미사 규칙에 걸려 차단됩니다.

예외, 분류, 최종 규칙 순으로 정리하세요

명확한 예외: 단일 도메인이나 호스트 주소처럼 별도 처리가 필요한 항목은 해당 범위의 규칙보다 앞에 둡니다.
서비스별 분류: 도메인 접미사, 규칙 세트, 지역 또는 네트워크 분류를 원하는 우선순위에 따라 배치합니다.
최종 규칙: 남은 트래픽에 적용할 아웃바운드 정책을 정하고 MATCH를 목록 맨 끝에 둡니다.

구독 설정에 이미 규칙 전체가 들어 있다면 새 규칙을 파일 맨 끝에 무작정 추가하지 마세요. MATCH 뒤에 있는 규칙은 매칭되지 않습니다. 클라이언트에서 「앞에 규칙 추가」, 「규칙 추가」 또는 오버라이드 기능을 제공한다면 편집창에 저장된 줄 수만 볼 것이 아니라 최종 병합 위치를 확인해야 합니다.

RULE-SET: 규칙 내용과 아웃바운드 정책을 분리해 관리

도메인이 많아지면 mihomo의 rule-providers로 규칙 세트를 관리하고 RULE-SET으로 참조할 수 있습니다. 규칙 세트에는 매칭 조건을 저장하고, 기본 설정에서 일치한 뒤 사용할 정책을 지정합니다. 아래 예시는 로컬 파일을 사용하므로 먼저 구성을 검증한 뒤 원격 업데이트 소스를 연결할 수 있습니다.

기본 설정: 제공자를 선언하고 규칙 목록에 추가

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

rules:
  - RULE-SET,local-work,DIRECT
  - MATCH,DIRECT

local-work는 규칙 제공자 이름이며 참조할 때도 똑같이 써야 합니다. 상대 경로의 기준은 코어의 작업 디렉터리이므로 다운로드 폴더와 다를 수 있습니다. FlClash는 모바일 운영체제에서 앱 파일 접근 권한의 영향을 받습니다. 파일을 임의의 폴더에 저장했다고 해서 코어가 읽을 수 있는 것은 아닙니다.

규칙 세트 파일: 매칭 조건만 작성

payload:
  - DOMAIN,portal.example.com
  - DOMAIN-SUFFIX,example.net
  - IP-CIDR,192.168.50.0/24,no-resolve

다음은 behavior: classical 및 format: yaml에 해당하는 파일 내용입니다. 각 항목에 DIRECT나 정책 그룹 이름을 작성하지 않습니다. 아웃바운드 정책은 기본 설정의 RULE-SET,local-work,DIRECT에서 한 번에 지정합니다. 일반 3단 규칙을 그대로 복사해 이 파일에 넣지 마세요.

behavior: domain은 도메인 목록에 사용하며, 위 classical 예시와 파일 형식이 다릅니다.
behavior: ipcidr은 IP 대역 목록에 사용하며, 일반 도메인 규칙을 함께 넣을 수 없습니다.
HTTP 유형의 제공자를 사용하려면 접속 가능한 url을 설정해야 합니다. interval: 86400으로 지정하면 86400초, 즉 24시간마다 업데이트할 수 있습니다.

규칙 세트 업데이트와 구독 업데이트는 별개입니다. 구독 업데이트는 기본 설정을 갱신하고, 규칙 제공자는 해당 규칙 데이터를 갱신합니다. 규칙 세트가 로드되지 않으면 제공자 오류 로그와 파일 형식을 먼저 확인하세요. 형식이 잘못된 규칙 파일은 구독을 반복해서 새로 고쳐도 해결되지 않습니다.

FlClash에서 적용 여부 확인: 유효 설정과 새 연결 점검

사용자 규칙의 적용 여부는 코어가 실제로 불러온 설정과 연결 기록을 기준으로 판단해야 합니다. 클라이언트 버전에 따라 편집 또는 오버라이드 메뉴 이름이 다를 수 있습니다. 먼저 FlClash의 「설정」 페이지에서 현재 선택된 항목을 확인한 다음 해당 항목의 작업 메뉴에서 사용할 수 있는 편집 기능을 살펴보세요. 실제로 제공되는 편집 기능만 사용하고, 구독 업데이트 후에도 변경 내용이 유지되는지는 별도로 확인해야 합니다.

원본 설정 보관: 현재 설정을 내보내거나 복사하고, 기존 아웃바운드 모드와 정책 그룹 선택을 기록해 두세요. 원격 구독을 업데이트하면 직접 수정한 내용이 덮어써질 수 있습니다.
규칙은 한 번에 조금씩 추가: 먼저 정확한 도메인 규칙 하나를 관련된 포괄 규칙과 MATCH보다 앞에 넣으세요. 기존 rules가 있다면 목록에 합치고, 같은 이름의 최상위 키를 중복해서 만들지 마세요.
적용하고 로그 확인: 저장한 뒤 클라이언트가 제공하는 방법으로 설정을 다시 불러오세요. 구문 분석 오류, 알 수 없는 정책 또는 파일 읽기 오류가 발생하면 먼저 해결한 후 접속을 테스트하세요.
새 연결로 테스트: 기존 페이지나 관련 연결을 닫은 뒤 요청을 다시 보내세요. HTTP/2, HTTP/3, 앱 연결 풀은 기존 연결을 재사용할 수 있습니다. 새 규칙을 추가해도 이미 열린 연결의 아웃바운드가 자동으로 다시 선택되지는 않습니다.
연결 상세 정보 확인: 「연결」 페이지에서 대상 호스트, 대상 IP, 매칭된 규칙, 아웃바운드 체인을 확인하세요. 버전에 따라 표시되는 항목이 다를 수 있으므로 로그에서 규칙 유형과 정책 이름도 함께 확인하세요.

TUN은 더 많은 앱 트래픽을 코어로 전달하고, 규칙은 코어에 들어온 요청을 분류합니다. TUN을 켜도 특정 규칙의 우선순위가 자동으로 높아지지는 않습니다. 연결 목록에서 대상 요청을 찾을 수 없다면 규칙을 더 수정하기 전에 트래픽 가로채기, 앱 자체의 프록시 설정, 라우팅을 확인하세요.

자주 발생하는 오류: 증상별 규칙 문제 해결

증상	흔한 원인	해결 방법
저장 후 설정을 불러오지 못함	중국어 쉼표, Tab 들여쓰기, 정의되지 않은 정책 이름	영문 구두점과 공백 들여쓰기를 사용하고, 로그에 표시된 줄을 확인하세요
규칙이 있지만 전혀 매칭되지 않음	MATCH 또는 더 포괄적인 규칙 뒤에 배치됨	구체적인 예외를 관련 규칙보다 앞에 배치하세요
기본 페이지는 직접 연결되지만 리소스는 다른 정책을 사용함	페이지에서 다른 도메인을 호출함	연결 기록에서 이미지, API, 리소스 호스트 이름을 확인하세요
도메인 요청에 IP 규칙이 적용되지 않음	대상 IP를 아직 확인할 수 없고 no-resolve가 설정됨	DNS 조회 상태를 확인하거나 정확한 도메인 규칙을 사용하세요
구독 업데이트 후 사용자 설정이 사라짐	원격 설정이 직접 수정한 내용을 덮어씀	현재 버전에서 지원하는 설정 유지용 오버라이드 기능을 사용하거나 별도 설정을 관리하세요
규칙 세트를 불러오지 못함	behavior 또는 format이 실제 파일 내용과 맞지 않음	payload 구조, 파일 경로, 제공자 로그를 확인하세요

규칙은 매칭됐지만 접속에 실패함

규칙이 매칭됐다는 것은 트래픽 분기 판단이 완료됐다는 뜻일 뿐, 대상 서비스에 접속할 수 있다는 보장은 아닙니다. 직접 연결은 로컬 네트워크와 DNS에 달려 있고, 프록시 정책은 선택한 노드에 달려 있습니다. REJECT는 연결을 차단합니다. 연결 상세 정보에 예상한 정책이 표시된다면 같은 규칙을 계속 추가하지 말고 해당 아웃바운드 경로를 점검하세요.

규칙을 관리할 때는 이 예외가 필요한 이유를 YAML 주석으로 남기고, 더는 유효하지 않은 항목은 주기적으로 삭제하세요. 정확한 도메인과 좁은 네트워크 대역을 사용하고 최종 정책도 명확히 지정하는 것이 좋습니다. 클라이언트 조작 순서는 빠른 시작에서, 규칙·정책 그룹·TUN의 개념은 프로토콜 자세히 알아보기에서 확인하세요.