먼저 어느 단계에서 실패했는지 확인하기
Clash 클라이언트가 구독을 업데이트할 때는 먼저 구독 주소에 접속해 서버 응답을 받은 다음, 그 내용을 설정 파일로 파싱합니다. 프록시 노드·규칙·DNS 설정을 불러오는 것은 마지막 단계입니다. 화면에 같은 '업데이트 실패'로 표시되어도 연결 시간 초과, 비정상 HTTP 상태, 잘못된 응답 내용, YAML 파싱 실패 등 원인은 다를 수 있습니다.
점검할 때 현재 설정을 먼저 삭제하지 마세요. 계속 사용할 수 있는 설정 사본을 남겨 둔 뒤 업데이트 알림과 실행 로그를 확인해야 합니다. 일부 클라이언트는 구독 카드 옆에 다운로드 오류를 표시하고, 다른 클라이언트는 로그에만 전체 원인을 기록합니다. 일반적인 경로는 '구독' → '설정 카드' → '업데이트'이며, 로그는 보통 '설정' → '로그' 또는 '로그' → '코어 로그'에서 확인할 수 있습니다.
| 화면 또는 로그 메시지 | 일반적으로 해당하는 단계 | 우선 확인할 항목 |
|---|---|---|
| timeout、deadline exceeded | 연결을 설정하거나 응답을 기다리는 중 시간 초과 | 네트워크 경로, 시스템 프록시, DNS, 서버 부하 |
| 404 Not Found | 구독 경로가 존재하지 않음 | 주소 전체 여부, 토큰 만료 여부, 요금제 초기화 여부 |
| 401 또는 403 | 인증 거부 | 토큰, 계정 상태, 요청 빈도 및 출처 제한 |
| unexpected end、EOF | 응답이 중단되었거나 파일이 불완전함 | 네트워크 불안정, 게이트웨이 제한, 서버 생성 작업 |
| yaml、parse、unmarshal | 설정 파싱 실패 | 응답 형식, 들여쓰기, 필드 유형 및 클라이언트 호환성 |
| 업데이트는 성공했지만 노드가 0개 | 내용은 유효하지만 불러올 수 있는 프록시가 없음 | 구독 유형, 계정에서 사용할 수 있는 노드, 변환 템플릿 |
구독 가져오기 시간 초과 단계별 점검
1단계: 구독 도메인에 연결할 수 있는지 확인
시간 초과가 곧 노드 오류를 뜻하는 것은 아닙니다. 구독 다운로드와 프록시 노드 연결은 서로 다른 경로입니다. 전자는 구독 서비스 도메인에 접속하고, 후자는 설정에 등록된 프록시 서버에 연결합니다. 현재 노드로 웹 페이지를 열 수 있어도 DNS, 라우팅 또는 서버 장애 때문에 구독 도메인에는 연결하지 못할 수 있습니다.
- 실패 시각을 기록하고 60초 간격으로 수동 업데이트를 두 번 연속 시도해 일시적인 불안정을 배제하세요.
- 한 번 네트워크를 전환하세요. 예를 들어 가정용 인터넷에서 모바일 핫스팟으로 바꾼 뒤 다시 업데이트합니다.
- 시스템 프록시를 끈 상태와 현재 프록시를 유지한 상태를 각각 테스트하세요. 일부 구독 도메인은 직접 연결이 필요하지만, 다른 네트워크 환경에서는 기존 프록시를 통해 접속해야 할 수 있습니다.
- 기기의 날짜, 시간, 시간대를 확인하세요. 시간 오차가 크면 다운로드 전에 TLS 연결이 종료될 수 있습니다.
- 로그에서 대상 도메인과 오류가 발생한 단계를 확인하세요. DNS 조회 시간 초과와 TCP 연결 시간 초과는 별도로 처리해야 합니다.
시스템 프록시를 끈 뒤 업데이트된다면 구독 도메인이 사용할 수 없는 노드로 잘못 할당되지 않았는지 확인하세요. 규칙에서 해당 도메인을 직접 연결로 지정하거나 업데이트 중에 일시적으로 DIRECT를 선택할 수 있습니다. 프록시를 켜야만 업데이트된다면 새 설정을 검증하기 전까지 덮어쓰지 말고 안정적인 설정을 업데이트 경로로 유지하세요.
2단계: DNS 시간 초과와 연결 시간 초과 구분
로그에 'no such host', 'DNS lookup failed' 또는 DNS를 가리키는 'i/o timeout'이 나타나면 먼저 Clash의 DNS 모듈을 확인하세요. mihomo 코어를 사용할 때는 nameserver, proxy-server-nameserver, nameserver-policy의 역할도 구분해야 합니다. 프록시 서버 도메인을 해석하지 못하면 구독 다운로드와 노드 연결 모두 영향을 받을 수 있습니다.
- TUN 모드를 일시적으로 끈 뒤 다시 시도해 트래픽이 TUN, 시스템 프록시, 로컬 DNS 사이에서 순환하는지 확인하세요.
- 로컬 수신 포트가 충돌하지 않는지 확인하세요. 일반적인 mixed-port는 7890, HTTP 포트도 7890, SOCKS 포트는 7891인 경우가 많지만 실제 값은 현재 설정을 기준으로 해야 합니다.
- 시스템에서 패킷 캡처 도구, 다른 프록시 클라이언트 또는 VPN을 함께 실행 중이라면 그중 하나를 완전히 종료한 뒤 Clash 코어를 다시 시작하세요.
- DNS 설정을 변경한 뒤에는 코어를 한 번 재시작하세요. 프록시 그룹만 전환하면 전체 DNS 상태가 다시 구성되지 않을 수 있습니다.
3단계: 다운로드 대기 시간 적절히 조정
클라이언트에서 구독 시간 초과를 설정할 수 있다면 10초를 일시적으로 30초로 늘려 확인하세요. 30초를 넘어도 계속 실패한다면 몇 분까지 더 늘려도 경로 문제는 보통 해결되지 않습니다. 합리적인 테스트 값은 연결 대기 10초, 전체 다운로드 시간 30초이며 HTTP 리디렉션을 허용하는 것입니다.
데스크톱에서는 명령어로 응답 상태를 확인할 수 있습니다. 먼저 터미널에서 read -s SUB_URL을 실행하고 구독 주소를 붙여 넣은 다음 Enter를 누르고, 이어서 아래 명령을 실행하세요. 이렇게 하면 토큰이 명령 기록에 직접 남을 가능성을 줄일 수 있습니다.
curl -L \
--connect-timeout 10 \
--max-time 30 \
-D headers.txt \
-o profile.yaml \
"$SUB_URL"
wc -c profile.yaml
head -n 8 headers.txt종료 코드 0은 다운로드 과정이 완료되었다는 뜻일 뿐, 내용이 반드시 Clash 설정이라는 의미는 아닙니다. HTTP 상태, 파일 크기, 콘텐츠 유형을 계속 확인하세요. 정상적인 설정에는 일반적으로 proxies, proxy-providers, proxy-groups, rules 중 일부가 포함됩니다.
404, 401 또는 403 응답 처리 방법
404: 주소 경로 또는 구독 토큰이 변경됨
404는 서버에 연결할 수 있지만 현재 경로가 존재하지 않는다는 뜻입니다. 가장 흔한 원인은 복사 과정에서 쿼리 매개변수가 빠졌거나, 구독 토큰이 초기화되었거나, 이전 주소 제공이 중단되었거나, 채팅 앱이 주소의 특수 문자를 잘라낸 경우입니다. 도메인만 비교하지 말고 프로토콜부터 마지막 문자까지 전체 주소를 비교해야 합니다.
- 구독 서비스 제어판으로 돌아가 Clash 또는 Clash Meta에 맞는 구독 주소를 다시 복사하세요.
- 클라이언트에서 실패한 항목을 삭제한 뒤 다시 붙여 넣어 이전 항목이 캐시된 주소를 계속 참조하지 않도록 하세요.
- 주소 앞뒤에 공백, 줄바꿈, 한국어·중국어 인용 부호가 없는지 확인하세요.
- 서버에서 방금 토큰을 초기화했다면 이전 주소는 무효로 간주해야 하며 모든 기기에서 주소를 업데이트해야 합니다.
- 2~5분 기다린 뒤 다시 시도하세요. 일부 서비스는 설정을 다시 생성하거나 엣지 캐시를 동기화하는 데 시간이 필요합니다.
브라우저에서 주소를 열어 다운로드된다고 해서 클라이언트에서도 반드시 성공하는 것은 아닙니다. 일부 서비스는 User-Agent에 따라 다른 형식을 반환하거나 특정 요청 헤더를 요구할 수 있습니다. 반대로 브라우저에 웹 페이지가 표시된다고 구독이 만료된 것도 아닙니다. 서버가 일반 브라우저 요청을 안내 페이지로 보낼 수 있기 때문입니다. 클라이언트 로그의 상태 코드와 실제 응답 내용을 기준으로 판단하세요.
401 및 403: 인증 또는 접근 정책에 의해 거부됨
401은 보통 토큰이 유효하지 않거나 누락되었다는 뜻이고, 403은 계정 상태, 출처 주소, 접근 빈도 또는 서버 정책 때문에 현재 요청이 허용되지 않는 경우가 많습니다. 먼저 서비스 패널에 로그인해 계정과 구독 상태를 확인한 뒤 주소를 다시 생성하세요. 짧은 시간에 업데이트를 수십 번 연속 클릭하면 서버의 요청 제한이 발동할 수 있으므로 10~30분 동안 요청을 중지해야 합니다.
다운로드는 성공했지만 내용이 비어 있거나 파싱할 수 없음
먼저 응답이 YAML인지 Base64인지 HTML인지 확인
클라이언트가 HTTP 200을 받아도 업데이트에 실패할 수 있습니다. 서버가 로그인 페이지, 오류 안내, 빈 파일, 다른 클라이언트용 범용 Base64 노드 목록 또는 현재 클라이언트가 지원하지 않는 필드를 반환할 수 있습니다. 다운로드한 파일이 수십 바이트에 불과하거나 시작 부분에 <!DOCTYPE html>, <html>이 나타난다면 설정 파일이 아닌 내용을 받은 것입니다.
Clash 설정은 일반적으로 YAML 형식입니다. 노드는 proxies 아래에 직접 작성하거나 proxy-providers를 통해 원격 제공자를 참조할 수 있습니다. 다른 클라이언트 형식의 링크만 포함된 텍스트는 완전한 Clash 설정으로 바로 불러올 수 없습니다. 서버 패널에 클라이언트 유형을 선택하는 옵션이 있다면 코어에 맞는 Clash 또는 mihomo 형식을 선택하세요.
YAML 들여쓰기와 필드 유형 확인
YAML은 공백으로 계층을 표시하므로 같은 계층에서 탭을 섞어 사용할 수 없습니다. 흔한 오류로는 포트가 숫자가 아닌 텍스트로 작성된 경우, 존재하지 않는 노드를 프록시 그룹이 참조하는 경우, 규칙 제공자에 behavior가 빠진 경우, 이전 코어가 새 필드를 인식하지 못하는 경우가 있습니다. 클라이언트와 mihomo 코어를 업데이트한 뒤 다시 불러오면 버전이 너무 오래되어 발생한 호환성 문제를 배제할 수 있습니다.
proxy-providers:
remote-main:
type: http
url: "https://sub.example.net/client/REDACTED"
path: ./providers/remote-main.yaml
interval: 21600
health-check:
enable: true
interval: 600
url: "https://www.gstatic.com/generate_204"위 예시의 interval: 21600은 제공자를 21600초마다, 즉 6시간마다 업데이트한다는 뜻입니다. 상태 확인의 interval: 600은 10분마다 노드 사용 가능 여부를 테스트한다는 뜻입니다. 두 설정의 용도는 다릅니다. 상태 확인은 구독을 다시 다운로드하지 않으며, 구독 업데이트도 지속적인 노드 점검을 대신하지 않습니다.
업데이트 성공 후에도 노드 수가 0개인 경우
노드가 0개라면 먼저 원본 응답을 확인해 서버가 실제로 프록시 항목을 반환했는지 확인하세요. 계정 만료, 트래픽 소진, 지역 필터 결과 없음, 변환 템플릿 오류로 인해 구조는 유효하지만 노드가 없는 설정이 생성될 수 있습니다. 설정에 규칙과 프록시 그룹만 있고 proxies 또는 사용할 수 있는 proxy-providers가 없다면 클라이언트가 노드를 자동으로 만들어 낼 수 없습니다.
프록시 그룹의 참조 관계도 확인해야 합니다. 설정에 노드가 있어도 프록시 그룹의 use가 잘못된 provider 이름을 가리키면 화면에 빈 그룹으로 표시될 수 있습니다. 이름은 대소문자를 구분하므로 remote-main과 Remote-Main은 서로 다른 식별자로 취급해야 합니다.
자동 업데이트 간격은 얼마나 설정해야 할까
자동 업데이트는 자주 할수록 좋은 것이 아닙니다. 구독 내용은 보통 몇 분 단위로 바뀌지 않으며, 잦은 요청은 서버 부하를 높이고 요청 제한을 유발하기 쉽습니다. 개인 기기에서는 6~24시간이 안정적인 범위입니다. 서버 복구를 기다리는 동안에는 주기를 60초로 바꾸기보다 수동 업데이트를 한 번 실행하세요.
| 사용 상황 | 권장 간격 | 초 |
|---|---|---|
| 노드 변경이 잦은 일상용 기기 | 6시간 | 21600 |
| 일반 데스크톱 및 스마트폰 | 12시간 | 43200 |
| 장기간 안정적으로 사용하는 가정용 기기 | 24시간 | 86400 |
| 일시적인 문제 해결 | 자동 재시도 끄기, 필요할 때 수동 업데이트 | 해당 없음 |
그래픽 클라이언트의 설정 위치
클라이언트마다 '설정'과 '구독'의 명칭이 통일되어 있지 않습니다. 일반적인 경로는 '구독' → '설정 선택' → '편집' → '업데이트 간격' 또는 '설정' → '구독 카드 메뉴' → '자동 업데이트'입니다. 일부 클라이언트는 시간을 기준으로 입력하므로 6은 6시간을 의미하고, 다른 클라이언트는 분 단위이므로 6시간에 360을 입력해야 합니다. 저장하기 전에 입력란 뒤의 단위를 반드시 확인하세요.
Clash Verge Rev 같은 mihomo 그래픽 클라이언트는 보통 원격 설정을 '구독' 페이지에 모아 둡니다. 업데이트 간격을 변경한 뒤 구독 설정을 먼저 저장하고, 수동 업데이트를 한 번 실행해 업데이트 시각을 확인하세요. 구버전 Clash for Windows는 새 클라이언트와 메뉴 이름이 다르므로 Profiles 페이지에서 원격 설정 항목과 업데이트 옵션을 확인해야 합니다. 화면에 간격 설정이 없다면 백그라운드에서 자동 업데이트될 것이라고 바로 단정하지 마세요.
mihomo 설정의 두 가지 interval
설정을 직접 작성할 때 가장 헷갈리기 쉬운 부분은 제공자 업데이트 주기와 상태 확인 주기입니다. proxy-providers 항목 아래의 최상위 interval은 원격 파일을 다시 다운로드하는 주기를 제어하고, health-check 아래에 중첩된 interval은 연결 상태 테스트 주기를 제어합니다. 전자는 21600~86400초, 후자는 보통 300~900초가 적절합니다.
상태 확인을 지나치게 자주 실행하면 추가 연결이 발생합니다. 노드가 많을 때 30초마다 검사하면 순간적인 동시 연결과 배터리 소모가 커질 수 있습니다. 모바일 기기에서는 상태 확인을 600초 이상으로 설정하고 실제 사용하는 provider에만 켜는 것이 좋습니다. 구독 업데이트 실패는 상태 확인 간격을 조정해도 해결되지 않습니다.
TUN 모드, 시스템 프록시와 구독 업데이트의 관계
TUN을 켜면 클라이언트가 더 많은 시스템 트래픽을 처리할 수 있지만, 구독 요청은 여전히 그래픽 인터페이스 프로세스나 코어가 직접 보낼 수 있습니다. 클라이언트마다 구현이 달라 요청이 현재 프록시 그룹을 반드시 따르는 것은 아닙니다. '브라우저는 열리는데 클라이언트 업데이트는 시간 초과'인 경우 인터페이스 프로세스가 시스템 프록시를 사용하는지, 구독 도메인이 규칙에 매칭되는지, TUN 라우팅이 순환하는지를 중점적으로 확인하세요.
- TUN을 끄고 시스템 프록시는 유지한 상태에서 업데이트를 한 번 테스트하세요.
- 시스템 프록시를 끄고 TUN만 유지한 상태에서 업데이트를 한 번 테스트하세요.
- 둘 다 끄고 구독 요청을 직접 연결로 보내 업데이트를 한 번 테스트하세요.
- 원래 설정을 복원한 뒤 코어를 재시작하고, 로그에 포트 사용 중이나 라우팅 설치 실패가 없는지 확인하세요.
위 테스트에서는 매번 변수 하나만 변경하세요. DNS, 프록시 모드, TUN, 구독 주소를 동시에 수정하면 업데이트가 다시 작동해도 실제 원인을 판단할 수 없습니다. 테스트 중에는 규칙 모드를 유지하고 구독 도메인에만 DIRECT 또는 안정적인 프록시 그룹을 지정할 수 있습니다.
반복 실행할 수 있는 문제 해결 순서
- 이전 설정 보존:계속 사용할 수 있는 설정을 먼저 내보내고 바로 덮어쓰지 마세요.
- 전체 오류 확인:상태 코드, 대상 도메인, 발생 시각과 로그 키워드를 기록하세요.
- 주소 확인:구독 URL을 다시 복사해 공백, 잘림, 만료된 토큰을 배제하세요.
- 네트워크 전환:현재 네트워크와 모바일 핫스팟에서 각각 테스트하세요.
- 요청 경로 전환:직접 연결, 시스템 프록시, TUN 상태를 차례로 테스트하세요.
- 응답 확인:HTTP 상태, 파일 크기, YAML 콘텐츠인지 여부를 확인하세요.
- 설정 검증:proxies, proxy-providers, 프록시 그룹 참조와 YAML 들여쓰기를 확인하세요.
- 코어 확인:클라이언트가 지원하는 mihomo 코어 버전으로 업데이트한 뒤 다시 불러오세요.
- 적절한 주기 설정:일상적인 사용에서는 6시간, 12시간 또는 24시간으로 설정하고 분 단위 업데이트는 피하세요.
- 마지막으로 서버에 문의:실패 시각, 상태 코드와 개인정보를 가린 로그를 제공하고 전체 구독 토큰은 보내지 마세요.
업데이트가 복구된 뒤 추가로 확인할 항목
구독이 성공적으로 업데이트되었다고 표시되면 먼저 업데이트 시각, 노드 수와 프록시 그룹이 예상과 일치하는지 확인한 뒤 새 설정으로 전환하세요. 노드 하나를 선택해 지연 시간을 테스트하고 자주 사용하는 사이트에 접속해 규칙 분할이 정상인지 확인합니다. 노드는 있지만 모든 연결이 실패한다면 문제는 '구독 다운로드'에서 '노드 연결'로 넘어간 것이므로 구독 업데이트를 반복하지 말고 연결 로그를 확인해야 합니다.
마지막으로 자동 업데이트 주기를 적절한 값으로 되돌리세요. 문제 해결 중 설정한 짧은 주기는 즉시 해제해 백그라운드에서 요청이 계속 발생하지 않도록 해야 합니다. 데스크톱 클라이언트는 24시간 동안 예정대로 한 번 업데이트되는지 확인할 수 있습니다. 모바일 운영체제는 백그라운드 작업을 제한할 수 있어 절전 정책과 시스템 예약에 따라 자동 업데이트 시각이 달라집니다. 필요하면 클라이언트를 연 뒤 수동 업데이트하세요.
전체 판단 흐름은 주소 유효성, 네트워크 연결, 응답 내용, 설정 파싱, 프록시 그룹 참조, 노드 연결을 차례로 확인하는 것입니다. 이 여섯 단계를 따라가면 클라이언트를 반복해서 삭제하거나 업데이트를 연속 클릭하는 것보다 문제를 쉽게 찾을 수 있습니다.