2026-08-24 설정 가이드 읽는 데 약 10분

Clash 프록시 그룹 선택 가이드: url-test·fallback·load-balance 설정과 활용법

url-test, fallback, load-balance의 작동 방식과 interval, tolerance, strategy 설정을 설명하고 안정성·전환 빈도·다중 회선 사용 목적에 맞는 구성 예시를 소개합니다.

세 가지 프록시 그룹: 지연 시간·우선순위·연결 분배 기준

Clash 프록시 그룹은 규칙에 일치한 연결을 어느 출구로 보낼지 결정합니다. 규칙이 연결을 그룹에 전달하면 그룹이 후보 노드 중 하나를 선택합니다. 프록시 그룹을 자동 테스트 방식으로 바꿔도 도메인 규칙이 자동으로 수정되지는 않으며, 기존에 DIRECT로 연결되던 트래픽이 프록시로 전환되지도 않습니다.

url-test는 테스트 지연 시간이 낮은 출구를 자동으로 선택할 때 적합합니다. fallback은 명확한 주·백업 순서를 유지할 때, load-balance는 여러 출구에 연결을 분배할 때 사용합니다. 세 그룹은 성능 등급이 다르다는 뜻이 아닙니다. 지연 시간, 출구 안정성, 다중 회선 활용도 등 실제 요구 사항에 따라 선택하세요.

유형	선택 기준	사용 사례	주요 제한 사항
`url-test`	테스트 결과와 전환 허용 오차	일상적인 웹 탐색에서 지연 시간이 낮은 회선을 자동 선택	테스트 지연 시간이 낮아도 다운로드 속도가 빠르다는 뜻은 아닙니다
`fallback`	후보 목록의 순서와 사용 가능 상태	주 회선을 고정하고 장애가 발생하면 백업 회선 사용	주 회선이 복구되면 다시 전환될 수 있습니다
`load-balance`	분배 알고리즘과 연결 상태	여러 대상에 접속하거나 여러 연결을 동시에 사용하는 작업	단일 연결을 여러 회선으로 나눠 대역폭을 합산하지 않습니다

url-test: tolerance로 전환 빈도 조절하기

url-test는 후보 노드에서 지정된 테스트 주소로 요청을 보내고, 측정 결과를 바탕으로 출구를 선택합니다. ICMP ping이나 대역폭 테스트와는 다릅니다. 측정 시간은 프록시 연결, 대상 사이트의 응답, 네트워크 상태에 따라 달라지므로 동일한 테스트 주소로 후보 노드를 비교해야 합니다.

기본 설정과 매개변수 단위

아래는 전체 구독 설정이 아닌 설정 일부입니다. 현재 설정의 proxies에 ‘홍콩-01’, ‘홍콩-02’, ‘일본-01’ 노드가 정의되어 있다고 가정합니다. 적용할 때는 실제로 등록된 노드 이름과 정확히 일치하도록 바꾸세요. 최상위 proxy-groups를 새로 만들지 말고 기존 목록에 항목을 추가하세요.

proxy-groups:
  - name: 자동 저지연
    type: url-test
    proxies:
      - 홍콩-01
      - 홍콩-02
      - 일본-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

url: 상태 확인에 사용할 HTTP 또는 HTTPS 주소입니다. 응답이 짧은 테스트 엔드포인트를 사용하고, 로그인이 필요한 서비스 페이지는 지정하지 마세요.
interval: 300: 300초, 즉 5분마다 주기적으로 테스트합니다. 300밀리초가 아닙니다.
tolerance: 50: 전환 허용 오차는 50밀리초입니다. 후보 노드의 성능 차이가 작을 때 잦은 전환을 막는 데 사용합니다.
lazy: false: 그룹을 사용하지 않는 동안에도 주기적인 테스트를 계속합니다. 상태를 관찰하고 비교하기 편리하지만 테스트 요청이 늘어납니다.

허용 오차는 지연 시간 상한이 아닙니다

