Clash 프록시 그룹 유형 선택 가이드: url-test·fallback·load-balance 차이와 설정 방법

Clash 설정에서 프록시 그룹은 연결을 최종적으로 어느 노드에 전달할지 결정합니다. 규칙은 트래픽을 특정 그룹으로 보낼 뿐이며, 그룹 내부의 type이 노드 선택 방식을 결정합니다. 수동 그룹 select는 사용자가 노드를 지정하고, 자동 그룹은 상태 확인, 목록 순서 또는 분배 알고리즘에 따라 노드를 선택합니다.

url-test、fallback 및 load-balance는 모두 상태 확인을 사용하지만 목적은 서로 다릅니다. 첫 번째는 낮은 측정 지연 시간을, 두 번째는 고정 우선순위와 장애 대체를, 세 번째는 새 연결을 여러 사용 가능한 노드에 분산하는 것을 중시합니다. 유형을 잘못 선택하면 설정 오류보다 잦은 전환, 접속 출구 변경 또는 예비 노드가 예상대로 인계하지 않는 문제가 흔히 발생합니다.

세 가지 자동 프록시 그룹의 핵심 차이

유형을 판단할 때는 먼저 다음 질문에 답해 보세요. 이 그룹에 필요한 것은 “응답이 빠른 노드 선택”, “업무 우선순위에 따른 대체”, “여러 노드가 새 연결을 함께 처리” 중 무엇인가요? 각각 url-test、fallback、load-balance에 해당합니다.

유형	선택 기준	주요 용도	출구 특성
`url-test`	상태 확인 지연 시간 및 허용 오차	일상적으로 지연 시간이 낮은 노드 자동 선택	일정 시간 동안 현재 우선 노드 집중 사용
`fallback`	설정 순서 및 사용 가능 상태	주 회선 우선, 예비 회선으로 대체	목록에서 사용 가능한 첫 번째 구성원 우선 사용
`load-balance`	부하 분산 방식	새 연결을 여러 노드에 분산	연결마다 서로 다른 출구를 사용할 수 있음

상태 확인은 업무 연결을 계속 점유해 속도를 측정하는 방식이 아닙니다

자동 그룹은 interval에 지정한 초마다 테스트 URL에 접속해 구성원의 사용 가능 여부와 응답 시간을 기록합니다. 예를 들어 interval: 300이면 일반적인 주기는 300초, 즉 5분입니다. 주기가 너무 짧으면 노드와 로컬 네트워크에 상태 확인 요청이 늘고, 너무 길면 회선 복구나 장애 발견이 늦어집니다.

테스트 URL은 보통 응답 내용이 작고 응답이 안정적인 주소를 선택합니다. 예를 들면 https://www.gstatic.com/generate_204가 있습니다. 해당 주소 자체가 대상 네트워크에서 차단되면 모든 노드가 동시에 실패로 표시될 수 있습니다. 이때는 모든 노드가 고장 났다고 단정하기보다 안정적으로 응답하는 가벼운 주소로 바꿔야 합니다.

url-test: 측정 지연 시간에 따른 자동 선택

url-test는 주기적으로 그룹 구성원을 테스트하고, 측정 지연 시간이 낮은 사용 가능한 노드를 선택합니다. 웹 브라우징, 메신저, 코드 저장소처럼 응답 시간에 민감한 일상 트래픽에 적합합니다. 선택은 프록시 그룹 단위로 이루어지며, 모든 요청마다 다시 속도를 측정한다는 뜻은 아닙니다.

proxy-groups:
  - name: 자동 우선 선택
    type: url-test
    proxies:
      - 홍콩-01
      - 홍콩-02
      - 일본-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

tolerance: 몇 ms 차이로 인한 전환 줄이기

tolerance의 단위는 밀리초입니다. 위 예시에서 50으로 설정하면 새 결과가 허용 오차만큼 충분히 좋아졌을 때 전환할 가치가 있다는 뜻이며, 세부 선택 방식은 사용하는 코어의 구현에 따라 달라집니다. 이 옵션의 핵심 효과는 지연 시간이 비슷한 두 노드 사이에서 우선 노드가 계속 바뀌는 현상을 줄이는 것입니다.

