Clash 구독 업데이트 실패 해결법: 오류 원인과 자동 업데이트 간격 설정

구독 다운로드 실패인지, 설정 불러오기 실패인지 먼저 확인하세요

Clash 구독 업데이트는 보통 세 단계를 거칩니다. 클라이언트가 구독 주소에 요청을 보내고, 응답을 설정 파일로 저장한 다음, 코어가 설정을 검사하고 불러옵니다. ‘업데이트 실패’는 어느 단계에서든 발생할 수 있습니다. 노드에 계속 연결된다면 기존 설정이 작동 중일 수 있지만, 새 구독을 다운로드했다는 뜻은 아닙니다. 화면의 업데이트 시간이 바뀌어도 새 설정이 정상적으로 적용되지 않았을 수 있습니다.

먼저 클라이언트의 ‘설정’ 또는 ‘Profiles’ 페이지에서 현재 구독 카드를 찾아 ‘업데이트’를 한 번 수동으로 실행하세요. 그런 다음 ‘로그’ 또는 ‘Logs’에서 같은 시각의 오류를 확인합니다. 메뉴 이름은 클라이언트와 버전에 따라 다를 수 있습니다. 노드 목록의 지연 시간 테스트가 아니라 구독 항목 자체의 업데이트 기능을 찾으세요.

1. 오류 원문을 기록하세요: context deadline exceeded, 403, x509, yaml: line 12처럼 구체적인 내용을 남기고, ‘실패’라고만 기록하지 마세요.
2. 영향 범위를 확인하세요: 구독 하나만 실패하면 링크와 서버를 먼저 확인하세요. 서로 다른 출처의 구독이 여러 개 동시에 실패하면 기기의 네트워크, 시간, 클라이언트 설정을 살펴보세요.
3. 사용 중인 설정을 보관하세요: 다운로드 방식을 바꾸기 전에 현재 설정을 내보내거나 백업하세요. 백업 파일에도 노드 비밀번호가 포함될 수 있으므로 안전한 곳에 보관해야 합니다.

오류별 확인 방법: 시간 초과, 상태 코드, 파싱 오류

이 단서는 원인을 좁히는 데 도움이 되지만, 확정적인 결론은 아닙니다. 예를 들어 403은 계정 만료가 아니라 보안 게이트웨이에서 발생했을 수도 있습니다. 시간 초과도 DNS 조회, 연결 설정, TLS 핸드셰이크, 응답 본문 대기 중 어느 단계에서든 생길 수 있습니다. 판단할 때는 오류 전후의 로그를 남기되 요청에 포함된 인증 정보는 공개하지 마세요.

구독 다운로드 시간 초과: 요청이 어떤 네트워크를 사용하는지 확인하세요

브라우저에서 열려도 클라이언트에서 다운로드된다는 보장은 없습니다

브라우저는 시스템 프록시, 자체 보안 DNS 또는 로그인 세션을 사용할 수 있습니다. 반면 클라이언트의 구독 다운로드 기능은 직접 연결하거나 별도의 프록시 설정을 사용할 수 있습니다. 따라서 ‘브라우저에서는 다운로드되는데 Clash는 업데이트되지 않는’ 상황도 가능합니다. 먼저 클라이언트 설정에서 ‘프록시를 통해 업데이트’와 비슷한 옵션이 있는지 확인하고, 로그에서 실제로 구독 서버에 연결하는지 아니면 로컬 프록시 포트에 연결하는지 살펴보세요.

• 직접 연결 요청이 시간 초과되는 경우: 같은 기기에서 휴대폰 핫스팟으로 전환한 뒤 다시 업데이트하세요. 핫스팟에서는 정상적으로 작동한다면 기존 네트워크의 DNS, 외부 연결 또는 접속 정책이 원인일 가능성이 높습니다.
• 프록시를 통한 업데이트가 실패하는 경우: 선택한 노드로 일반 웹사이트에 접속할 수 있는지 먼저 확인하세요. 기존 노드가 모두 작동하지 않으면 해당 노드로 새 구독을 다운로드하려는 시도는 악순환이 될 수 있습니다.
• 오류에 로컬 포트가 표시되는 경우: 예를 들어 127.0.0.1:7890이라면 코어가 실행 중인지, 혼합 프록시 포트가 실제로 7890인지 확인하세요. 이 값은 흔한 예시일 뿐이므로 클라이언트에 표시된 실제 포트와 비교해야 합니다.

