Clash 구독 실패·파싱 오류 6가지 원인과 점검 방법

구독 문제가 생겼다면 먼저 증상 유형을 구분하자

구독(Subscription)이란 클라이언트가 주기적으로 서비스 제공자가 준 링크에 요청을 보내 노드 정보가 담긴 설정 파일을 받아오고, 이를 바탕으로 정책 그룹을 자동 생성하는 방식입니다. 구독 관련 오류는 대체로 세 가지 증상으로 나뉩니다. 첫째, 가져오기 시점에 바로 오류가 뜨며 클라이언트가 "파싱할 수 없음" 또는 "형식 오류"라고 표시하는 경우. 둘째, 가져오기는 되지만 노드 수가 비정상적인 경우, 예를 들어 갱신 후 노드가 수십 개에서 0개나 극히 적은 수로 줄어드는 경우. 셋째, 가져오기와 노드 목록 표시는 정상인데 연결 후 실제로는 사용이 안 되는 경우입니다. 이 세 가지 증상은 원인이 완전히 다르기 때문에, 클라이언트를 무작정 재설치하거나 "구독 업데이트"만 반복해서는 해결되지 않고 진짜 원인을 오히려 놓치기 쉽습니다. 아래에서는 서버 쪽부터 클라이언트 쪽 순서로 가장 흔한 여섯 가지 원인과 판별 방법을 설명합니다.

원인 1·2: 링크 만료와 트래픽 초과 — 가장 쉽게 놓치는 서버 쪽 문제

구독 링크는 영구히 유효한 인증 수단이 아닙니다. 대부분의 서비스 제공자는 링크에 유효기간을 설정하거나 계정 만료 시점과 연동해둡니다. 링크가 만료되면 서버는 보통 404, 403 또는 빈 내용을 반환하는데, 클라이언트는 정상적인 설정 텍스트를 받지 못했으니 "파싱 실패"라고 표시합니다. 이 오류 메시지는 클라이언트 자체의 문제로 오해하기 쉽지만 원인은 사실 서버 쪽에 있습니다. 판별 방법은 간단합니다. 구독 링크를 브라우저 주소창에 그대로 붙여넣어 접속해보세요. 브라우저에서도 열리지 않거나 정상 텍스트가 아닌 결과가 나온다면 링크가 이미 만료된 것으로 보고 서비스 제공자에게 재발급을 요청해야 합니다.

트래픽 초과는 좀 더 구체적인 증상으로 나타납니다. 구독을 갱신하면 노드 수가 수십 개에서 갑자기 몇 개로, 심지어 0개로 줄어들고, 클라이언트에 안내 메시지가 뜨는 경우도 있습니다(서비스 제공자마다 표현이 다르지만 "트래픽 소진" 또는 "요금제 만료"가 흔한 문구입니다). 트래픽이 다 소진되면 많은 서비스 제공자가 구독 인터페이스의 응답 내용을 정상 노드 목록 대신 안내 문구로 바꿔버리는데, 클라이언트는 이 문구를 설정 파일로 인식해 파싱하려 하니 결과가 비어 있거나 오류가 나는 것입니다. 서비스 제공자의 사용자 패널에 로그인해 트래픽 사용량을 확인하는 것이 이 원인을 가장 확실하게 확인하는 방법입니다.

원인 3·4: 형식 비호환과 UA 차단 — 클라이언트와 서버의 "신원"이 맞지 않는 경우

Clash 계열 설정 파일은 본질적으로 YAML 텍스트이며, 프록시 노드, 정책 그룹, 규칙의 작성 방식을 규정합니다. 코어마다 지원하는 필드 범위가 완전히 같지는 않습니다. 초기 Clash Premium, 커뮤니티가 관리하는 Clash Meta(현재 코어 이름은 mihomo), 그리고 각 GUI 클라이언트에 내장된 파서는 새 필드(특정 프로토콜의 특수 매개변수, 규칙 세트 문법 등)에 대한 호환 진행 속도가 다릅니다. 구독 내용에 비교적 새로운 코어만 인식하는 필드가 쓰여 있는데 현재 클라이언트 버전이 오래됐다면, 파서가 그 한 노드만 건너뛰는 게 아니라 전체 파일을 형식 오류로 판단해버릴 수 있습니다. 이 경우 판별 방법은 더 새로운 클라이언트 버전이나 다른 GUI로 같은 구독 링크를 가져와보는 것입니다. 정상적으로 파싱된다면 버전 호환성 문제로 확인할 수 있으며, 클라이언트를 최신 버전으로 업데이트하면 해결됩니다.

User-Agent(UA) 차단은 또 다른 놓치기 쉬운 원인으로, 증상이 다소 특이합니다. 같은 링크를 브라우저로 접속하면 전체 내용이 보이지만 클라이언트로 가져오면 오류가 나거나 내용이 이상하게 반환됩니다. 원리는 서비스 제공자가 요청 헤더의 User-Agent 값을 보고 요청 출처를 판단해, 클라이언트별(clash, clash-verge, clash-meta, Shadowrocket 등 식별값)로 다른 형식이나 다른 노드 집합을 반환한다는 것인데, 보통 사용량 통계나 클라이언트 전용 최적화가 목적입니다. 서비스 제공자의 적용 로직에 문제가 있거나, 서비스 제공자가 등록해두지 않은 비주류 클라이언트를 쓰고 있다면 비정상 요청으로 오인되어 서비스가 거부되거나 불완전한 내용이 반환될 수 있습니다. 이럴 때는 클라이언트 설정에서 "User-Agent 사용자 지정" 옵션이 있는지 확인하고, clash나 clash-meta 같은 범용 식별값으로 바꾼 뒤 다시 구독을 갱신해보세요.

