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

먼저 구분하기: 구독 다운로드 실패인가, 설정 적용 실패인가

클라이언트의 ‘구독’ 또는 ‘프로필’ 화면에서 오류가 난 구독 항목을 찾아 마지막 업데이트 시각을 기록한 다음, 수동으로 한 번 업데이트해 보세요. 이어서 ‘로그’를 열고 해당 작업에서 발생한 오류를 확인합니다. 먼저 어느 단계에서 실패했는지 파악한 뒤 네트워크와 업데이트 주기를 조정해야 노드 문제를 구독 오류로 오인하지 않습니다.

• 다운로드 단계 실패: timeout, connection refused, no such host 또는 HTTP 오류 코드가 나타나면 구독 URL과 접속 경로부터 확인하세요.
• 파싱 단계 실패: 콘텐츠를 받았지만 yaml, unmarshal, unsupported proxy type 오류가 나타나면 응답 형식과 코어 지원 여부를 먼저 확인하세요.
• 적용 단계 실패: 구독 업데이트는 성공으로 표시되지만 설정을 전환할 때 오류가 난다면 규칙 참조, 프록시 그룹 이름, 설정 병합 결과를 확인하세요.
• 노드 연결 실패: 설정은 이미 불러왔고 노드 속도 측정만 시간 초과되는 경우입니다. 노드 사용 가능 여부 문제이므로 구독을 계속 새로고침해도 해결되지 않을 수 있습니다.

오류별 확인 방법: 시간 초과, 인증서, HTTP 상태 코드

같은 ‘업데이트 실패’ 메시지도 원인은 서로 다를 수 있습니다. 아래 상태 코드는 구독 다운로드 요청의 응답이며 노드 속도 측정 결과가 아닙니다. 항목에 표시된 빨간 오류만 보지 말고 클라이언트 로그에서 전체 오류 유형을 확인하세요.

시간 초과: 규칙을 바꾸기 전에 접속 경로부터 확인

현재 Wi-Fi 대신 모바일 핫스팟을 연결한 뒤 수동으로 한 번 업데이트해 보세요. 핫스팟에서는 성공하지만 기존 네트워크에서 실패한다면 해당 네트워크의 DNS, 접근 제한 또는 게이트웨이를 확인하세요. 프록시를 통해서만 업데이트된다면 기존 프록시 경로를 이용해야 구독 주소에 접속할 수 있다는 뜻입니다. 반대로 프록시에서는 실패하고 직접 연결에서는 성공한다면 현재 프록시 노드와 클라이언트의 구독 다운로드 방식을 확인하세요.

일부 클라이언트에서는 다운로드 시간 초과 설정을 조정할 수 있습니다. 비교를 위해 10초를 30초로 바꿔 볼 수 있지만, 모든 클라이언트에 이 옵션이 있는 것은 아닙니다. 도메인을 확인할 수 없거나 인증 정보가 만료된 경우에는 대기 시간을 늘려도 해결되지 않습니다.

인증서 오류: 시간 동기화 후 네트워크 환경 확인

Windows 11에서 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’을 열고 ‘자동으로 시간 설정’을 켠 다음 ‘지금 동기화’를 실행하세요. 시스템 시간 오차는 인증서 유효 기간 판단에 영향을 줍니다. 회사나 학교 네트워크에서만 오류가 난다면 휴대폰 핫스팟으로 다시 확인하세요. 조직 인증서가 필요한 기기는 관리자 안내에 따라 시스템 신뢰 설정을 구성해야 합니다.

인증서 검증을 끄는 방법은 일반적인 해결책으로 사용하지 마세요. 구독에는 노드 주소와 인증 정보가 들어 있으므로 검증을 건너뛰면 다운로드 과정에서 상대방의 신원을 확인하기 어려워집니다. 특히 노드 설정의 skip-cert-verify는 해당 노드 연결의 인증서 검증을 제어하는 옵션이며, 클라이언트의 구독 다운로드 TLS 오류를 일반적으로 해결해 주지는 않습니다.

응답 콘텐츠 확인: YAML, Base64, 로그인 페이지

