Clash 프록시 그룹 설정 총정리: url-test, fallback, load-balance 차이

먼저 프록시 그룹의 역할부터 이해하기

Clash 또는 mihomo에서 구독을 불러오면 보통 여러 프록시 노드가 생성됩니다. 프록시 그룹은 노드와 트래픽 분기 규칙 사이에서 작동합니다. 규칙이 요청을 특정 프록시 그룹으로 보내면, 그룹이 실제로 사용할 노드를 결정합니다. 수동 선택 그룹은 사용자가 노드를 지정하고, 자동 프록시 그룹은 지연 시간, 연결 가능 여부 또는 분배 알고리즘에 따라 계속 노드를 선택합니다.

url-test, fallback, load-balance는 모두 그룹 내 노드의 상태를 확인하지만 선택 기준은 서로 다릅니다. 이를 단순히 “자동으로 노드를 고르는 기능”이라고 이해하면 설정이 어긋날 수 있습니다. 예를 들어 백업 회선에는 안정적인 주·예비 순서가 필요한데 최저 지연 시간 우선으로 설정하거나, 다운로드 작업에서 여러 연결을 분산하려고 하면서 로드 밸런싱이 단일 연결의 대역폭까지 합쳐 준다고 착각할 수 있습니다.

프록시 그룹 유형	주요 목표	선택 방식	적합한 상황
`url-test`	접속 지연 시간 줄이기	정상 노드 중 측정 결과가 가장 낮은 노드 선택	웹 브라우징, 검색, 대화형 애플리케이션
`fallback`	회선 가용성 유지	목록 순서대로 첫 번째 정상 노드 사용	주 회선과 예비 회선 구성, 원격 근무
`load-balance`	여러 연결로 분산	일관성 해시 또는 라운드 로빈 알고리즘으로 분배	다중 연결 다운로드, 동시 요청, 일괄 작업

url-test: 응답 지연 시간을 기준으로 선택

url-test는 그룹 내 각 노드로 지정된 테스트 주소에 접속해 응답 시간을 기록한 뒤, 사용 가능한 노드 중 더 빠른 노드를 선택합니다. 웹 브라우징, 메신저, 원격 터미널처럼 반응 속도가 중요한 트래픽에 적합합니다. 측정 결과인 68ms, 115ms, 240ms는 테스트 요청의 왕복 시간이며 다운로드 속도나 노드의 실제 가용 대역폭을 의미하지는 않습니다.

바로 사용할 수 있는 기본 설정

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

rules:
  - DOMAIN-SUFFIX,example.com,자동 선택
  - MATCH,자동 선택

이 설정은 300초마다 상태 확인을 실행하며, 테스트 주소가 정상적으로 응답하면 빈 응답을 반환합니다. tolerance: 80은 현재 노드와 후보 노드의 지연 시간 차이가 80ms를 크게 넘지 않을 때 불필요한 전환을 줄이는 옵션입니다. 현재 노드가 92ms이고 새 결과가 54ms라면 차이는 38ms이므로 즉시 전환하기보다 현재 노드를 유지하는 편이 일반적으로 안정적입니다. 반대로 새 노드가 55ms이고 현재 노드가 190ms까지 느려졌다면 전환할 이유가 충분합니다.

안정적인 파라미터 설정 방법

url: 테스트 주소는 응답 크기가 작고 안정적이며 결과를 예측할 수 있어야 합니다. 측정 대상 자체에 속도 제한이나 지역 차단이 있으면 모든 노드가 비정상으로 오판될 수 있습니다.
interval: 단위는 초입니다. 일반적인 사용 환경에서는 300초부터 시작하고, 네트워크 변화가 잦다면 120초로 줄일 수 있습니다. 고정된 가정용 네트워크라면 600초도 무난합니다.
tolerance: 단위는 밀리초입니다. 0으로 설정하면 작은 지연 변화에도 선택 노드가 바뀌어 수치가 비슷한 노드 사이를 자주 오갈 수 있습니다. 일반적으로 50~150ms 범위를 많이 사용합니다.
lazy: 활성화하면 실제로 사용하지 않는 프록시 그룹의 불필요한 능동 테스트를 줄일 수 있습니다. 예비 그룹을 계속 모니터링해야 한다면 코어의 동작과 실제 필요에 따라 비활성화를 검토하세요.
proxies: 노드 이름은 설정에 정의된 이름과 공백, 지역 표기, 숫자까지 완전히 일치해야 합니다. 이런 문자가 포함된 이름은 따옴표로 감싸는 것이 좋습니다.

