Clash 프록시 그룹 url-test·fallback·load-balance 차이와 설정법

목표에 맞는 그룹 선택: 낮은 지연 시간, 우선순위 고정, 연결 분산

url-test는 사용 가능한 노드 중 탐지 지연 시간이 낮은 노드를 선택합니다. fallback은 설정 순서대로 첫 번째 사용 가능한 노드를 선택하고, load-balance는 지정한 알고리즘에 따라 여러 연결을 분배합니다.세 방식 모두 상태 확인을 사용할 수 있지만, 노드의 가용성을 확인하는 것과 연결을 어느 노드에 보낼지 결정하는 것은 별개입니다. 자동 탐지를 지원한다고 해서 모두 가장 빠른 노드를 자동 선택한다고 생각하면 안 됩니다.

유형	선택 기준	적합한 목적	주요 제한 사항
`url-test`	탐지 URL의 지연 시간과 전환 허용치	일상적인 웹 탐색에서 응답이 빠른 노드 자동 선택	탐지 지연 시간은 다운로드 대역폭과 다릅니다
`fallback`	후보 순서와 사용 가능 여부	주 회선을 고정하고 장애 시 예비 회선으로 전환	뒤에 배치된 지연 시간이 짧은 노드는 우선 선택되지 않습니다
`load-balance`	해시, 라운드 로빈 등의 분배 알고리즘	여러 연결을 서로 다른 노드에 분배	단일 연결의 대역폭을 여러 노드의 대역폭으로 합산하지 않습니다

예를 들어 세 노드의 탐지 결과가 각각 HK-A 90ms, HK-B 65ms, JP-A 130ms라고 가정해 보겠습니다. 자동 속도 측정 그룹은 전환 조건을 충족하면 HK-B를 선택하는 경향이 있습니다. 장애 전환 그룹의 순서가 HK-A, HK-B, JP-A라면 상태가 정상인 HK-A를 계속 사용합니다. 부하 분산 그룹은 서로 다른 대상의 연결을 각기 다른 노드로 보낼 수 있습니다. 수치는 선택 과정을 설명하기 위한 예시일 뿐, 실제 회선 측정 결과나 속도를 보장하지 않습니다.

url-test 설정: tolerance로 작은 지연 시간 변동에 따른 전환 제한

url-test는 후보 노드를 통해 지정한 URL에 접속하고 요청에 걸린 시간을 노드 선택 기준으로 사용합니다. 노드 서버에 ICMP ping을 한 번 보내는 방식은 아닙니다. 결과는 노드 핸드셰이크, 출구 회선, 대상 사이트, 연결 재사용 등의 영향을 받습니다. 따라서 테스트 주소는 안정적이어야 하며 실제 접속 방향을 잘 반영하는 주소를 선택하는 것이 좋습니다.

proxy-groups:
  - name: 자동 속도 측정
    type: url-test
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

세 가지 옵션의 단위부터 확인하기

interval: 300: 탐지 간격은 300초, 즉 5분입니다. 300밀리초가 아닙니다.
tolerance: 50: 전환 허용치는 50밀리초입니다. 작은 지연 시간 변동으로 인한 전환을 줄이기 위한 값이며, 요청 시간 제한이 아닙니다.
lazy: true: 지연 탐지를 활성화합니다. 그룹을 사용하지 않을 때 주기적인 탐지가 일시 중지될 수 있습니다. 앱에서 요청을 보낼 때마다 먼저 속도 측정을 한다는 뜻은 아닙니다.

현재 노드의 지연 시간이 약 90ms이고 다른 노드가 약 65ms라면 차이는 25ms입니다. 허용치를 50ms로 설정하면 곧바로 다른 노드로 전환될 것으로 기대하기 어렵습니다. 다른 노드의 지연 시간이 약 30ms로 낮아져야 전환 조건에 가까워집니다. 실제 선택은 현재 노드의 유효 여부와 탐지 결과의 갱신 여부에도 영향을 받습니다. 현재 노드를 사용할 수 없다면 허용치 때문에 장애 노드를 계속 유지한다고 해석해서는 안 됩니다.

