로드 밸런싱과 페일오버 실전 활용

노드가 많아도 스케줄링을 못 하면 의미가 없습니다. 피크 시간대마다 손으로 노드를 바꾸거나, 밤새 다운로드를 돌리다가 노드가 죽어도 아무도 모르는 상황을 겪어본 적이 있을 겁니다. 이 글에서는 세 가지 자동화 정책 그룹으로 스케줄링을 Clash에 온전히 맡기는 방법을 다룹니다. 목표는 빠를 때는 더 빠르게, 문제가 생겨도 눈치채지 못하게입니다.

세 가지 자동 정책 그룹 다시 보기

유형	스케줄링 방식	가장 적합한 상황
`url-test`	주기적으로 전체 속도 테스트 후 가장 빠른 노드로 이동	일상적인 웹서핑, 저지연 우선
`fallback`	목록 순서대로 검사해 살아 있는 첫 번째 노드를 사용	명확한 주/보조 우선순위가 있는 경우
`load-balance`	서로 다른 연결을 여러 노드에 분산	멀티스레드 다운로드, 특정 노드 속도 제한 방지

url-test: tolerance로 흔들림 줄이기

기본 설정에서 url-test에는 신경 쓰이는 문제가 하나 있습니다. 두 노드의 지연 시간이 비슷하면 계속 왔다 갔다 하면서, 전환될 때마다 진행 중이던 연결이 끊길 수 있습니다. 해법은 tolerance를 추가하는 것입니다.

흔들림을 줄인 url-test

