Clash 프록시 그룹 유형 비교: url-test, fallback, load-balance 선택 가이드

프록시 그룹, 노드, 프록시 규칙부터 구분하기

Clash와 mihomo 코어를 사용하는 Clash Verge Rev는 프록시 노드를 프록시 그룹으로 묶고, 규칙에 따라 각 연결을 어느 그룹으로 보낼지 결정합니다. 프록시 그룹은 새로운 프록시 서버가 아니며 노드의 기존 프로토콜, 전송 방식 또는 출구 위치를 바꾸지도 않습니다. 그룹 구성원 중 이번 연결에 사용할 대상을 선택하는 역할을 담당합니다.

예를 들어 규칙에 따라 동영상 서비스 도메인은 “스트리밍” 그룹으로, 업무용 도메인은 “안정 회선” 그룹으로, 나머지 트래픽은 “기본 프록시” 그룹으로 보낼 수 있습니다. 각 그룹에는 서로 다른 유형을 사용할 수 있습니다. url-test는 테스트 결과를 바탕으로 지연 시간이 낮은 사용 가능 구성원을 우선 선택하고, fallback은 설정 순서에 따라 가장 먼저 사용 가능한 구성원을 선택하며, load-balance는 여러 사용 가능 구성원에 연결을 분산합니다.

따라서 세 유형의 차이를 단순히 “어느 쪽이 더 빠른가”로 설명할 수는 없습니다. 선택할 때는 최소한 다음 네 가지 기준을 확인해야 합니다.

구성원 선택 기준: 지연 시간, 고정 우선순위, 분배 알고리즘 중 무엇을 기준으로 선택하는지 확인합니다.
장애 발생 후 동작: 다시 측정하는지, 다음 순서로 넘어가는지, 나머지 구성원에 계속 분배하는지 확인합니다.
출구 일관성: 같은 대상 또는 같은 세션에서 가능한 한 동일한 출구 주소를 유지해야 하는지 확인합니다.
기기 부담: 주기적인 테스트는 소량의 네트워크 요청과 배터리, 백그라운드 리소스를 사용하므로 특히 모바일 기기에서는 간격을 적절히 설정해야 합니다.

상태 확인은 무엇을 측정하나

자동 프록시 그룹은 설정에 지정된 테스트 주소에 접속하고, 설정된 간격마다 가용성 또는 지연 시간 결과를 갱신합니다. 일반적인 테스트 주소는 매우 작은 HTTP 응답을 반환하며 DNS, TCP, TLS와 프록시 경로가 요청을 완료할 수 있는지 판단하는 데 사용됩니다. 이 결과는 기본 연결 상태를 보여주지만 모든 웹사이트의 실제 다운로드 속도와 같지는 않습니다.

테스트 대상의 위치, 노드에서 대상 사이트까지의 경로, 일시적인 혼잡, 통신사 네트워크가 결과에 영향을 줍니다. 어떤 노드가 테스트 주소에 가장 낮은 지연 시간을 보여도 다른 지역의 서비스에 반드시 가장 빠른 것은 아닙니다. 특정 서비스에 명확한 지역 및 안정성 요구가 있다면 먼저 용도에 맞는 노드를 추린 다음, 좁혀진 범위에서 자동 프록시 그룹을 사용하는 편이 적절합니다.

url-test: 테스트 지연 시간으로 사용 가능한 구성원 선택

url-test는 그룹 내 구성원의 연결 상태를 테스트한 뒤, 사용 가능한 구성원 중 테스트 지연 시간이 낮은 대상을 선택합니다. 구성원의 기능과 출구 지역이 비슷하고 사용자가 주로 반응 속도를 중시하는 환경에 적합합니다. 예를 들어 같은 지역에 일반 회선이 여러 개 있다면 url-test로 기본적인 자동 선별을 수행해 수동 전환 횟수를 줄일 수 있습니다.

다음은 자주 사용하는 설정 구조입니다. 지원되는 필드와 동작은 사용하는 코어 버전에 따라 달라질 수 있으므로, 가져오기 전에 현재 mihomo 설정 문서와 클라이언트 로그를 기준으로 확인해야 합니다.

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

