Clash 노드 타임아웃 연결 안 될 때: 구독·포트·프로토콜 순서대로 점검하기

노드 타임아웃은 Clash와 mihomo 코어를 쓰면서 가장 흔히 겪는 오류 현상이지만, "타임아웃"이라는 표시 뒤에 숨은 원인은 하나가 아닙니다. 똑같은 빨간 느낌표나 timeout 메시지라도 구독 자체가 만료됐을 수도 있고, 로컬 속도 측정 방식이 부정확할 수도 있으며, 포트나 프로토콜 설정값이 잘못 입력됐거나 시스템 시간 오차·로컬 방화벽이 핸드셰이크 패킷을 막는 경우일 수도 있습니다. 하나씩 점검하기 전에 먼저 유형을 나눠 판단하면 불필요한 삽질을 절반 이상 줄일 수 있습니다.

B-01전체 타임아웃인지 일부 타임아웃인지 먼저 구분하기

노드 목록을 열어 타임아웃되는 노드의 분포 범위를 확인하세요. 이 단계에서 이후 점검 방향이 정해집니다.

• 전체 노드 타임아웃: 대개 로컬 네트워크 환경 문제, 구독 전체 만료, 시스템 시간 오차, 또는 로컬 방화벽·보안 소프트웨어의 전면 차단을 가리키며, 특정 노드 자체의 고장이 아닌 경우가 많습니다.
• 일부 노드만 타임아웃, 나머지는 정상: 해당 노드의 서버가 다운됐거나, 해당 노드의 프로토콜 설정이 서버와 맞지 않거나, 그 노드가 걸치는 중계 경로 자체가 불안정할 가능성이 높습니다.
• 들쭉날쭉 반복되는 경우: 대부분 속도 측정 방식 자체가 부정확하거나 서버가 트래픽이 몰리는 시간대에 속도를 제한하는 경우이며, 노드가 완전히 죽은 것은 아닙니다.

B-02구독 유효성 점검

전체 노드가 타임아웃된다면 먼저 구독 자체가 여전히 유효한지 확인하세요. 가장 놓치기 쉽지만 발생 빈도가 가장 높은 단계입니다.

1. 클라이언트의 구독 관리 페이지를 열어 만료일과 남은 트래픽을 확인하세요. 대부분의 구독은 트래픽을 다 쓰거나 요금제가 만료되면 서버 측에서 모든 연결 요청을 바로 거부하며, 이는 전체 노드 타임아웃으로 나타납니다.
2. "구독 업데이트"를 눌러 노드 수가 변하는지 확인하세요. 업데이트 후 노드 수가 0이 되거나 목록이 비어 있다면 구독 링크가 이미 만료됐거나 서버에서 내려간 상태입니다.
3. 브라우저에서 구독 링크를 직접 열어보세요(클라이언트 전용 요청 헤더 제한을 제외하고). 오류 페이지나 빈 응답이 아니라 정상적인 Base64 또는 YAML 텍스트가 반환되는지 확인합니다. 403, 404 또는 빈 내용이 돌아온다면 문제는 클라이언트 설정이 아니라 구독 소스 쪽입니다.
4. 구독 링크에 만료 파라미터나 임시 인증 토큰이 포함돼 있는지 확인하세요. 일부 서비스의 구독 링크는 유효기간이 있어 만료되면 관리 페이지에서 다시 생성해야 합니다.

B-03로컬 속도 측정 방식 검증

클라이언트 화면에 표시되는 지연 값은 속도 측정 방식이 적절한지에 크게 좌우됩니다. 측정 방식이 부적절하면 실제로는 정상인 노드가 타임아웃으로 잘못 판정될 수 있습니다.

• 측정용 주소 선택: 대부분의 클라이언트는 기본값으로 http://www.gstatic.com/generate_204 또는 유사한 연결 확인 주소를 사용합니다. 로컬 네트워크에서 이 도메인 접속 자체가 불안정하면 측정된 지연값이 왜곡될 수 있으니 설정에서 다른 감지 주소로 바꿔 다시 비교해 보세요.
• 측정 프로토콜의 차이: TCP 지연 테스트와 실제 프록시 트래픽이 거치는 프로토콜(Shadowsocks, VMess, Trojan, Hysteria2 등)의 핸드셰이크 방식은 다릅니다. TCP 단계에서 정상으로 표시되더라도 프록시 프로토콜 단계에서 반드시 연결이 성립된다는 뜻은 아니며, 이것이 "속도는 정상인데 페이지가 느리거나 타임아웃되는" 흔한 원인입니다.
• 동시 측정으로 인한 간섭: 모든 노드를 한꺼번에 일괄 측정하면 로컬 대역폭과 동시 연결 수가 서로 자리를 다투게 되어 뒤에 처리되는 노드일수록 측정값이 높게 나올 수 있습니다. 의심되는 노드 하나만 따로 측정한 뒤 결론을 내리는 것이 좋습니다.

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I -m 5

