Clash rule-providers란: 규칙 목록과 라우팅 정책 분리하기

rule-providers는 도메인이나 IP 규칙을 별도 파일로 관리하고, Clash 설정에서는 그 목록을 불러와 정책 그룹에 연결하는 기능입니다. 설정 파일 안에 DOMAIN-SUFFIX 항목을 수백 줄씩 직접 쌓는 대신 규칙 목록은 GitHub 저장소에 두고, 메인 프로필에는 제공자 이름과 업데이트 방식만 선언할 수 있습니다. 앱이나 기기가 여러 대여도 동일한 목록을 재사용하기 쉽고, 규칙 변경 기록을 Git 커밋으로 추적할 수 있다는 점이 장점입니다.

다만 rule-provider가 트래픽을 스스로 프록시로 보내는 것은 아닙니다. 제공자는 “어떤 요청이 규칙에 해당하는가”를 판단할 목록을 제공하고, 메인 설정의 RULE-SET 규칙이 일치한 요청을 Proxy나 특정 정책 그룹으로 전달합니다. 따라서 제공자 이름, 규칙 유형, 파일 내용, 규칙의 위치가 모두 맞아야 원하는 결과가 나옵니다. 특히 Clash 계열 클라이언트마다 내장 코어와 지원 필드가 다를 수 있으므로, 설정을 적용하기 전에 현재 사용하는 코어가 rule-provider 형식을 지원하는지 확인하세요.

ℹ 먼저 기억할 점: 제공자 파일은 규칙 목록이고, RULE-SET의 마지막 항목은 적용할 정책입니다. 제공자가 정상적으로 내려받아져도 해당 규칙이 rules:에 없거나 위쪽의 다른 규칙에 먼저 걸리면 기대한 정책으로 연결되지 않습니다.

GitHub에서 규칙 파일을 호스팅하고 YAML에 연결하기

저장소에는 메인 설정 전체를 올리기보다 재사용할 규칙 목록만 별도 파일로 두는 편이 관리하기 좋습니다. 예를 들어 저장소 안에 rules/my-sites.yaml을 만들고 아래처럼 도메인 규칙을 적을 수 있습니다. 이 파일은 원격 제공자가 읽을 데이터이므로, 제공자 선언이나 rules: 목록을 섞지 말고 규칙 항목만 담습니다. 

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,api.example.net
  - DOMAIN-KEYWORD,example-service

저장소에 파일을 커밋한 다음 브라우저에서 해당 파일의 원본(raw) 보기 주소가 열리는지 확인합니다. 일반 GitHub 파일 페이지 주소와 원본 파일 주소는 서로 다릅니다. Clash 설정의 url에는 브라우저용 저장소 페이지가 아니라 원본 콘텐츠를 반환하는 HTTPS 주소를 넣어야 합니다. 저장소나 브랜치 이름을 바꾸면 주소도 달라지므로, 처음에는 고정된 브랜치를 사용하고 URL을 실제로 열어 YAML 본문이 표시되는지 점검하세요. 

rule-providers:
  MY-SITES:
    type: http
    behavior: domain
    format: yaml
    url: https://raw.githubusercontent.com/OWNER/REPO/main/rules/my-sites.yaml
    path: ./rule-providers/my-sites.yaml
    interval: 86400

rules:
  - RULE-SET,MY-SITES,Proxy
  - MATCH,DIRECT

위 예시에서 MY-SITES는 메인 설정 안에서 제공자를 참조하는 이름이며, 저장소 파일 경로나 정책 그룹 이름과 같을 필요는 없습니다. behavior: domain은 도메인 형식의 항목을 다룬다는 뜻이고, IP 대역을 제공한다면 알맞은 behavior와 파일 내용을 함께 선택해야 합니다. 여러 종류의 규칙 문법을 한 파일에 무작정 넣지 말고, 코어가 요구하는 형식에 맞춰 구분하세요. format: yaml과 path의 지원 여부 및 해석 방식도 실행 중인 Mihomo·Clash 코어 버전에 따라 확인하는 것이 안전합니다.

interval: 86400은 제공자 업데이트 간격을 초 단위로 지정한 예시입니다. 매분 갱신한다고 최신성이 크게 좋아지는 것은 아니며, 요청이 잦으면 GitHub나 중간 네트워크의 제한에 걸리거나 불필요한 다운로드가 늘 수 있습니다. 규칙을 자주 바꾸지 않는다면 하루 간격처럼 운영 목적에 맞는 값을 선택하세요. path는 내려받은 파일을 로컬에 보관할 위치이므로, 클라이언트가 사용하는 구성 경로에서 쓰기 가능한지 확인해야 합니다. 구독 프로필을 새로고침할 때 로컬 수정이 덮어써지는 클라이언트라면 제공자 선언을 어느 파일에 둘지도 먼저 점검하세요.

규칙 유형과 매칭 순서에 맞춰 제공자 설계하기

제공자 하나에 모든 규칙을 몰아넣기보다 변경 이유와 적용 정책에 따라 나누면 추적이 쉬워집니다. 예를 들어 자주 바뀌는 서비스 도메인, 사내에서 유지하는 예외 목록, IP 대역 목록을 별도 제공자로 관리할 수 있습니다. 이렇게 나누면 어느 저장소 변경이 특정 서비스의 라우팅을 바꿨는지 확인하기 쉽습니다. 반대로 규칙이 몇 개뿐이고 거의 바뀌지 않는다면 메인 설정에 직접 두는 편이 단순할 수 있으므로, 분리 자체를 목표로 삼을 필요는 없습니다.

