Clash 프록시 그룹 유형 비교: url-test, fallback, load-balance 선택법

Clash 설정에서 프록시 그룹은 규칙과 개별 프록시 노드 사이에 있습니다. 규칙이 연결의 트래픽 유형을 판단하면 프록시 그룹이 해당 연결을 처리할 노드를 최종 결정합니다. 프록시 그룹을 단순한 ‘노드 폴더’로 이해하면 잘못 판단하기 쉽습니다. 그룹 유형마다 선택 조건과 상태 확인 방식, 장애 처리 순서가 다르므로 이름이 비슷하다고 동작까지 같은 것은 아닙니다.

url-test, fallback, load-balance는 모두 여러 프록시를 참조할 수 있지만 용도는 서로 다릅니다. 첫 번째는 테스트 결과가 더 좋은 노드를 찾고, 두 번째는 미리 정한 우선순위에 따라 예비 회선을 유지하며, 세 번째는 서로 다른 연결을 사용 가능한 여러 노드에 분산합니다. 선택하기 전에 클라이언트 화면의 지연 시간 수치만 보지 말고, 평소 지연 시간을 줄일지, 출구 우선순위를 유지할지, 동시 연결을 분산할지부터 명확히 정해야 합니다.

라우팅 규칙에서 프록시 그룹의 위치

요청이 Clash 또는 Mihomo에 들어오면 일반적으로 DNS 및 인바운드 처리를 거친 뒤 설정된 규칙과 위에서 아래로 대조됩니다. 규칙 대상에는 개별 노드나 프록시 그룹을 지정할 수 있습니다. 실제 설정에서는 보통 그룹 이름을 대상으로 지정합니다. 예를 들어 개발 서비스는 ‘웹 자동 선택’, 업무 시스템은 ‘업무 주·예비 회선’, 대량의 독립적인 다운로드 작업은 ‘다운로드 분산’ 그룹으로 보낼 수 있습니다.

프록시 그룹은 규칙에 의해 해당 그룹으로 전달된 연결만 처리합니다. 속도 테스트 그룹을 여러 개 만들어도 규칙의 최종 대상이 DIRECT라면 연결은 그대로 직접 접속합니다. 최종적으로 MATCH 규칙에 걸려 다른 그룹으로 들어간 경우에도 앞에 있는 속도 테스트 그룹은 사용되지 않습니다. 따라서 ‘노드는 정상인데 트래픽이 해당 노드를 거치지 않는’ 문제를 해결할 때는 노드 목록만 보지 말고 규칙 일치 기록과 프록시 그룹의 현재 선택을 함께 확인해야 합니다.

자동 그룹과 수동 select 그룹의 관계

select는 흔히 사용하는 수동 선택 그룹이며 자동 그룹을 선택 항목으로 넣을 수 있습니다. 평소에는 자동 선택을 사용하다가 특정 웹사이트가 출구를 제한할 때 고정 노드로 임시 전환할 수 있습니다. 자동 그룹도 다른 그룹에서 참조할 수 있지만 중첩 단계가 많아지면 문제 해결이 어려워집니다. 그룹 이름은 ‘웹 자동 선택’, ‘업무 주·예비 회선’, ‘다운로드 분산’처럼 용도가 드러나게 지정하고 ‘그룹 1’, ‘그룹 2’처럼 모호하게 짓지 않는 것이 좋습니다.

url-test: 테스트 결과에 따른 자동 선택

url-test는 코어가 그룹 안의 후보 프록시를 대상으로 지정된 URL을 테스트하고, 그 결과를 바탕으로 성능이 더 좋은 노드를 선택하게 합니다. 지연 시간이 높은 회선을 자동으로 피하고 싶은 웹 브라우징, 코드 호스팅, 소프트웨어 업데이트 같은 일상 트래픽에 적합합니다. 여기서 ‘더 좋다’는 평가는 주로 테스트 요청의 응답 시간과 사용 가능 여부를 기준으로 하며, 대역폭과 패킷 손실, 사용량이 몰리는 저녁 시간대의 안정성까지 종합적으로 평가하는 것은 아닙니다.