예를 들어 노드 A의 측정값이 82ms이고 노드 B가 106ms라면 차이는 24ms입니다. 허용 오차가 50ms일 때는 한 번의 측정 변동만으로 전환할 필요가 없습니다. 노드 A가 178ms로 올라가고 노드 B가 103ms를 유지해 차이가 75ms가 되면 다시 선택하는 편이 합리적입니다. 가정용 Wi-Fi처럼 지연 변동이 클 때는 50~100ms부터 시도하고, 안정적인 유선 네트워크에서는 20~50ms를 사용할 수 있습니다.

lazy: 트래픽이 있을 때만 검사 유지

lazy: true는 자주 사용하지 않는 프록시 그룹에 적합합니다. 그룹에 장시간 연결이 없으면 코어가 불필요한 주기 테스트를 줄이고, 다시 매칭되는 트래픽이 발생하면 검사를 재개할 수 있습니다. 예비 회선 상태를 빠르게 감지해야 하는 핵심 업무 그룹은 사용하는 mihomo 버전과 클라이언트 동작을 함께 확인한 뒤 활성화 여부를 결정하세요.

url-test가 적합한 경우와 부적합한 경우

용도가 비슷하고 요금제와 회선 품질이 비슷한 여러 노드에 적합합니다.
지연 시간이 높은 노드를 자동으로 피하면서 고정 출구 주소는 필요하지 않은 경우에 적합합니다.
로그인 세션에서 장기간 동일한 지역 또는 동일한 출구 주소를 유지해야 하는 경우에는 적합하지 않습니다.
한 번의 204 테스트만으로 동영상 대역폭을 판단하는 용도에는 적합하지 않습니다. 지연 시간 측정은 지속적인 처리량 측정을 대신할 수 없습니다.

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

fallback의 핵심은 지연 시간이 가장 짧은 노드가 아니라 목록에서 앞에 있고 현재 사용 가능한 노드입니다. 목록의 첫 번째 구성원이 주 회선이며, 주 회선의 상태 확인이 실패한 뒤에야 그룹이 다음 예비 구성원을 시도합니다. 주 회선이 복구되어 검사를 통과하면 일반적으로 다시 앞쪽 구성원으로 돌아갑니다.

proxy-groups:
  - name: 업무 회선
    type: fallback
    proxies:
      - 기업 전용 회선
      - 홍콩 예비
      - 일본 예비
    url: https://www.gstatic.com/generate_204
    interval: 180
    lazy: false

이 설정은 명확한 업무 우선순위를 나타냅니다. 먼저 “기업 전용 회선”을 사용하고, 사용할 수 없으면 “홍콩 예비”로 전환하며, 둘 다 사용할 수 없을 때 “일본 예비”를 사용합니다. 일본 노드의 측정값이 45ms이고 기업 전용 회선이 92ms라도 기업 전용 회선이 사용 가능한 동안에는 계속 우선순위를 유지합니다.

“사용 가능”은 테스트 URL이 정상 완료된다는 뜻일 뿐입니다

노드가 204 테스트 주소에 접속할 수 있다고 해서 규칙에 지정된 업무 도메인에도 반드시 접속할 수 있는 것은 아닙니다. 특정 회선은 상태 확인을 통과하면서도 특정 서비스에는 정상적으로 접속하지 못할 수 있습니다. 이 경우 업무 그룹에 실제 대상과 가까운 테스트 주소를 사용할 수 있지만, 로그인 필요 페이지나 여러 차례 리디렉션되는 페이지, 대용량 파일을 반환하는 주소는 피해야 합니다.

장애 전환이 이미 수립된 TCP 연결을 다른 노드로 끊김 없이 옮겨 주는 것도 아닙니다. 주 회선이 끊기면 기존 다운로드, SSH 또는 WebSocket 연결은 대개 중단되며, 애플리케이션이 다시 연결한 뒤에야 새 연결이 예비 구성원을 거칩니다. 장시간 연결이 필요한 업무라면 애플리케이션 자체의 재시도 기능도 함께 확인해야 합니다.

fallback의 대표적인 사용 사례

고정 주 회선: 주 노드는 안정적인 출구 또는 특정 지역을 제공하고, 다른 노드는 장애 발생 시에만 대체합니다.
비용 우선: 트래픽이 충분한 회선을 먼저 사용하고, 비용이 높거나 사용량이 제한된 회선은 뒤에 배치합니다.
지역 순서: 먼저 홍콩 지역을 사용하고, 모두 사용할 수 없을 때 일본 또는 싱가포르 지역으로 전환합니다.
원격 연결: 원격 개발이나 관리 패널 같은 업무는 수십 ms의 지연 차이보다 출구의 연속성을 더 중시합니다.

