Clash 구독 업데이트 오류 해결 및 자동 업데이트 간격 설정
Clash 구독 업데이트가 실패하는 네트워크·인증서·만료된 링크·형식 호환성 문제를 살펴보고, 주요 클라이언트에서 자동 업데이트 간격을 설정하거나 프록시를 통해 구독을 갱신하는 방법을 안내합니다.
먼저 구독 다운로드와 노드 연결을 구분하세요
구독 업데이트에 실패하면 클라이언트를 바로 다시 설치하기보다 업데이트 요청의 오류부터 확인하세요. 구독 업데이트는 HTTP 또는 HTTPS 주소에서 설정 파일을 받아오는 과정이고, 노드 연결은 커널이 기존 설정에 따라 프록시 연결을 만드는 과정입니다. 두 작업은 서버, 인증 방식, 네트워크 경로가 서로 다를 수 있습니다. 기존 노드가 계속 작동한다고 해서 구독 링크가 유효한 것은 아니며, 구독 다운로드에 성공해도 모든 노드가 연결된다는 보장은 없습니다.
자주 혼동하는 또 다른 개념은 ‘전체 설정’과 ‘노드 제공자’입니다. 클라이언트의 구독 관리 화면은 보통 전체 설정을 다운로드한 뒤 커널에 불러옵니다. 반면 proxy-providers는 해당 기능을 지원하는 커널이 노드 목록을 다운로드하는 설정입니다. 두 기능은 업데이트 방식이 다릅니다. YAML의 interval만 바꿔도 클라이언트가 전체 구독을 새로고침하는 주기가 바뀌지 않을 수 있습니다.
- 클라이언트 이름과 버전, 커널 종류를 기록하세요. 예를 들어 mihomo를 사용하는지 확인합니다. ‘최신 Clash’라고만 적으면 충분하지 않습니다.
- 업데이트 버튼을 한 번 눌러 오류가 발생한 시각과 정확한 오류 유형을 기록하세요.
- 실패가 다운로드, 파싱, 설정 적용 중 어느 단계에서 발생했는지 확인하세요.
- 한 번에 한 가지 조건만 바꾸고, 성공한 다음 자동 업데이트를 설정하세요. DNS, 포트, 구독 주소를 동시에 바꾸지 마세요.
오류 메시지로 네트워크와 링크 문제 찾기
먼저 클라이언트의 구독 알림, 업데이트 상세 정보 또는 로그 화면을 확인하세요. 똑같이 ‘업데이트 실패’라고 표시되어도 실제 원인은 연결 시간 초과일 수도, 서버의 접근 거부 응답일 수도 있습니다. 아래와 같은 상태 코드와 오류 문구가 일반적인 팝업 안내보다 유용합니다.
| 오류 단서 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
no such host | 구독 도메인 이름을 확인할 수 없음 | 도메인 철자와 시스템 DNS를 확인한 뒤 다른 네트워크에서도 비교하세요 |
i/o timeout、context deadline exceeded | 연결·핸드셰이크·응답 수신 시간 초과 | 직접 연결과 이미 작동하는 프록시 경로를 각각 테스트하세요 |
401、403 | 토큰, 계정 상태 또는 접근 정책 | 서비스 제공업체 페이지에 로그인해 전용 구독 주소를 다시 복사하세요 |
404、410 | 주소가 변경되었거나 리소스가 삭제됨 | 페이지에 표시된 새 링크를 확인하고 이전 주소로 재시도하지 마세요 |
429 | 업데이트 빈도 제한에 걸림 | 연속해서 버튼을 누르지 말고 서버 안내에 따라 기다리세요 |
500、502、503 | 구독 서비스 또는 상위 서버의 일시적인 장애 | 기존 설정을 보관하고 잠시 기다린 뒤 다시 시도하세요 |
다른 네트워크에서 한 번 비교해 보세요
같은 기기에서 먼저 현재 Wi-Fi로 업데이트한 다음 휴대폰 핫스팟으로 시도하세요. 핫스팟에서는 성공한다면 현재 네트워크의 DNS, 외부 연결 제한 또는 인증 포털이 원인일 가능성이 큽니다. 공용 Wi-Fi에서 웹 로그인을 완료하지 않으면 구독 요청에 YAML 대신 로그인 페이지가 반환될 수 있습니다. 브라우저에서 서비스 제공업체의 홈페이지가 열린다고 해서 구독 하위 도메인과 API에도 접속할 수 있는 것은 아닙니다.
로그에 connection refused가 표시되면 어느 쪽에서 연결을 거부했는지 확인하세요. 대상이 127.0.0.1:7890이라면 구독 서버보다 로컬 프록시 포트가 열려 있는지 먼저 확인하는 편이 좋습니다. 7890은 흔히 쓰이는 예시일 뿐이므로 현재 클라이언트에 표시된 HTTP 또는 혼합 포트를 기준으로 확인하세요.
인증서 오류와 만료된 구독 링크는 따로 해결하세요
인증서 오류: 먼저 기기 시간을 확인한 뒤 네트워크를 살펴보세요
x509: certificate has expired or is not yet valid 오류는 서버 인증서가 만료된 경우뿐 아니라 기기 시간이 잘못된 경우에도 발생할 수 있습니다. 시스템의 날짜 및 시간 자동 설정을 켜고 연도, 날짜, 시간대가 맞는지 확인한 뒤 다시 업데이트하세요. certificate signed by unknown authority가 표시되면 시스템 인증서 저장소, 기업 네트워크의 HTTPS 검사, 클라이언트 실행 환경의 노후 여부를 확인하세요.
‘인증서 검증 건너뛰기’를 장기 해결책으로 사용하지 마세요. 구독 다운로드에는 계정 토큰이 포함될 수 있으므로 인증서 검증을 끄면 서버 신원을 확인하는 보안이 약해집니다. 또한 노드 설정의 skip-cert-verify는 보통 해당 노드의 TLS 연결에 적용되며, 클라이언트 자체의 구독 다운로드에서 발생한 인증서 문제를 일반적으로 해결하지 못합니다. 서버 인증서에 문제가 있다고 확인되면 서비스 제공업체가 이를 수정해야 합니다.
만료된 링크: 계정 페이지에서 새 링크를 받으세요
계정 만료, 토큰 재설정, 이전 구독 도메인 중단 등으로 기존 주소가 작동하지 않을 수 있습니다. 서비스 제공업체 페이지에서 요금제 상태를 확인하고 현재 클라이언트나 커널에 맞는 구독 형식을 선택한 다음 전체 링크를 복사하세요. 브라우저 로그인 페이지 주소를 복사하거나 물음표 뒤의 매개변수를 빠뜨리지 않도록 주의하세요. 메신저에서 URL이 자동으로 줄바꿈되거나 끝에 공백이 붙지 않았는지도 확인하세요.
- 링크를 바꾸기 전에 기존 구독 항목을 보관하세요. 새 설정을 추가해 업데이트가 되는지 확인한 다음 기존 항목을 삭제할 수 있습니다.
403오류가 발생해도 계정이 만료됐다고 단정하지 마세요. 요청 출처나 User-Agent 제한 때문에 거부될 수도 있습니다.- 브라우저 로그인 쿠키가 있어야 다운로드되는 페이지는 클라이언트의 자동 업데이트 주소로 사용할 수 없을 수 있습니다.
다운로드는 성공했지만 파싱에 실패할 때
HTTP 상태 코드 200은 서버가 콘텐츠를 성공적으로 반환했다는 뜻일 뿐, 그 내용이 Clash 설정이라는 의미는 아닙니다. 오류에 HTML 태그, DOCTYPE, 로그인 안내가 보인다면 웹페이지를 받은 경우가 많습니다. Base64 노드 목록이나 ss://, vmess:// 단일 노드 링크가 반환되더라도 전체 YAML 설정으로 가져올 수 있다고 단정하면 안 됩니다.
전체 설정과 provider 파일 구분하기
- 전체 설정: 일반적으로
proxies,proxy-groups,rules등의 필드가 포함되며, provider를 통해 외부 노드를 참조할 수도 있습니다. - 노드 provider: 흔히 YAML의
proxies:에 노드가 들어갑니다. 전체 정책 그룹과 규칙을 제공하는 파일은 아닙니다. - 규칙 provider: 보통
payload:에 규칙이 들어갑니다. 노드 구독으로 사용할 수 없습니다.
구버전 Clash 커널과 mihomo는 지원하는 프로토콜과 필드가 완전히 같지 않습니다. 로그에서 특정 프록시 유형을 지원하지 않는다고 알리면 들여쓰기만 바꾸지 말고 커널의 지원 여부를 확인하거나 호환되는 형식으로 출력하세요. YAML을 직접 편집할 때는 탭 대신 공백을 사용하고 같은 단계의 필드를 정렬하세요. 전체 설정의 규칙이 존재하지 않는 정책 그룹을 참조해도 ‘다운로드 완료 후 적용 실패’가 발생할 수 있습니다.
먼저 서비스 제공업체가 제공하는 올바른 형식으로 다시 다운로드하세요. 변환이 꼭 필요하다면 신뢰할 수 있는 로컬 도구나 직접 운영하는 변환 서비스를 사용하고, 변환 후 필요한 정책 그룹과 규칙이 유지됐는지 확인하세요. 문제를 해결하려고 토큰이 포함된 구독 URL을 공개해서는 안 됩니다.
클라이언트 자동 업데이트 간격 설정 방법
자동 새로고침은 수동 업데이트가 성공한 뒤에 켜세요. 처음에는 6시간 간격으로 설정할 수 있습니다. 단위가 분이면 360, 초이면 21600을 입력하세요. 관리하기 좋은 시작값일 뿐 모든 서비스에 적용되는 공통 기준은 아닙니다. 서비스 제공업체가 최소 업데이트 간격을 안내한다면 해당 기준을 따르세요.
주요 클라이언트 설정 위치
배포판마다 메뉴 이름이 다를 수 있으므로 전역 네트워크 설정만 찾지 말고 구독 항목의 편집 화면부터 확인하세요. 아래 경로는 설정 위치를 찾기 위한 안내이며, 실제로는 현재 버전에 표시되는 항목과 단위를 기준으로 설정하세요.
| 클라이언트 | 일반적인 설정 경로 | 저장 후 확인할 항목 |
|---|---|---|
| Clash Verge Rev | ‘구독’ → 해당 항목 메뉴 → ‘편집’ → 업데이트 간격 | 단위와 자동 업데이트 스위치를 확인하고 수동 업데이트를 한 번 실행하세요 |
| 구버전 Clash for Windows | ‘Profiles’ → 구독 항목 우클릭 → ‘Settings’ → ‘Update Interval’ | 대부분의 버전은 분 단위로 입력하지만 구버전 화면은 다를 수 있습니다 |
| 구버전 Clash for Android | ‘설정’ → 해당 설정의 편집 화면 → 자동 업데이트 | 자동 업데이트가 켜져 있는지 확인하고 백그라운드 실행 제한도 살펴보세요 |
0을 ‘즉시 업데이트’로 간주하지 마세요. 일부 클라이언트에서는 자동 새로고침을 끄는 값이며, 버전에 따라 별도 스위치로 제어하기도 합니다. 저장한 뒤 ‘마지막 업데이트’ 시간이 바뀌는지 확인하세요. 화면의 숫자만 바뀌었다고 예약 작업이 실행된 것은 아닙니다.
컴퓨터가 꺼져 있거나 클라이언트가 종료됐거나, 시스템이 모바일 앱을 중지하면 일반적으로 예약된 새로고침이 실행되지 않습니다. 기기가 절전 모드에서 깨어난 뒤 놓친 작업을 실행할지도 클라이언트 구현에 따라 다릅니다. Android에서 업데이트가 계속 누락되면 시스템의 ‘설정’ → ‘앱’ → 해당 클라이언트 → 배터리 또는 백그라운드 관리에서 제한을 확인하세요. 제조사마다 메뉴 이름이 다르므로 구독 업데이트를 위해 모든 절전 기능을 끌 필요는 없습니다.
provider의 interval과 구독 새로고침은 다릅니다
mihomo에서 HTTP 노드 provider를 사용할 때는 proxy-providers 아래의 각 provider에 초 단위 interval을 지정할 수 있습니다. 아래는 기존 HTTP provider 항목 내부에 추가하는 필드 예시이며 전체 설정이 아닙니다. 기존의 type, url, path 등의 설정은 그대로 유지하세요.
interval: 3600
proxy: DIRECT
이 설정은 해당 provider를 3600초, 즉 1시간마다 업데이트하도록 하고 직접 연결로 다운로드하도록 지정합니다. proxy 필드를 현재 커널에서 지원하는지 확인하세요. 해당 필드를 지원하는 mihomo에서는 이미 존재하고 사용할 수 있는 아웃바운드나 정책 그룹 이름을 입력할 수도 있습니다. 이 필드를 지원하지 않는 구버전 커널에 그대로 복사하지 마세요.
- 클라이언트의 전체 구독 새로고침: 클라이언트가 예약하며 원격 설정 전체를 교체할 수 있습니다.
- provider의 노드 새로고침: 커널이 예약하며 해당 provider의 노드 정보만 업데이트합니다.
health-check.interval: 상태 검사 주기를 설정하며 노드 목록 다운로드 주기를 설정하는 항목이 아닙니다.
원격 설정 파일을 직접 수정하면 다음 클라이언트 새로고침 때 변경 사항이 덮어써질 수 있습니다. 변경 사항을 계속 유지하려면 클라이언트에서 제공하는 오버라이드, 병합 또는 로컬 설정 기능을 사용하고 업데이트 후 실제 적용된 설정을 확인하세요. 병합 방식은 클라이언트에 따라 다르므로 편집기의 원본 파일만 보고 판단하면 안 됩니다.
프록시를 통해 구독을 업데이트하는 순서
구독 도메인에 직접 연결할 수 없다면 프록시를 통한 다운로드를 시도할 수 있습니다. 단, 먼저 정상 작동하는 프록시 경로가 있어야 합니다. 전체 구독은 보통 클라이언트 자체의 네트워크 요청으로 다운로드되지만, provider는 커널이 다운로드할 수 있습니다. 시스템 프록시, TUN 모드, 구독 항목의 프록시 옵션은 서로 다른 설정입니다. 하나를 켠다고 나머지 두 경로의 요청까지 프록시를 통과하는 것은 아닙니다.
- 기존 설정으로 커널을 시작하고, 작동 여부를 확인한 노드를 선택하세요.
- 구독 항목의 편집 또는 업데이트 메뉴에서 ‘프록시 사용’ 또는 유사한 옵션을 찾아보세요. 현재 버전에서 해당 옵션을 제공하는 경우에만 켜세요.
- 클라이언트에서 프록시 주소를 입력하라고 하면 실제로 수신 중인 HTTP 또는 혼합 포트를 사용하세요. 예:
http://127.0.0.1:7890. 제어 인터페이스 포트를 입력하지 마세요. - 다시 업데이트한 뒤 오류가 연결 시간 초과에서 명확한 HTTP 응답으로 바뀌었는지 확인하세요. 업데이트 시각과 새 설정 내용도 함께 살펴보세요.
클라이언트에 별도의 구독 프록시 옵션이 없다면 해당 버전의 시스템 프록시 또는 TUN 지원을 확인하세요. 요청이 반드시 프록시를 통과한다고 가정해서는 안 됩니다. TUN이 이런 요청까지 처리하는지는 라우팅, 프로세스 제외 설정, DNS 설정에도 영향을 받습니다. HTTP 프록시 포트는 외부 제어 인터페이스가 아닙니다. 흔히 쓰는 제어 포트 9090은 커널 관리용이므로 구독 다운로드 프록시로 사용할 수 없습니다.
복구 후 다음 다섯 항목을 확인하세요
마지막으로 ‘업데이트 성공’ 안내만 확인하고 끝내지 마세요. 설정 다운로드, 커널 적용, 노드 사용 가능 여부는 각각 다른 결과이므로 모두 확인해야 문제 해결이 끝납니다.
- 시간: 구독의 마지막 업데이트 시간이 이전 기록이 아니라 이번 작업 시각으로 바뀌었는지 확인하세요.
- 내용: 필요한 정책 그룹과 노드가 실제로 있는지, 현재 선택된 설정이 올바른지 확인하세요.
- 로그: 이후에 YAML 파싱 실패, 정책 그룹 참조 오류, 미지원 프로토콜 안내가 없는지 확인하세요.
- 접속: 실제로 프록시가 필요한 대상에 연결해 현재 출구를 통해 연결이 정상적으로 이루어지는지 확인하세요.
- 예약 실행: 클라이언트를 켜 둔 상태에서 다음 예약 시각이 지난 뒤 자동으로 새로고침되는지 확인하세요. 실패하면 당시의 네트워크와 절전 상태를 기록하세요.
계속 실패한다면 클라이언트 및 커널 버전, 운영체제 버전, 오류 발생 시각, 개인정보를 가린 오류 로그, ‘직접 연결 실패·프록시 연결 성공’과 같은 비교 결과를 유지보수 담당자에게 전달하세요. 구독 토큰과 노드 비밀번호는 공개할 필요가 없습니다. 실패한 단계를 구체적으로 설명하면 설정을 반복해서 삭제하거나 프로그램을 다시 설치하는 것보다 원인을 빠르게 찾을 수 있습니다.