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

먼저 구분할 것: 구독 업데이트, 노드 속도 측정, 연결 상태

Clash 구독 자동 업데이트는 클라이언트가 원격 구독 주소에 정기적으로 요청을 보내고, 응답 내용으로 로컬 설정이나 노드 제공자 정보를 갱신하는 기능입니다. 노드 속도 측정이나 출구 노드를 주기적으로 바꾸는 기능과는 다릅니다. 서버에서 구독 내용을 바꾸지 않았다면 업데이트에 성공해도 노드 수가 그대로일 수 있으며, 이는 정상입니다.

설정하기 전에 구독을 관리하는 주체부터 확인하세요. Clash Verge Rev 같은 데스크톱 클라이언트는 보통 앱에서 원격 설정을 관리합니다. mihomo 코어를 직접 실행하는 환경에서는 proxy-providers로 노드를 가져올 수 있습니다. 두 곳 모두 ‘업데이트 주기’ 설정이 있을 수 있지만, 대상과 단위, 타이머를 실행하는 프로세스는 서로 다릅니다.

원격 설정 업데이트: 전체 설정 파일을 다운로드합니다. 노드뿐 아니라 프록시 그룹, 규칙, DNS 설정도 함께 바뀔 수 있습니다.
노드 제공자 업데이트: 특정 proxy-providers에 해당하는 노드 목록만 새로 가져옵니다. 기본 설정의 규칙이 자동으로 바뀌지는 않습니다.
상태 확인: 노드를 사용할 수 있는지 테스트합니다. health-check.interval은 검사 주기이며, 구독 다운로드 주기가 아닙니다.

Clash Verge 계열 클라이언트에서 자동 업데이트 설정하기

아래는 Clash Verge Rev에서 흔히 볼 수 있는 화면을 기준으로 설명합니다. 버전에 따라 구독 카드의 우클릭 메뉴나 더보기 메뉴에 설정이 있을 수 있으며, 항목 이름도 ‘업데이트 주기’ 또는 ‘자동 업데이트’로 다를 수 있습니다. 로컬 YAML 파일이 아닌 원격 구독을 편집 중인지 먼저 확인하세요.

왼쪽 메뉴에서 ‘구독’을 열고 현재 사용하는 구독 카드를 찾아 카드에 표시된 마지막 업데이트 시간을 확인합니다.
구독 카드를 마우스 오른쪽 버튼으로 클릭한 다음 ‘정보 편집’을 선택합니다. 더보기 메뉴를 사용하는 버전에서는 같은 카드의 메뉴에서 편집 화면을 여세요.
구독 URL이 서비스 제공업체에서 현재 안내하는 주소인지 확인하고, ‘업데이트 주기’ 항목에 표시된 단위에 맞춰 값을 입력합니다.
자동 업데이트를 별도로 켜는 스위치가 있다면 활성화한 뒤 저장합니다. 단위가 분이면 12시간은 720, 24시간은 1440입니다.
구독 카드로 돌아가 ‘업데이트’를 한 번 실행합니다. 다운로드나 파싱 오류가 없는지 확인한 다음 마지막 업데이트 시간이 바뀌었는지 살펴보세요.

‘정보 편집’과 ‘파일 편집’을 혼동하지 마세요. 전자는 보통 URL, 이름, 예약 업데이트 설정을 저장하고 후자는 설정 내용을 수정합니다. 전체 설정 파일 최상위에 interval: 720을 임의로 추가해도 클라이언트의 구독 업데이트 예약을 대신할 수 없습니다.

주기를 설정했는데도 자동 업데이트가 되지 않는 이유

데스크톱 클라이언트의 예약 작업은 대개 앱 프로세스가 계속 실행 중이어야 동작합니다. 창을 닫고 트레이에 남겨 둔 상태와 트레이 메뉴에서 앱을 종료한 상태는 다릅니다. 컴퓨터가 절전 모드인 동안에는 정해진 시각에 네트워크 요청을 보낼 수 없습니다. 절전에서 깨어난 뒤 바로 업데이트할지는 클라이언트 구현에 따라 다르므로, 절전 전에 설정한 시각만으로 동작을 단정할 수 없습니다.