구독을 새로고침하려고 ‘LAN 연결 허용’을 켜지 마세요. 로컬 프로그램이 루프백 주소로 프록시에 접속하는 데는 LAN 포트를 외부에 열 필요가 없습니다. TUN도 구독 업데이트에 반드시 필요한 기능은 아닙니다. TUN은 네트워크 트래픽을 가로채는 기능이며, 구독 다운로드가 해당 경로를 이용하는지는 라우팅, 프로세스 제외 설정, 클라이언트 구현에 따라 달라집니다.

연속으로 누르지 말고 한 번씩 비교 테스트하세요

같은 구독 주소를 유지한 채 ‘현재 네트워크에서 직접 연결’, ‘현재 네트워크에서 정상 작동하는 프록시 이용’, ‘다른 네트워크’를 차례로 테스트하세요. 한 번에 조건 하나만 바꾸면 됩니다. 클라이언트에 다운로드 시간 초과 설정이 있다면 너무 짧게 설정된 경우 적절히 늘릴 수 있습니다. 다만 DNS 조회 실패, 인증 정보 만료, 서버의 접근 거부는 시간 제한을 늘려도 해결되지 않습니다.

파싱 오류: Clash 설정을 받아왔는지 확인하세요

구독 링크에서 항상 같은 형식의 콘텐츠가 반환되는 것은 아닙니다. 완전한 Clash 설정에는 보통 proxies, proxy-groups, rules 등의 필드가 들어 있습니다. 노드 모음 파일에는 proxies만 있을 수 있으며, 이는 프록시 모음용입니다. 범용 구독 중에는 인코딩된 노드 URI 목록을 반환하는 유형도 있는데, 이를 완전한 YAML 설정처럼 불러올 수는 없습니다.

YAML을 수정하기 전에 응답 형식부터 확인하세요

1. 서비스 제공자 계정 페이지에서 Clash, Clash Meta 또는 mihomo용이라고 명시된 구독 주소를 선택하고, 현재 클라이언트 코어가 해당 형식을 지원하는지 확인하세요.
2. 응답 첫 부분에 <!DOCTYPE html>, 로그인 페이지 제목 또는 CAPTCHA 페이지가 보인다면 설정 파일이 아니라 웹페이지를 다운로드한 것입니다. 로그인 리디렉션, 접근 제한 또는 잘못된 주소를 확인하세요.
3. 내용이 vmess://, ss:// 같은 노드 링크 목록이라면 클라이언트가 명시적으로 지원하는 가져오기 방법을 사용하거나 서비스 제공자에게 해당 형식을 요청하세요.
4. 로그에 YAML 행 번호가 표시되면 로컬 복사본에서 해당 행과 앞선 몇 행의 들여쓰기, 콜론, 따옴표를 확인하세요. YAML 들여쓰기에는 공백을 사용하고 탭 문자는 넣지 마세요.

파일 확장자를 .yaml로 바꾸는 것만으로는 콘텐츠 형식이 변환되지 않습니다. 출처를 알 수 없는 온라인 변환 사이트에 전체 구독 주소를 입력하는 것도 피하세요. 변환 서비스가 노드와 인증 정보를 읽을 수 있습니다. 서비스 제공자가 제공하는 출력 형식이나 신뢰할 수 있는 로컬 도구를 우선 사용하세요.

구문이 올바르더라도 코어와 호환되지 않을 수 있습니다

