rule-providers로 사용자 규칙 분리하기
사용자 규칙을 기본 Clash 설정의 rules에 모두 적으면 규칙 목록이 길어지고, 수정할 때마다 전체 설정을 편집해야 합니다. rule-providers를 사용하면 규칙 데이터를 별도 파일로 분리한 뒤 기본 설정에서 제공자 이름으로 참조할 수 있습니다. 규칙 목록을 GitHub 저장소에서 관리하면 변경 이력을 확인하고 이전 버전과 비교하기도 쉽습니다.
규칙 제공자는 프록시 노드를 내려받는 proxy-providers와 다릅니다. 규칙 제공자는 도메인, IP 대역 또는 클래식 규칙을 제공하며, 이를 어느 정책 그룹으로 보낼지는 기본 설정의 rules 항목에서 정합니다. 따라서 저장소에는 규칙 파일을, Clash 설정에는 제공자 정의와 적용 순서를 둡니다.
GitHub에 규칙 파일 올리기
저장소에 규칙 파일을 만들고, 파일 내용이 선택한 behavior와 일치하도록 작성합니다. 공개 저장소라면 브라우저에서 파일을 열 때 표시되는 주소가 아니라 원시 파일을 반환하는 raw 주소를 설정에 사용해야 합니다. 아래 예시의 OWNER와 REPO는 실제 GitHub 계정과 저장소 이름으로 바꾸세요.
domain 동작은 도메인 목록, ipcidr 동작은 IP 대역 목록, classical 동작은 DOMAIN-SUFFIX나 IP-CIDR처럼 Clash 규칙 문법으로 작성한 목록을 사용합니다. 아래는 도메인 목록의 예입니다.
payload:
- '+.ads.example'
- '+.tracker.example'
- '+.metrics.example'파일 형식과 동작 유형을 혼동하지 마세요. behavior: domain인 제공자에 DOMAIN-SUFFIX,ads.example 같은 클래식 규칙 줄을 넣으면 기대한 방식으로 처리되지 않을 수 있습니다. 반대로 classical을 선택했다면 각 항목이 해당 코어에서 인식되는 규칙 형식인지 점검해야 합니다. 도메인 패턴의 세부 문법도 사용 중인 코어 문서와 맞춰 확인하세요.
GitHub 저장소의 파일 경로를 정할 때는 이름과 디렉터리를 단순하게 유지하는 편이 좋습니다. 예를 들어 rules/ads.yaml로 관리하면 원시 파일 주소는 다음 형태가 됩니다.
https://raw.githubusercontent.com/OWNER/REPO/main/rules/ads.yaml기본 브랜치 이름이 main이 아니거나 규칙 파일을 다른 경로에 두었다면 주소도 실제 저장소에 맞춰 바꾸세요. URL에 공백이나 잘못된 대소문자가 들어가면 다운로드 실패가 발생할 수 있습니다. 공개 저장소 주소와 파일 경로를 브라우저에서 열어 YAML 내용이 반환되는지도 확인합니다. GitHub의 파일 설명 페이지나 저장소 첫 화면 주소를 그대로 넣으면 규칙 데이터 대신 HTML 페이지가 내려올 수 있습니다.
Clash 설정 연결과 갱신 주기
다음 예시는 공개 GitHub raw 파일을 HTTP 방식으로 가져와 로컬에 캐시하고, 하루 간격으로 갱신하는 구성입니다. interval의 단위는 초이므로 86400은 24시간입니다. path는 코어가 규칙 파일을 저장할 위치이며, 실행 환경에서 해당 디렉터리에 쓸 수 있어야 합니다.
rule-providers:
ad-domains:
type: http
behavior: domain
url: "https://raw.githubusercontent.com/OWNER/REPO/main/rules/ads.yaml"
path: ./rules/ads.yaml
interval: 86400
rules:
- RULE-SET,ad-domains,REJECT
- MATCH,Proxy예시의 Proxy는 실제 설정에 정의되어 있는 정책 그룹 이름으로 바꿔야 합니다. 해당 그룹이 없으면 규칙을 적용할 때 오류가 나거나 설정 로드가 실패할 수 있습니다. 광고 차단 대신 직접 연결을 원한다면 정책을 DIRECT로 지정할 수 있지만, 차단 의도와 맞는지 먼저 검토하세요. 제공자 이름 ad-domains는 RULE-SET 참조 이름과 철자까지 같아야 합니다.
규칙은 위에서 아래로 평가되며, 먼저 일치한 항목이 적용됩니다. 따라서 예외 도메인을 특정 정책으로 보내려면 광범위한 규칙 세트보다 앞에 둘 수 있습니다. 반대로 넓은 규칙을 먼저 배치하면 뒤에 있는 예외 규칙이 실행되지 않을 수 있습니다. MATCH는 나머지 트래픽을 처리하므로 보통 규칙 목록의 마지막에 둡니다.
| 항목 | 역할 | 확인할 점 |
|---|---|---|
type | 규칙 파일을 가져오는 방식 | 원격 주소를 가져오는 구성은 http를 사용합니다. |
behavior | 규칙 데이터의 종류를 지정 | domain, ipcidr, classical 중 파일 내용에 맞춥니다. |
url | 원격 규칙 파일 주소 | GitHub 저장소 페이지가 아니라 raw 파일 주소인지 확인합니다. |
path | 로컬 캐시 파일 경로 | 코어의 실행 환경에서 쓰기 가능한 위치인지 확인합니다. |
interval | 원격 파일을 확인하는 간격 | 초 단위로 지정하며, 지나치게 짧은 주기는 불필요한 요청을 늘립니다. |
RULE-SET | 제공자 규칙을 실제 규칙 목록에 연결 | 제공자 이름과 적용할 정책 그룹이 모두 정확해야 합니다. |
갱신 간격은 규칙 변경 빈도와 원격 호스팅의 안정성을 고려해 정하세요. 규칙을 하루에 여러 번 수정하지 않는다면 몇 분 단위로 자주 요청할 필요가 없습니다. 간격이 짧다고 새 변경이 즉시 반영되는 것도 아닙니다. 사용 중인 코어의 갱신 동작, 클라이언트의 설정 다시 불러오기, 다운로드 성공 여부를 함께 확인해야 합니다.
변경 이력 관리와 오류 점검
GitHub를 사용하면 규칙 변경 시점과 변경 내용을 커밋 단위로 남길 수 있습니다. 한 번에 많은 항목을 바꾸기보다 목적별로 나누어 커밋하고, 삭제한 규칙과 추가한 규칙의 이유를 간단히 기록하세요. 문제가 생겼을 때 이전 커밋과 비교하면 어떤 변경이 영향을 주었는지 좁히기 쉽습니다. 운영 중인 규칙 파일을 바로 수정하기보다 테스트용 파일이나 브랜치에서 먼저 확인하는 방법도 유용합니다.
- 파일 주소 확인: raw URL을 브라우저에서 열어 규칙 YAML 또는 텍스트가 표시되는지 확인합니다. 로그인 화면, 404 페이지, 저장소 설명 HTML이 반환되면 주소나 접근 권한을 점검합니다.
- 파일 구조 확인: YAML 들여쓰기가 올바른지,
payload가 목록으로 작성되었는지, 각 항목이 선택한behavior와 맞는지 살펴봅니다. - 로컬 경로 확인:
path의 디렉터리가 존재하는지와 실행 중인 코어가 해당 위치에 파일을 쓸 수 있는지 확인합니다. 클라이언트마다 작업 디렉터리가 다를 수 있으므로 상대 경로가 가리키는 위치를 단정하지 마세요. - 이름과 정책 확인:
RULE-SET의 제공자 이름, 정책 그룹 이름, 대소문자와 철자가 정의 부분과 일치하는지 비교합니다. - 갱신 로그 확인: 연결 로그나 코어 로그에서 요청 실패, 상태 코드, YAML 파싱 오류를 찾습니다. 로그를 공유할 때는 내부 호스트 이름과 민감한 경로를 가리세요.
- 적용 순서 확인: 테스트 대상 도메인이 앞선 규칙에 이미 매칭되지 않는지 점검합니다. 정책 그룹을 바꿔도 해당 규칙까지 도달하지 않으면 결과는 달라지지 않습니다.
GitHub raw 파일을 정상적으로 열 수 있어도 Clash가 규칙을 가져오지 못할 수 있습니다. 코어가 실행되는 네트워크에서 GitHub에 접근할 수 있는지, 프록시 환경이 원격 규칙 요청에도 적용되는지, TLS 연결이 차단되지 않는지 확인하세요. 또한 HTTP 상태 코드가 성공이어도 응답 본문이 올바른 규칙 형식이라는 보장은 없습니다. 로그의 다운로드 결과와 파싱 결과를 구분해서 살펴보세요.
장애가 발생하면 먼저 변경을 멈추고, 정상 작동했던 커밋과 현재 파일을 비교합니다. 제공자 정의를 잠시 비활성화하거나 이전 규칙 파일로 되돌려 원인이 원격 호스팅인지, 파일 문법인지, 규칙 우선순위인지 분리해 확인할 수 있습니다. 규칙 제공자만 되돌릴 때도 전체 설정의 다른 변경을 함께 취소하지 않도록 차이를 검토하세요. 이 방식으로 관리하면 구독에서 내려받은 기본 설정을 직접 훼손하지 않고 사용자 규칙을 독립적으로 추적하고 복구할 수 있습니다.