interval은 테스트 간격을 의미하며 일반적으로 초 단위로 지정합니다. 간격을 지나치게 짧게 설정하면 백그라운드 테스트 빈도만 높아지고 사용성이 반드시 좋아지지는 않습니다. 반대로 너무 길면 회선 상태 변화를 제때 감지하지 못할 수 있습니다. 상시 사용하는 데스크톱은 네트워크 변동에 따라 몇 분 단위로 설정하고, 모바일 기기에서는 간격을 더 늘리는 것이 좋습니다.

tolerance는 지연 시간 차이가 작을 때 잦은 전환을 줄이는 데 사용합니다. 현재 구성원의 지연 시간이 95ms이고 다른 구성원이 80ms라면 차이가 크지 않으므로 즉시 전환하기보다 현재 구성원을 유지하는 편이 안정적일 수 있습니다. 허용 오차는 낮을수록 좋은 것이 아닙니다. 0으로 설정하면 측정값의 작은 흔들림에도 선택 대상이 반복해서 바뀔 수 있습니다.

lazy를 활성화하면 코어가 프록시 그룹이 실제로 사용될 때 해당 테스트를 수행할 수 있어, 장기간 사용하지 않는 그룹의 백그라운드 요청을 줄이는 데 도움이 됩니다. 다만 지연 검사 실행 조건과 캐시 동작은 코어 구현에 따라 다르므로 결과를 판단할 때는 로그와 클라이언트에 표시되는 마지막 테스트 시간을 기준으로 삼아야 합니다.

url-test의 적합한 용도와 한계

웹 브라우징, 코드 저장소 접속, 낮은 응답 시간이 필요한 일상적인 연결에 적합합니다.
같은 지역, 같은 용도, 비슷한 품질의 노드 묶음에 적합하며, 기능 차이가 큰 출구를 지연 시간만으로 한 자동 그룹에 섞는 방식에는 적합하지 않습니다.
테스트 지연 시간이 대역폭을 직접 의미하지는 않습니다. 대용량 파일 다운로드는 출구 대역폭, 서버 속도 제한, 장시간 혼잡의 영향을 더 크게 받습니다.
선택된 구성원이 바뀌면 새 연결에서 새로운 출구 주소를 사용할 수 있습니다. 출구 일관성이 중요한 로그인 세션에서는 주의해야 합니다.

fallback: 순서에 따라 첫 번째 사용 가능 구성원 사용

fallback의 핵심은 최저 지연 시간 비교가 아니라 우선순위입니다. 코어는 그룹 내 구성원의 사용 가능 여부를 확인하고 목록 앞쪽에 있는 사용 가능한 대상을 우선 선택합니다. 첫 번째 구성원을 사용할 수 없을 때만 다음 구성원을 사용하며, 첫 번째 구성원이 복구되면 이후에 생성되는 새 연결은 일반적으로 우선순위가 높은 구성원으로 돌아갑니다.

proxy-groups:
  - name: 안정 회선
    type: fallback
    proxies:
      - 주 회선
      - 보조 회선-1
      - 보조 회선-2
    url: http://www.gstatic.com/generate_204
    interval: 300
    lazy: true

이 방식은 회선마다 명확한 우선순위가 있는 환경에 특히 적합합니다. 예를 들어 주 회선은 고정된 출구를 사용하고 대상 서비스와 호환되며 장기간 안정적으로 작동하고, 보조 회선은 주 회선에 장애가 발생했을 때만 사용하는 경우입니다. 보조 회선의 테스트 지연 시간이 가끔 더 낮더라도 fallback은 여전히 사용 가능한 주 회선을 건너뛰지 않습니다.

“사용 가능”이라는 판단은 테스트 주소와 함께 해석해야 합니다. 테스트 성공은 해당 노드가 테스트 대상에 접속할 수 있다는 뜻일 뿐, 모든 대상 서비스에 접속할 수 있음을 보장하지 않습니다. 주 회선이 연결 상태 테스트에 정상적으로 응답하더라도 특정 업무 도메인이 라우팅, 지역 또는 서버 정책의 영향을 받으면 프록시 그룹은 주 회선을 계속 사용 가능한 상태로 판단할 수 있습니다. 이때는 단순히 검사 간격을 줄이기보다 업무 규칙을 조정하거나 프록시 그룹을 분리하고, 실제 환경을 잘 반영하는 테스트 대상을 사용해야 합니다.

