Clash 노드 시간 초과 문제 해결

1. 속도 측정 시간 초과와 실제 연결 실패 구분하기

Clash 클라이언트에 ‘시간 초과’가 표시되더라도 이는 보통 테스트가 제한 시간 안에 끝나지 않았다는 뜻이며, 이 정보만으로 노드가 작동하지 않는다고 단정할 수는 없습니다. 지연 시간 테스트는 대개 선택한 노드를 통해 테스트 URL에 접속합니다. 노드 도메인 조회, 원격 포트 연결, 프로토콜 핸드셰이크, 테스트 사이트 접속 중 어느 단계에서든 실패하면 비슷한 결과가 나올 수 있습니다. 오류 내용과 영향 범위를 먼저 기록한 뒤 설정을 변경하면 테스트 주소에 접속할 수 없는 문제를 전체 노드 장애로 오해하는 일을 줄일 수 있습니다.

세 가지 상황으로 점검 시작점 찾기

• 노드 하나만 실패: 현재 설정은 그대로 두고 같은 정책 그룹의 다른 노드로 같은 웹사이트에 접속해 보세요. 문제가 해결되면 해당 노드의 서버 상태와 설정을 먼저 확인합니다.
• 모든 노드가 실패: 로컬 네트워크, 시스템 시간, 구독 유효 기간, 코어 로그부터 확인하세요. 노드 포트를 한꺼번에 변경하지 마세요.
• 속도 측정은 실패하지만 웹페이지는 열림: 테스트 URL에 접속할 수 있는지, 실제 웹페이지 요청이 해당 노드를 통과하는지 확인하세요. 브라우저 캐시나 직접 연결 규칙 때문에 접속이 되는 것처럼 보일 수도 있습니다.

클라이언트의 ‘연결’ 또는 ‘로그’ 화면에서 새 요청의 대상 도메인, 적용된 규칙, 실제 연결 경로를 확인하세요. 예를 들어 웹 요청에 DIRECT가 적용됐다면 직접 연결이 정상이라는 뜻일 뿐, 선택한 프록시 노드가 작동한다는 증거는 아닙니다. 클라이언트마다 화면 이름은 다를 수 있으므로 실제 인터페이스와 현재 코어 설정을 기준으로 아래 내용을 확인하세요.

2. 프록시를 끄고 로컬 네트워크와 시간 확인하기

다른 프록시나 VPN을 종료한 뒤 현재 클라이언트의 시스템 프록시와 TUN을 잠시 끄세요. 브라우저에 프록시를 별도로 설정했다면 시스템 설정을 사용하도록 되돌려야 합니다. 평소 직접 접속할 수 있는 웹사이트를 열어 기본 네트워크가 정상인지 확인하세요. 공용 Wi-Fi를 사용한다면 먼저 네트워크 인증을 완료합니다. 직접 연결도 되지 않는다면 무선 연결, 공유기 또는 통신사 네트워크 문제부터 해결하세요.

기본 점검 순서

1. Windows 11의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 설정을 확인하세요. 클라이언트를 종료한 상태라면 작동하지 않는 로컬 포트를 가리키는 프록시 설정이 남아 있지 않아야 합니다.
2. ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 자동 시간 설정을 켜고 ‘지금 동기화’를 실행하세요. 시간대 표시뿐 아니라 실제 날짜와 시간도 확인해야 합니다.
3. macOS에서는 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 자동 설정을 확인할 수 있습니다. 네트워크 프록시는 ‘네트워크’ → 현재 네트워크 서비스 → ‘세부사항’ → ‘프록시’에서 확인하세요.
4. 기본 네트워크를 복구한 뒤 프록시 클라이언트 하나만 실행하세요. 먼저 시스템 프록시로 테스트하고 정상 작동을 확인한 다음 TUN을 다시 켜세요. 가상 네트워크 어댑터와 라우팅 변수를 동시에 추가하지 않는 것이 좋습니다.

TLS 인증서에는 유효 기간이 정해져 있어 시스템 날짜가 맞지 않으면 핸드셰이크가 바로 실패할 수 있습니다. 다만 모든 프로토콜이 같은 시간 동기화 방식을 사용하는 것은 아닙니다. 따라서 시간 동기화는 기본 점검 항목이지 모든 시간 초과 문제를 해결하는 방법은 아닙니다.

3. 구독이 만료되지 않았고 설정이 최신인지 확인하기

구독 링크를 내려받을 수 있다고 해서 계정에 사용 가능한 데이터가 남아 있거나 모든 노드가 정상이라는 뜻은 아닙니다. 구독 서비스 계정 페이지에서 만료일, 잔여 데이터, 점검 공지, 클라이언트 사용 제한을 확인하세요. 계정이 정지됐다면 먼저 계정 상태를 해결해야 합니다. DNS를 반복해서 변경해도 정지된 서비스는 복구되지 않습니다.

