이 글의 목차
"자동"은 낮은 지연 시간을 좇거나 주 회선을 유지하는 방식일 수 있습니다
url-test와 fallback 모두 상태 검사를 하지만 결정 목표가 다릅니다. url-test는 후보 노드의 탐지 지연 시간을 비교해 조건을 만족하는 낮은 결과를 선택합니다. fallback은 설정 순서에서 첫 번째 사용 가능 노드를 쓰고 현재 항목이 실패할 때만 뒤로 전환합니다.
전자는 동등한 노드 그룹에서 낮은 지연 시간을 선호할 때 적합하고 후자는 "주 회선 우선, 예비 회선 보완"에 적합합니다. 직접 노드를 선택하려면 select를 사용하세요. 여러 회선에 연결을 분배하려면 load-balance이며 fallback으로 대신할 수 없습니다.
목적에 따라 정책 그룹부터 선택
| type | 결정 방식 | 적합한 상황 |
|---|---|---|
| select | 사용자가 수동으로 선택 | 진단, 고정 계정 출구, 중요한 장기 연결 |
| url-test | 상태 검사 지연 시간에 따라 선택 | 동급 노드의 일상적인 자동 선택 |
| fallback | 목록 순서에서 첫 번째 사용 가능 항목 선택 | 명확한 우선순위의 주/예비 전환 |
| load-balance | 정책에 따라 연결을 여러 항목에 분배 | 동시 트래픽 분산용이며 장애 조치를 담당하지 않음 |
자동 그룹은 후보 안에서만 선택하며 잘못된 목록을 저절로 고치지는 못합니다
자동 그룹을 만들기 전에 select로 후보 노드를 하나씩 고정해 실제 요청을 완료하세요. 현재 커널이 프로토콜을 지원하지 않거나 구독이 만료되었거나 로컬 네트워크에서 완전히 접근할 수 없는 노드는 후보에서 먼저 제거해야 합니다. 그렇지 않으면 상태 검사가 계속 오류를 내고 로그가 쓸모없는 결과로 가득 찹니다.
노드는 proxies에 직접 작성하거나 use로 proxy-providers를 참조할 수 있습니다. provider 업데이트 후 새 노드가 후보에 들어오므로 이름 필터링, 지역 필터링, 빈 목록을 확인하세요. 그룹이 존재한다고 표시되어도 실제 항목이 있다는 뜻은 아닙니다.
후보 목록의 조건
- 각 노드가 고정 선택 상태에서 실제 요청을 완료했음
- 노드 이름으로 지역 또는 회선을 구분할 수 있고 대량의 같은 이름 항목이 아님
- provider가 현재 업데이트에 성공했고 필터링 후 비어 있지 않음
- 중요 계정에 고정 출구가 필요할 때 별도 select 그룹을 남김
시험 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 하나에 넣을 필요는 없습니다. 지역별 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: 300url-test는 선택 과정을 검증하고 fallback은 전환 순서를 검증하세요
일상 세션을 방해하지 않는 검증 방법
별도 시험 그룹 생성 또는 사용
다운로드, 회의 또는 중요 계정 로그인 중에는 전환을 시험하지 마세요.
상태 검사 한 번 수동 실행
각 후보의 결과와 현재 선택 항목을 기록합니다.
브라우저에서 해당 정책 그룹 사용
Connections에 상위 그룹, 하위 노드, 실제 출구가 표시되어야 합니다.
다음 검사 주기 관찰
url-test는 허용 범위 안에서 유지되는지, fallback은 목록 앞 항목을 우선하는지 확인합니다.
fallback을 시험할 때는 사용 불가임을 확인했고 민감한 정보가 없는 시험 노드를 잠시 맨 앞에 두어 독립 그룹에서 두 번째 항목으로 이동하는지 볼 수 있습니다. 완료 후 즉시 제거하세요. 인터넷을 끊거나 시스템 프록시를 끄거나 운영 설정을 망가뜨려 장애를 만들지 마세요. 너무 많은 변수가 동시에 바뀝니다.
자동 그룹이 작동하지 않으면 후보 목록, 탐지 또는 참조에 오류가 있는 경우가 많습니다
그룹이 비어 보임
proxies / use 참조, provider 업데이트 시각, 노드 필터링 결과를 확인하세요.
모든 후보가 Timeout
health URL을 따로 시험하고 현재 네트워크와 실제 노드 요청을 비교하세요.
url-test가 두 노드 사이에서 계속 전환함
tolerance 또는 interval을 늘리고 탐지 주소가 안정적인지 확인하세요.
fallback이 항상 두 번째 항목을 선택함
첫 항목이 상태 검사를 통과하지 못했습니다. 순서를 바꾸지 말고 구체적인 오류를 확인하세요.
전환 후 계정 로그인을 자주 다시 요구함
민감한 세션을 고정 select 그룹에 넣어 출구 자동 변경을 피하세요.
provider 업데이트 후 그룹이 갑자기 비어 있음
필터 표현식과 새 노드 이름을 대조하세요. 기존 캐시가 이전 문제를 가렸을 수 있습니다.
실제 요청으로 자동 그룹을 유지할 가치가 있는지 판단하세요
대상 서비스 규칙을 자동 그룹으로 지정하고 웹 요청, 스트리밍 응답 또는 다운로드를 여러 번 연속 완료하세요. Connections에 예상 상위 그룹과 구체적인 노드가 보여야 합니다. url-test는 작은 지연 차이로 자주 움직이지 않아야 하고 fallback은 주 회선을 사용할 수 있을 때 첫 항목을 유지해야 합니다.
상태 검사가 모두 정상인데 원래 작업은 실패한다면 현재 노드를 고정해 다시 시험하고 프로토콜, DNS 또는 대상 서비스로 돌아가세요. 자동 그룹을 유지할 기준은 간단합니다. 작업이 안정적이고 출구 변화를 설명할 수 있으며 주/예비 순서가 예상과 맞아야 합니다. 탐지 페이지만 정상 색상이 되었다고 설정 완료는 아닙니다.