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

먼저 실패 단계부터 확인하세요: 다운로드, 파싱 또는 적용

구독 업데이트는 보통 클라이언트가 구독 주소에 요청을 보내고, 응답 내용을 확인한 뒤, 설정을 저장하거나 불러오는 순서로 진행됩니다. “업데이트 실패”가 노드 사용 불가를 뜻하는 것은 아닙니다. 노드에 연결할 수 있어도 구독 주소가 더 이상 유효하지 않을 수 있습니다. 문제를 살필 때는 현재 작동하는 설정을 그대로 두세요. 삭제 후 다시 가져오거나 새로고침을 연달아 누르지 마세요.

1. 대상 기록: “설정 / Profiles”의 원격 설정 전체인지, “프록시 공급자 / Proxy Providers”의 특정 노드 모음인지 확인합니다.
2. 오류 내용 기록: 클라이언트의 “로그 / Logs”를 열고 수동으로 한 번 업데이트한 다음, 같은 시각 전후의 오류 메시지와 HTTP 상태 코드, 설정 이름을 기록합니다. 클라이언트마다 메뉴 이름은 다를 수 있습니다.
3. 현재 상태 확인: 기존 설정이 여전히 작동하는지, 마지막 업데이트 성공 시간이 바뀌었는지, 업데이트 후 대상 설정이 계속 선택되어 있는지 확인합니다.

다운로드 시간 초과: 도메인, 네트워크, 다운로드 경로를 각각 확인

먼저 네트워크를 바꾸고 설정은 나중에 수정하세요

context deadline exceeded는 작업이 제한 시간을 넘겼다는 뜻입니다. 이 메시지만으로 DNS, TCP 연결, TLS 핸드셰이크 중 어느 단계에서 문제가 생겼는지, 아니면 응답이 늦게 도착했는지 판단할 수는 없습니다. 먼저 로그에 표시된 단계를 확인한 뒤 같은 기기에서 Wi-Fi를 모바일 핫스팟으로 바꾸고 동일한 구독 주소를 수동으로 한 번 업데이트해 보세요. 한 번에 한 가지 조건만 바꿔야 원래 네트워크의 영향인지 알 수 있습니다.

• 도메인 확인 실패: 링크에 공백이나 줄바꿈이 들어갔거나 문자가 빠지지 않았는지 확인하세요. 다른 웹사이트가 열린다고 해서 구독 도메인도 반드시 확인되는 것은 아닙니다.
• 연결 거부: connection refused는 대개 대상 포트에서 연결을 거부했다는 뜻입니다. 서버 주소나 로컬 프록시의 수신 상태를 확인하세요.
• 응답 읽기 시간 초과: 서버가 연결을 수락했지만 응답을 완료하지 못하고 있을 수 있습니다. 발생 시각과 네트워크 환경을 기록해 서비스 제공업체에 문의하세요.

시스템 프록시, TUN, 구독 다운로드는 각각 별개의 설정입니다

설정 전체는 클라이언트 UI 프로세스가 다운로드할 수도 있고 다른 구성 요소가 처리할 수도 있습니다. 반면 proxy-providers의 원격 리소스는 보통 코어가 가져옵니다. 따라서 “브라우저에서 프록시를 사용 중”이라는 사실만으로 구독 요청도 같은 경로를 이용한다고 볼 수 없습니다. TUN이 어떤 연결을 처리하는지는 라우팅, 프로세스 제외 설정, 클라이언트 구현에 따라서도 달라집니다.

클라이언트에 “프록시를 통해 업데이트”와 같은 옵션이 있다면, 먼저 사용할 수 있는 노드가 있는지 확인한 뒤 해당 옵션을 전환해 비교해 보세요. 기존 노드가 모두 작동하지 않을 때 새 구독을 받으려면 기존 노드가 필요하도록 설정하면 순환 의존성이 생길 수 있습니다. 직접 연결을 시도하거나 구독 주소에 접근할 수 있는 다른 네트워크를 사용하세요.

인증서 오류: 먼저 시간과 신뢰 체인을 확인하세요

HTTPS 구독은 서버의 신원을 확인해야 합니다. 인증서 오류가 발생하면 먼저 전체 메시지를 확인하고, 인증서 검증을 바로 끄지 마세요. 노드 설정의 skip-cert-verify는 해당 프록시 노드의 TLS 검증에 주로 영향을 줍니다. 클라이언트의 구독 다운로드 전반에 적용되는 해결 옵션은 아닙니다.

