Rule Provider 실전: 규칙 세트를 자동 업데이트해 수동 관리 벗어나기

Rule Provider를 써야 하는 이유

수백 줄의 DOMAIN-SUFFIX를 rules 목록에 그대로 나열해도 동작은 합니다. 다만 유지 관리 비용이 상당히 큽니다. 규칙 세트 작성자가 내용을 업데이트하면 매번 손으로 동기화해야 하고, 규칙이 늘어날수록 설정 파일도 읽기 어려워집니다. Rule Provider는 이 부분을 별도의 원격 파일로 분리해, 클라이언트가 정해진 주기마다 자동으로 다시 가져오게 합니다. 규칙 세트 자체의 관리는 완전히 상류(업스트림)에 맡기고, 여러분은 rules에서 그 이름을 참조하기만 하면 됩니다.

세 가지 behavior, 잘못 고르면 안 됩니다

Rule Provider를 정의할 때 가장 실수하기 쉬운 부분이 behavior 필드입니다. 이 값은 클라이언트에게 규칙 세트의 내용을 어떻게 해석해야 하는지 알려줍니다.

• domain — 규칙 세트 내용이 순수한 도메인 목록인 경우(한 줄에 도메인 하나씩, DOMAIN-SUFFIX와 같은 의미);
• ipcidr — 규칙 세트 내용이 IP 대역 목록인 경우(한 줄에 CIDR 하나씩, IP-CIDR과 같은 의미);
• classical — 규칙 세트 내용이 완전한 규칙인 경우(한 줄마다 규칙 유형이 포함되어 있어 rules에 직접 적는 형식과 동일합니다. 가장 유연하지만 파일 용량도 가장 큽니다).

전체 설정 예시

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.txt
    interval: 86400

  local-ip:
    type: http
    behavior: ipcidr
    url: "https://example.com/rules/local-ip.txt"
    path: ./rules/local-ip.txt
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,local-ip,DIRECT
  - MATCH,PROXY

path는 규칙 세트를 로컬에 캐시하는 경로입니다. 처음 가져올 때 이 파일에 기록되고, 이후 interval(단위: 초)마다 자동으로 다시 내려받아 덮어씁니다. 잠깐 네트워크가 끊기더라도 클라이언트는 로컬에 캐시된 이전 버전으로 계속 동작할 수 있어, 한 번의 업데이트 실패로 규칙 전체를 잃는 일은 없습니다.

규칙 세트가 여러 개일 때 순서는 어떻게

규칙은 여전히 위에서 아래로 순서대로 매칭하고, 걸리면 즉시 멈춥니다. Rule Provider로 바꾼다고 해서 이 원칙이 바뀌지는 않습니다. 실무에서는 다음 순서가 비교적 안정적입니다.

• 먼저 광고·악성 도메인 차단용 규칙 세트(예: reject)를 배치해, 불필요한 요청을 최대한 빨리 걸러냅니다;
• 그다음 명확히 프록시를 태워야 하는 규칙 세트(예: 자주 쓰는 해외 서비스 도메인 목록)를 배치합니다;
• 이어서 국내·지역 내 직접 연결 규칙 세트(도메인과 IP 대역)를 배치합니다;
• 마지막으로 MATCH로 나머지를 처리하며, 보통 프록시로 보내 어떤 규칙에도 걸리지 않은 새로운 서비스가 곧바로 실패하는 상황을 막습니다.

업데이트 주기는 어떻게 정할까

규칙 세트는 노드 속도 측정처럼 자주 새로 고칠 필요가 없습니다. 대부분의 경우 interval을 12~24시간(43200~86400초) 사이로 설정하면 충분합니다. 너무 자주 갱신하면 규칙 세트 서버에 부담만 늘어날 뿐 실질적인 이득은 거의 없습니다. 직접 관리하는 개인 규칙 세트이고 변경 빈도가 낮다면 2~3일까지 늘려도 문제없습니다.

자주 발생하는 문제 점검하기

Rule Provider를 연동한 뒤 「설정은 했는데 적용이 안 되는」 것처럼 보인다면 다음 방향으로 하나씩 점검해 보세요.

• 규칙 세트 가져오기 실패 — url을 브라우저로 직접 열 수 있는지 확인하세요. 일부 규칙 세트는 특정 플랫폼에 호스팅되어 있어 특정 네트워크 환경에서는 오히려 프록시를 타야만 접근할 수 있는, 닭이 먼저냐 달이 먼저냐 같은 상황이 생기기도 합니다. 이런 경우 더 가까운 미러 서버 주소로 바꾸는 것을 권장합니다;
• behavior와 내용 불일치 — 앞서 언급했듯 가장 흔한 실패 원인입니다. classical 형식의 파일을 domain으로 선언하면 클라이언트가 순수 도메인 형식으로 해석하려 하고, 앞에 붙은 규칙 유형 접두사까지 도메인의 일부로 취급되어 규칙 세트 전체가 무력화됩니다;
• 로컬 캐시가 오래됨 — 지금 쓰고 있는 것이 오래전에 캐시된 버전이라 의심되면 path가 가리키는 로컬 파일을 직접 삭제하세요. 클라이언트가 다음번 시작할 때 완전히 새로 가져옵니다;
• 새 규칙 세트가 순서를 흐트러뜨림 — 규칙 세트를 새로 추가했다면 삽입 위치가 「정밀한 규칙은 앞, 마지막 처리 규칙은 뒤」라는 원칙에 맞는지 확인하세요. 위치를 잘못 넣으면 그 뒤에 있던 기존 규칙이 더 이상 매칭되지 않을 수 있습니다.

「규칙이 적용되지 않는」 문제는 대부분 이 네 가지 원인 중 하나로 귀결됩니다. 순서대로 점검하면 대체로 금방 원인을 찾을 수 있습니다. 규칙 문법의 전체 종류를 체계적으로 알고 싶다면 고급 문서의 전체 참조표를 확인해 보세요.