어떤 증상이 «구독 갱신」 문제인가요?
대표적인 패턴은 다음과 같습니다. 첫 가져오기는 성공했는데 이후 자동 갱신이 멈추어 노드 이름·지연이 며칠 전 그대로입니다. 또는 주기적 갱신은 되지 않고, 사용자가 수동으로 «업데이트»를 눌렀을 때만 오류 메시지가 뜹니다. 로그에 403, 404, TLS handshake 실패, 인증서 날짜 관련 문구가 섞여 나오기도 합니다. 이때는 먼저 «실제로 구독 URL에 대한 HTTP 응답이 무엇인지」를 분리해 보는 것이 좋습니다. 프록시를 켠 브라우저로 같은 URL을 열었을 때와, Clash가 직접 요청할 때의 결과가 다르면 경로(UA·쿠키·리다이렉트) 차이를 의심할 수 있습니다.
반대로 구독은 최신인데 특정 사이트만 느리다면 이 글보다는 YAML 규칙 분기나 DNS·노드 지역 이슈에 가깝습니다. 여기서는 구독 링크를 클라이언트가 주기적으로 받아 오는 데 실패하는 경우에 초점을 맞춥니다.
1단계: 시스템 시간·타임스탬프(인증서 유효 기간)
HTTPS 요청은 서버 인증서의 유효 기간을 로컬 시계와 비교합니다. PC나 폰의 시각이 몇 년씩 틀어져 있으면 «인증서가 아직 유효하지 않다» 또는 «만료되었다»는 식으로 TLS 협상이 끊깁니다. 이때 사용자 입장에서는 구독 갱신만 실패하는 것처럼 보이지만, 실제로는 모든 HTTPS 사이트에 비슷한 증상이 동시에 나타나는 경우가 많습니다.
조치는 단순합니다. OS 설정에서 자동 시간 동기화(NTP)를 켜고, 이중 부팅·가상 머신·오래된 하드웨어 시계에서 자주 생기는 큰 오차를 바로잡습니다. 일부 기업망에서는 NTP가 막혀 있을 수 있으므로, 관리자에게 표준 시간 소스 허용을 요청해야 할 수도 있습니다. 시간을 맞춘 뒤 Clash에서 구독만 다시 시도해 보고, 같은 오류가 반복되는지 로그를 확인하세요.
2단계: HTTPS·TLS·인증서·중간자 검사
구독 링크가 https://로 시작한다면, 클라이언트는 기본적으로 시스템 신뢰 저장소를 사용해 서버 인증서를 검증합니다. 안티바이러스·기업 SSL 가시화·일부 캡티브 포털은 자체 루트를 주입해 MITM과 유사한 환경을 만듭니다. 이때 Clash가 «신뢰할 수 없는 인증서»로 거절하면 갱신은 실패합니다. 브라우저에만 예외를 넣어 두었다면 CLI·Clash 쪽은 여전히 실패할 수 있습니다.
대응은 (1) 해당 소프트웨어의 HTTPS 검사를 끄거나 예외에 구독 호스트를 넣기, (2) 회사 정책상 필요한 경우 IT가 배포한 신뢰 루트를 OS 수준에 올바르게 설치했는지 확인하기, (3) 구독 제공 측이 자체 서명·만료된 체인을 쓰는지 공지를 확인하기 등이 있습니다. «인증서를 무시한다»는 옵션은 보안상 권장되지 않으므로, 가능한 한 근본 원인을 고치는 편이 낫습니다.
또한 HTTPS가 아닌 http:// 구독은 중간 경로에서 내용이 바뀌거나 캐시될 수 있어, 제공자가 https를 권장한다면 맞춰 주는 것이 안전합니다.
3단계: User-Agent·봇 차단·클라이언트 지문
일부 구독 백엔드는 요청 헤더의 User-Agent를 보고 브라우저가 아닌 클라이언트를 차단합니다. Clash·서브 변환기·스크립트마다 기본 UA 문자열이 달라서, 제공자가 «특정 UA만 허용»하거나 «비어 있으면 거절»하는 정책을 쓰면 403이나 빈 응답이 돌아올 수 있습니다.
사용 중인 GUI에서 구독 항목별로 UA를 덮어쓸 수 있는지 확인해 보세요. 공급자 문서에 권장 UA가 있다면 그대로 맞추고, 없다면 일반적인 브라우저 UA로 시험해 볼 수 있습니다. 반대로 «브라우저로는 열리는데 Clash만 막힌다»면 UA 차이를 가장 먼저 의심하는 것이 좋습니다. 단, 개인정보·보안 정책에 맞는 범위에서만 조정해야 합니다.
4단계: HTTP 403·404·429와 링크 만료
응답 코드만으로도 원인 범위가 줄어듭니다. 404는 경로가 바뀌었거나 토큰이 폐기된 경우가 많습니다. 대시보드에서 새 구독 링크를 발급받아 클라이언트에 붙여 넣어야 합니다. 403은 권한·지역·Referer·UA·IP 제한·WAF 규칙 등 여러 요인이 겹칩니다. 같은 URL을 모바일 데이터와 Wi-Fi에서 번갈아 시험해 보면 IP 기반 차단인지 가늠할 수 있습니다.
429(Too Many Requests)은 갱신 주기를 너무 짧게 설정했을 때 발생하기도 합니다. 클라이언트의 자동 업데이트 간격을 제공자가 권장하는 최소 시간 이상으로 늘리고, 불필요한 중복 프로필(같은 URL을 여러 번 구독)을 정리하세요. 로그에 리다이렉트 체인이 길게 찍히면 최종 도착 URL이 의도와 다른지도 확인합니다.
5단계: 캐시·프록시 경로·환경 변수
Clash 자체가 아웃바운드 프록시를 쓰도록 설정되어 있고, 그 경로에서 구독 도메인이 막히거나 다른 국가 IP로 나가면 서버 측 규칙과 충돌할 수 있습니다. «시스템 프록시를 따라간다» 옵션이 있다면 끄거나, 구독 전용으로 DIRECT에 가깝게 두는 구성을 검토합니다. 반대로 반드시 특정 회선을 타야만 구독 호스트에 닿는 환경이라면, 그 회선이 켜져 있는지부터 확인해야 합니다.
로컬 캐시 파일이 손상되었을 때는 클라이언트가 이전 스냅샷만 보여 주기도 합니다. 앱에서 해당 프로필 캐시를 지우고 다시 받기, 또는 구독 URL을 삭제 후 재등록하는 방법이 도움이 됩니다. 터미널에서 curl로 동일 URL을 받아 볼 때는 -v로 상태 코드와 리다이렉트를 함께 확인하면 Clash 로그와 대조하기 쉽습니다.
클라이언트별로 챙길 것
제품마다 UI 이름이 다르지만 공통적으로는 다음을 확인합니다. 자동 갱신이 켜져 있는지, 갱신 주기(분 단위)가 과도하게 짧지 않은지, 구독별로 프록시/UA/헤더 오버라이드가 있는지입니다. 백그라운드 실행·배터리 최적화(모바일)에 의해 주기 작업이 잘리는 경우도 있으므로, 해당 OS 설정도 함께 보세요.
고급 사용자는 원격 규칙·Rule Providers와 별도로, 프록시 프로바이더(proxy-providers) 항목의 url·interval이 의도대로인지 YAML에서 직접 검토할 수 있습니다. 코어 버전이 오래되면 특정 TLS 기능과 맞지 않는 경우도 있어, 미호모 코어 업그레이드를 병행하는 편이 안전합니다.
마무리
Clash 구독 문제는 한 가지 원인만 있는 경우가 드뭅니다. 시각 오차로 TLS가 깨지고, 고쳐도 UA나 403 규칙에 걸리고, 링크가 바뀌면 404만 남는 식으로 겹칩니다. 로그에 찍힌 상태 코드와 TLS 메시지를 기준으로 위 순서를 밟으면 «왜 갱신만 안 되는지」를 빠르게 좁힐 수 있습니다. 구독 제공자 공지와 권장 갱신 간격을 함께 확인하면 재발도 줄일 수 있습니다.
설정 파일 전반이 길어졌다면 규칙 순서와 정책 그룹 설계를 YAML 가이드와 맞춰 정리하고, 클라이언트는 한곳에서 받아 두는 것이 이후 점검에도 유리합니다.