이 명령은 로컬 프록시 포트를 거쳐 연결 확인 요청을 보냅니다. HTTP/1.1 204가 반환되면 현재 선택된 노드와 로컬 프록시 경로 모두 정상이며, 타임아웃 표시는 클라이언트 화면의 측정 로직 자체 문제일 가능성이 큽니다. 명령 자체가 멈추거나 오류가 나면 실제로 프록시 경로에 문제가 있다는 뜻이니 포트와 프로토콜 설정을 이어서 점검하세요.

B-04포트·프로토콜 설정 점검

특정 노드가 계속 타임아웃되고 구독과 측정 방식을 확인해도 여전히 그렇다면, 대부분 해당 노드의 연결 설정값이 서버 설정과 맞지 않는 경우입니다.

1. 포트 번호 확인: 노드 상세 정보를 열어 포트 번호가 서비스 관리 페이지에서 제공한 정보와 완전히 일치하는지 확인하세요. 수동 구독이나 직접 만든 노드에서는 복사·붙여넣기 과정에서 숫자가 하나 더 붙거나 빠지는 실수가 가장 흔합니다.
2. 프로토콜과 암호화 방식 확인: Shadowsocks는 암호화 방식(aes-256-gcm, chacha20-ietf-poly1305 등)이 서버와 일치하는지 확인해야 하고, VMess는 UUID, AlterId(최신 버전은 대부분 0), 전송 방식(TCP/WS/gRPC)을 확인해야 하며, Trojan과 Hysteria2는 SNI와 인증서 검증 옵션이 서버 설정과 맞는지 확인해야 합니다. 이 중 하나라도 잘못 입력되면 핸드셰이크가 실패해 타임아웃으로 나타납니다.
3. 전송 계층 설정 확인: 노드가 WebSocket이나 gRPC 전송을 사용한다면 Path, Host 헤더가 서버와 일치하는지도 확인해야 합니다. 이런 설정값은 수동 구독 링크를 파싱할 때 종종 잘리거나 이스케이프 오류가 발생합니다.
4. TLS/SNI 설정 확인: TLS를 사용하는 노드에서 SNI가 잘못 입력됐거나 등록되지 않은·차단된 도메인을 가리키면 핸드셰이크 단계에서 바로 타임아웃이 발생하며, 화면상으로는 포트 오류와 거의 구분되지 않으므로 설정 파일을 하나씩 대조해야 합니다.

B-05시스템 시간과 로컬 방화벽 점검

앞의 단계들을 모두 확인해도 문제가 없는데 여전히 전체 타임아웃이라면, 놓치기 쉬운 시스템 차원의 두 가지 환경 요인이 남아 있습니다.

• 시스템 시간 오차: 대부분의 암호화 프록시 프로토콜(특히 Shadowsocks의 AEAD 암호화와 VMess의 타임스탬프 검증)은 클라이언트와 서버의 시스템 시간이 대체로 맞아야 동작합니다. 로컬 시간이 일정 범위 이상 벗어나면 서버가 핸드셰이크를 바로 거부해 모든 노드가 동시에 타임아웃될 수 있습니다. "네트워크 시간 자동 동기화"가 켜져 있는지, 시간대 설정이 올바른지 직접 확인하세요.
• 로컬 방화벽과 보안 소프트웨어: 일부 보안 소프트웨어나 시스템 기본 방화벽이 Clash가 사용하는 로컬 포트(예: 7890 혼합 포트, TUN 모드 가상 네트워크 어댑터)를 차단하거나 속도를 제한할 수 있습니다. 보안 소프트웨어의 네트워크 보호 기능을 잠시 꺼서 대조 테스트를 해보고, 꺼면 정상으로 돌아온다면 보호 기능을 계속 끄지 말고 해당 항목마다 허용 규칙을 추가하세요.
• TUN 모드의 드라이버 권한: TUN 모드로 전체 트래픽을 처리하려면 가상 네트워크 어댑터 드라이버가 관리자/root 권한으로 정상 생성돼야 합니다. 권한이 부족하면 트래픽이 TUN이 아닌 시스템 프록시 경로로 흘러 일부 앱에서 연결 오류가 발생할 수 있으니, 점검 시 시스템 프록시 모드로 전환해 대조해 보세요.
• 라우터 또는 상위 네트워크 제한: 일부 가정용 인터넷이나 회사 네트워크는 특정 포트 범위의 속도를 제한하거나 차단합니다. 로컬 설정에 이상이 없음을 확인했다면 다른 네트워크 환경(예: 휴대폰 테더링)으로 바꿔서 교차 검증해 보세요.

B-06점검 순서 정리

표로 정리해두면 순서대로 하나씩 대조하기 편하고 빠뜨리거나 중복 작업하는 것을 막을 수 있습니다.

위 순서대로 한 번 점검하면 대부분의 타임아웃 문제는 원인을 특정할 수 있습니다. 최종적으로 서버 측 노드 자체가 다운됐거나 속도 제한이 걸린 것으로 확인됐다면 서비스를 바꾸거나 제공처에 문의하는 것이 유일한 해결책이며, 클라이언트 로컬 설정으로는 서버 측 문제를 해결할 수 없습니다.