로드 밸런싱과 페일오버：안정적인 프록시 그룹 구성하기

프록시 그룹 및 전략 개요

Clash의 proxy-groups는 트래픽이 여러 노드 또는 하위 그룹 중에서 어떻게 선택되는지를 결정합니다. 규칙이 매칭된 후 특정 프록시 그룹(예: PROXY, 자동 선택, 페일오버)으로 지정되고, 그룹 내 전략이 최종적으로 어느 노드를 사용할지 결정합니다.

수동으로 선택하는 select 외에도 세 가지 자동화 전략이 있어 안정성과 경험을 크게 향상시킵니다:

• url-test: 정기적으로 속도 테스트를 하여 가장 낮은 지연의 노드를 자동으로 선택합니다.
• fallback: 순서대로 사용하며, 현재 노드를 사용할 수 없을 때 자동으로 다음 노드로 전환합니다.
• load-balance: 연결을 여러 노드에 분산하여 부하를 분담합니다.

이러한 전략을 합리적으로 조합하면 「수동 노드 전환」, 「단일 장애점으로 인한 연결 끊김」 등의 일반적인 불편함에서 벗어나 프록시 연결을 빠르고 안정적으로 유지할 수 있습니다.

select：수동 선택

select는 가장 기본적인 프록시 그룹 유형으로 사용자가 클라이언트 또는 대시보드에서 수동으로 노드를 선택합니다. 「어떤 회선이 가장 좋은지 알고 있는」 경우나 자동 전략의 보조로 적합합니다. 예를 들어 「자동 선택」(url-test)과 「수동 선택」(select)을 동시에 설정하여 평소에는 자동을 사용하고 필요할 때 수동으로 개입할 수 있습니다.

구독 서비스에는 보통 「노드 선택」, 「홍콩」, 「일본」 등의 select 그룹이 제공되어 지역이나 용도에 따라 편리하게 전환할 수 있습니다.

url-test：자동 최적 선택