1. 시스템 시간 동기화: 운영체제에서 날짜와 시간 자동 설정을 켜고 연도, 시간대, 동기화 상태를 확인하세요. 시스템 시계가 맞지 않으면 유효한 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판정될 수 있습니다.
2. 도메인 확인: certificate is valid for와 같은 오류는 호스트 이름이 일치하지 않을 때 발생할 수 있습니다. 구독 도메인을 임의로 IP 주소로 바꾸지 마세요. 인증서 검증과 가상 호스트 선택에 문제가 생길 수 있습니다.
3. 네트워크 인증 확인: 공용 Wi-Fi는 먼저 인증 페이지에서 로그인해야 할 수 있습니다. 로그인한 뒤 업데이트하세요. 회사 네트워크의 HTTPS 검사로 인증서 체인이 바뀔 수도 있으니 네트워크 관리자에게 확인하세요.
4. 신뢰 환경 확인: certificate signed by unknown authority 오류는 서버의 인증서 체인이 완전하지 않거나 기기의 신뢰 저장소 또는 네트워크 가로채기에서 비롯될 수 있습니다. 개인용 핫스팟으로 다시 확인하면 원인을 좁히는 데 도움이 됩니다.

기기 시간이 정확한데도 여러 네트워크에서 같은 구독 도메인에 인증서 만료 오류가 발생하면 서비스 제공업체에 수정을 요청하세요. HTTPS 주소를 HTTP로 바꾸거나 출처를 알 수 없는 루트 인증서를 설치해 경고를 우회하지 마세요.

응답이 YAML이 아님: 상태 코드와 구독 유형 확인

HTTP 요청이 성공했다고 해서 사용할 수 있는 설정을 받은 것은 아닙니다. 상태 코드가 200이어도 본문은 로그인 페이지, 접근 확인 페이지, 계정 만료 안내일 수 있습니다. 반대로 Content-Type이 text/plain이라고 해서 바로 실패로 판단할 수도 없습니다. 일부 서비스는 이 형식으로 유효한 YAML을 반환합니다. 최종적으로는 본문 구조를 확인해야 합니다.

응답 유형별 해결 방법

• 본문이 <!DOCTYPE html>로 시작함: 웹페이지를 받은 것입니다. 계정 관리 페이지 주소가 아니라 클라이언트용 구독 주소를 복사했는지 확인하세요. 웹페이지 내용을 설정 파일로 저장해 강제로 불러오지 마세요.
• 본문이 vmess:// 같은 링크 또는 긴 인코딩 문자열임: 현재 클라이언트에 맞는 설정 형식이 아니라 일반 노드 구독을 선택했을 수 있습니다. 서비스 제공업체의 구독 내보내기 메뉴에서 해당 클라이언트에 맞는 유형을 선택하세요.
• 본문이 JSON 오류 메시지임: 먼저 서버의 오류 내용을 확인하세요. YAML 들여쓰기를 바꿔도 계정 만료나 토큰 오류는 해결되지 않습니다.
• 본문이 실제 YAML임: 필드 계층, 자료형, 코어 지원 여부를 추가로 확인하세요. YAML 문법을 파싱할 수 있어도 Clash 또는 mihomo 설정 구조에 맞는다는 뜻은 아닙니다.

전체 설정과 노드 모음을 혼동하지 마세요

전체 설정에는 proxies, proxy-groups, rules가 포함될 수 있으며, proxy-providers를 통해 노드 모음을 참조할 수도 있습니다. 일반적인 provider YAML에는 proxies: 아래에 노드가 나열됩니다. 이는 정책 그룹과 규칙을 포함한 완전한 설정과 다릅니다. 전체 설정 주소를 노드 모음만 받는 메뉴에 입력하거나, 노드 모음을 전체 설정으로 가져오면 파싱 또는 실행 문제가 생길 수 있습니다.

로그에 특정 노드 유형이나 필드를 지원하지 않는다는 메시지가 명확히 표시되면 클라이언트의 “정보” 화면에서 코어 이름과 버전을 확인하세요. 기존 Clash와 Clash Meta(현재 mihomo로 불림)는 지원 범위가 다릅니다. 앱 이름에 Clash가 들어 있는지만 봐서는 알 수 없습니다. 필드 구조는 설정 파일 구조 안내를, 형식 변환의 범위는 구독 변환 안내를 참고하세요.

자동 업데이트 간격: 세 가지 interval 구분하기

“구독을 매시간 업데이트”하려고 YAML의 아무 곳에나 interval: 3600을 넣는 것은 올바른 방법이 아닙니다. 원격 설정 전체를 정기적으로 새로 받는 기능은 보통 클라이언트의 설정 관리 메뉴에 있습니다. provider 다운로드와 노드 상태 확인에는 각각 별도의 필드가 사용됩니다. 이 세 가지를 혼동하면 지연 시간 검사는 계속 실행되는데 노드 목록은 바뀌지 않는 상황이 생길 수 있습니다.

구독 전체: 원격 설정 항목에서 설정

