Clash 구독 업데이트 오류 해결 및 자동 업데이트 주기 설정

먼저 어느 단계에서 실패하는지 확인하기

Clash 구독 업데이트는 단순히 파일을 한 번 내려받는 작업이 아닙니다. 클라이언트가 구독 주소에 요청을 보내고, 응답을 파싱한 다음, 설정이나 노드 목록을 저장해 커널에 전달합니다. 어느 단계에서든 오류가 나면 화면에는 그저 ‘업데이트 실패’라고 표시될 수 있습니다. 계속 업데이트 버튼을 누르기보다 오류 메시지 원문, 업데이트 시각, 현재 설정 이름을 먼저 기록하세요.

구독은 두 종류로 나눠 살펴봐야 합니다. 그래픽 클라이언트가 관리하는 원격 전체 설정과 mihomo 설정의 proxy-providers가 관리하는 노드 제공자입니다. 전자의 업데이트 주기는 보통 클라이언트가 저장하고, 후자는 제공자 내부의 interval 필드를 사용합니다. 서로 다른 타이머이므로 한쪽을 변경해도 다른 쪽에는 적용되지 않습니다.

오류 또는 증상	우선 확인할 항목	다음 단계
`401`、`403`	토큰, 계정 권한, 서버 접근 정책	서비스 제공업체 계정 페이지에서 링크 상태 확인
`404`、`410`	오래된 주소, 폐기된 주소 또는 복사가 누락된 주소	현재 구독 주소를 다시 복사
`429`	짧은 간격의 반복 요청, 여러 기기에서 동시 새로고침	재시도를 멈추고 서버가 안내하는 시간만큼 대기
`timeout`、`EOF`	네트워크 경로, TLS, 중간 네트워크 장비	직접 연결과 프록시 요청 비교
`yaml`、`unmarshal`	응답 형식과 필드 유형	응답이 실제로 목표 설정 형식인지 확인
업데이트는 성공했지만 불러오기에 실패	커널 지원 범위, 정책 그룹 참조	설정 검증 결과와 로드 로그 확인

링크 만료 및 서버 거부: 상태 코드부터 확인

주소를 다시 복사하고 매개변수를 직접 조합하지 않기

구독 서비스 계정 페이지에서 요금제, 사용량, 만료일을 확인한 뒤 Clash 또는 Clash Meta용 구독 주소를 다시 복사하세요. 구독 토큰을 재설정하면 기존 주소가 즉시 만료될 수 있습니다. 클라이언트에 예전 주소가 저장돼 있다면 자동 새로고침을 해도 계속 실패합니다. 주소를 복사할 때 앞뒤 공백과 줄바꿈이 없는지, 메신저가 & 뒤의 매개변수를 잘라내지 않았는지도 확인하세요.

403이라고 해서 반드시 요금제가 만료된 것은 아닙니다. 접근 정책, 요청 헤더 제한 또는 보안 확인 페이지가 원인일 수 있습니다. 반대로 200도 구독이 정상이라는 보장은 없습니다. 로그인 페이지, 인증 페이지, 오류 안내 페이지도 성공 상태 코드를 반환할 수 있습니다. 브라우저에서 주소가 열리는지만 보지 말고 응답 본문까지 확인해야 합니다.

curl로 HTTP 오류와 연결 오류 구분하기

아래 명령은 Bash에서 실행하며 curl이 설치되어 있어야 합니다. 주소는 숨김 입력으로 받아 셸 기록에 직접 남지 않도록 합니다. 출력 파일은 로컬에서만 확인하세요. 노드 인증 정보가 들어 있을 수 있으므로 작업 후 삭제해야 합니다. 여기서 20초는 이번 진단에만 적용되는 최대 대기 시간이며 클라이언트 기본값이 아닙니다.

umask 077
read -r -s -p '구독 주소: ' SUB_URL
printf '\n'
curl --noproxy '*' --location \
  --connect-timeout 10 --max-time 20 \
  --output subscription-response.txt \
  --write-out 'HTTP=%{http_code}\nTYPE=%{content_type}\n' \
  "$SUB_URL"

HTTP=000은 서버 상태 코드가 아닙니다. 일반적으로 유효한 HTTP 응답을 받지 못했다는 뜻이므로 curl 오류 메시지와 함께 DNS, 연결 또는 인증서 문제를 확인해야 합니다. 숨김 입력을 사용해도 비밀이 완전히 격리되는 것은 아닙니다. 실행 중에는 URL이 로컬 프로세스 인자에 표시될 수 있으므로 신뢰할 수 없는 공용 호스트에서는 실행하지 마세요.