원인 5·6: 인코딩 오류와 코어 차이 — 텍스트·프로토콜 레벨의 호환 문제

구독 링크가 반환하는 내용은 보통 Base64로 인코딩되어 있으며, 클라이언트는 이를 다운로드한 뒤 먼저 디코딩해서 YAML이나 노드 목록 텍스트로 복원한 다음 파싱합니다. 서비스 제공자가 설정 파일을 생성할 때 사용한 문자 인코딩이 클라이언트가 기대하는 것과 다르면(예: UTF-8이 아닌 인코딩의 노드 메모가 섞여 있는 경우) 디코딩 후 글자가 깨질 수 있습니다. 가벼운 경우 노드 이름이 물음표나 사각형 문자로 표시되고, 심한 경우 해당 줄이 정상적인 노드로 인식되지 못해 통째로 건너뛰어져 전체 노드 수가 예상보다 줄어듭니다. 이 문제의 판별 특징은 "전체가 아니라 일부 노드만 사라진다"는 점이며, 사라진 노드는 대개 이름에 특수 기호나 비표준 문자가 포함된 경우가 많습니다. 점검할 때는 사라진 노드들의 이름 패턴을 살펴보고, 인코딩 문제로 확인되면 대개 서비스 제공자의 수정을 기다리는 수밖에 없으며 클라이언트 쪽에서 안정적으로 우회할 방법은 없습니다.

코어 차이로 인한 문제는 형식 비호환과 비슷하지만 증상이 더 "국지적"입니다. 전체 구독이 파싱 실패하는 게 아니라 비교적 새로운 프로토콜이나 새 매개변수를 쓴 일부 노드만 목록에서 조용히 사라지고 나머지 노드는 정상 표시됩니다. 파서가 인식하지 못하는 프로토콜 유형이나 필드를 만나면 전체 파싱을 실패시키는 대신 그 항목만 건너뛰기 때문인데, 이런 동작은 더 "은밀해서" 서비스 제공자가 노드를 덜 보낸 것으로 오해하기 쉽습니다. 확인 방법은 클라이언트의 코어 버전 번호를 확인하고, 해당 코어의 업데이트 로그나 프로토콜 지원 목록을 대조해 새 프로토콜을 지원하기 시작한 버전을 확인한 뒤, 클라이언트 업그레이드나 코어 교체가 필요한지 판단하는 것입니다.

점검 단계: 10분 안에 구독 실패 원인 특정하기

구독 문제가 생겼을 때 아래 순서대로 하나씩 점검하면 위의 여섯 가지 원인 대부분을 커버할 수 있으며, 보통 고객센터에 문의하지 않고도 문제가 어느 단계에 있는지 스스로 판단할 수 있습니다.

1. 구독 링크를 그대로 복사해 브라우저 주소창에 접속해서 열리는지, 텍스트가 반환되는지 아니면 오류 페이지인지 확인합니다. 이 단계에서 먼저 링크 자체의 만료 여부를 배제합니다.
2. 서비스 제공자의 사용자 패널에 로그인해 현재 요금제의 트래픽 사용량과 만료 시점을 확인해 트래픽 초과나 계정 만료 가능성을 배제합니다.
3. 클라이언트에서 현재 코어 버전을 확인하고 최근 반년 이내 버전인지 확인합니다. 버전이 너무 오래됐다면 먼저 클라이언트를 업그레이드한 뒤 다시 테스트합니다.
4. 클라이언트가 User-Agent 사용자 지정을 지원한다면 clash나 clash-meta 같은 범용 식별값으로 바꾼 뒤 구독을 다시 갱신해봅니다.
5. 갱신 전후 노드 수 변화를 비교합니다. 전부 0개로 줄었다면 트래픽이나 링크 문제, 일부만 사라졌다면 인코딩이나 코어 호환 문제일 가능성이 큽니다.
6. 다른 클라이언트(특히 코어 업데이트가 빠른 GUI)로 같은 링크를 가져와보고, 결과 차이를 통해 문제가 서버 쪽인지 클라이언트 쪽인지 역추적합니다.

구독 갱신 후 설정이 실제로 적용됐는지 확인하는 법

구독 파싱에 오류가 없고 노드 수도 정상이라 해도 설정이 반드시 적용됐다는 뜻은 아닙니다. 일부 클라이언트는 구독 갱신 후 새 정책 그룹을 자동으로 적용하지 않거나, 기존 규칙 세트 캐시가 지워지지 않아 화면상 노드 목록은 새것인데 실제 트래픽은 여전히 이전 설정을 거치는 경우가 있습니다. 구독을 갱신할 때마다 프록시 모드를 한 번 전환(예: "규칙"에서 "글로벌"로 바꾼 뒤 다시 "규칙"으로)하거나 클라이언트 서비스를 직접 재시작한 뒤, 이전에는 접속되지 않던 사이트를 열어 실제로 테스트해보는 것을 권장합니다. 노드 목록의 숫자만 보는 게 아니라 새 설정이 실제로 적용됐는지 직접 확인하는 게 중요합니다.