지연 시간이 가장 낮다고 해서 항상 사용감이 좋은 것은 아닙니다. 한 노드는 48ms로 측정되지만 저녁 시간 가용 대역폭이 8Mbps에 불과할 수 있고, 다른 노드는 86ms여도 120Mbps를 안정적으로 제공할 수 있습니다. 웹 페이지는 전자가, 대용량 다운로드는 후자가 더 적합할 수 있습니다. 따라서 url-test는 지연 시간 중심의 선택 기능이지 종합 성능 점수가 아닙니다.

fallback: 우선순위에 따라 가용성 유지

fallback도 상태 확인을 수행하지만 정상 노드 중 지연 시간이 가장 낮은 노드를 찾지는 않습니다. proxies 목록 순서대로 확인하며, 앞쪽에 있고 현재 사용 가능한 노드를 우선합니다. 첫 번째 노드가 실패해야 두 번째 노드로 전환하고, 첫 번째 노드가 복구되어 다시 정상으로 확인되면 우선 회선으로 돌아갈 수 있습니다.

이 동작은 “주 회선 우선, 장애 시 예비 회선 사용”이라는 명확한 요구에 적합합니다. 예를 들어 회사 업무에서 특정 지역의 출구를 고정해야 한다면 주 노드를 첫 번째에 배치하고, 주 노드 연결이 실패할 때만 같은 지역의 예비 노드로 전환하게 할 수 있습니다. 예비 노드의 지연 시간이 30ms 낮더라도 주 노드를 적극적으로 대체해서는 안 됩니다.

주·예비 회선 YAML 예시

proxy-groups:
  - name: "업무 회선"
    type: fallback
    proxies:
      - "싱가포르 전용 회선"
      - "싱가포르 예비"
      - "일본 예비"
    url: "http://www.gstatic.com/generate_204"
    interval: 180
    lazy: false

rules:
  - DOMAIN-SUFFIX,corp.example,업무 회선
  - DOMAIN-SUFFIX,meeting.example,업무 회선

이 목록의 순서가 곧 우선순위입니다. 먼저 “싱가포르 전용 회선”을 사용하고, 사용할 수 없으면 “싱가포르 예비”로 전환하며, 둘 다 실패한 경우에만 “일본 예비”를 사용합니다. interval: 180은 약 3분마다 다시 확인한다는 뜻입니다. 두 확인 사이에 장애가 발생하면 새 연결이 먼저 시간 초과를 겪을 수 있으므로, 복구 시간이 중요한 업무에서는 간격을 너무 길게 설정하지 않는 것이 좋습니다.

fallback이 적합하지 않은 상황

항상 현재 지연 시간이 가장 낮은 노드를 선택하려면 url-test를 사용하세요.
여러 노드가 동시에 많은 독립 연결을 처리해야 한다면 load-balance를 고려하세요.
여러 노드에 명확한 우선순위가 없고 단지 이름 순서만 다르다면, fallback은 자동으로 속도를 비교해 주지 않습니다.
고정 출구 IP가 필요한 로그인 세션은 지역이 다른 예비 노드에 함부로 넣지 마세요. 장애 전환 후 출구 지역이 바뀔 수 있습니다.

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

load-balance의 목표는 그룹 내 여러 정상 노드가 연결을 나누어 처리하도록 하는 것이지, 하나의 “가장 빠른 노드”를 고르는 것이 아닙니다. 웹 페이지의 독립 리소스가 많거나, 분할 다운로드, 동시 API 요청, 일괄 작업을 수행할 때 적합합니다. 연결 분배 방식은 strategy로 결정하며, mihomo에서 자주 사용하는 전략으로 consistent-hashing과 round-robin이 있습니다.

