Clash 구독 업데이트 실패 해결법: 원인 점검과 자동 업데이트 주기 설정

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

Clash 클라이언트에서 표시되는 “업데이트 실패”는 하나의 장애를 뜻하지 않습니다. 원격 구독 업데이트는 일반적으로 도메인 확인, TCP 및 TLS 연결, HTTP 요청, 콘텐츠 다운로드, 설정 파싱, 커널 검증과 설정 전환을 거칩니다. 화면에 실패 메시지 하나만 표시되더라도 업데이트를 계속 누르기보다 정확히 어느 단계에서 멈췄는지 먼저 확인해야 합니다.

가장 유용한 판단 근거는 클라이언트 로그, HTTP 상태 코드와 다운로드된 콘텐츠입니다. 먼저 실패 시각을 기록한 다음 로그 페이지를 열고, 같은 분에 구독 도메인, timeout, certificate, 401, 403, 404, parse 또는 yaml이 포함된 항목을 찾으세요. 단계에 따라 점검 방향은 달라집니다.

링크 만료, 요청 차단과 비정상적인 서버 응답

복사 과정에서 링크가 손상되지 않았는지 확인하기

구독 주소는 줄바꿈, 끝부분 공백, 메신저의 잘림 또는 HTML 이스케이프 때문에 작동하지 않을 수 있습니다. 흔한 사례는 첫 번째 & 앞까지만 복사되거나 끝부분 토큰의 문자가 몇 개 빠지는 경우입니다. 구독 서비스 관리 페이지에서 전체 URL을 다시 복사해 클라이언트의 기존 주소를 덮어쓰고, 토큰을 직접 조합하지 마세요.

HTTP 상태 코드를 확인하면 원인을 빠르게 좁힐 수 있습니다. 401은 대개 인증 정보나 토큰이 더 이상 유효하지 않다는 뜻입니다. 403은 접근 정책, 요청 빈도 제한 또는 접속 네트워크와 관련될 수 있습니다. 404는 경로가 존재하지 않음을, 410은 리소스가 명확히 만료되었음을 의미하는 경우가 많습니다. 429는 짧은 시간에 요청이 너무 많다는 뜻입니다. 429가 발생한 뒤 계속 빠르게 새로 고치면 제한 시간이 오히려 길어질 수 있습니다.

터미널에서 HTTP 요청만 따로 테스트하기

데스크톱에서는 curl을 사용해 네트워크 다운로드와 클라이언트 파싱을 분리해서 테스트할 수 있습니다. 먼저 구독 주소를 현재 터미널의 환경 변수에 저장한 뒤 다음 명령을 실행하세요. 이 명령은 연결 시간 초과를 10초, 전체 시간 초과를 30초로 설정하고 HTTP 리디렉션을 따릅니다.

export SUB_URL='전체 구독 주소'
curl -L \
  --connect-timeout 10 \
  --max-time 30 \
  -D response-headers.txt \
  -o profile.yaml \
  "$SUB_URL"

response-headers.txt에서 최종 상태 코드를 확인한 뒤 profile.yaml의 앞부분을 살펴보세요. 일반적인 Clash 또는 Mihomo 설정에는 proxies:, proxy-groups:, rules:와 같은 YAML 필드가 표시됩니다. 콘텐츠가 <html로 시작한다면 실제로 다운로드된 것은 로그인 페이지, 인증 페이지 또는 오류 페이지입니다. JSON 오류 객체가 반환된 경우에도 설정으로 바로 가져올 수 없습니다.

일부 서비스는 Base64로 인코딩된 범용 구독을 반환하지만, 클라이언트 입력란은 Clash YAML만 지원합니다. 이 경우 네트워크 요청은 성공해도 파싱에는 실패합니다. 파일 확장자만 바꾸지 말고 서버에서 Clash, Clash Meta 또는 Mihomo 형식을 선택하세요.

시스템 시간과 TLS 연결 확인하기

기기 시간의 오차는 HTTPS 인증서 검증에 영향을 줍니다. 로그에 certificate has expired, not yet valid 또는 핸드셰이크 실패가 표시되면 먼저 시스템 자동 시간 동기화를 켜세요. Windows에서는 「설정」→「시간 및 언어」→「날짜 및 시간」에서 자동 시간 설정을 켤 수 있습니다. macOS에서는 「시스템 설정」→「일반」→「날짜 및 시간」에서 자동 설정을 켜세요.

브라우저에서는 구독 주소가 열리지만 클라이언트에서는 계속 시간 초과가 발생한다면 두 프로그램이 사용하는 네트워크 경로를 비교해야 합니다. 브라우저는 시스템 프록시를 사용하지만 클라이언트 업데이트 기능은 직접 연결을 사용할 수 있고, 그 반대일 수도 있습니다. 이 차이는 “브라우저는 열리는데 Clash 업데이트가 실패하는” 흔한 원인입니다.

