Clash 구독 업데이트 실패의 흔한 원인과 자동 업데이트 설정 방법

증상부터 확인: 업데이트 실패의 세 가지 전형적인 유형

구독 업데이트 실패는 단일한 오류가 아니라 여러 증상을 통칭하는 말입니다. 본격적으로 원인을 찾기 전에 자신이 겪는 증상이 어떤 유형인지부터 확인하세요:

• 「업데이트」를 클릭하면 몇 초간 로딩 표시가 돌다가 시간 초과 또는 Error 메시지가 뜨고, 구독 항목의 타임스탬프가 제자리에 멈춰 있는 경우.
• 업데이트 성공 메시지가 뜨지만 노드 목록은 전혀 바뀌지 않고 타임스탬프가 며칠 전에 머물러 있는 경우 — 대부분 로컬 캐시를 읽은 것이거나 새 구성이 제대로 기록되지 않은 것입니다.
• 구독 항목이 바로 빨간색으로 표시되고 노드 수가 0이 되며, 로그에 context deadline exceeded, 403 Forbidden, 401 Unauthorized 같은 문구가 나타나는 경우.

클라이언트의 로그 패널을 열어 오류 원문을 빠짐없이 기록해 둔 뒤 다음 단계로 넘어가세요. 「업데이트 실패」라는 문구 자체에는 아무 정보도 없고, 오류 원문에 단서가 있습니다.

네트워크 원인: 업데이트 요청은 기본적으로 프록시를 거치지 않습니다

이것은 구독 업데이트 실패 원인 중 가장 큰 비중을 차지하면서도 가장 간과하기 쉬운 부분입니다.

구독 업데이트는 본질적으로 한 번의 평범한 HTTPS 요청입니다. 클라이언트가 구독 주소에 연결해 노드 목록을 가져오는 것이죠. 대부분의 클라이언트는 이 요청을 프록시 없이 직접 연결로 보냅니다. 그래서 언뜻 모순적으로 보이는 현상이 발생합니다 — 노드는 분명히 잘 작동하는데 구독은 업데이트되지 않는 것입니다. 이유는 간단합니다. 노드 트래픽은 프록시 터널을 지나지만, 업데이트 요청은 터널 밖으로 그대로 노출되어 나가기 때문입니다. 구독 도메인이 로컬 네트워크에서 접근 불가능하거나, 서버에서 로컬까지의 회선 품질이 나쁘면 직접 연결 요청은 시간 초과가 됩니다.

해결 방법은 세 가지이며, 순서대로 시도해 보세요:

1. TUN 모드 또는 시스템 프록시를 켠 뒤 업데이트를 수동으로 한 번 더 눌러 보세요. TUN이 기기 전체 트래픽을 가져가면 업데이트 요청도 터널 안으로 들어가 직접 연결 차단을 우회합니다. TUN의 구체적인 활성화 방법과 문제 해결은 구성 심화 페이지를 참고하세요.
2. 클라이언트 구독 설정에서 「프록시를 통해 업데이트」 옵션을 켜세요. Clash Verge Rev는 구독 항목의 편집 메뉴에서 이 스위치를 제공하며, FlClash와 Clash Meta for Android의 구독 편집 화면에도 같은 설정이 있습니다. 켜 두면 직접 연결이 막혀 있어도 업데이트를 완료할 수 있습니다.
3. mihomo 구성을 직접 작성하는 사용자는 proxy-providers에서 구독 소스에 proxy 필드를 지정하면 됩니다. 그러면 다운로드 트래픽이 지정한 프록시 그룹을 거칩니다:

proxy-providers:
  airport:
    type: http
    url: "https://example.com/api/sub?token=xxxx"
    interval: 43200
    proxy: 节点选择
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy 필드를 지정하지 않으면 기본값이 DIRECT 직접 연결인데, 바로 이것이 대부분의 업데이트 실패의 근본 원인입니다.

링크 원인: 만료, 재설정, 형식 불일치

네트워크 측에 문제가 없다면 링크 자체를 살펴볼 차례입니다. 구독 링크가 무효화되는 전형적인 경우는 네 가지입니다:

• 요금제 만료 또는 데이터 소진: 제공처가 구독 응답을 바로 끊어 403 또는 빈 내용을 반환합니다. 제공처 공식 사이트에 로그인해 요금제 상태를 확인하세요. 이 한 단계로 「클라이언트가 고장 났다」는 오판의 절반을 걸러낼 수 있습니다.
• 구독이 재설정된 경우: 제공처 관리 페이지에서 「구독 재설정」을 누르면 기존 token이 즉시 무효화되어 클라이언트의 이전 주소는 계속 업데이트에 실패합니다. 새 링크를 복사해 다시 가져오면 됩니다.
• 제공처가 도메인을 변경한 경우: 기존 도메인에 접근할 수 없거나 폐기되면 이전 링크가 비정상적으로 리디렉션되거나 아예 연결되지 않습니다. 공식 사이트 공지의 최신 구독 주소를 기준으로 삼으세요.
• UA 형식 불일치: 많은 제공처가 요청의 User-Agent에 따라 서로 다른 형식을 반환합니다. 브라우저로 구독을 열었을 때 긴 base64 문자열이 보인다고 해서 Clash에서 쓸 수 있는 것은 아닙니다 — Clash 계열 클라이언트가 필요로 하는 것은 YAML입니다. 클라이언트 UA가 잘못 판별되면 범용 형식을 받게 되어 파싱 단계에서 바로 오류가 납니다.