일관성 해시 설정

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

rules:
  - DOMAIN-SUFFIX,download.example,동시 분산
  - DOMAIN-SUFFIX,static.example,동시 분산

consistent-hashing은 대상 정보를 바탕으로 안정적인 매핑을 수행하므로, 노드 구성이 크게 바뀌지 않으면 같은 대상이 같은 프록시로 연결되는 경향이 있습니다. 한 사이트의 여러 요청이 서로 다른 출구 IP로 자주 바뀌는 현상을 줄일 수 있어 로그인 상태, CDN 리소스, 출구 일관성이 어느 정도 필요한 상황에 적합합니다.

라운드 로빈 설정

proxy-groups:
  - name: "라운드 로빈 노드"
    type: load-balance
    strategy: round-robin
    proxies:
      - "일본 01"
      - "일본 02"
      - "일본 03"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    lazy: true

round-robin은 새 연결을 정상 노드에 차례로 배분해 연결 수를 직접 분산합니다. 출구 IP 변경을 허용하는 동시 작업에 적합하지만, 같은 웹사이트가 IP 변경에 민감하다면 로그인, CAPTCHA 또는 세션 검증에 문제가 생길 수 있습니다. 이 경우 일관성 해시나 단일 노드 전략을 우선 사용하세요.

상태 확인 파라미터와 노드 출처

세 프록시 그룹 모두 상태 확인에 의존합니다. 테스트 결과가 시간 초과나 음수로 표시되더라도 구독 노드가 전부 만료되었다고 바로 판단하지 마세요. 먼저 테스트 URL 접속 여부, 시스템 시간, 대상 도메인 DNS 해석을 확인하고 로컬 방화벽이 코어 프로세스를 차단하는지도 점검하세요. 특정 네트워크에서 테스트 주소가 불안정하다면 작은 응답을 반환하는 다른 HTTPS 또는 HTTP 주소로 바꿔 결과를 비교해 보세요.

증상	우선 확인할 항목	권장 조치
모든 노드에서 동시에 시간 초과	테스트 URL, DNS, 로컬 네트워크	브라우저에서 테스트 주소에 직접 접속하고 코어 로그 확인
특정 노드에서 계속 시간 초과	노드 파라미터, 서버 상태	해당 노드를 수동 선택해 실제 연결 테스트
url-test가 자주 전환됨	`tolerance`가 너무 작음	80ms 또는 100ms부터 조정
fallback이 최저 지연 노드를 선택하지 않음	노드 배열 순서	업무 우선순위에 따라 재배치하거나 url-test로 변경
로드 밸런싱 후 로그인이 풀림	출구 IP가 자주 변경됨	일관성 해시 또는 단일 노드 그룹으로 변경

구독 노드가 많을 때 프록시 제공자 사용

구독으로 노드가 동적으로 업데이트된다면 proxies에 하나씩 입력하기가 번거롭습니다. mihomo에서는 proxy-providers로 구독 출처를 정의한 뒤 프록시 그룹에서 use로 제공자를 참조할 수 있습니다. 구독이 업데이트되면 조건에 맞는 노드가 해당 그룹에 들어갑니다.

proxy-providers:
  main-subscription:
    type: http
    url: "https://subscription.example/profile.yaml"
    path: "./providers/main.yaml"
    interval: 21600
    health-check:
      enable: true
      url: "http://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: "홍콩 자동"
    type: url-test
    use:
      - main-subscription
    filter: "(?i)香港|港|HK"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

filter는 정규 표현식으로 노드 이름을 필터링합니다. 예시에서는 이름에 “香港”, “港” 또는 “HK”가 포함된 노드를 남기며, (?i)는 영문 대소문자를 구분하지 않는다는 뜻입니다. 구독마다 “Hong Kong”, “HKG” 또는 지역 국기 이모지처럼 이름 표기가 다를 수 있으므로, 적용 전 노드 목록을 확인하고 실제 이름에 맞게 표현식을 수정하세요.

