Clash 구독 업데이트 실패 해결법: 흔한 오류 원인과 자동 업데이트 간격 설정
구독 링크 만료, UA 차단, DNS 오염, 프록시 루프 등 Clash 구독 업데이트 실패 원인을 점검하고 FlClash의 자동 업데이트 간격과 업데이트 프록시 권장 설정을 안내합니다.
먼저 실패가 발생한 계층을 구분하기
Clash 또는 FlClash에 “구독 업데이트 실패”가 표시되더라도 문제의 원인이 반드시 구독 서비스 자체에 있는 것은 아닙니다. 한 번의 업데이트는 최소 네 단계를 거칩니다. 클라이언트가 구독 URL을 읽고, 시스템 또는 mihomo가 도메인을 해석한 다음, 직접 연결이나 프록시를 통해 HTTPS 연결을 수립하고, 설정 내용을 다운로드해 파싱합니다. 어느 한 단계에서든 중단되면 화면에는 짧은 오류 메시지만 표시될 수 있습니다.
점검하기 전에 세 가지 정보를 기록하세요. 실패가 발생한 정확한 시간, 화면이나 로그에 표시된 전체 오류 메시지, 현재 네트워크 환경입니다. 가정용 인터넷에서는 되지만 모바일 핫스팟에서는 실패한다면 네트워크나 DNS 문제일 가능성이 큽니다. 브라우저에서는 링크가 열리지만 클라이언트에서 403이 반환된다면 요청 헤더나 접근 정책을 확인해야 합니다. 다운로드는 성공했지만 설정이 유효하지 않다는 메시지가 나오면 응답 내용과 YAML 구조를 점검하세요.
상태 코드로 빠르게 원인 좁히기
401 Unauthorized: 유효한 인증 정보가 필요합니다. 토큰이 만료되었을 수 있습니다.403 Forbidden: 서버가 요청을 거부했습니다. User-Agent, 발신 IP 또는 접근 빈도가 정책에 맞지 않는 경우가 흔합니다.404 Not Found: URL 경로가 존재하지 않습니다. 기존 구독 주소가 변경되었을 수 있습니다.429 Too Many Requests: 짧은 시간에 요청이 너무 많이 발생했습니다. 수동 업데이트를 중지하고 자동 업데이트 간격을 늘리세요.5xx: 구독 서버 또는 upstream 게이트웨이에 문제가 있습니다. 다른 네트워크에서 다시 테스트한 뒤 복구를 기다리세요.timeout,connection reset: 연결 수립 또는 데이터 전송 중 연결이 끊겼습니다. DNS, 라우팅, 업데이트 프록시를 계속 점검하세요.invalid character,yaml: unmarshal errors: 응답은 받았지만 클라이언트가 읽을 수 있는 Clash YAML 형식이 아닙니다.
구독 링크, 유효 기간, 응답 내용 확인하기
구독 URL에는 보통 긴 접근 토큰이 포함됩니다. 복사 과정에서 끝부분이 누락되거나, 메신저가 링크를 자동으로 잘라내거나, 주소에 줄바꿈이 섞이면 서버에서 오류를 반환할 수 있습니다. 구독 서비스 제공업체의 관리 화면에서 완전한 URL을 다시 복사한 뒤 FlClash의 설정 목록에서 해당 구독을 편집하세요. 기존 주소를 반복해서 수정하는 방법은 피하는 것이 좋습니다.
브라우저에서 열린다고 해서 내용이 올바른 것은 아닙니다
브라우저에서 구독 링크를 열었을 때 YAML, Base64 텍스트 또는 서버가 클라이언트 유형에 맞춰 생성한 설정이 표시되어야 합니다. 로그인 화면, 캡차, HTML 오류 페이지 또는 JSON 오류 메시지가 표시된다면 클라이언트가 다운로드를 완료했더라도 이를 Clash 설정으로 불러올 수 없습니다. 응답 시작 부분에 <!doctype html> 또는 <html이 보이면 웹 페이지를 받은 것으로 보는 것이 거의 확실합니다.
데스크톱 시스템에서는 명령어로 상태 코드와 응답 헤더를 확인할 수 있습니다. 실행할 때 토큰이 포함된 전체 출력 내용을 공개 채널에 공유하지 마세요:
curl -L --connect-timeout 10 --max-time 30 \
-A "clash.meta" \
-o subscription.yaml \
-w "HTTP=%{http_code} SIZE=%{size_download} TIME=%{time_total}\n" \
"https://example.invalid/subscription/token"정상적인 경우 HTTP=200이 반환되어야 하며 파일 크기가 0이어서는 안 됩니다. 수십 개의 노드와 규칙이 포함된 설정은 보통 수 KB 이상입니다. 200~500바이트만 다운로드된다면 파일을 열어 오류 안내문인지 확인하세요. 명령어의 도메인은 형식 예시일 뿐이므로 실제 테스트에는 자신의 구독 주소를 사용해야 합니다.
설정 형식과 클라이언트 호환성 확인하기
- FlClash에서 mihomo 커널을 사용할 때는 Clash, Clash Meta 또는 mihomo 형식을 우선 선택하세요.
vmess://,ss://같은 공유 링크만 포함된 일반 텍스트는 완전한 설정으로 바로 불러오지 못할 수 있습니다.- 설정에서
rule-providers를 참조한다면 규칙 세트 URL에도 접근할 수 있어야 합니다. 기본 구독 업데이트가 성공했다고 해서 원격 규칙 세트 동기화까지 성공한 것은 아닙니다. - 서비스에서 “일반 구독”과 “Clash 구독”을 별도로 제공한다면 Clash 또는 mihomo라고 명확히 표시된 항목을 선택하세요.
User-Agent 차단과 요청 빈도 제한 처리하기
일부 구독 서비스는 User-Agent에 따라 다른 형식을 반환하거나 식별된 클라이언트만 허용합니다. 브라우저는 Chrome, Safari 등의 식별자를 사용하지만 FlClash 또는 mihomo는 다른 식별자를 보낼 수 있어 “브라우저에서는 정상 다운로드되지만 클라이언트에서는 403이 반환되는” 차이가 발생합니다.
요청 헤더 비교 테스트
일반적인 브라우저 식별자와 mihomo 식별자를 각각 사용해 같은 주소에 요청하고 HTTP 상태 코드, 파일 크기, 응답 유형을 비교할 수 있습니다. 특정 식별자에서만 200이 반환된다면 서버에 요청 헤더 규칙이 있다는 뜻입니다.
curl -L -A "clash.meta" -D headers-meta.txt \
-o profile-meta.yaml "https://example.invalid/subscription/token"
curl -L -A "Mozilla/5.0" -D headers-browser.txt \
-o profile-browser.yaml "https://example.invalid/subscription/token"해결 방법은 먼저 구독 서비스의 클라이언트 유형 옵션을 확인하고 Clash에 맞는 주소를 다시 생성하는 것입니다. FlClash 현재 버전에서 구독 요청 헤더 설정을 제공한다면 구독 편집 화면에서 서비스 제공업체가 명시한 User-Agent를 입력하세요. 별도 요구 사항이 없다면 여러 식별자를 무작정 연속해서 입력하는 것은 권장하지 않습니다.
429와 과도한 자동 새로고침
업데이트 버튼을 연속으로 수동 클릭하거나, 여러 기기에서 같은 구독을 공유하거나, 간격을 5분으로 설정하면 빈도 제한이 발생할 수 있습니다. 구독 내용은 보통 매분 바뀌지 않습니다. 개인 기기는 24시간을 기본 간격으로 두는 것이 안정적이며, 노드 변경이 잦다면 6시간으로 설정할 수 있습니다. 1시간으로 줄이는 것은 서비스 제공업체가 명확히 권장할 때만 사용하세요.
| 사용 시나리오 | 권장 간격 | 초 환산 |
|---|---|---|
| 일상적인 개인 기기 | 24시간 | 86400 |
| 노드 변경이 잦은 경우 | 6시간 | 21600 |
| 단기 장애 관찰 | 1시간 | 3600 |
429가 발생하면 최소 15~30분 동안 새로고침을 중지하세요. 계속 클릭하면 제한 시간이 오히려 늘어날 수 있습니다. 여러 기기에서 같은 주소를 사용할 때는 업데이트 시간을 분산하세요. 예를 들어 컴퓨터는 정각, 휴대폰은 매 시 30분에 실행하면 같은 시점의 동시 요청을 줄일 수 있습니다.
DNS 오염, 인증서 오류, 네트워크 타임아웃 점검하기
구독 도메인이 잘못된 IP로 해석되면 연결 시간 초과, 연결 재설정 또는 도메인과 인증서 이름 불일치가 흔히 발생합니다. 먼저 시스템 DNS 결과와 신뢰할 수 있는 DNS의 결과를 비교한 다음 FlClash의 DNS 설정을 조정할지 결정하세요.
두 가지 DNS 조회 테스트
nslookup subscription.example.com
nslookup subscription.example.com 1.1.1.1두 결과가 크게 다르다고 해서 어느 한쪽이 반드시 틀렸다는 뜻은 아니지만, 서비스 제공업체가 공개한 회선 정보와 함께 확인할 필요가 있습니다. 가정용 인터넷과 모바일 핫스팟을 번갈아 사용할 수도 있습니다. 같은 기기에서 핫스팟으로는 2초 안에 업데이트되지만 가정용 인터넷에서는 30초 동안 타임아웃이 발생한다면 YAML 자체보다 가정용 인터넷의 DNS나 라우팅 문제일 가능성이 높습니다.
FlClash에서는 「설정」→「매개변수 설정」으로 이동해 DNS와 실행 모드를 확인할 수 있습니다. mihomo DNS를 활성화했다면 upstream DNS 주소에 연결할 수 있어야 하며 구독 도메인이 로컬 주소로 잘못 매핑되지 않았는지 확인하세요. DoH를 사용할 때도 시작 단계에서는 DoH 서버 도메인을 해석해야 하므로 사용 가능한 기본 DNS 경로를 유지하거나 관련 도메인에 올바른 초기 해석 경로를 제공해야 합니다.
시스템 시간과 인증서 체인을 놓치지 마세요
- 시스템 시간이 몇 시간만 어긋나도 TLS 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판단될 수 있습니다.
- 공용 네트워크의 인증 페이지가 최초 HTTPS 연결을 차단할 수 있으므로 먼저 브라우저에서 네트워크 인증을 완료하세요.
- 회사 또는 학교 네트워크가 HTTPS 검사 장비를 거치는 경우 인증서 오류는 네트워크 관리자에게 확인해야 하며, 인증서 검증을 끄는 방법은 권장하지 않습니다.
- 모바일 기기에서 절전 모드나 백그라운드 데이터 제한을 사용하면 예약 업데이트가 시스템에 의해 지연될 수 있습니다. 이 경우 앱을 다시 전면으로 가져와 수동 업데이트하면 정상적으로 실행되기도 합니다.
업데이트 프록시와 프록시 루프 처리 방법
현재 네트워크에서 구독 서버에 직접 연결할 수 없다면 기존 프록시를 통해 업데이트해야 합니다. 그러나 새 기기는 처음 가져올 때 사용할 노드가 없고 아직 다운로드하지 않은 구독에 의존할 수도 없습니다. 이것이 대표적인 시작 의존성 문제입니다. 또 다른 경우는 클라이언트가 구독 요청을 로컬 프록시 포트로 보내고, 프록시 프로세스는 해당 구독이 로드되기를 기다리면서 루프나 타임아웃이 발생하는 상황입니다.
직접 연결과 프록시 중 어느 쪽을 사용할지 먼저 판단하기
- 시스템 프록시를 끄고 구독 도메인에 직접 연결해 200 응답을 받을 수 있는지만 테스트하세요.
- 직접 연결에 실패한다면 이미 사용 가능한 로컬 설정을 실행한 뒤 로컬 혼합 포트를 통해 테스트하세요.
- 일반적인 mixed-port는
7890이지만 실제 포트는 「설정」→「매개변수 설정」에 표시된 값을 기준으로 해야 합니다. - 업데이트가 성공한 뒤 로그를 확인해 요청이 예상한 정책을 통과했는지, DIRECT와 프록시 사이에서 반복 재시도하지 않았는지 확인하세요.
curl -L --proxy http://127.0.0.1:7890 \
--connect-timeout 10 --max-time 30 \
-o subscription.yaml \
"https://example.invalid/subscription/token"프록시를 사용하면 3초 안에 완료되지만 직접 연결은 항상 10초 동안 연결 시간이 초과된다면 업데이트 프록시가 필요하다는 뜻입니다. 반대로 프록시 테스트에서 Connection refused가 표시되면 FlClash가 실행 중인지, mixed-port가 실제로 7890인지, 해당 포트를 다른 프로그램이 사용 중인지 확인하세요.
업데이트 트래픽이 사용할 수 없는 정책으로 되돌아가지 않게 하기
구독 업데이트 프록시는 현재 이미 사용 가능하다고 확인된 노드나 정책 그룹을 선택해야 합니다. 업데이트가 완료되어야 생성되는 임시 정책은 선택하지 마세요. 최초 가져오기에서는 직접 연결 가능한 네트워크, 모바일 핫스팟 또는 로컬에서 사용 가능한 설정으로 먼저 시작할 수 있습니다. 업데이트가 끝난 뒤 평소 사용하는 규칙 모드로 되돌리세요.
TUN 모드는 더 많은 시스템 트래픽을 가로채지만 구독 서버에 접근할 수 없는 문제를 자동으로 해결하지는 않습니다. TUN 라우팅, DNS 하이재킹, 시스템 프록시를 동시에 활성화했다면 구독 요청이 최종적으로 어느 경로로 들어가는지 중점적으로 확인하세요. 문제를 해결할 때는 TUN을 잠시 끄고 명확한 HTTP 또는 mixed 프록시 경로 하나만 유지하세요. 구독 업데이트가 정상임을 확인한 후 TUN과 DNS 설정을 하나씩 다시 활성화하면 됩니다.
FlClash 자동 업데이트 간격 권장 설정
FlClash에서 설정 관리 페이지를 열고 해당 원격 구독을 선택한 뒤 편집 항목으로 들어가세요. 전역 네트워크 매개변수는 「설정」→「매개변수 설정」에서 확인할 수 있습니다. 버전에 따라 버튼 문구는 조금 다를 수 있지만 구독 URL, 자동 업데이트 활성화 여부, 업데이트 간격, 프록시를 통한 업데이트 여부는 반드시 확인해야 합니다.
일상적인 기기를 위한 안정적인 조합
- 자동 업데이트: 켜기.
- 업데이트 간격: 24시간. 노드 변경이 잦다면 6시간으로 설정하세요.
- 업데이트 프록시: 구독 도메인에 직접 연결할 수 있다면 직접 연결을 유지하고, 직접 연결이 계속 실패한다면 이미 사용 가능한 프록시 정책을 선택하세요.
- 시작 시 업데이트: 짧은 간격의 자동 업데이트와 함께 사용할 필요가 없습니다. 재시작할 때마다 중복 요청이 발생하는 것을 피하세요.
- 실패 시 재시도: 간격을 최소 5~15분으로 두고, 몇 초 단위의 연속 재시도는 하지 마세요.
mihomo의 proxy-providers로 원격 노드를 관리한다면 업데이트 간격은 초 단위로 interval에 입력합니다. 아래 예시는 6시간으로 설정하고 노드 상태 확인은 10분마다 실행하도록 구성합니다. 상태 확인은 기존 노드만 테스트하며 구독을 다시 다운로드하는 것과는 다릅니다.
proxy-providers:
remote-nodes:
type: http
url: "https://example.invalid/subscription/token"
path: ./providers/remote-nodes.yaml
interval: 21600
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 600proxy-providers의 원격 파일은 프록시 노드 모음을 반환해야 합니다. 완전한 Clash 설정 구독은 보통 클라이언트의 설정 관리 기능으로 가져옵니다. 두 구조는 다르므로 완전한 설정 URL을 provider에 입력했다고 해서 반드시 호환되는 것은 아닙니다. 파싱 오류가 발생하면 서버가 provider 전용 형식을 제공하는지 확인하세요.
자동 업데이트가 실제로 실행되었는지 확인하는 방법
- 설정 페이지에 표시된 마지막 업데이트 시간을 기록하세요.
- 한 번 수동 업데이트를 실행하고 시간, 트래픽 정보 또는 노드 목록이 합리적으로 변경되는지 확인하세요.
- 전체 주기가 지난 뒤 다시 확인하세요. 클라이언트 시작 시간을 업데이트 시간으로 대신하지 마세요.
- 로그에 HTTP 상태 코드, provider 업데이트 성공 또는 파싱 실패 기록이 남았는지 확인하세요.
- 업데이트가 끝난 뒤 두 노드를 전환해 지연 시간을 테스트하고 새 설정이 실행 중인 커널에 로드되었는지 확인하세요.
파일 다운로드는 성공했지만 실행 중인 설정이 바뀌지 않았다면 새 설정이 검증을 통과하지 못했거나, 클라이언트가 다른 로컬 설정을 사용 중이거나, provider 파일이 업데이트된 뒤 아직 다시 로드되지 않았을 수 있습니다. 먼저 현재 활성화된 설정 이름을 확인한 다음 로그의 로드 경로를 점검하세요.
오류 증상별 최종 점검
| 증상 | 우선 확인할 항목 | 처리 방향 |
|---|---|---|
| 401 또는 404 | 구독 토큰과 URL | 서비스 관리 화면에서 주소를 다시 생성 |
| 403 | User-Agent, 발신 IP | Clash 형식을 선택하고 요청 정책 확인 |
| 429 | 업데이트 빈도와 기기 수 | 새로고침을 중지하고 6~24시간 간격으로 변경 |
| 연결 시간 초과 | DNS, 라우팅, 업데이트 프록시 | 직접 연결, 핫스팟, mixed-port 비교 |
| 인증서 오류 | 시스템 시간, 인증 네트워크 | 시간을 보정하고 네트워크 인증 완료 |
| YAML 파싱 실패 | 응답 내용과 구독 형식 | 반환된 내용이 HTML 또는 로그인 페이지가 아닌지 확인 |
| 업데이트 성공 후에도 노드가 바뀌지 않음 | 활성 설정과 로드 경로 | 현재 설정을 확인하고 다시 로드 |
전체 점검 순서는 여섯 단계로 줄일 수 있습니다. 구독 URL을 다시 복사하고, HTTP 상태 코드와 다운로드 내용을 확인한 뒤, User-Agent를 비교하세요. 네트워크를 바꾸며 DNS를 점검하고, 직접 연결과 로컬 프록시를 각각 테스트한 다음, 마지막으로 적절한 자동 업데이트 간격을 설정하면 됩니다. 이 순서는 대부분의 Clash, mihomo, FlClash 구독 업데이트 문제를 다루며 형식 문제를 커널 문제로 잘못 판단하는 것도 막아 줍니다.
문제를 해결한 뒤에는 실행 가능한 로컬 설정을 하나 보관하고 현재 mixed-port, DNS 모드, 업데이트 시간을 기록해 두는 것이 좋습니다. 다음에 문제가 발생하면 먼저 로컬 설정으로 안정적인 네트워크를 만든 뒤 원격 구독을 업데이트하는 편이 클라이언트를 반복해서 삭제하고 재설치하는 것보다 빠른 경우가 많습니다.