proxy-groups:
  - name: "자동 속도 테스트"
    type: url-test
    proxies: [홍콩 01, 홍콩 02, 도쿄 01, 싱가포르 01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50   # switch only if 50ms+ faster than current

새 노드가 현재 노드보다 최소 50ms 이상 빨라야만 전환한다는 뜻입니다. 값은 필요에 따라 조정하면 됩니다. 값이 클수록 안정적이고, 작을수록 민감하게 반응합니다.

fallback: 주/보조 회선을 다루는 올바른 방법

고품질 전용 회선 하나와 일반 회선 여러 개를 함께 갖고 있다면 fallback이 최선의 선택입니다. 평소에는 항상 전용 회선을 쓰고, 전용 회선에 문제가 생기면 자동으로 강등되며, 복구되면 다시 자동으로 돌아옵니다.

주/보조 fallback

proxy-groups:
  - name: "주/보조 전환"
    type: fallback
    proxies: [홍콩-전용회선, 홍콩-일반 01, 미국-보조]   # priority order
    url: "http://www.gstatic.com/generate_204"
    interval: 120    # check more often for faster failover

proxies에 적은 순서가 그대로 우선순위 순서입니다. 검사 간격은 url-test보다 짧게 잡는 게 좋습니다. 그래야 장애 전환이 충분히 빨라집니다.

load-balance: 두 가지 분산 전략

load-balance 예시

proxy-groups:
  - name: "로드 밸런싱"
    type: load-balance
    proxies: [홍콩 01, 홍콩 02, 홍콩 03]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing   # or: round-robin

consistent-hashing: 같은 목적지 사이트는 항상 같은 노드로 고정되어 로그인 상태가 흐트러지지 않습니다. 평소에는 이쪽을 추천합니다.
round-robin: 연결이 노드마다 번갈아 분배됩니다. 멀티스레드 다운로드 속도가 눈에 띄게 좋아지지만, 일부 사이트는 IP가 바뀔 때마다 재로그인을 요구할 수 있습니다.

조합 전략: 중첩으로 "빠르고 안정적인" 체계 만들기

정책 그룹은 다른 정책 그룹을 참조할 수 있습니다. 아래 3단 구조는 커뮤니티에서 평가가 좋은 방식입니다.

중첩 조합 방안

proxy-groups:
  # Layer 1: user-facing switch
  - name: "노드 선택"
    type: select
    proxies: [스마트 스케줄링, 홍콩 전용회선, 수동 선택]

  # Layer 2: auto scheduling with failover
  - name: "스마트 스케줄링"
    type: fallback
    proxies: [저지연 그룹, 로드 밸런싱 그룹]
    url: "http://www.gstatic.com/generate_204"
    interval: 120

  # Layer 3: workers
  - name: "저지연 그룹"
    type: url-test
    proxies: [홍콩 01, 홍콩 02, 도쿄 01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: "로드 밸런싱 그룹"
    type: load-balance
    proxies: [싱가포르 01, 싱가포르 02, 미국 01]
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    strategy: consistent-hashing

평소 트래픽은 "저지연 그룹"에서 자동 속도 테스트로 처리됩니다. 그룹 전체가 쓸 수 없게 되면 fallback이 자동으로 "로드 밸런싱 그룹"으로 강등시킵니다. 직접 수동으로 개입하고 싶을 때는 "노드 선택"에서 한 번에 전환할 수 있습니다. 3단 구조가 각자 역할을 나눠 맡는 방식입니다.

성능 참고 url이 있는 정책 그룹은 각각 주기적으로 속도 테스트 요청을 보냅니다. 그룹이 너무 많거나 interval이 너무 짧으면 백그라운드 트래픽이 꽤 커질 수 있습니다. 일반 사용자는 자동 그룹 3~5개, 300초 간격이면 충분합니다.

세 가지 유형, 한 줄로 정리한 선택 기준

앞의 세세한 파라미터를 다 봤는데도 뭘 골라야 할지 감이 안 온다면, 이 간단한 기준을 기억하세요. 어떤 노드든 상관없이 가장 빠른 것만 원한다 → url-test, 명확한 주/보조 우선순위가 있다 → fallback, 대역폭을 최대한 뽑아내고 싶고 가끔 재로그인은 감수할 수 있다 → load-balance. 대부분의 사람은 일상적으로 url-test 그룹 하나만 있어도 충분합니다. fallback과 load-balance는 "명확한 필요가 생긴 뒤에" 추가하는 심화 옵션에 가까우니, 처음부터 복잡하게 구성하려고 애쓰지 않아도 됩니다.

정책 그룹이 작동하지 않을 때 점검할 방향

설정을 마쳤는데 스케줄링이 제대로 안 되는 것 같다면 이 순서로 확인해 보세요.

rules가 실제로 이 그룹을 참조하고 있는지 먼저 확인하세요: 정책 그룹을 정의했다고 해서 자동으로 쓰이는 건 아닙니다. 규칙(또는 최종 MATCH)이 그 그룹을 가리켜야 실제로 작동합니다. 가장 자주 빠뜨리는 부분입니다.
제어판의 프록시 페이지를 열어 그룹 내 노드 상태를 확인하세요: 그룹 안의 노드가 전부 타임아웃이거나 오프라인이면 url-test/load-balance가 "작동하지 않는 것처럼" 보이는데, 실제로는 쓸 수 있는 노드가 없는 상태일 뿐입니다.
url 테스트 주소 자체가 접속 가능한지 확인하세요: 기본값인 generate_204 주소가 특정 네트워크 환경에서 막혀 있어 테스트 결과가 전부 타임아웃으로 나올 수 있습니다. 다른 검사용 주소로 바꿔서 시도해 보세요.
fallback의 interval이 너무 길게 설정되어 있는지 확인하세요: 검사 간격을 600초 이상으로 설정하면 노드에 문제가 생겨도 한참 뒤에야 감지되고 전환됩니다. 체감상 "작동을 안 하는" 것처럼 느껴질 수 있습니다.

스케줄링 구성에는 처음부터 완벽한 정답이 없습니다. 가장 단순한 단일 url-test 그룹으로 얼마간 써 보면서 실제로 어떤 불편함이 있는지 관찰한 뒤, 필요에 맞춰 fallback이나 load-balance를 하나씩 추가하는 편이 처음부터 3단 구조를 짜는 것보다 유지보수하기 쉽습니다.

언제 복잡한 다단 구성에 시간을 들일 만할까

앞서 소개한 3단 구조가 모두에게 필요한 건 아닙니다. 복잡한 스케줄링을 짜기 전에 스스로 몇 가지를 먼저 물어보세요. 집이나 회사에 품질이 다른 여러 회선이 있어서 주/보조를 구분해야 하나요? 멀티스레드 다운로드를 자주 쓰고 노드 하나로는 대역폭이 부족한가요? "노드가 갑자기 죽었는데 아무도 바로 몰랐던" 경험이 있나요? 이 질문들의 답이 대부분 "아니오"라면 간단한 url-test 그룹 하나로 충분하고, "더 전문적으로 보이려고" 설정을 쌓을 필요는 없습니다. 반대로 가족이나 팀 전체의 네트워크 출구를 책임지고 있다면, 다단 스케줄링이 가져다주는 안정성 향상은 실질적이니 시간을 들여 다듬을 가치가 있습니다.

참고로 정책 그룹 이름은 직관적으로 짓는 게 좋습니다("홍콩 전용회선", "로드 밸런싱-싱가포르" 같은 식으로). 그래야 반년 뒤에 설정 파일을 다시 열었을 때도 당시 왜 이렇게 짰는지 한눈에 이해할 수 있습니다. select/fallback/url-test가 뒤섞인 이름들을 보며 멍하니 있는 상황을 피할 수 있습니다.

정리

세 가지 정책 그룹은 역할이 분명합니다. url-test는 "항상 가장 빠르게"를 추구해 대부분의 일상적인 상황에 적합하고, fallback은 "주/보조를 명확히"하는 데 강점이 있어 회선 우선순위가 뚜렷한 사용자에게 맞으며, load-balance는 "대역폭을 최대한 뽑아내는" 데 특화되어 있어 멀티스레드 다운로드나 특정 노드 속도 제한 방지에 어울립니다. tolerance와 interval 두 파라미터를 가볍게 보지 마세요. 제대로 맞추면 이유 없이 노드가 흔들리거나 전환이 느려서 답답한 상황을 많이 줄일 수 있습니다. 단순한 url-test 그룹 하나부터 시작해서, 실제로 필요가 생겼을 때 하나씩 더해 가는 편이 처음부터 복잡한 구조를 짜는 것보다 대부분의 사람에게 더 맞습니다.