고급 설정 예상 읽기 시간 12분

Clash 정책 그룹 url-test·fallback·load-balance 설정 및 차이

url-test·fallback·load-balance의 노드 선택 방식과 interval·tolerance 설정을 비교하고, 안정성이나 연결 분산에 맞춘 그룹 구성법을 알아봅니다.

세 가지 자동 정책 그룹, 어떻게 선택할까

Clash 정책 그룹은 여러 출구 중 하나를 선택하고, 규칙은 연결을 어느 정책 그룹으로 보낼지 결정합니다. 두 설정은 서로 다른 단계에서 작동합니다. 자동 그룹을 올바르게 설정해도 규칙이 연결을 DIRECT로 보내면 해당 연결은 그룹의 노드를 사용하지 않습니다. 이 글은 mihomo(구 Clash Meta) 설정 문법을 기준으로 설명합니다. 다른 코어와 구버전에서는 지원하는 매개변수가 다를 수 있으므로, 설정을 편집하기 전에 클라이언트의 ‘정보’ 또는 코어 정보 화면에서 실제 사용 중인 코어를 확인하세요.

먼저 사용 목적에 맞는 유형을 고르세요. 지연 시간이 짧은 노드를 자동으로 선택하려면 url-test, 주 회선을 사용할 수 있을 때 계속 우선하려면 fallback, 여러 출구에 연결을 분산하려면 load-balance를 사용합니다. 세 유형 모두 연결 상태를 확인하지만, 확인 결과를 선택에 반영하는 방식은 서로 다릅니다.

유형 선택 기준 적합한 상황 주요 한계
url-test 후보 출구의 테스트 주소 응답 시간을 비교하고 허용 오차를 고려해 선택합니다. 일상적인 웹 탐색, 같은 지역 노드 중 자동 선택 테스트 지연 시간이 짧다고 대용량 다운로드 속도까지 빠른 것은 아닙니다.
fallback 목록 순서대로 확인해 처음으로 사용 가능한 출구를 선택합니다. 주·예비 회선 구성, 특정 지역 우선 우선 노드가 느려져도 계속 연결할 수 있다면 대개 예비 노드로 전환하지 않습니다.
load-balance 지정한 분배 알고리즘에 따라 사용 가능한 출구에 연결을 배정합니다. 여러 작업을 동시에 실행하거나 연결 부하를 분산할 때 단일 TCP 연결을 여러 회선으로 나눠 대역폭을 합산하지는 않습니다.

url-test 설정: 자동 선택과 전환 허용 오차

아래 예시는 현재 설정의 proxies 또는 프록시 제공자에 ‘홍콩-01’, ‘홍콩-02’, ‘일본-01’이라는 이름의 노드가 이미 있다고 가정합니다. 이 이름은 기존 노드를 참조하는 값이지, 노드 정의 전체가 아닙니다. 실제 설정에 있는 이름으로 바꿔야 합니다. 기존에 proxy-groups가 있다면 목록 항목을 추가하고, 같은 최상위 키를 새로 만들지 마세요.

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

interval과 tolerance의 역할

  • interval: 300: 주기 검사 간격은 300초, 즉 5분입니다. 300밀리초가 아닙니다.
  • tolerance: 50: 전환 허용 오차는 50밀리초입니다. 작은 지연 시간 변동으로 노드가 자주 바뀌는 것을 줄이는 값으로, 검사 시간 제한이나 지연 시간 상한이 아닙니다.
  • lazy: true: 지연 검사를 활성화합니다. 그룹을 사용하지 않을 때 주기 검사를 건너뛸 수 있습니다. 수동 속도 측정이나 최초 사용 시의 동작은 클라이언트와 코어 구현에 따라 달라질 수 있습니다.
  • url: 연결 상태와 지연 시간을 검사할 대상 주소입니다. 안정적이고 응답 데이터가 작으며, 실제로 이용할 네트워크 경로를 잘 반영하는 주소를 선택하세요.

