Clash 노드 전체 타임아웃 진단 순서: 구독 유효성부터 포트 충돌까지 단계별 점검

먼저 "전체 타임아웃"과 "일부 타임아웃"을 구분하기

점검을 시작하기 전에 먼저 상황을 분류해야 합니다. 방향이 다르면 뒤에서 시간을 절반 이상 아낄 수 있습니다.

• 일부 노드만 타임아웃되고 나머지는 정상: 대부분 해당 노드나 착지 라인 자체의 문제입니다. 정상 작동하는 다른 노드로 바꿔 쓰면 되고, 로컬 설정을 의심할 필요는 없습니다.
• 평소 안정적이던 노드까지 포함해 전체 노드가 동시에 타임아웃: 이 글에서 다루는 상황이 바로 이겁니다. 이 경우 문제는 거의 확실히 로컬 환경이나 구독 쪾에 있으며, 수십 개 노드가 동시에 전부 고장 날 가능성은 매우 낮습니다.

측정 화면에 바로 "타임아웃"이 뜨거나 수치가 0ms로 고정되어 계속 바뀌지 않는다면, 노드를 지우거나 구독 판매처를 바꾸기 전에 아래 순서대로 먼저 점검해 보세요.

1단계: 구독이 만료되지 않았는지 확인

구독 링크는 사실 판매처나 서비스 제공자가 생성한 설정 스냅샷을 가져오는 창구입니다. 대부분의 서비스는 만료 후에도 링크 자체를 바로 삭제하지 않고, 링크는 계속 접속되지만 노드가 전부 무효 처리되거나 빈 목록만 반환되도록 처리합니다. 이런 "겉으로만 살아있는" 상태가 클라이언트 문제로 가장 많이 오인됩니다.

1. 판매처/서비스 제공자의 사용자 패널에 접속해 요금제 만료일을 직접 확인하세요. 구독 링크가 열리는지만으로는 판단하지 마세요.
2. 클라이언트에서 직접 "구독 업데이트"를 실행한 뒤 노드 수와 노드명이 바뀌었는지 확인하세요. 업데이트 전후로 노드 목록이 완전히 똑같다면 서버 쪽에서 새 데이터를 내려주지 않았다는 뜻입니다.
3. 구독에 트래픽 소진 시 속도 제한이나 서비스 중단 조항이 있는지 확인하세요. 일부 판매처는 트래픽을 다 쓰면 링크는 유지한 채 서비스만 멈추고, 별도 에러 표시는 하지 않습니다.

2단계: 로컬 시스템 시간 확인

이 항목은 자주 놓치지만 점검 목록 중 효율이 가장 높은 단계입니다. 대부분의 프록시 프로토콜(특히 AEAD 암호화를 쓰는 Shadowsocks, VMess, 그리고 TLS 인증서 유효기간 검증에 의존하는 프로토콜들)은 핸드셰이크 단계에서 타임스탬프를 검증합니다. 로컬 시스템 시간과 실제 시간의 차이가 크면 서버가 요청을 즉시 비정상으로 판단해 연결을 거부하는데, 이때 겉으로는 "노드 전체 타임아웃"으로 보이며 네트워크 자체가 원활한지와는 무관합니다.

• Windows 사용자는 우측 하단 시간 설정에서 "시간 자동 설정"이 켜져 있는지, 시간대가 올바른지 확인하세요.
• macOS/Linux 사용자는 터미널에서 date 명령을 실행해 휴대폰의 네트워크 시간과 일치하는지 비교해 보세요.
• 가상머신, 오래된 라우터, 장시간 절전 후 깨어난 기기에서 시간 오차가 가장 자주 발생합니다. 네트워크 시간(NTP)을 다시 동기화한 뒤 재테스트하세요.

시간 오차는 보통 몇 초까지 정밀하게 맞출 필요는 없지만, 몇 분 이상 벌어지면 암호화 핸드셰이크가 실패할 수 있습니다. 이 단계는 점검 비용이 매우 낮으니 구독 확인 다음으로 최우선으로 진행하는 것을 권장합니다.

3단계: 포트 충돌 및 점유 여부 확인

Clash / Clash Meta(mihomo 코어)는 실행 시 혼합 포트, HTTP 포트, SOCKS5 포트, 그리고 컨트롤 패널 포트를 리스닝해야 합니다. 이 포트들이 이미 다른 프로그램에 점유되어 있으면 클라이언트는 에러를 내며 종료되는 대신 "정상 작동하는 것처럼 보이지만 모든 요청이 타임아웃되는" 형태로 나타날 수 있습니다.

