Clash 노드 타임아웃, 연결이 안 될 때? 이 순서대로 하나씩 점검하세요

NT-04.1먼저 증상 범위를 확인하고, 무작정 노드부터 바꾸지 말 것

"노드 타임아웃"이라는 표현은 사실 여러 가지 다른 원인을 뭉뚱그린 말입니다. 본격적으로 점검하기 전에 1분만 투자해 증상 범위를 확인하면 불필요한 작업을 크게 줄일 수 있습니다. 핵심은 세 가지 질문에 답하는 것입니다. 모든 노드가 타임아웃되는가, 아니면 일부만 그런가? 모든 프로그램이 접속 불가인가, 아니면 브라우저는 되고 CLI 도구만 안 되는가? 지연 시간(Latency) 테스트에서 숫자가 뜨는가, 아니면 바로 타임아웃 표시가 뜨는가?

일부 노드만 타임아웃되고 나머지는 정상이라면, 그 노드들의 서버 문제나 회선 혼잡일 가능성이 높으므로 지연이 정상인 다른 노드로 바꾸면 됩니다. 더 이상 점검할 필요는 없습니다. 반면 모든 노드가 동시에 타임아웃되고, 지연 테스트 칸이 아예 비어 있거나 타임아웃으로 표시된다면 문제는 대개 로컬 네트워크, 구독 데이터, 클라이언트 설정 쪽에 있습니다. 이 경우 아래 순서대로 하나씩 확인해야 합니다.

NT-04.21단계: 로컬 네트워크와 시스템 프록시 설정

점검 순서는 "가까운 곳부터 먼 곳까지"라는 원칙을 따릅니다. 가장 가깝고 확인하기 쉬운 부분부터 살피고, 이후 구독이나 프로토콜처럼 더 많은 작업이 필요한 영역으로 넘어갑니다. 첫 단계는 항상 로컬 네트워크 자체입니다.

1. 기기 자체가 인터넷에 정상적으로 접속되는지 확인하세요. Clash 클라이언트의 프록시 스위치를 잠시 끄고 시스템 네트워크로 임의의 웹페이지를 열어, 단순한 단선이나 로컬 네트워크 장애가 아닌지 확인합니다.
2. 클라이언트의 시스템 프록시 스위치가 켜져 있는지 확인하세요. 일부 클라이언트는 기본적으로 시스템 프록시를 자동 설정하지 않아, 프록시 서비스는 실행 중이지만 실제 트래픽이 그쪽을 지나지 않고 브라우저 요청이 여전히 직접 연결로 나가는 경우가 있습니다.
3. 프록시 모드 설정을 확인하세요. 규칙 모드(Rule)에서는 일부 직결 규칙 때문에 트래픽이 노드를 우회할 수 있습니다. 규칙 문제가 의심되면 잠시 전역 모드(Global)로 전환해 테스트해보세요. 전역 모드에서 정상이라면 문제는 노드가 아니라 규칙 설정에 있는 것입니다.
4. 로컬 방화벽이나 보안 소프트웨어가 클라이언트의 네트워크 요청을 막고 있는지 확인하세요. 특히 최근 설치한 백신 프로그램이나 시스템 기본 방화벽의 아웃바운드 규칙을 살펴보세요.

이 단계에서 상당수의 "가짜 타임아웃"을 걸러낼 수 있습니다. 클라이언트는 분명 실행 중인데 트래픽이 프록시를 전혀 타지 않아 지연 테스트가 정상적으로 나오지 않는 경우가 여기에 해당합니다.

NT-04.32단계: 구독이 여전히 유효한지 확인

로컬 네트워크에 문제가 없음을 확인했다면, 다음은 구독 자체를 점검할 차례입니다. 구독 링크가 가리키는 것은 노드 목록, 서버 주소, 포트, 인증 정보가 담긴 설정 파일입니다. 이 데이터가 만료되었거나 오류가 있으면 노드 서버 상태와 무관하게 모든 노드가 자연히 타임아웃됩니다.

