Clash 구독 업데이트 실패 해결: 링크 만료·시간 초과·자동 업데이트 간격 설정

먼저 실패 지점을 확인하세요: 구독 다운로드인가, 설정 파일 로드인가

‘구독 업데이트 실패’는 세 단계에서 발생할 수 있습니다. 클라이언트가 콘텐츠를 다운로드하지 못했거나, 서버가 콘텐츠를 반환했지만 사용 가능한 설정 파일이 아니거나, 파일을 저장한 뒤 코어가 로드하는 과정에서 필드 또는 참조 오류를 발견한 경우입니다. 각 상황의 해결 방법은 다릅니다. 노드가 여전히 연결된다는 사실은 로컬에 저장된 이전 설정이 작동한다는 뜻일 뿐, 구독 주소가 아직 유효하다는 증거는 아닙니다.

현재 작동하는 설정은 먼저 보관하고 구독 항목을 바로 삭제하지 마세요. 클라이언트 이름, 코어 종류, 마지막 업데이트 시각, 전체 오류 메시지를 기록하세요. 로그를 공유하기 전에는 구독 URL의 경로에 포함된 키, 쿼리 매개변수, 노드 비밀번호, 서버 주소를 가리세요. 구독 링크는 보통 접근 권한을 가진 자격 증명처럼 취급해야 합니다.

링크 만료: 주소, 계정, HTTP 상태 코드 확인

구독 주소를 다시 복사하세요. 계정 페이지 주소를 복사하면 안 됩니다

1. 서비스 제공자 계정 페이지에 로그인해 구독 상태, 만료일, 남은 사용량을 확인하세요. 계정에 로그인할 수 있어도 구독 다운로드가 가능하다는 뜻은 아닙니다.
2. Clash 또는 Mihomo용이라고 명확히 표시된 구독 메뉴를 선택하세요. 브라우저 주소창에 표시된 계정 페이지 주소는 구독 주소를 대신할 수 없습니다.
3. 링크 전체를 복사하고 ? 뒤의 쿼리 매개변수도 유지하세요. 복사 과정에서 섞인 공백, 줄바꿈, 문장 부호는 제거합니다.
4. 기존 구독 항목의 편집 화면에서 URL을 교체하고 저장한 뒤 한 번 수동으로 업데이트하세요. 구독 키를 재설정했다면 다른 기기에 저장된 이전 링크도 함께 바꿔야 합니다.

401은 대개 인증 문제를 가리킵니다. 403은 접근 제어, 지역 제한, 보안 차단 페이지 때문에 발생할 수도 있으므로 상태 코드만으로 계정 만료라고 단정할 수 없습니다. 404는 경로가 잘못되었거나 서비스 제공자가 유효하지 않은 자격 증명을 숨기고 있을 수 있습니다. 계정 상태와 응답 내용을 함께 확인하세요.

HTTP 200이어도 오류 페이지가 반환될 수 있습니다

서버가 200을 반환했다는 것은 HTTP 요청이 성공 응답을 받았다는 뜻일 뿐입니다. 본문이 <!DOCTYPE html> 또는 <html>로 시작한다면 로그인 페이지, 캡차 페이지 또는 점검 페이지를 다운로드했을 수 있습니다. 이 경우 YAML 들여쓰기를 계속 수정해도 소용없습니다. 먼저 실제 구독 응답을 받아야 합니다.

키가 포함된 구독 주소를 공개 진단 사이트에 붙여 넣지 마세요. 서비스 제공자에게 확인을 요청할 때는 상태 코드, 발생 시각, 민감 정보를 가린 오류 내용을 전달하면 됩니다. 전체 링크는 신뢰할 수 있는 비공개 지원 채널로만 보내세요.

요청 시간 초과: DNS, TLS, 프록시 경로를 구분하세요

구독 요청은 클라이언트 자체가 보낼 수도 있고 코어의 proxy-providers가 보낼 수도 있습니다. 두 요청이 같은 네트워크 경로를 사용하는 것은 아닙니다. 시스템 프록시나 TUN 모드를 켠 뒤 브라우저에서 웹사이트에 접속할 수 있더라도 클라이언트의 구독 업데이트 요청이 같은 경로를 이용한다고 볼 수는 없습니다.

오류가 발생한 단계별로 확인하세요