1. 다른 프록시 프로그램, 구버전 클라이언트의 잔여 프로세스, 이전에 정상 종료되지 않은 동종 프로그램이 함께 실행 중인지 확인하세요.
2. Windows에서는 netstat -ano | findstr 7890(포트 번호는 실제 설정값으로 변경)으로 해당 포트를 다른 프로세스가 점유하고 있는지 확인하세요.
3. macOS/Linux에서는 lsof -i:7890으로 포트 점유 상태를 확인할 수 있습니다.
4. 충돌이 확인되면 점유 프로세스를 먼저 종료하거나, 설정에서 다른 비어 있는 포트로 변경한 뒤 클라이언트를 재시작해 다시 테스트하세요.

4단계: 프로토콜과 코어 버전이 맞는지 확인

일부 노드는 비교적 최신 프로토콜 기능(예: Hysteria2, 일부 VMess의 AEAD 변형, 특정 Trojan 확장 파라미터)을 사용합니다. 클라이언트의 코어 버전이 오래되어 해당 필드를 인식하지 못하면 명확한 에러 없이 해당 노드를 그냥 사용 불가나 연결 타임아웃으로 표시해버릴 수 있습니다. 이런 문제의 대표적인 특징은, 같은 구독인데 최신 코어 클라이언트에서는 정상이고 구버전 코어 클라이언트에서는 전부 실패한다는 점입니다.

• 현재 사용 중인 클라이언트 코어가 Clash Premium(업데이트 종료)인지, Clash Meta / mihomo 코어인지 확인하세요. 신규 프로토콜은 거의 Meta 계열 코어에서만 지원됩니다.
• 클라이언트의 정보 페이지나 설정 페이지에서 코어 버전 번호를 확인하고, 공식 최신 버전과 비교해 크게 뒤처지지 않았는지 점검하세요.
• 구독 판매처에서 최신 프로토콜을 지원한다고 안내하는데 로컬 코어 버전이 오래되었다면, 먼저 클라이언트를 최신 버전으로 업그레이드한 뒤 다시 테스트하세요.

반대로 설정 파일에 현재 코어가 지원하지 않는 필드나 프록시 유형이 포함되어 있으면, 일부 클라이언트는 에러 알림 없이 해당 노드를 건너뛰는 방식으로 처리합니다. 이 역시 "노드가 전부 사라지거나 타임아웃되는" 것처럼 보이지만, 실제로는 파싱 단계에서 이미 걸러진 것입니다.

5단계: 올바른 속도 측정 및 지연 테스트 방법

앞의 4단계에서 모두 문제가 없었다면, 이제 지연 테스트 자체를 다시 살펴봐야 합니다. 지연 테스트에 쓰이는 측정 주소(예: http://www.gstatic.com/generate_204 같은)도 특정 네트워크 환경에서 불안정할 수 있습니다. 측정 주소 자체 접속이 막혀 있으면 모든 노드가 타임아웃으로 표시되지만, 실제로는 노드가 정상 작동 중인 경우가 있습니다.

1. 클라이언트 설정에서 현재 사용 중인 측정 주소를 확인하고, 다른 자주 쓰이는 측정 주소로 바꿔 테스트해 보세요.
2. 노드 하나를 직접 선택하고 글로벌 모드로 전환한 뒤, 실제로 웹페이지를 열어 정상 로딩되는지 확인하세요. 지연 수치만으로 판단하지 마세요.
3. 지연 수치는 이상하지만 웹페이지는 정상적으로 열린다면, 측정 링크 자체에 문제가 있는 것이고 노드는 실제로 정상 작동 중인 것이므로 노드 설정을 더 점검할 필요는 없습니다.

진단 순서 정리

위 5단계를 고정된 순서로 정리해 두면, "노드 전체 타임아웃"이 발생했을 때 이 순서대로 실행하는 것만으로 대개 몇 분 안에 문제 지점을 찾을 수 있습니다.

1. 구독이 만료되었거나 트래픽이 소진되었는지 — 서비스 제공자 패널에서 직접 확인하고, 링크가 열리는지만으로 판단하지 않기.
2. 로컬 시스템 시간에 오차가 있는지 — 자동 동기화가 켜져 있는지, 시간대가 올바른지 확인하기.
3. 포트가 점유되거나 충돌하는지 — netstat/lsof로 확인하고 잔여 프로세스를 정리하기.
4. 프로토콜과 코어 버전이 맞는지 — 클라이언트 코어를 업그레이드하고 프로토콜 지원 범위를 확인하기.
5. 측정 주소 자체가 정상 작동하는지 — 측정 주소를 바꿔 보고, 실제 웹페이지 접속 여부를 기준으로 판단하기.