텍스트를 다운로드했다고 해서 Clash 설정을 받은 것은 아닙니다. 계정 관리 페이지 URL을 복사했거나, 다른 클라이언트 전용 구독 링크를 사용했거나, 복사 과정에서 URL 뒤쪽 매개변수가 빠진 경우가 흔합니다. 서비스 계정 페이지로 돌아가 Clash 또는 mihomo용이라고 명확히 표시된 구독 주소를 선택해 전체를 복사하세요. 토큰을 직접 삭제하거나 수정하지 마세요.

콘텐츠로 형식 구분하기

• 완전한 Clash 설정: 일반적으로 proxies 또는 proxy-providers와 프록시 그룹, 규칙 등의 설정이 포함됩니다. 구체적인 필드는 서비스에서 생성하는 방식에 따라 달라지므로 파일 확장자만으로 판단할 수 없습니다.
• 프록시 제공자 콘텐츠: 보통 proxies: 아래에 노드 목록이 구성됩니다. 기본 설정의 proxy-providers에서 참조해야 하며, 완전한 설정인 것처럼 바로 적용해서는 안 됩니다.
• Base64 노드 목록: 디코딩하면 프로토콜 링크가 한 줄씩 나올 수 있습니다. Clash YAML과는 다른 형식이며, 가져오기나 변환을 지원하는지는 클라이언트 구현에 따라 다릅니다.
• HTML 페이지: 콘텐츠가 <!DOCTYPE html>로 시작하거나 로그인, 인증, 접근 거부 문구가 포함되어 있다면 구독 설정이 아닌 웹페이지를 받은 것입니다.

브라우저에서 구독 URL이 열린다고 해서 클라이언트에서도 다운로드할 수 있는 것은 아닙니다. 브라우저에는 로그인 쿠키가 있을 수 있지만 클라이언트는 보통 해당 로그인 상태를 이어받지 않습니다. 브라우저와 클라이언트의 프록시 경로도 다를 수 있습니다. 웹 로그인이 필요하거나 추가 인증을 거쳐야 하는 API라면 서비스에 클라이언트 전용 구독 주소를 요청하세요.

파싱 오류: 코어 호환성을 확인하고 들여쓰기를 무작정 수정하지 마세요

unsupported proxy type 오류가 나면 먼저 클라이언트의 ‘정보’ 또는 코어 정보 화면에서 클라이언트 버전과 코어 이름을 확인하세요. Clash 생태계의 코어마다 지원 범위가 다르며, mihomo용으로 생성된 설정이 구형 Clash 코어에서 작동하지 않을 수 있습니다. 서비스의 형식 옵션에서 호환 형식을 선택하거나 필요한 프로토콜을 지원하는 클라이언트를 사용하세요.

줄 번호가 표시된 YAML 오류가 발생하면 해당 위치의 들여쓰기, 콜론, 따옴표를 확인하세요. 원격 설정이 업데이트될 때마다 로컬 파일을 덮어쓴다면 캐시 파일만 수정할 것이 아니라 상위 설정 생성 방식이나 클라이언트의 덮어쓰기 규칙을 고쳐야 합니다. 그렇지 않으면 다음 업데이트에서 같은 오류가 반복됩니다.

프록시로 업데이트: 사용 가능한 기존 노드를 통해 다운로드

‘시스템 프록시 사용’과 ‘프록시를 통한 구독 다운로드’는 같은 설정이 아닙니다. 구독 요청은 클라이언트 자체 또는 코어에서 보낼 수 있으며, 시스템 프록시를 따르는지는 클라이언트 구현에 달려 있습니다. 규칙 모드, 전역 모드 또는 TUN 모드만 전환해도 구독 다운로드 경로가 바뀐다고 보장할 수 없습니다.