fallback은 어떤 작업에 적합한가

원격 근무, 특정 지역 서비스, 홈 게이트웨이, 장시간 실행되는 기기는 일반적으로 “선호 회선을 유지하고 장애가 발생했을 때만 다음 회선으로 전환”하는 방식을 중시합니다. 이러한 요구는 fallback의 순서 기반 동작과 일치합니다. 설정할 때 장기간 사용하려는 구성원을 맨 앞에 배치하고, 보조 구성원도 동일한 업무 서비스에 접속할 수 있는지 확인해야 합니다.

목록 순서에 특별한 의미가 없고 모든 구성원을 자유롭게 교체할 수 있다면 url-test가 일상적인 자동 선택 요구에 더 잘 맞는 경우가 많습니다. 반대로 사용자가 현재 노드를 직접 지정하려면 select 유형을 사용해야 하며, fallback이 임시 수동 선택을 기억할 것이라고 기대해서는 안 됩니다.

load-balance: 여러 사용 가능 구성원에 연결 분산

load-balance는 하나의 “가장 빠른 노드”를 선택하는 것이 주된 목적이 아니라, 정책에 따라 서로 다른 연결을 그룹 내 여러 사용 가능 구성원에 분산합니다. 서로 독립적인 요청이 많거나 동시 다운로드, 여러 기기가 공유하는 게이트웨이 환경에 적합하지만, 이미 설정된 단일 연결의 대역폭을 여러 노드의 대역폭으로 직접 합산하지는 않습니다.

proxy-groups:
  - name: 동시 분배
    type: load-balance
    proxies:
      - 노드-A
      - 노드-B
      - 노드-C
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

일반적인 consistent-hashing은 대상 정보를 기준으로 일관된 매핑을 수행하므로 구성원 목록이 안정적일 때 동일하거나 유사한 대상이 같은 구성원을 사용하는 경향이 있습니다. 덕분에 같은 사이트에 연속해서 요청할 때 출구가 자주 바뀌는 현상을 줄일 수 있습니다. 구성원에 장애가 발생하거나 목록이 바뀌면 일부 매핑도 조정되므로 영구적으로 출구를 고정하는 방식은 아닙니다.

round-robin은 새 연결을 차례로 분배하는 방식에 가깝습니다. 구성원마다 연결을 받을 기회를 비교적 균등하게 제공하지만, 하나의 앱이 여러 도메인에 접속하거나 여러 연결을 만들 때 서로 다른 출구 주소가 사용될 수 있습니다. 사용할 수 있는 strategy 값은 Clash 계열과 mihomo 버전에 따라 달라지므로 사용 전 현재 코어 문서를 확인해야 하며, 다른 구현의 필드를 설정에 그대로 복사해서는 안 됩니다.

로드 밸런싱은 단일 연결의 대역폭 결합이 아닙니다

브라우저에서 파일 하나를 다운로드할 때 서버가 단일 연결만 설정한다면 해당 연결은 일반적으로 하나의 구성원만 거칩니다. 다운로드 프로그램, 브라우저 또는 애플리케이션이 여러 개의 독립 연결을 만들고 이 연결들이 서로 다른 구성원에 분배될 때만 전체 처리량이 여러 회선을 활용할 가능성이 있습니다. 최종 속도는 로컬 네트워크 한도, 노드 속도 제한, 대상 서버와 프로토콜 동작의 영향을 계속 받습니다.

로드 밸런싱은 출구 일관성 문제도 일으킬 수 있습니다. 일부 웹사이트는 짧은 시간에 출처 주소가 자주 바뀌는 것을 비정상적인 활동으로 판단하며, 로그인 상태, 인증 코드 요청 빈도, 지역별 콘텐츠에도 영향을 줄 수 있습니다. 이러한 서비스에는 규칙을 사용해 도메인을 fallback, url-test 또는 고정된 select 그룹으로 보내고, 정적 리소스나 소프트웨어 업데이트처럼 동시 요청이 많은 트래픽은 로드 밸런싱 그룹으로 분산할 수 있습니다.