일상적인 사용이라면 간격 300초, 허용치 50ms부터 시작해 동작을 살펴보세요. 간격을 5초로 줄이면 대개 탐지 요청과 모바일 네트워크 깨우기 횟수, 서버 부담만 늘어납니다. 허용치를 0으로 설정하면 몇 밀리초의 차이에도 후속 연결의 출구가 자주 바뀔 수 있습니다. 세션 안정성이 중요하다면 화면에 표시되는 최솟값을 쫓기보다 불필요한 전환을 줄이는 것이 우선입니다.

fallback 설정: 노드 순서가 우선순위

fallback의 핵심은 ‘가장 빠른 노드 선택’이 아니라 ‘위에서부터 확인해 처음으로 정상인 노드 선택’입니다. 주 회선이 정상이라면 예비 회선의 지연 시간이 더 짧아도 주 회선보다 먼저 선택되지 않습니다. 지역이나 출구를 고정하거나 비용 우선순위가 중요한 경우에 적합합니다.

proxy-groups:
  - name: 주·예비 회선
    type: fallback
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

HK-A와 HK-B가 모두 정상이면 HK-A를 우선 선택합니다.
상태 확인 결과 HK-A를 사용할 수 없고 HK-B는 사용 가능하면 이후 연결에는 HK-B를 사용합니다.
이후 상태 확인에서 HK-A가 복구된 것으로 확인되면 그룹은 다시 HK-A를 우선 선택합니다.

여기서 ‘복구’ 여부는 상태 확인 결과에 따라 판단합니다. 확인 간격이 300초라고 해서 모든 장애가 1초 안에 전환되는 것도, 반드시 정확히 300초를 기다려야 하는 것도 아닙니다. 수동 테스트, 클라이언트의 동작 방식, 코어 구현에 따라 상태 갱신 시점이 달라질 수 있습니다. 진행 중인 TCP 세션은 예비 서버로 자동 이전되지 않습니다. 연결이 끊긴 다운로드, SSH, 동영상 연결은 앱에서 다시 연결해야 합니다.

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

load-balance는 여러 정상 노드에 연결을 분배합니다. 패킷을 하나씩 번갈아 보내는 방식도, 100Mbps 회선 세 개를 자동으로 합쳐 300Mbps 터널 하나를 만드는 방식도 아닙니다. 단일 TCP 연결은 선택된 노드를 통해 계속 전송됩니다. 앱이 여러 연결을 생성할 때 여러 노드가 동시에 트래픽을 처리할 수 있습니다.

proxy-groups:
  - name: 연결 분산
    type: load-balance
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

consistent-hashing과 round-robin 중 무엇을 선택할까요?

consistent-hashing: 대상 정보를 바탕으로 일관된 해시를 계산해 같은 대상이 동일한 출구를 사용하도록 하는 방식입니다. 구체적인 해시 키는 코어 구현과 도메인 정보를 사용할 수 있는지에 따라 달라집니다. 모든 계정 세션이 영구적으로 같은 노드에 고정된다는 뜻은 아닙니다.
round-robin: 연결을 순서대로 번갈아 분배합니다. 여러 연결이 분산되는지 확인할 때 사용할 수 있지만, 같은 사이트의 연결도 서로 다른 출구를 이용할 수 있습니다.

라운드 로빈이 필요하다면 예시의 마지막 줄을 strategy: round-robin으로 바꾸면 됩니다. 그룹 전체를 다시 작성할 필요는 없습니다. 다운로드 하나의 속도가 빨라졌는지만으로 부하 분산 여부를 판단하지 마세요. 클라이언트의 연결 목록에서 여러 대상과 새 연결이 실제로 어떤 프록시 경로를 사용하는지 확인하는 편이 직접적입니다.

일관된 해시를 사용하더라도 한 웹페이지가 로그인, 이미지, API, 인증 문자 등의 여러 도메인에 동시에 접속할 수 있으며, 각 도메인이 같은 노드로 연결된다는 보장은 없습니다. 지역 제한, 계정 보안, 접속 IP 일관성이 중요한 서비스에는 지역이 다른 노드 간 부하 분산을 바로 적용하지 않는 것이 좋습니다. 노드 구성이나 상태가 바뀌면 기존 매핑이 다시 분배될 수도 있습니다.