load-balance: 새 연결을 여러 노드에 분산

load-balance는 여러 사용 가능한 구성원 사이에 연결을 분배합니다. 대역폭을 합산하는 기능은 아닙니다. 단일 TCP 다운로드는 일반적으로 하나의 노드를 계속 사용하므로, 100Mbps 회선 세 개를 자동으로 합쳐 300Mbps 연결로 만들 수 없습니다. 많은 독립 요청, 여러 도메인 접속 또는 다수의 동시 작업에 더 적합합니다.

proxy-groups:
  - name: 동시 연결 분산
    type: load-balance
    proxies:
      - 홍콩-01
      - 홍콩-02
      - 홍콩-03
    url: https://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

consistent-hashing: 관련 대상의 연결성을 비교적 안정적으로 유지

consistent-hashing은 연결 대상을 기준으로 분배 결과를 계산해 동일하거나 유사한 대상이 같은 구성원으로 향하도록 합니다. 완전한 순환 방식보다 웹사이트 로그인, API 호출처럼 어느 정도 출구 연속성이 필요한 경우에 적합합니다. 노드 목록이 변경되면 일부 대상은 다시 매핑될 수 있으므로 진정한 고정 출구를 대신할 수는 없습니다.

round-robin: 새 연결을 순서대로 분배

mihomo가 지원하는 round-robin 방식은 새 연결이 사용 가능한 구성원을 차례로 사용하도록 합니다. 그룹에 A, B, C 세 노드가 있다면 연속으로 생성되는 연결은 A, B, C, A 순서로 분배될 수 있습니다. 하나의 웹페이지도 여러 도메인에 동시에 연결하는 경우가 많으므로, 같은 페이지를 불러오는 동안 여러 출구 주소가 나타날 수 있습니다.

라운드 로빈은 동시 수집이나 연결 수 분산처럼 단일 출구에 의존하지 않는 작업에 적합합니다. 계정 로그인, 결제, 인터넷 뱅킹 또는 IP 변경에 민감한 API에는 사용하지 않는 편이 좋습니다. 서버가 짧은 시간에 여러 출구를 비정상으로 판단한다면 select、fallback 또는 매핑 결과가 안정적인 전략을 사용하세요.

부하 전략	연결 분배 방식	적합한 상황	주의할 점
`consistent-hashing`	대상을 기준으로 비교적 안정적인 매핑 계산	여러 사이트 접속, 동시 API 요청	구성원 변경 후에도 매핑이 바뀔 수 있음
`round-robin`	새 연결을 순서대로 순환 분배	독립 작업, 동시 다운로드 작업	같은 애플리케이션에서 여러 출구가 나타날 수 있음

조합형 프록시 그룹: 지역 내 우선 선택 후 지역 단위 대체

복잡한 설정을 하나의 그룹에서 모두 해결할 필요는 없습니다. 프록시 그룹은 다른 프록시 그룹을 참조할 수 있으므로, 지역별로 url-test를 먼저 만들고 상위 fallback에서 지역 우선순위를 정하는 방식이 더 명확합니다. 이렇게 하면 같은 지역에서는 지연 시간이 낮은 노드를 선택하고, 해당 지역 전체를 사용할 수 없을 때 다른 지역으로 전환할 수 있습니다.

proxy-groups:
  - name: 홍콩 자동
    type: url-test
    proxies:
      - 홍콩-01
      - 홍콩-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 일본 자동
    type: url-test
    proxies:
      - 일본-01
      - 일본-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 기본 출구
    type: fallback
    proxies:
      - 홍콩 자동
      - 일본 자동
    url: https://www.gstatic.com/generate_204
    interval: 180

rules:
  - DOMAIN-SUFFIX,example.net,기본 출구
  - MATCH,기본 출구

이 구조에서는 “홍콩 자동”이 두 홍콩 노드 중 적합한 구성원을 먼저 선택합니다. 상위 그룹인 “기본 출구”는 홍콩 그룹을 우선 사용하고, 홍콩 그룹이 검사를 완료하지 못할 때만 일본 그룹을 사용합니다. 그룹 이름은 대소문자, 공백, 기호를 포함해 완전히 일치해야 합니다. YAML 들여쓰기는 두 칸으로 통일하고 Tab을 섞어 쓰지 않는 것이 좋습니다.

수동 그룹과 자동 그룹 함께 사용하기

