Clash url-test·fallback·load-balance 전략 그룹 비교 및 설정 가이드

세 가지 전략 그룹, 라우팅 목적부터 구분하기

웹 서핑에서 지연 시간이 짧은 노드를 자동으로 고르고 싶다면 url-test를 사용하세요. 주 회선을 우선 사용하고 장애가 발생했을 때만 예비 회선으로 전환하려면 fallback이 적합합니다. 여러 노드에 연결을 분산하려면 load-balance를 선택하세요. 모두 proxy-groups 유형이지만 노드를 고르는 기준은 서로 다릅니다. 클라이언트에 ‘자동’이라고 표시되는지만 보고 선택하면 안 됩니다.

전략 그룹은 어떤 아웃바운드를 사용할지 결정하지만, 앱 트래픽을 자동으로 Clash에 연결하지는 않습니다. 시스템 프록시나 TUN이 트래픽을 받아오고, 규칙 모드에서는 rules가 연결을 특정 전략 그룹으로 전달합니다. 규칙이 최종적으로 DIRECT를 가리킨다면 그룹의 테스트 옵션을 바꿔도 해당 연결 경로는 달라지지 않습니다.

전략 유형	선택 기준	적합한 사용 사례	주요 제한 사항
`url-test`	지연 시간 테스트 및 전환 허용치	웹 서핑, 일상적인 자동 노드 선택	지연 시간이 짧아도 처리량이 높다는 뜻은 아님
`fallback`	목록 순서 및 상태 확인	고정 주 회선과 장애 시 예비 회선	예비 회선이 더 빠르다고 우선 사용하지 않음
`load-balance`	분배 알고리즘 및 상태 확인	여러 연결을 사용하는 작업, 여러 대상에 접속하는 경우	단일 연결의 대역폭을 합산할 수 없음

url-test: 지연 시간으로 노드 선택, tolerance로 불필요한 전환 방지

url-test는 후보 노드로 테스트 주소에 요청을 보내고 결과에 따라 노드를 자동으로 선택합니다. 여기서 측정하는 값은 테스트 서버에 요청하는 데 걸린 시간이지, 다운로드 속도나 모든 웹사이트에서의 평균 체감 속도가 아닙니다. 테스트 서버까지의 경로가 원활해도 동영상 서비스나 개발 저장소까지의 경로가 좋다는 보장은 없습니다.

권장 시작값: 300초 간격, 50ms 허용치

아래는 그룹 정의 예시이며 전체 구독 설정이 아닙니다. 예시에 나온 ‘노드-A’, ‘노드-B’, ‘노드-C’는 기존 설정의 proxies에 이미 정의되어 있어야 하며 이름도 정확히 일치해야 합니다. 기존 proxy-groups 목록에 추가하고 최상위 키를 중복해서 만들지 마세요.

proxy-groups:
  - name: 자동 저지연
    type: url-test
    proxies:
      - 노드-A
      - 노드-B
      - 노드-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

interval: 300: 정기 상태 확인 간격은 300초, 즉 5분입니다. 앱 요청의 제한 시간이 아닙니다.
tolerance: 50: 전환 허용치는 50ms입니다. 후보 노드가 조금 더 빠르다는 이유만으로 계속 전환되는 현상을 줄여 줍니다. 지연 시간 상한이 아니며, 50ms를 초과한 노드를 제외하지도 않습니다.
lazy: false: 그룹을 사용하지 않는 동안에도 정기적으로 검사해 결과를 확인하기 쉽습니다. 노드가 많으면 테스트 요청도 늘어납니다.
url: 응답이 빠르고 안정적으로 접속할 수 있는 테스트 주소를 선택하세요. 예시 주소는 보통 HTTP 204를 반환합니다. 로그인이 필요하거나 리디렉션이 잦고 보안 확인을 거치는 페이지는 사용하지 마세요.

예를 들어 다른 조건이 같을 때 현재 노드의 측정값이 120ms이고 후보 노드가 105ms라면, 차이가 15ms에 불과해 50ms 허용치에서는 보통 경로를 바꿀 이유가 없습니다. 후보 노드가 60ms까지 낮아지면 전환할 만한 차이가 됩니다. 이는 옵션의 의미를 설명하기 위한 예시이며, 사이트에서 직접 측정한 결과가 아닙니다. 실제 선택은 현재 코어 상태와 로그를 기준으로 판단하세요.

지연 시간만으로 판단하기 어려운 작업

대용량 다운로드, 장시간 동영상 전송, 원격 데스크톱은 대역폭과 패킷 손실, 지터에도 영향을 받습니다. 자동 그룹으로 사용 가능한 노드를 추린 뒤 같은 시간대와 같은 대상에 접속해 전송 속도를 비교해 보세요. 로그인 세션처럼 출구 IP를 고정해야 한다면 노드를 직접 선택하거나 주 회선과 예비 회선의 순서가 명확한 그룹을 사용하는 편이 좋습니다.

fallback: 목록 순서대로 사용 가능한 첫 번째 노드 선택