가상의 수치로 살펴보겠습니다. 현재 노드의 지연 시간은 180밀리초, 다른 노드는 155밀리초로 차이는 25밀리초입니다. 허용 오차를 50밀리초로 설정했다면 매번 두 번째 노드로 전환되리라고 기대해서는 안 됩니다. 다른 노드의 지연 시간이 100밀리초로 낮아져 차이가 커지면 전환 조건에 더 가까워집니다. 실제 선택은 해당 테스트 결과와 노드의 사용 가능 여부에도 영향을 받습니다.

tolerance는 ‘지연 시간이 50밀리초를 넘으면 사용할 수 없다’는 뜻이 아니며, 회선 지연 시간이 항상 특정 값 이하로 유지된다는 보장도 아닙니다. 일상적인 웹 탐색에서는 먼저 간격 300초, 허용 오차 50밀리초로 설정해 살펴보세요. 출구가 계속 바뀐다면 허용 오차를 키우기 전에 노드 품질과 테스트 대상을 확인하세요. 테스트 간격을 몇 초로 줄이는 것만으로 해결하려 하지 마세요.

fallback: 목록 순서에 따라 주·백업 노드 설정하기

fallback은 목록에서 앞쪽에 있고 상태 검사에 통과한 노드를 우선 사용합니다. 모든 노드 중 지연 시간이 가장 짧은 것을 찾는 방식은 아닙니다. 두 번째 노드의 지연 시간이 80밀리초이고 첫 번째 노드가 160밀리초여도, 첫 번째 노드를 사용할 수 있다고 판단하는 동안에는 주·백업 그룹이 첫 번째 노드를 우선 사용합니다.

proxy-groups:
  - name: 주·백업 출구
    type: fallback
    proxies:
      - 홍콩-01
      - 일본-01
      - 홍콩-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

여기서는 ‘홍콩-01’이 기본 노드, ‘일본-01’이 첫 번째 백업 노드, ‘홍콩-02’가 두 번째 백업 노드입니다. 특정 지역으로 고정해야 하는 서비스라면 해당 지역에 맞는 노드만 목록에 넣으세요. 서로 다른 지역을 백업 목록에 섞으면 가용성이 높아질 수 있지만, 서비스 지역이나 언어 설정, 로그인 위험 관리 상태가 달라질 수 있습니다.

장애 조치는 세션 이전을 의미하지 않습니다

상태 확인에는 시간이 걸립니다: 간격을 300초로 설정해도 장애 발생 즉시 전환되는 것은 아닙니다. 실제 감지 시간은 테스트 시점, 시간 초과, 연결 발생 여부에 따라 달라집니다.
주 노드로 되돌아갈 수 있습니다: 목록에서 앞에 있는 노드가 복구되면 이후 연결은 해당 노드를 다시 사용할 수 있습니다. 백업 노드에 영구히 머무는 것은 아닙니다.
기존 연결은 다른 노드로 옮겨가지 않습니다: 기존 노드에 장애가 생기면 전송 중인 연결이 끊길 수 있으며, 앱에서 다시 연결해야 할 수 있습니다. 프록시 그룹은 TCP 세션 이전을 지원하지 않습니다.

원격 관리나 장시간 업로드처럼 출구를 고정하는 것이 중요한 작업에는 수동 select 또는 순서가 명확한 fallback을 고려할 수 있습니다. 작업 중 출구가 바뀌면 안 되는 경우에는 자동 주·백업 설정만으로 충분하지 않습니다. 앱 자체의 재연결, 이어받기, 세션 복구 기능도 필요합니다.

load-balance: 연결 분배 방식이며 단일 연결 대역폭을 합치지 않습니다

load-balance는 여러 후보 출구에 연결을 분배합니다. TCP 연결 하나를 둘로 나눠 두 노드에 보내는 방식이 아니므로, 한 번의 다운로드에 회선 세 개를 추가한다고 속도가 세 배로 늘어나지는 않습니다. 여러 작업이나 여러 대상에 접속할 때 효과가 있는지는 분배 정책, 각 회선의 용량, 대상 사이트의 제한에 따라 달라집니다.

proxy-groups:
  - name: 다중 회선 분배
    type: load-balance
    proxies:
      - 홍콩-01
      - 홍콩-02
      - 일본-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashing과 round-robin

