Clash 노드가 전부 빨간색일 때: 지연 테스트, UDP, STUN, DNS로 범위 좁히기

“노드 전부 빨간색”이 의미하는 것

Clash·Mihomo 계열 클라이언트에서는 프록시 그룹마다 지연 테스트(Latency test)나 건강 검사(Health check, URL-Test 등) 결과를 색이나 숫자로 보여 줍니다. 사용자 입장에서는 “전부 빨간색이면 전부 막힌 것”처럼 느껴지지만, 실제로는 측정 대상이 TCP 핸드셰이크인지, 특정 도메인에 대한 HTTP GET인지, 구독에 적힌 서버 정보가 DNS로 풀리는지에 따라 실패 원인이 달라집니다. 먼저 “브라우저로 일반 사이트는 되는데 테스트만 전부 실패한다”와 “아무 것도 안 된다”를 나누는 것이 시간을 아낍니다.

이 가이드는 법령·서비스 약관을 준수하는 합법적 용도를 전제로, Clash 지연 테스트가 전부 타임아웃이거나 노드 전부 빨간색으로만 보일 때 DNS·UDP·STUN과의 관계를 정리하고, 설정·네트워크·제공자 측 중 어디를 의심할지 순서를 잡습니다. 기본 흐름은 구독 가져오기 가이드와 규칙 분할 라우팅 가이드를 먼저 맞춰 둔 뒤 적용하는 것이 좋습니다.

지연 테스트 ≠ 실제 트래픽 전부

대부분의 클라이언트에서 보이는 지연(ms)은 노드 서버까지의 TCP 연결 지연을 샘플링한 값입니다. 반면 음성·화상(WebRTC), 일부 게임, QUIC 등은 UDP를 씁니다. 시스템 프록시만 켜 두고 앱이 프록시를 타지 않거나, UDP가 터널 밖으로 새는 경우가 있으면 “지연 숫자는 예쁜데 실제 서비스는 끊긴다”는 패턴이 나올 수 있습니다. 반대로 지연 테스트만 전부 실패해도, DNS가 꼬여 서버 주소 자체를 잘못 잡았거나 방화벽이 측정용 포트만 막은 경우에는 웹 일부는 동작하는 이상한 상태가 되기도 합니다.

STUN은 NAT 뒤에서 UDP 홀펀칭 가능 여부를 확인하는 데 쓰이는 프로토콜로, Clash UI에 “STUN”이라는 문구가 직접 뜨지 않아도 WebRTC 기반 서비스가 불안정할 때는 사실상 같은 축(UDP 경로) 문제로 묶어 생각할 수 있습니다. 이때는 TUN 모드로 전역 라우팅을 맞추는지, 앱별 우회가 남아 있는지 함께 봅니다.

0단계: 구독·시간·프로필이 살아 있는지

노드 전부 빨간색이라도 먼저 확인할 것은 구독이 비어 있지 않은지, 프로필 갱신이 성공했는지, 시스템 시각이 크게 틀어지지 않았는지입니다. TLS 검증은 시간이 맞지 않으면 “연결 실패”로 보이기 쉽습니다. 같은 Wi-Fi에서 다른 기기는 정상인지, 모바일 테더링으로만 되는지도 한 번 비교해 보세요. 여기서 막히면 UDP나 DNS 이전에 상위 네트워크(캡티브 포털, 회사 프록시) 문제일 수 있습니다.

1단계: DNS — fake-ip와 nameserver부터

Clash의 DNS 설정은 규칙 매칭과 강하게 엮입니다. fake-ip를 쓰는 경우 브라우저가 보는 IP와 실제 백엔드 질의 순서가 어긋나면, 특정 도메인만 간헐 실패하거나 지연 테스트 대상 호스트가 엉뚱한 곳으로 붙을 수 있습니다. 진단용으로는 잠시 redir-host 계열로 바꿔 동일 증상이 재현되는지 보거나, 클라이언트의 DNS 로그에서 “어떤 nameserver로 무엇을 물었는지”를 확인하는 방법이 있습니다.

시스템 전역에 광고 차단 DNS·필터 DNS만 걸어 둔 상태에서 구독 도메인이나 노드 도메인 질의가 실패하면, 구독은 받아졌는데 건강 검사 URL만 계속 타임아웃하는 식으로 나타날 수 있습니다. 이때는 OS DNS를 기본값으로 되돌리거나, Clash 쪽 nameserver·fallback 구성을 구독 제공자가 안내한 값과 맞추는 것이 우선입니다. DNS가 안정돼야 지연 테스트가 의미 있는 숫자를 돌려줍니다.

규칙 순서와 GEOIP

