프로바이더의 구독으로 생성된 설정 파일을 열어본 적이 있다면, 수백 줄에 달하는 rules 목록을 본 적이 있을 것입니다. 이 규칙들 대부분은 프로바이더가 직접 작성한 것이 아니라, 커뮤니티에서 관리하는 공개 규칙 세트(대표적으로 ACL4SSR, blackmatrix7 시리즈가 있습니다)를 참조한 것입니다. 규칙 세트 자체는 원격으로 호스팅되며, 설정 파일에는 "어떤 규칙 세트를 참조하는지"만 선언되어 있습니다.
Rule Provider가 해결하는 문제
Rule Provider가 없다면, 특정 앱이나 사이트의 라우팅을 세밀하게 제어하려면 DOMAIN-SUFFIX / DOMAIN-KEYWORD를 하나씩 직접 작성해야 하고, 도메인이 바뀌거나 새로운 서비스가 등장할 때마다 규칙 목록을 계속 관리해야 합니다. Rule Provider는 이 관리 부담을 규칙 목록을 유지하는 커뮤니티 쪽으로 넘기는 방식으로, 사용자는 참조만 하면 되고 규칙 내용은 원격 파일 쪽에서 자동으로 업데이트됩니다.
세 가지 핵심 필드
| 필드 | 역할 | 자주 쓰는 값 |
|---|---|---|
| type | 규칙 세트를 가져오는 방식 | http(원격 구독, 자동 업데이트), file(로컬 파일) |
| behavior | 규칙 세트에 담긴 데이터 유형으로, 해석 방식을 결정 | domain(순수 도메인 목록), ipcidr(IP 대역 목록), classical(완전한 규칙 문법 라인) |
| interval | type이 http일 때 자동으로 업데이트를 확인하는 주기(초) | 일반적으로 43200(12시간)~86400(24시간) |
완전한 예시
rule-providers: reject: type: http behavior: domain url: https://example.com/reject.txt path: ./ruleset/reject.yaml interval: 86400 direct: type: http behavior: classical url: https://example.com/direct.txt path: ./ruleset/direct.yaml interval: 86400 rules: # 규칙 세트를 참조하는 형식은 RULE-SET,규칙세트이름,정책 으로 고정 - RULE-SET,reject,REJECT - RULE-SET,direct,DIRECT - GEOIP,CN,DIRECT - MATCH,PROXY
path는 로컬 캐시 경로를 지정합니다. 코어가 규칙 세트를 처음 가져오면 로컬에 한 부 저장하고, 이후에는 interval 주기에 따라 업데이트를 확인합니다. 일시적으로 오프라인이더라도 로컬 캐시로 정상 작동하며, 가져오기에 실패했다고 해서 규칙 전체가 무효화되지는 않습니다.
자주 발생하는 함정
- behavior와 실제 내용이 일치하지 않음: 규칙 세트의 내용이 실제로는 완전한 문법 라인(예: DOMAIN-SUFFIX,example.com)인데 behavior를 domain(순수 도메인만 기대)으로 설정하면, 해석에 실패하거나 규칙이 적용되지 않을 수 있습니다. 규칙 세트를 참조하기 전에 원본 파일의 실제 형식을 먼저 확인하는 것이 좋습니다.
- 규칙 순서를 잘못 배치: 규칙은 위에서 아래로 순서대로 매칭됩니다. 범위가 매우 넓은 규칙 세트(거의 모든 사이트에 매칭되는 대형 목록 등)를 맨 앞에 두면, 이후의 더 세밀한 규칙이 영원히 매칭되지 않을 수 있습니다. 일반적으로는 차단 규칙을 가장 먼저, 세밀한 예외 규칙을 그 다음, 범위가 넓은 기본 규칙을 마지막에 두는 것이 좋습니다.
- interval을 너무 짧게 설정: 규칙 세트는 보통 자주 바뀌지 않으므로 몇 분마다 업데이트할 필요가 없습니다. 그렇게 하면 불필요한 네트워크 요청만 늘어납니다. 12~24시간 정도가 적절한 범위입니다.
- 로컬 파일 경로 충돌: 여러 규칙 세트의 path가 같은 파일을 가리키면 서로 덮어쓰게 됩니다. 규칙 세트 이름을 파일명으로 사용하는 등 명명 규칙을 정해두는 것이 좋습니다.
규칙 세트를 직접 관리해야 할까
대부분의 사용자에게는 커뮤니티가 관리하는 공개 규칙 세트를 참조하는 것만으로 충분하며, 굳이 처음부터 다시 만들 필요는 없습니다. 회사 내부 시스템의 도메인 목록이나 자신만 사용하는 특수한 사이트 목록처럼 매우 구체적이고 개인적인 요구가 있을 때만, type: file로 로컬 규칙 세트를 만들어 공개 규칙 세트와 함께 사용하며 각자 다른 부분을 담당하게 하는 것이 가치가 있습니다.
Rule Provider가 해결하는 것은 "관리 비용" 문제이지 "기능" 문제가 아닙니다 — 일반적인 규칙 문법으로 할 수 있는 일은 규칙 세트로도 모두 할 수 있으며, 단지 관리 작업을 외부에 맡기는 것일 뿐입니다.
규칙 세트를 어떻게 조합할까
실제로는 하나의 설정에서 여러 규칙 세트를 동시에 참조하며, 각각 다른 카테고리를 담당하게 하는 경우가 많습니다. 흔한 계층 구성 방식은 먼저 차단 계열(광고, 트래킹)을 두고, 그다음 프록시를 거쳐야 하는 앱 카테고리(예: 지역 제한이 있는 스트리밍이나 소셜 앱)를 두고, 이어서 로컬/직접 연결용 대형 목록을 두고, 마지막으로 MATCH로 기본 처리를 하는 것입니다. 각 계층이 하나의 역할만 담당하면 문제가 생겼을 때 어느 계층의 규칙 세트가 원인인지 더 쉽게 찾을 수 있습니다.
참조한 규칙 세트들 사이에 규칙이 중복될 경우(예: 두 규칙 세트가 같은 도메인을 포함하지만 서로 다른 정책을 지정하는 경우), 실제로 적용되는 것은 항상 먼저 배치되어 먼저 매칭된 쪽입니다. 따라서 규칙 세트를 참조하는 순서 자체도 일종의 우선순위 선언이며, 순서를 조정하는 것이 규칙 세트의 내용을 수정하는 것보다 문제를 더 빠르게 해결할 때도 있습니다.
규칙 세트가 적용되고 있는지 확인하는 방법
규칙 세트를 설정한 후에는 추측으로 작동 여부를 판단할 필요가 없습니다. 앞선 글에서 소개한 대시보드의 "Connections" 화면에서는 각 연결이 실제로 어떤 규칙 이름에 매칭되었는지 보여줍니다. "매칭 없음"이 아니라 특정 규칙 세트의 이름이 표시된다면, 그 규칙 세트가 정상적으로 작동하고 있다는 뜻입니다. 이는 규칙 문제를 진단할 때 가장 직접적이고 시간이 적게 드는 방법으로, 설정을 계속 수정하며 테스트하는 것보다 훨씬 효율적입니다.