fallback의 핵심은 우선순위입니다. 목록 앞쪽 노드가 상태 검사에 통과하면 해당 노드를 우선 사용하고, 사용할 수 없을 때만 뒤쪽의 사용 가능한 노드로 넘어갑니다. 따라서 주 회선을 첫 번째에, 예비 회선을 그 뒤에 배치해야 합니다.

proxy-groups:
  - name: 주 회선 장애 전환
    type: fallback
    proxies:
      - 노드-A
      - 노드-B
      - 노드-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

노드-A의 테스트 지연 시간이 180ms이고 노드-B가 75ms라고 가정해 보겠습니다. A가 정상 상태라면 그룹은 계속 A를 우선 사용합니다. 여기에 tolerance를 추가해도 지연 시간에 따라 노드를 선택하는 그룹으로 바뀌지는 않습니다. ‘더 빠른 노드를 사용’하려는 목적이라면 url-test를 사용하세요.

복구 및 장애 전환 범위

주 회선이 정상 상태로 복구되면 이후 연결에서는 다시 주 회선이 우선 고려됩니다. 장애 감지와 복구는 검사 결과와 코어의 동작 시점에 따라 달라지므로 즉시 전환된다고 보장할 수 없습니다.
그룹 전환은 주로 이후에 생성되는 연결에 적용됩니다. 이미 설정된 TCP 연결은 새 노드로 옮겨가지 않으며, 기존 연결이 끊기면 앱에서 다시 연결해야 할 수 있습니다.
테스트 주소에 접속할 수 있다는 것은 해당 상태 검사를 통과했다는 뜻일 뿐입니다. 특정 서비스 사이트에만 접속할 수 없는 경우에도 주 회선은 정상으로 판정될 수 있으므로 대상 사이트나 규칙을 확인해야 합니다.

회의나 원격 터미널처럼 연결을 계속 유지해야 하는 작업에서 주·예비 회선 전환은 장애 복구 수단이지, 연결을 끊김 없이 이전하는 기능이 아닙니다. 적용 전에 테스트용 주 회선을 잠시 비활성화해 새 연결이 예비 회선으로 넘어가는지 확인한 다음, 주 회선을 복구해 우선순위를 검증할 수 있습니다. 테스트 중 DNS와 TUN 설정을 함께 바꾸면 어느 계층에서 변화가 생겼는지 판단하기 어려우므로 피하세요.

load-balance: 연결 분산, 단일 연결 대역폭 합산은 불가

load-balance는 사용 가능한 구성원 노드에 트래픽을 분산하며, 분배 방식은 strategy에 따라 달라집니다. 파일 하나의 연결을 여러 회선으로 나눠 동시에 전송하는 대역폭 합산 기능은 아닙니다. 단일 TCP 연결은 선택된 아웃바운드 하나를 사용하며, 앱이 여러 연결을 직접 만들 때 여러 노드가 참여할 수 있습니다.

proxy-groups:
  - name: 다중 연결 분산
    type: load-balance
    proxies:
      - 노드-A
      - 노드-B
      - 노드-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashing과 round-robin

전략 값	분배 방식	선택 기준
`consistent-hashing`	대상 주소 정보를 바탕으로 일관성 해싱을 적용해 같은 대상은 대체로 같은 노드에 연결	같은 대상의 출구가 자주 바뀌는 것을 줄이고 싶을 때 고려
`round-robin`	새 연결을 사용 가능한 구성원에 순서대로 분배	출구가 여러 개여도 괜찮은 개별 연결 작업에 적합

라운드 로빈을 사용하면 같은 웹사이트에 새로 연결할 때도 서로 다른 출구 IP를 사용할 수 있습니다. 로그인 보안 확인이 엄격한 서비스, 결제 페이지, IP 일관성이 필요한 API에는 바로 적용하지 않는 편이 좋습니다. 일관성 해싱은 출구 변경을 줄일 수 있지만, 구성원 상태나 노드 목록이 바뀌면 출구가 항상 고정된다고 보장할 수 없습니다.

세 노드가 동일한 상위 회선의 병목을 공유한다면 연결을 분산해도 사용 가능한 대역폭이 저절로 늘어나지는 않습니다. 효과를 확인할 때는 구성원 세 개의 테스트 지연 시간만 보지 말고 연결 화면에 표시된 실제 노드와 대상 사이트의 처리량, 실패율을 함께 살펴보세요.

자동 그룹을 규칙에 연결하고 수동 선택 경로 유지하기

세 가지 자동 그룹을 함께 구성하고 select 그룹에서 현재 사용할 전략을 선택할 수 있습니다. 이렇게 하면 웹 서핑, 주·예비 회선, 다중 연결 작업에 맞춰 전환할 때 규칙을 계속 수정할 필요가 없습니다. 아래 내용은 앞서 정의한 세 그룹과 합쳐야 하며, 단독으로 불러올 수 있는 전체 설정이 아닙니다.

proxy-groups:
  - name: 프록시 출구
    type: select
    proxies:
      - 자동 저지연
      - 주 회선 장애 전환
      - 다중 연결 분산
      - 노드-A
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,프록시 출구
  - MATCH,프록시 출구

