브라우저는 되는데 클라이언트만 실패하는 이유

구독 갱신은 단순히 「파일을 받는다」가 아니라, Clash 코어가 지정한 URL로 HTTP GET을 보내 응답 본문을 파싱하는 과정입니다. 브라우저에서 링크를 열면 최신 Chrome·Safari·Edge의 User-Agent 문자열과 쿠키·세션·자동 리다이렉트 처리가 함께 따라가고, 모바일 페이지와 데스크톱 페이지가 갈리는 사이트도 있습니다. 반면 Clash와 많은 GUI 클라이언트는 기본적으로 짧은 UA 문자열이나 코어가 붙이는 고정 패턴을 쓰기 때문에, 서버 측 WAF(웹 방화벽)나 구독 패널이 「브라우저가 아닌 클라이언트」 요청을 403 Forbidden으로 거절하는 경우가 있습니다.

또 다른 흔한 차이는 경로와 쿼리의 완전 일치입니다. 대시보드에서 복사한 URL 끝에 공백이 붙었거나, 한 번 쓰인 토큰이 회전해 이전 링크만 404가 나는 식입니다. 브라우저는 로그인된 세션으로 다른 URL을 보여 줄 수 있어도, Clash는 복사한 그 문자열만 그대로 요청합니다. 갱신 직후 노드가 비어 보이는 문제는 파싱 실패·빈 응답·로컬 캐시가 섞여 나타나므로, 구독·노드 유지보수에서 다루는 프로필 정리와 함께 읽으면 원인을 더 빨리 가릴 수 있습니다.

ℹ 먼저 할 일: 클라이언트 로그에서 구독 URL 요청에 대한 HTTP 상태 코드(404, 403 등)와 최종 요청 URL이 찍히는지 확인하세요. 상태 코드가 없고 타임아웃만 있다면 이 글보다 네트워크·DNS 쪽을 먼저 보는 편이 맞습니다.

HTTP 404: 경로·만료·리다이렉트

404 Not Found는 서버가 「이 경로에는 리소스가 없다」고 답한 것입니다. Clash 구독 갱신 맥락에서는 다음을 의심합니다. 첫째, 패널에서 발급한 구독 주소가 갱신되며 이전 경로가 폐기된 경우입니다. 둘째, 복사 과정에서 줄바꿈·공백·누락된 쿼리 파라미터(?token= 등)가 섞인 경우입니다. 셋째, 서버가 HTTP→HTTPS 리다이렉트를 주는데 클라이언트가 중간 응답만 보고 실패하는 환경(드묾)입니다.

대응 순서는 단순합니다. 제공자 대시보드에서 최신 구독 링크를 다시 발급받아 붙여 넣고, 구독 항목의 「이름」이 아니라 URL 필드 전체를 교체합니다. 브라우저 주소창에 붙여 넣었을 때와 Clash에 넣었을 때가 동일한지 한 글자씩 비교해 보세요. 여러 프로필을 쓰는 경우 잘못된 프로필에 구독이 묶여 있지 않은지도 확인합니다. 플랫폼별 앱 선택은 클라이언트 고르기 가이드와 맞춰 두면 설정 화면 위치를 헷갈리지 않습니다.

로그에 나올 수 있는 예(의미 이해용) 
GET https://example.com/sub/old-path: 404
fetch proxy providers: http error: status code 404

HTTP 403: User-Agent·리퍼러·봇 차단

403 Forbidden은 「알겠지만 허용하지 않는다」는 뜻으로, 구독 패널·CDN·보안 규칙이 비브라우저 요청을 막을 때 자주 보입니다. 클라이언트 설정에 User-Agent 커스터마이징 항목이 있으면, 제공자가 안내한 문자열(또는 일반적인 브라우저 UA)로 맞춰 보세요. 일부 패널은 특정 UA만 허용하고, 빈 문자열이나 Go-http-client 류 기본값을 거절합니다. Referer(리퍼러)를 요구하는 경우도 있어, 고급 설정에서 허용된다면 패널 도메인을 넣어 시험해 볼 수 있습니다.

403이 특정 네트워크에서만 난다면 IP 기반 차단이나 지역 CDN 정책일 수 있습니다. 같은 URL을 휴대전화 핫스팟 등 다른 회선에서 갱신해 보면 가려집니다. 회사·학교망은 보안 장비가 암호화 트래픽 안의 SNI·도메인을 보고 차단하기도 하므로, FAQ의 연결·환경 항목과 함께 「어디서만 실패하는지」를 메모해 두면 문의나 재현에 도움이 됩니다.

⚠ 주의: User-Agent를 무작정 유명 브라우저로 위장하는 것은 일부 서비스 약관에 어긋날 수 있습니다. 구독 제공자가 허용한 값을 우선하세요.

갱신 후에도 노드가 비어 있을 때