UDP 트래픽도 세션 매핑과 노드 지원 여부를 확인해야 합니다. 음성 통화, 게임, QUIC 연결은 경로 변화에 민감하므로 단순히 “분산”을 목적으로 관련 트래픽을 출구 사이에서 자주 바꾸면 안 됩니다. 설정 후에는 실제 앱으로 패킷 손실, 지연 변동, 재연결 상태를 테스트해야 하며 상태 확인 수치만 확인해서는 안 됩니다.

기기와 사용 환경에 따른 프록시 그룹 선택

데스크톱 일상 브라우징: url-test 우선

Windows, macOS 또는 Linux 데스크톱은 일반적으로 웹 브라우징, 코드 다운로드, 메신저를 동시에 처리합니다. 노드가 같은 지역에 있고 접속 성능이 비슷하다면 url-test를 사용하되, 적절한 허용 오차를 설정해 불필요한 전환을 줄일 수 있습니다. 특정 지역을 고정해야 하거나 안정적인 출구가 필요한 도메인은 규칙을 통해 별도의 fallback 또는 수동 선택 그룹으로 분리하세요.

원격 근무와 고정 업무: fallback 우선

기업 시스템, 원격 데스크톱, 관리 콘솔, 장시간 로그인 상태를 유지하는 서비스는 예측 가능성을 더 중시합니다. 요구 사항에 가장 잘 맞는 회선을 첫 번째에 두고 실제 안정성에 따라 보조 구성원을 정렬하는 방식이 단순히 밀리초 단위 지연 시간으로 정렬하는 것보다 적합합니다. 주 회선에 장애가 발생한 뒤에야 보조 회선이 호환되지 않는다는 사실을 알지 않도록, 대상 서비스, DNS 해석, UDP 지원을 미리 확인해야 합니다.

홈 게이트웨이와 여러 기기의 동시 연결: load-balance는 신중하게 사용

라우터나 보조 게이트웨이가 여러 기기를 동시에 처리하면 연결 수가 많아져 로드 밸런싱의 연결 분산 효과가 더 잘 드러납니다. 출구 일관성이 중요한 서비스는 규칙으로 별도 그룹에 분리하고, 시스템 업데이트, 정적 리소스, 일반적인 동시 요청은 load-balance로 보내는 것이 좋습니다. 게이트웨이 하드웨어 성능에 한계가 있다면 상태 확인, TUN 전달, 대량 연결 추적이 차지하는 리소스도 함께 관찰해야 합니다.

모바일 기기: 테스트 간격을 늘리고 구성원 범위 줄이기

노트북과 모바일 단말은 Wi-Fi, 핫스팟, 셀룰러 네트워크 사이를 오갑니다. 네트워크 환경 자체가 바뀌면 테스트 결과가 무효화될 수 있어 지나치게 잦은 상태 확인의 효과가 제한적입니다. 자동 그룹의 구성원 수를 줄이고 검사 간격을 늘리며 적절한 지연 검사를 활성화할 수 있습니다. 프록시를 가끔만 사용하는 기기라면 복잡한 자동 정책보다 수동 선택 그룹이 더 직관적일 수도 있습니다.

TUN 모드가 프록시 그룹의 의미를 바꾸지는 않습니다

TUN 모드는 시스템 프록시 설정을 따르지 않는 일부 프로그램을 포함해 더 많은 시스템 트래픽을 가로채는 기능입니다. url-test를 로드 밸런싱으로 바꾸거나 fallback의 구성원 순서를 변경하지는 않습니다. 트래픽이 mihomo에 들어온 뒤에도 규칙에 따라 프록시 그룹에 매칭되고, 프록시 그룹이 구성원을 선택하는 방식은 그대로 유지됩니다.