로그에 unsupported proxy type이 표시되거나 지원되지 않는 필드가 지목된다면 다운로드 문제가 아니라 현재 코어에서 구현되지 않은 프로토콜이나 옵션을 설정에서 사용했을 수 있습니다. Clash 원본, Clash Meta, 이후 버전의 mihomo는 지원 기능이 완전히 같지 않습니다. 클라이언트의 ‘정보’ 또는 코어 정보 페이지에서 실제 실행 중인 코어를 확인한 뒤 호환되는 구독 형식을 선택하세요. 앱 이름만으로는 호환 여부를 판단하기 어렵습니다.

새로 다운로드한 설정에 구문 오류나 호환성 문제가 있으면, 모르는 필드를 하나씩 삭제하기보다 백업으로 먼저 되돌리세요. 프록시 그룹, 프록시 모음 또는 규칙 참조를 삭제하면 ‘정책을 찾을 수 없음’과 같은 로드 오류가 추가로 발생할 수 있습니다.

인증서 오류와 링크 문제는 따로 확인하세요

x509 오류가 발생하면 먼저 기기 시간을 확인하세요

인증서 검증에는 올바른 날짜와 시간이 필요합니다. Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 자동 시간 설정을 확인하고 동기화를 실행하세요. macOS에서는 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 자동 설정을 확인하면 됩니다. 시간을 바로잡은 뒤 다시 업데이트하세요. 구독 형식을 먼저 바꿀 필요는 없습니다.

• certificate has expired or is not yet valid: 기기 시간을 확인하세요. 시간이 정확하다면 서버 측에서 인증서 유효 기간을 확인해야 합니다.
• certificate signed by unknown authority: 인증서 체인이 불완전하거나 기기의 신뢰 저장소에 문제가 있을 수 있습니다. 네트워크에서 HTTPS 검사를 수행하는 경우도 있습니다.
• 인증서 도메인 불일치: 링크가 IP 주소로 바뀌었거나 일치하지 않는 도메인으로 리디렉션됐는지 확인하세요. 우선 서비스 제공자가 안내한 HTTPS 주소를 다시 복사하세요.

노드 설정의 skip-cert-verify는 해당 노드 연결의 인증서 검증을 제어합니다. 구독 다운로드 오류를 전반적으로 해결하는 옵션이 아닙니다. 문제를 진단하려고 인증서 검증을 끄면 보안 위험이 커지며, 인증 실패나 YAML 형식 오류도 해결되지 않습니다.

401·403 오류와 계정 상태

서비스 제공자 계정에 로그인해 요금제가 유효한지, 구독 주소가 재설정되었는지, 요청 빈도나 기기 제한이 있는지 확인하세요. 링크를 복사할 때는 계정 페이지의 복사 버튼을 사용해 표시된 텍스트의 줄임표, 줄바꿈, 한글 문장부호가 들어가지 않도록 하세요. 물음표 뒤의 매개변수를 함부로 삭제하지 마세요. 인증 정보인 경우가 많습니다.

브라우저에서 로그인한 뒤 접근할 수 있는 페이지가 클라이언트에서 직접 요청할 수 있는 구독 API인 것은 아닙니다. 클라이언트는 보통 브라우저 로그인 쿠키를 이어받지 않습니다. 정상적인 주소는 서비스 제공자 규격에 따라 설정을 직접 반환해야 하며, 로그인 버튼을 누르도록 요구하지 않습니다.

자동 업데이트 간격: 클라이언트 구독과 프록시 모음을 구분하세요

‘얼마나 자주 업데이트할지’는 두 가지 설정으로 나뉩니다. 클라이언트에 저장된 원격 설정은 클라이언트가 관리합니다. 설정 내부의 proxy-providers는 해당 기능을 지원하는 코어가 관리합니다. 두 설정이 함께 존재할 수 있지만 같은 필드로 서로를 대체할 수는 없습니다.

전체 구독: 클라이언트 설정에서 조정하세요