테스트 URL은 안정적이고 응답 본문이 작으며 성공 상태를 명확히 반환해야 합니다. 많은 설정이 빈 콘텐츠를 반환하는 HTTP 엔드포인트를 사용하는 이유는 테스트 트래픽을 줄이기 위해서입니다. 테스트 주소가 일부 네트워크 환경에서 리디렉션되거나 속도 제한 또는 별도 최적화의 영향을 받으면 측정 순위가 실제 서비스 성능과 달라질 수 있습니다. 테스트 주소를 바꿀 때는 모든 후보 회선이 해당 엔드포인트에 같은 조건으로 접근할 수 있는지 확인해야 합니다.

proxy-groups:
  - name: 웹 자동 선택
    type: url-test
    proxies:
      - 노드-A
      - 노드-B
      - 노드-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

interval은 주기적인 테스트 간격을 나타내며 단위는 일반적으로 초입니다. 간격이 너무 짧으면 요청 수가 늘어나고 사소한 네트워크 변동에도 선택 결과가 바뀔 수 있습니다. 반대로 너무 길면 노드 장애가 발생한 뒤 상태 갱신이 늦어질 수 있습니다. 일반 단말에서는 수십 초마다 확인하는 것보다 몇 분 간격으로 확인하는 편이 대체로 안정적이며, 구체적인 값은 노드 수와 기기 성능을 고려해 정해야 합니다.

tolerance는 전환에 허용 오차를 적용하는 옵션입니다. 현재 노드와 후보 노드의 차이가 허용 오차를 넘지 않으면 기존 선택을 유지하여 잦은 전환을 줄일 수 있습니다. 현재 결과가 125ms이고 다른 노드가 90ms라고 가정할 때 허용 오차가 50ms라면 차이가 기준보다 작아 전환되지 않습니다. 차이가 계속 커져 기준을 넘어야 자동 그룹이 선택을 변경할 근거가 생깁니다. 코어 버전과 클라이언트에 따라 옵션 표시가 조금씩 다를 수 있으므로 실제 사용하는 Mihomo 또는 Clash 코어 문서를 기준으로 확인해야 합니다.

lazy를 활성화하면 일반적으로 그룹이 실제로 사용될 때 상태 확인을 수행하는 쪽으로 동작하여 사용하지 않는 그룹의 주기적인 테스트를 줄일 수 있습니다. 지역별 그룹은 많지만 평소에는 일부만 사용하는 설정에 적합합니다. 장애를 빠르게 감지해야 하는 핵심 연결을 담당하는 그룹이라면 감지 지연과 백그라운드 테스트 부하를 함께 고려해야 합니다.

fallback: 우선순위에 따른 주·예비 회선 유지

fallback의 핵심은 ‘가장 빠른 항목 선택’이 아니라 ‘목록에서 처음으로 사용 가능한 항목 선택’입니다. 앞에 배치된 노드의 우선순위가 더 높으며, 상태 확인에서 사용 가능하다고 판단되는 동안에는 계속 해당 노드를 사용합니다. 현재 우선 항목에 장애가 생겨야 뒤쪽의 사용 가능한 노드를 찾습니다. 출구 IP, 지역 또는 회선 안정성이 몇 ms의 지연 시간보다 중요한 상황에 적합합니다.

예를 들어 업무 서비스에서 특정 지역의 출구를 계속 사용해야 한다면 주 노드를 첫 번째, 같은 지역의 예비 노드를 두 번째, 다른 지역의 비상 노드를 마지막에 둘 수 있습니다. 예비 노드의 테스트 지연 시간이 더 낮아도 정상 동작 중인 주 노드보다 먼저 선택되지는 않습니다. 출구 변경은 줄어들지만, 주 노드가 ‘연결은 되지만 체감 품질이 나쁜’ 상태일 때 자동으로 전환되지 않을 수 있습니다.

proxy-groups:
  - name: 업무 주·예비 회선
    type: fallback
    proxies:
      - 주 회선
      - 동일 지역 예비 회선
      - 다른 지역 비상 회선
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