1. 클라이언트의 ‘구독’ 또는 ‘설정’ 화면에서 현재 사용하는 항목을 찾아 업데이트한 뒤 업데이트 시간과 결과를 확인하세요.
2. 업데이트된 설정이 선택되어 있고 코어에 정상적으로 로드됐는지 확인하세요. 다운로드는 성공했지만 파싱에 실패했다면 이전 설정이 계속 실행 중일 수 있습니다.
3. 정책 그룹에서 실제로 선택된 노드를 확인하세요. 자동 선택 그룹이나 장애 조치 그룹의 현재 연결 경로는 마지막으로 수동 선택한 노드와 다를 수 있습니다.
4. 로그에 알 수 없는 프록시 유형, 누락된 필드, 존재하지 않는 정책 그룹이 표시된다면 네트워크 시간 초과로 분류하지 말고 먼저 설정 호환성 문제를 해결하세요.

4. 노드 도메인과 원격 포트 확인하기

구독에 문제가 없는지 확인한 다음 ‘주소를 찾을 수 없음’과 ‘주소는 확인되지만 포트에 연결할 수 없음’을 구분하세요. 노드의 server와 port를 확인하되 로컬 HTTP 프록시 수신 포트를 원격 노드 포트와 혼동하지 마세요. 아래 명령의 example.com과 443은 명령 형식을 보여 주기 위한 예시일 뿐입니다. 실행할 때는 현재 노드의 실제 서버 도메인과 포트로 바꾸세요. 예시 노드는 실제로 사용할 수 있는 노드를 뜻하지 않습니다.

# Windows PowerShell: 먼저 도메인을 조회한 다음 TCP 포트 테스트
Resolve-DnsName example.com
Test-NetConnection -ComputerName example.com -Port 443

# macOS: 도메인 조회 및 TCP 연결 테스트
nslookup example.com
nc -vz -G 5 example.com 443

도메인 조회에 실패하면 먼저 노드 도메인의 철자가 올바른지, 더 이상 사용되지 않는 도메인은 아닌지 확인한 다음 현재 네트워크의 DNS 서비스를 점검하세요. mihomo 내장 DNS를 사용한다면 노드 서버 도메인이 어떤 경로로 조회되는지도 확인해야 합니다. 설정의 proxy-server-nameserver로 프록시 노드 도메인을 조회할 DNS 서버를 지정할 수 있지만, 실제 버전과 DNS 설정을 함께 살펴봐야 합니다. 이 필드 하나만 복사해 넣는다고 조회 경로가 올바르게 설정되는 것은 아닙니다.

TcpTestSucceeded: True는 TCP 연결이 한 번 성공했다는 뜻일 뿐, 인증이나 TLS, 프록시 프로토콜 핸드셰이크가 성공했다는 의미는 아닙니다. Hysteria2, TUIC처럼 UDP를 사용하는 프로토콜은 TCP 포트 테스트로 작동 여부를 확인할 수 없습니다. 일반적인 ping은 ICMP를 사용하므로 서버가 ICMP에 응답하지 않아도 프록시 서비스는 정상일 수 있습니다.

휴대폰 핫스팟으로 비교 테스트하기

클라이언트, 구독, 노드는 그대로 두고 컴퓨터의 Wi-Fi만 휴대폰 핫스팟으로 바꾼 다음 새 연결을 시도하세요. 핫스팟에서는 정상이고 기존 네트워크에서 계속 시간 초과가 발생한다면 기존 네트워크 경로, UDP 제한, 라우팅 정책 또는 외부 연결 필터가 원인일 가능성이 높습니다. 다만 이것만으로 특정 포트가 차단됐다고 단정할 수는 없습니다. 같은 시간대의 로그와 서버 상태를 함께 확인하세요. 회사나 학교 네트워크를 이용할 때는 해당 네트워크의 이용 규정을 따르고 관리되는 보안 정책을 임의로 변경하지 마세요.

5. 코어 호환성과 프로토콜 설정 확인하기

Clash는 클라이언트 생태계와 코어 설정에서 널리 쓰이는 이름이지만, 모든 코어가 같은 프로토콜을 지원하는 것은 아닙니다. Clash Meta는 이후 mihomo라는 이름으로 개발되고 있습니다. 오래된 코어는 새 프로토콜이나 새 설정 항목을 인식하지 못할 수 있습니다. 먼저 ‘정보’, 코어 정보 또는 시작 로그에서 클라이언트와 코어 버전을 확인한 뒤 구독 서비스의 요구 사항과 대조하세요. 인터페이스 프로그램만 업데이트하고 실제 실행 중인 코어를 바꾸지 않았다면 호환성 문제는 계속될 수 있습니다.

