구독만으로는 자동 최적·주·예비가 안 보이는 이유

대부분의 구독 링크는 개별 프록시 노드(proxies) 목록을 채워 줄 뿐, 「어떤 트래픽에 어떤 그룹을 쓸지」는 설정 작성자의 proxy-groups와 rules에 달려 있습니다. 템플릿이 type: select인 Proxy 그룹 하나만 두고 끝나 있으면, 사용자가 UI에서 손으로 고르지 않는 한 노드는 바뀌지 않습니다. 반대로 url-test를 넣었는데 규칙이 🇯🇵 Tokyo-01처럼 노드 이름을 직접 가리키면, 그룹이 아무리 똑똑해도 해당 줄은 그 노드만 타므로 자동 전환이 눈에 안 들어옵니다.

또 한 가지 흔한 오해는 「측정이 돌고 있다 = 실제 웹사이트도 그 노드로 나간다」입니다. 헬스 체크는 지정한 측정 URL에 대한 왕복에 가깝고, 방문하는 사이트의 경로·프로토콜·지역 CDN과 완전히 같지 않을 수 있습니다. 그래도 운영 목적상 url-test는 여전히 유용합니다. 다만 값은 회선과 사용 패턴에 맞게 조정해야 합니다.

ℹ 한 줄 체크: 규칙에 나오는 이름이 proxy-groups에 정의된 그룹 이름과 대소문자까지 동일한지 먼저 확인하세요. 한 글자만 달라도 Clash는 다른 대상을 찾거나 오류를 냅니다.

정책 그룹 타입: select·url-test·fallback·load-balance

Clash 계열에서 자주 쓰는 전략 그룹은 대략 다음 네 가지입니다. 이름은 설정마다 다르지만 역할은 동일합니다.

실무에서는 AUTO(url-test)와 FALLBACK(fallback)을 만들고, 그 위에 select로 「수동 고정」 레이어를 두는 구성이 흔합니다. 규칙 가독성은 규칙 라우팅 모범 사례와 함께 보시면 흐름이 잡힙니다.

url-test 실습: 지연 측정으로 자동 노드 고르기

아래는 형태를 보여 주는 예시입니다. proxies에 이미 구독에서 받은 노드 이름이 있다고 가정하고, 그 이름들을 그대로 나열합니다. 이름이 실제 proxies[].name과 다르면 로딩 단계에서 실패합니다.

proxy-groups — url-test example

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - node-a
      - node-b
      - node-c
    url: http://www.gstatic.com/generate_204
    interval: 30
    tolerance: 50
    lazy: false

url은 작은 응답(예: HTTP 204)을 주는 엔드포인트를 많이 씁니다. 다만 그 URL이 특정 지역 CDN에만 있거나 차단되면 모든 노드가 동시에 「나쁨」으로 보일 수 있으니, 자신의 회선에서 브라우저나 curl로 한 번 확인해 보는 것이 좋습니다. interval은 측정 주기(초)입니다. 너무 짧으면 배터리·로그·상대 서버 측에서 부담이 됩니다. tolerance는 현재 선택을 유지할 만큼의 여유(ms)로 이해하면 됩니다. 애매한 차이로 노드가 자주 바뀌면 세션이 끊겨 보일 수 있습니다. lazy: false는 시작 직후에도 측정을 돌리게 하는 편이 일반적입니다(클라이언트·코어 버전에 따라 기본값이 다를 수 있음).

fallback 실습: 순서대로 살아 있는 출구로 넘기기

fallback은 「우선 이 출구, 안 되면 다음」을 코드로 표현합니다. 마지막에 DIRECT를 두면 프록시가 모두 실패할 때만 직접 연결로 떨어지게 할 수 있습니다. 반대로 보안 정책상 직접이 금지된 환경이라면 DIRECT 대신 다른 그룹이나 REJECT를 두는 식으로 조정해야 합니다.

proxy-groups — fallback chain example

proxy-groups:
  - name: FALLBACK
    type: fallback
    proxies:
      - premium-line
      - backup-line
      - AUTO
      - DIRECT
    url: http://cp.cloudflare.com/generate_204
    interval: 15

위 예에서 AUTO는 앞 절의 url-test 그룹 이름입니다. 이렇게 그룹 안에 또 다른 그룹을 넣어 계층을 쌓을 수 있습니다. 순서는 정말로 중요합니다. 운영자가 의도한 「주 → 예비 → 자동 측정 → 직접」이 아니라면 배열만 바꿔도 동작이 달라집니다.

측정 URL·interval·tolerance·lazy를 고르는 기준

측정 URL은 세 가지를 동시에 만족할수록 좋습니다: (1) TLS/바이너리 부담이 적고 응답이 가벼울 것, (2) 지리적으로 지나치게 한쪽에만 붙어 있지 않을 것, (3) 이용 약관·회사 정책상 문제가 없을 것. 커뮤니티에서 자주 인용되는 generate_204 계열도 환경에 따라 느리거나 막힐 수 있으니, 고정 관념보다 본인 회선에서의 왕복을 기준으로 삼으세요.

interval을 극단적으로 줄이면 「실시간에 가깝다」는 착각이 들 수 있지만, 노드 전환은 애플리케이션 입장에선 TCP 재연결을 의미하기도 해서 오히려 끊김으로 돌아올 수 있습니다. 반대로 너무 길면 장애 반영이 느립니다. 홈·이동·테더링을 바꿔 쓰는 사용자라면 프로필을 나누거나, 클라이언트에서 수동으로 한 번 갱신하는 운영이 더 나을 때도 있습니다.