1. 현재 작동하는 기존 설정을 활성화하고 사용 가능한 노드를 선택한 다음, 일반 HTTPS 요청이 정상적으로 완료되는지 먼저 확인하세요.
2. ‘구독’ 또는 ‘프로필’을 열고 대상 구독의 편집 또는 업데이트 메뉴에서 ‘프록시로 업데이트’, ‘프록시 사용’과 같은 옵션을 찾으세요. 옵션 이름과 위치는 클라이언트 버전에 따라 다릅니다.
3. 해당 옵션이 있으면 켠 뒤 수동으로 한 번 업데이트하고 로그에서 결과를 확인하세요. 옵션이 없다면 클라이언트 문서를 확인하고 숨겨진 매개변수를 추측해 사용하지 마세요.
4. 업데이트가 성공하면 업데이트 시각, 노드 목록, 설정 적용 상태를 확인한 뒤 이 다운로드 경로를 계속 사용할지 결정하세요.

이 PC의 혼합 포트가 실제로 7890으로 설정된 Windows 기기를 예로 들면 PowerShell에서 다음 두 가지를 확인할 수 있습니다. 클라이언트에 다른 포트가 표시된다면 화면에 나온 실제 포트를 사용하세요.

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -I https://clash13.com/

첫 번째 명령은 로컬 포트가 연결을 받는지 확인하고, 두 번째 명령은 로컬 HTTP 프록시를 명시적으로 거쳐 HTTPS 요청을 테스트합니다. 사이트 응답은 해당 요청의 결과만 보여 줄 뿐, 구독 주소에 연결할 수 있는지 또는 클라이언트의 구독 요청이 같은 경로를 사용하는지 증명하지는 않습니다. 프록시 접속에 인증이 필요하다면 로컬 설정에 맞는 인증 정보도 제공해야 합니다.

자동 업데이트 주기: 클라이언트 구독과 제공자를 구분하세요

자동 업데이트에는 두 가지 단계가 있습니다. 클라이언트가 원격 설정 전체를 정기적으로 다운로드하는 방식과 mihomo가 설정 안의 프록시 제공자를 정기적으로 새로고침하는 방식입니다. 두 기능은 함께 사용할 수 있지만 서로 같지는 않습니다. 클라이언트 항목에 표시된 업데이트 시각이 특정 제공자의 방금 전 새로고침을 의미하지 않을 수도 있습니다.

전체 구독: 클라이언트 구독 편집 화면에서 설정

‘구독’ 또는 ‘프로필’ → 대상 구독 메뉴 → ‘편집’으로 이동해 자동 업데이트 스위치와 업데이트 주기를 찾으세요. 입력란 옆의 단위를 먼저 확인해야 합니다. 360을 입력했을 때 단위가 분이면 6시간이고 초라면 6분입니다. 자동 업데이트 옵션이 없는 클라이언트에서는 YAML 최상위에 interval을 임의로 추가해도 기능이 생기지 않습니다.

• 일반 사용: 우선 6시간 또는 12시간을 선택할 수 있습니다. 각각 360분과 720분에 해당하며, 이후 서비스 안내에 맞춰 조정하세요.
• 노드 변경이 드문 경우: 불필요한 요청을 줄이도록 24시간, 즉 1440분으로 설정할 수 있습니다.
• 문제 해결 중: 수동으로 한 번 업데이트한 뒤 로그를 확인하세요. 임시로 매분 새로고침하도록 설정하지 마세요.

이 값은 설정을 위한 권장 예시이지 클라이언트 기본값이 아닙니다. 컴퓨터가 절전 모드이거나 클라이언트가 종료된 경우, 모바일 앱의 백그라운드 실행이 제한된 경우, 네트워크가 끊긴 경우에는 예약 작업이 실행되지 않을 수 있습니다. 다시 실행했을 때 작업을 보충하는지는 클라이언트에 따라 다릅니다. 설정한 시간이 지났는데 업데이트되지 않았다면 서버 오류라고 단정하기 전에 프로그램이 계속 실행 중이었는지 확인하세요.

프록시 제공자: interval 단위는 초

mihomo HTTP 프록시 제공자는 proxy-providers 아래 해당 제공자의 interval을 초 단위로 설정합니다. 6시간은 21600초, 12시간은 43200초, 24시간은 86400초입니다. 수정할 때는 해당 제공자의 기존 URL, 경로 및 다른 필드를 유지하고 새로고침 주기만 변경하세요.

