기본 정책 그룹 세 가지 되짚어보기

url-test(자동 선택)는 주기적으로 속도를 측정해 항상 현재 지연이 가장 낮은 노드를 사용합니다. select(수동 전환)는 사용자가 직접 노드를 지정합니다. 이 두 가지가 가장 흔히 쓰이는 기본 설정입니다. 노드 수가 늘어나고 사용 시나리오가 복잡해지면 load-balancefallback이라는 두 유형이 더 구체적인 문제를 해결해 줍니다.

load-balance: 트래픽을 여러 노드에 분산

load-balance 그룹은 각기 다른 연결 요청을 그룹 내 여러 노드에 나누어 배정합니다. url-test처럼 항상 「최적」의 노드 하나만 쓰는 것이 아닙니다. 이렇게 하면 특정 노드 하나에 몰리는 대역폭 부담을 나눌 수 있어, 여러 기기가 같은 구독을 동시에 쓰면서 트래픽이 많은 상황에서 특히 유용합니다. strategy 필드로 지정하는 두 가지 분배 전략이 있습니다.

proxy-groups:
  - name: 로드 밸런스
    type: load-balance
    strategy: consistent-hashing
    proxies: [노드A, 노드B, 노드C]
    url: http://www.gstatic.com/generate_204
    interval: 300
  • consistent-hashing — 목적지 주소를 기준으로 일관성 해싱을 수행해, 같은 목적지는 항상 같은 노드로 배정됩니다. 「세션 유지」가 필요한 상황(예: 발신 IP가 자주 바뀌면 이상 인증이 발동하는 일부 사이트)에 적합합니다;
  • round-robin — 요청 순서대로 그룹 내 노드를 차례로 순환합니다. 더 균등하게 분산되지만 같은 목적지 주소가 매번 같은 노드로 가는 것은 보장되지 않습니다.

어느 쪽을 고를지 애매하다면 consistent-hashing을 우선 사용하는 것을 추천합니다. 대부분의 상황에서 더 안정적인 체감을 줍니다.

fallback: 기본 노드가 다운되면 자동으로 대체

fallback 그룹은 설정된 순서대로 노드의 가용성을 차례로 확인해, 정상 상태에서는 항상 목록의 첫 번째 사용 가능한 노드를 사용합니다. 현재 사용 중인 노드의 속도 테스트가 실패하면(사용 불가로 판정) 즉시 다음 사용 가능한 노드로 자동 전환되고, 기본 노드가 복구되면 다시 돌아갑니다. 이는 「지연이 낮은 쪽을 쓴다」는 url-test와는 다르게, fallback은 「기본 노드를 우선 사용하고, 안 될 때만 대안으로 넘어간다」는 원칙을 따릅니다.

proxy-groups:
  - name: 장애 조치
    type: fallback
    proxies: [기본 노드, 백업 노드A, 백업 노드B]
    url: http://www.gstatic.com/generate_204
    interval: 300

조합해서 사용하기

실제 설정에서는 이런 정책 그룹 유형들이 서로 겹쳐서 쓰이는 경우가 많습니다. 예를 들어 먼저 url-test로 같은 지역의 여러 노드 중 지연이 가장 낮은 것을 고르고, 그렇게 만들어진 여러 지역별 url-test 그룹을 다시 select로 묶어 지금 어떤 지역을 쓸지 수동으로 선택할 수 있습니다. 대역폭을 분산해야 하는 상황이라면 노드 일부를 별도로 load-balance로 지정하고, 이를 다른 정책 그룹들과 함께 최종 수동 선택 메뉴에 나란히 넣어 필요할 때마다 전환하면 됩니다.

참고: 어떤 유형이든 urlinterval이 속도 테스트의 목적지 주소와 빈도를 결정합니다. 테스트 주소가 특정 네트워크 환경에서 막혀 있을 수 있으니, 특정 정책 그룹이 계속 노드를 사용 불가로 판정한다면 먼저 테스트 주소 자체에 정상적으로 접속되는지 확인하세요.

tolerance를 놓치지 마세요, 불필요한 전환을 줄여줍니다

url-test와 load-balance 그룹에는 자주 간과되는 파라미터가 하나 더 있습니다. tolerance(지연 허용치, 단위는 밀리초)입니다. 이 값을 설정하지 않으면 클라이언트는 「지연이 가장 낮은 쪽을 쓴다」는 로직을 엄격하게 따르는데, 속도 측정 결과에는 원래 자연스러운 편차가 있어서 몇 밀리초 정도의 흔들림은 흔히 발생합니다. 허용치 없이 이 로직만 따르면 지연이 비슷한 후보들 사이에서 노드가 빈번하게 오가며 전환되고, 오히려 사용 경험이 나빠질 수 있습니다(특히 진행 중인 다운로드나 영상 재생은 전환되는 순간 짧게 끊기기도 합니다).

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies: [노드A, 노드B, 노드C]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

tolerance: 50을 설정하면, 새 노드의 지연이 현재 노드보다 최소 50밀리초 이상 낮아야만 실제로 전환이 일어납니다. 그렇지 않으면 순간적으로 측정된 지연이 조금 더 높더라도 현재 노드를 계속 사용합니다. 이 값을 크게 잡을 필요는 없고, 보통 50~100밀리초 정도면 의미 없는 흔들림으로 인한 전환을 대부분 걸러낼 수 있습니다.

어떤 것을 써야 할지는 실제 문제에 따라 다릅니다

처음 던진 질문으로 돌아가 보면, 지연에 따른 전환이 너무 빈번한 것뿐이라면 tolerance를 추가하는 것으로 충분하고, 굳이 더 복잡한 정책 그룹 유형으로 바꾸지 않아도 됩니다. 여러 기기의 트래픽을 서로 다른 노드로 분산해 단일 노드의 부담을 낮추고 싶다면 그때 load-balance가 필요합니다. 「기본 노드가 다운돼도 자동으로 대체될 수 있는지」가 관심사라면 답은 fallback입니다. 세 가지 질문과 세 가지 해법이 있으니, 한꺼번에 다 적용할 필요 없이 실제로 마주한 상황에 맞춰 설정하면 됩니다. 정책 그룹 파라미터를 더 알고 싶다면 고급 문서를 참고하세요.

정책 그룹 설정을 마쳤다면 이제 사용할 차례입니다

Clash 클라이언트를 다운로드하고 구독을 불러오면 이 정책 그룹 설정을 바로 적용할 수 있습니다.