rules에 수백 줄의 DOMAIN-SUFFIX를 직접 작성했다면, 거의 확실히 비효율적인 방법을 쓰고 있는 것입니다. 규칙 세트(rule-providers)는 이런 흔한 카테고리를 별도의 파일로 묶어 통합 관리하고 정기적으로 업데이트할 수 있게 해주어, 메인 설정 파일을 깔끔하게 유지할 수 있습니다.
rule-providers란
간단히 말해, 다른 곳(로컬 파일 또는 원격 URL)에 있는 규칙 목록을 Clash가 일정 주기로 가져와 로드하는 것입니다. rules에서 RULE-SET 한 줄로 참조하기만 하면 되고, 수백 개의 규칙을 메인 설정에 쌓아둘 필요가 없습니다.
behavior 필드: 3가지 규칙 세트 형식
| behavior | 내용 형식 | 주요 용도 |
|---|---|---|
| domain | 도메인 / 도메인 접미사 목록 | 광고 차단, 스트리밍 분기, 소셜 플랫폼 도메인 세트 |
| ipcidr | IP 범위 목록 | 로컬 IP 범위, 특정 데이터센터 IP 직접 연결 |
| classical | 완전한 규칙 문법(타입 접두사 포함) | 여러 타입 혼합, 매칭 방식을 정밀하게 제어해야 하는 경우 |
behavior는 규칙 세트 파일의 실제 내용 형식과 반드시 일치해야 합니다. 일치하지 않으면 규칙 세트 로드가 실패하거나 매칭이 이상해질 수 있으니, 반드시 규칙 세트 제공처가 명시한 설명에 따라 설정하세요.
type: http인가 file인가
- http: 원격 URL에서 정기적으로 가져옵니다. 커뮤니티가 계속 유지 관리하는 규칙 세트를 따라가는 데 적합합니다.
- file: 로컬 파일만 읽으며 자동 업데이트되지 않습니다. 직접 관리하는 규칙에 적합합니다.
자주 쓰는 규칙 세트 출처
커뮤니티에는 장기간 유지 관리되는 오픈소스 규칙 세트 프로젝트가 많이 있으며, 광고 차단, 직접 연결, 스트리밍 분기, 소셜 플랫폼 분기 등의 카테고리를 다룹니다. 필요에 따라 몇 개를 골라 조합해 사용하면 처음부터 직접 작성할 필요가 없습니다.
흔한 규칙 세트 카테고리를 어떻게 조합할까
어떤 규칙 세트를 도입해야 할지 모르겠다면, "우선순위가 높은 것부터 낮은 것" 순으로 구성해보세요. 먼저 광고/추적 차단을 처리하고(불필요한 연결 방지), 다음으로 반드시 직접 연결해야 하는 로컬/내부 주소, 그다음 특별한 분기가 필요한 스트리밍과 소셜 플랫폼, 마지막으로 로컬 IP 범위 직접 연결 규칙으로 마무리합니다. 나머지 매칭되지 않은 트래픽은 기본적으로 프록시로 흐릅니다. 이 순서의 핵심 논리는, 영향 범위가 좁고 판단 기준이 명확한 규칙을 앞에 두고 모호한 예비 규칙을 뒤에 두어, 범위가 넓은 규칙이 원래 정밀하게 매칭되어야 할 트래픽을 먼저 가로채는 것을 막는 것입니다.
나만의 개인 규칙 세트 유지하기
회사 내부 서비스나 개인적으로 자주 쓰지만 소규모인 사이트는 커뮤니티 규칙 세트가 다루지 않을 가능성이 큽니다. 이런 경우에는 type: file이 적합합니다. 원격 규칙 세트와 형식은 완전히 동일하지만 네트워크에서 자동 업데이트되지 않는 로컬 관리 파일을 만들어 직접 편집하며 유지합니다.
회사 VPN이나 내부 관리 페이지 같은 도메인을 이 개인 규칙 세트에 넣으면, 메인 설정을 깔끔하게 유지하면서도 공용 규칙 세트 업데이트로 덮어써질 걱정도 없습니다.
자동 업데이트 설정 방법
interval 필드는 업데이트 빈도를 초 단위로 제어합니다. 광고 차단이나 스트리밍 분기처럼 자주 바뀌는 규칙 세트에는 짧은 간격(하루 정도)을, 비교적 안정적인 규칙 세트에는 긴 간격(일주일 정도)을 설정하는 것이 일반적입니다.
규칙 세트도 매칭 순서에 주의해야 한다
일반 규칙과 마찬가지로 RULE-SET 참조도 "위에서 아래로, 처음 매칭되면 중단" 원칙을 따릅니다. 범위가 넓은 규칙 세트를 앞에 두면 뒤에 있는 더 정밀한 규칙이 영원히 매칭되지 않을 수 있으니, 문제 해결 시 규칙 순서를 먼저 확인하세요.
규칙 세트 로드 실패 시 문제 해결 방법
규칙 세트 설정 오류는 보통 몇 가지 전형적인 증상으로 나타납니다: 코어 시작 오류, 패널/로그의 "규칙 세트 다운로드 실패" 메시지, 또는 규칙이 로드된 것처럼 보이지만 전혀 적용되지 않는 경우입니다. 다음 순서로 하나씩 확인해보세요.
- URL에 접근 가능한지 확인:
url필드의 주소를 브라우저에서 직접 열어, 404나 추가 인증 없이 텍스트 콘텐츠가 정상적으로 다운로드되는지 확인합니다. - behavior가 파일 형식과 일치하는지 확인: 로컬에 다운로드된 규칙 파일을 열어 내용 형식을 확인하고, 설정한
behavior(domain/ipcidr/classical)와 일치하는지 확인합니다. - path가 가리키는 디렉터리에 쓰기 권한이 있는지 확인: 코어는 원격 콘텐츠를
path가 지정한 로컬 경로에 캐시해야 하는데, 디렉터리에 쓰기 권한이 없으면 업데이트가 실패합니다. - 규칙 참조 이름의 표기가 일치하는지 확인:
rule-providers에 정의된 이름은rules의RULE-SET,이름,...과 완전히 일치해야 합니다. 대소문자나 철자가 다르면 규칙이 조용히 무시됩니다.
규칙 세트 캐시를 수동으로 정리해야 할까
일반적으로 필요하지 않습니다. 코어는 interval을 기준으로 캐시 만료 여부를 자동으로 판단하고 다시 가져오므로 수동 개입이 필요 없습니다. 다만 로컬에 캐시된 규칙 파일이 손상되었다고 의심되는 경우(이전 다운로드가 중단된 경우 등)나 제공처가 내용 형식을 변경해 파싱 오류가 발생한 경우에는, path가 가리키는 로컬 파일을 수동으로 삭제하면 코어 재시작 시 완전히 새로 다운로드되어 캐시를 강제로 새로고침하는 효과를 얻을 수 있습니다.
규칙 세트가 시작 속도를 느리게 하지 않을까
규칙 세트를 도입하면 코어는 매번 시작할 때(또는 캐시가 만료되어 업데이트가 필요할 때) 이 파일들을 다운로드하고 파싱하는 데 추가 시간이 필요합니다. 규칙 세트가 많거나 개별 파일이 클수록 시작 시간도 그만큼 늘어납니다. 대부분의 가정용 환경에서는 이 정도 지연이 거의 느껴지지 않지만, 리소스가 제한된 기기(저성능 라우터 등)에서 코어를 실행하면서 많은 규칙 세트를 도입한다면, interval을 적절히 늘려 불필요하게 자주 재다운로드하는 것을 줄이고, 업데이트 빈도를 실제로 필요한 범위로 제한하는 것을 고려해보세요.
정리
직접 작성한 규칙과 비교했을 때 규칙 세트의 가장 큰 가치는 "분리"와 "자동 업데이트"입니다. 메인 설정에는 소량의 사용자 정의 규칙과 프록시 그룹 구조만 남기고, 번거로운 도메인/IP 분류 작업은 외부 규칙 세트가 관리하도록 맡김으로써 반복 작업을 크게 줄이고 장기적인 유지 관리도 훨씬 쉬워집니다.