먼저 어느 단계에서 실패했는지 확인하기
Clash 클라이언트의 ‘구독 업데이트’는 한 단계로 끝나지 않습니다. 업데이트를 누르면 클라이언트가 먼저 설정에 저장된 구독 URL을 읽고, 네트워크 요청으로 원격 콘텐츠를 가져온 다음, 해당 콘텐츠를 Clash 설정으로 해석할 수 있는지 확인합니다. 마지막으로 새 설정으로 로컬 사본을 교체합니다. 어느 단계에서든 실패하면 화면에는 ‘업데이트 실패’만 표시될 수 있지만, 해결 방법은 서로 다릅니다.
점검하기 전에 현재 설정을 삭제하지 마세요. 대부분의 클라이언트는 마지막으로 정상 다운로드한 로컬 사본을 보관하므로 원격 서버를 일시적으로 이용할 수 없어도 이미 불러온 노드와 규칙은 계속 사용할 수 있습니다. 설정을 바로 삭제하면 이 사본까지 잃어 복구 절차가 오히려 늘어납니다.
오류 문구로 원인 범위 좁히기
| 화면 안내 또는 로그 키워드 | 일반적인 의미 | 우선 확인할 항목 |
|---|---|---|
| timeout、deadline exceeded、i/o timeout | 제한 시간 안에 요청이 완료되지 않음 | 네트워크 경로, DNS, 프록시 업데이트 설정 |
| 404、Not Found | 서버에서 해당 구독 주소를 찾을 수 없음 | 링크 만료 여부, 전체 복사 여부 |
| 401、403、Forbidden | 인증 정보가 만료되었거나 서버가 요청을 거부함 | 구독 재발급, 기기 또는 요청 빈도 제한 |
| connection refused | 대상 포트가 연결을 거부했거나 업데이트 요청이 로컬 프록시로 잘못 전달됨 | 7890·7891 등의 포트와 프록시 설정 |
| unexpected EOF、connection reset | 전송 중 연결이 종료됨 | 네트워크 안정성, 중복 요청, 서버 상태 |
| YAML、parse、unmarshal | 콘텐츠는 다운로드했지만 형식을 해석할 수 없음 | 응답 내용이 실제 Clash YAML인지 확인 |
‘다운로드 실패’인지 ‘파싱 실패’인지 확인하기
다운로드 실패라면 로그에 도메인, 연결, 시간 초과 또는 HTTP 상태 코드가 포함되는 경우가 많습니다. 파싱 실패에서는 YAML 줄 번호, 필드명, 형식 불일치 등의 정보가 자주 나타납니다. 예를 들어 요청이 로그인 페이지를 정상적으로 반환하면 HTTP 상태는 200일 수 있지만, 첫 줄이 HTML이므로 클라이언트는 파싱 단계에서 오류를 냅니다.
클라이언트에서 설정 파일을 확인할 수 있다면 방금 다운로드한 콘텐츠의 앞부분을 열어 보세요. 표준 Clash 또는 mihomo 설정에는 보통 proxies, proxy-groups, rules 등의 필드가 포함됩니다. 웹 코드나 오류 메시지, 계정 로그인 페이지만 보인다면 구독 주소가 불러올 수 있는 설정이 아닌 내용을 반환한 것입니다.
mixed-port: 7890
mode: rule
proxies:
- name: Example
type: ss
proxy-groups:
- name: PROXY
type: select
rules:
- MATCH,PROXY위 내용은 구조를 확인하기 위한 간단한 예시일 뿐이므로 실제 구독을 대신해 사용할 수 없습니다. 서비스마다 DNS, 규칙 집합, 상태 확인 및 많은 노드 필드가 추가될 수 있습니다.
Clash 구독 업데이트 시간 초과 해결 순서
시간 초과는 정해진 시간 안에 클라이언트가 완전한 응답을 받지 못했다는 뜻입니다. 구독 도메인을 확인할 수 없거나 직접 연결 경로에 접근할 수 없고, 프록시 노드가 만료되었을 수 있습니다. 또는 ‘프록시를 사용해 업데이트’가 켜져 있지만 현재 프록시 자체가 아직 정상적으로 연결되지 않았을 수도 있습니다. 정해진 순서대로 확인하면 노드를 반복해서 바꾸는 것보다 빠르게 해결할 수 있습니다.
1단계: 직접 연결 업데이트와 프록시 업데이트를 각각 테스트하기
클라이언트마다 메뉴 이름은 조금씩 다릅니다. 일반적으로 ‘설정’ → ‘환경 설정’ → ‘구독’ 또는 설정 화면 오른쪽 상단의 업데이트 메뉴에서 찾을 수 있습니다. ‘프록시를 사용해 업데이트’, ‘프록시를 통해 구독 업데이트’, ‘Proxy Subscription Update’와 같은 항목을 찾아보세요.
- 먼저 ‘프록시를 사용해 업데이트’를 끄고 저장한 뒤 수동으로 한 번 업데이트하세요. 그러면 구독 요청이 현재 시스템의 직접 연결 네트워크를 우선 사용합니다.
- 그래도 시간 초과가 발생하면 해당 설정을 다시 켜고, 정상 작동이 확인된 노드를 선택한 뒤 업데이트를 다시 진행하세요.
- 두 방식을 짧은 시간 안에 계속 전환하지 마세요. 각 테스트가 끝날 때까지 기다리고 어떤 방식이 성공했는지 기록하는 것이 좋습니다.
직접 연결은 실패하지만 프록시 업데이트가 성공한다면 현재 네트워크에서 구독 도메인 접속이 불안정하다는 뜻일 수 있습니다. 직접 연결은 성공하고 프록시 업데이트만 실패한다면 노드, 프록시 그룹 선택 및 로컬 포트를 확인해야 합니다. 두 방식 모두 실패하면 URL, DNS와 서버 상태를 계속 점검하세요.
2단계: 로컬 프록시 포트 확인하기
많은 Clash 클라이언트는 혼합 포트로 7890을 기본 사용합니다. HTTP 포트는 보통 7890, SOCKS5 포트는 보통 7891이지만 설정에 따라 변경할 수 있습니다. 운영체제, 브라우저 또는 다른 다운로드 도구가 이미 종료된 포트를 계속 가리키고 있다면 구독 요청에서 connection refused가 발생할 수 있습니다.
- 클라이언트의 ‘설정’ → ‘네트워크 설정’ 또는 ‘포트’에서 현재 Mixed Port, HTTP Port와 SOCKS Port를 확인하세요.
- 시스템 프록시의 호스트가 보통
127.0.0.1로 표시되는지, 포트가 클라이언트의 실제 수신 대기 포트와 일치하는지 확인하세요. - 같은 포트를 사용하는 Clash 클라이언트를 동시에 실행하지 마세요. 포트가 충돌하면 나중에 시작한 클라이언트가 포트를 열지 못할 수 있습니다.
- 방금 포트를 변경했다면 먼저 시스템 프록시를 껐다가 다시 켜서 운영체제에 올바른 주소를 다시 기록하게 하세요.
3단계: DNS와 네트워크 전환 문제 제외하기
회사 네트워크에서 모바일 핫스팟으로, Wi-Fi에서 유선 네트워크로 전환하면 이전 연결과 DNS 캐시가 잠시 남아 있을 수 있습니다. 클라이언트를 완전히 종료하고 네트워크 연결을 끊었다가 다시 연결한 후 클라이언트를 시작해 테스트하세요. 창을 닫는 것만으로는 완전한 종료가 아닐 수 있으므로 시스템 트레이나 메뉴 막대의 프로세스가 끝났는지 확인해야 합니다.
로그에 no such host, server misbehaving 또는 도메인 확인 시간 초과가 표시되면 먼저 일반 웹페이지가 열리는지 확인하세요. TUN 모드를 사용 중이라면 TUN을 잠시 끄고 일반 시스템 프록시만 유지한 상태에서 구독 업데이트를 테스트하세요. TUN을 끈 뒤 정상화된다면 클라이언트를 바로 재설치하지 말고 TUN에서 사용하는 DNS 가로채기, Fake-IP 범위와 nameserver 설정을 확인해야 합니다.
404·401·403 오류가 발생할 때의 해결 방법
HTTP 상태 코드는 요청이 서버에 도달했다는 뜻이므로 이제 핵심은 로컬 포트가 아니라 구독 URL과 서버 인증입니다. 404는 대부분 주소가 존재하지 않는다는 의미이고, 401은 유효한 인증 정보가 없다는 뜻입니다. 403은 서버가 요청을 이해했지만 콘텐츠 제공을 거부했다는 의미입니다.
404: 구독 링크 만료 또는 불완전한 복사
구독 링크에는 토큰, 클라이언트 유형 또는 설정 형식과 같은 긴 경로와 쿼리 매개변수가 포함되는 경우가 많습니다. 메신저의 줄바꿈, 브라우저 주소창의 잘림, 복사 과정에서 마지막 문자가 빠지는 문제로 정상 주소가 404로 바뀔 수 있습니다. 확인할 때는 도메인만 비교하지 말고 https://부터 URL 전체를 문자 단위로 대조하세요.
- 구독 제공업체의 관리 페이지로 돌아가 Clash 또는 mihomo용 구독 주소를 다시 복사하세요.
- 클라이언트의 설정 목록에서 기존 설정의 편집 메뉴를 열고 URL을 교체한 뒤 저장하세요.
- 클라이언트에서 URL 편집을 지원하지 않는다면 원격 설정을 새로 만들고 새 링크를 가져오세요.
- 새 설정이 정상적으로 업데이트되고 노드 전환도 문제없이 되는 것을 확인한 후 만료된 이전 항목을 삭제하세요.
다시 복사한 뒤에도 404가 발생하면 브라우저에서 링크를 직접 열어 결과를 확인하세요. YAML 파일이 다운로드되거나 설정 텍스트가 표시되면 주소를 사용할 수 있다는 뜻입니다. 로그인 페이지, 요금제 페이지 또는 사이트 홈으로 이동한다면 구독 인터페이스가 아닌 관리 페이지 주소를 복사했을 가능성이 있습니다.
401·403: 인증 정보 또는 접근 제한
401은 토큰 만료, 계정 상태 변경 또는 구독 주소 초기화 때문에 발생하는 경우가 많습니다. 403은 인증 문제 외에도 요청 빈도, 접속 네트워크 또는 기기 수 제한으로 발생할 수 있습니다. 이런 문제는 일반적으로 Clash의 프록시 포트를 바꿔도 해결되지 않습니다.
- 서비스 페이지에서 구독 링크를 새로 생성하고, 저장해 둔 예전 주소를 계속 사용하지 마세요.
- 짧은 시간 동안 반복해서 새로고침하지 마세요. 한 번 테스트한 뒤 최소 5분 간격을 두는 것이 좋습니다.
- 계정 유효 기간과 트래픽 상태, 서비스 제공업체가 인터페이스 점검 공지를 발표했는지 확인하세요.
- 브라우저에서는 다운로드되지만 클라이언트에서 403이 반환된다면 먼저 프록시 업데이트를 끄고 외부 IP 제한 여부를 확인해 보세요.
- 직접 연결에서는 403이 반환되지만 프록시 업데이트는 정상이라면 프록시 업데이트를 유지할 수 있습니다. 다만 지연 시간이 크게 변하는 자동 노드보다 안정적인 프록시 그룹을 선택하세요.
200을 반환해도 실패할 때: 설정 형식과 콘텐츠 확인
HTTP 200은 서버가 콘텐츠를 정상적으로 반환했다는 뜻일 뿐, 그 내용이 반드시 Clash 설정이라는 의미는 아닙니다. 웹 오류 페이지, Base64 노드 목록, 다른 클라이언트 전용 형식도 200으로 반환된 뒤 파싱 단계에서 실패할 수 있습니다.
일반적인 파싱 오류 확인하기
| 증상 | 가능한 원인 | 해결 방법 |
|---|---|---|
| 첫 번째 줄 부근에서 YAML 구문 오류 발생 | HTML, JSON 오류 메시지가 반환되었거나 콘텐츠가 잘림 | 원본 응답을 확인하고 올바른 구독 주소를 다시 가져오기 |
| proxies 또는 proxy-groups가 없다는 메시지 | 완전한 Clash 설정이 아닌 구독 | Clash, Clash Meta 또는 mihomo 형식 선택 |
| unknown field 메시지 | 현재 커널이 지원하지 않는 새 필드를 설정에서 사용 | 클라이언트를 업데이트하거나 호환 형식으로 전환 |
| mapping values, bad indentation 메시지 | YAML 들여쓰기 손상 또는 잘못된 수동 편집 | 원격 원본 설정으로 복원하고 탭을 들여쓰기에 사용하지 않기 |
| 다운로드한 콘텐츠가 인코딩된 한 줄 텍스트뿐임 | 범용 Base64 노드 구독일 가능성 | 서비스 페이지에서 Clash 전용 링크 선택 |
mihomo는 이전 Clash 커널보다 규칙 집합, 프록시 제공자와 DNS 필드를 폭넓게 지원합니다. 구독에 mihomo 또는 Clash Meta용이라고 명시되어 있는데 클라이언트가 오래된 커널을 사용한다면 필드를 인식하지 못할 수 있습니다. 먼저 ‘설정’ → ‘커널’ 또는 ‘정보’에서 커널 유형과 버전을 확인한 뒤 알맞은 구독 형식을 선택하세요.
오류를 없애려고 모르는 필드를 함부로 삭제하지 마세요. 일부 필드는 규칙 제공자, DNS 분할 라우팅 또는 노드 상태 확인을 담당하므로 삭제하면 설정이 불러와지더라도 트래픽 경로가 달라질 수 있습니다. 해당 형식을 지원하는 클라이언트로 업그레이드하거나 구독 서비스에서 호환 설정을 생성하는 편이 안전합니다.
자동 업데이트 간격을 합리적으로 설정하는 방법
자동 업데이트는 자주 실행할수록 좋은 것이 아닙니다. 노드와 규칙은 보통 분 단위로 바뀌지 않으므로 간격이 너무 짧으면 중복 요청이 발생하고 서버의 요청 빈도 제한에 걸리기 쉽습니다. 개인 기기에서는 6~24시간이 일반적인 범위입니다.
| 사용 상황 | 권장 간격 | 설명 |
|---|---|---|
| 일상적으로 사용하는 개인용 컴퓨터 | 12시간 | 노드 변경과 요청 빈도의 균형 |
| 가끔 켜는 노트북 | 24시간 | 시작 후 한 번 수동 업데이트하면 보통 충분함 |
| 노드 변경이 잦음 | 6시간 | 몇 분 단위로 더 줄이는 것은 권장하지 않음 |
| 고정 규칙 및 직접 구축한 노드 | 24~72시간 | 설정 변경이 적으므로 업데이트 빈도를 낮출 수 있음 |
| 장애를 점검하는 중 | 자동 업데이트를 일시적으로 끄기 | 자동 작업이 로그와 테스트 결과를 덮어쓰지 않게 하기 |
클라이언트에서 업데이트 간격 설정하기
일반적인 경로는 ‘설정’ 또는 ‘구독’ 페이지로 이동한 뒤 해당 원격 설정의 편집 메뉴를 열고 자동 업데이트 간격을 시간 단위로 지정하는 것입니다. 일부 클라이언트는 초 단위를 사용합니다. 6시간은 21600초, 12시간은 43200초, 24시간은 86400초입니다. 입력란에 분 단위라고 명시되어 있다면 360, 720 또는 1440을 입력하고 단위를 혼용하지 마세요.
설정을 마친 뒤 다음 예약 업데이트 시간이 예상대로 표시되는지 확인하세요. 일부 클라이언트는 프로그램이 실행 중일 때만 예약 업데이트를 수행하므로 컴퓨터가 꺼져 있는 동안 모든 작업을 보충 실행하지 않습니다. 다시 시작한 후 한 번 업데이트하면 충분하며 간격을 지나치게 짧게 설정할 필요는 없습니다.
‘프록시를 사용해 업데이트’를 계속 켜 둬야 할까
켜야 하는지는 구독 도메인에 실제로 접속할 수 있는지에 따라 달라집니다. 직접 연결이 장기간 안정적이라면 프록시 업데이트를 끄는 편이 간단하고, 현재 노드가 작동하지 않아 구독 새로고침이 막히는 문제도 피할 수 있습니다. 구독 주소가 반드시 프록시를 거쳐야 하거나 직접 연결에서 자주 시간 초과가 발생할 때만 켜 두는 것이 좋습니다.
- 직접 연결 업데이트가 안정적임: ‘프록시를 사용해 업데이트’를 끄고 자동 간격을 12시간 또는 24시간으로 설정하세요.
- 직접 연결은 시간 초과지만 프록시는 안정적임: 프록시 업데이트를 켜고 안정적인 프록시 그룹을 통해 업데이트 트래픽을 보내세요.
- 네트워크를 자주 변경함: 직접 연결을 우선 사용하고, 실패할 때만 수동으로 프록시 업데이트로 전환하세요.
- 현재 모든 노드를 사용할 수 없음: 프록시 업데이트를 꺼서 요청이 작동하지 않는 프록시로 전달되지 않게 하세요.
수정 후 설정이 실제로 적용되었는지 확인하는 방법
화면에 ‘업데이트 성공’이 표시되는 것은 새 파일이 저장되었다는 뜻일 뿐입니다. 클라이언트가 실제로 해당 파일을 불러왔는지도 확인해야 합니다. 일부 클라이언트는 다운로드 후 자동으로 전환하지만, 일부는 이전 설정을 계속 사용하므로 새 항목을 수동으로 선택해야 합니다.
- 설정 목록에서 ‘마지막 업데이트’ 시간을 확인해 방금 작업한 시간과 일치하는지 확인하세요.
- 업데이트된 설정을 선택하고 커널이 다시 불러오기를 완료할 때까지 기다리세요.
- 프록시 페이지로 이동해 노드 수, 프록시 그룹 이름 또는 규칙이 예상대로 변경되었는지 확인하세요.
- 자주 사용하는 노드의 지연 시간을 한 번 테스트하세요. 지연 시간은 테스트 주소에 접근할 수 있는지만 보여 주며 모든 웹사이트에 접속할 수 있다는 뜻은 아닙니다.
- ‘규칙 모드’를 유지한 채 직접 연결되어야 하는 대상과 프록시를 사용해야 하는 대상을 각각 방문해 트래픽 분할 결과를 확인하세요.
- 실행 로그에서 파싱 오류, DNS 순환 또는 연결 거부가 계속 발생하지 않는지 확인하세요.
계속 실패할 때 확인할 최종 체크리스트
- 구독 URL을 서비스 페이지에서 다시 복사했으며 앞뒤에 공백, 줄바꿈 또는 누락된 문자가 없는지 확인하세요.
- 브라우저에서 주소를 열었을 때 로그인 페이지가 아니라 설정 텍스트가 반환되거나 파일이 다운로드되는지 확인하세요.
- 직접 연결 업데이트와 프록시 업데이트를 각각 테스트했는지, 한 경로만 반복해서 시도한 것은 아닌지 확인하세요.
- 시스템 프록시 포트가 클라이언트의 실제 수신 대기 포트와 일치하는지, 7890 또는 7891을 다른 프로그램이 사용하고 있지 않은지 확인하세요.
- TUN을 끈 뒤 업데이트되는지 확인하세요. 가능하다면 DNS 가로채기와 TUN 스택 설정을 계속 점검해야 합니다.
- 구독 형식이 Clash, Clash Meta 또는 mihomo 커널과 일치하는지 확인하세요.
- 자동 업데이트 간격이 너무 짧지 않은지, 연속 요청으로 403 또는 일시적인 제한이 발생하지 않았는지 확인하세요.
- 업데이트 성공 후 새 설정을 수동으로 선택했으며 커널이 다시 불러오기를 완료했는지 확인하세요.
구독 장애를 가장 효과적으로 점검하려면 먼저 상태 코드에 따라 네트워크, 인증과 형식 문제를 구분한 다음 직접 연결과 프록시라는 두 업데이트 경로를 비교하세요. 시간 초과는 네트워크와 프록시 업데이트 설정을 우선 확인하고, 404는 전체 링크를 다시 발급받으며, 401 또는 403은 인증과 요청 빈도를 확인해야 합니다. 파싱 오류가 발생하면 반환된 콘텐츠와 커널 형식을 점검하세요. 자동 업데이트를 6~24시간으로 설정하고 최근에 정상 작동한 설정을 보관하면 반복 장애의 영향을 줄이는 데 도움이 됩니다.