url-test는 그룹 내 각 노드에 정기적으로 HTTP 요청을 보내(기본 속도 테스트 URL: http://www.gstatic.com/generate_204), 지연에 따라 가장 빠른 노드를 선택하여 자동 전환합니다. 「항상 가장 빠른 노드를 사용하고 싶고 수동 속도 테스트를 하지 않고 싶은」 사용자에게 적합합니다.

핵심 파라미터 설명:

• interval: 속도 테스트 간격(초), 기본값 300. 너무 짧으면 잦은 전환이 발생할 수 있으므로 주의하세요.
• tolerance: 허용 오차(밀리초). 새 노드가 현재보다 이 값 이상 빠를 때만 전환하여 잦은 변동을 방지합니다.
• lazy: 지연 로드. 트래픽이 있을 때만 속도 테스트를 수행하여 리소스를 절약합니다.

fallback：페일오버

fallback은 proxies 목록 순서대로 노드를 사용하며, 현재 노드의 속도 테스트가 실패하거나 도달할 수 없을 때만 다음 노드를 시도합니다. 「명확한 주력 노드가 있고, 주력이 다운될 때 백업을 사용」하는 경우에 적합합니다. 예: 주력 홍콩, 백업 일본, 백업 미국.

url-test와의 차이점: fallback은 더 빠른 노드로 능동적으로 전환하지 않으며, 현재 노드가 실패했을 때만 전환합니다. 따라서 더 안정적이고 전환이 적습니다. 지연 변동에 민감하거나 특정 회선을 고정적으로 사용하고 싶은 사용자, 예를 들어 라이브 스트리밍이나 원격 데스크톱 연결 시에 적합합니다.

load-balance：로드 밸런싱

load-balance는 서로 다른 연결을 그룹 내 여러 노드에 분산하여 단일 노드의 부하를 줄이고 전체적인 처리량을 향상시킵니다. 선택 가능한 전략:

• round-robin: 라운드 로빈. 각 노드를 순서대로 사용합니다.
• consistent-hashing: 일관성 해싱. 동일한 대상(도메인+포트)은 항상 같은 노드로 고정되어 세션 유지가 필요한 사이트(예: 로그인 상태)에 더 적합합니다.

로드 밸런싱은 다중 노드, 고병렬 환경에 적합하며 개인 사용자의 일상적인 사용에는 url-test나 fallback으로 보통 충분합니다. 구독한 노드 수가 많다면 지역별로 url-test 그룹을 구성하고 상위 레이어에서 2차 최적 선택을 하여 다중 노드의 장점을 최대한 활용하는 것도 좋습니다. 프록시 그룹 구조를 합리적으로 계획하는 것이 Clash 사용 경험을 향상시키는 핵심 단계입니다.

중첩 프록시 그룹

프록시 그룹의 proxies에는 노드 이름뿐만 아니라 다른 프록시 그룹 이름도 넣을 수 있어 중첩이 가능합니다. 예를 들어:

먼저 각 지역 그룹 내에서 가장 빠른 노드를 선택하고, 그 다음 지역 그룹들 사이에서 가장 빠른 것을 선택합니다. 구조가 명확하고 관리하기 쉽습니다. 중첩 레이어 수는 너무 많지 않게 하는 것이 좋으며, 보통 2~3 레이어면 대부분의 요구를 충족할 수 있습니다. 너무 깊은 중첩은 속도 테스트 오버헤드와 이해 비용을 증가시킵니다.

파라미터 조정과 문제 해결

자동 전환이 너무 잦으면 tolerance 또는 interval을 늘리세요. 노드가 자주 오프라인으로 잘못 판단되면 속도 테스트 URL에 접근 가능한지, 노드가 차단되었는지 확인하세요. 특정 노드를 고정적으로 사용하고 싶다면 select나 fallback을 사용하고 목표 노드를 첫 번째에 배치하세요. 속도 테스트 URL은 generate_204 유형의 경량 인터페이스를 사용하는 것을 권장합니다. 응답이 빠르고 트래픽이 적어 노드에 추가적인 부담을 주지 않습니다.

Clash 대시보드의 Proxies 페이지에서 각 그룹의 현재 선택된 노드와 지연을 실시간으로 확인할 수 있어 디버깅에 편리합니다. 구독 서비스를 사용하는 경우 일부 구독에는 이미 최적화된 프록시 그룹이 내장되어 있어 바로 사용할 수 있습니다. 직접 설정을 작성할 때는 본문의 예시를 참고하여 단계적으로 조정하세요.

대표적인 사용 시나리오

일상적인 인터넷 사용: 규칙에서 PROXY를 url-test의 「자동 선택」으로 지정하여 속도와 편리함을 모두 잡습니다. 가끔 노드를 고정해야 할 때 클라이언트에서 select 그룹으로 전환합니다. 대부분의 구독 서비스에는 이미 비슷한 구조가 내장되어 있어 가져오기 후 바로 사용할 수 있습니다.

라이브 스트리밍 / 화상 회의: 지연과 안정성 요구가 높습니다. fallback을 사용하여 저지연 노드를 첫 번째에 배치하거나, select로 속도 테스트 최적의 회선을 고정하여 url-test의 자동 전환으로 인한 일시적인 끊김을 방지하는 것을 권장합니다.

대용량 파일 다운로드: load-balance로 여러 노드에 분산하거나 select로 대역폭이 큰 전용 회선 노드를 선택할 수 있습니다. 일부 구독 서비스는 단일 연결 속도를 제한하므로 로드 밸런싱이 단일 회선 대역폭 상한을 돌파하지 못할 수 있습니다. 어떤 시나리오든 Clash 대시보드에서 실제 성능을 관찰한 후 interval, tolerance 등의 파라미터 조정 여부를 결정하여 과도한 최적화로 인한 불안정을 방지하세요.

정리

url-test, fallback, load-balance 세 가지 전략은 각각 특징이 있습니다: 속도 추구에는 url-test, 안정성 추구에는 fallback, 부하 분산에는 load-balance. tolerance, interval, lazy 등의 파라미터로 미세 조정하고, select 수동 개입과 중첩 프록시 그룹을 결합하면 빠르고 안정적이며 끊기지 않는 프록시 방안을 구성할 수 있습니다. 「자동 선택 + 수동 선택」의 이중 그룹 설정으로 시작하여 실제 경험에 따라 점진적으로 최적화하는 것을 권장합니다. 프록시 그룹 설정은 Clash 고급 활용의 핵심 기술 중 하나로, 숙달하면 구독 서비스를 변경하거나 자체 노드를 구축할 때도 빠르게 편리한 연결 전략을 구성할 수 있습니다. 약간의 시간을 투자하여 각 전략의 차이를 이해하면 장기적으로 수동 노드 전환 시간을 크게 절약하고 인터넷 경험도 더 편하고 원활해집니다.