프록시 루프, TUN 모드와 DNS 경로 점검

구독 업데이트 요청에는 작동 가능한 시작 경로가 필요합니다. 업데이트 기능이 현재 프록시에 의존하는데 현재 설정의 노드가 모두 만료되었다면 시작 의존성이 생깁니다. 노드를 복구하려면 먼저 업데이트해야 하지만, 업데이트 요청 역시 해당 노드를 거쳐야 하는 상황입니다. 클라이언트 프로세스의 요청이 시스템 프록시나 TUN을 통해 다시 자기 자신에게 전달되는 경우에도 루프가 발생할 수 있습니다. 로그에는 같은 도메인에 대한 연결이 반복되거나 연결 거부 및 시간 초과가 연속으로 나타날 수 있습니다.

직접 연결 테스트로 시작 의존성 끊기

1. 현재 설정과 모드를 기록한 뒤 TUN 모드를 잠시 끄세요.
2. 시스템 프록시를 끄고 브라우저나 터미널에서 일반 웹사이트에 직접 접속할 수 있는지 확인하세요.
3. 클라이언트에서 대상 구독을 한 번 수동 업데이트하세요.
4. 업데이트가 성공하면 시스템 프록시 또는 TUN을 다시 켜고 기존 규칙 모드를 복원하세요.

구독 도메인에 프록시가 반드시 필요하다면 작동이 확인된 시작 경로를 하나 남겨 두어야 합니다. 연결 가능한 로컬 설정으로 먼저 전환한 뒤 원격 설정을 업데이트하세요. 사용 가능한 설정을 마지막 하나까지 삭제한 다음 원격 구독을 테스트하지 마세요.

로컬 포트와 시스템 프록시 확인하기

일반적인 데스크톱 설정에서는 HTTP 또는 mixed 수신 포트로 7890을 사용하고, 구형 분리 설정에서는 HTTP 7890과 SOCKS 7891을 사용할 수 있습니다. 외부 컨트롤 포트는 보통 9090입니다. 이 값은 변경할 수 있으므로 현재 클라이언트의 「설정」 또는 「포트」 화면에 표시된 실제 값을 기준으로 확인하세요.

시스템 프록시가 127.0.0.1:7890을 가리키는데 커널이 실행 중이 아니거나 mixed-port가 다른 값으로 변경되었다면 시스템 프록시를 거치는 모든 업데이트 요청이 실패합니다. 먼저 커널이 실행 중인지 확인한 다음 해당 포트가 수신 대기 중인지 점검하세요. 포트 충돌 로그에는 보통 address already in use가 포함됩니다.

구독 도메인의 DNS 결과 확인하기

TUN과 fake-ip를 켜면 애플리케이션에 보이는 주소가 fake-ip 주소 풀에서 나온 것일 수 있으며, 이는 정상적인 전달 방식입니다. 그러나 클라이언트 자체의 업데이트 기능은 실제 도메인 확인을 완료해야 합니다. 로그에 DNS 시간 초과가 표시되면 TUN을 잠시 끈 뒤 다시 테스트하여 시스템 DNS 경로와 Mihomo DNS 경로를 구분하세요.

IPv6도 확인해야 합니다. 일부 네트워크는 AAAA 레코드를 반환하지만 안정적인 IPv6 출구가 없어 약 10~30초 기다린 뒤 시간 초과가 발생할 수 있습니다. 시스템에서 해당 네트워크 인터페이스의 IPv6을 임시로 끄거나 클라이언트의 DNS 및 연결 정책을 조정한 뒤 다시 테스트하세요. 테스트 결과가 IPv6을 명확히 가리킬 때만 장기적인 변경을 적용하여 다른 문제까지 가리지 않도록 하세요.

다운로드는 성공했지만 파싱에 실패할 때의 처리 순서

로그에 HTTP 200이 이미 표시되었다면 문제의 초점은 네트워크에서 콘텐츠로 옮겨야 합니다. 먼저 다운로드된 파일이 예상한 설정인지 확인하고, 다음으로 YAML 문법을 점검한 뒤, 마지막으로 현재 커널이 해당 필드를 지원하는지 확인하세요. 세 단계를 한꺼번에 처리하면 DNS와 프록시 설정만 반복해서 바꾸고 정작 파싱 오류는 해결하지 못하기 쉽습니다.

먼저 YAML 기본 구조 검증하기

YAML은 들여쓰기에 민감합니다. Tab 문자, 잘못된 목록 계층과 닫히지 않은 따옴표 때문에 설정 로드가 거부될 수 있습니다. Mihomo 명령줄을 사용할 때는 프록시 수신 포트를 실행하지 않고도 설정을 테스트할 수 있습니다:

mihomo -t -f profile.yaml

테스트가 통과하면 대개 설정 검증 성공 메시지가 표시되고, 실패하면 문제가 된 필드나 줄 번호가 안내됩니다. 원격 구독으로 자동 생성되는 설정이라면 매번 덮어써지는 파일을 로컬에서 직접 수정하지 말고, 구독 형식 설정이나 변환 규칙에서 처리하세요.

전체 설정과 프록시 프로바이더 구분하기

완전한 원격 설정에는 보통 포트, DNS, 프록시 그룹과 규칙이 포함되며 클라이언트 설정으로 바로 활성화할 수 있습니다. proxy-providers는 독립적인 노드 모음을 주 설정에서 참조하는 방식으로, 두 설정의 업데이트 메커니즘은 다릅니다. 노드 목록만 있는 provider 파일을 전체 설정으로 가져오면 proxy-groups와 rules가 빠질 수 있습니다. 반대로 전체 설정을 provider 주소에 입력해도 구조가 맞지 않아 실패합니다.

Mihomo 설정에서 provider의 interval 단위는 초입니다. 예를 들어 21600은 6시간마다 한 번 확인한다는 뜻입니다. 이 값은 해당 provider만 제어하며, 그래픽 클라이언트에서 전체 원격 설정에 지정한 업데이트 주기와는 다릅니다.

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.net/subscription/token-value"
    path: ./providers/remote-nodes.yaml
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

필드 호환성은 커널 버전과 함께 확인하기

구독 서비스가 새로운 Mihomo 필드를 추가했지만 클라이언트에는 오래된 커널이 포함되어 있을 수 있습니다. 반대로 구형 Clash 필드를 출력해 현재의 엄격한 검증 규칙과 맞지 않을 수도 있습니다. 먼저 클라이언트의 「정보」 또는 「커널」 화면에서 실제 Mihomo 버전을 확인한 뒤 파싱 로그에 표시된 필드를 살펴보세요. 그래픽 인터페이스를 업데이트해도 커널이 함께 업데이트된다는 보장은 없으므로, 작업 후 커널 버전 번호를 다시 확인해야 합니다.

기존 설정은 로드되는데 새 설정이 특정 시점부터 일괄적으로 오류를 낸다면 서버에서 생성하는 형식이 변경되었는지 먼저 비교하세요. 노드 하나 때문에 전체 설정이 실패하는 경우에는 로그에서 해당 노드의 프로토콜과 필드를 확인한 뒤 구독 서비스에서 호환 형식으로 다시 생성하도록 요청하세요.

클라이언트별 자동 업데이트 주기 설정 방법

클라이언트마다 “자동 업데이트”를 부르는 이름은 조금씩 다릅니다. 아래 경로는 Clash Verge Rev 2.3.x, Clash Meta for Android 2.11.x와 FlClash 0.8.x의 일반적인 화면을 기준으로 정리했습니다. 마이너 버전이 바뀌면 버튼 위치가 달라질 수 있지만, 설정 대상은 노드 상태 확인이 아니라 원격 설정 자체입니다.

일상적인 사용에는 12~24시간 권장

노드와 규칙이 자주 바뀌지 않는다면 1440분마다 업데이트해도 일상적인 변경을 충분히 반영하면서 서버 요청을 줄일 수 있습니다. 서비스 제공자가 하루에 여러 번 노드를 조정한다면 720분으로 설정하세요. 더 빠른 동기화가 꼭 필요할 때만 360분을 권장합니다. 5분이나 10분으로 설정하는 것은 대개 불필요하며 HTTP 429를 유발할 수도 있습니다.

모바일에서는 운영체제의 백그라운드 정책도 영향을 줍니다. Android의 배터리 절전 제한은 백그라운드 작업을 중지할 수 있고, iOS 역시 앱을 종료한 뒤 클라이언트가 매분 정확히 실행된다고 보장하지 않습니다. 따라서 “12시간으로 설정”했다는 것은 클라이언트가 실행될 기회를 얻었을 때 해당 주기로 확인한다는 뜻이며, 시스템이 정확한 시각에 앱을 깨운다는 의미는 아닙니다. 중요한 업데이트는 클라이언트를 포그라운드에서 연 뒤 수동으로 한 번 실행하세요.

구독 업데이트와 상태 확인을 혼동하지 않기

구독 업데이트는 노드, 정책 그룹과 규칙 콘텐츠를 다운로드합니다. 상태 확인은 테스트 URL에 요청을 보내 기존 노드의 사용 가능 여부를 판단합니다. 상태 확인을 600초로 설정해도 10분마다 구독이 다운로드되는 것은 아닙니다. 반대로 구독을 하루에 한 번 업데이트해도 노드 상태를 10분마다 확인하는 데는 지장이 없습니다.