mihomo 사용자는 proxy-providers에서 header 필드로 UA를 명시적으로 지정해 Clash 형식으로 반환하도록 강제할 수 있습니다:

proxy-providers:
  airport:
    type: http
    url: "https://example.com/api/sub?token=xxxx"
    interval: 43200
    header:
      User-Agent:
        - "clash.meta"

또한 제3자 구독 변환 사이트를 거친 링크는 변환 사이트가 다운되거나 도메인에 접근할 수 없을 때도 똑같이 업데이트에 실패합니다. 문제 해결 단계에서는 변환 사이트를 우회해 제공처의 원본 구독 링크로 먼저 검증해 보는 것이 좋습니다.

환경 원인: 시스템 시간, 쓰기 권한, 보안 소프트웨어

링크와 네트워크가 모두 정상이라면 문제는 로컬 환경에 있습니다. 발생 빈도가 높은 순서로 정리하면 다음과 같습니다:

• 시스템 시간 오차가 큰 경우: TLS 인증서 검증은 시스템 시간에 의존하므로 몇 분만 어긋나도 핸드셰이크에 실패하며, 로그에는 보통 certificate라는 문구가 남습니다. 시간을 맞추고 자동 동기화를 켠 뒤 다시 시도하세요.
• 네트워크가 중간에서 가로채기된 경우: 회사 내부망이나 학교 네트워크에서 TLS 검사를 수행하면 클라이언트가 중간 인증서를 신뢰하지 않아 업데이트가 반드시 실패합니다. 모바일 핫스팟으로 전환해 한 번 확인해 보면 원인을 특정할 수 있습니다.
• 구성 디렉터리에 쓰기 권한이 없는 경우: 구독 내용은 다운로드됐지만 로컬 파일에 저장되지 못해 「업데이트했는데 변화가 없는」 증상이 나타납니다. Windows에서 클라이언트를 Program Files에 설치하고 일반 권한으로 실행하는 경우에 가장 흔히 발생합니다. 구성 디렉터리 권한과 디스크 여유 공간을 확인하세요.
• 보안 소프트웨어 차단: 일부 백신 프로그램이 클라이언트의 아웃바운드 요청을 차단합니다. 클라이언트 실행 파일을 허용 목록에 추가하고 다시 시도하세요.
• 클라이언트 버전이 너무 오래된 경우: 원래 Clash 코어는 유지 관리가 중단되어 새로운 형식의 구독과의 호환성이 점점 떨어지고 있습니다. mihomo 코어를 쓰는 현역 클라이언트로 바꾸면 파싱 관련 문제는 대개 바로 사라집니다.

자동 업데이트: 간격을 어떻게 설정해야 적절할까

자동 업데이트의 원리는 간단합니다. 클라이언트가 설정된 간격으로 그 HTTPS 요청을 반복하는 것입니다. 간격 선택은 양쪽을 저울질해야 합니다 — 너무 짧으면 구독 API를 자주 호출해 제공처의 API 할당량을 소모할 뿐 아니라 고빈도 접근에 대한 제공처의 리스크 관리를 촉발해 구독이 일시적으로 차단될 수 있습니다. 너무 길면 노드 증감이나 접속 주소 변경 같은 중요한 정보를 받지 못해 쓰다 보면 연결이 끊깁니다.

경험상 적절한 범위는 6~24시간에 한 번입니다. 각 클라이언트의 설정 위치와 단위는 다음과 같습니다:

헷갈리기 쉬운 지점이 두 가지 있습니다. 첫째, mihomo 구성에서 interval의 단위는 분이 아니라 초입니다. 12시간으로 설정하려면 43200을 입력하세요. 둘째, proxy-providers에서 health-check의 interval은 노드 지연 시간 감지 주기로, 구독 다운로드 주기와는 무관합니다. 수정할 때 줄을 잘못 건드리지 않도록 주의하세요.

마지막으로 수동 업데이트 습관도 유지하세요. 제공처가 접속 주소 변경이나 노드 조정을 공지할 때 다음 자동 업데이트를 마냥 기다리지 말고, 클라이언트에서 수동으로 한 번 누르면 즉시 반영됩니다.

업데이트 이후: 4단계 점검 목록

1. 구독 항목의 타임스탬프를 확인해 현재 시간으로 갱신됐는지 확인하세요.
2. 노드 수와 그룹 구조가 제공처 공식 사이트 공지와 일치하는지 확인하세요.
3. 사용 중인 노드의 지연 시간을 한 번 테스트하세요 — 구독 업데이트 후 기존 노드가 내려갔을 수 있으며, 무효화된 노드에 연결해 두면 「프록시는 켜져 있는데 인터넷이 안 되는」 증상이 나타납니다.
4. 브라우저에서 해외 사이트에 접속해 연결이 원활한지 확인하세요. 접속되지 않으면 노드 목록으로 돌아가 다시 속도를 측정해 고르세요.

구독 문제의 점검 순서는 이렇게 고정해 두면 좋습니다. 먼저 오류 원문을 보고, 다음으로 네트워크 직접 연결을 확인하고, 그다음 링크 상태를 확인하고, 마지막으로 로컬 환경을 확인하는 것입니다. 업데이트 실패의 90% 이상이 이 네 단계 안에서 원인을 찾을 수 있습니다. 나머지는 자동 업데이트에 맡기고, 간격을 12시간 안팎으로 설정해 두면 평소에는 신경 쓸 필요가 없습니다.