먼저 다운로드, 파싱, 적용 중 어느 단계에서 실패하는지 확인하세요
Clash 모바일에서 ‘업데이트 실패’는 하나의 고정된 오류가 아닙니다. 구독 업데이트는 보통 요청 주소 확인, 응답 다운로드, 설정 파싱, 파일 저장, 설정 적용 단계를 거칩니다. 노드에 연결할 수 있어도 구독 주소가 유효하다는 뜻은 아니며, 구독을 다운로드했더라도 현재 커널에서 새 설정을 불러올 수 있다는 보장은 없습니다. 먼저 실패한 단계를 파악해야 링크를 바꿀지, 네트워크를 조정할지, 설정 호환성을 해결할지 판단할 수 있습니다.
- 현재 사용 중인 설정을 보존하세요. 설정 이름, 마지막 업데이트 시각, 클라이언트 이름을 기록하세요. 클라이언트에서 내보내기를 지원한다면 먼저 기기에 사본을 저장하세요. 사본에 노드 비밀번호가 포함될 수 있으므로 안전한 위치에 보관해야 합니다.
- 한 번 수동으로 업데이트하세요. 구독 또는 설정 목록에서 해당 항목을 찾아 ‘업데이트’를 실행하고 오류 메시지 전체를 기록하세요. 모든 구독을 연달아 반복해서 새로 고치지는 마세요.
- 같은 시각의 로그를 확인하세요. 실패 시각을 분 단위까지 기록하고 HTTP 상태 코드, 연결 시간 초과, TLS 인증서 오류, YAML 파싱 오류를 구분하세요.
- 한 번에 조건 하나만 바꾸세요. 예를 들어 Wi-Fi와 모바일 네트워크만 전환하거나 업데이트 요청의 프록시 사용 여부만 바꾼 뒤 결과를 비교하세요.
| 메시지 또는 증상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
401 / 403 | 토큰, 계정 상태, 접근 제한 | 구독 서비스 관리 페이지에서 주소와 권한 확인 |
404 / 410 | 주소가 이전되거나 비활성화되었는지 확인 | 관리 페이지에서 구독 주소를 다시 복사 |
429 | 짧은 시간 동안 요청이 너무 많음 | 연속 새로 고침을 중단하고 서버가 안내하는 대기 시간 준수 |
5xx | 서버 또는 상위 시스템 오류 | 기존 설정을 보존하고 잠시 후 재시도 |
timeout / lookup | 연결 경로 또는 도메인 확인 | 네트워크를 바꾸고 요청이 프록시를 사용하는지 확인 |
yaml / unmarshal | 응답 내용과 설정 형식 | 웹페이지나 다른 클라이언트용 형식이 다운로드되지 않았는지 확인 |
상태 코드는 단서일 뿐 최종 결론은 아닙니다. 예를 들어 403은 웹사이트의 보안 정책 때문에 발생할 수도 있으며, 구독이 만료되었다는 뜻은 아닙니다. 구독 서비스 관리 페이지, 클라이언트 로그, 서비스 공지를 함께 확인하세요.
구독 링크가 유효하지 않을 때: 토큰, 만료일, 응답 내용 확인
서비스 관리 페이지에서 다시 복사하고, 채팅 기록을 이어 붙이지 마세요
구독 URL에는 계정별 토큰이 포함되는 경우가 많습니다. 구독 주소를 재설정하거나 보안 설정을 변경하거나 서비스가 이전되면 기존 주소가 더 이상 유효하지 않을 수 있습니다. 복사할 때 쿼리 매개변수를 빠짐없이 포함하고, 끝에 공백이나 줄바꿈이 붙지 않았는지, 한글 문장 부호가 들어가지 않았는지, 채팅 앱에서 잘린 주소를 복사하지 않았는지 확인하세요. 링크의 &는 매개변수를 구분하는 문자입니다. 주소 입력란에 HTML 엔티티 문자열로 잘못 입력하지 마세요.
먼저 서비스 관리 페이지에서 요금제 유효 기간, 남은 데이터, 구독 상태를 확인한 뒤 현재 제공되는 주소로 기존 항목을 업데이트하세요. 클라이언트에서 주소를 편집할 수 없다면 새 구독 항목을 만들어 테스트하세요. 성공한 뒤 기존 항목을 정리하면 사용할 수 있는 설정을 먼저 삭제하는 일을 피할 수 있습니다.
HTTP 200 응답에도 오류 내용이 담길 수 있습니다
서버가 200을 반환했다는 것은 요청에 응답했다는 뜻일 뿐입니다. 실제 응답은 로그인 페이지, 인증 페이지, 요금제 만료 안내 또는 한 줄짜리 오류 메시지일 수 있습니다. 파싱 오류 근처에 <html>이나 <!DOCTYPE이 보인다면 YAML 들여쓰기를 조정하기보다 먼저 주소와 접근 제한을 확인하세요.
형식 호환성: 전체 설정과 노드 구독 구분하기
‘구독 지원’이 모든 클라이언트에서 같은 응답 형식을 읽을 수 있다는 뜻은 아닙니다. 흔히 전체 Clash YAML, 노드 제공자 파일, URI 목록, Base64로 인코딩된 노드 목록을 사용합니다. 전체 설정에는 보통 proxies, proxy-groups, rules 등의 필드가 포함됩니다. 반면 노드 제공자 파일은 주로 노드만 제공하며, 정책 그룹이나 분기 규칙은 포함하지 않을 수 있습니다.
- 전체 설정으로 가져오기: 서비스 관리 페이지에서 Clash 또는 현재 커널에 맞는 형식이라고 명시한 항목을 선택하세요. 다른 클라이언트 전용 구독 주소를 전체 설정으로 바로 가져오지 마세요.
- 노드 제공자 불러오기:
proxy-providers는 제공자 콘텐츠를 다운로드하며 전체 설정과 구조가 다릅니다. 두 형식을 잘못된 메뉴에 넣으면 필드 누락이나 파싱 오류가 발생할 수 있습니다. - Meta / mihomo 기능: 일부 프로토콜, 규칙 필드, DNS 옵션은 해당 기능을 지원하는 커널이 필요합니다. Clash 원본, Clash Meta / mihomo, 각 그래픽 클라이언트의 지원 범위는 서로 완전히 같지 않습니다.
문제를 확인할 때는 클라이언트의 ‘정보’ 또는 커널 정보 화면에서 실제 사용 중인 커널을 확인한 뒤 설정 제공자의 안내와 비교하세요. 앱 이름에 Clash가 들어간다는 사실만으로 새 필드 지원 여부를 알 수는 없습니다. 로그에 알 수 없는 프로토콜이나 지원하지 않는 필드가 명시되어 있다면 제공자에게 호환 형식을 요청하거나 해당 기능을 지원하는 클라이언트를 사용하세요. 설정을 한 줄씩 지우며 시험하지 마세요.
오류 행 번호는 위치를 찾기 위한 단서일 뿐 원인을 가리키지 않을 수 있습니다
YAML은 들여쓰기에 민감하므로 공백 대신 Tab을 임의로 사용하면 안 됩니다. 오류는 로그에 표시된 행에서 발생할 수도 있고, 앞 행의 닫히지 않은 따옴표나 괄호에서 비롯될 수도 있습니다. 원격 구독이라면 먼저 제공자에게 원본 내용을 확인하세요. 휴대폰에서 다운로드된 파일을 직접 편집하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 로컬 설정을 추가하려면 클라이언트에서 지원하는 오버라이드 또는 병합 메뉴를 사용하세요. 관련 개념은 기술 참고 자료를 확인하세요.
업데이트 요청이 프록시를 사용하지 않을 때: 노드 연결과 구독 접근은 별개입니다
모바일 클라이언트는 앱 자체에서 전체 구독을 다운로드할 수도 있고, 커널에서 원격 제공자를 다운로드할 수도 있습니다. 두 요청의 네트워크 경로는 다를 수 있습니다. 브라우저에서 서비스 관리 페이지가 열린다는 것은 브라우저의 현재 접속 경로가 작동한다는 뜻일 뿐, 클라이언트의 구독 요청도 같은 경로를 이용한다는 뜻은 아닙니다.
두 네트워크 경로를 비교해 보세요
- 기존 설정을 유지하고 현재 선택한 노드가 실제로 인터넷에 접속되는지 확인하세요. VPN 아이콘이 켜져 있는지만 확인해서는 안 됩니다.
- 구독 편집 화면이나 업데이트 설정에서 ‘프록시를 통해 업데이트’, ‘업데이트 프록시’와 같은 옵션을 찾으세요. 실제 메뉴 이름은 클라이언트마다 다르므로 특정 앱의 메뉴 경로를 모든 모바일 클라이언트에 그대로 적용하지 마세요.
- 해당 옵션이 있다면 직접 연결과 프록시 연결로 각각 한 번씩 수동 업데이트하고 결과를 기록하세요. 프록시 연결에서만 성공했다면 해당 구독의 업데이트 방식을 프록시로 설정하세요.
- 두 방식 모두 실패하면 Wi-Fi와 모바일 네트워크를 전환해 다시 확인하세요. DNS, 노드, 구독 형식을 동시에 바꾸면 어떤 변경이 효과가 있었는지 알기 어렵습니다.
전역 모드로 전환해도 구독 다운로드 경로가 바뀌지 않을 수 있습니다. 다운로드가 커널을 거치지 않고 앱에서 직접 실행될 수 있기 때문입니다. 반대로 해당 필드를 지원하는 mihomo에서는 설정의 proxy-providers에 다운로드용 proxy를 지정할 수 있습니다. 이 설정은 해당 제공자에만 적용되며 클라이언트 전체 구독의 업데이트 방식을 자동으로 바꾸지는 않습니다.
휴대폰의 VPN 권한, TUN 연결, 앱 제외 목록도 요청 경로에 영향을 줄 수 있습니다. 특히 클라이언트 자체를 제외했거나 앱별 프록시를 사용하는 경우, 다른 앱에서 인터넷이 된다는 이유만으로 네트워크 문제를 배제해서는 안 됩니다. 로그에 no such host가 있으면 먼저 도메인 확인을 점검하세요. 연결 시간이 초과되었다면 회선, 프록시 출구, 서버 접근성을 확인하세요.
인증서 검증 오류: 시스템 시간을 맞춘 뒤 네트워크 환경 확인
x509: certificate has expired or is not yet valid, 호스트 이름 불일치, 신뢰할 수 없는 인증서 체인은 모두 TLS 검증 오류입니다. YAML 파싱과는 다른 단계의 문제이므로 노드 비밀번호를 바꿔도 해결되지 않습니다.
- 시스템 자동 시간 설정을 켜세요. Android에서는 보통 시스템 설정의 ‘날짜 및 시간’에서 자동 설정을 켭니다. iOS에서는 ‘설정’ → ‘일반’ → ‘날짜 및 시간’에서 ‘자동 설정’을 확인하세요. 날짜가 맞지 않으면 유효한 인증서도 만료되었거나 아직 유효하지 않은 것으로 판단될 수 있습니다.
- 공용 Wi-Fi 로그인을 확인하세요. 호텔이나 학교 네트워크는 웹페이지 인증을 먼저 요구할 수 있습니다. 해당 네트워크에 정상적으로 로그인한 다음 구독 요청을 다시 실행하세요.
- 네트워크를 바꿔 다시 확인하세요. 특정 Wi-Fi에서만 실패한다면 해당 네트워크가 HTTPS 검사나 도메인 리디렉션을 사용하는지 확인하세요. 출처가 불분명한 루트 인증서는 함부로 설치하지 마세요.
- 서비스 제공자에게 도메인 인증서를 확인해 달라고 요청하세요. 여러 네트워크에서 만료 또는 호스트 이름 오류가 동일하게 발생하면 서비스 제공자가 인증서 설정을 수정하거나 올바르게 구성된 구독 주소를 제공해야 합니다.
설정의 노드 옵션 skip-cert-verify는 보통 노드 연결의 인증서 검증에 적용되며 구독 다운로드의 TLS 설정과는 다릅니다. 구독 오류 메시지를 없애려고 노드 옵션을 일괄 변경하지 마세요. HTTP 평문 주소를 장기 대안으로 사용해서도 안 됩니다. 구독 응답 자체에 접근 인증 정보가 포함될 수 있습니다.
자동 업데이트 주기: 서로 다른 두 타이머를 구분하세요
클라이언트의 ‘구독 자동 업데이트’는 보통 원격 설정 전체를 업데이트합니다. 커널의 proxy-providers에 있는 interval은 특정 노드 제공자의 새로 고침 주기를 제어합니다. 두 기능을 함께 사용할 수 있지만 서로 대체할 수는 없습니다. 혼동하기 쉬운 또 다른 필드인 health-check.interval은 상태 확인 주기를 제어하며 노드 목록을 다시 다운로드하지 않습니다.
| 업데이트 대상 | 설정 위치 | 권장 시작값 |
|---|---|---|
| 원격 전체 설정 | 클라이언트의 구독 편집 또는 업데이트 설정 | 24시간, 서비스 제공자의 안내에 따라 조정 |
| HTTP 노드 제공자 | proxy-providers 아래의 해당 항목 | interval: 86400 |
| HTTP 규칙 제공자 | rule-providers 아래의 해당 항목 | 규칙 소스의 업데이트 주기에 맞춰 설정 |
| 노드 상태 확인 | health-check 관련 설정 | 별도로 설정하고 구독 업데이트 주기로 사용하지 않기 |
전체 설정: 하루 한 번부터 시작
노드가 자주 바뀌지 않는 구독이라면 24시간을 시작값으로 설정할 수 있습니다. 더 자주 변경해야 한다면 6~12시간을 고려하되 서비스 제공자의 요청 제한을 따르세요. 이는 설정 권장 사항이지 모든 서비스에 적용되는 공통 기준은 아닙니다. 서버가 429와 함께 Retry-After를 반환하면 해당 대기 시간을 우선 따르고 몇 초마다 새로 고침을 누르지 마세요.
설정 전에 입력 단위를 확인하세요. 24시간은 1440분이며 86400초입니다. 클라이언트 화면은 분이나 시간을 사용할 수 있지만 커널 제공자의 interval은 초 단위이므로 같은 숫자를 서로 다른 위치에 그대로 입력하면 안 됩니다. 0의 의미도 클라이언트 안내를 확인하세요. ‘즉시 업데이트’를 뜻한다고 임의로 판단하지 마세요.
제공자: 기존 항목의 업데이트 필드만 수정
mihomo의 HTTP 노드 제공자를 사용하고 하루에 한 번 업데이트하려면 기존 제공자 항목에 아래 한 줄을 설정하세요. 이는 필드 예시일 뿐 단독으로 가져올 수 있는 전체 설정이 아닙니다. 기존 이름, 주소, 경로 및 기타 필수 설정은 유지해야 합니다.
# 기존 proxy-providers 항목의 하위 항목, 단위는 초
interval: 86400수정한 뒤 설정을 불러올 수 있는지 먼저 확인하고 로그에 표시되는 제공자 업데이트 시각을 살펴보세요. 이 줄을 설정 최상위에 넣어 클라이언트 전체의 원격 구독을 제어하려고 하지 마세요. 로컬 파일 제공자를 사용하는 경우에도 HTTP 정기 다운로드 동작을 그대로 적용할 수 없습니다.
휴대폰 화면이 잠긴 뒤 업데이트되지 않을 때: 예약 제한과 성공 시각 확인
자동 업데이트 주기는 보통 클라이언트나 커널이 업데이트를 예약하는 간격을 뜻하며, 휴대폰이 정확한 시각에 작업을 실행한다는 보장은 없습니다. Android의 절전 정책과 제조사별 백그라운드 제한, 네트워크 연결 끊김, iOS의 백그라운드 작업 및 네트워크 확장 제한 때문에 업데이트가 지연될 수 있습니다. VPN 아이콘이 표시되어도 설정을 다운로드하는 앱의 화면 프로세스가 실행 중이라는 뜻은 아닙니다.
- Android: 시스템의 앱 배터리 설정에서 해당 클라이언트의 백그라운드 활동이 제한되어 있는지 확인하세요. ‘백그라운드 실행 허용’, ‘자동 실행’ 등의 옵션은 제조사마다 위치가 다르므로 기기의 실제 메뉴를 따르세요. 제한을 완화하면 배터리 사용량이 늘어날 수 있습니다.
- iOS: 사용하는 클라이언트가 제공하는 백그라운드 기능을 기준으로 확인하세요. 일반 앱의 예약 작업을 항상 실행되는 서비스처럼 생각해서는 안 됩니다. 필요하다면 클라이언트를 열어 업데이트 결과를 직접 확인하세요.
- 두 운영체제 모두 확인: 클라이언트에서 모바일 네트워크 업데이트를 허용하는지, 현재 네트워크에 데이터 사용 제한이 있는지, 화면에 표시된 시각이 ‘마지막 시도’인지 ‘마지막 성공’인지 확인하세요.
설정을 마친 뒤 앱을 열어 수동 업데이트를 한 번 실행하고 새 설정이 저장되어 정상적으로 불러와지는지 확인하세요. 그런 다음 자동 업데이트 설정이 켜져 있는지만 보는 대신 설정한 주기가 지난 뒤 성공 시각을 확인하세요. 휴대폰을 재시작한 후에도 설정이 선택된 상태인지, VPN 권한이 유효한지, 자동 업데이트 설정이 시스템에서 초기화되거나 삭제되지 않았는지 확인해야 합니다.
문의 전에 남겨야 할 최소한의 문제 기록
계속 실패한다면 앱을 반복해서 삭제하고 재설치하기보다 재현 가능한 기록을 정리하는 편이 효과적입니다. 앱 데이터를 지우면 구독, 오버라이드, 정책 그룹 선택도 함께 삭제될 수 있으므로 백업을 완료하고 다른 방법으로 해결되지 않았을 때 고려하세요.
- 클라이언트 이름, 앱 버전, 실제 커널 정보, 휴대폰 운영체제 버전을 기록하세요.
- 실패 시각, Wi-Fi와 모바일 네트워크 중 어느 쪽을 사용했는지, 요청이 직접 연결인지 프록시 연결인지 기록하세요.
- HTTP 상태 코드, TLS 오류, 설정 파싱 행 번호 등 민감 정보를 가린 오류 메시지 전체를 보관하세요.
- 수동 업데이트 성공 여부, 전체 설정과 제공자 중 실패한 대상, 기존 설정의 사용 가능 여부를 설명하세요.
- 주소 권한이나 응답 문제는 구독 서비스 제공자에게 문의하세요. 재현 가능한 다운로드, 파싱, 업데이트 예약 오류는 클라이언트 유지 관리 담당자에게 전달하세요.
마지막으로 세 가지를 모두 확인해야 합니다. 구독 다운로드 성공, 새 설정 불러오기 성공, 실제 연결 정상 여부입니다. 업데이트 시각만 바뀌고 설정을 적용할 수 없다면 문제가 해결된 것이 아닙니다. 모바일 클라이언트의 초기 설정과 권한 확인은 설치 및 사용 안내에서 이어서 확인하세요.