Clash 프록시 그룹 url-test·fallback·load-balance 설정 가이드
select, url-test, fallback, load-balance 그룹의 선택 방식과 주요 옵션을 살펴보고, 바로 수정해 쓸 수 있는 proxy-groups 예제를 확인하세요.
규칙, 프록시 그룹, 노드의 역할 구분하기
Clash 설정에서 rules는 연결을 어느 프록시 그룹으로 보낼지 정하고, proxy-groups는 해당 그룹에서 어떤 노드나 하위 그룹을 출구로 선택할지 정합니다. proxies와 proxy-providers는 선택 가능한 노드를 제공합니다. 규칙은 적용됐는데 출구가 예상과 다르다면 노드 목록만 확인하지 말고, 규칙이 가리키는 그룹과 그룹에서 현재 선택된 항목을 먼저 살펴보세요.
그룹의 type에 따라 선택 방식이 달라집니다. select는 직접 선택하고, url-test는 탐지 지연 시간을 기준으로 자동 선택하며, fallback은 목록 순서대로 사용 가능한 항목을 고릅니다. load-balance는 사용 가능한 노드에 연결을 분산합니다. 이 그룹들은 모두 규칙의 대상으로 지정할 수 있지만, 자동 선택이 구독의 노드를 수정하거나 규칙의 적용 순서를 바꾸는 것은 아닙니다.
| 유형 | 선택 기준 | 사용 사례 |
|---|---|---|
select | 클라이언트에서 직접 선택한 항목 | 수동으로 출구를 지정하거나 직접 연결을 유지할 때 |
url-test | 탐지 결과에서 지연 시간이 가장 짧은 항목 | 일상적인 웹 탐색에 빠른 노드를 자동으로 선택할 때 |
fallback | 목록에서 가장 앞에 있는 사용 가능한 항목 | 지정한 노드를 우선 사용하고, 사용할 수 없을 때 전환할 때 |
load-balance | 설정한 분배 방식과 노드의 사용 가능 여부 | 여러 노드에 연결을 나눠 보낼 때 |
select: 출구를 직접 선택하기
select는 보통 규칙과 다른 프록시 그룹 사이에 둡니다. 예를 들어 규칙이 '수동 선택'을 가리키도록 하고, 그룹에는 '자동 최적 선택', '장애 전환', 개별 노드와 DIRECT를 함께 넣을 수 있습니다. 규칙을 수정하지 않아도 클라이언트의 '프록시' 화면에서 출구를 바꿀 수 있습니다. DIRECT는 프록시를 거치지 않고 직접 연결한다는 뜻입니다. 그룹에 추가해 두면 프록시 연결과 직접 연결 결과를 비교할 때 명확한 선택지가 됩니다.
select는 지연 시간을 기준으로 항목을 자동 변경하지 않습니다. 목록에 자동 그룹과 개별 노드가 함께 있다면 '자동 최적 선택'을 골랐을 때 하위 url-test 그룹이 구체적인 노드를 결정합니다. 구독이 업데이트되거나 그룹 이름이 바뀌면 클라이언트에 표시되는 선택 항목을 다시 확인해야 할 수 있습니다. 설정을 업데이트한 뒤에는 그룹에 필요한 항목이 남아 있는지 확인하고 실제 출구도 점검하세요.
url-test: 속도가 아닌 탐지 지연 시간으로 선택
url-test에서 url은 탐지 주소를, interval은 탐지 간격을 초 단위로 지정합니다. 예를 들어 interval: 300은 300초마다 정기적으로 탐지한다는 뜻입니다. 클라이언트에 표시되는 지연 시간은 탐지 요청의 응답 시간으로, 다운로드 속도가 아니며 동영상 전송 속도를 단독으로 판단하는 기준도 아닙니다. 안정적으로 응답하는 주소를 사용해야 합니다. 예시에는 널리 쓰이는 https://www.gstatic.com/generate_204를 사용했습니다. 현재 네트워크나 노드에서 이 주소에 접속할 수 없다면, 직접 접속 여부를 확인한 가벼운 주소로 바꾸세요. 그렇지 않으면 지연 시간 탐지가 계속 실패할 수 있습니다.
tolerance: 50은 선택 허용 오차를 50밀리초로 설정해 지연 시간이 비슷한 노드 사이에서 선택이 자주 바뀌는 것을 줄입니다. 연결 시간 제한이 아니며, '50밀리초를 넘으면 장애로 판단한다'는 뜻도 아닙니다. 로그인 상태가 출구 IP 변경에 민감한 서비스처럼 고정 IP가 필요한 경우에는 최저 탐지 지연 시간에만 의존하지 말고 select에서 특정 노드를 직접 지정하세요.
fallback: 목록 순서가 우선순위
fallback도 url과 interval로 각 항목의 사용 가능 여부를 확인하지만, 지연 시간이 가장 짧은 항목을 고르지는 않습니다. 예를 들어 후보 순서가 '홍콩 01', '홍콩 02', '일본 01'이라면 '홍콩 02'의 탐지 지연 시간이 더 짧아도 '홍콩 01'을 사용할 수 있는 동안에는 해당 노드를 우선 사용합니다. 첫 번째 항목을 사용할 수 없을 때 다음 항목을 순서대로 시도합니다.
따라서 fallback은 주 노드와 예비 노드를 정해 둘 연결에 적합합니다. 계속 사용할 노드를 앞에, 예비 노드를 뒤에 배치하세요. 노드 이름만 보고 순서를 정하지 말고 필요한 서비스에서 실제로 사용할 수 있는지도 확인해야 합니다. 탐지에 실패했을 때의 전환은 상태 확인 결과에 따라 이뤄지며, 웹 요청이 발생할 때마다 즉시 재시도하는 방식은 아닙니다. 이미 연결된 세션이 새 노드로 자동 이동한다고 보장할 수도 없습니다.
load-balance: 연결 분산, 단일 연결 대역폭 합산은 아님
load-balance는 여러 사용 가능한 노드에 연결을 분산합니다. mihomo 설정의 strategy: consistent-hashing은 일관성 해싱 방식으로, 같은 대상이 같은 노드에 연결되는 경향이 있습니다. strategy: round-robin은 차례대로 노드를 선택합니다. 분산 대상은 연결입니다. 파일 하나를 여러 회선으로 나눠 동시에 전송하는 기능이 아니므로, 여러 노드의 표시 대역폭을 더해 단일 연결의 속도로 간주할 수 없습니다.
전략은 사용 사례에 맞춰 선택하세요. 같은 사이트에서 출구를 최대한 유지하고 싶다면 consistent-hashing부터 시도하고, 서로 독립적인 여러 요청에 노드를 차례로 할당하려면 round-robin을 테스트해 볼 수 있습니다. 로그인, 결제 또는 고정된 접속 주소가 필요한 서비스에서는 출구가 바뀌면 추가 인증이 발생할 수 있습니다. 이런 경우 탐지 간격을 계속 줄이기보다 개별 노드나 fallback을 사용하는 편이 간단합니다.
수정해서 사용할 수 있는 proxy-groups 설정
아래 예시는 현재 설정의 proxies 또는 프록시 제공자에 '홍콩 01', '홍콩 02', '일본 01'이라는 노드가 이미 있다고 가정합니다. 붙여넣기 전에 이 세 이름을 설정에 실제로 등록된 노드 이름으로 정확히 바꾸세요. 이름에 들어간 공백도 일치해야 합니다. 예시의 proxy-groups와 rules는 최상위 필드이므로 특정 노드 아래에 들여쓰지 마세요. 파일에 같은 이름의 최상위 필드가 이미 있다면 내용을 병합하고 두 번째 항목을 추가하지 마세요.
proxy-groups:
- name: 자동 최적 선택
type: url-test
proxies:
- 홍콩 01
- 홍콩 02
- 일본 01
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
- name: 장애 전환
type: fallback
proxies:
- 홍콩 01
- 홍콩 02
- 일본 01
url: https://www.gstatic.com/generate_204
interval: 300
- name: 부하 분산
type: load-balance
proxies:
- 홍콩 01
- 홍콩 02
- 일본 01
url: https://www.gstatic.com/generate_204
interval: 300
strategy: consistent-hashing
- name: 수동 선택
type: select
proxies:
- 자동 최적 선택
- 장애 전환
- 부하 분산
- 홍콩 01
- DIRECT
rules:
- MATCH,수동 선택
MATCH는 기본 규칙이므로 기존 규칙의 맨 마지막에 둡니다. 예시의 rules로 기존 파일을 그대로 덮어쓰면 원래의 트래픽 분기 규칙은 더 이상 적용되지 않습니다. 기존 분기 규칙을 유지하려면 각 규칙의 대상 그룹 이름만 '수동 선택'으로 바꾸고 원래 순서를 그대로 두세요. '부하 분산'을 순환 방식으로 사용하려면 커널이 지원하는지 확인한 다음 strategy를 round-robin으로 바꾸세요.
프록시 제공자를 사용하는 경우
노드가 설정의 proxies에 직접 나열되지 않고 proxy-providers에서 제공된다면, use로 기존 제공자 이름을 그룹에 지정할 수 있습니다. 예를 들어 최상위 제공자 키가 main-provider라면 해당 그룹에 use: [main-provider]를 작성합니다. 먼저 제공자가 정상적으로 로드됐는지 확인한 다음 그룹에 노드가 표시되는지 확인하세요. use만 작성한다고 구독이 생성되거나 구독 주소가 입력되지는 않습니다. 수동 노드도 함께 추가하려면 사용하는 커널에서 지원하는 문법에 따라 같은 그룹에 use와 proxies를 각각 설정하세요.
가져온 뒤 확인할 순서
- 먼저 문법과 이름을 확인하세요. YAML은 공백으로 들여쓰며,
type,proxies,url,interval은 같은 그룹에 속해야 합니다. 노드를 찾을 수 없다는 메시지가 나오면 항목 이름을 하나씩 대조하세요. 필드 중복 메시지가 나오면 최상위proxy-groups나rules를 두 번 붙여 넣지 않았는지 확인하세요. - 다음으로 상태 확인을 살펴보세요. 클라이언트의 '프록시' 화면에서 '자동 최적 선택'이나 '장애 전환'을 열고 지연 시간 테스트를 실행해 세 노드의 결과를 확인하세요. 전부 실패하면 탐지 주소에 접속할 수 있는지와 노드 자체가 연결되는지부터 확인하세요. 바로
interval: 300을 더 짧은 값으로 바꾸지는 마세요. - 마지막으로 트래픽 경로를 확인하세요. '프록시' 화면에서 '수동 선택'과 하위 그룹을 선택하고 클라이언트의 프록시 연결 기능이 활성화됐는지 확인한 다음 대상 사이트에 접속하세요. 규칙 모드라면 연결 기록에서 어떤 규칙이 적용됐는지 확인하세요. 전역 모드나 직접 연결 모드에서는
rules의MATCH만으로 실제 출구를 판단할 수 없습니다.
출구를 고정하려면 select, 탐지 지연 시간을 우선하려면 url-test, 주 노드와 예비 노드의 순서를 지정하려면 fallback, 여러 노드에 연결을 분배하려면 load-balance를 사용하세요. 네 가지 그룹은 하나의 설정에서 함께 사용할 수 있습니다. 규칙이 올바른 그룹을 가리키는지 확인하고, 구독 업데이트 후에는 노드 이름과 탐지 결과, 현재 선택 항목을 다시 점검하세요.