301 또는 302가 반환되면 최종 이동 주소가 로그인 페이지가 아닌지 확인하세요. 위 명령의 --location 옵션은 리디렉션을 따라갑니다.
429가 반환되면 Retry-After를 우선 따르세요. 분마다 업데이트를 시도해도 해결되지 않습니다.
인증서 오류가 발생하면 시스템 시간과 인증서 체인을 확인하세요. TLS 인증 검사를 건너뛰는 방법을 상시 해결책으로 사용하지 마세요.

네트워크 차단 및 프록시를 거치지 않는 업데이트

브라우저에서 구독 주소에 접속된다고 해서 클라이언트의 업데이트 기능도 접속할 수 있는 것은 아닙니다. 브라우저는 시스템 프록시를 사용하는 반면 업데이트 기능은 직접 연결할 수 있습니다. 반대로 TUN이나 투명 게이트웨이가 활성화돼 있으면 ‘직접 연결’로 표시된 요청도 네트워크 계층에서 가로채질 수 있습니다. 따라서 아래 비교로 확인할 수 있는 것은 curl이 HTTP 프록시를 명시적으로 사용하는지 여부뿐입니다. 명령 이름만으로 하위 네트워크 트래픽이 TUN을 완전히 우회한다고 단정할 수는 없습니다.

로컬 프록시 포트 비교 테스트

먼저 클라이언트에서 HTTP 또는 mixed 수신 포트를 확인하세요. 아래 예시는 127.0.0.1:7890을 사용하며, 이 포트가 실제로 로컬에서 수신 중일 때만 유효합니다. 설정에 mixed-port: 7897이 있다면 명령의 포트도 7897로 바꾸세요.

curl --noproxy '' --proxy http://127.0.0.1:7890 \
  --location --connect-timeout 10 --max-time 20 \
  --output subscription-via-proxy.txt \
  --write-out 'HTTP=%{http_code}\nTYPE=%{content_type}\n' \
  "$SUB_URL"

unset SUB_URL

프록시를 명시한 요청은 성공하고 앞선 요청은 실패했다면 네트워크 경로를 우선 점검할 필요가 있습니다. 다만 이것만으로 그래픽 클라이언트도 같은 경로를 사용한다고 볼 수는 없습니다. 클라이언트에서 구독 업데이트 관련 로그를 켜고 한 번 수동으로 새로고침해 해당 요청이 기록되는지 확인하세요. 이어서 요청에 사용된 프록시, 정책 그룹, 오류 정보를 살펴보세요. 일부 클라이언트는 커널과 별도의 다운로드 기능을 사용하므로 연결 패널에 기록이 없다고 요청을 보내지 않았다고 단정해서는 안 됩니다.

구독 업데이트의 순환 의존성 피하기

구독에 포함된 노드만 구독 도메인에 접속할 수 있는데 그 노드가 모두 만료된 상황이라면, ‘업데이트 시 프록시 사용’을 켜도 연결을 복구할 수 없습니다. 사용 가능한 대체 경로나 서비스 제공업체가 제공하는 접속 가능한 주소가 필요합니다.
로그에 구독 도메인의 연결 방식이 DIRECT로 표시되고 직접 연결이 실패하는 것을 확인했다면, 네트워크 요구 사항을 분명히 한 뒤 규칙을 조정하고 실제로 어떤 규칙이 적용되는지 확인하세요.
도메인 이름을 확인할 수 없다는 오류가 발생하면 먼저 구독 호스트 이름과 DNS 로그를 확인하세요. DNS, TUN, 규칙, 포트를 한꺼번에 변경하면 어떤 변경이 효과가 있었는지 파악하기 어렵습니다.
특정 Wi-Fi에서만 실패한다면 모바일 네트워크로 한 번 비교해 보세요. 네트워크 환경 차이를 찾는 데 도움이 되며, 클라이언트를 먼저 다시 설치할 필요는 없습니다.

형식 호환성 문제: 다운로드 후에도 검증 필요

구독 API는 전체 YAML, 노드만 포함한 YAML, 인코딩된 공유 링크 목록 또는 다른 클라이언트 전용 형식으로 응답할 수 있습니다. 그래픽 클라이언트가 자동 변환을 지원하는지는 구현에 따라 다릅니다. mihomo의 HTTP 노드 제공자와 전체 설정 로더도 입력 형식이 서로 다르므로 같은 응답을 구분 없이 아무 곳에나 넣을 수는 없습니다.

응답 내용을 보고 구조 확인하기

