증상이 이렇게 보일 때: 목록은 있는데 지연 테스트만 전부 실패

Windows에서 Clash·Mihomo 기반 클라이언트(예: Clash Verge Rev)를 켠 뒤 프록시 노드 이름·그룹은 정상처럼 보이는데, 일괄 지연 테스트를 누르면 한 줄 한 줄 타임아웃이거나 프로그레스가 돌아가기만 하고 숫자가 거의 안 붙는다면 사용자는 보통 「노드가 전부 죽었다」고부터 생각하기 쉽습니다. 특히 새 구독을 넣었을 때 UI가 새로 채워지지 않는 증상은 구독 캐시·강제 새로고침 문제와 헷갈리기 좋지만, 본 글처럼 이름은 보이지만 핸드셰이크·RTT 레이어만 막히는 경우는 다른 원인 쪽이 많습니다.

Clash류 지연 테스트는 결국 선택한 노드에 대해 TCP 또는 프로토콜별 헬스 체크를 수행했을 때 시간 안에 성공 회신이 왔는지를 보여 줍니다. 여기에서 DNS가 엉켜 이름이 엉뚱한 주소를 가리키거나, IPv6가 우선돼 깨진 경로로 나가거나, 업데이트용 구독 HTTPS GET부터 방화벽·중간 검사(SSLO)에 걸린 경우, 표면적으로는 비슷하게 「전부 빨간색」처럼 느껴질 수 있습니다. 아래에서는 Windows를 기준으로 가장 자주 이득이 나는 순서로 범위를 줄여 보겠습니다.

구독이 안 바뀌는 문제와 다름: 먼저 레이어를 나누기

갱신을 눌렀는데 목록이 그대로인 이슈는 원격 YAML이 실제로 동일하거나 UI가 옛 캐시를 붙잡는 쪽이 핵심인 경우가 많습니다. 반면 본문이 주로 다루는 것은 프록시 정의는 이미 메모리에 올라왔으나 측정·실연결이 막히는 흐름입니다. 구분이 서면 다음 단계에서 할 일이 달라집니다. 혼란을 줄이려면 먼저 로그에 subscription fetch가 주기적으로 성공하는지, 아니면 outbound 연결 시도에서만 오류가 쌓이는지를 대략만이라도 훑어 두세요. 자세한 해석은 연결 로그·규칙 적중 가이드와 같이 보면 빠릅니다.

1단계: DNS—시스템과 Clash 설정이 서로 엇갈리지 않게

Windows는 이더넷·Wi-Fi 어댑터마다 DNS가 따로 잡혀 있고, 일부 환경에서는 ISP DNS가 느리거나 특정 도메인을 가짜로 돌려 DNS poisoning에 가까운 응답을 주기도 합니다. Clash 쪽에서 fake-ip·redir-host·DoH 조합을 쓰는데 시스템 리졸버가 여전히 공격적으로 캐시하거나, 분할 라우팅 템플릿과 맞지 않으면 노드 이름이 아무리 많아 보여도 목적 호스트 이름이 다른 IP 그룹으로 풀리면서 핸드셰이크가 반복 타임아웃되는 패턴이 납니다.

체크 순서 예시입니다. (1) Windows 설정에서 활성 어댑터의 DNS를 잠깐이라도 신뢰할 수 있는 퍼블릭 리졸버 한 벌로 지정하고, ipconfig /flushdns로 OS 캐시를 비웁니다. (2) Clash DNS 블록이 프로필에 있다면 제공자 문서와 같은 철학인지 확인하고, 필요하면 테스트 기간에는 DoH 업스트림을 명시적으로 줄여 봅니다. (3) 게임·뱅킹처럼 실제 목적지 IP가 중요한 앱과 묶여 있다면 fake-ip와 redir-host의 차이 글처럼 DNS 모드 선택이 테스트 결과까지 흔드는 경우가 있습니다. 한 번 설정을 바꾼 뒤에는 반드시 코어 재시작·지연 테스트를 다시 돌려 변화 여부만 확인합니다.

2단계: IPv6—「우선은 IPv6인데 실제 경로는 불능」일 때

한국·일부 해외 회선은 IPv6가 활성화돼 있어도 터널 브로커나 사업장 정책 때문에 AAAA 레코드를 잡았을 때 UDP/TCP 세션이 중간에서 드랍되는 경우가 있습니다. 브라우저는 QUIC·폴백으로 겉으로 통과할 수 있는데, Clash 노드 테스트는 순수하게 선택한 egress로 패킷을 태우느라 IPv6 라우팅만 전부 깨져 보일 수 있습니다. 증상이 일관되게「전 노드 무응답」이면, 진단 차원에서 무선 카드 속성에서 IPv6를 잠시 해제했을 때 테스트가 바뀌는지 보는 방법이 현장에서 많이 쓰입니다.

IPv6를 끄는 것이 정답이라기보다 원인 분리용 스위치라는 점을 분명히 해 두세요. 이후에는 가능한 한 ISP가 제공하는 안정적인 듀얼 스택나, 라우터에서 선택적 IPv6 offloading을 조정하는 쪽으로 정리합니다. 회사 네트워크라면 무선 게스트망은 IPv6를 아예 빼두는 예도 흔하므로 집 회선과 비교 테스트해 보는 것도 빠른 판별입니다.