• 도메인 확인 실패: no such host 오류가 있으면 구독 도메인의 철자, 시스템 DNS, 현재 네트워크를 먼저 확인하세요. 구독 도메인을 IP 주소로 바로 바꾸면 HTTPS 인증서 검증과 가상 호스트 라우팅에 문제가 생길 수 있습니다.
• 연결 시간 초과: dial tcp 뒤에 시간 초과 오류가 나타나면 연결 단계가 정상적으로 완료되지 않은 것입니다. 휴대폰 핫스팟으로 테스트하면 현재 네트워크의 제한과 서버 문제를 구분하는 데 도움이 됩니다.
• 응답 대기 시간 초과: context deadline exceeded는 여러 단계에서 발생할 수 있습니다. 응답 헤더를 기다리는 중이라는 메시지도 함께 표시된다면 DNS만 바꾸지 말고 서버 부하와 외부 연결 경로를 확인하세요.
• TLS 오류: x509, 인증서 만료, 호스트 이름 불일치가 나타나면 먼저 기기의 날짜, 시간, 시간대를 확인한 뒤 서비스 제공자에게 인증서 문제를 문의하세요. 인증서 검증을 끄는 방식으로 문제를 덮지 마세요.

두 번의 비교 업데이트로 경로를 파악하세요

클라이언트에 구독 업데이트를 직접 연결 또는 프록시로 설정하는 옵션이 있다면 먼저 직접 연결로 수동 업데이트한 다음, 현재 사용할 수 있는 프록시 노드를 선택해 업데이트해 보세요. 한 번에 조건 하나만 바꾸는 것이 중요합니다. 직접 연결은 성공하고 프록시는 실패한다면 선택한 노드와 프록시 출구를 확인하세요. 프록시는 성공하고 직접 연결이 실패한다면 로컬 네트워크에서 구독 도메인에 접근할 수 있는지 확인하세요.

현재 설정의 모든 노드가 작동하지 않는데 업데이트가 그중 하나를 반드시 거치도록 설정되어 있으면 의존성 순환이 생길 수 있습니다. 이때는 사용 가능한 업데이트 경로로 전환하거나, 신뢰할 수 있는 다른 네트워크를 임시로 이용해 설정을 받으세요. 로컬에 유일하게 저장된 설정부터 삭제하지 마세요.

형식 호환성 문제: 전체 설정과 노드 제공자 확인

Clash YAML, Base64로 인코딩된 노드 링크, 단일 노드 URI는 서로 다른 입력 형식입니다. ss://, vmess://, vless:// 링크 목록을 완전한 YAML 구독인 것처럼 가져오면 파싱 오류가 발생할 수 있습니다. 파일 확장자가 .yaml이라고 해서 본문 형식이 올바르다는 뜻은 아닙니다.

다운로드 후 로드에 실패하면 코어 기능을 확인하세요

Clash와 Clash Meta(현재 mihomo)의 필드 및 프로토콜 지원 범위는 완전히 같지 않습니다. 로그에 알 수 없는 프록시 유형이 표시되면 링크 만료로 단정하지 말고 구독 출력 형식과 현재 코어를 확인하세요. 우선 서비스 제공자에게 현재 코어에 맞는 형식을 요청하세요. 클라이언트를 바꿔야 한다면 해당 클라이언트가 사용하는 코어 종류부터 확인하세요.

로그에 YAML 행 번호가 표시되면 해당 행과 앞뒤의 들여쓰기, 따옴표, 목록 기호를 확인하세요. 정책 그룹이나 규칙에서 참조한 이름이 없다는 메시지가 나타나면 proxy-groups, rules, 노드 이름이 서로 일치하는지 확인하세요. 원격 구독을 업데이트할 때마다 수동 편집 내용이 덮어써질 수 있으므로, 계속 유지할 변경 사항은 클라이언트가 지원하는 오버라이드 또는 병합 설정에 작성하세요.

형식 변환이 필요하면 서비스 제공자가 제공하는 대상 형식을 우선 사용하세요. 타사 온라인 변환 서비스는 원본 구독 링크를 받아야 하는 경우가 많으므로 구독 콘텐츠와 접근 자격 증명이 노출될 수 있습니다. 신중하게 이용하세요.

자동 업데이트 간격: 클라이언트 설정과 interval 필드

자동 업데이트에는 두 가지가 있습니다. 클라이언트가 일정한 간격으로 전체 구독을 다운로드하는 방식과 코어가 설정에 포함된 노드 제공자를 주기적으로 새로고침하는 방식입니다. 전자는 보통 클라이언트 자체의 구독 메타데이터에 저장되고, 후자는 proxy-providers 아래의 interval에 해당합니다. 서로 대체할 수 없습니다.