응답 파일을 로컬 텍스트 편집기에서 여세요. 파일이 <!doctype html>로 시작하거나 로그인 화면 문구가 보인다면 YAML 들여쓰기 문제가 아니라 다운로드 또는 인증 단계의 문제입니다.
전체 설정에는 보통 proxies, proxy-groups, rules 등의 필드가 포함됩니다. 네이티브 YAML 노드 제공자는 일반적으로 노드 목록을 proxies:로 표현합니다. 구체적인 필드 구성은 사용 목적에 맞춰 확인하세요.
proxy-groups와 rules에서 참조하는 이름이 실제로 존재하는지 확인하세요. 노드 다운로드에 성공했더라도 정책 그룹의 참조가 빠져 있으면 설정이 제대로 작동하지 않을 수 있습니다.
서비스 제공업체가 Clash용과 Clash Meta용 출력을 모두 제공한다면 현재 커널에 맞는 것을 선택하세요. 구형 Clash 커널은 mihomo의 최신 필드나 프로토콜을 지원하지 않을 수 있습니다.

로컬에 mihomo가 설치되어 있다면 전체 설정의 복사본으로 구문과 설정을 검사할 수 있습니다. 아래 예시는 파일을 현재 디렉터리의 config.yaml로 저장했다고 가정합니다. 노드 제공자 파일은 전체 설정으로 검사할 수 없습니다. 설정이 외부 파일을 참조한다면 작업 디렉터리와 의존 경로도 올바른지 확인하세요.

mihomo -v
mihomo -t -d . -f ./config.yaml

-v는 실제 커널 버전을 확인해 필드 지원 여부를 점검할 때 사용합니다. -t 검사를 통과해도 모든 노드에 연결할 수 있다는 뜻은 아닙니다. 오류 원문과 커널 버전을 저장한 뒤 문제를 좁혀 가세요. 인식하지 못하는 필드를 전부 삭제해 억지로 불러오려 하지 마세요. 형식을 변환해야 한다면 신뢰할 수 있고 통제된 방법을 사용하고, 출처가 불분명한 변환 사이트에 전체 구독 토큰을 보내지 마세요.

클라이언트 자동 업데이트 주기 설정 위치

자동 업데이트는 클라이언트 인터페이스에서 제공하는 기능이며 버전에 따라 이름과 위치가 달라질 수 있습니다. 먼저 ‘정보’ 페이지에서 클라이언트 버전을 확인한 다음 대상 구독의 편집 화면을 여세요. ‘노드 지연 시간 테스트 주기’를 구독 다운로드 주기와 혼동하지 마세요. ‘모든 구독 업데이트’도 예약 작업을 활성화하는 기능이 아닙니다.

클라이언트	설정 메뉴 경로	확인할 항목
Clash Verge Rev	‘구독’ → 대상 구독 카드 메뉴 또는 마우스 오른쪽 버튼 클릭 → ‘편집’	업데이트 주기, 해당 버전에서 제공하는 프록시 업데이트 옵션
Clash for Windows 구버전	‘Profiles’ → 대상 원격 설정을 마우스 오른쪽 버튼으로 클릭 → ‘Settings’	업데이트 주기, 프록시 다운로드 옵션 및 화면에 표시된 단위
Clash for Android 구버전	‘설정’ → 대상 원격 설정의 편집 버튼	자동 업데이트와 주기, 전역 설정의 네트워크 관련 옵션
mihomo 명령줄	설정 파일의 `proxy-providers`	`interval` 및 `proxy`

Clash Verge Rev에서는 구독 편집 화면에서 ‘업데이트 주기’, ‘프록시 사용’과 같은 항목을 먼저 찾아보세요. 해당 버전에서 업데이트 방식이 카드 메뉴에 있다면 메뉴에서 프록시 업데이트 작업을 실행하면 됩니다. 한 번 수동으로 프록시 업데이트에 성공했다고 해서 이후 예약 업데이트에도 같은 방식이 적용된다고 단정할 수 없습니다. 설정을 다시 열어 변경 사항이 저장됐는지 확인하세요.

Clash for Windows와 Clash for Android는 지원이 중단된 구형 클라이언트입니다. 남아 있는 버전에 따라 화면 구성이 다를 수 있습니다. 현재 화면에 프록시 업데이트 옵션이 없다면 다른 클라이언트의 메뉴 경로를 그대로 따라 하지 마세요. 로그에서 업데이트 요청의 실제 경로를 확인하거나 현재 설정을 지원하는 유지 관리 중인 클라이언트로 옮기세요.

화면에 표시된 단위에 맞춰 주기 입력

우선 6시간 또는 12시간으로 설정한 뒤 서비스 제공업체의 제한에 맞게 조정하세요. 화면에 ‘분’으로 표시되면 6시간은 360, 12시간은 720을 입력합니다. ‘시간’으로 표시되면 각각 6, 12를 입력하세요. 입력란에 보이는 숫자만 보고 단위를 짐작하지 마세요. 저장한 뒤 한 번 수동으로 업데이트하고 ‘마지막 업데이트’ 시각이 바뀌었는지 확인하세요.