strategy 값	분배 방식	사용 권장 사항
`consistent-hashing`	대상 정보를 바탕으로 일관된 해시를 계산해 같은 대상은 보통 같은 출구로 연결	같은 대상에 대한 출구 변경을 줄이고 싶은 다중 사이트 일상 접속
`round-robin`	사용 가능한 후보에 연결을 차례대로 분배	출구가 바뀌어도 괜찮은 다중 연결 작업

일관성 해시의 기준에는 대체로 대상 도메인의 등록 가능한 주 도메인이 포함됩니다. 대상이 IP 주소인 경우에는 해당 주소 정보를 기준으로 처리합니다. 구체적인 동작은 사용하는 코어의 구현을 확인하세요. 계정과 연관된 모든 도메인이 같은 출구를 사용한다고 보장하지는 않습니다. 로그인, 결제, API 도메인이 각각 다른 출구로 연결될 수 있으며, 노드 목록이 바뀌면 매핑 결과도 달라질 수 있습니다.

순환 분배를 사용하려면 예시에서 정책을 strategy: round-robin으로 바꾸세요. 순환 분배가 ‘모든 요청을 균등하게 나눈다’는 뜻은 아닙니다. 여러 HTTP 요청이 하나의 TCP 또는 QUIC 연결을 재사용할 수 있으며, 연결 분배는 요청 단위 분배와 다릅니다. 결제나 계정 관리에는 출구를 고정하는 편이 적합합니다. 여러 회선을 활용하려는 목적으로만 부하 분산을 강제로 적용하지 마세요.

규칙 연결: 트래픽이 자동 프록시 그룹을 사용하도록 설정하기

프록시 그룹을 정의하는 것만으로는 충분하지 않습니다. 규칙이 기존 그룹을 계속 가리키면 새 그룹은 해당 연결을 처리하지 않습니다. 아래 예시에서는 수동 선택 그룹을 전체 진입점으로 사용하고, 세 가지 자동 정책과 직접 연결 옵션을 함께 두어 클라이언트에서 동작을 비교할 수 있게 합니다.

proxy-groups:
  - name: 프록시 진입점
    type: select
    proxies:
      - 자동 저지연
      - 주·백업 출구
      - 다중 회선 분배
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,프록시 진입점
  - MATCH,프록시 진입점

여기에는 진입점 항목과 규칙만 표시되어 있습니다. 앞서 정의한 자동 그룹과 합쳐서 사용해야 합니다. example.com은 규칙 매칭을 보여 주기 위한 예시 도메인이며 실제 서비스용이 아닙니다. MATCH는 앞선 규칙에 일치하지 않은 연결을 처리합니다. 실제 설정에서는 기존 LAN, 직접 연결, 서비스별 규칙을 유지하고 기본 처리 규칙을 맨 마지막에 두세요. 이 간단한 예시로 전체 분기 설정을 덮어쓰지 마세요.

클라이언트의 설정 편집 메뉴나 덮어쓰기 기능에서 설정을 병합하고 YAML 들여쓰기를 확인하세요. 목록 항목에는 공백을 사용하고 Tab은 사용하지 마세요.
설정을 다시 불러온 뒤 자동 그룹 세 개와 ‘프록시 진입점’이 모두 표시되는지 확인하세요. ‘프록시를 찾을 수 없음’ 또는 프록시 그룹 순환 참조 오류가 없어야 합니다.
프록시 그룹 화면에서 ‘프록시 진입점’을 펼친 다음, 기존 수동 노드에 머무르지 말고 테스트할 자동 그룹을 선택하세요.
새 연결을 만든 다음 연결 목록에서 일치한 규칙과 프록시 체인을 확인하고, 최종 출구가 예상한 대로인지 점검하세요.

테스트 결과 해석: 지연 시간, DNS, TUN의 한계

속도 테스트는 정상이지만 서비스가 작동하지 않을 때

테스트 주소에 연결된다는 것은 해당 회선으로 해당 주소에 요청을 보낼 수 있다는 뜻일 뿐, 모든 사이트에 접속할 수 있다는 의미는 아닙니다. 출구 지역, 대상 사이트의 차단, 인증서 문제, DNS 조회 오류로 서비스가 작동하지 않을 수 있습니다. 이럴 때는 먼저 진입점을 단일 노드로 고정해 서비스를 다시 시도하고 연결 로그를 확인하세요. 자동 그룹 알고리즘의 오류라고 바로 단정하지 마세요.