실제 설정에서는 임시로 노드를 지정할 수 있도록 select 그룹도 보통 유지합니다. “자동 우선 선택”, “업무 회선”, “동시 연결 분산”과 개별 노드를 수동 그룹에 함께 넣은 뒤 규칙이 이 수동 그룹을 가리키도록 구성할 수 있습니다. 평소에는 자동 전략을 선택하고, 고정 출구가 필요할 때는 특정 노드로 전환하세요.

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - 자동 우선 선택
      - 업무 회선
      - 동시 연결 분산
      - 홍콩-01

이 구조는 모든 규칙이 하위 자동 그룹을 직접 가리키도록 하는 것보다 유지 관리가 쉽습니다. 클라이언트 화면에서는 “노드 선택”만 조작하고, 하위 그룹은 계속 상태 확인과 장애 판단을 담당합니다. 설정을 수정한 뒤에는 클라이언트에서 “설정” → “다시 불러오기”를 실행하고, 프록시 그룹 이름 없음, YAML 파싱 실패 또는 노드 참조 오류가 로그에 나타나는지 확인하세요.

규칙 모드, 시스템 프록시 및 TUN 모드와의 관계

프록시 그룹은 출구를 선택하고, 규칙은 어느 그룹으로 들어갈지 결정합니다. 규칙 모드에서는 연결이 위에서부터 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 등의 규칙과 일치하며, 매칭되면 지정된 프록시 그룹으로 들어갑니다. 전역 모드에서는 일반적으로 트래픽을 전역 정책에 일괄 전달하므로 일반 규칙을 하나씩 적용해 경로를 결정하지 않습니다.

시스템 프록시와 TUN 모드는 어떤 트래픽이 코어로 들어갈 수 있는지를 결정할 뿐, url-test、fallback 또는 load-balance의 기본 선택 로직을 바꾸지 않습니다. 브라우저가 시스템 프록시를 통해 Clash로 들어오거나 게임 트래픽이 TUN을 통해 mihomo로 들어오더라도 최종적으로 같은 프록시 그룹에 매칭되면 해당 그룹 유형에 따라 노드를 선택합니다.

TUN 모드에서는 UDP를 별도로 확인해야 합니다

게임, 음성 통화 및 일부 HTTP/3 트래픽은 UDP를 사용합니다. 노드 프로토콜, 서버와 클라이언트 코어가 모두 해당 UDP 전달을 지원해야 합니다. TCP 테스트 URL을 통과한 노드라고 해서 UDP까지 반드시 사용 가능한 것은 아닙니다. 웹페이지는 정상인데 음성 통화나 게임이 실패한다면 연결 패널에서 네트워크 유형을 확인하고, 노드의 UDP 지원 여부, TUN 설정 및 방화벽 규칙을 점검하세요.

DNS 결과가 규칙과 연결 대상에 영향을 줍니다

Fake-IP를 활성화하면 DNS 모듈이 매핑 주소를 반환하고, 코어가 매핑 관계에 따라 도메인을 복원한 뒤 규칙을 적용합니다. Redir-Host를 활성화하면 도메인 해석 결과가 연결에 더 직접적으로 사용됩니다. 프록시 그룹 자체는 DNS 문제를 해결하지 않습니다. 도메인 해석이 시간 초과되면 세 자동 그룹 모두 정상적인 업무 연결을 만들 기회를 얻지 못할 수 있습니다.

매개변수 조정 방법: 안정적인 설정부터 시작하기

자동 프록시 그룹 매개변수에는 모든 네트워크에 맞는 정답이 없습니다. 가정용 회선, 모바일 핫스팟, 중국 본토와 해외를 잇는 전용 회선, 클라우드 서버는 변동 폭이 서로 다릅니다. 가장 안정적인 방법은 보수적인 값으로 시작해 전환과 실패 상황을 기록한 뒤 문제에 맞춰 조정하는 것입니다.

매개변수	권장 시작값	값을 낮췄을 때의 영향	값을 높였을 때의 영향
`interval`	180~300초	변화를 더 빨리 발견하지만 상태 확인이 잦아짐	요청은 줄지만 장애 감지가 느려짐
`tolerance`	50 ms	작은 지연 시간 차이에도 민감해져 전환이 늘어날 수 있음	선택은 안정적이지만 다소 느린 노드가 유지될 수 있음
`lazy`	일반 그룹은 true로 설정 가능	상태 확인을 더 적극적으로 지속	유휴 그룹의 상태 확인 감소