중첩 select 그룹: 수동 전환과 규칙 기반 출구 유지

자동 그룹이 모든 트래픽의 진입점이 될 필요는 없습니다. 유지 관리가 쉬운 구성은 바깥쪽 select가 사용 모드를 선택하고, 안쪽 그룹이 각각 자동 속도 측정, 주·예비 전환, 연결 분산을 담당하는 방식입니다. 탐지에 문제가 생겨도 그룹 유형을 임시로 바꾸지 않고 클라이언트 화면에서 특정 노드로 바로 전환할 수 있습니다.

아래는 앞의 세 가지 개별 예시를 대체할 수 있는 통합 설정입니다. 모든 후보 이름은 기존 노드나 정의된 정책 그룹으로 확인되어야 합니다. ‘프록시 출구’를 하위 그룹의 후보로 지정하면 순환 참조가 발생하므로 주의하세요.

proxy-groups:
  - name: 프록시 출구
    type: select
    proxies:
      - 자동 속도 측정
      - 주·예비 회선
      - 연결 분산
      - HK-A
      - HK-B
      - JP-A

  - name: 자동 속도 측정
    type: url-test
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 주·예비 회선
    type: fallback
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

  - name: 연결 분산
    type: load-balance
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

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

노드가 proxy-providers에서 제공되는 경우, 지원되는 그룹에서 use로 기존 provider를 가져올 수 있습니다. provider 이름을 노드처럼 proxies에 넣으면 안 됩니다. provider의 health-check 설정도 확인하세요. provider 노드의 상태 확인은 해당 제공자 쪽에 올바르게 설정해야 합니다. 그룹에 url을 적었다고 모든 출처의 노드가 예상대로 탐지되는 것은 아닙니다.

구독을 업데이트하면 직접 편집한 설정이 덮어써질 수 있습니다. 수정 전에 백업하고 클라이언트가 로컬 오버라이드, 설정 병합, 임시 편집 중 어떤 방식을 제공하는지 확인하세요. 여기서 다루는 내용은 코어의 YAML 구조이므로 모든 클라이언트에 동일한 ‘설정’ 메뉴가 있다고 가정할 수 없습니다. 기본 가져오기 방법은 입문 가이드를, 규칙과 DNS의 관계는 고급 설정에서 확인하세요.

적용 후 네 단계로 확인해 ‘그룹은 바뀌는데 트래픽은 그대로’인 상황 방지

설정이 정상적으로 불러와졌는지 확인합니다. 다시 불러온 후 먼저 오류 로그를 확인하세요. 노드 이름의 대소문자, 잘못된 들여쓰기, 알 수 없는 정책 유형, 최상위 키 중복 때문에 새 설정이 적용되지 않을 수 있습니다. 화면에 이전 그룹이 계속 표시된다면 먼저 설정 로드 문제를 해결하세요.
모드와 규칙이 일치하는지 확인합니다. Proxies에서 현재 선택된 외부 그룹을 확인하고, Rules에서 대상 규칙을 확인한 다음 Logs나 연결 상세 정보에서 최종 경로를 확인하세요. 규칙 모드에서만 rules에 따라 트래픽이 분기됩니다. 전역 모드에서는 특정 도메인용으로 설정한 진입점을 우회할 수 있습니다.
직접 테스트하고 결과를 기록합니다. 그룹 테스트를 수동으로 실행하고 시간, URL, 노드 지연 시간, 최종 선택 노드를 기록하세요. 전후 결과를 비교할 때는 같은 테스트 주소를 사용해야 합니다. 목적지가 다른 두 주소의 지연 시간을 같은 기준처럼 비교하지 마세요.
새 연결로 다시 확인합니다. 그룹을 전환한 뒤에도 기존 연결은 이전 노드에 남아 있을 수 있습니다. 새 명령줄 요청을 보내거나 테스트 앱의 연결을 종료한 후 다시 시도하고 프록시 경로를 확인하세요. 페이지를 새로고침한 뒤 체감한 속도만으로 판단하지 마세요.

curl로 브라우저 연결 재사용의 영향 확인하기