클라이언트를 실행 상태로 유지하고 수동 업데이트가 정상적으로 되는지 확인하세요.
‘시작 프로그램에 등록’과 ‘시작할 때 업데이트’는 별개의 설정입니다. 전자를 켜도 후자가 실행된다는 보장은 없습니다.
같은 이름의 다른 구독 카드를 편집한 것은 아닌지, 현재 활성화된 설정이 방금 수정한 항목인지 확인하세요.
0이 즉시 업데이트를 뜻한다고 단정하지 마세요. 예약 업데이트를 끄거나 기본값을 사용한다는 의미일 수 있으니 현재 화면의 항목 설명을 확인해야 합니다.

업데이트 주기 선택: 6시간, 12시간, 24시간

업데이트 주기는 속도 측정 결과가 아니라 구독 내용이 바뀌는 빈도를 기준으로 정하세요. 노드 지연 시간이 늘었다고 구독이 오래된 것은 아닐 수 있습니다. 노드가 중단되고 서비스 제공업체가 대체 주소를 배포한 경우에는 구독 업데이트로 해결될 수 있습니다.

사용 환경	권장 주기	분 / 초
서비스 제공업체가 노드를 자주 변경하는 경우	6시간	360 / 21600
일반적인 데스크톱 사용	12시간	720 / 43200
노드가 안정적이고 여러 기기에서 사용하는 경우	24시간	1440 / 86400

표의 값은 설정 권장사항일 뿐 서버가 보장하는 조건은 아닙니다. 특별한 이유가 없다면 1분마다 새로고침하도록 설정하지 마세요. 하루에 1,440회 요청이 발생하며, 여러 기기에서 같은 주소를 사용하면 요청량이 더 늘어 서버의 요청 제한에 걸릴 수 있습니다. 노드에 문제가 한꺼번에 발생했다면 수동 업데이트를 한 번 실행해 보세요. 업데이트 버튼을 연달아 눌러도 서버 복구가 빨라지지는 않습니다.

구독 응답이나 서비스 제공업체 안내에 권장 주기가 포함되어 있다면 클라이언트가 해당 값을 반영했는지도 확인하세요. 특히 이전 클라이언트에서 설정을 옮겼다면 가져올 때 보인 기본 숫자만 보고 단위를 판단하지 마세요.

mihomo proxy-providers의 interval 단위는 초

mihomo 설정을 직접 관리한다면 HTTP 노드 제공자의 interval은 해당 제공자 항목 아래에 지정하며, 단위는 초입니다. 아래 예시는 12시간마다 노드를 다운로드하고 5분마다 상태를 확인합니다. 두 주기는 서로 독립적입니다.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://subscription.example.net/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 43200
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: Subscription
    type: select
    use:
      - remote-nodes

예시의 subscription.example.net은 설명을 위한 도메인이므로 실제 노드를 가져올 수 없습니다. 실제로 배포할 때는 사용하는 노드 제공자 주소로 바꾸고, 응답 내용이 제공자 형식에 맞는지 확인하세요. 전체 Clash 설정 파일과 노드만 포함된 제공자 파일은 모든 상황에서 서로 바꿔 사용할 수 없습니다. 상태 확인 주소도 현재 네트워크에서 접속할 수 있는 주소로 선택해야 합니다.

interval: 43200: 제공자의 원격 내용을 업데이트하며, 기본 설정 파일 전체를 다운로드하지는 않습니다.
health-check.interval: 300: 노드 상태를 확인하며, 새 노드를 다운로드하지는 않습니다.
path: 로컬 캐시 파일의 경로를 지정합니다. 코어를 실행하는 계정에 해당 디렉터리의 쓰기 권한이 있어야 합니다.
use: 프록시 그룹에서 해당 제공자를 참조하도록 합니다. 제공자만 선언하고 참조하지 않으면 프록시 그룹에 해당 노드가 자동으로 표시되지 않습니다.

