Clash 구독·규칙 갱신 실패? TLS, 시스템 시간, 단계별 점검

이 글에 해당하는지 먼저 볼 것

Clash·Mihomo 계열 앱에 구독 URL이나 rule-providers에 적어 둔 원격 규칙(룰셋) 주소는, 한 번에만 받아 오는 것이 아니라 주기적으로 다시 HTTP(S)로 가져와야 최신 노드·룰을 유지할 수 있습니다. 그런데 첫 import는 됐는데 「지금 업데이트」「갱신」을 누르면 TLS 관련 경고, 인증서 오류, 혹은 스피너만 돌다 끊기는 경우가 흔합니다. 이는 「구독이 어디서 오는가」를 설명하는 첫입문 글이 아니라, 이미 URL을 붙여 넣은 뒤에만 터지는 pull 실패를 원인과 순서에 맞춰 줄이는 문서입니다. 링크 획득·기본 붙여 넣기 절차는 Clash 구독 링크 가져오기를 먼저 다루고, 여기서는 Clash 구독 갱신 실패와 rule-providers·원격 룰 풀다운이 같은 층에서 어떻게 막히는지에 집중합니다.

증상: 브라우저는 열리는데 앱의 갱신만 실패할 때

에러 문구는 클라이언트마다 다르지만, 실질적으로는 (1) 핸드셰이크 단계에서 멈추거나, (2) certificate·x509·SSL·TLS 키워드가 섞이거나, (3) context deadline·timeout처럼 시간이 끊기는 패턴으로 나뉩니다. 원격 룰 URL도 구독과 동일하게 HTTPS이면 동일한 스택(시스템 루트 CA, OS 시간, 프록시 경로)을 탑니다. 그래서 「규칙만」 실패해도, 로그에 찍힌 대상이 githubusercontent.com이냐 구독 제공자 도메인이냐를 구분하되, 조치는 같은 줄에서 출발하는 경우가 많습니다. 반대로 브라우저로 직접 URL을 열면 JSON·YAML·텍스트가 보이는데 앱만 실패하면, User-Agent 제한, 시스템 프록시 루프, 혹은 Clash가 자기 요청에 프록시를 잘못 씀을 의심하는 편이 낫습니다.

1단계: 시스템 시간·시간대(타임 싱크)

TLS 인증서의 유효기간은 기기의 시계를 기준으로 검증됩니다. 시스템이 수 분 이상 뒤처지거나 앞서 있으면, 겉으로는 "인증서가 잘못됐다"로 보이기도 하고, 중간에 OCSP·스테이플링 검사가 어긋날 수도 있습니다. 먼저 Windows·macOS·Linux 모두에서 자동 날짜·시간·시간대를 켜고, 가능하면 NTP에 맞췄는지 확인하세요. 가상 머신·듀얼 부팅·수면에서 깨진 뒤에만 터지는 이슈라면, 시계만 고쳐도 구독 업데이트와 rule-providers 둘 다 같이 풀리는 사례가 꽤 있습니다. BIOS 배터리가 낡은 노트북은 부팅 직후에만 오차가 생기기도 하니, 틀릴 때마다 한 번씩 OS 동기화를 눌러 주는 것만으로도 재현이 사라질 수 있습니다.

2단계: TLS·인증서·기업·보안 SSL 검사

다음으로는 MITM(HTTPS 가로채기)이나, 기업·캠퍼스망의 SSL 검사가 자체 루트를 주입해 두었는지 봅니다. 이때는 브라우저에 별도 확장·정책이 얹혀 있어 "브라우저만" 정상이고, Go 런타임·Clash가 쓰는 시스템 루트와 결과가 갈릴 수 있습니다. 해결책은 (1) 검사를 끄거나 예외에 구독·룰 URL 도메인을 넣는 것, (2) 조직이 배포한 사설 CA를 OS 신뢰 저장소에 올바르게 넣는 것, (3) 정말 한시적으로 일부 앱이 제공하는 insecure·skip-cert-verify류 옵션을 쓰는 것인데, 마지막은 보안·규정을 희생하므로 개인·테스트에만 한정하는 것이 좋습니다. 일회성으로는 휴대전화 테더링 같은 다른 경로에 붙어 갱신이 되는지 비교해 보면, 회선·보안 스택 쪽을 빠르게 가를 수 있습니다.

3단계: 시스템 프록시·Clash가 Clash를 거치는 루프

윈도우·macOS에서 시스템 프록시를 Clash(혹은 Mixed/SOCKS/HTTP) 포트로 맞춰 둔 상태에서, Clash 자신의 아웃바운드가 다시 "시스템 프록시를 따르면" 프록시가 자기를 호출하는 루프에 빠질 수 있습니다. 증상은 갱신만 타임아웃이고 일반 웹은 되는 식으로 자주 나옵니다. 점검 순서는 (1) OS 네트워크 설정에서 수동/자동 시스템 프록시 잠깐 끄고 갱신 시도, (2) Clash·Mihomo의 dialer-proxy·proxy-chain류가 구독 fetch에 잘못 얹혀 있지 않은지, (3) TUN/시스템 터널이 로컬 루프백·Clash API·구독·룰 풀 대역을 직행(Direct)으로 빼야 하는지입니다. TUN 모드와 Fake-IP·DNS를 같이 쓰는 경우에는, "규칙은 잘 먹는데 갱신만 DNS가 엉뚱한 쪽"으로 흐르는 경우도 있으니, 연결·DNS 로그의 목적지 IP·호스트를 한 번만이라도 캡처해 두는 것이 좋습니다. WSL2·Docker 등과 겹치면 WSL2·호스트 프록시 절차가 도움이 됩니다.

