Clash 구독 관리: 업데이트 실패, 인증, 헬스체크 트러블슈팅 가이드

구독이란 정확히 무엇이고, 문제가 생기면 어디를 봐야 할까

흔히 말하는 "구독 가져오기"는 설정 파일 차원에서 보면 실제로 proxy-providers 필드에 해당합니다. 클라이언트가 주기적으로 특정 URL에 접속해서 반환된 노드 목록을 내려받아 노드로 파싱한 다음, 해당 정책 그룹에 집어넣는 방식입니다. 이 원리를 이해하고 있어야 "구독 업데이트 실패"가 발생했을 때 어느 방향으로 문제를 찾아야 할지 알 수 있습니다.

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/sub?token=xxx"
    interval: 3600       # 3600초마다 자동 업데이트
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

대부분의 GUI 클라이언트는 이 긴 설정을 "구독 가져오기" 입력창 뒤에 숨겨두고 있습니다. 여러분이 입력하는 링크가 바로 url 필드이고, 화면상의 "업데이트 간격"은 interval에 대응되며, 본질적으로는 차이가 없습니다.

구독 업데이트가 실패하는 흔한 원인들

• "비정상 클라이언트"로 인식되어 접속이 거부됨일부 구독 서비스는 요청의 User-Agent를 검사해서 흔히 쓰이지 않는 클라이언트의 요청을 차단합니다. header 필드에 흔히 쓰이는 UA 문자열을 직접 지정해서 위장하면 됩니다.
• 구독 링크에 인증이 필요함구독 주소에 접속할 때 Authorization 헤더가 필요한 경우(자체 구축 패널의 구독 API에서 흔함)에도 마찬가지로 header 필드를 통해 추가해야 하며, 토큰을 URL에 이어붙이는 방식은 권장하지 않습니다(일부 서비스는 두 방식을 모두 지원하지만 header 방식이 더 정석적입니다).
• 구독을 가져오는 것 자체에 프록시가 필요함구독 서버가 해외에 있는데, 해외 사이트에 접속하려면 먼저 사용 가능한 노드가 있어야 하는 경우 "사용 가능한 노드가 없어서 구독을 못 받아오고, 구독을 못 받아오니 노드가 없는" 무한 루프가 생길 수 있습니다. 이때는 proxy 필드로 구독 업데이트 전용의 고정된 안내 노드를 지정하면 됩니다.
• 구독 파일 크기가 제한을 초과함size-limit 필드는 기본적으로 제한이 없지만, 클라이언트나 패널에서 자체적으로 더 보수적인 제한을 걸어둔 경우 지나치게 큰 구독 파일이 바로 거부될 수 있습니다. 이 제한을 적절히 늘리거나 제거하면 됩니다.

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/sub"
    proxy: 직접연결 안내노드    # 구독 업데이트 전용 고정 출구
    header:
      User-Agent:
        - clash-verge/v2.0.0
      Authorization:
        - Bearer your-token-here

health-check로 죽은 노드 찾아내기

구독 노드를 오래 쓰다 보면 서버가 다운되거나, 속도가 제한되거나, 차단되는 일이 흔하게 일어납니다. 헬스체크를 하지 않으면 정책 그룹 안에 연결되지 않는 "좀비 노드"가 잔뜩 섞여 있게 되어 자동 측정/자동선택 시 체감이 나빠집니다. health-check가 바로 이 문제를 해결해줍니다.

해당 proxy-providers 항목 아래에 health-check 항목을 추가하고 안정적인 검사 주소를 지정하면 됩니다(https://www.gstatic.com/generate_204나 https://cp.cloudflare.com를 추천). 클라이언트는 설정한 간격마다 각 노드에 검사 요청을 보냅니다.

• enable: 헬스체크 활성화 여부로, 항상 켜두는 것을 권장합니다.
• interval: 검사 간격(초 단위)으로, 너무 짧게 설정할 필요는 없으며 300~600초면 충분합니다.
• lazy: 기본값은 true로, 노드가 실제로 사용되지 않을 때는 검사하지 않아 리소스를 절약합니다. 패널에 항상 정확한 지연 데이터를 표시하고 싶다면 끌 수 있지만 백그라운드 트래픽이 조금 늘어납니다.

구독 노드가 너무 많고 뒤섞여 있다면? filter로 정리하기

일부 구독은 한 번에 수백 개의 노드를 제공하는데, 이걸 전부 하나의 정책 그룹에 몰아넣으면 고르기도 어렵고 보기도 안 좋습니다. filter / exclude-filter를 사용하면 키워드나 정규식으로 노드를 걸러내거나 제외할 수 있어서, 같은 지역이나 같은 용도의 노드를 별도의 정책 그룹으로 나눌 수 있습니다.

proxy-providers:
  hk-only:
    type: http
    url: "https://example.com/sub"
    filter: "(?i)港|hk|hongkong"
  no-relay:
    type: http
    url: "https://example.com/sub"
    exclude-filter: "(?i)中转|relay"

같은 구독 주소를 여러 개의 proxy-providers 항목으로 설정해서, 서로 다른 filter로 "홍콩만", "일본만", "경유 노드 제외" 같은 하위 세트를 나눈 다음 각각 정책 그룹을 만들면, 수백 개짜리 큰 목록에서 일일이 찾는 것보다 훨씬 편리합니다.

자주 묻는 질문