‘사용 가능’ 여부는 상태 확인 결과에 따라 정해지며, 상태 확인은 지정된 엔드포인트만 관찰할 수 있습니다. 어떤 노드가 테스트 URL에는 접속할 수 있지만 특정 서비스 도메인에는 접속하지 못해도 fallback이 해당 노드를 계속 유지할 수 있습니다. 이 경우 대상 도메인이 올바른 규칙에 걸리는지 먼저 확인한 다음 DNS 조회, 대상 사이트의 제한, 회선의 특정 프로토콜 지원 여부를 점검해야 합니다. 테스트 간격만 줄인다고 서비스 엔드포인트 불일치 문제가 해결되지는 않습니다.

주 회선이 복구되면 그룹이 목록 앞쪽 노드로 다시 돌아갈 수 있습니다. 회선이 사용 가능과 불가능 상태를 반복하면 복귀 전환이 계속 발생합니다. 더 안정적인 테스트 엔드포인트를 선택하고, 적절한 확인 간격을 늘리며, 불안정한 노드를 최우선 항목으로 두는 것이 맞는지 재검토하면 이를 완화할 수 있습니다. 현재 사용 가능한 출구를 수동으로 바꿀 때까지 계속 유지하는 것이 목적이라면 자동 장애 조치보다 수동 select 그룹이 더 적합합니다.

잘못된 장애 조치의 흔한 원인

• 목록 순서가 실제 주·예비 의도와 반대로 되어 있어 낮은 우선순위의 회선이 맨 앞에 배치되어 있습니다.
• 상태 확인 주소에는 특정 회선으로 접속할 수 없지만 실제 서비스 주소에는 접속할 수 있어 노드가 너무 일찍 사용 불가로 판정됩니다.
• 구독 업데이트 후 노드 이름이 바뀌어 정적 그룹의 참조가 끊기거나 다른 노드를 가리킵니다.
• 규칙이 해당 fallback 그룹으로 연결을 보내지 않아 실제 출구가 다른 그룹이나 최종 기본 규칙에서 선택됩니다.
• 클라이언트 화면에 이전 상태가 캐시되어 코어의 실제 선택과 표시 갱신이 일치하지 않습니다. 연결 기록을 확인해야 합니다.

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

load-balance는 여러 개의 독립적인 연결을 대상으로 합니다. 코어는 부하 분산 방식에 따라 그룹 안의 사용 가능한 노드 중 하나를 연결별로 선택합니다. 여러 노드의 대역폭을 하나의 더 넓은 통로로 합치는 방식이 아니며, 단일 TCP 연결의 패킷을 여러 출구에 임의로 나누지도 않습니다. 단일 파일 다운로드가 하나의 연결만 사용한다면 일반적으로 한 노드가 전부 처리합니다. 다중 연결 다운로드나 여러 동시 요청, 여러 기기의 동시 접속에서 분산 효과를 더 쉽게 확인할 수 있습니다.

Mihomo에서 흔히 사용하는 부하 분산 방식에는 consistent-hashing과 round-robin이 있습니다. 일관된 해싱은 동일한 대상의 연결이 계속 같은 노드로 향하게 하는 경향이 있어, 같은 사이트의 출구가 짧은 시간 동안 자주 바뀌는 현상을 줄이는 데 유리합니다. 라운드 로빈은 연결마다 사용 가능한 노드를 차례로 선택하여 더 직접적으로 분산하지만, 동일한 서비스에 대한 여러 연결이 서로 다른 출구를 사용할 수 있습니다.

proxy-groups:
  - name: 다운로드 분산
    type: load-balance
    proxies:
      - 노드-A
      - 노드-B
      - 노드-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

