Clash 구독 업데이트 실패 원인과 자동 업데이트 주기 설정법

먼저 어느 단계에서 실패하는지 확인하세요

Clash 클라이언트의 ‘구독 업데이트’는 보통 원격 콘텐츠 다운로드, 설정 파일 파싱, 설정 저장 또는 불러오기의 세 단계로 진행됩니다. 다운로드에 성공해도 설정을 사용할 수 있다는 뜻은 아닙니다. 기존 노드로 인터넷에 접속할 수 있다고 해서 구독 주소가 유효한 것도 아닙니다. 오류 메시지를 먼저 확인한 뒤 링크, 네트워크 경로, 코어 중 어디를 수정할지 판단하세요.

현재 정상적으로 작동하는 설정을 유지하고 구독 이름, 마지막 업데이트 성공 시각, 현재 선택된 설정을 기록하세요.
구독 하나만 선택해 수동 업데이트를 한 번 실행하고, 실행 시각을 기록한 뒤 클라이언트 로그에서 해당 항목을 확인하세요.
오류가 HTTP 상태 코드, 연결 시간 초과, 인증서 검증, YAML 또는 프로토콜 필드 파싱 중 어디에 해당하는지 구분하세요.
한 번에 변수 하나만 조정하세요. 업데이트 경로를 바꾼 뒤 먼저 다시 시도하고 DNS, 노드, 코어를 동시에 바꾸지 마세요.

오류 메시지에 맞춰 확인할 항목을 선택하세요

오류 또는 증상	일반적인 원인	다음 조치
HTTP 401 / 403	인증 정보, 권한 또는 접근 정책으로 요청이 거부됨	구독 상태를 확인하고 서비스 제공업체의 안내를 살펴보세요
HTTP 404 / 410	주소가 존재하지 않거나 리소스가 폐기됨	서비스 제공업체 콘솔에서 링크를 다시 복사하세요
HTTP 429	요청 횟수 제한에 걸림	연속 재시도를 멈추고 Retry-After 지침을 따르세요
HTTP 500 / 502 / 503	서버 또는 상위 서비스 오류	잠시 후 다시 시도하고 서비스 공지를 확인하세요
timeout / deadline exceeded	파싱, 연결 또는 응답 읽기 시간 초과	직접 연결과 프록시 경로를 확인하세요
yaml / unmarshal / unsupported	콘텐츠 구조 또는 필드가 호환되지 않음	응답 본문과 코어 지원 여부를 확인하세요

이 표는 원인을 좁히기 위한 참고 자료이며, 상태 코드만으로 원인을 단정할 수는 없습니다. 예를 들어 403은 웹사이트의 접근 방지 정책 때문에 발생할 수도 있으므로 계정 만료라고 바로 판단하면 안 됩니다. 200 응답도 유효한 구독이 아니라 로그인 페이지일 수 있습니다.

링크가 유효하지 않을 때: 인증 정보, 유효 기간, 응답 본문 확인

먼저 서비스 제공업체 콘솔에서 Clash 또는 mihomo용 구독 주소를 다시 복사하세요. 브라우저 주소창의 관리 페이지 링크를 복사하거나 QR 코드 표시용 웹페이지를 구독 API로 사용하면 안 됩니다. 복사할 때는 쿼리 매개변수를 모두 포함하고 끝의 공백, 줄바꿈, 한글 문장 부호를 제거하세요.

다음 네 가지를 순서대로 확인하세요

계정 상태: 이용 기간, 트래픽 한도, 구독 권한을 확인하세요. 일부 서비스는 한도를 초과하면 안내 문구를 반환하고, 다른 서비스는 설정을 반환하더라도 노드를 사용할 수 없게 합니다.
링크 재설정 여부: 구독 토큰을 재설정하면 이전 주소가 즉시 만료될 수 있습니다. 업데이트 버튼만 반복해서 누르지 말고 기존 구독의 URL을 새 주소로 바꾸세요.
주소 리디렉션 여부: 301 또는 302 리디렉션으로 로그인 페이지로 이동하면 클라이언트가 최종적으로 HTML을 받을 수 있습니다. 최초 요청의 상태 코드뿐 아니라 최종 응답을 확인하세요.
요청 제한 여부: 여러 기기에서 같은 링크를 공유하며 자주 새로고침하면 429 오류가 발생할 수 있습니다. 자동 업데이트를 잠시 중지하고 제한이 풀린 뒤 기기별로 다시 활성화하세요.