구독 갱신·노드 품질 유지와 맞물린 내용은 구독·노드 유지보수 가이드에서 이어집니다. 측정은 살아 있는 노드를 고르는 데 도움이 될 뿐, 구독 자체가 비어 있으면 아무것도 고를 수 없습니다.

규칙에서 DIRECT·REJECT·그룹 이름 맞추기

정책 그룹을 아무리 잘 만들어도 규칙이 거기로 가리키지 않으면 소용이 없습니다. 예를 들어 마지막 줄이 - MATCH,Proxy인데 Proxy가 select 그룹이면, 사용자가 고르지 않은 초기 상태나 잘못된 이름 때문에 흐름이 멈출 수 있습니다. 자동화를 쓰고 싶다면 - MATCH,AUTO 또는 - MATCH,FALLBACK처럼 의도한 그룹 이름을 명시합니다.

rules fragment — policy names

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,FALLBACK

DIRECT는 말 그대로 프록시를 거치지 않습니다. 국내 트래픽을 직접으로 보내는 전략은 흔하지만, 회사망·캠퍼스 정책과 충돌할 수 있으니 전제를 확인하세요. REJECT는 해당 흐름을 버립니다. 광고·추적 도메인을 막을 때 쓰지만, 과하게 넓은 키워드 규칙은 정상 앱까지 죽일 수 있어 규칙 순서와 가독성이 특히 중요합니다.

REJECT와 fallback을 함께 설계할 때는 「거부 규칙이 프록시 그룹보다 위에 있는가」를 봅니다. 거부가 먼저면 프록시는 호출조차 되지 않습니다. 의도한 것이 맞는지 로그로 확인하세요.

DNS·unified-delay·게임 UDP 등 주의점

DNS가 규칙과 어긋나면, 브라우저는 빨리 열리는 것처럼 보이다가 TCP 단계에서 막히는 현상이 납니다. fake-ip 모드에서는 도메인 규칙과의 정렬이 더 중요해집니다. DNS만 따로 조정하고 프록시 결정은 다른 출구를 타면 「노드는 최적인데 사이트만 안 된다」는 혼란이 생깁니다. 기초 정리는 FAQ에서 다루는 흐름과 맞춰 보세요.

Clash Meta(mihomo) 계열에서는 unified-delay: true처럼 지연 계산 방식을 통일하는 옵션이 문서화되어 있습니다. 측정 숫자가 클라이언트마다 미세하게 다르면 이 설정과 클라이언트 표시 방식을 함께 의심합니다.

UDP가 많은 게임·음성 채팅은 url-test가 고른 「HTTPS 지연 최저」 노드와 잘 맞지 않을 수 있습니다. 이때는 게임 트래픽만 DIRECT나 별도 그룹으로 분리하는 식의 시나리오 분할이 필요합니다. 연결 로그에 반복되는 타임아웃이 있다면 timeout·TLS 로그 해석을 참고해 원인을 노드인지 규칙인지 나눕니다.

증상별 점검 순서

  1. 그룹 이름 불일치: rules에 적힌 문자열이 proxy-groups[].name·proxies[].name과 정확히 같은지 확인합니다.
  2. 규칙이 노드를 직접 지목: 자동 전환을 기대한다면 대상을 AUTO·FALLBACK 같은 그룹으로 바꿉니다.
  3. 측정 URL 전원 실패: URL을 회선에서 직접 요청해 보고, 필요하면 다른 경량 엔드포인트로 교체합니다.
  4. interval·tolerance: 너무 공격적이면 진동(빈번한 스위칭), 너무 느슨하면 장애 반영 지연입니다.
  5. lazy: 시작 직후 한동안 자동이 안 바뀌는 것 같으면 값과 코어 기본 동작을 확인합니다.
  6. 중첩 그룹 순환: A가 B만 보고 B가 A만 보면 안 됩니다. 계층을 단순화합니다.

준수 알림

⚠ 준수 알림: 현지 법령·서비스 약관·고용주·학교·공공망의 정책을 준수하세요. 본문은 허용된 네트워크에서 Clash 설정을 이해하기 위한 기술 설명이며, 무단 접근·감시 우회·타인에게 피해를 주는 트래픽 조작을 조장하지 않습니다.

기업 VPN·제로 트러스트·SSL 검사가 있는 환경에서는 동일한 YAML도 동일하게 동작하지 않을 수 있습니다. 기술적으로 가능하다고 해서 정책상 허용된다는 뜻은 아닙니다.

맺음말

Clash 정책 그룹의 url-test와 fallback은 「구독을 넣었다」는 사실만으로는 자동으로 채워지지 않는 레이어입니다. 측정 URL과 주기, 규칙이 가리키는 이름, DIRECT·REJECT의 위치까지 맞춰야 비로소 「자동 최저지연」과 「주·예비 전환」이 설정 의도대로 보이기 시작합니다. 숫자에 집착하기보다 로그에서 실제로 어떤 그룹이 잡히는지 확인하는 습관이 장기적으로 가장 큰 이익을 줍니다.

같은 도구라도 클라이언트에 따라 편의 기능과 표시가 다릅니다. 코어 설정을 손대기 전에 GUI가 자동 생성한 YAML을 한 번 읽어 보면 학습 곡선이 줄어듭니다. 다른 도구에 비해 Clash는 규칙과 그룹을 파일 한곳에 서술할 수 있어, 한 번 맞춰 두면 재현성이 좋다는 장점이 있습니다.

→ Clash를 무료로 다운로드하고, 정책 그룹·지연 측정·규칙을 한 프로필 안에서 정리해 보세요.