로그인 상태에 민감하거나 출구 IP를 검사하는 서비스에는 일반적으로 라운드 로빈보다 일관된 해싱이 안전합니다. 일부 웹사이트는 로그인 세션과 보안 위험 상태, 지역별 콘텐츠를 출구 IP와 연결합니다. 페이지 리소스와 API 요청이 서로 다른 노드로 전달되면 반복 인증, 지역 변경, 세션 만료가 발생할 수 있습니다. 일관된 해싱을 사용해도 도메인이 다른 리소스는 서로 다른 노드에 배정될 수 있으므로 금융 서비스, 기업 로그인, 고정 출구가 필요한 업무에는 고정 노드나 fallback이 더 적합합니다.

라운드 로빈은 출구 변경을 허용할 수 있는 대량의 독립적인 연결에 적합합니다. 여러 소프트웨어 패키지 다운로드, 분산된 공개 리소스 요청, LAN 내 여러 기기에서 발생하는 다수의 민감하지 않은 연결이 이에 해당합니다. 전체 처리량 향상 여부는 로컬 인터넷 회선의 대역폭, 원격 서버 제한, 노드의 업스트림 용량, 동시 연결 방식에도 달려 있습니다. 병목 지점이 가정용 인터넷 회선이나 대상 서버라면 노드 수를 늘려도 그 한계를 넘을 수 없습니다.

구독 노드와 상태 확인 연동 방식

노드를 구독으로 가져오는 경우 일반적으로 proxy-providers로 원격 공급자를 관리하고 여러 프록시 그룹에서 use를 통해 동일한 공급자를 참조합니다. 그러면 구독이 업데이트될 때 새 노드가 해당 동적 그룹에 자동으로 들어가므로 그룹마다 노드 이름을 일일이 복사할 필요가 없습니다. 공급자의 업데이트 주기와 상태 확인 주기는 서로 별개입니다. 전자는 노드 목록을 언제 가져올지, 후자는 기존 노드 상태를 언제 확인할지 결정합니다.

proxy-providers:
  provider-main:
    type: http
    url: https://example.com/clash-provider.yaml
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: 구독 자동 선택
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

공급자 상태 확인과 프록시 그룹 테스트를 동시에 설정할 수도 있습니다. 노드가 많다면 중복 테스트로 인한 네트워크 요청과 기기 부하에 유의해야 합니다. 특히 모바일 기기, 저사양 라우터, 노드 수가 많은 구독에서 영향이 두드러집니다. 확인 주기를 통일하거나 필요할 때만 검사하도록 설정하고, 실제 선택에 사용되는 그룹에만 필요한 테스트를 적용할 수 있습니다. 테스트를 줄인다는 것은 모든 검사를 끄는 것이 아니라 장애 감지 요구에 맞게 빈도를 조정하는 것입니다.

구독 업데이트로 노드 이름과 정렬 순서, 태그가 바뀔 수도 있습니다. filter로 지역을 선별할 때는 정규식이 테스트 노드를 잘못 포함하거나 이름 형식이 바뀐 노드를 누락하지 않는지 확인해야 합니다. fallback이 공급자를 통해 노드를 동적으로 참조한다면 공급자가 반환하는 순서도 우선순위에 영향을 줄 수 있습니다. 순서를 고정해야 하는 주·예비 회선은 노드를 명시적으로 나열하는 편이 관리하기 쉽지만, 노드 이름이 바뀌면 설정도 함께 수정해야 합니다.

사용 목적에 맞는 프록시 그룹 선택

일반 웹 브라우징과 범용 앱

먼저 url-test를 고려하고 적절한 테스트 주기와 허용 오차를 설정한 뒤 수동 선택 수단도 남겨 두는 것이 좋습니다. 기능이 비슷한 여러 노드 중에서 일상적으로 사용할 노드를 자동 선택할 수 있습니다. 노드의 지역 차이가 크다면 먼저 지역별 자동 그룹을 만들고 상위 select에서 지역을 선택하세요. 자동 테스트 때문에 업무 요건과 맞지 않는 지역으로 출구가 바뀌는 일을 방지할 수 있습니다.

고정 지역, 업무 시스템 및 원격 접속

