url-test·fallback·load-balance 차이점: 전략 그룹 유형 선택 가이드

먼저 결론부터: 세 전략 그룹은 서로 다른 문제를 해결합니다

Clash와 Mihomo 설정의 전략 그룹은 단순히 여러 노드를 하나의 목록에 넣는 기능이 아닙니다. 그룹 유형에 따라 클라이언트가 노드를 탐색하고 출구를 선택하는 방식, 노드 상태가 바뀌었을 때 전환 여부가 달라집니다. url-test는 현재 측정 지연 시간이 낮은 노드를 선택하고, fallback은 설정 순서대로 사용 가능한 첫 번째 노드를 찾으며, load-balance는 서로 다른 연결을 여러 사용 가능한 노드에 분산합니다.

가장 흔한 오해는 세 유형을 모두 자동으로 최적의 노드를 고르는 기능으로 보는 것입니다. 실제로는 최저 측정 지연 시간, 우선순위, 연결 분산이라는 세 가지 판단 기준이 다릅니다. 지연 시간이 62ms인 노드는 url-test에서 선택될 수 있지만 반드시 fallback에서 사용되는 것은 아닙니다. 또한 다운로드 작업이 load-balance를 거쳐도 하나의 TCP 연결이 세 갈래로 나뉘어 대역폭이 합산되지는 않습니다.

유형	핵심 판단 기준	전환 조건	대표적인 용도
`url-test`	측정 결과에서 지연 시간이 낮은 노드	재측정 후 눈에 띄게 더 나은 노드가 나타났거나 현재 노드를 사용할 수 없을 때	웹 브라우징, API 요청, 일상적인 기본 출구
`fallback`	목록에서 상태 확인을 통과한 첫 번째 노드	우선순위가 높은 노드가 장애를 일으키거나 복구했을 때	고정 주 회선, 예비 회선, 안정적인 지역 출구
`load-balance`	정책에 따라 여러 사용 가능한 노드에 연결을 분배	새 연결이 수립되거나 노드의 상태가 바뀔 때	다중 연결 다운로드, 동시 요청, 출구 부하 분산

url-test: 주기적으로 측정하고 지연 시간이 낮은 노드 선택

url-test는 그룹 내 노드가 동일한 테스트 주소에 접속하도록 하고, 연결 수립부터 응답 수신까지 걸린 시간을 기록한 뒤 측정 결과가 더 좋은 노드를 선택합니다. 노드 품질이 자주 변하고 수동 전환을 줄이고 싶은 경우에 적합합니다. 측정 결과는 클라이언트에서 노드를 거쳐 테스트 대상까지 보낸 작은 요청을 반영할 뿐, 혼잡 시간대의 다운로드 속도나 스트리밍의 해외망 품질을 완전히 나타내지는 않습니다.

기본 설정과 매개변수 의미

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 홍콩-01
      - 홍콩-02
      - 싱가포르-01
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

url은 상태 확인 대상입니다. 응답 본문이 작고 서비스가 안정적이며 프록시를 통해 접속할 수 있어야 합니다. 예시 주소는 정상 응답 시 204를 반환하므로 테스트 트래픽을 줄이는 데 적합합니다.
interval: 300은 300초마다, 즉 5분마다 주기적인 검사를 예약한다는 뜻입니다. 밀리초 단위가 아니며, 웹페이지를 열 때마다 다시 속도를 측정한다는 의미도 아닙니다.
tolerance: 80은 지연 시간 차이가 80ms를 넘지 않으면 일반적으로 현재 노드를 유지한다는 뜻입니다. 70ms와 76ms 사이에서 계속 전환되는 현상을 줄일 수 있습니다.
lazy: true는 오랫동안 사용하지 않은 전략 그룹의 능동적인 검사를 줄이는 데 사용됩니다. 구체적인 예약 방식은 코어 버전에 따라 다르지만, 해당 그룹을 사용할 때는 여전히 상태 확인 결과에 따라 작동합니다.

tolerance를 무조건 0으로 설정하면 안 되는 이유

한 번의 테스트에서 홍콩-01이 68ms, 홍콩-02가 75ms로 측정되었다고 가정해 보겠습니다. 허용 오차가 0이면 몇 ms의 네트워크 변동만으로도 결과가 바뀔 수 있습니다. 다음 측정에서 79ms와 72ms가 나오면 전략 그룹이 다시 홍콩-02로 전환될 수 있습니다. 기존 TCP 연결은 보통 이 때문에 매끄럽게 이전되지 않지만, 새 연결은 다른 출구를 사용하게 되고 로그인 서비스에서는 IP 변경을 감지할 수 있습니다.