4단계: 구독·룰 풀 URL은 DIRECT가 맞는지

서비스 제공자가 국내/저지연이 빠른 직접 경로를 열어 둔 경우, 구독 URL이 자신의 해외 중계를 타면 오히려 지연이나 소켓 수 제한에 걸릴 수 있습니다. 이때는 정책에서 해당 도메인·IP 대역에 대해 직접 연결(DIRECT)이나, 제공자가 안내한 전용 그룹이 있으면 그쪽을 쓰는 것이 맞습니다. rule-providers는 GitHub·jsDelivr·자체 서버 등으로 가는 경우가 많아, "규칙 파일만" 막히면 로그에 찍힌 호스트를 규칙 목록의 앞부분에 DIRECT·적절한 그룹으로 한 번 올려 보는 분기 테스트를 권장합니다. 전역 Proxy에 묶이면, 노드 쪽 TLS 인터셉트·불안정·대역 제한이 그대로 원격 룰·구독에도 복제되기 쉽습니다. 반면 일부 지역에서 특정 API가 막힌다면, 오히려 해당 호스트만 셀렉트 그룹으로 보내는 편이 낫기도 하므로, "무조건 DIRECT"가 정답은 아닙니다. 로그의 실제 목적지를 보며 조정하세요.

5단계: rule-providers·원격 룰만 따로 실패하는 경우

구독이 정상 갱신되는데 rule-providers·룰셋 URL만 403·429·5xx이면, 레이트 리밋·IP 차단·미러 이슈일 수 있습니다. GitHub raw는 빈도를 줄이고, interval을 늘리거나, jsDelivr·자체 서버 미러 URL로 바꾸는 실무 팁이 자주 쓰입니다. 응답이 HTML 에러 페이지인데 YAML 파서로 읽으면 파싱 오류로 보이기도 합니다. 그때는 브라우저로 같은 URL의 응답 앞 몇 줄이 YAML인지 HTML인지 먼저 구분하세요. Clash에서 user-agent를 맞춰야만 받는 서버는, proxy-providers·rule-providers에 UA 필드를 쓰는지 코어/문서를 확인해 보는 것이 좋고, 문서의 권장 값을 따르면 불필요한 403을 줄이는 데 도움이 될 수 있습니다.

6단계: DNS·Fake-IP·분할 터널

fake-ip와 도메인 규칙이 겹칠 때, 구독·룰 도메인이 의도와 다른 A 레코드로 해석돼, 실제론 "막힌" 프록시로만 붙는 경우가 있습니다. nameserver 체인·fallback·fake-ip-filter는 별도 주제이지만, 갱신만 불안정하면 해당 FQDN에 대해 (1) DNS만 시스템/DoH로 고정, (2) Clash DNS로만 해석, 중 무엇이 맞는지 한 가지씩 꺼 보며 비교해 보는 방식이 안전합니다. split tunnel(분할 터널)이 켜진 VPN과 동시에 쓰는 환경에서는, 구독 트래픽이 터널 밖으로 나가야 하는데 앱 내 설정이 반대로 되어 TLS 오류만 나는 사례도 있으니, "전체/분할"을 바꾼 뒤 한 번만 갱신해 보는 것도 값싼 점검입니다.

빠른 체크리스트(복북용)

OS 시간·시간대 자동 동기화, 브라우저 잠금 아이콘, MITM/SSL 검사 유무, 시스템 프록시 루프, 구독·룰 URL이 의도한 출구(DIRECT/Proxy)를 타는지, rule-providers interval·미러, User-Agent·403/429 로그, Fake-IP·DNS 일관성, 다른 네트워크(테더링)에서 동일 URL을 앱·브라우저로 비교. 이 순서는 Clash 구독 갱신 실패를 "구독이 없어서"가 아니라 "경로·시간·인증"으로 좁힌 뒤, 로그에 나온 호스트 한두 개에 규칙을 맞추는 데 유리합니다. 노드·그룹 설계는 Clash 규칙·GEOIP 글과 연결해 읽을 수 있습니다.

맺음: 안정적으로 받아 쓰려면

갱신·원격 룰을 안정화하면, 쓰는 쪽의 체감은 노드뿐 아니라 최신 룰·노드 목록이 끊기지 않는다는 점에 있습니다. 앱 생태는 빠르게 바뀌므로, Mihomo·GUI·모바일 빌드는 공식 다운로드에서 맞는 플랫폼을 고르는 것이, 오래된 TLS 스택·파서로 인한 가짜 TLS 오류를 줄이는 데에도 이어집니다. 다른 상용 VPN에 비해 한 화면에서 로그·규칙·노드를 함께 보는 편이라, 원인이 한 번에 드러나는 편이기도 합니다.

최신 클라이언트는 Clash 공식 다운로드 페이지에서 고를 수 있습니다. → Clash를 무료로 내려받고 TLS·시간·규칙을 한꺼번에 맞춰 보세요.