노드 100개가 포함된 provider에서는 지나치게 짧은 상태 확인 주기가 많은 동시 요청을 발생시킬 수 있습니다. 600초 또는 900초부터 시작하고 기기 전력 소비와 노드 수에 따라 조정하세요. 지연 시간 테스트 URL은 가벼운 응답을 반환해야 하며 실제 출구의 연결성을 대표할 수 있어야 합니다.

수동 강제 업데이트의 올바른 절차

강제 업데이트의 목적은 새 설정을 받아 실제로 로드되었는지 확인하는 것이지, 진행 아이콘이 돌아가는지만 보는 것이 아닙니다. 다음 순서를 따르면 중복 요청, 캐시 오판과 기존 연결의 간섭을 함께 피할 수 있습니다.

1. 클라이언트 로그를 열고 현재 설정 이름, 업데이트 시각과 커널 상태를 기록하세요.
2. 진행 중인 중복 업데이트를 중지하고 대상 설정의 업데이트 버튼은 한 번만 클릭하세요.
3. 요청이 완료될 때까지 기다린 뒤 로그에서 최종 HTTP 상태와 파싱 결과를 확인하세요.
4. 설정 카드의 업데이트 시각이 바뀌었는지, 노드 수와 정책 그룹이 예상과 일치하는지 확인하세요.
5. 새 설정을 명확히 선택한 뒤 「설정 다시 불러오기」를 실행하거나 커널을 다시 시작하세요.
6. 정책 그룹의 노드를 다시 선택하고, 확인하려는 애플리케이션의 연결을 끊었다가 다시 여세요.
7. 연결 테스트 페이지에 접속하거나 연결 로그를 확인하여 새 연결이 예상한 규칙과 출구를 사용했는지 확인하세요.

업데이트는 성공했지만 노드 목록이 바뀌지 않는다면 먼저 서버 콘텐츠가 실제로 변경되었는지 비교하세요. HTTP 캐시가 304 Not Modified를 반환할 수 있는데, 이는 클라이언트가 보유한 버전이 여전히 유효하다고 판단되었다는 뜻이지 네트워크 실패가 아닙니다. 서버 콘텐츠가 바뀌었는데도 클라이언트가 계속 이전 콘텐츠를 사용한다면 해당 원격 설정을 삭제한 뒤 다시 가져오세요. 작업 전에 로컬 덮어쓰기, 정책 그룹 선택과 사용자 규칙을 저장해야 합니다.

설정을 전환해도 기존 TCP 또는 UDP 세션이 모두 자동으로 이전되는 것은 아닙니다. 브라우저의 장시간 연결, 다운로드 작업과 메신저 연결은 기존 출구를 계속 사용할 수 있습니다. 확인할 때는 해당 애플리케이션의 연결을 끊고 필요하면 앱을 다시 시작하세요. 같은 장시간 연결만 새로 고치는 것으로는 충분하지 않습니다.

계속 실패할 때 남겨야 할 진단 정보

위의 점검을 마친 뒤에도 업데이트할 수 없다면 최소한의 진단 기록을 정리하세요. 클라이언트 이름과 버전, Mihomo 커널 버전, 운영체제 버전, 실패 시각, HTTP 상태 코드, 오류 로그 앞뒤 각 10줄, TUN 사용 여부, 시스템 프록시 주소, 수신 포트와 직접 연결 및 프록시 경로의 테스트 결과를 포함해야 합니다.

구독 주소는 도메인만 남기고 토큰과 쿼리 매개변수는 가리세요. 설정 파일에 인증 정보가 포함되어 있는지도 확인해야 합니다. 특정 네트워크에서만 문제가 발생한다면 가정용 인터넷, 모바일 데이터 또는 회사 네트워크의 비교 결과를 추가하세요. 네트워크를 바꾸자마자 복구된다면 클라이언트를 반복해서 재설치하기보다 DNS, IPv6, 접근 정책과 로컬 게이트웨이를 우선 점검해야 합니다.

전체 진단 순서는 다음과 같이 요약할 수 있습니다. 먼저 로그로 실패 단계를 확인하고, URL 연결 가능성을 테스트한 다음, 반환 콘텐츠와 YAML을 점검하고, 마지막으로 커널 호환성, 자동 업데이트 주기와 설정 재로드를 처리하세요. 이 순서를 따르면 “구독 만료”, “다운로드 실패”, “파싱 실패”와 “설정 미전환”을 서로 다른 문제로 나누어 불필요한 변경을 줄일 수 있습니다.