모바일에서는 백그라운드 실행, 배터리 최적화, 시스템 절전의 영향도 받습니다. 예약 업데이트가 화면 잠금 후 정확히 정해진 시각에 실행된다고 보장할 수는 없습니다. 데스크톱 클라이언트도 완전히 종료하면 보통 자체 예약 작업을 계속 실행하지 않습니다. 앱을 다시 열어야만 업데이트된다면 주기를 더 짧게 설정하기보다 먼저 앱의 실행 상태와 수명 주기를 확인하세요.

mihomo의 interval 및 프록시 업데이트 필드

HTTP 유형 proxy-providers의 interval 단위는 초입니다. 예를 들어 21600은 6시간, 43200은 12시간, 86400은 24시간입니다. 이는 노드 제공자의 다운로드 주기이며 원격 전체 설정의 자동 새로고침 설정이 아닙니다.

해당 필드를 지원하는 mihomo 버전에서는 제공자의 proxy로 다운로드에 사용할 아웃바운드 프록시 또는 정책 그룹을 지정할 수 있습니다. 아래는 기존 HTTP 제공자에 합쳐 넣을 필드 예시일 뿐 전체 설정이 아닙니다. 기존 url, path와 제공자 이름은 그대로 유지하세요. PROXY는 설정에 이미 존재하고 현재 사용할 수 있는 아웃바운드 이름이어야 합니다.

interval: 21600
proxy: PROXY
health-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600

여기서 health-check.interval: 600은 600초마다 상태를 확인한다는 뜻이지, 10분마다 구독을 다운로드한다는 뜻이 아닙니다. 상태 확인 URL은 네트워크 접근성과 사용 목적에 맞춰 선택하세요. 예시 주소는 연결 확인 대상이며 구독 주소가 아닙니다.

명령줄에서 mihomo를 실행할 때 설정 최상위에 interval을 추가해도 전체 설정이 주기적으로 다시 다운로드되지는 않습니다. 전체 설정을 새로 받아야 한다면 다운로드, 검증, 백업, 재로드를 관리하는 별도의 작업을 사용하고 실패 시 기존 파일을 보존하세요. 네트워크 응답으로 현재 사용 중인 설정 파일을 바로 덮어쓰지 마세요.

업데이트 후에도 바뀐 점이 없을 때 확인할 6가지

업데이트 대상 확인. 다른 구독을 업데이트한 뒤 실제로는 별도 설정을 계속 사용하고 있지 않은지, 카드 이름과 구독 주소의 출처를 확인하세요.
시각과 내용 확인. 업데이트 시각이 바뀌었다는 것은 클라이언트가 업데이트 작업을 기록했다는 뜻일 뿐입니다. 서버가 이전과 같은 내용을 반환했을 수도 있습니다. 노드 수가 그대로라는 사실만으로 실패를 단정할 수는 없습니다.
새 설정이 로드됐는지 확인. 일부 클라이언트는 ‘다운로드’와 ‘활성화’를 별도로 처리합니다. 설정이 선택되어 있는지 확인하거나 재로드 로그를 살펴보세요.
노드 목록 출처 확인. 정책 그룹이 로컬에 고정된 노드만 참조한다면 원격 제공자를 업데이트해도 새 노드가 그룹에 표시되지 않을 수 있습니다. use와 제공자 이름을 확인하세요.
필터 조건 확인. 지역 필터, 정규식 필터 또는 제외 규칙이 새 노드를 숨길 수 있습니다. 먼저 제공자가 반환한 원래 노드 수를 확인하세요.
예약 작업이 계속 실행되는지 확인. 클라이언트를 재시작한 뒤 업데이트 주기가 유지됐는지 확인하고, 다음 실행 후 기록된 시각을 살펴보세요.

진단에 사용한 응답 파일은 마지막에 삭제해 동기화 폴더나 공유 폴더에 남지 않도록 하세요. 유지 관리 담당자에게 문의해야 한다면 클라이언트 버전, 커널 버전, 오류 발생 시각, HTTP 상태 코드, 민감 정보를 가린 오류 원문을 전달하면 됩니다. 구독 토큰, 노드 비밀번호, 전체 응답은 공개 첨부 파일로 보내지 마세요.

rm -f subscription-response.txt subscription-via-proxy.txt

권장 점검 순서는 링크 유효성 확인 → 요청 경로 비교 → 응답 형식 점검 → 설정 로드 확인 → 적절한 업데이트 주기 설정입니다. 자동 새로고침은 수동 작업을 줄여줄 뿐, 만료된 토큰이나 잘못된 형식, 접속할 수 없는 다운로드 경로를 해결해 주지는 않습니다.