1. 클라이언트에 표시되는 구독의 최근 업데이트 시간을 확인하세요. 구독처가 명시한 유효 주기를 이미 지났다면 설정이 만료되었을 가능성이 있으므로 수동으로 구독을 업데이트해야 합니다.
2. 구독의 트래픽 사용량이나 만료 시점이 남아 있는지 확인하세요. 대부분의 구독 상품은 용량이나 기간 제한이 있어, 이를 초과하면 서버가 신규 연결을 바로 거부하며 이는 노드 전체 타임아웃으로 나타납니다.
3. 클라이언트의 자동 업데이트에만 맡기지 말고 구독 링크를 다시 한 번 직접 가져오세요. 일부 클라이언트는 자동 업데이트 간격이 길기 때문에, 수동으로 강제 새로고침하면 최신 설정을 즉시 받을 수 있습니다.
4. 설정 파일 상세 정보를 열어 노드 수와 이름이 구독처 안내 페이지와 일치하는지 대조하세요. 노드 수가 갑자기 줄거나 이름이 깨져 보인다면 대개 구독 주소 자체에 문제가 생긴 것입니다.

NT-04.43단계: 프로토콜 파라미터와 핸드셰이크 세부사항

구독 데이터와 노드 목록에 문제가 없는데도 타임아웃이 지속된다면 프로토콜 레벨을 점검해야 합니다. Clash가 지원하는 노드 프로토콜(Shadowsocks, VMess, Trojan, Hysteria2 등)은 각각 독립적인 핸드셰이크 과정을 거치며, 파라미터 하나라도 잘못되면 연결 수립 자체가 실패합니다. 클라이언트 쪽에서는 이 모든 경우가 똑같이 타임아웃으로만 표시되고 구체적인 오류 원인은 알려주지 않습니다.

1. 서버 주소와 포트가 구독처의 최신 안내와 일치하는지 확인하세요. 일부 서비스 제공자는 출구 IP나 포트를 수시로 변경하는데, 로컬에 캐시된 오래된 설정이 이를 반영하지 못한 경우가 있습니다.
2. 암호화 방식(cipher), 전송 프로토콜(ws, grpc, tcp 등) 같은 필드가 서버 측 설정과 일치하는지 확인하세요. 이 중 하나라도 맞지 않으면 핸드셰이크 단계에서 멈춘 채 타임아웃으로 이어집니다.
3. 노드가 TLS나 SNI 위장을 사용한다면 인증서 도메인과 SNI 필드가 올바르게 입력되었는지 확인하세요. 인증서 검증 실패는 명확한 오류 메시지 대신 대개 연결 타임아웃이나 즉시 끊김으로 나타납니다.
4. 클라이언트의 로그 패널(대부분 설정이나 도구 메뉴에서 실시간 로그를 확인할 수 있습니다)을 열어보세요. 로그에는 dial tcp: i/o timeout, context deadline exceeded 같은 원문 정보가 남는 경우가 많으며, 화면 상의 "타임아웃" 아이콘보다 훨씬 참고 가치가 높습니다.

time="2026-07-10T14:02:11+08:00" level=warning msg="[TCP] dial ss-node-hk failed: dial tcp 203.0.113.10:443: i/o timeout"

이런 로그가 보인다면 클라이언트 자체 결함이 아니라 해당 서버와의 네트워크 연결성 또는 파라미터 불일치에 문제가 있다고 거의 확신할 수 있습니다.

NT-04.54단계: 포트 점유와 로컬 충돌

프로토콜 파라미터를 다 확인했는데도 여전히 모든 노드가 타임아웃된다면 로컬 포트 충돌을 점검해야 합니다. Clash와 코어 프로그램은 HTTP 프록시 포트, SOCKS5 프록시 포트, 믹스 포트, 컨트롤 패널 포트(흔히 7890, 7891, 9090)처럼 여러 로컬 포트를 사용합니다. 이 포트들이 다른 프로그램에 점유되었거나 시스템 권한에 막히면 프록시 서비스가 실제로는 정상 리스닝되지 않고, 결과적으로 연결 타임아웃으로 나타납니다.