이 설정은 서비스 제공업체가 제공한 최신 값을 기준으로 해야 합니다. 익숙하다는 이유로 포트를 모두 443으로 바꾸거나 전송 유형을 임의로 변경하지 마세요. 서버 이름과 노드 연결 도메인이 항상 같은 것은 아닙니다. server를 IP 주소로 바꾸면 DNS 조회 방식이 달라지고 인증서 검증에도 영향을 줄 수 있습니다. 인증서 오류가 발생하면 시간을 바로잡거나 이름 또는 서버 인증서를 수정하세요. 인증서 검증 건너뛰기를 기본 해결 방법으로 사용하지 마세요.

6. 노드는 연결되지만 앱이 실패할 때 트래픽 처리 경로 확인하기

내장 테스트는 통과하지만 브라우저나 특정 앱에서 계속 시간 초과가 발생한다면 해당 앱의 요청이 클라이언트에 들어오는지, 어떤 규칙이 적용되는지, 잘못된 정책 그룹으로 전달되는지 확인해야 합니다. 시스템 프록시와 TUN은 서로 다른 트래픽 처리 방식입니다. 둘 중 하나를 켰다고 모든 앱이 같은 연결 경로를 사용하는 것은 아닙니다.

로컬 포트 수신 여부를 확인한 뒤 규칙 점검하기

현재 설정에 mixed-port: 7890이 명시되어 있다면 아래 명령으로 HTTPS 요청 한 번을 로컬 HTTP 프록시를 통과시켜 테스트할 수 있습니다. 7890은 예시 값이며 모든 클라이언트의 고정 포트가 아닙니다. 먼저 실제 설정이나 구성 파일에서 수신 포트를 확인하세요.

# Windows PowerShell에서는 명령 별칭 차이를 피하기 위해 curl.exe 사용
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

• 로컬 포트 연결이 거부됨: 코어가 실행 중인지, 수신 포트가 일치하는지, 다른 프로그램이 포트를 사용 중인지 확인하세요. Windows에서는 netstat -ano | findstr :7890으로 수신 기록과 PID를 확인할 수 있습니다.
• 요청은 클라이언트에 들어오지만 원격 핸드셰이크가 실패함: 노드 주소, 프로토콜 설정, 원격 네트워크를 다시 확인하세요. 브라우저 프록시를 계속 조정할 필요는 없습니다.
• 요청에 REJECT가 적용됨: 규칙 순서와 출처를 확인하세요. 규칙은 순서대로 검사하며 처음 일치하는 규칙이 처리 방식을 결정합니다. 노드만 바꾸지 말고 규칙을 수정해야 합니다.
• TUN을 켰을 때만 실패함: 서비스 권한, 가상 네트워크 어댑터, DNS 처리, 다른 VPN과의 라우팅 충돌을 확인하세요. 먼저 정상 작동이 확인된 시스템 프록시 경로로 되돌린 뒤 TUN 기능을 하나씩 켜세요.

명령이 HTTP 응답을 반환해도 해당 요청이 완료됐다는 뜻일 뿐입니다. 로그에서 실제 연결 경로를 확인하세요. 연결 재사용으로 이전 노드 연결이 유지될 수도 있으므로 노드를 바꾼 뒤에는 새 요청을 보내야 합니다. 필요하다면 해당 연결만 종료하면 되며 전체 설정을 초기화할 필요는 없습니다.

7. 재현에 필요한 기록을 정리해 문의하기

앞의 점검으로도 원인을 찾지 못했다면 ‘시간 초과’ 화면만 보내기보다 다른 사람이 비교해 볼 수 있는 기록을 함께 제공하세요. 테스트할 때는 한 번에 조건 하나만 바꾸고 변경 전후 결과를 기록합니다. 구독, DNS, 코어, 네트워크를 동시에 바꾸면 어떤 변경이 영향을 줬는지 확인할 수 없습니다.

1. 환경 기록: 운영체제, 클라이언트 버전, 실제 코어 버전, 시스템 프록시 또는 TUN 사용 여부
2. 발생 범위 기록: 특정 노드만 실패하는지 전체 노드가 실패하는지, 속도 측정만 실패하는지 실제 HTTPS 요청도 실패하는지, 특정 앱에서만 발생하는지
3. 비교 결과 기록: 같은 노드를 기존 네트워크와 휴대폰 핫스팟에서 테스트한 결과, 테스트 시각, 실패 단계. 예시 수치를 실제 측정 결과처럼 제시하지 마세요.
4. 로그 기록: 로그 수준을 일시적으로 높이고 한 번 재현한 뒤 해당 시간대의 로그를 추출하세요. 민감한 정보를 가린 뒤 제출하고 점검이 끝나면 평소 로그 수준으로 되돌리세요.