현재 설정을 보존하고 수동으로 한 번 업데이트하세요
Clash 구독 업데이트에 실패했다고 해서 현재 노드가 즉시 사용할 수 없게 되는 것은 아닙니다. 클라이언트는 대개 마지막으로 정상 다운로드한 설정을 계속 사용합니다. 기존 노드가 작동한다면 연결을 유지한 채 업데이트 경로를 점검하세요. 처음부터 구독을 삭제하거나 설정 폴더를 비우고 반복해서 재설치하지 마세요. 인터넷에 연결할 수 있는 기존 설정까지 사라질 수 있습니다.
- ‘프로필’ 또는 ‘Profiles’에서 현재 활성화된 구독 이름을 확인하고 마지막 업데이트 시간을 기록하세요.
- 클라이언트의 내보내기 또는 백업 기능으로 현재 설정을 저장하세요. 파일에 노드 비밀번호나 구독 토큰이 들어 있을 수 있으므로 신뢰할 수 있는 기기에만 보관해야 합니다.
- 대상 구독에서 ‘업데이트’를 한 번 실행한 뒤 ‘로그’를 열어 전체 오류 메시지, 발생 시간, HTTP 상태 코드를 기록하세요.
- 실패한 대상이 구독 전체인지, 설정 내부의
proxy-providers중 하나인지 확인하세요. 두 경우에 사용하는 다운로드 방식과 업데이트 주기가 다를 수 있습니다.
오류 메시지로 실패 지점을 찾으세요
먼저 다운로드 응답을 받았는지 확인하고, 그다음 응답을 정상적으로 파싱할 수 있는지 살펴보세요. 아래와 같은 메시지는 클라이언트에서 한국어로 변환되어 표시될 수 있으므로 로그의 실제 하위 오류를 기준으로 판단해야 합니다. 상태 코드 하나만 보고 계정 만료로 단정하지 말고 구독 서비스 관리 화면과 응답 내용도 함께 확인하세요.
| 로그 또는 증상 | 우선 확인할 항목 | 다음 조치 |
|---|---|---|
401 / 403 | 토큰, 접근 제한, 계정 상태 | 서비스 관리 화면에 로그인해 전용 구독 주소를 다시 복사하고, 클라이언트 유형을 지정해야 하는지 확인하세요. |
404 / 410 | 이전 API, 취소된 링크 | 서비스 제공자가 현재 안내하는 주소를 확인하세요. 추측으로 URL 경로를 바꾸지 마세요. |
429 | 요청이 너무 많음 | 연속으로 재시도하지 말고, 응답 헤더에 Retry-After가 있으면 안내된 시간만큼 기다리세요. |
500 / 502 / 503 | 서버 또는 게이트웨이 오류 | 기존 설정을 보존하고 잠시 후 다시 시도한 뒤 서비스 공지를 확인하세요. |
no such host | 구독 도메인 이름 확인 | 현재 DNS, 도메인 철자, 사용 중인 네트워크를 확인하세요. |
timeout / deadline exceeded | 라우팅, 프록시 출구, 응답 속도 | 직접 연결과 작동 중인 프록시를 이용한 업데이트 경로를 각각 테스트하세요. |
x509 또는 TLS 오류 | 시스템 시간, 인증서 체인, 네트워크 차단 | 시스템 시간을 동기화하고 인증 포털 및 HTTPS 검사 소프트웨어를 점검하세요. |
| YAML 파싱 오류 | 응답 형식과 설정 호환성 | 다운로드한 내용이 HTML, 노드 목록 또는 호환되지 않는 설정인지 확인하세요. |
HTTP 200은 서버가 콘텐츠를 반환했다는 뜻일 뿐, 사용할 수 있는 Clash 설정이라는 의미는 아닙니다. 인증 포털이 로그인 페이지를 반환하거나 API가 JSON에 오류 메시지를 담아 보내는 경우도 있습니다. 이때 클라이언트는 이후 YAML 오류나 필드 유형 오류를 표시할 수 있습니다.
링크 만료 및 토큰 무효화 해결
전체 URL을 다시 복사하고 매개변수를 직접 조합하지 마세요
구독 서비스 관리 화면에서 ‘Clash’ 또는 ‘Clash Meta / mihomo’에 해당하는 구독 주소를 복사한 뒤 기존 설정의 원격 주소를 교체하세요. 계정 만료, 구독 토큰 초기화, 구독 도메인 이전으로 기존 주소가 작동하지 않을 수 있습니다. QR 코드는 URL을 전달하는 또 다른 방법일 뿐이며, 스캔해 가져와도 토큰 검증을 우회할 수는 없습니다.
- 링크 앞뒤에 공백, 줄바꿈, 한글 문장 부호가 섞이지 않았는지 확인하세요. 메신저에서 복사한
&가 원래 매개변수를 손상시킬 수도 있습니다. - 웹 관리 페이지 주소를 구독 주소로 사용하지 마세요. 브라우저에서 로그인할 수 있는 페이지라도 클라이언트가 설정 파일로 다운로드할 수 있는 것은 아닙니다.
- 새 링크와 기존 링크의 토큰이 다르면 먼저 한 기기에서 확인한 뒤 다른 기기에 적용하세요. 토큰을 자주 초기화하면 기존 기기에서도 모두 접속이 끊길 수 있습니다.
- 전체 구독 URL을 공개 스크린샷, 온라인 변환 도구, 질문 게시판에 올리지 마세요. 문제 해결에 필요한 경우 도메인과 오류 유형만 남기고 경로의 인증 정보와 쿼리 매개변수는 가리세요.
403은 서버 측 보안 설정이나 클라이언트 식별자 제한 때문에 발생할 수도 있습니다. 관리 화면에서 계정이 정상임을 확인했다면 DNS를 계속 바꾸기보다 서비스 제공자의 클라이언트 호환 안내를 확인하세요. DNS로 서버가 거부한 접근 권한을 해결할 수는 없습니다.
직접 연결 실패 시 프록시로 업데이트할지 선택하기
먼저 클라이언트의 구독 다운로드가 어떤 네트워크 경로를 사용하는지 확인하세요. 브라우저에서 시스템 프록시를 통해 접속된다고 해서 클라이언트의 백그라운드 다운로드도 같은 프록시를 이용하는 것은 아닙니다. 일부 클라이언트에는 ‘프록시를 통해 업데이트’ 옵션이 있고, 다른 클라이언트는 자체 네트워크 스택을 사용합니다. TUN 모드는 더 많은 트래픽을 처리할 수 있지만 모든 백그라운드 업데이트 요청이 지정한 노드를 거친다고 보장하지는 않습니다.
무작정 반복하지 말고 두 번만 조건을 바꿔 테스트하세요
- 현재 작동하는 노드를 유지한 채 수동 업데이트를 한 번 실행하고 시간 초과 여부를 기록하세요.
- 클라이언트에 ‘프록시를 통해 업데이트’ 옵션이 있으면 설정을 바꾼 뒤 한 번 더 시도하세요. 해당 옵션이 없다면 시스템 프록시가 반드시 적용된다고 가정하지 말고 클라이언트 안내를 확인하세요.
- 프록시 경로에서만 성공하면 해당 업데이트 방식을 유지하세요. 직접 연결에서만 성공하면 선택한 프록시 출구가 구독 서비스에서 제한되는지 확인하세요.
- 두 경로 모두 실패하면 노드를 계속 바꾸지 말고 도메인 확인, 서버 상태, 로컬 방화벽을 점검하세요.
데스크톱에서는 curl로 결과를 비교할 수도 있습니다. 아래 명령은 주소를 로컬에서 직접 입력하게 하므로 토큰이 명령 기록에 남지 않습니다. 출력 파일에도 민감한 정보가 포함되므로 확인 후 삭제하세요. Bash와 curl을 사용할 수 있는 환경에서만 적용되는 예시입니다.
read -r -s -p '구독 URL 입력: ' SUB_URL
printf '\n'
curl --noproxy '*' --connect-timeout 10 --max-time 30 \
-D subscription.headers -o subscription.body "$SUB_URL"
unset SUB_URL여기서 10초는 연결 시간 제한이고 30초는 전체 요청의 제한 시간이지, 측정된 지연 시간이 아닙니다. --noproxy '*'는 curl의 프록시 설정을 우회하지만 시스템 라우팅이나 활성화된 TUN까지 우회하지는 않습니다. TUN을 사용하지 않는 경로와 비교하려면 현재 설정을 기록한 다음 TUN을 잠시 끄고 테스트하세요.
curl에서 로컬 프록시를 지정하려면 클라이언트에 표시된 HTTP 또는 혼합 포트를 사용하세요. 예를 들어 실제 수신 주소가 127.0.0.1:7890인 경우에만 --proxy http://127.0.0.1:7890를 사용하세요. 컨트롤 인터페이스 포트를 프록시 포트로 착각하지 마세요. 설정마다 수신 포트가 다를 수 있습니다.
인증서 오류 및 형식 호환성
TLS 오류가 발생하면 먼저 시스템 시간을 확인하세요
certificate has expired, certificate is not yet valid, unknown authority 오류가 나타나면 먼저 시스템의 날짜 및 시간 설정을 열고 자동 시간 동기화를 켜세요. 이어서 공용 Wi-Fi에 웹 인증이 필요한지 확인하고, 보안 소프트웨어가 HTTPS 연결을 중간에서 복호화하는지도 점검하세요.
특정 구독 도메인에서만 인증서 오류가 계속 발생하고 다른 HTTPS 서비스는 정상이라면 서비스 제공자에게 인증서 유효 기간과 중간 인증서 체인을 확인해 달라고 요청하세요. 노드 설정의 skip-cert-verify는 구독 다운로드를 해결하는 범용 옵션이 아닙니다. 구독 서버의 인증서 문제를 해결할 수 없으며, 문제 해결을 위해 인증서 검증을 장기간 끄는 것도 권장하지 않습니다.
콘텐츠를 받은 뒤 형식을 확인하세요
- 완전한 Clash YAML: 일반적으로
proxies,proxy-groups,rules가 포함됩니다. providers를 통해 외부 리소스를 참조할 수도 있으며, 호환되는 클라이언트에서 불러와야 합니다. - Base64 노드 목록: 디코딩하면 여러 줄의 프로토콜 링크가 나올 수 있지만 완전한 Clash 설정은 아닙니다. 서비스 관리 화면에서 해당 형식을 선택하는 것이 좋습니다.
- Provider YAML: 일반적으로
proxies만 포함하는 노드 모음입니다.proxy-providers에 넣어 사용하는 형식이며, 전체 트래픽 분할 설정으로 바로 사용할 수 있다고 가정하면 안 됩니다. - HTML 또는 JSON 오류 응답: 먼저 로그인, 권한 또는 게이트웨이 문제를 해결하세요. YAML 들여쓰기를 바꿔도 해결되지 않습니다.
Clash는 클라이언트와 코어 생태계를 통칭하며, Clash Meta는 이후 mihomo라는 이름으로 유지 관리되고 있습니다. 구형 코어는 새 프로토콜이나 필드를 지원하지 않을 수 있습니다. 로그에 지원되지 않는 프록시 유형이 명시되어 있다면 데스크톱 앱 이름만 보지 말고 실제 실행 중인 코어와 서비스 제공자의 호환 요구 사항을 확인하세요. 직접 수정하기 전에 설정을 백업하고 YAML 들여쓰기에는 Tab이 아닌 공백을 사용하세요.
클라이언트별 자동 업데이트 주기 설정 위치
원격 설정 전체의 예약 업데이트는 대개 그래픽 클라이언트가 관리합니다. 모든 클라이언트의 구독을 제어하는 공통 최상위 interval은 없습니다. 해당 구독의 편집 화면을 열고 각 항목에 표시된 단위를 확인하세요. 아래는 일반적인 메뉴 경로입니다. 배포판에 따라 번역, 버튼 위치, 필드 이름이 달라질 수 있으므로 현재 설치된 버전의 실제 화면을 기준으로 확인하세요.
| 클라이언트 | 일반적인 메뉴 경로 | 참고 사항 |
|---|---|---|
| Clash Verge Rev | ‘프로필’ → 대상 원격 설정의 마우스 오른쪽 버튼 메뉴 또는 더보기 메뉴 → ‘정보 편집’ → ‘업데이트 주기’ | 해당 설정 항목의 업데이트 주기만 변경됩니다. 화면에 표시된 단위를 확인하고 저장하세요. |
| Clash for Windows | ‘Profiles’ → 원격 설정을 마우스 오른쪽 버튼으로 클릭 → ‘Settings’ → ‘Update Interval’ | 프로젝트 유지 관리가 중단되었습니다. 구버전은 화면 구성과 호환성이 다를 수 있으니 설정을 보존한 뒤 이전을 고려하세요. |
| Clash for Android | ‘프로필’ → 대상 원격 설정의 편집 메뉴 → ‘자동 업데이트’ 또는 업데이트 주기 항목 | 이전 프로젝트는 유지 관리가 중단되었습니다. 백그라운드 업데이트는 시스템 배터리 제한 및 앱의 백그라운드 권한에도 영향을 받습니다. |
| 기타 mihomo 그래픽 클라이언트 | ‘프로필 / 구독’ → 대상 항목의 ‘편집’ 또는 ‘설정’ | 수동 업데이트 버튼만 있다면 자동 업데이트를 지원한다고 단정하지 말고 해당 버전의 기능을 확인하세요. |
업데이트 주기는 어떻게 정하나요?
일반적인 노드 구독은 우선 6시간마다 업데이트하도록 설정할 수 있습니다. 필드 단위에 맞춰 360분 또는 21600초를 입력하세요. 이는 시작점으로 권장하는 값이며 모든 서비스에 적용되는 요구 사항은 아닙니다. 서비스 제공자가 최소 주기를 지정했다면 해당 기준을 따르세요. 노드가 적고 오랫동안 안정적인 구독은 12시간 또는 24시간으로 늘려도 됩니다.
업데이트 실패를 ‘해결’하려고 주기를 1분으로 설정하지 마세요. 권한, 인증서, 형식 오류는 요청을 자주 보낸다고 사라지지 않으며 오히려 429를 유발할 수 있습니다. 0의 의미도 클라이언트마다 다릅니다. 자동 업데이트를 끄는 경우도 있고 기본값으로 되돌리는 경우도 있으므로 필드 안내를 확인하세요.
mihomo Provider 업데이트는 별도의 기능입니다
설정 전체는 정상적으로 다운로드됐는데 노드 목록이 바뀌지 않았다면 proxy-providers를 확인하세요. mihomo의 HTTP provider는 초 단위 interval을 지원하며 코어가 외부 노드 파일을 가져옵니다. 이는 그래픽 클라이언트가 구독 설정 전체를 새로 고치는 작업과는 별개입니다.
아래 예시는 기존 설정에 넣을 수 있는 로컬 provider 조각만 보여 줍니다. 파일이 미리 있어야 하며 올바른 노드 목록이 포함되어야 합니다. 원격 업데이트는 수행하지 않으며 interval을 추가한다고 HTTP 구독으로 바뀌지 않습니다.
proxy-providers:
local-nodes:
type: file
path: ./providers/local-nodes.yaml기존 HTTP provider에는 실제 url과 필요한 필드를 그대로 유지하고, 해당 provider 안에 interval: 21600을 설정하면 노드 파일이 6시간마다 업데이트됩니다. 이 줄을 rules에 넣거나 설정 최상위에 추가해 구독 전체가 자동 업데이트되기를 기대하지 마세요.
proxy-providers.名称.interval: 해당 HTTP 노드 목록의 다운로드 주기를 초 단위로 설정합니다.health-check.interval: provider 노드의 상태 확인 주기를 설정하며 새 노드를 다운로드하지는 않습니다.rule-providers.名称.interval: 해당 HTTP 규칙 목록을 업데이트하며 노드 목록을 새로 고치지는 않습니다.
원격 구독을 다음에 새로 고칠 때 직접 수정한 provider 설정이 덮어써질 수 있습니다. 변경 사항을 계속 유지하려면 클라이언트가 지원하는 오버라이드, 병합 또는 확장 설정 기능을 사용하고 최종 적용된 설정을 확인하세요. 편집기에서 저장됐다는 사실만으로 실행 중인 코어에 새 값이 적용됐다고 볼 수는 없습니다.
업데이트 복구 후 확인할 항목
- 다운로드 결과 확인: 마지막 업데이트 시간이 바뀌었고 로그에 새로운 HTTP, TLS 또는 파싱 오류가 없는지 확인하세요.
- 설정 활성화 상태 확인: 이름만 같은 로컬 복사본이 아니라 방금 업데이트한 설정이 선택되어 있는지 확인하세요.
- 정책 그룹 확인: 노드 목록이 바뀌었는지 살펴보고 선택한 노드가 삭제됐다면 사용 가능한 출구를 다시 선택하세요.
- 실제 연결 확인: 프록시가 필요한 서비스에 접속해 연결 기록에서 규칙과 출구를 확인하세요. 구독이 성공해도 트래픽이 예상대로 분할된다는 보장은 없습니다.
- 다음 업데이트 주기 확인: 현재 시간과 업데이트 주기를 기록하고 다음 주기가 지난 뒤 타임스탬프를 확인해 예약 작업이 실제로 실행됐는지 확인하세요.
마지막으로 복구에 필요한 경로를 하나 확보해 두세요. 현재 설정을 백업하고 구독 주소와 수동 업데이트 메뉴 위치를 기록하세요. 문제가 계속되면 서비스 제공자나 클라이언트 유지 관리자에게 민감 정보를 가린 로그, 클라이언트 및 코어 버전, 오류 발생 시간, 직접 연결과 프록시 테스트 결과를 전달하세요. 전체 구독 주소나 인증 정보가 포함된 설정 파일은 보내지 마세요.