클라이언트의 구독 편집 화면에서 설정

Clash Verge Rev의 일반적인 화면을 예로 들면, ‘구독’에서 대상 구독 카드의 마우스 오른쪽 버튼 메뉴를 열고 ‘편집’을 선택한 다음 ‘업데이트 간격’ 항목을 찾습니다. 버전에 따라 메뉴 이름이 다를 수 있으니 실제 편집 화면을 기준으로 확인하세요. 이 화면의 단위는 보통 분이지만, 입력하기 전에 입력란의 단위 안내를 반드시 확인하고 코어에서 사용하는 초 단위 값을 그대로 넣지 마세요.

1. 먼저 수동 업데이트가 성공하는지 확인한 뒤 자동 업데이트를 설정하세요. 360분, 즉 6시간부터 시작하고 서비스 제공자의 요청 빈도 제한을 따르세요.
2. 편집 내용을 저장하고 클라이언트에서 해당 자동 업데이트 옵션을 켜야 하는지 확인하세요. 지연 시간 테스트 간격을 구독 업데이트 간격으로 착각하지 마세요.
3. 클라이언트를 실행한 상태로 두고 다음 업데이트 기록을 확인하세요. 앱 종료, 기기 절전, 시스템의 백그라운드 제한 때문에 예약 작업이 늦어질 수 있습니다.

mihomo 노드 제공자의 interval 단위는 초입니다

아래는 노드 제공자 예시이지 전체 설정이 아닙니다. 예시에 사용된 도메인으로 실제 노드를 다운로드할 수는 없습니다. 적용할 때는 유효한 주소를 사용하고 정책 그룹에서 use로 제공자를 참조하세요.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://subscription.example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 21600

여기서 21600은 21600초, 즉 6시간을 뜻합니다. path는 로컬 캐시 파일의 경로이며 코어를 실행하는 사용자에게 해당 디렉터리의 쓰기 권한이 있어야 합니다. URL이 호환되는 노드 제공자 콘텐츠가 아니라 완전한 설정을 반환한다면 새로고침 간격을 바꿔도 형식 오류는 해결되지 않습니다.

url-test 정책 그룹의 interval이나 제공자 상태 확인 간격을 구독 새로고침 간격과 혼동하지 마세요. 이 필드들은 노드의 연결 가능 여부나 지연 시간을 확인할 뿐, 전체 구독을 다운로드하지 않습니다. 로그에 429가 표시되면 60초마다 계속 요청하지 말고 서비스 제공자의 안내에 따라 새로고침 주기를 늘리세요.

업데이트 후 확인: 파일, 노드, 규칙이 적용되었는지 확인하세요

1. 업데이트 결과 확인: 대상 구독의 업데이트 시각이 바뀌었고 로그에 다운로드 또는 파싱 실패가 더는 기록되지 않는지 확인하세요. ‘요청을 보냈습니다’라는 알림만으로 업데이트가 완료된 것은 아닙니다.
2. 현재 설정 확인: 방금 업데이트한 구독을 실제로 사용 중인지 확인하세요. 활성화되지 않은 설정을 업데이트해도 현재 연결에 사용되는 노드 목록은 바뀌지 않을 수 있습니다.
3. 노드와 정책 그룹 확인: 노드 수와 이름, 정책 그룹 참조가 올바른지 확인하세요. 노드 테스트는 통과하지만 접속에 실패한다면 규칙 매칭과 아웃바운드 선택도 확인해야 합니다.
4. 다음 작업 확인: 다음 자동 업데이트가 실행되는지 기록하세요. 수동 업데이트는 성공하고 자동 업데이트만 실패한다면 링크를 다시 만들기보다 앱 실행 상태, 예약 설정, 해당 시점의 네트워크를 먼저 확인하세요.

계속 실패한다면 민감 정보를 가린 기록을 서비스 제공자나 클라이언트 유지 관리자에게 전달하세요. 클라이언트 이름, 코어 종류, 오류 발생 시각, HTTP 상태 코드 또는 원문 오류, 직접 연결과 프록시 경로의 결과를 포함하면 됩니다. 네트워크 요청 실패, 설정 형식 오류, 예약 작업 미실행은 각각 구분해 설명하세요.

필드를 확인하려면 설정 참조를 살펴보세요. 구독을 처음 가져오는 경우 빠른 시작 가이드를 따라 진행하면 됩니다. 클라이언트를 바꾸기 전에 설정을 백업해 구독 문제와 마이그레이션 문제를 혼동하지 않도록 하세요.