GEOIP나 RULE-SET이 앞서 매칭되면 생각지도 않은 그룹으로 빠져 “노드는 살아 있는데 앱만 안 된다”는 상황이 됩니다. Clash 지연 테스트는 보통 특정 그룹·특정 노드에 대해 돌아가므로, 글로벌 모드와 규칙 모드를 바꿔 가며 숫자가 달라지는지 비교해 보세요. 자세한 작성 순서는 규칙 분할 가이드의 흐름과 맞춰 점검하면 됩니다.

2단계: UDP와 STUN — TUN·스택 설정

UDP가 중간에 드랍되면 음성·실시간 협업 도구가 먼저 불안정해지고, 일부 클라이언트의 부가 기능(예: 특정 형태의 NAT 탐지)도 실패할 수 있습니다. 시스템 프록시만으로는 UDP가 앱에 따라 우회하는 경우가 있어, “TCP만 프록시” 상태가 됩니다. TUN 모드를 켜면 시스템 전체 트래픽을 가상 인터페이스로 모으기 쉬워져 UDP까지 규칙에 태울 여지가 커집니다. 다만 OS 권한·보안 소프트웨어와 충돌할 수 있으니, 켠 뒤에도 증상이 같으면 방화벽 예외를 함께 보아야 합니다.

STUN 서버에 대한 접속이 막힌 네트워크(일부 회사망, 공공 Wi-Fi)에서는 WebRTC가 계속 “연결 중”으로 남을 수 있습니다. 이는 노드 전부 빨간색과 별개로 동시에 터질 수 있으므로, 같은 LAN에서 비업무용 회선으로만 테스트해 보면 원인이 네트워크인지 클라이언트 설정인지 빨리 갈립니다.

3단계: 건강 검사와 지연 테스트가 실제로 측정하는 것

프로필에 포함된 health-check·url-test류는 구성에 따라 주기적으로 특정 URL에 요청을 보냅니다. 여기서 막히면 그룹 전체가 “불량”으로 보일 수 있습니다. 반면 수동 지연 테스트는 클라이언트가 노드의 호스트·포트에 TCP 연결을 시도하는 방식인 경우가 많아, 둘이 항상 같은 결과는 아닙니다. 그래서 “수동 테스트는 빨간색인데 실제 브라우징은 된다”는 말이 나옵니다.

확인 순서로는 (1) 측정 URL이 HTTPS인지 HTTP인지, (2) 회사 방화벽이 해당 도메인만 차단하는지, (3) 제공자가 안내한 전용 측정 주소가 있는지를 봅니다. Clash 지연 테스트 결과만 보고 노드를 전부 교체하기보다, 동일 프로필을 다른 기기에서 열었을 때도 같은지 비교하면 서버 측 장애와 로컬 설정 문제를 가늠하기 쉽습니다.

4단계: 방화벽·보안 소프트웨어·혼합 포트

Windows Defender, macOS 방화벽, 제3자 안티바이러스가 로컬 mixed-port나 코어 프로세스의 수신을 막으면, UI는 켜진 것처럼 보여도 측정·실제 연결이 동시에 실패할 수 있습니다. “방금 업데이트했다” 이후에만 노드 전부 빨간색이 되었다면 예외 규칙을 다시 확인하세요. Allow LAN·방화벽 체크리스트는 PC에서 다른 기기로 프록시를 열 때도 같은 맥락으로 유용합니다.

5단계: 제공자·노드 자체와 혼동하지 않기

구독 패널에서 서버 점검 중이거나 특정 리전만 장애인 경우, 클라이언트에서는 일시적으로 지연 테스트가 전부 실패할 수 있습니다. 이때는 공지·상태 페이지를 확인하고, 동일 리전이 아닌 다른 그룹이 있는지 살펴보는 것이 빠릅니다. 로컬에서 DNS·UDP를 고쳐도 해결되지 않으면 이 축을 의심합니다.

정리

Clash 지연 테스트가 전부 실패하거나 노드 전부 빨간색일 때, 한 가지 원인만 있는 경우는 드뭅니다. DNS가 올바른 이름을 풀고 있는지, UDP·STUN이 필요한 트래픽이 원하는 경로로 가는지, 건강 검사 URL과 수동 측정이 같은 것을 보고 있는지, 방화벽이 로컬 리슨만 막고 있는지를 순서대로 가르면 헛수고를 줄일 수 있습니다. TUN·규칙·DNS는 서로 연결되어 있으므로, 한 번 맞춰 두면 이후 유지 보수도 쉬워집니다.

비슷한 도구들과 비교해 보면 Clash·Mihomo 계열은 구독과 규칙을 코드로 고정해 두기 쉬워, 동일 증상이 반복될 때 “어디를 손대야 하는지”가 명확한 편입니다. 지금 쓰는 OS에 맞는 클라이언트로 바로 점검해 보시려면 Clash를 무료로 다운로드한 뒤, 구독과 DNS·모드를 함께 맞춰 보시기 바랍니다.