여기서 MATCH는 기본 규칙에서 전략 그룹을 참조하는 방법을 보여주는 예시일 뿐, 완성된 국내외 분기 설정이 아닙니다. 기존 구독에는 보통 로컬 네트워크, 중국 본토 사이트, 규칙 목록에 대한 규칙이 더 포함되어 있습니다. 기존 분기 설정은 유지하고 프록시가 필요한 규칙의 대상만 ‘프록시 출구’로 바꾸세요. 규칙은 위에서 아래로 순서대로 적용되므로 포괄적인 규칙을 너무 앞에 두면 뒤쪽 규칙이 적용되지 않을 수 있습니다.

현재 작동하는 설정을 백업하고 세 자동 그룹과 구성원 이름을 코어가 인식하는지 먼저 확인합니다.
클라이언트의 프록시 또는 전략 그룹 화면에서 ‘프록시 출구’를 ‘자동 저지연’ 같은 대상 그룹으로 설정합니다. 이름과 메뉴 위치는 클라이언트에 따라 다를 수 있습니다.
규칙 모드에서 테스트 사이트에 접속한 뒤 연결 상세 정보에서 적용된 규칙과 전략 경로, 최종 노드를 확인합니다.
다른 전략 그룹을 선택한 뒤 새 연결을 만들어 확인하세요. 기존 연결은 계속 이전 노드를 사용할 수 있으므로 페이지를 한 번 새로고침하는 것만으로 판단하면 안 됩니다.

앱 트래픽이 프록시를 거치는지 먼저 확인하려면 시스템 프록시 설정 안내에 따라 트래픽 처리 방식을 점검한 다음 지연 시간 테스트 안내에서 그룹 상태를 확인하세요. 규칙 적용 여부를 확인하는 대신 전역 모드로 전환하지 마세요.

자주 발생하는 설정 오류: 간격, 구성원 출처, 구독 덮어쓰기

interval을 밀리초 단위로 입력하는 경우

interval: 300000은 5분이 아니라 300000초를 뜻합니다. 5분마다 검사하려면 300으로 설정하세요. ‘더 빠른 반응’을 위해 1로 설정하는 것도 권장하지 않습니다. 노드가 많을수록 요청 부담이 커지며, 검사를 자주 해도 노드 자체의 혼잡은 해결되지 않습니다.

노드 이름만 입력하고 설정에 해당 구성원이 없는 경우

proxies에는 구독 링크가 아니라 기존 노드나 전략 그룹의 이름을 지정합니다. 대소문자와 공백, 기호까지 정확히 일치해야 합니다. 그룹끼리 순환 참조를 만들어서도 안 됩니다. 예를 들어 ‘프록시 출구’에 ‘자동 저지연’을 포함하고, 다시 ‘자동 저지연’에 ‘프록시 출구’를 포함하는 설정은 사용할 수 없습니다.

노드가 proxy-providers에서 제공된다면 use로 이미 정의된 제공자를 참조할 수 있습니다. 예: use: [구독 노드]. ‘구독 노드’는 기존 제공자 키 이름과 일치해야 합니다. 제공자의 health-check와 그룹 내부 검사는 서로 다른 설정 계층에 있으므로, 그룹 검사 간격을 바꾸면 모든 제공자의 검사도 함께 바뀐다고 가정하지 마세요.

구독 업데이트 후 사용자 지정 전략 그룹이 사라지는 경우

원격 구독으로 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써지는 경우가 많습니다. 클라이언트에서 지원하는 덮어쓰기, 병합 또는 확장 설정 기능을 우선 사용하세요. 해당 기능의 위치와 지원 여부는 클라이언트마다 다릅니다. 저장 후 설정을 검사하고 구독도 한 번 업데이트해 그룹 정의와 규칙 참조, 수동 노드 선택 경로가 유지되는지 확인하세요.

전략 선택 결론: 필요한 안정성에 맞춰 자동화 수준 결정

일상적인 웹 서핑과 범용 프록시: url-test, 300초 간격, 50ms 허용치로 시작하고 노드가 자주 전환되는지 살펴보세요.
주 회선과 예비 회선을 고정해 사용: fallback을 선택하고 주 노드를 목록 첫 번째에 둔 뒤 장애와 복구 상황을 직접 테스트하세요.
여러 대상에 접속하거나 연결이 많은 작업: load-balance를 고려하고 먼저 일관성 해싱을 사용한 다음, 작업 특성상 라운드 로빈을 사용할 수 있는지 판단하세요.
계정 세션과 고정 출구 IP: select에 개별 노드를 직접 선택하는 항목을 남겨 두세요. 필요하면 관련 도메인만 별도의 고정 전략으로 연결하세요.

전략 그룹은 모든 상황에서 가장 낮은 테스트 수치를 추구하는 기능이 아니라, 실제 작업에 맞는 라우팅을 구성하기 위한 기능입니다. 언제든 되돌릴 수 있는 설정을 보관하고 한 번에 옵션 하나씩 변경한 다음 새 연결에서 최종 출구를 확인해야 설정 변경과 사용 경험의 차이를 정확히 비교할 수 있습니다.