로그에는 200 OK가 찍혔는데 UI에 프록시가 없다면, 응답 본문이 비어 있거나 Clash가 이해할 수 있는 프록시 목록 형식이 아닐 수 있습니다. 예를 들어 HTML 오류 페이지나 「구독이 만료되었습니다」 같은 텍스트만 오면 파서는 노드를 만들지 못합니다. Base64로 감싼 구독인데 디코딩에 실패하면 비슷한 증상이 납니다. 이때는 응답 앞부분 몇 줄(민감한 토큰은 가린 뒤)을 제공자 측에 보내 형식 문제인지 확인하는 것이 빠릅니다.

또 한 가지는 규칙·프로바이더 이름이 꼬여 이전 캐시 노드만 참조하는 경우입니다. 구독 소스를 새로 넣었는데도 옛 그룹 이름을 가리키면 목록이 비어 보일 수 있어, 프로필에서 proxy-providers·proxy-groups 참조 관계를 한 번 정리합니다. 자동 선택·지연 테스트 그룹만 비어 있고 수동 선택에는 노드가 있다면, 헬스 체크 URL이 막혔거나 테스트 대상이 전부 실패한 레이어일 수 있습니다.

로컬 캐시·프로필 데이터 정리

구독 서버는 이미 정상인데 클라이언트만 옛 응답을 붙잡는 경우, 로컬 캐시를 지우는 것이 효과적입니다. Clash 계열 앱은 보통 사용자 데이터 디렉터리에 구독 스냅샷·다운로드 파일·캐시 DB를 둡니다. Windows에선 %USERPROFILE% 아래 앱별 폴더, macOS에선 ~/Library/Application Support, Linux에선 ~/.config 근처를 앱 이름으로 찾아볼 수 있습니다. 정확한 경로는 사용 중인 GUI 클라이언트 문서를 따르는 것이 안전합니다.

일반적인 절차는 다음과 같습니다. 앱을 종료한 뒤, 해당 프로필·구독과 연관된 캐시·다운로드 폴더만 삭제하거나, 앱 내 「캐시 지우기」「데이터 재설정」이 있으면 그 기능을 사용합니다. 전체 앱 데이터를 지우면 다른 프로필까지 날아갈 수 있으니, 먼저 백업을 권장합니다. 삭제 후 앱을 다시 켜고 구독 URL을 한 번 더 저장·갱신하면 서버에서 새 목록을 받아 옵니다.

여전히 같은 404·403이 반복되면 캐시 문제가 아니라 URL·서버 정책 쪽으로 돌아가야 합니다. 캐시는 「정상 응답을 잘못 오래 붙잡는」 경우에만 증상을 바꿉니다.

한눈에 보는 점검 순서

아래 순서는 Clash 구독 갱신 실패를 빠르게 좁히기 위한 것입니다. 앞에서부터 건너뛰지 말고 확인해 보세요.

  1. 로그에서 구독 요청의 HTTP 코드가 404인지 403인지, 아니면 연결 오류인지 적습니다.
  2. 대시보드에서 받은 최신 URL로 교체하고, 공백·줄바꿈 없이 붙였는지 확인합니다.
  3. 클라이언트에 User-Agent·필요 시 Referer를 제공자 안내대로 설정합니다.
  4. 다른 네트워크(핫스팟 등)에서 한 번 갱신해 IP·망 차단 여부를 봅니다.
  5. 성공 코드인데 노드가 없으면 응답이 유효한 구독 형식인지, 프로필 내 참조 이름이 맞는지 봅니다.
  6. 앱을 끄고 구독 캐시·다운로드 파일을 지운 뒤 다시 갱신합니다.
  7. 그래도 동일하면 제공자에게 로그·상태 코드와 함께 문의합니다.

정리와 다음 단계

브라우저에서 열리는 링크가 Clash에서만 실패할 때, 원인은 대개 요청 헤더 차이(특히 User-Agent)·만료되거나 잘못 복사된 URL·서버 측 접근 제어 가운데에 있습니다. HTTP 404는 주소와 발급 정책을, HTTP 403은 UA·리퍼러·네트워크별 차단을 우선 의심하면 됩니다. 갱신이 끝났는데도 노드가 비면 본문 형식과 프로필 참조를 보고, 그다음에 로컬 캐시를 비우는 순서가 실무에서 덜 헷갈립니다.

같은 증상이라도 원인은 여러 겹일 수 있어, 한 번에 모든 옵션을 바꾸기보다 로그에 찍힌 상태 코드를 기준으로 한 가지씩 바꾸면 재현과 되돌리기가 쉽습니다. 장기적으로는 구독과 노드를 주기적으로 점검하는 습관이, 급할 때 설정을 뒤엎는 일을 줄여 줍니다.

→ 구독 갱신 흐름이 안정적인 클라이언트로 Clash를 무료 받아, 오류가 나도 원인을 빨리 짚을 수 있게 해 보세요.