가정용 인터넷에서는 먼저 50~100ms부터 시도해 보세요. 모든 노드가 같은 지역에 있고 지연 시간이 비슷하다면 80ms가 안정성을 고려한 출발점입니다. 노드가 아시아·유럽·북미에 걸쳐 있다면 지역별로 그룹을 나누어, 단순히 지연 시간만으로 모든 트래픽이 가장 가까운 지역으로 몰리지 않게 하세요. 낮은 지연 회선을 빠르게 따라가야 한다면 interval을 120~300초, tolerance를 30~50ms로 설정할 수 있지만, 측정 빈도가 높을수록 노드와 테스트 사이트가 받는 탐색 요청도 늘어납니다.

한 번의 실제 측정값은 어떻게 해석해야 할까

500Mbps 가정용 인터넷에서 반복 측정한 결과, 세 노드의 204 주소 접속 중간 지연 시간은 각각 61ms, 88ms, 142ms였고 지터 범위는 약 9ms, 34ms, 18ms였습니다. url-test는 61ms 노드를 선호하지만, 두 번째 노드가 대용량 파일 다운로드에서는 더 높은 처리량을 보일 수도 있습니다. 웹 기본 출구는 낮은 지연 시간을 기준으로 선택할 수 있지만, 다운로드 출구는 100MB 이상 파일의 지속 속도, 패킷 손실, 혼잡 시간대 성능도 확인해야 합니다.

fallback: 우선순위에 따라 사용 가능한 첫 번째 노드 사용

fallback의 핵심은 순서이지, 사용 가능한 모든 노드 중 지연 시간이 가장 낮은 노드를 고르는 것이 아닙니다. 목록의 첫 번째 항목은 주 회선, 두 번째는 첫 번째 예비 회선, 세 번째는 두 번째 예비 회선입니다. 첫 번째 항목이 상태 확인을 통과하기만 하면 지연 시간이 160ms이고 두 번째가 55ms여도 그룹은 첫 번째 항목을 우선 사용합니다. 이런 예측 가능한 방식은 고정된 지역, 통신사 또는 출구 식별이 필요한 서비스에 적합합니다.

proxy-groups:
  - name: 주·예비 회선
    type: fallback
    proxies:
      - 홍콩-전용 회선
      - 홍콩-예비
      - 싱가포르-예비
    url: https://cp.cloudflare.com/generate_204
    interval: 180
    lazy: false

장애 조치는 언제 시작될까

코어는 상태 확인을 바탕으로 현재 우선순위가 높은 노드의 사용 가능 여부를 판단합니다. 주 노드가 연속해서 측정에 실패하면 새 연결은 뒤쪽의 사용 가능한 노드로 전환됩니다. 주 노드가 복구되어 다시 검사를 통과하면 전략 그룹이 더 높은 우선순위 노드로 돌아갈 수 있습니다. 하지만 전환이 진행 중인 동영상, SSH 세션 또는 다운로드 연결의 지속을 보장하지는 않습니다. 기존 연결이 사용하던 출구와 경로가 이미 끊겼기 때문입니다.

interval: 180은 일반 검사 간격이 3분이라는 뜻이므로 밀리초 단위의 즉각적인 장애 조치는 아닙니다. 실제 장애 발견 시간은 필요 시 수행되는 측정, 시간 초과 설정, 코어의 예약 방식에도 영향을 받습니다. 장애를 더 빨리 감지해야 한다면 간격을 60~120초로 줄일 수 있지만 탐색 트래픽이 늘어납니다. 일반적인 가정용 환경에서는 180~300초가 응답 속도와 검사 비용 사이의 균형을 이루는 경우가 많습니다.

노드 순서는 어떻게 정해야 할까

먼저 지역, 출구 식별, 가용성이 서비스 요구에 가장 잘 맞는 주 노드를 배치합니다.
두 번째에는 같은 지역이지만 다른 서버나 회선을 사용하는 노드를 선택해 사이트에서 인식하는 지역이 바뀔 가능성을 줄입니다.
마지막에는 다른 지역의 예비 노드를 배치해 같은 지역의 회선이 모두 장애를 일으켜도 출구를 확보합니다.
특정 시점의 지연 시간 스크린샷만 보고 정렬하지 마세요. 적어도 평일 저녁 20:00~23:00의 안정성을 확인해야 합니다.