브라우저에서 파일을 다운로드할 수 있다는 사실은 브라우저의 현재 요청 경로가 작동한다는 것만 보여줍니다. 브라우저는 로그인 쿠키를 사용하거나 시스템 프록시를 거치고, 클라이언트와 다른 DNS를 사용할 수 있습니다. 결과를 비교할 때는 양쪽의 프록시 사용 여부를 기록하세요. ‘브라우저에서는 열린다’는 이유만으로 점검을 끝내면 안 됩니다.

인증서 만료, 신뢰할 수 없는 발급자 또는 호스트 이름 불일치 오류가 있다면 먼저 기기의 날짜와 시간대, 현재 네트워크에서 웹 로그인이 필요한지 확인하세요. 구독 서비스의 인증서 상태를 확인한 뒤 조치해야 합니다. 인증서 검증을 끄는 방식으로 문제를 덮지 마세요. 구독 인증 정보도 HTTPS로 보호해야 합니다.

형식이 맞지 않을 때: 전체 설정과 노드 provider 구분하기

‘구독’은 하나의 고정된 파일 형식을 가리키지 않습니다. 일반적인 콘텐츠 유형으로는 전체 Clash YAML, 노드만 담긴 provider 파일, Base64로 인코딩된 공유 링크 모음이 있습니다. 이 형식들은 모든 가져오기 메뉴에서 서로 바꿔 사용할 수 없습니다. 다운로드 후 파싱 오류가 발생하면 먼저 콘텐츠 유형을 확인하고 클라이언트의 코어를 점검하세요.

콘텐츠 유형	일반적인 구조	사용 위치
전체 설정	proxies, proxy-groups, rules 등의 설정 항목 포함	클라이언트의 원격 설정 또는 구독 메뉴
노드 provider	주로 proxies 목록 포함	기본 설정에서 proxy-providers로 참조
공유 링크 모음	ss://, vmess:// 등의 링크 또는 인코딩된 콘텐츠	해당 형식을 지원하는 가져오기 도구 또는 신뢰할 수 있는 변환 절차
HTML 또는 안내 문구	로그인 페이지, 인증 페이지, 사용량 한도 안내	YAML 설정으로 불러올 수 없음

YAML 문법 오류와 프로토콜 오류를 구분해 처리하세요

들여쓰기 오류, Tab 문자, 올바르게 인용되지 않은 특수 문자는 YAML 파싱 오류를 일으킬 수 있습니다. 로그에 줄 번호가 표시되면 로컬 편집기에서 해당 줄과 바로 앞 줄을 확인하세요. 전체 구독에는 민감한 노드 정보가 포함되므로 공개 온라인 YAML 검사 도구에 업로드하지 않는 것이 좋습니다.

로그에 특정 프록시 유형이 지원되지 않는다고 표시된다면 들여쓰기보다는 코어의 지원 여부가 원인일 가능성이 큽니다. Clash는 클라이언트 생태계에서 널리 쓰이는 이름이며, Clash Meta는 이후 mihomo라는 이름을 사용합니다. 클라이언트마다 내장된 코어와 버전은 서로 다릅니다. 오래된 코어는 화면의 이름만 바꾼다고 새 프로토콜을 지원하지 않습니다. 클라이언트의 ‘정보’ 또는 코어 정보 페이지에서 실제 코어를 확인하세요.

문제를 해결할 때는 서비스 제공업체가 제공하는 호환 형식을 우선 사용하거나 대상 설정을 지원하는 클라이언트를 선택하세요. 오류가 난 프로토콜 필드를 그대로 삭제하지 마세요. 파싱은 통과하더라도 연결 단계에서 실패할 수 있습니다. 원격 설정을 로컬에서 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있으므로, 계속 유지해야 하는 변경은 클라이언트가 지원하는 오버라이드 또는 병합 기능을 사용하세요.

업데이트가 잘못된 프록시를 사용할 때: 시스템 프록시와 구독 다운로더 구분하기

시스템 프록시를 켰다고 구독 다운로드도 반드시 프록시를 거치는 것은 아닙니다. 클라이언트가 별도의 HTTP 다운로더를 사용하면서 ‘프록시 사용’, ‘프록시를 통해 업데이트’ 또는 ‘시스템 프록시 사용’ 같은 옵션을 제공할 수 있습니다. 코어가 관리하는 provider는 또 다른 요청 경로를 사용합니다. TUN이 일부 트래픽의 경로를 바꿀 수는 있지만 모든 업데이트 요청이 특정 노드를 사용한다고 단정할 수도 없습니다.

