증상: 수동/자동 갱신 뒤에도 노드·지연이 그대로일 때

Clash·Mihomo 계열 클라이언트에서 구독(subscription) URL을 연결한 뒤, 「업데이트」「새로고침」「지금 갱신」에 해당하는 버튼을 눌렀는데도 노드 목록·지연 측정 값이 이전과 동일해 보이는 경우는 흔합니다. 사용자 입장에서는 「캐시가 안 비워진 것 아닌가」「구독 주소가 잘못됐나」「앱이 실제로는 원격을 안 받고 있는 것 아닌가」라는 의심이 들기 쉬운데, 실제로는 원격 콘텐츠가 정말로 동일하거나, 다른 프로필을 보고 있거나, 로컬 캐시/오류 응답이 UI에 남아 있는 셋이 가장 자주 겹칩니다. 본문에서는 Windows를 기준으로, 먼저 사실을 구분한 다음 캐시를 걷어 내고 강제로 다시 내려받는 순서를 잡겠습니다.

이 글은 구독 링크·공항 노드 가져오기·다중 구독 관리를 이미 읽고 URL을 앱에 넣는 단계는 넘어온 독자를 대상으로 합니다. 처음 Windows에 Clash Verge Rev를 올리는 절차는 Clash Verge Rev Windows 가이드에 모아 두었으니, 설치·초기 프로필 연결이 불안하다면 그쪽을 먼저 맞춘 뒤 이 글의 「갱신이 안 먹는다」 쪽을 보시면 흐름이 끊기지 않습니다.

반드시 버그는 아님: 서버 쪽에서 목록이 안 바뀌는 경우

가장 먼저 짚을 점은, 공항(프록시 판매 서비스) 측에서 그 시간대에 노드 구성을 바꾸지 않았다면 구독 본문이 이전과 완전히 같고, Clash 쪽 UI도 당연히 같게 보인다는 사실입니다. 토큰·경로·만료는 문제없이 200 응답이 나왔는데 YAML 안의 proxies 이름·순서가 직전과 동일하면, 앱이 멈춘 것이 아니라 서버가 같은 스냅샷을 내려준 것입니다. 반대로 대시보드에서 노드를 추가했는데도 반나절 동안 Clash에 반영이 안 되면, 그때는 공항의 다른 엔드포인트(Clash/Shadowsocks 전용 URL)를 보고 있거나, 캐시/동기 지연을 의심하는 편이 맞습니다.

1단계: 구독 URL이「지금 쓰는 것」과 맞는지, 브라우저·로그로 확인

Clash Verge Rev 등 GUI에서는 프로필(구독) 카드마다 URL이 따로 있고, 같은 공항이라도 Clash·V2·범용 링크를 혼동하기 쉽습니다. 대시보드에서 새로 발급한 주소로 바꾼 뒤 저장을 안 했거나, 이전 URL이 아직 남아 있으면 갱신을 아무리 눌러도 옛 엔드포인트를 두드리는 셈입니다. URL 문자열 끝의 토큰 한 글자가 어긋나도 서버는 다른 계정·만료 응답을 줄 수 있으니, 대시보드의 「복사」로 다시 가져와 카드에 붙여 넣는 것이 가장 확실합니다.

이어서, 같은 URL을 시스템 프록시를 끈 브라우저나 curl로 직접 열어(민감한 토큰이 화면에 남을 수 있으니 주의) 응답이 200인지, 본문이 기대한 YAML/베이스64인지를 확인해 보세요. 302가 나면 최종 URL이 맞는지, 401·403이면 토큰 만료·정책 제한이니 대시보드에서 재발급이 필요합니다. Clash 쪽 로그(코어·UI)에 구독 요청 실패·TLS 오류·타임아웃이 기록돼 있으면, 캐시를 지우기 전에 네트워크·시간·안티바이러스가 발신을 막고 있지 않은지부터 보는 것이 좋습니다. 자세한 로그 읽는 법은 연결 로그·규칙 적중 가이드의 흐름을 참고하세요.

2단계: Clash Verge Rev(Windows)에서 수동 갱신과 캐시 비우기

UI에서의 일반적 순서

Clash Verge Rev는 구독이 프로필/구독 항목에 묶이고, 항목마다 수동 업데이트(또는 동기화)를 둡니다. 먼저 항목을 하나만 골라 수동 갱신을 누른 뒤, 구성이 머지된 전체 프로필을 다시 로드(적용)하는 단계를 거쳤는지 확인하세요. 일부 흐름에서는 원격 provider만 받아 오고, 활성 프로필에 병합·재선택이 끝나야 노드 UI가 갱신됩니다. 코어는 살아 있는데 UI만 남는 경우, 앱을 완전히 종료한 뒤 다시 켜면 메모리상의 이전 프록시 목록이 비워지기도 합니다.

앱 데이터·캐시 디렉터리(개념)