제공자 계층과 프록시 그룹 계층 모두 상태 확인을 수행할 수 있습니다. 전자는 노드의 사용 가능 상태를 관리하고, 후자는 전략에 따라 노드를 선택합니다. 노드가 100개 이상이라면 여러 확인 간격을 모두 30초로 설정할 경우 탐지 요청이 크게 늘어납니다. 일반적으로는 300초를 사용하고, 구독 업데이트 간격은 21600초, 즉 6시간으로 설정할 수 있습니다.

Clash Nyanpasu에서 설정 적용하기

먼저 현재 실행 중인 코어가 설정에 사용된 프록시 그룹 유형과 파라미터를 지원하는지 확인하세요. Clash Nyanpasu에서 「설정」→「Clash 코어」로 이동하면 코어 유형과 버전을 확인할 수 있습니다. mihomo 코어를 사용한다면 로그 시작 부분에서 실제 로드된 버전을 확인하세요. 이 문서의 예시는 mihomo에서 흔히 사용하는 문법을 기준으로 하며, 오래된 Clash 계열은 일부 로드 밸런싱 전략이나 제공자 필터 파라미터를 인식하지 못할 수 있습니다.

「프로필」 페이지로 이동해 현재 활성화된 구독 프로필을 찾으세요.
프로필 편집 메뉴를 열고 최상위 proxy-groups 항목으로 이동하세요.
새 프록시 그룹을 proxy-groups에 추가하고, 각 단계의 공백 들여쓰기를 일관되게 유지하세요. Tab은 사용하지 마세요.
rules에서 처리할 도메인, 규칙 세트 또는 최종 규칙이 새 그룹 이름을 가리키도록 설정하세요.
설정을 저장하고 다시 불러온 다음 「로그」를 열어 YAML 구문 오류나 프록시 노드를 찾을 수 없다는 메시지가 있는지 확인하세요.
프록시 그룹 화면에서 지연 시간 테스트를 한 번 실행해 노드 상태와 자동 선택 결과가 예상과 일치하는지 확인하세요.

세 가지 프록시 그룹 전략 조합하기

복잡한 설정에서 한 가지 유형만 선택할 필요는 없습니다. 지역별로 url-test 그룹을 만든 뒤 수동 선택에 사용할 수도 있고, 핵심 업무에는 fallback, 대량 다운로드에는 load-balance를 구성할 수도 있습니다. 다만 그룹을 중첩할 때는 목적을 명확히 하고 순환 참조를 피해야 합니다.

proxy-groups:
  - name: "홍콩 저지연"
    type: url-test
    proxies:
      - "홍콩 01"
      - "홍콩 02"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "일본 저지연"
    type: url-test
    proxies:
      - "일본 01"
      - "일본 02"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "핵심 업무"
    type: fallback
    proxies:
      - "홍콩 저지연"
      - "일본 저지연"
    url: "http://www.gstatic.com/generate_204"
    interval: 180

  - name: "노드 선택"
    type: select
    proxies:
      - "홍콩 저지연"
      - "일본 저지연"
      - "핵심 업무"
      - DIRECT

이 구조는 먼저 각 지역 안에서 지연 시간이 낮은 노드를 선택한 다음, “핵심 업무”가 홍콩 우선, 일본 예비 순서로 동작하게 합니다. 최상위 “노드 선택” 그룹은 수동 제어 진입점을 유지합니다. 홍콩 노드를 모두 사용할 수 없을 때만 fallback이 일본 그룹으로 전환하며, 홍콩 그룹 안에서 노드 하나만 비정상인 경우에는 내부 url-test가 다른 홍콩 노드로 먼저 전환을 시도합니다.

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

그룹 이름 또는 노드 이름이 일치하지 않음