통제된 요청을 두 번 보내 경로를 비교하세요

사용 가능한 설정을 하나 보관하고 인터넷에 연결되는 노드를 선택한 뒤, 클라이언트의 로컬 프록시 수신 포트를 확인하세요.
해당 구독의 편집 화면에서 기존 설정을 기록하고, 구독 업데이트 전용 프록시 옵션을 끈 뒤 수동 업데이트를 한 번 실행하고 로그를 확인하세요.
해당 프록시 옵션을 켜고 다시 업데이트하세요. 연결 시간 초과, HTTP 상태 코드, 최종 파싱 결과를 비교하세요.
직접 연결은 성공하지만 프록시는 실패하면 출구 노드와 정책 선택을 점검하세요. 프록시 연결은 성공하고 직접 연결이 실패한다면 작동하는 업데이트 경로를 유지하세요.

실제 HTTP 또는 mixed 수신 포트가 7890이라고 가정하면 프록시 주소를 http://127.0.0.1:7890으로 명시할 수 있습니다. 여기서 7890은 설명을 위한 예시이며 모든 클라이언트의 기본값은 아닙니다. 클라이언트의 포트 설정을 기준으로 삼으세요. SOCKS 포트, HTTP 포트, 컨트롤 인터페이스 포트는 서로 바꿔 사용할 수 없습니다.

같은 링크가 모바일 네트워크에서는 성공하고 현재 Wi-Fi에서는 시간 초과된다면 네트워크 로그인 상태, DNS 조회, 대상 사이트 접속 가능성을 추가로 확인하세요. 네트워크 전환은 원인을 찾기 위한 방법일 뿐이며, TUN을 켜거나 DNS 설정 전체를 바꿀 필요는 없습니다. DNS를 테스트할 때도 수정 전후의 조회 결과를 기록해 일시적인 복구를 영구적인 해결로 착각하지 않도록 하세요.

자동 업데이트 주기: 클라이언트 구독과 provider를 따로 설정하세요

전체 원격 설정의 정기 다운로드는 보통 클라이언트가 담당합니다. mihomo의 HTTP 노드 provider는 proxy-providers 아래의 설정으로 제어됩니다. 두 방식은 함께 사용할 수 있지만 시간 단위와 실행 조건이 다릅니다. 전체 설정의 최상위에 interval을 임의로 추가해도 클라이언트가 자동으로 인식할 것이라고 기대하지 마세요.

클라이언트별 설정 위치

Clash Verge Rev: ‘구독’으로 이동해 대상 원격 구독 카드의 메뉴를 연 다음 정보 편집 화면으로 들어가세요. 구독 URL, 업데이트 주기, 다운로드 프록시 관련 옵션을 확인하세요. 항목 이름은 버전에 따라 달라질 수 있으니 화면에 표시된 단위를 기준으로 설정하세요.
Clash for Windows: ‘Profiles’에서 원격 설정을 찾고 오른쪽 클릭 메뉴에서 설정 편집 및 업데이트 관련 옵션을 확인하세요. 이전 버전은 화면과 옵션이 다르므로 다른 클라이언트의 메뉴 경로를 그대로 적용하면 안 됩니다.
Clash for Android: ‘구성’으로 이동해 해당 원격 설정을 편집하고 자동 업데이트 스위치와 주기를 확인하세요. 시스템이 앱의 백그라운드 실행을 제한하지 않는지도 확인해야 합니다. 주기를 설정해도 기기가 절전 상태일 때 정해진 시간에 실행된다는 보장은 없습니다.
mihomo 직접 실행: 기본 설정의 proxy-providers를 확인하세요. HTTP provider의 interval 단위는 초입니다. 전체 기본 설정 파일을 정기적으로 다시 다운로드하는 작업은 외부 관리 프로그램이 담당해야 합니다.

먼저 클라이언트의 ‘정보’ 페이지에서 버전을 기록하고 현재 버전의 화면을 기준으로 설정하세요. ‘업데이트 시 프록시 사용’ 옵션을 찾지 못했다고 기본으로 활성화되어 있다고 단정하면 안 됩니다. 해당 버전의 설정 안내를 확인하거나 로그에서 업데이트 프로그램의 실제 동작을 확인하세요.

단위를 환산해 불필요한 잦은 요청을 피하세요

목표 주기	분 단위 입력란	초 단위 interval
1시간	60	3600
6시간	360	21600
24시간	1440	86400