기본 설정을 수정한 뒤에는 mihomo가 설정을 다시 불러와야 새 주기가 적용됩니다. 기본 설정이 클라이언트의 구독 업데이트로 생성된다면 다운로드된 파일을 직접 수정해도 다음 업데이트 때 덮어쓰일 수 있습니다. 로컬 변경사항은 클라이언트에서 지원하는 오버라이드나 병합 기능으로 저장하세요.

구독 업데이트 실패 원인: 오류 유형별 점검 방법

1. 시간 초과 또는 도메인 이름 확인 실패: 구독 주소까지의 네트워크 경로 확인

웹페이지가 열린다는 것은 브라우저에서 사용하는 네트워크 경로가 작동한다는 뜻일 뿐입니다. 구독 요청은 클라이언트 백그라운드에서 전송될 수 있어 브라우저 확장 프로그램이나 동일한 시스템 프록시를 거치지 않을 수 있습니다. 먼저 로그에 기록된 구독 도메인과 오류를 확인한 뒤 DNS 조회 실패, TCP 연결 시간 초과, TLS 핸드셰이크 실패를 구분하세요.

로컬에서 해당 주소의 HTTP 상태 코드와 콘텐츠 유형을 확인할 수 있지만, 전체 구독 URL을 공개 진단 사이트에 올리지는 마세요. 브라우저에서 로그인 페이지나 인증 페이지가 반환되면 상태 코드가 200이어도 클라이언트는 HTML을 Clash 설정으로 파싱할 수 없습니다.

2. 현재 프록시를 사용할 수 없음: 업데이트 요청이 오류 노드에 의존하는 경우

일부 클라이언트는 ‘프록시를 통해 업데이트’ 같은 다운로드 방식을 제공합니다. 구독 도메인이 현재 사용할 수 없는 노드로 라우팅되면 업데이트 요청도 해당 노드에 의존해 완료되지 않는 악순환이 생길 수 있습니다. 우선 사용 가능한 노드로 전환한 뒤 수동 업데이트를 실행하세요. 구독 주소에 직접 연결할 수 있다면 클라이언트에서 지원하는 범위 내에서 직접 연결로 업데이트할 수도 있습니다.

이 문제만으로 모든 프록시 설정을 바로 끄지는 마세요. 구독 사이트에 프록시를 통해서만 접속할 수 있다면 강제로 직접 연결해도 문제가 계속 발생합니다. TUN 모드를 사용한다고 해서 구독 요청이 반드시 프록시를 거치는 것도 아닙니다. 실제 경로는 라우팅, 규칙, 앱의 요청 처리 방식에 따라 달라집니다.

3. 로컬 프록시 포트 이상: 설정된 포트와 실제 연결 값 확인

클라이언트의 혼합 포트가 7890으로 설정되어 있는데 외부 도구가 이전 포트인 7897에 계속 연결하면 연결이 거부될 수 있습니다. 이 숫자는 점검 방법을 설명하기 위한 예시입니다. 실제 값은 현재 클라이언트 설정에서 확인해야 하며, 어느 포트도 모든 클라이언트의 고정 기본값으로 간주하면 안 됩니다.

프록시 클라이언트 두 개가 동시에 실행되어 사용하려는 포트를 다른 프로세스가 점유하고 있지 않은지 확인하세요.
로그에 address already in use 또는 connection refused가 표시되는지 확인하세요.
포트를 변경했다면 시스템 프록시, 브라우저 프록시 확장 프로그램, 터미널의 HTTP_PROXY 및 HTTPS_PROXY 환경 변수도 함께 확인하세요.