3단계: 구독 URL 자체가 막히지 않았는지

노드가 아직 화면에 있다고 해서 최근에 성공적으로 가져온 구독이라고 단정할 수 없습니다. 백신·기업 HTTPS 검사·학교 프록시가 구독 도메인의 TLS를 깨면 UI는 옛 스냅샷을 유지하거나 일부만 갱신될 수 있습니다. 구독 URL을 시스템 프록시를 끈 브라우저나 curl로 연 것과, Clash를 통한 업데이트 로그가 같은지 확인하세요. 401·403·403(rate limit)이라면 공항 패널에서 토큰을 다시 받아야 하고, TLS 인증 오류면 PC 시각·중간 증명서를 우선 의심합니다.

구독이 아예 새로 받아지지 않으면 테스트할 노드 문자열도 오래된 것일 수 있으니 구독 링크 설정 튜토리얼의 URL 검증 순서와 함께 보세요. 업데이트 GET이 차단되어 있어도 캐시의 YAML로는 목록이 남아 있어, 사용자는「한때는 됐는데 갑자기 전부 타임아웃」으로 느낄 수 있습니다.

4단계: Windows 방화벽·Defender·루프백·TUN 자기참조

Windows Defender나 서드파티 백신이 Clash/Mihomo 실행 파일의 아웃바운드 연결만 선별 차단하는 경우, UI는 살아 있는데 외부 핸드셰이크가 전부 막힌 것처럼 보일 수 있습니다. 이때는 오탐·격리 대응 가이드 흐름으로 예외를 주거나 로그에 차단 이벤트가 있는지 맞춰 봅니다. 또한 TUN 모드와 시스템 프록시를 동시에 켠 채로 Clash가 자기 자신을 다시 프록시에 태우는 루프가 생기면 이상한 타임아웃이 날 수 있으니, 문제 재현 시에는 TUN을 잠시 끄고 혹은 시스템 프록시만 남기는 식으로 한 축씩 줄여 보세요.

혼합 포트·수동 프록시 포트가 꼬였는지는 7890 충돌 점검 글과도 연결됩니다. 실제 사용 환경이 처음이라면 Clash Verge Rev Windows 설치 가이드에서 기본 전역·DNS·시스템 프록시 순서를 다시 맞추는 것도 시간을 아낍니다.

한 장 체크리스트로 정리

① OS DNS를 바꾸고 캐시를 비운 뒤 코어를 재시작해 지연 테스트를 다시 돌린다. ② IPv6를 잠시 끄고 동일 테스트를 해 본다. ③ 구독 URL을 브라우저·curl로 직접 열어 응답 코드와 본문 형식을 본다. ④ 백신·SSL 검사·회사 프록시 로그에 구독·노드 도메인이 없는지 본다. ⑤ TUN·시스템 프록시 조합을 단순화한다. ⑥ 그래도 의심스러우면 연결 로그에 남는 dial·TLS·DNS 문자열을 캡처해 오프라인으로만 공유한다. 이 순서는 서버가 실제로 다운된 경우와 로컬 스택 문제를 빠르게 가릅니다.

문서맥락과 설치 경로

Clash 계열은 포크마다 화면 용어가 조금씩 다르지만, DNS—전송—아웃바운드라는 큰 축은 같습니다. 개념을 다시 잡을 때는 사용 설명서를 함께 두고, 설치 파일은 출처를 통일하기 위해 다운로드 페이지에서 고르는 편이 안전합니다. 오픈소스 저장소는 라이선스·이슈 확인용으로 두고, 실행 파일을 받는 1차 동선은 사이트에 맞추는 전략이 반복 사용에 잘 맞습니다.

마무리: 빨간색 한 줄이 곧 공항 전체 장애는 아님

지연 테스트가 모두 실패한다고 해서 항상 노드 품질만의 문제는 아닙니다. Windows DNS·IPv6·구독 가져오기·로컬 보안 스택이 겹치면 겉보기에는 같아도 내부 원인은 전혀 다릅니다. 구독 UI가 갱신되지 않는 이슈는 캐시 길을, 목록은 있는데 숫자만 안 붙는 이슈는 본 글의 스택 순서를 기준으로 나누면 이후 트러블슈팅이 훨씬 짧아집니다. 설정을 정리한 뒤에는 다시 한 번 전체 지연 테스트를 돌려 보고, 여전히 특정 지역만 실패한다면 그때는 공항 상태·특정 프로토콜 제한을 의심하면 됩니다. 같은 생태계 안에서도 클라이언트가 규칙·DNS·노드를 한 번에 맞춰 주는 편이 사용 감각이 덜 지치는데, 배포가 검증된 빌드로 맞추고 싶다면 다운로드 페이지에서 Windows용 패키지를 고른 뒤 → Clash를 무료로 내려받아 지연 테스트와 실사용을 이어가 보세요.