TUN을 활성화하면 처리 대상 연결의 범위가 넓어져 DNS, 로컬 네트워크 트래픽, UDP 앱도 코어로 들어올 수 있으므로 프록시 그룹 설정 문제가 더 뚜렷하게 나타날 수 있습니다. 문제를 해결할 때는 “트래픽이 TUN에 의해 가로채졌는가”, “어느 프록시 그룹에 규칙이 매칭되었는가”, “프록시 그룹이 최종적으로 어떤 구성원을 선택했는가”를 세 단계로 나누어 확인해야 합니다.

프록시 그룹이 예상대로 전환되지 않을 때의 점검 순서

현재 실제로 실행 중인 설정을 확인합니다.
구독을 업데이트하면 새로운 프록시 그룹이 생성될 수 있고, 설정 오버라이드로 그룹 이름, 구성원, 테스트 매개변수가 바뀔 수도 있습니다. 먼저 Clash Verge Rev의 설정 페이지에서 현재 활성화된 설정을 확인한 뒤 실행 중인 프록시 그룹의 내용을 대조하세요.
규칙 매칭 결과를 확인합니다.
연결이 대상 프록시 그룹으로 들어가지 않았다면 그룹 내부 알고리즘을 바꿔도 효과가 없습니다. 연결 또는 로그 페이지를 열어 도메인, 대상 주소, 규칙 유형, 최종 매칭된 프록시 그룹 이름을 확인하세요.
상태 테스트 결과를 확인합니다.
각 구성원의 마지막 테스트 시간, 지연 시간, 사용 가능 상태를 확인합니다. 모두 시간 초과라면 테스트 주소, DNS, 노드 자체, 로컬 네트워크를 점검해야 합니다. 일부 구성원만 실패한다면 해당 회선을 개별적으로 확인하세요.
이름과 들여쓰기를 확인합니다.
YAML은 들여쓰기에 민감하며, proxies 안의 이름은 노드 또는 다른 프록시 그룹 이름과 정확히 일치해야 합니다. 이름에 특수 문자가 포함되어 있다면 따옴표로 감싸 파싱 시 모호함을 피하세요.
새 연결로 다시 테스트합니다.
테스트 중인 앱의 기존 세션을 종료하거나 연결이 끝날 때까지 기다린 뒤 다시 접속하세요. 화면에 표시된 프록시 상태만 새로 고쳐서는 이미 설정된 모든 연결이 즉시 이동하지 않습니다.
DNS 문제와 프록시 장애를 구분합니다.
도메인이 해석되지 않으면 프록시 그룹이 연결할 대상 자체를 아직 확보하지 못했을 수 있습니다. 먼저 DNS 로그, nameserver 설정, DNS 가로채기 설정을 확인한 뒤 노드 선택에 이상이 있는지 판단하세요. IP 주소로는 연결되지만 도메인으로 실패한다면 일반적으로 이름 해석 경로부터 점검하는 것이 좋습니다.

세 가지 프록시 전략 요약

지연 시간이 낮은 구성원을 자동으로 선택해야 할 때: url-test를 사용하고 허용 오차로 잦은 전환을 줄입니다.
주 회선과 순차적인 보조 회선을 고정해야 할 때: fallback을 사용하고 실제 업무 우선순위에 따라 구성원을 배치합니다.
많은 독립 연결을 여러 구성원에 분산해야 할 때: load-balance를 사용하되 출구 일관성 문제도 함께 관리합니다.
사용자가 노드를 직접 지정해야 할 때: select를 사용하고 자동 전략으로 수동 제어를 흉내 내지 않습니다.

실제 설정에서는 여러 유형을 조합할 수 있습니다. 최상위 프록시 그룹에서 수동 선택을 제공하고, 내부에 자동 속도 테스트 그룹, 장애 전환 그룹, 로드 밸런싱 그룹을 배치하는 방식입니다. 규칙은 용도가 분명한 그룹 이름만 참조하고 그룹 내부 구성원은 같은 유형으로 유지하며, 테스트 주소와 간격은 기기와 업무 환경에 맞게 조정하세요. 이렇게 하면 Clash Verge Rev에서 상태를 확인하기 쉽고, 장애가 발생했을 때 규칙, 상태 확인, 노드 자체 중 어느 부분에 문제가 있는지도 빠르게 파악할 수 있습니다.