이 글의 목차
자동 선택에 원하는 결과는 서로 다를 수 있습니다. 지연 시간을 줄이려는 사람도 있고, 주 연결이 실패할 때만 예비 연결을 쓰려는 사람도 있으며, 로그인 세션 동안 접속 경로를 고정해야 하는 사람도 있습니다. 필요한 결과를 정한 뒤 정책 그룹과 테스트 방법을 선택하세요. 비슷해 보이는 설정도 장시간 연결과 계정 세션에는 다른 영향을 줄 수 있습니다.
url-test, fallback, select, load-balance 선택
정책 그룹의 선택 방식
| type | 결정 방식 | 적합한 상황 |
|---|---|---|
| select | 사용자가 수동으로 선택 | 진단, 고정 계정 출구, 중요한 장기 연결 |
| url-test | 상태 검사 지연 시간에 따라 선택 | 동급 노드의 일상적인 자동 선택 |
| fallback | 목록 순서에서 첫 번째 사용 가능 항목 선택 | 명확한 우선순위의 주/예비 전환 |
| load-balance | 정책에 따라 연결을 여러 항목에 분배 | 동시 트래픽을 분산하며 고정된 주·예비 순서대로 선택하지 않음 |
후보 노드: 사용 가능 여부, 필터링, 빈 목록
자동 그룹을 만들기 전에 select로 후보 노드를 고정하고 각 노드에서 실제 요청을 완료해 보세요. 현재 코어가 프로토콜을 지원하지 않거나 구독이 만료되었거나 로컬 네트워크에서 전혀 접근할 수 없는 노드는 후보에서 제외해야 합니다. 그렇지 않으면 상태 확인이 계속 실패하고 반복 오류가 쌓여 유용한 로그를 찾기 어려워집니다.
노드는 proxies에 직접 쓰거나 use로 proxy-providers를 참조할 수 있습니다. provider 업데이트로 후보 목록이 바뀌므로 이름 필터, 지역 필터, 빈 목록을 확인하고 노드 이름으로 지역이나 회선을 구분할 수 있게 하세요.
상태 점검 URL과 실제 서비스 요청
상태 검사는 각 후보 노드에서 url로 지정한 주소에 접속합니다. 주소 자체가 불안정하거나 일부 지역에서 거부되거나 로그인이 필요하면 전체 그룹 결과가 왜곡됩니다. 일반적으로 안정적이고 응답이 작으며 계정이 필요 없는 HTTPS 주소를 선택하세요. 예를 들어 204를 반환하는 탐지 페이지가 적합합니다.
시험 URL은 일상 접속 내용과 비슷한 것이 좋지만 개인 token이 포함된 API를 사용하거나 타사 사이트에 고빈도 요청을 보내지 마세요. 특정 노드의 탐지 성공은 당시 해당 URL에 접근할 수 있었다는 뜻일 뿐 영상, AI 스트리밍 응답, UDP는 각각 해당 앱에서 검증해야 합니다.
proxy-groups:
- name: 自动选择
type: url-test
include-all: true
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
lazy: trueinterval, tolerance, lazy와 점검 시간 초과
- interval
- 두 상태 검사 사이의 간격이며 단위는 초입니다. 너무 짧으면 트래픽과 서버 부담이 늘어납니다.
- tolerance
- url-test의 지연 시간 허용 범위이며 단위는 밀리초입니다. 차이가 크지 않을 때 현재 선택을 유지해 반복 전환을 줄입니다.
- lazy
- 그룹을 사용하지 않을 때 능동 검사를 줄이거나 중지하며 계속 사용하지 않는 정책 그룹에 적합합니다.
- timeout
- 일부 설정에서는 단일 탐지 대기 시간을 지정할 수 있습니다. 너무 짧으면 일시적인 느린 응답을 사용 불가로 판단합니다.
모든 네트워크에 맞는 매개변수 조합은 없습니다. 가정용 네트워크가 안정적이고 노드 지연 시간이 비슷하면 긴 interval과 적절한 tolerance를 사용할 수 있습니다. 모바일 네트워크가 자주 바뀌더라도 검사 간격을 몇 초로 줄이지 마세요. 새 요청의 접속 경로는 자주 바뀔 수 있지만 기존 연결이 끊기는지는 노드 장애와 클라이언트가 이전 연결을 종료하는지에 따라 달라집니다.
수정 후 일정 시간 실제로 사용해 보세요. Connections의 노드가 몇 분 안에 반복 전환되고 각 후보 차이가 수십 밀리초뿐이라면 노드를 더 추가하지 말고 tolerance 또는 interval부터 늘리세요.
fallback의 주 연결과 예비 연결 선택 순서
fallback은 두 번째 항목의 지연 시간이 낮다고 바로 이동하지 않습니다. 첫 항목이 상태 검사를 통과하는 동안 계속 사용하고 첫 항목을 사용할 수 없을 때만 뒤의 사용 가능 항목을 선택합니다. 따라서 설정 순서에 업무 선호도를 반영하세요. 안정적인 주 연결을 앞에 두고 비용이 높거나 지역이 다른 예비 연결을 뒤에 둡니다.
proxy-groups:
- name: 主线路
type: select
include-all: true
filter: "(?i)主线"
proxies: [DIRECT]
- name: 同区备用
type: select
include-all: true
filter: "(?i)同区备用"
proxies: [DIRECT]
- name: 异区备用
type: select
include-all: true
filter: "(?i)异区备用"
proxies: [DIRECT]
- name: 主备线路
type: fallback
proxies: [主线路, 同区备用, 异区备用]
url: https://www.gstatic.com/generate_204
interval: 300
lazy: true주 연결이 복원되면 fallback이 이후 상태 검사에서 다시 판단합니다. 전환할 때 기존 연결은 이동하지 않을 수 있고 새 요청에서 새 출구를 확인하기 쉽습니다. 계정 관리 페이지와 긴 다운로드에는 출구 변경이 세션에 영향을 주지 않도록 고정 select를 고려하세요.
지역별로 url-test와 fallback 조합
후보 노드가 많다면 모두 하나의 url-test에 넣을 필요는 없습니다. 지역별로 url-test를 만든 뒤 지역 그룹을 우선순위대로 fallback에 추가하세요. 각 지역에서 지연 시간이 낮은 노드를 선택하고, 현재 지역을 사용할 수 없으면 다음 지역으로 전환합니다. Connections에서는 요청이 거친 정책 그룹도 확인할 수 있습니다.
그룹을 많이 중첩할수록 빈 provider, 순환 참조, 중복 그룹 이름을 찾기 어려워집니다. 두 단계로 충분하다면 세 번째 단계를 추가하지 마세요. 각 지역 그룹이 독립적으로 작동하는지 확인한 뒤 주·예비 선택 그룹에 넣으세요.
proxy-groups:
- name: 香港自动
type: url-test
include-all: true
filter: "(?i)香港|HK"
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
- name: 日本自动
type: url-test
include-all: true
filter: "(?i)日本|JP"
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
- name: 地区主备
type: fallback
proxies: [香港自动, 日本自动]
url: https://www.gstatic.com/generate_204
interval: 300별도 테스트 그룹에서 선택과 장애 시 전환 관찰
앞의 YAML 조각은 정책 그룹만 정의합니다. 전체 설정의 사본을 편집해 기존 proxy-groups 목록에 새 그룹을 추가하고 원래 노드, proxy-providers, rules는 유지하세요. 설정 전체를 조각으로 바꾸거나 proxy-groups 키를 중복 작성하지 마세요.
Clash Verge Rev v1.6.2 이후 버전에서는 전체 YAML 사본을 클라이언트로 끌어 넣어 로컬 설정을 만든 뒤 사용하도록 선택하세요. 새 그룹이 Proxies에 표시되어야 합니다. 불러오지 못하면 원래 설정을 다시 선택하고 로그를 확인하세요. 원래 구독 파일은 덮어쓰지 마세요.
일상 세션을 방해하지 않는 검증 방법
설정 사본의 별도 테스트 그룹 사용
다운로드, 회의 또는 중요 계정 로그인 중에는 전환을 시험하지 마세요.
상태 검사 한 번 수동 실행
각 후보의 결과와 현재 선택 항목을 기록하세요. 예시의 하위 select 그룹은 DIRECT가 아니라 실제 프록시 노드를 선택해야 합니다.
브라우저에서 해당 정책 그룹 사용
Connections에 상위 그룹, 하위 노드, 실제 출구가 표시되어야 합니다.
다음 검사 주기 관찰
url-test는 허용 범위 안에서 유지되는지, fallback은 목록 앞 항목을 우선하는지 확인합니다.
fallback을 시험할 때는 사용 불가임을 확인했고 민감한 정보가 없는 시험 노드를 잠시 맨 앞에 두어 독립 그룹에서 두 번째 항목으로 이동하는지 볼 수 있습니다. 완료 후 즉시 제거하세요. 인터넷을 끊거나 시스템 프록시를 끄거나 운영 설정을 망가뜨려 장애를 만들지 마세요. 너무 많은 변수가 동시에 바뀝니다.
빈 목록, 점검 실패, 잦은 노드 변경 처리
그룹이 비어 보임
proxies / use 참조, provider 업데이트 시각, 노드 필터링 결과를 확인하세요.
모든 후보가 Timeout
health URL을 따로 시험하고 현재 네트워크와 실제 노드 요청을 비교하세요.
url-test가 두 노드 사이에서 계속 전환함
tolerance 또는 interval을 늘리고 탐지 주소가 안정적인지 확인하세요.
fallback이 항상 두 번째 항목을 선택함
첫 항목이 상태 검사를 통과하지 못했습니다. 순서를 바꾸지 말고 구체적인 오류를 확인하세요.
전환 후 계정 로그인을 자주 다시 요구함
민감한 세션을 고정 select 그룹에 넣어 출구 자동 변경을 피하세요.
provider 업데이트 후 그룹이 갑자기 비어 있음
필터 표현식과 새 노드 이름을 대조하세요. 기존 캐시가 이전 문제를 가렸을 수 있습니다.
웹페이지, 긴 응답, 다운로드로 자동 그룹 검증
대상 서비스 규칙을 자동 그룹으로 지정하고 웹 요청, 스트리밍 응답 또는 다운로드를 여러 번 연속 완료하세요. Connections에 예상 상위 그룹과 구체적인 노드가 보여야 합니다. url-test는 작은 지연 차이로 자주 움직이지 않아야 하고 fallback은 주 연결을 사용할 수 있을 때 첫 항목을 유지해야 합니다.
상태 점검은 정상인데 원래 작업은 실패하면 select로 바꿔 현재 노드를 고정하고 다시 테스트한 뒤 프로토콜, DNS, 대상 서비스를 확인하세요.