Windows에서는 프로필·다운로드한 원격 구성·provider 캐시가 사용자 데이터 폴더 아래에 저장됩니다. 실제 경로는 빌드·버전·설정에 따라 다르지만, Verge/Mihomo 계열은 보통 %APPDATA% 또는 %USERPROFILE%\.config 트리 아래에 profiles, cache, workspace에 가까운 이름의 하위 폴더를 둡니다. 앱을 완전히 종료한 뒤, 해당 앱이 문서에 안내하는 데이터 디렉터리에서 문제의 프로필에 대응하는 캐시·내려받은 subscription 파일만 백업 없이 지우는 방식이 가장 확실한 「강제 초기화」입니다. 잘못 짚으면 전체 설정이 사라질 수 있으니, 먼저 구독 URL 문자열은 메모해 두고, 대시보드에서 언제든 다시 받을 수 있다는 전제하에 진행하세요.

캐시를 비운 뒤에는 같은 구독 URL로 프로필을 다시 가져오기를 실행합니다. 이 시점에서 노드가 바뀌면, 이전에는 로컬에 남은 이전 provider 결과를 UI가 붙잡고 있었던 것입니다. 전혀 바뀌지 않으면, 1단계의 URL·응답이 여전히 동일하거나, 아래 3단계 쪽 이슈를 의심합니다.

3단계: 캐시를 지웠는데도 같을 때 (프로필·TUN·안티바이러스·시간)

여러 프로필을 쓰는 환경에서는 지금 보는 창이 다른 프로필일 수 있습니다. 한쪽 프로필만 갱신해 두고, 트레이에서 연 다른 프로필을 띄우고 있으면 노드가「안 바뀌는」 것처럼 느껴집니다. 활성 프로필과 구독이 연결된 프로필이 일치하는지 먼저 맞춰 보세요. 또한 TUN/시스템 프록시가 끼어 있으면 자기 자신에 대한 루프로 요청이 꼬이는 사례가 있어, 일시로 TUN·시스템 프록시를 끄고 구독 URL을 직접 받아 보는 것도 점검에 포함됩니다(보안 정책이 허용하는 범위에서).

백신·엔드포인트 보안이 Clash 프로세스의 아웃바운드 HTTP만 골라 막는 경우, UI에는「업데이트 누름」만 있을 뿐 실제 GET이 실패하고, 이전 캐시가 남아 있을 수 있습니다. 잠시 예외를 주거나, 로그에 막힘 기록이 있는지 대조하세요. PC 시스템 시각이 크게 틀어지면 TLS 인증서 검증이 실패해 갱신이 전부 막힌 것처럼 보이기도 합니다. Windows의 시간·타임존을 맞춘 뒤 다시 시도해 보는 것이 좋습니다.

「구독 가져오기」 본편과의 관계

구독 URL을 처음 넣는 방법, 여러 구독을 병합할 때 이름 충돌이 나지 않게 하는지, 자동 갱신 간격이 공항 쪽 레이트 리밋과 맞는지는 Clash 구독 링크 사용 튜토리얼에 정리돼 있습니다. 본 글은 그다음 단계로, 이미 넣은 URL이「갱신」되지 않는 것처럼 보이는 상황을 캐시·URL·로그 측에서 나누는 데 집중합니다. 두 문서를 같이 읽으면, 도입(가져오기)과 운용(갱신 실패)이 한 줄로 이어집니다.

전체 흐름이 헷갈릴 때: 문서·빌드

Clash·Mihomo 생태는 클라이언트 포크가 많고, 화면 용어가 빌드마다 조금씩 다릅니다. 공통 개념은 사용 설명서에서 다시 잡을 수 있고, 어떤 설치 파일을 쓰는지는 가능한 한 검증된 다운로드 페이지에서 고르는 편이 안전합니다. 오픈소스 본가의 Issue·릴리스는 신뢰도 확인에 유용하지만, 초기 설치 패키지의 1차 경로는 사이트 동선에 맡기는 전략이 흔한 사용자에게 잘 맞습니다.

정리: 「안 바뀐다」를 사실·캐시·프로필로 나누기

구독 갱신 뒤에도 노드·지연이 그대로라고 해서, 항상 클라이언트 캐시 탓만은 아닙니다. 원격 본문이 실제로 동일한지, 지금 URL이 맞는지, 같은 프로필을 보고 있는지를 먼저 가르고, Windows에서는 앱을 닫고 로컬 캐시·다운로드된 구독 조각을 지운 뒤 수동 갱신을 다시 수행해 보는 순서가 효율적입니다. 그래도 의심이 남으면 로그에 구독 요청 응답 코드와 TLS·DNS 메시지를 남기고, 오프라인에서만 공유하세요. 장기 운용에서는 구독 토큰을 주기적으로 회전하고, 공항 쪽에 노드가 바뀌었는지 먼저 물어보는 것도 시간을 아낍니다. 안정적으로 클라이언트를 쓰려면, 규칙·노드·DNS가 맞게 붙는지 한 번에 확인하는 로그 기반 점검과 병행하면 이후에도 재현·공유가 쉬워집니다. 준비가 되면 다운로드 페이지에서 Windows용 빌드를 다시 맞추고, → Clash를 무료로 내려받아 구독 갱신과 프로필 운용을 이어가 보세요.