포트 충돌이 반드시 구독 다운로드를 막는 것은 아닙니다. 업데이트 요청이 해당 로컬 프록시 포트를 이용할 때만 그 경로에서 실패합니다. 로그에 서버의 403 응답이 이미 기록됐다면 포트를 계속 바꾸기보다 주소 접근 권한을 확인하세요.

4. 401·403·404·429 오류: 권한, 링크, 요청 제한 확인

401은 보통 인증 문제, 403은 권한 제한이나 사이트 보호 조치, 404는 주소 경로가 더 이상 유효하지 않을 가능성을 나타냅니다. 429는 요청이 너무 많다는 뜻입니다. 이 상태 코드만으로 요금제가 만료됐다고 단정할 수는 없으므로 서비스 제공업체 계정 페이지와 응답 내용을 함께 확인하세요.

서비스 제공업체 계정에서 Clash 또는 mihomo에 맞는 구독 주소를 다시 복사하고, 구독이 재설정되었는지, 계정이 만료되었는지, 트래픽을 모두 사용했는지 확인하세요. 429가 반환되면 연속으로 재시도하지 마세요. Retry-After 안내가 있으면 그 시간만큼 기다린 뒤 각 기기의 자동 업데이트 주기를 늘리세요.

5. 다운로드는 성공했지만 파싱 실패: 응답 형식과 코어 지원 여부 확인

‘파싱 실패’와 ‘네트워크 시간 초과’는 서로 다른 문제입니다. 응답이 YAML 형식인지, 웹 공유 주소를 잘못 복사하지 않았는지, 다른 클라이언트용 구독 형식을 가져온 것은 아닌지 확인하세요. 새 프로토콜이나 필드를 사용하려면 최신 mihomo 코어가 필요할 수도 있습니다. 그래픽 인터페이스에서 열리더라도 코어가 모든 노드 유형을 인식하는 것은 아닙니다.

백업하기 전에 아직 사용할 수 있는 이전 설정을 삭제하지 마세요. 현재 설정을 보존한 뒤 다운로드한 내용과 오류 행 번호를 확인하세요. YAML을 점검할 때는 들여쓰기에 공백을 사용하고 같은 단계에서는 들여쓰기 수준을 맞추세요. 특수 문자가 포함된 URL은 따옴표로 감싸야 합니다.

변경 후 확인 절차와 구독 주소 보호

설정을 마친 뒤 ‘수동 다운로드 성공’과 ‘예약 작업 실행’을 각각 한 번 이상 확인하세요. 전자는 주소와 현재 네트워크가 작동한다는 뜻이고, 후자까지 확인해야 자동 업데이트 설정이 적용됐다고 볼 수 있습니다. 서버가 이전과 완전히 같은 내용을 반환할 수 있으므로 노드 수만으로 판단하지 마세요.

구독 이름, 마지막 업데이트 시간, 설정한 주기를 기록하세요. 예: 720분.
수동 업데이트를 실행하고 다운로드 실패, 파싱 실패, 설정 적용 실패가 로그에 없는지 확인하세요.
클라이언트를 계속 실행한 상태로 업데이트 주기 한 번이 지날 때까지 기다린 다음 업데이트 시간과 관련 로그를 확인하세요.
다운로드는 성공했는데 노드가 바뀌지 않았다면 현재 활성화된 설정과 제공자 참조를 확인한 뒤 서버에서 실제로 새 내용을 배포했는지 살펴보세요.
확인이 끝나면 정상적인 주기로 되돌리세요. 테스트용으로 설정한 짧은 주기를 여러 기기에서 계속 사용하지 마세요.

다음 순서로 점검하면 됩니다: 업데이트 대상과 단위 확인 → 수동 업데이트 → 오류 유형 확인 → 요청 경로 점검 → 예약 실행 여부 확인. 시스템 프록시, 규칙 모드, TUN 설정을 확인하려면 문제 해결을 참고하세요. 구독을 처음 가져오는 경우에는 설정 가이드부터 시작하세요.