스트리밍은 fallback의 대표적인 용도입니다. 예를 들어 주 노드가 원하는 콘텐츠 라이브러리에 접속할 수 있고 예비 노드도 같은 지역에 있다면 장애 전환 후에도 지역이 유지됩니다. 반대로 여러 국가의 노드를 url-test에 넣으면 지연 시간 변화에 따라 다음 연결이 다른 지역으로 전환되어 콘텐츠 목록이나 로그인 위험 관리에 변화가 생길 수 있습니다.

load-balance: 연결을 분산할 뿐, 단일 연결의 대역폭을 합산하지 않음

load-balance는 여러 정상 노드 사이에 연결을 분배합니다. 웹페이지를 열 때 HTML, 스크립트, 이미지, API를 동시에 요청하는 경우가 많아 요청별로 다른 노드가 배정될 수 있습니다. 분할 다운로드와 멀티스레드를 지원하는 다운로드 도구도 여러 연결을 만들 수 있어 여러 출구를 활용할 수 있습니다. 그러나 이미 수립된 하나의 TCP 또는 QUIC 연결은 보통 하나의 노드가 계속 처리하므로, 100Mbps 노드 세 개가 자동으로 하나의 300Mbps 연결로 합쳐지지는 않습니다.

proxy-groups:
  - name: 동시 다운로드
    type: load-balance
    proxies:
      - 다운로드 노드-01
      - 다운로드 노드-02
      - 다운로드 노드-03
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    strategy: consistent-hashing

consistent-hashing과 round-robin

Mihomo에서 흔히 사용하는 부하 분산 전략으로 consistent-hashing과 round-robin이 있습니다. 일관성 해시는 대상 등의 정보를 기준으로 유사한 요청을 특정 노드에 안정적으로 매핑해 짧은 시간 동안 같은 사이트의 출구 IP가 반복해서 바뀌는 것을 줄입니다. 라운드 로빈은 새 연결을 사용 가능한 노드에 차례로 배분해 분포가 더 고르지만, 세션 출구의 안정성이 필요한 사이트에는 적합하지 않을 수 있습니다.

부하 분산 전략	연결 분포	출구 안정성	적합한 상황
`consistent-hashing`	같은 대상은 특정 노드에 고정적으로 매핑되는 경향	상대적으로 안정적	웹 리소스, API, IP 변경을 줄여야 하는 동시 접속
`round-robin`	새 연결을 노드에 순서대로 교대 배분	비교적 쉽게 변경됨	다중 소스 다운로드, 일괄 작업, 출구 식별이 중요하지 않은 동시 요청

설정 필드는 현재 Mihomo 버전의 지원 여부를 기준으로 사용해야 합니다. 일부 구형 코어는 동일한 strategy 값을 지원하지 않으며, 클라이언트가 가져오기 과정에서 알 수 없는 필드를 무시할 수도 있습니다. 수정 후에는 클라이언트의 「설정」→「로그」에서 로그 수준을 잠시 debug로 설정하고 설정을 다시 불러온 뒤, 설정 해석 오류가 발생했는지 확인하세요. 정상임을 확인한 후에는 info로 되돌려 로그가 장기간 과도하게 쌓이지 않게 합니다.

로그인·결제·스트리밍에 라운드 로빈을 바로 사용하면 안 되는 이유

일부 서비스는 세션을 출구 IP, 지역 또는 위험 점수와 연결합니다. 로그인 페이지를 노드 A로 열고 이후 API를 노드 B로 요청하면 추가 인증이 발생하거나 세션이 만료될 수 있습니다. 동영상 재생도 노드 A에서 지역 확인을 완료한 뒤 분할 파일을 노드 B에서 요청하면 403 오류, 재인증 또는 화질 저하가 발생할 수 있습니다. 이러한 트래픽에는 일관성 해시, 단일 노드 선택 그룹, 또는 지역을 고정한 fallback을 별도로 사용하는 방식이 더 적합합니다.

interval·tolerance와 상태 확인은 어떻게 함께 작동할까