매칭 순서는 제공자 설계만큼 중요합니다. Clash는 일반적으로 위에서부터 규칙을 확인해 먼저 일치한 규칙의 정책을 적용합니다. 특정 도메인을 직접 지정한 규칙보다 넓은 범위의 규칙 집합이 위에 있으면, 뒤쪽에 적은 예외 규칙까지 도달하지 못할 수 있습니다. 예외를 먼저 두고 범위가 넓은 규칙 집합을 뒤에 배치한 다음, 마지막에 최종 일치 규칙을 두는 구조가 읽기 쉽습니다. 다만 같은 요청이 어떤 규칙에 해당할지는 제공자 내용과 다른 규칙의 범위에 따라 달라지므로 연결 로그에서 실제 일치 항목을 확인하세요.

behavior: domain은 도메인 중심 목록을 구성할 때 적합하고, IP 대역을 관리할 때는 CIDR 규칙과 해당 코어가 지원하는 유형을 함께 검토해야 합니다. 여러 종류를 포함하는 일반 규칙 목록은 코어가 지원하는 형식에 맞춰 관리하며, 항목 형식을 혼동하지 않도록 저장소의 파일명과 설명에도 목적을 기록하세요. DOMAIN-SUFFIX,example.com은 하위 도메인을 포함하는 범위로 매칭될 수 있지만, DOMAIN,api.example.com은 지정한 도메인 자체를 대상으로 합니다. 차이를 고려하지 않으면 지나치게 넓은 규칙이 원치 않는 요청까지 같은 정책으로 보낼 수 있습니다.

GitHub에 공개 저장소를 쓰면 누구나 규칙 파일을 읽을 수 있으므로 개인 설정, 구독 주소, 인증 토큰, 내부 전용 도메인 목록은 올리지 마세요. 비공개 저장소를 사용하더라도 인증 정보를 메인 YAML에 평문으로 넣어 공유하거나 동기화하지 않는 것이 중요합니다. 원격 규칙 파일은 실수나 저장소 변경으로 내용이 달라질 수 있으니, 변경 전후의 커밋을 검토하고 파일을 수정할 수 있는 계정을 제한하세요. 운영 환경에서는 “누가 바꿨는지”, “어떤 변경이 적용됐는지”를 Git 기록으로 확인할 수 있도록 커밋 메시지를 구체적으로 남기는 편이 유용합니다.

규칙이 로드되지 않거나 정책이 적용되지 않을 때

문제가 생겼을 때는 먼저 메인 설정의 파싱 오류와 원격 파일 다운로드 오류를 구분합니다. 설정을 저장했는데 코어가 시작되지 않는다면 들여쓰기, 콜론, 따옴표 같은 YAML 문법과 제공자 선언의 필수 항목부터 살펴보세요. 코어 로그에 제공자 업데이트 실패가 표시되면 원본 URL이 유효한지, 파일이 공개되어 있는지, GitHub 응답이 로그인 페이지나 404 화면으로 바뀌지 않았는지 확인합니다. 파일이 열리더라도 본문이 오류 페이지나 HTML이라면 정상적인 규칙 목록으로 읽히지 않습니다.

다운로드는 성공했는데 라우팅이 달라지지 않는다면 이름을 세 군데 대조하세요. rule-providers 아래의 제공자 이름, RULE-SET에서 참조하는 이름, 실제 규칙 파일의 내용이 서로 의도대로 연결되어야 합니다. 이어서 rules:에 해당 RULE-SET 항목이 있는지, 더 넓은 규칙이 위에서 먼저 일치하지 않는지 확인합니다. 앱이 편집한 파일이 아닌 다른 프로필을 활성화한 경우도 흔하므로, 수정한 프로필과 현재 실행 중인 프로필이 같은지 반드시 확인하세요.

연결 로그에서는 테스트할 도메인의 요청을 찾아 최종 정책과 매칭 규칙을 확인합니다. 예상한 제공자 규칙 대신 다른 규칙이 표시되면 순서나 범위를 조정하고, 요청 자체가 나타나지 않으면 시스템 프록시·TUN·앱의 프록시 설정처럼 트래픽이 Clash 코어를 통과하는 경로부터 점검합니다. 제공자 갱신 직후에도 이전 동작이 남는다면 업데이트 시각과 로컬 저장 경로를 확인한 뒤 클라이언트가 제공자를 다시 읽었는지 살펴보세요. 코어 버전이 오래되어 선언 필드를 지원하지 않는 경우에는 규칙 내용만 반복해서 바꾸기보다 코어의 호환성을 먼저 확인해야 합니다.

일부 GUI는 원격 프로필을 편집하거나 갱신할 때 로컬 YAML 변경을 덮어쓸 수 있고, 간단한 규칙 편집 기능은 제공자 파일과 Git 변경 기록을 함께 관리하기 어렵습니다. Clash V.CORE에서는 Mihomo 계열 설정을 활용해 규칙 제공자를 한곳에 정리하고, 로그와 정책 그룹을 함께 확인하며 문제를 좁힐 수 있습니다. 프로필 관리와 원격 규칙을 꾸준히 다룰 계획이라면 현재 사용하는 코어의 지원 범위를 확인한 뒤 Clash V.CORE 다운로드 페이지에서 필요한 버전을 살펴보세요.