먼저 fallback을 고려하세요. 출구 요건에 가장 잘 맞는 회선을 앞에 배치하고 같은 지역의 예비 회선을 그 뒤에 둡니다. 서비스가 출구 IP에 엄격히 고정된다면 고정 노드나 수동 그룹이 더 적합할 수 있습니다. 자동 장애 조치는 장애 발생 시 연결 지속성을 높여 주지만 출구가 바뀌는 것 자체가 대상 서비스의 보안 인증을 유발할 수도 있습니다.

동시 다운로드와 여러 기기의 공유

load-balance를 고려할 수 있으며, 서비스의 출구 일관성 요구에 따라 일관된 해싱 또는 라운드 로빈을 선택합니다. 로그인, 결제, 기업 인증 같은 민감한 연결은 라운드 로빈 그룹에 섞지 마세요. 다운로드 도메인과 업데이트 서비스 또는 특정 기기의 트래픽만 규칙으로 부하 분산 그룹에 보내고, 나머지 트래픽은 안정적인 출구를 계속 사용하도록 설정하는 편이 안전합니다.

TUN 모드에서의 선택

TUN 모드를 사용하면 코어가 처리할 수 있는 트래픽 범위는 넓어지지만 세 가지 프록시 그룹의 기본 선택 방식은 달라지지 않습니다. TUN으로 들어온 연결도 규칙과 대조된 뒤 해당 프록시 그룹으로 전달됩니다. TUN을 활성화한 후 접속 결과가 달라졌다면 시스템 라우팅, DNS 가로채기 또는 리디렉션 설정, 규칙 일치 여부, 프록시 그룹 옵션을 각각 확인해야 합니다. 모든 이상 현상을 자동 속도 테스트 탓으로 돌려서는 안 됩니다.

잦은 전환과 잘못된 장애 조치의 점검 순서

1. 일치한 규칙을 확인합니다. 클라이언트 연결 기록에서 대상 도메인을 찾아 실제로 어떤 프록시 그룹에 들어갔는지 확인하세요. 규칙 대상이 잘못되었다면 상태 확인 설정을 조정해도 트래픽 경로는 바뀌지 않습니다.
2. 그룹 유형이 목적에 맞는지 확인합니다. 주·예비 순서가 필요한데 url-test를 사용하거나 고정 출구가 필요한데 라운드 로빈을 사용하면 이상해 보이더라도 설정 논리에는 맞는 결과가 나옵니다.
3. 테스트 엔드포인트를 확인합니다. 테스트 URL이 모든 노드에서 안정적으로 성공 상태를 반환하는지 점검하고, 지역 제한과 리디렉션, 서버 측 속도 제한이 판단에 영향을 주지 않게 하세요.
4. 간격과 허용 오차를 확인합니다. url-test 선택이 자주 바뀐다면 먼저 허용 오차를 늘리세요. 장애 감지가 너무 느릴 때 확인 주기를 검토하되 무조건 매우 짧게 설정하지는 마세요.
5. 노드 순서를 확인합니다. fallback은 앞에서부터 사용 가능한 항목을 선택하므로 첫 번째 항목에는 실제로 가장 우선해서 사용할 회선을 배치해야 합니다.
6. 구독 업데이트 결과를 확인합니다. 노드 이름, 필터 규칙, 공급자 상태를 점검하여 그룹 안의 실제 후보가 예상과 달라지는 일을 방지하세요.
7. 홈 화면의 숫자만 보지 말고 실제 연결을 확인합니다. 지연 시간 패널은 테스트 결과일 뿐이며, 특정 서비스가 최종적으로 사용한 노드는 연결 로그에서 확인해야 합니다.

프록시 그룹을 선택할 때는 ‘속도 순위’, ‘주·예비 우선순위’, ‘연결 분산’을 구분하는 것이 중요합니다. url-test는 기능이 비슷한 노드 중에서 자동 선택할 때, fallback은 명확한 회선 우선순위를 유지할 때, load-balance는 여러 독립적인 연결을 분산할 때 적합합니다. 설정이 끝나면 한 번의 지연 시간 테스트만으로 결론 내리지 말고 실제 서비스로 규칙 일치, 노드 선택, 출구 안정성을 검증해야 합니다.