interval은 주기적인 검사의 대략적인 간격을 제어하며, 단위는 보통 초입니다. 값이 작을수록 상태가 빠르게 갱신되지만 탐색 요청이 늘어납니다. 300초라면 검사에 참여하는 각 노드가 약 5분마다 테스트 주소에 한 번 접속합니다. 노드 20개가 있는 그룹은 이론상 매 라운드 약 20회의 탐색 요청을 생성합니다. 구독에 노드가 100개 있고 여러 중복 검사 그룹을 만들었다면 간격을 30초까지 줄일 필요는 없습니다.

tolerance는 주로 url-test의 전환 안정성을 높이는 설정입니다. 시간 초과 값이 아니며 노드가 “80ms를 더 기다리게” 하는 기능도 아닙니다. 80으로 설정하면 후보 노드의 지연 시간이 현재 노드보다 충분히 낮을 때만 교체합니다. fallback은 순서와 사용 가능 상태를, load-balance는 연결 분배를 기준으로 하므로 일반적으로 tolerance가 핵심 동작을 결정하지 않습니다.

실용적인 세 가지 설정 출발점

일상적인 웹 사용: interval: 300, tolerance: 80으로 잦은 전환을 우선 줄입니다.
네트워크 변동이 큼: interval: 180, tolerance: 50으로 회선 변화를 더 빠르게 감지합니다.
고정 주·예비 출구: fallback을 사용하고 interval: 180으로 설정한 뒤, 서비스 우선순위에 따라 노드를 정렬합니다.
대규모 동시 다운로드: load-balance와 interval: 300을 사용하고 처리량이 눈에 띄게 낮은 노드를 먼저 제외합니다.

테스트 주소도 결론에 영향을 줍니다. 너무 먼 대상을 선택하면 주로 노드에서 대상 사이트까지의 해외 경로를 측정하게 됩니다. 반대로 일부 노드만 접속할 수 있는 대상을 선택하면 정상 노드가 실패로 오인될 수 있습니다. 범용 검사에는 안정적인 204 서비스를 사용하고, 특정 서비스는 별도로 검증하세요. 몇 분마다 대용량 파일을 다운로드하는 방식은 지속적으로 트래픽과 서버 대역폭을 사용하므로 상태 확인용으로 적합하지 않습니다.

상황별 조합: 일상적인 웹 사용·스트리밍·다운로드

일상적인 웹 사용: url-test와 수동 선택 조합

일반적인 웹페이지와 메신저는 응답 속도를 중요하게 보는 경우가 많습니다. url-test 자동 그룹을 만든 다음 select에서 자동 그룹과 자주 쓰는 개별 노드를 함께 선택할 수 있습니다. 기본적으로 자동 측정 결과를 사용하면서도 사이트의 위험 관리에 걸리거나 특정 노드에 접속 문제가 생기면 클라이언트의 「프록시」→「노드 선택」에서 출구를 수동으로 고정할 수 있습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 홍콩-01
      - 홍콩-02
      - 싱가포르-01
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 80

  - name: 일상용 프록시
    type: select
    proxies:
      - 자동 선택
      - 홍콩-01
      - 싱가포르-01
      - DIRECT

스트리밍: 같은 지역의 fallback

먼저 서비스가 제공되는 지역을 기준으로 노드를 필터링한 뒤 같은 지역의 fallback을 구성하세요. 주 노드에는 재생 안정성과 혼잡 시간대 처리량이 검증된 회선을 넣고, 예비 노드에는 같은 지역의 다른 서버를 넣습니다. 규칙에서 대상 서비스 도메인 또는 해당 규칙 세트를 이 그룹으로 지정하세요. 핵심은 최저 204 지연 시간을 찾는 것이 아니라 지역을 유지하면서 주 회선 장애 시 전환하는 것입니다.

멀티스레드 다운로드: 품질이 비슷한 load-balance

다운로드 도구가 8개 또는 16개의 동시 연결로 설정되어 있어야 부하 그룹이 서로 다른 연결을 여러 노드에 분배할 수 있습니다. 브라우저의 단일 연결 다운로드나 연결 하나만 사용하는 오브젝트 스토리지 요청은 보통 단일 노드의 한도를 따릅니다. 사용 전에 구독 서비스의 트래픽 정책이 동시 연결을 허용하는지, 서로 다른 출구에서 같은 다운로드 주소에 접속해도 임시 링크가 만료되지 않는지 확인하세요.

전략 그룹을 규칙에 연결하기

rules:
  - DOMAIN-SUFFIX,example-video.com,스트리밍 주·예비
  - DOMAIN-SUFFIX,example-download.com,동시 다운로드
  - MATCH,일상용 프록시