제공자 내부의 health-check에 있는 interval은 노드 상태를 확인하는 설정이지 구독 다운로드 주기가 아닙니다. 상태 확인 주기를 300초로 설정해도 노드 목록이 5분마다 새로고침되는 것은 아닙니다. 제공자에 설정하는 초 단위 값을 클라이언트의 ‘분’ 단위 입력란에 그대로 복사하지 마세요.

수동 강제 새로고침: 결과를 확인한 뒤 캐시 처리

‘강제 새로고침’은 모든 클라이언트에 공통으로 있는 버튼이 아닙니다. ‘업데이트’만 있는 경우도 있고 ‘모두 업데이트’나 ‘프록시 제공자 업데이트’가 별도로 있는 경우도 있습니다. 원격 설정 전체를 새로고침할지 설정 내부의 제공자를 새로고침할지 먼저 구분하세요. 외부 설정만 업데이트해도 모든 제공자가 바로 다시 다운로드되는 것은 아닙니다.

1. 백업 및 기록: 현재 사용할 수 있는 설정을 저장하고 대상 구독 이름, 마지막 업데이트 시각, 업데이트 전 노드 수를 기록하세요.
2. 한 번 실행: 대상 구독에서 ‘업데이트’를 누르고 요청이 끝날 때까지 기다리세요. 429가 나타나면 반복해서 누르지 마세요.
3. 불러오기 확인: 로그에서 다운로드, 파싱, 적용이 성공했는지 확인하세요. 클라이언트에서 새 설정을 직접 활성화해야 한다면 전환도 진행하세요.
4. 콘텐츠 확인: 변경된 것으로 알고 있는 노드나 규칙을 확인하세요. 노드 수가 그대로여도 업데이트가 안 된 것은 아닙니다. 서버가 내용이 바뀌지 않은 응답을 보냈을 수도 있습니다.
5. 마지막으로 캐시 처리: 주소가 올바르고 응답도 유효한데 클라이언트가 계속 이전 콘텐츠를 읽을 때만 해당 클라이언트 문서에 따라 대상 캐시를 처리하세요. 설정 폴더 전체를 비우지 마세요.

캐시를 ‘무시’하려고 구독 URL 뒤에 임의의 매개변수를 추가하지 마세요. 일부 서비스는 서명이나 쿼리 매개변수를 엄격하게 검사하므로 수정하면 링크가 바로 무효가 될 수 있습니다. 304 Not Modified는 일반적으로 서버가 기존 캐시를 유효하다고 판단했다는 뜻이므로, 이 상태만 보고 업데이트 실패라고 판단해서도 안 됩니다.

계속 실패한다면: 재현 가능한 정보 정리

먼저 최소한의 비교 테스트를 진행하세요. 같은 구독을 기존 네트워크와 휴대폰 핫스팟에서 각각 확인하고, 직접 연결과 프록시 다운로드도 비교합니다. 각 방식은 한 번씩만 시도하고 시간과 오류를 기록하세요. 네 가지 결과만으로도 네트워크 경로, 구독 서비스, 클라이언트 처리 문제를 구분하는 데 도움이 됩니다. 열 번 연속으로 누르는 것보다 원인을 찾기 쉽습니다.

• 운영체제, 클라이언트의 정확한 버전, 코어 이름과 버전을 기록하세요. ‘최신 버전’이라고만 쓰지 마세요.
• 구독 다운로드 오류 코드, 파싱 성공 여부, 오류가 발생한 현지 시각과 시간대를 기록하세요.
• 시스템 프록시, TUN, 프록시를 통한 구독 업데이트가 각각 활성화되어 있는지 적어 주세요.
• 민감 정보를 가린 오류 로그 일부를 제공하세요. 전체 구독 URL, 노드 비밀번호, 원본 설정은 공개하지 마세요.

문제가 해결되면 자동 업데이트를 적절한 주기로 설정하고 정상 작동을 확인한 설정을 보관하세요. 구독 업데이트는 설정을 가져오는 단계입니다. 노드 연결, 규칙에 따른 트래픽 분기, 앱의 프록시 사용 여부는 각각 따로 확인해야 합니다. 단계를 나눠 점검하면 다음에 같은 문제가 생겨도 해당 지점부터 바로 살펴볼 수 있습니다.