예를 들어 현재 노드의 테스트 지연 시간이 110밀리초이고 다른 노드는 95밀리초라면, 차이는 15밀리초뿐입니다. 허용 오차를 50밀리초로 설정했을 때 매번 숫자가 가장 낮은 노드로 바뀌리라고 기대해서는 안 됩니다. 허용 오차는 지연 시간의 흔들림을 완화하는 값이지, 특정 시점에 반드시 전환된다는 보장이 아닙니다. 현재 노드에 연결할 수 없다면 코어는 이 두 지연 시간만으로 계속 판단할 수도 없습니다.

이 수치는 매개변수의 의미를 설명하기 위한 예시이며 실제 회선 측정 결과가 아닙니다. 테스트 주소의 TLS 핸드셰이크, 네트워크 혼잡, 서버 응답, 연결 재사용 여부에 따라 측정값이 달라집니다. 웹페이지 응답은 빠른데 다운로드가 느리다면 처리량, 패킷 손실, 저녁 시간대 혼잡을 추가로 확인하세요. 진단 대신 tolerance를 계속 0으로 낮추지는 마세요.

fallback 설정: 주·예비 순서 지정

fallback은 ‘목록에서 어느 노드를 먼저 사용할 수 있는가’를 기준으로 하며, ‘어느 노드가 가장 빠른가’를 기준으로 하지 않습니다. 주 회선을 사용할 수 있다면 예비 회선의 측정값이 더 낮아도 보통 주 회선을 계속 사용합니다. 지역, 요금 또는 출구를 우선해야 하는 경우에 적합합니다.

proxy-groups:
  - 주·예비 회선
    type: fallback
    proxies:
      - 홍콩-01
      - 홍콩-02
      - 일본-01
    url: https://www.gstatic.com/generate_204
    interval: 120
    lazy: true

이 순서에서는 홍콩-01이 최우선, 홍콩-02가 두 번째, 일본-01이 마지막 예비 노드입니다. 첫 번째 노드가 테스트 대상에 연결되지 않고 두 번째 노드는 정상이라면 그룹은 두 번째 노드를 선택합니다. 이후 검사에서 첫 번째 노드가 다시 사용 가능해지면 해당 노드를 우선 선택합니다.

자동 장애 전환이 연결을 끊김 없이 옮겨 주는 것은 아닙니다

  • 검사 주기가 120초라고 해서 어떤 장애든 120초 안에 복구된다는 뜻은 아닙니다. 검사 시작 시점, 탐색에 걸리는 시간, 애플리케이션 자체의 재시도도 영향을 줍니다.
  • 노드에서 테스트 주소가 열린다고 해서 실제 서비스 웹사이트에도 연결할 수 있는 것은 아닙니다. 지역 제한, 대상 사이트의 차단, 특정 사이트로 향하는 경로 문제는 검사에서 발견되지 않을 수 있습니다.
  • 정책 전환은 주로 새로 만드는 연결에 적용됩니다. 이미 연결된 다운로드, 동영상 재생, WebSocket 연결이 다른 회선으로 자동 이전되지는 않습니다.

load-balance 설정: 단일 연결의 대역폭을 합치는 것이 아니라 연결 분산

load-balance는 여러 연결이 동시에 발생하는 작업에 적합합니다. 아래 예시는 consistent-hashing을 사용해 후보 목록이 안정적인 동안 같은 대상이 가능한 한 같은 출구에 연결되도록 합니다. 같은 웹사이트의 출구가 자주 바뀌는 상황을 줄이는 데 도움이 되지만, IP 주소를 영구히 고정해 주지는 않습니다.

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

분배 알고리즘 선택하기

  • consistent-hashing: 대상 정보를 바탕으로 일관성 해싱 방식으로 분배합니다. 대상 도메인을 확인할 수 있는지, 후보 노드가 바뀌는지에 따라 분배 결과가 달라집니다.
  • round-robin: 연결을 순서대로 번갈아 배정합니다. 동작을 이해하기 쉽지만 연결 수가 비슷해도 트래픽 양은 다를 수 있으며, 각 회선이 같은 바이트 수를 처리한다고 보장하지 않습니다.