‘설정’ 또는 ‘Profiles’로 이동 → 원격 구독 카드를 찾기 → 마우스 오른쪽 버튼 메뉴나 더보기 메뉴 열기 → ‘편집’, ‘구독 설정’ 또는 ‘자동 업데이트’를 찾으세요. 현재 버전에서 업데이트 간격을 설정할 수 있다면 입력란 옆의 단위를 확인한 뒤 저장하세요. 해당 옵션이 없다면 클라이언트 도움말을 확인하세요. 최상위 설정에 interval을 임의로 추가해도 화면에서 자동으로 새로고침되지는 않습니다.

이 값은 설정을 시작할 때 참고하는 기준일 뿐 노드 품질을 나타내지 않습니다. 간격을 1분으로 설정해도 노드가 빨라지지 않으며, 오히려 요청 제한에 걸릴 수 있습니다. 여러 기기에서 같은 구독을 사용한다면 요청이 누적되는 점도 고려하세요. 컴퓨터가 절전 모드에 있거나 휴대폰의 백그라운드 실행이 제한되거나 클라이언트가 종료된 경우 업데이트 작업이 제시간에 실행되지 않을 수 있습니다. 다시 실행한 뒤 마지막 성공 시각과 로그를 확인하세요.

프록시 모음: interval 단위는 초입니다

아래는 프록시 모음을 지원하는 코어의 설정 예시입니다. 예시 도메인은 구조를 보여 주기 위한 것이므로 사용 전에 서비스 제공자가 안내한 실제 프록시 모음 주소로 바꿔야 합니다. 이 코드는 단독으로 실행되는 완전한 설정이 아닙니다.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.com/nodes.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 21600
    health-check:
      enable: false

여기서 interval: 21600은 21600초, 즉 6시간마다 모음을 가져온다는 뜻입니다. 응답은 해당 코어가 지원하는 프록시 모음 형식이어야 하며, 보통 proxies 목록을 포함합니다. 아무 완전한 설정 구독이나 그대로 입력하면 안 됩니다. 정책 그룹에서 사용하려면 해당 그룹의 use 목록에 remote-nodes를 지정해야 합니다.

health-check는 노드의 연결 가능 여부를 확인하는 기능이며, 노드 목록을 다시 다운로드하는 기능과 다릅니다. 예시에서는 업데이트 동작만 확인할 수 있도록 이 기능을 꺼 두었습니다. 구독 업데이트 속도를 높이려고 상태 확인 간격을 줄이지 마세요. 두 설정은 서로 다른 문제를 해결합니다.

설정 후 전체 업데이트 과정을 한 번 확인하세요

1. 수동으로 한 번 새로고침하세요: 로그에 기존 다운로드 또는 파싱 오류가 더 이상 나타나지 않는지 확인하고 마지막 성공 시각을 기록하세요.
2. 설정이 적용됐는지 확인하세요: 현재 활성 설정이 대상 구독인지 확인하고 노드와 정책 그룹이 정상적으로 표시되는지 살펴보세요.
3. 정책 선택 상태를 유지하세요: 업데이트 후 정책 그룹에서 사용 가능한 노드가 선택되어 있는지 확인하세요. 구독 다운로드에 성공해도 모든 노드에 연결할 수 있는 것은 아닙니다.
4. 실제 접속을 테스트하세요: 평소 이용하는 웹사이트를 열고 연결 상태와 로그를 확인하세요. 노드 연결 실패와 구독 다운로드 실패는 구분해서 해결해야 합니다.
5. 업데이트 주기를 한 번 기다리세요: 클라이언트가 실행될 수 있는 상태로 둔 뒤 새로운 성공 기록이 있는지 확인하세요. 수동 업데이트만 성공한다면 예약 작업, 백그라운드 권한, 실행 상태를 집중적으로 살펴보세요.

클라이언트 개발자나 서비스 제공자에게 문의해야 한다면 운영체제와 클라이언트 버전, 코어 이름과 버전, 오류 발생 시각, 오류 전문, 직접 연결과 프록시 다운로드 결과를 함께 전달하세요. 이런 정보가 ‘구독이 안 돼요’라는 설명보다 문제를 파악하는 데 도움이 됩니다. 전체 구독 주소, 노드 비밀번호, 계정 정보는 비공개 지원 채널에서만 공유하세요.