노드가 많아지면 수동 전환이 가장 귀찮은 일이 됩니다. Clash가 제공하는 세 가지 자동 프록시 그룹——url-test, fallback, load-balance——은 각각 다른 문제를 해결하며, 잘 조합하면 노드 장애나 지연 변동을 거의 "느끼지 못하게" 만들 수 있습니다.
세 가지 자동 프록시 그룹 한눈에 보기
| 종류 | 노드 선택 로직 | 적합한 상황 |
|---|---|---|
| url-test | 정기적으로 속도를 측정해 항상 지연이 가장 낮은 노드를 사용 | 최적의 속도를 원하고 간혹 전환되는 것을 허용할 수 있는 경우 |
| fallback | 순서대로 사용하며, 현재 노드가 실패해야 다음으로 전환 | 명확한 "주·백업" 우선순위가 필요한 경우 |
| load-balance | 알고리즘으로 여러 요청을 여러 노드에 분산 | 여러 노드에 부하를 분산해 단일 노드의 과부하를 피하고 싶은 경우 |
url-test: 가장 빠른 노드를 자동으로 선택
가장 많이 쓰이는 그룹 타입입니다. Clash는 그룹 내 모든 노드에 대해 정기적으로 속도 테스트 요청을 보내고, 항상 지연이 가장 낮은 노드를 사용합니다.
tolerance(허용 오차, 단위 밀리초)는 몇 밀리초의 측정 흔들림 때문에 잦은 전환이 일어나는 것을 막아줍니다. 새 노드의 지연이 "현재 지연 − tolerance"보다 낮을 때만 실제로 전환됩니다.
fallback: 명확한 주·백업 순서
"주력 노드"가 있고, 그것이 실패했을 때만 백업 노드로 전환하고 싶다면 fallback이 더 적합합니다. proxies 목록의 순서대로 확인하며, 항상 목록에서 앞쪽에 있으면서 사용 가능한 노드를 우선 사용합니다.
load-balance: 부하를 분산하기
품질이 비슷한 노드가 여러 개 있고 연결 부하를 분산하고 싶을 때는 load-balance를 사용할 수 있습니다. 두 가지 분배 알고리즘을 지원합니다.
- consistent-hashing: 같은 목적지 주소는 항상 같은 노드에 안정적으로 배정되어, 세션 유지가 필요한 상황에 적합합니다.
- round-robin: 순서대로 연결을 배분해 분포는 더 균등하지만, 같은 목적지 주소가 다른 노드에 배정될 수 있습니다.
헬스 체크 파라미터는 어떻게 조정할까
url, interval, tolerance 세 필드가 함께 그룹이 "얼마나 자주 검사할지"와 "얼마나 차이가 나야 전환할지"를 결정합니다. 너무 공격적으로 설정하거나 너무 보수적으로 설정하면 모두 문제가 생길 수 있습니다.
| 필드 | 역할 | 조정 권장 |
|---|---|---|
| url | 속도 테스트 요청이 도달하는 목적지 주소 | 가볍고 안정적인 테스트 주소를 사용하고, 대용량 파일이나 변동이 잦은 사이트는 피하세요 |
| interval | 두 번의 속도 테스트 사이 간격(초) | 너무 짧으면 노드 측 부담이 늘어나므로, 300초 정도가 대체로 균형이 좋습니다 |
| tolerance | 전환에 필요한 최소 지연 차이(밀리초) | 네트워크 자체가 흔들림이 크면 조금 높게 설정해 몇 밀리초 차이로 잦은 전환이 일어나는 것을 막으세요 |
tolerance 설정이 너무 작지 않은지 확인하세요. 곧바로 노드 품질을 의심하기보다 먼저 확인해야 할 부분입니다.
프록시 그룹을 중첩할 수 있을까
가능합니다. 프록시 그룹의 proxies 필드에는 구체적인 노드 이름뿐 아니라 다른 프록시 그룹의 이름도 넣을 수 있습니다. 이를 통해 "먼저 지역별로 자동 속도 테스트 그룹을 만들고, 그다음 어느 지역을 쓸지 수동으로 선택"하는 계층 구조를 만들 수 있습니다. 다만 중첩 단계는 너무 깊게 하지 않는 것이 좋습니다. 한 단계가 늘어날 때마다 실제로 적용되는 판단 로직도 한 단계 늘어나, 문제가 생겼을 때 원인을 찾기가 더 복잡해집니다. 일반적으로 2~3단계면 대부분의 사용 사례를 충분히 다룰 수 있습니다.
실전: 다중 지역 노드 풀 구성하기
흔히 쓰는 다층 구조는, 먼저 지역별로 여러 url-test 하위 그룹("홍콩 자동", "싱가포르 자동" 등)을 만들고, 그 위에 select 수동 그룹 하나를 두어 최종 선택권을 스스로 갖는 방식입니다. 자동화와 유연성을 모두 챙길 수 있습니다.
다른 규칙을 다른 프록시 그룹에 매칭시키기
프록시 그룹의 진짜 힘은 rules와 결합했을 때 발휘됩니다. 서로 다른 종류의 트래픽을 모두 하나의 "만능" 프록시 그룹에 몰아넣지 않고, 각각 다른 그룹으로 라우팅할 수 있습니다. 예를 들어 스트리밍 도메인은 스트리밍 해제 효과가 좋은 노드만 포함하는 전용 그룹으로, 게임 도메인은 저지연 우선 url-test 그룹으로, 나머지 트래픽은 범용 자동 선택 그룹으로 보내는 방식입니다. 이렇게 하면 각 트래픽 종류가 가장 적합한 노드 선택 로직에 매칭되며, 하나의 기준으로 모든 상황을 처리하지 않게 됩니다.
프록시 그룹을 나눠야 할지 판단하는 방법
모든 상황을 세밀하게 나눌 필요는 없습니다. 판단 기준은 간단합니다. 특정 종류의 트래픽이 "노드 선택 로직"에 대해 뚜렷하게 다른 선호를 갖고 있다면(게임은 지연에 극도로 민감하고, 스트리밍은 해제 지역에 엄격한 요구가 있는 경우 등) 별도의 프록시 그룹으로 나눌 가치가 있습니다. 반면 일반적인 웹 브라우징이라면 범용 자동 선택 그룹만으로 충분하며, "더 전문적으로 보이기" 위해 과도하게 나눌 필요는 없습니다. 그렇게 하면 오히려 이후 유지 관리와 문제 해결의 복잡도만 늘어납니다.
노드를 전환한 뒤 기존 연결이 영향을 받지 않는 이유
수동 또는 자동으로 그룹 내 노드를 전환한 뒤, 이미 맺어진 연결(다운로드 중인 파일, 재생 중인 영상 등)이 즉시 새 노드로 넘어가지 않고, 해당 연결이 자연스럽게 끝난 뒤 다음에 새로 맺어지는 연결부터 새 노드를 사용한다는 것을 발견할 수 있습니다. 이는 의도된 설계입니다. 프록시 계층의 노드 전환은 "새 연결"에 대해 작동하며, 이미 맺어진 세션을 중단시키지 않습니다. 이렇게 하면 노드를 자주 전환해도 진행 중인 다운로드나 통화가 끊기는 것을 막을 수 있습니다. 모든 연결을 즉시 전환해야 한다면, 패널의 Connections에서 기존 연결을 수동으로 끊어 새 요청이 다시 시작되도록 할 수 있습니다.
정리
어떤 프록시 그룹도 "만능"은 아닙니다. 속도를 원한다면 url-test, 명확한 주·백업 순서가 필요하다면 fallback, 부하를 분산하고 싶다면 load-balance를 사용하세요. 실제 사용에서는 이들을 중첩해 조합하고, 마지막에 수동 select 그룹으로 받쳐주는 것이 자동화와 제어력의 균형을 맞추는 가장 좋은 방법인 경우가 많습니다.