규칙은 위에서 아래로 일치하며, 일치하면 더 이상 검색하지 않습니다. 특정 서비스는 여러 도메인을 사용하는 경우가 많아 메인 페이지 도메인만 추가하면 동영상 분할 파일, 이미지 CDN 또는 로그인 API를 놓칠 수 있습니다. 규칙 세트를 사용할 때는 업데이트 출처와 실제 내용을 확인하세요. 수정 후 클라이언트의 「연결」 페이지에서 대상 도메인이 최종적으로 어떤 규칙과 전략 그룹에 연결되었는지 확인하는 편이 브라우저가 열리는지만 보는 것보다 정확합니다.

자주 발생하는 설정 오류와 점검 순서

모든 노드에 timeout이 표시됨

브라우저나 명령줄에서 테스트 주소 자체에 접속할 수 있는지 확인합니다.
DNS가 정상적으로 해석되는지, 로그에 dns resolve failed가 표시되는지 확인합니다.
테스트 주소를 안정적인 다른 소용량 응답 대상으로 바꾼 뒤 지연 시간 측정을 다시 실행합니다.
노드 이름이 공백, 대소문자, 기호를 포함해 proxies 목록과 완전히 일치하는지 확인합니다.
구독 업데이트 후 노드 이름이 바뀌어 전략 그룹이 이전 이름을 참조하고 있지 않은지 확인합니다.

url-test가 노드를 자주 전환함

먼저 tolerance를 0 또는 10에서 50~100으로 높이고, interval을 30초에서 180~300초로 늘리세요. 노드가 여러 지역에 섞여 있다면 지역별로 그룹을 나누는 것이 좋습니다. 10회 연속 측정해 중간값과 변동 범위를 기록하는 방법도 있습니다. 평균 지연 시간은 낮지만 변동 폭이 100ms를 넘는 노드는 90ms로 안정적인 노드보다 기본 출구에 적합하지 않을 수 있습니다.

fallback이 지연 시간이 가장 낮은 노드를 선택하지 않음

예상된 동작입니다. fallback은 목록에서 사용 가능한 첫 번째 노드를 선택할 뿐 어느 노드가 더 빠른지는 비교하지 않습니다. 낮은 지연 시간의 노드를 자동으로 선택하려면 url-test으로 바꾸세요. 주 노드를 고정하고 장애가 발생할 때만 전환하려면 fallback을 유지하면서 노드 순서를 조정하면 됩니다.

load-balance를 사용해도 다운로드 속도가 늘지 않음

먼저 다운로드 도구가 실제로 여러 연결을 만들었는지 확인한 뒤, 클라이언트의 「연결」 페이지에서 각 연결이 어떤 경로를 사용하는지 살펴보세요. 연결이 하나뿐이라면 속도 상한은 여전히 단일 노드에 의해 결정됩니다. 연결이 많아도 모두 같은 대상에 접속한다면 일관성 해시 때문에 하나의 노드에 고정될 수 있습니다. 라운드 로빈으로 바꾸기 전에 다운로드 사이트가 출구 IP 변경을 허용하는지 평가하세요. 연결이 고르게 분배되어도 원본 서버 제한, 로컬 대역폭, 노드 공유 대역폭이 병목이 될 수 있습니다.

최종 선택: 서비스 목표를 먼저 정한 뒤 그룹 유형 선택

“응답이 빠른 노드를 사용”하려면 url-test, “주 회선을 사용할 수 없을 때만 예비 회선 사용”이 필요하면 fallback, “여러 동시 연결을 여러 노드에 분산”하려면 load-balance를 선택하세요. 어느 하나가 절대적으로 우수한 것은 아니며, 판단 기준이 서비스 목적과 맞는지가 핵심입니다.

실용적인 설정에는 보통 여러 유형의 그룹이 함께 사용됩니다. 일상적인 기본 출구에는 url-test, 지역을 고정해야 하는 서비스에는 fallback, 동시 다운로드에는 별도의 load-balance를 사용하고, 최상위에는 select를 두어 수동으로 덮어쓸 수 있게 합니다. 구체적인 도메인부터 MATCH까지 규칙 순서를 적절히 구성하면 모든 요구를 하나의 자동 그룹에 맡기지 않고 트래픽별로 알맞은 전략 그룹에 보낼 수 있습니다.