먼저 모든 노드에서 테스트 URL이 안정적으로 접속되는지 확인하고, 최소 3회 연속으로 검사하세요.
한 번의 결과만 보지 말고 노드 지연 시간을 기록하세요. 82ms, 91ms, 87ms는 서로 비슷한 값이고, 82ms와 260ms는 뚜렷한 차이입니다.
클라이언트 연결 패널에서 실제 정책 경로를 확인해 규칙이 매칭된 그룹이 예상과 일치하는지 점검하세요.
조정 후 설정을 다시 불러오고 새 연결을 만들어 테스트하세요. 기존 연결은 변경 전 출구를 계속 사용할 수 있습니다.
전체 그룹이 실패하면 먼저 로컬 네트워크와 테스트 주소를 확인한 다음 구독 노드를 점검하세요. 여러 매개변수를 동시에 변경하지 마세요.

자주 하는 오해와 문제 해결 순서

오해 1: url-test는 모든 요청을 지연 시간이 가장 낮은 노드로 보낸다

최근 상태 확인 결과를 바탕으로 현재 선택을 유지하며, 모든 HTTP 요청 전에 전체 속도 측정을 다시 수행하지는 않습니다. 두 검사 주기 사이에 노드 지연 시간이 변하면 현재 결과가 잠시 늦게 반영될 수 있는데, 이는 주기적 검사 방식에서 정상적인 동작입니다.

오해 2: fallback은 예비 목록에서 가장 빠른 노드를 선택한다

fallback은 먼저 목록 순서를 따릅니다. 첫 번째 구성원이 사용 가능한 한 두 번째 구성원의 지연 시간이 더 낮더라도主动적으로 전환하지 않습니다. 지연 시간에 따라 선택하려면 url-test를 사용하거나 fallback 안에 url-test 하위 그룹을 참조하세요.

오해 3: load-balance는 단일 파일 다운로드 속도를 높인다

단일 연결은 일반적으로 하나의 노드에绑定됩니다. 다운로드 프로그램이 파일을 여러 독립 연결로 나누고, 그 연결들이 서로 다른 구성원에 분배될 때만 전체 처리량이 달라질 수 있습니다. 최종 속도는 여전히 원본 서버의 속도 제한, 노드 대역폭, 회선 혼잡 및 분배 전략의 영향을 받습니다.

고정된 문제 해결 순서

클라이언트의 “설정” 페이지에서 현재 불러온 파일이 방금 수정한 설정 파일인지 확인하세요.
로그를 열어 프록시 그룹 유형, 구성원 이름 및 YAML 들여쓰기가 올바른지 확인하세요.
“프록시” 또는 “정책” 페이지에서 지연 시간 테스트를 한 번 실행하고 실패한 구성원을 기록하세요.
“연결” 패널에서 대상 연결에 실제로 적용된 규칙과 정책 경로를 확인하세요.
대상 애플리케이션을 종료한 뒤 다시 열어 기존 TCP 연결이 이전 출구를 재사용하는 상황을 배제하세요.
시스템 프록시 트래픽은 정상인데 TUN 트래픽만 비정상이라면 TUN, DNS 및 방화벽을 점검하세요. 프록시 그룹 유형을 반복해서 바꾸지는 마세요.

선택 결론: 이름이 아니라 목적에 따라 결정하기

측정 지연 시간이 낮은 노드를 자동으로 사용하려면 url-test를 선택하세요.
주 회선을 우선 사용하고 장애 발생 시 순서대로 대체하려면 fallback을 선택하세요.
여러 노드에 새 연결을 분산하고 출구 변경을 허용할 수 있다면 load-balance를 선택하세요.
수동 제어와 자동 판단을 함께 사용하려면 바깥쪽에 select를 두고 자동 그룹을 구성원으로 추가하세요.
지역 우선순위가 필요하다면 먼저 지역 내에 url-test를 만들고, 상위 fallback으로 조합하세요.

대부분의 개인 설정은 “수동 선택 + 자동 우선 선택”의 2단계 구조로 시작하면 충분합니다. 주 회선과 예비 회선이 명확할 때만 fallback을 추가하고, 실제로 독립 연결이 많으며 출구 분산을 감수할 수 있을 때만 load-balance를 사용하세요. 유형이 많다고 설정이 더 효과적인 것은 아닙니다. 그룹과 규칙의 역할이 명확해야 검증과 문제 해결이 쉬워집니다.