YAML의 이름은 전체 문자열을 기준으로 일치 여부를 판단합니다. “홍콩 01”과 “홍콩01”은 서로 다른 이름이며, 전각·반각 공백 차이도 참조 실패의 원인이 될 수 있습니다. 로그에 proxy not found와 같은 메시지가 나타나면 이름을 다시 입력하지 말고 노드의 원래 이름을 복사하세요.

들여쓰기는 맞지만 계층이 잘못됨

proxy-groups, proxy-providers, rules는 모두 최상위 필드입니다. 프록시 그룹을 proxies 노드 안에 잘못 넣으면 텍스트가 정렬되어 보여도 정상적으로 불러올 수 없습니다. 목록 항목 앞에 공백 두 칸을 쓰는 것은 흔한 방식일 뿐이며, 같은 계층의 들여쓰기를 일관되게 유지하는 것이 핵심입니다.

지연 시간 측정은 정상인데 실제 웹사이트에 접속할 수 없음

먼저 전략을 전역 또는 수동 노드로 바꿔 규칙 문제인지 노드 문제인지 구분하세요. 수동 노드에서는 접속되지만 규칙 모드에서 실패한다면 규칙 순서를 확인해야 합니다. Clash 규칙은 위에서 아래로 매칭되므로 앞쪽의 DOMAIN, DOMAIN-SUFFIX, 규칙 세트 또는 GEOIP가 이미 요청을 다른 그룹으로 보냈을 수 있습니다.

TUN 모드의 결과가 시스템 프록시와 다름

시스템 프록시는 시스템 프록시 설정을 따르는 애플리케이션만 처리하지만, TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 처리합니다. TUN으로 전환하면 터미널 프로그램, 게임 또는 독립 업데이트 프로그램이 Clash를 통과하기 시작해 프록시 그룹의 부하가 달라질 수 있습니다. 점검할 때는 현재 모드, DNS 설정, 대상 프로세스를 기록해 트래픽 진입점의 변화를 그룹 장애로 오인하지 않도록 하세요.

구독 수정 후 설정이 덮어써짐

원격 구독으로 생성된 설정을 직접 편집하면 다음 업데이트 때 구독 원본으로 되돌아갈 수 있습니다. 장기간 사용할 사용자 지정 전략은 클라이언트가 지원하는 오버라이드, 병합 또는 스크립트 처리 기능에 넣으세요. 변경 전 로컬 설정을 복사해 테스트하고 그룹, 규칙 참조, 제공자 필터가 정상적으로 로드되는지 확인한 뒤 지속적으로 관리할 방식으로 옮기는 것이 좋습니다.

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

웹 브라우징, 검색, 원격 상호작용에는 url-test를 우선 고려하고, tolerance를 50~150ms로 설정해 잦은 전환을 줄이세요.
주 회선을 반드시 우선 사용하고 장애가 발생했을 때만 예비 회선으로 전환하려면 fallback을 사용하세요. 노드 배열 순서가 곧 업무 우선순위입니다.
작업에 독립 연결이 많고 여러 노드로 분산해야 한다면 load-balance를 사용하세요. 로그인 상태가 중요하다면 일관성 해시를 우선 선택하세요.
단일 연결 속도가 느릴 때는 로드 밸런싱으로 대역폭이 합쳐질 것이라고 기대하지 말고, 노드 용량, 프로토콜 오버헤드, 로컬 네트워크, 대상 서버의 속도 제한을 각각 확인하세요.
어떤 자동 그룹을 사용하든 규칙의 연결 대상, 상태 확인 주소, 코어 호환성, 구독 업데이트 후 노드 이름을 함께 점검해야 합니다.

실제 설정은 노드 3개와 300초 상태 확인 간격을 사용하는 간단한 그룹에서 시작해 하루 동안 지연 시간, 전환 횟수, 로그를 관찰한 뒤 단계적으로 조정하세요. 최저 지연 시간, 가용성 우선, 동시 연결 분산 중 무엇을 원하는지 먼저 정하면 세 가지 프록시 그룹 전략 중 적합한 방식을 정확히 선택할 수 있습니다.