개인 기기에서는 우선 6시간 주기로 설정한 뒤 서비스 제공업체의 권장 사항에 맞게 조정할 수 있습니다. 기기가 계속 켜져 있고 정확히 6시간마다 실행된다면 구독 하나당 예약 요청이 약 4회 발생합니다. 10분마다 실행하면 약 144회로 늘어나며, 수동 업데이트와 실패 재시도는 여기에 포함되지 않습니다. 노드 변경이 드문 구독은 자주 새로고침해도 요청량만 늘어나는 경우가 많습니다.

기존 HTTP provider의 이름이 primary라고 가정하고, 아래에는 주기와 다운로드 경로에 해당하는 필드만 표시했습니다. 이는 설정 일부를 합친 예시이지 단독으로 실행할 수 있는 전체 설정이 아닙니다. 기존 type, url, path 등의 필드는 그대로 유지해야 합니다.

proxy-providers:
  primary:
    interval: 21600
    proxy: DIRECT

해당 필드를 지원하는 mihomo에서는 provider의 proxy로 다운로드에 사용할 아웃바운드를 지정하며, DIRECT는 직접 연결을 뜻합니다. 프록시나 정책 그룹을 사용한다면 이름이 현재 설정에서 유효해야 하며, 해당 provider를 통해서만 얻을 수 있는 노드에 의존하지 않도록 주의하세요. 이 필드는 클라이언트 외부에서 전체 구독을 다운로드하는 동작을 제어하지 않습니다.

노드 상태 확인용 health-check.interval은 노드 사용 가능 여부를 점검하는 별도의 타이머이며 노드 목록을 다시 다운로드하지 않습니다. 마찬가지로 rule-providers의 업데이트 주기는 규칙 세트에만 적용되며 구독 노드 업데이트 주기와는 다릅니다.

저장 후 업데이트 시각, 노드 변경, 설정 적용 여부 확인

자동 업데이트를 설정한 뒤 먼저 수동 업데이트를 실행해 경로가 정상인지 확인하고, 다음 예약 실행을 지켜보세요. 기기 절전, 프로세스 종료, Android 백그라운드 제한, 클라이언트의 예약 실행 방식에 따라 실제 실행이 설정한 시간보다 늦어질 수 있습니다. 업데이트 주기를 운영체제 수준의 정확한 예약 작업으로 생각하지 마세요.

다운로드 완료 확인: 화면에 잠깐 표시되는 성공 알림만 보지 말고 대상 구독의 업데이트 시각과 로그를 확인하세요.
대상 확인: 방금 업데이트한 항목이 현재 선택된 설정인지, provider가 새로고침되었는지 확인하세요.
콘텐츠 사용 가능 여부 확인: 노드 목록과 프록시 그룹이 계속 유효한지 살펴보세요. 노드 수가 그대로여도 업데이트되지 않은 것은 아닙니다. 서버의 콘텐츠가 변경되지 않았을 수 있습니다.
설정 적용 결과 확인: 설정이 정상적으로 적용되었는지, 직접 선택해 둔 노드가 삭제되거나 이름이 바뀌었는지 확인하고 필요하면 출구 노드를 다시 선택하세요.
예약 실행 확인: 예약된 업데이트 시각과 실제 실행 시각을 기록하세요. 수동 업데이트만 성공한다면 자동 업데이트 설정, 백그라운드 권한, 프로그램 실행 상태를 집중적으로 확인하세요.

계속 실패할 때 전달할 정보

서비스 제공업체나 클라이언트 개발자에게 문의할 때는 클라이언트 버전, 코어 버전, 운영체제 버전, 오류 발생 시각, HTTP 상태 코드, 직접 연결과 프록시 테스트의 차이를 제공하세요. 로그에 구독 URL, 노드 비밀번호, 인증 헤더가 포함되어 있다면 먼저 삭제해야 합니다. 이 정보로 서버의 요청 거부, 다운로드 경로 오류, 설정 파싱 문제를 구분할 수 있습니다.

다음 순서로 점검하면 됩니다. 링크와 권한을 확인하고, 응답 형식을 점검한 뒤, 업데이트 경로를 비교하고, 마지막으로 적절한 업데이트 주기를 설정하세요. 수동 업데이트가 안정적으로 성공해야 자동 업데이트도 의미가 있습니다. 주기를 짧게 설정해도 만료된 링크나 호환되지 않는 설정은 해결되지 않습니다.