일반적인 경로는 “설정 / Profiles” → 대상 원격 설정의 메뉴 → “편집 / Edit” → 자동 업데이트 또는 업데이트 간격입니다. 이는 대표적인 메뉴 경로이며 실제 이름은 클라이언트에 따라 다를 수 있습니다. 입력란의 단위가 분이면 60을 입력해야 1시간이고, 초이면 3600을 입력해야 합니다. 다른 클라이언트의 숫자를 그대로 따라 입력하지 마세요.

먼저 6시간 또는 하루에 한 번 업데이트하도록 설정하고, 서비스 제공업체의 안내에 따라 조정하세요. 구독 주소가 안정적이고 노드가 자주 바뀌지 않는다면 지나치게 잦은 새로고침은 도움이 되지 않습니다. 0을 입력하면 반드시 꺼진다고 가정하지 마세요. 명확한 끄기 옵션을 사용하고 현재 클라이언트의 안내를 확인하세요.

HTTP provider: 해당 모음에서 설정

다음은 mihomo에서 자주 사용하는 HTTP provider 설정 예시이며, 그대로 실행할 수 있는 완전한 설정은 아닙니다. example.com은 문서용 예시 도메인으로 실제 노드를 제공하지 않습니다. 사용할 때는 계정에서 제공하는 노드 모음 주소를 입력하고 정책 그룹에서 use로 모음 이름을 참조해야 합니다.

proxy-providers:
  daily-nodes:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/daily-nodes.yaml
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 300

여기서 21600초는 6시간으로 노드 모음 다운로드 주기를 제어합니다. 300초는 상태 확인 간격이며 노드 목록을 새로 받지는 않습니다. 상태 확인 주소는 현재 노드로 정상 접속할 수 있어야 합니다. 여러 provider를 사용할 때는 같은 파일에 쓰이지 않도록 캐시 파일 경로를 서로 다르게 지정하세요.

수동 새로고침: 한 번 실행해 결과 확인하기

수동 새로고침은 수정이 효과가 있는지 확인할 때 사용하세요. 반복해서 시도해 운에 맡기는 용도로 쓰면 안 됩니다. 특히 429가 표시되면 버튼을 연달아 누르지 마세요. 응답에 Retry-After가 있으면 서버가 지정한 시간만큼 기다리세요. 500, 502, 503 등 서버 오류가 발생하면 기존 설정을 유지하고 잠시 후 재시도하거나 서비스 상태를 확인하세요.

1. 백업 보관: 클라이언트에서 지원하는 내보내기 기능으로 현재 작동하는 설정을 저장하고 로컬 덮어쓰기, 정책 선택, 구독 출처를 따로 기록하세요.
2. 대상 확인: 원격 설정 항목에서 업데이트를 실행하세요. 정책 그룹의 지연 시간 테스트 버튼을 잘못 누르지 않도록 주의하고, provider를 업데이트할 때도 모음 이름을 확인하세요.
3. 한 번에 하나만 변경: 예를 들어 네트워크만 바꾸거나 시스템 시간만 수정한 뒤 수동으로 한 번 새로고침하고 오류가 달라졌는지 기록하세요.
4. 저장 및 불러오기 확인: 업데이트 시간이 바뀌었는지, 이후 로그에 파싱 오류가 없는지, 현재 어떤 설정이 활성화되어 있는지 확인하세요. 일부 클라이언트는 현재 사용 중이 아닌 설정을 업데이트해도 자동으로 전환하지 않습니다.
5. 실제 연결 확인: 정책 그룹에서 여전히 사용할 수 있는 노드를 선택했는지 확인한 뒤 자주 사용하는 서비스에 접속해 보세요. “다운로드 성공”과 “서비스 정상 이용”은 각각 확인해야 합니다.

업데이트 후 노드는 복구됐지만 사용자 지정 규칙이 사라졌다면 원격 설정에 직접 수정 내용을 입력했는지 확인하세요. 이후 다운로드 과정에서 해당 파일이 교체될 수 있습니다. 장기간 유지할 규칙은 클라이언트가 명확히 지원하는 덮어쓰기, 병합 또는 확장 기능에 넣고 최종 생성된 설정을 검증하세요. 가져오기와 전환 절차는 구독 가져오기 가이드를 참고하세요.

서비스 제공업체나 클라이언트 유지관리자에게 문의할 때는 발생 시각, 운영체제 및 클라이언트 버전, 코어 버전, 민감 정보를 가린 상태 코드, 같은 주소를 다른 네트워크에서 시도했을 때의 결과를 알려주세요. 이런 정보가 “업데이트 실패”라는 메시지를 반복해서 보내는 것보다 원인 파악에 도움이 됩니다. 구독 토큰, 전체 노드 접속 정보, 계정 페이지 스크린샷의 민감한 내용은 먼저 삭제하세요.