HTTPS 테스트에는 연결 설정과 TLS 통신에 걸리는 시간도 포함될 수 있습니다. mihomo의 최상위 unified-delay 설정은 프록시 핸드셰이크 차이가 지연 시간 비교에 미치는 영향을 줄이는 데 사용할 수 있습니다. 이 설정은 프록시 그룹 내부의 필드가 아닙니다. 측정값을 비교할 때는 해당 설정, 테스트 URL, 네트워크를 동일하게 유지하세요. 서로 다른 조건에서 얻은 수치를 그대로 순위 매기지 마세요.

TUN은 프록시 그룹의 선택 알고리즘을 바꾸지 않습니다

시스템 프록시나 TUN은 트래픽이 코어에 들어가는 방식을 결정하고, 규칙은 어느 그룹에 전달할지 정하며, 프록시 그룹은 출구를 선택합니다. TUN을 켜도 fallback이 지연 시간이 가장 낮은 노드를 자동 선택하지 않으며, load-balance에 대역폭 결합 기능이 추가되지도 않습니다. 앱의 연결이 코어 연결 목록에 보이지 않는다면 tolerance를 수정하기보다 트래픽이 코어로 전달되는 경로부터 확인하세요.

Fake-IP를 사용하면 코어가 주소 매핑을 통해 도메인 매칭 정보를 유지할 수 있지만, 그렇다고 프록시 그룹의 상태 검사를 대신하는 것은 아닙니다. 노드 서버가 도메인 이름을 사용하는 경우에는 DNS 조회 경로도 작동하는지 확인하세요. 프록시 연결에 필요한 DNS 요청을 같은 프록시에 의존해 처리하는 상황은 피해야 합니다. DNS 장애로 모든 자동 그룹 노드가 시간 초과되는 것처럼 보일 수 있으므로 DNS 로그도 함께 확인하세요.

설정 적용: 보수적인 값부터 확인하기

처음 설정할 때는 interval: 300으로 통일하고, 문제를 확인하는 동안에는 lazy: false로 설정한 뒤 동작을 확인하고 나서 기기 배터리 사용 시간과 노드 수에 맞게 조정할 수 있습니다. 그룹에 노드가 12개 있고 노드마다 회당 최소 한 번씩 테스트한다고 가정하면, 5분마다 한 차례씩 테스트할 경우 시간당 약 144회입니다. 추가 테스트, 재시도, 수동 속도 측정에 따라 실제 요청 수는 달라지므로 이를 트래픽 요금의 확정 수치로 간주하지 마세요.

낮은 지연 시간을 우선: url-test를 선택하고 허용 오차를 먼저 50밀리초로 설정한 뒤, 새 연결의 출구가 지나치게 자주 바뀌는지 살펴보세요.
주 회선을 우선: fallback을 선택하고 우선 사용할 노드를 목록 맨 앞에 배치하세요. 백업 노드의 지역과 용도도 확인해야 합니다.
여러 회선을 함께 사용: load-balance를 선택하고 먼저 일관성 해시를 사용해 보세요. 출구가 바뀌어도 괜찮은 서비스에서만 순환 분배를 사용하세요.
세션 고정을 우선: 수동 select 진입점을 유지하고 로그인, 결제, 장시간 작업에는 안정적인 노드를 지정하세요.

확인할 때는 한 번에 변수 하나만 바꾸세요. 먼저 노드와 테스트 주소를 고정하고 정책 유형을 바꾼 뒤, 마지막으로 간격과 허용 오차를 조정합니다. 테스트 주기를 최소 두 번 온전히 지켜본 다음 새 연결, 장시간 다운로드, 실제 서비스 페이지를 각각 확인하세요. 현재 네트워크에 적합한 설정인지는 한 번의 속도 테스트에서 가장 낮은 수치보다 선택 결과, 서비스 성공률, 연결 안정성으로 판단하는 편이 정확합니다.