1. 다른 프록시 소프트웨어나 VPN 클라이언트가 동시에 실행 중인지 확인하세요. 두 프로그램이 같은 포트를 두고 충돌하면 나중에 실행된 쪽이 조용히 실패하는 경우가 많습니다.
2. 해당 포트 번호가 시스템이나 다른 서비스에 점유되지 않았는지 확인하세요. 시스템 명령줄에서 포트 점유 상태를 확인할 수 있습니다(Windows는 netstat -ano, macOS/Linux는 lsof -i:포트번호). 리스닝 중인 프로세스가 실제로 현재 Clash 코어인지 확인하세요.
3. 최근 설정 파일에서 포트 값을 수정했다면, 클라이언트 화면에 표시되는 포트와 설정 파일의 포트가 일치하는지 확인하고 클라이언트를 재시작해 변경 사항을 적용하세요.
4. TUN 모드에서 타임아웃이 발생한다면 가상 네트워크 카드가 정상적으로 생성됐는지, 라우팅 테이블이 다른 네트워크 도구에 의해 덮어써지지 않았는지 추가로 확인하세요. 관련 점검 방법은 사이트 내 TUN 모드 튜토리얼을 참고하시기 바랍니다.

NT-04.65단계: 정책 그룹과 노드 선택 로직

여기까지 왔는데 앞의 네 가지 항목에서 모두 문제가 없었다면, 마지막으로 놓치기 쉬운 부분이 남아 있습니다. 바로 정책 그룹(Proxy Group)의 선택 로직입니다. Clash의 정책 그룹은 실제 트래픽이 어느 노드를 타는지 결정하며, 흔히 쓰이는 유형으로 select(수동 선택), url-test(자동 속도 측정 후 선택), fallback(장애 시 전환), load-balance(로드 밸런싱)가 있습니다. 정책 그룹이 현재 선택하고 있는 노드 자체가 이미 실패한 노드라면, 체감상 타임아웃으로 나타나지만 노드 목록의 다른 노드들은 지연 테스트에서 정상으로 나옵니다.

1. 정책 그룹 패널을 열어 현재 적용 중인 정책 그룹이 실제로 어떤 노드를 선택하고 있는지 확인하세요. 정책 그룹 이름만 봐서는 알 수 없습니다.
2. url-test 유형의 정책 그룹은 설정된 테스트 주소와 간격에 따라 자동으로 전환됩니다. 테스트 주소 자체가 특정 네트워크 환경에서 접속 불가라면 자동 선택 결과가 부정확할 수 있으니, 일단 수동으로 지연이 정상인 노드를 하나 선택해 비교해보세요.
3. 규칙 세트에서 특정 도메인이나 앱이 비어 있거나 이미 실패한 정책 그룹으로 잘못 연결되어 있지 않은지 확인하세요. 커스텀 규칙이 많은 설정에서 흔히 발생하는 상황입니다.
4. 여러 구독을 합쳐서 사용하는 설정이라면, 노드 이름 중복으로 정책 그룹이 잘못된 노드를 참조하고 있지 않은지 확인하세요.

이 다섯 단계를 모두 거치면 Clash 환경에서 발생하는 "노드 타임아웃"의 거의 모든 원인을 짚어낼 수 있습니다. 점검 순서를 가까운 곳부터 먼 곳으로 설계한 이유는 헛수고를 줄이기 위해서입니다. 대부분의 사람들은 처음에 노드나 구독처를 의심하지만, 실제로는 로컬 네트워크 설정이나 포트 충돌 같은 로컬 문제의 비중이 상당히 크고, 이런 문제는 몇 분 안에 확인하고 배제할 수 있습니다.

NT-04.7점검 요약

위 순서대로 하나씩 확인했는데도 문제가 계속된다면 클라이언트 로그 패널의 원문 오류 정보를 남겨두시길 권합니다. 이 정보는 화면 상의 "타임아웃" 표시보다 훨씬 구체적이며, 네트워크 환경 문제인지 설정 자체의 문제인지 더 정확하게 파악하는 데 도움이 됩니다.