로컬 HTTP 또는 mixed 프록시가 127.0.0.1:7890에서 대기 중이라고 가정하면 아래 명령을 실행할 수 있습니다. 포트는 클라이언트의 현재 설정에 따라야 합니다. 7890이 SOCKS 전용 포트라면 HTTP 프록시 프로토콜을 그대로 사용하면 안 됩니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --head https://example.com/

Windows PowerShell에서는 일부 환경에서 명령 별칭이 다르게 동작할 수 있으므로 명령 앞부분을 curl.exe로 바꾸면 됩니다. 이 요청은 앞에서 설정한 example.com 규칙에 해당하며, 로그와 함께 확인하면 ‘프록시 출구’를 통과하는지 점검할 수 있습니다. 해당 대상의 요청 경로와 응답만 확인하는 방법이며 모든 웹사이트, UDP 트래픽, TUN 처리까지 정상임을 의미하지는 않습니다.

TUN을 활성화하면 가상 네트워크 인터페이스가 연결을 처리할 수 있지만, 최종적으로 어떤 정책 그룹을 사용할지는 작업 모드와 규칙에 따라 결정됩니다. TUN을 켜도 fallback이 속도 측정 그룹으로 바뀌지 않으며, load-balance가 단일 연결의 대역폭을 자동으로 합산하지도 않습니다.

자주 발생하는 문제: 탐지 결과를 먼저 확인한 뒤 옵션 조정

모든 속도 측정이 timeout인데 일부 사이트는 열리는 경우

대개 ‘테스트 URL에 연결할 수 없음’과 ‘모든 서비스에 연결할 수 없음’을 구분하지 못한 상황입니다. 먼저 테스트 주소의 DNS와 TLS, 노드 출구에서의 접속 여부를 확인한 뒤 작은 응답을 정상적으로 반환하는 다른 HTTPS 주소로 교차 검증하세요. 로그인이나 리디렉션 인증이 필요하거나 요청 제한이 있는 서비스의 메인 페이지를 장기 상태 확인 주소로 사용하지 마세요.

url-test가 계속 이전 노드를 선택하는 경우

먼저 그룹이 사용 중인지, 지연 탐지 설정이 갱신을 막고 있는지, 지연 시간 차이가 tolerance를 넘는지 확인하세요. 현재 연결이 이미 만들어진 상태인지도 살펴보세요. 화면에 다른 노드가 10ms 빠르게 표시되고 허용치가 50ms라면 설정 오류가 아닙니다. 탐지 결과가 갱신되고 차이가 충분히 큰데도 새 연결이 예상과 다를 때 코어 버전과 그룹 참조 관계를 추가로 점검하세요.

fallback이 지연 시간이 가장 짧은 예비 노드를 선택하지 않는 경우

순서가 우선인 정상 동작입니다. 주 노드에 장애가 생긴 뒤 예비 노드 중 가장 빠른 회선을 선택하려면 url-test 그룹을 주·예비 그룹의 예비 위치에 넣고, 중첩 후 실제 연결로 선택 결과를 확인할 수 있습니다. 중첩하면 상태 판단이 복잡해지므로 회선이 두세 개뿐이라면 먼저 단순한 구조로 구성하는 편이 문제를 찾기 쉽습니다.

부하 분산 후 사이트에서 로그인을 반복해서 요구하는 경우

먼저 해당 사이트의 트래픽만 노드를 고정하거나 수동 선택 그룹으로 보내고, 새 세션이 안정되는지 확인하세요. 사이트가 여러 도메인을 함께 사용해 지역과 IP를 확인할 수 있으므로 라운드 로빈을 일관된 해시로 바꾸는 것만으로는 해결되지 않을 수 있습니다. 세션 문제를 해결한 뒤에도 해당 서비스에 연결 분산이 필요한지 검토하세요.

최종 선택 기준: 일상적인 웹 탐색에는 적절한 허용치를 설정한 url-test, 주 회선을 고정하려면 fallback, 여러 연결을 분산해야 할 때만 load-balance를 사용하세요. 세 그룹 바깥에 select를 두고 규칙 적용 결과, 상태 확인, 새 연결 로그를 함께 점검하면 속도 측정 간격을 계속 바꾸는 것보다 결과를 이해하고 문제를 찾기 쉽습니다.