예를 들어 프로그램 하나가 다운로드 연결 8개를 동시에 만들면 부하 분산으로 각 연결이 서로 다른 노드에 배정될 수 있습니다. 서버가 연결 하나만 허용한다면 선택된 회선의 단일 연결 처리량만 이용할 수 있습니다. 브라우저는 HTTP/2를 사용해 하나의 연결에서 여러 요청을 처리하기도 하므로, 페이지에 리소스가 많다는 이유만으로 모든 노드를 고르게 사용한다고 판단할 수는 없습니다.

인터넷 뱅킹, 계정 관리, 특정 지역이 필요한 서비스에는 고정 노드나 고정 지역 정책을 우선 고려하세요. 일관성 해싱을 사용하더라도 노드가 오프라인이 되거나 후보 목록, 대상 도메인이 바뀌면 출구가 달라질 수 있습니다. 인증이 필요한 작업에서는 ‘분산’을 위해 후보 지역을 무리하게 늘리지 않는 것이 좋습니다.

정책 그룹 조합하기: 용도별 수동 선택 경로 유지

일상적인 설정에서는 세 가지 자동 그룹을 하나의 select 그룹에 넣을 수 있습니다. 기본값은 자동 최적 선택으로 두고, 우선순위를 고정해야 할 때는 주·예비 회선으로, 동시 작업에는 연결 분산으로 전환하세요. 아래 조각은 기존 proxy-groups 목록에 추가해야 합니다. rules는 마지막 기본 규칙만 보여 주는 별도 예시이므로 기존의 전체 트래픽 분기 규칙을 덮어쓰는 데 사용하면 안 됩니다.

proxy-groups:
  - 네트워크 출구
    type: select
    proxies:
      - 자동 최적 선택
      - 주·예비 회선
      - 동시 연결 분산
      - 홍콩-01

rules:
  - MATCH,네트워크 출구

위의 MATCH는 여기까지 와도 일치하는 규칙이 없는 모든 연결을 처리합니다. LAN, 한국 국내 사이트 또는 업무 전용 규칙을 유지하려면 이 규칙보다 앞에 배치하세요. 규칙은 일반적으로 위에서 아래 순서로 적용되므로 기본 규칙을 맨 앞에 두고 뒤에 있는 트래픽 분기 규칙도 적용되길 기대해서는 안 됩니다.

그룹 참조 이름은 정확히 일치해야 하며, 순환 참조가 생겨서도 안 됩니다. 예를 들어 ‘네트워크 출구’가 ‘자동 최적 선택’을 참조한다면, ‘자동 최적 선택’에서 다시 ‘네트워크 출구’를 참조할 수 없습니다. 처음 문제를 점검할 때는 수동 선택기 하나와 자동 그룹 하나로 구성하세요. 중첩이 지나치게 깊으면 속도 측정 경로와 최종 출구를 파악하기 어렵습니다.

구독 업데이트 후 설정 변경 사항 유지하기

  1. 현재 설정을 먼저 백업하고 노드 이름, 그룹 이름, 관련 규칙을 기록하세요.
  2. 클라이언트에서 설정 덮어쓰기, 병합 또는 확장 기능을 지원하는지 확인하세요. 구독으로 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다.
  3. proxy-providers를 사용한다면 클라이언트의 지원 여부에 따라 use로 제공자를 참조할 수 있습니다. 제공자 이름을 노드 이름으로 잘못 알고 proxies에 넣지 마세요.
  4. 구독을 업데이트한 뒤 노드 이름과 후보 목록이 바뀌었는지 확인하고, 설정 검사와 수동 속도 측정을 진행하세요.

자동 정책이 작동하지 않을 때 점검 순서

먼저 설정이 정상적으로 로드되는지 확인한 다음 실제 연결 경로를 추적하세요. DNS, TUN, 정책 유형, 테스트 주소를 한꺼번에 바꾸지 마세요. 한 번에 하나씩 변경해야 어떤 매개변수가 영향을 줬는지 확인하기 쉽습니다.

1단계: YAML 문법과 참조 관계 확인

들여쓰기에는 탭이 아닌 공백을 사용하고, 목록 항목 앞에 -를 넣으세요. 같은 파일에 최상위 proxy-groups를 중복 선언하지 마세요. mihomo 명령줄 프로그램이 로컬에 설치되어 있다면 아래 명령으로 설정을 검사할 수 있습니다. 명령에서 사용하는 파일 이름은 현재 디렉터리의 config.yaml입니다. 구독 파일 이름을 이 이름으로 바꾸라는 뜻은 아닙니다.

mihomo -t -f config.yaml

특정 프록시나 정책 그룹을 찾을 수 없다는 메시지가 나오면 먼저 이름 참조를 수정하세요. 문법 검사 통과는 설정을 파싱할 수 있다는 뜻일 뿐, 원격 노드에 연결할 수 있거나 테스트 주소가 정상이라는 보장은 아닙니다.

2단계: 트래픽이 대상 그룹으로 들어가는지 확인

클라이언트의 연결 목록에서 대상 도메인을 찾아 일치한 규칙, 정책 경로, 최종 노드를 확인하세요. 시스템 프록시는 해당 설정을 읽는 앱에만 영향을 줍니다. TUN은 가상 네트워크 인터페이스를 통해 일치하는 트래픽을 처리합니다. 어느 쪽도 fallback의 우선순위 알고리즘을 바꾸지는 않습니다. 앱의 트래픽이 코어에 들어오지 않는다면 정책 그룹의 매개변수를 바꿔도 해당 앱의 출구는 달라지지 않습니다.

설정에 실제로 mixed-port: 7890이 지정되어 있다면 아래 명령으로 로컬 프록시를 통해 웹페이지에 요청을 보낼 수 있습니다. 여기서 7890은 예시 수신 포트이므로 실제 설정과 일치해야 합니다. 외부 컨트롤 인터페이스 포트와 혼동하지 마세요.

curl -x http://127.0.0.1:7890 -I https://example.com

3단계: 속도 검사 문제와 서비스 연결 문제 구분

  • 모든 노드가 시간 초과로 표시됨: 모든 회선에 동시에 문제가 생겼다고 단정하지 말고, 먼저 로컬 네트워크와 노드 인증 정보, 테스트 대상에 연결할 수 있는지 확인하세요.
  • 자동 그룹에 지연 시간이 표시되는데 웹사이트는 열리지 않음: 대상 사이트의 DNS, 규칙 일치 결과, 연결 로그를 확인하고 문제가 해당 사이트에만 발생하는지 살펴보세요.
  • 몇 분 사이에 노드가 계속 바뀜: 먼저 같은 테스트 주소를 유지하고 url-test의 허용 오차를 적절히 높여 보세요. 예를 들어 20밀리초에서 50밀리초로 조정한 뒤 이후 검사 결과를 확인합니다.
  • 전환 후에도 기존 작업에 변화가 없음: 새 연결을 만들어 다시 시도하세요. 필요하다면 해당 연결만 종료하고, 진행 중인 모든 작업을 한꺼번에 중단하지 마세요.

선택 기준은 간단하게 유지할 수 있습니다. 지연 시간 우선은 url-test, 목록 순서 우선은 fallback, 연결 분산은 load-balance를 선택하세요. 규칙으로 트래픽 경로를 지정하고 수동으로 선택할 수 있는 출구도 남겨 두면 자동 그룹을 여러 겹으로 쌓는 것보다 관리하기 쉽습니다. 전체 문법은 사이트의 프로토콜 레퍼런스에서 확인하고, 처음 설정한다면 설치 및 설정 가이드부터 읽어 보세요.

Clash 다운로드