Clash 노드 전체 시간 초과 해결 방법: 구독, 시스템 시간, 포트 점검 순서

속도 테스트 실패와 실제 연결 실패를 먼저 구분하세요

Clash 클라이언트에서 ‘시간 초과’는 보통 요청이 정해진 시간 안에 완료되지 않았다는 뜻이며, 구독이 만료됐다는 의미는 아닙니다. 지연 시간 테스트는 지정한 노드를 통해 테스트 주소에 접속합니다. 노드 핸드셰이크, 도메인 조회, 테스트 사이트 응답 중 어느 단계에서든 실패하면 시간 초과로 표시될 수 있습니다. Clash는 클라이언트 생태계에서 널리 쓰이는 일반적인 명칭이며, 실제 화면과 기능은 사용 중인 클라이언트와 실행 중인 코어에 따라 다릅니다. mihomo는 Clash Meta라는 이름을 사용하는 설정 안내에서도 자주 볼 수 있습니다.

먼저 문제가 발생하는 범위를 기록하세요. 모든 노드의 속도 테스트가 실패하는지, 특정 프록시 그룹만 실패하는지, 속도 테스트만 실패하고 웹페이지는 열리는지, 모든 프록시 요청이 실패하는지 확인합니다. 설정 업데이트 직후인지, Wi-Fi를 바꾼 뒤인지도 함께 적어 두세요. 이런 정보가 속도 테스트를 수십 번 반복하는 것보다 유용합니다.

일괄 속도 테스트를 중단하고 노드 하나를 직접 선택하세요. 규칙 모드를 사용한다면 대상 요청이 해당 노드가 포함된 프록시 그룹에 실제로 연결되는지 확인합니다.
클라이언트의 ‘연결’과 ‘로그’ 화면을 열고, 접속 가능한 HTTPS 페이지를 방문하세요. 같은 시각의 대상 주소, 적용된 규칙, 오류 내용을 기록합니다.
웹페이지는 열리는데 속도 테스트만 모두 실패한다면 테스트 주소, 테스트 시간 제한, 동시 실행 수부터 확인하세요. 클라이언트를 먼저 다시 설치할 필요는 없습니다.

1단계: 로컬 네트워크와 구독 상태 확인

로그인 인증과 네트워크 변경부터 확인하세요

시스템 프록시와 TUN을 잠시 끄고 일반 인터넷 연결이 되는지 확인하세요. 호텔, 학교, 공용 Wi-Fi에서는 먼저 웹페이지에서 인증해야 할 수 있습니다. 인증을 마치기 전에는 Wi-Fi 아이콘이 정상이어도 모든 노드 연결이 실패할 수 있습니다. 휴대폰 핫스팟을 비교용으로 사용할 수도 있습니다. 설정, 노드, 대상은 그대로 두고 연결 네트워크만 바꾸세요. 핫스팟에서는 연결되지만 기존 네트워크에서는 되지 않는다면 기존 네트워크의 DNS, 외부 접속 제한 또는 라우터를 확인해야 합니다.

구독 업데이트에 성공해도 서비스가 계속 사용 가능한 것은 아닙니다

계정 상태: 서비스 제공업체 페이지에서 만료일, 남은 데이터, 기기 수 또는 동시 연결 제한을 확인하세요. 페이지에 표시된 시간대도 확인해야 합니다.
업데이트 결과: 구독 업데이트 기록과 노드 수를 확인하세요. HTTP 401이나 403은 인증 정보 또는 접근 제한과 관련된 경우가 많고, 429는 요청 빈도 제한을 의미할 수 있습니다. 정확한 원인은 서비스 측 안내와 함께 확인해야 합니다.
설정 적용 여부: 다운로드에 성공했더라도 파일을 받은 것일 뿐입니다. 새 설정이 현재 활성화되어 있는지, 설정 항목 오류로 인해 코어가 로드를 거부하지 않았는지 확인하세요.
노드 출처: 여러 지역의 노드가 같은 진입 도메인을 공유할 수 있습니다. 따라서 ‘전체 시간 초과’는 모든 서버가 동시에 고장 난 것이 아니라 공통 진입점에 문제가 생긴 것일 수도 있습니다.

구독을 업데이트할 때 프록시가 필요하다면 연결이 끊긴 노드 때문에 업데이트가 계속 실패할 수 있습니다. 서비스 제공업체가 지원하는 네트워크에서 업데이트하거나 제공업체의 로컬 설정 가져오기 방법을 사용하세요. 구독 URL에는 보통 접속 인증 정보가 포함되므로 공개 속도 테스트 사이트, 변환 서비스, 게시판에 붙여 넣지 마세요.

2단계: 시스템 시간 동기화 및 핸드셰이크 조건 확인

TLS 인증서 유효 기간 확인과 일부 프로토콜의 인증에는 시스템 시계가 필요합니다. 기기가 절전 모드에서 깨어난 뒤 시간이 잘못되거나 날짜를 직접 잘못 설정하면 여러 노드가 동시에 실패할 수 있습니다. 작업 표시줄의 시각만 보지 말고 날짜, 연도, 시간대, 자동 동기화 결과도 확인하세요.

Windows 11: ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 ‘시간 자동 설정’을 켜고, 시간대를 확인한 뒤 ‘지금 동기화’를 선택하세요.
macOS: ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’에서 날짜와 시간 자동 설정을 켜세요. 시스템 버전에 따라 메뉴 이름이 조금 다를 수 있습니다.
Linux: timedatectl status를 실행해 시스템 시계 동기화 상태를 확인하세요. systemd를 사용하는 시스템에서는 해당 환경의 관리 지침에 따라 시간 동기화 서비스를 활성화할 수 있습니다.

예를 들어 로그에 x509: certificate has expired or is not yet valid가 표시되면 먼저 시스템 시간을 신뢰할 수 있는 시간 정보와 비교하세요. 시간을 맞춘 뒤에도 같은 오류가 계속될 때 서버 인증서를 확인하면 됩니다. 인증서 검증을 끄는 방식으로 문제를 숨기지 마세요. skip-cert-verify로 잘못된 비밀번호, 연결할 수 없는 포트, 프로토콜 매개변수 불일치를 해결할 수는 없습니다.

3단계: 코어 실행 상태와 포트 점유 확인

노드 목록이 표시된다고 프록시 코어가 정상 실행 중인 것은 아닙니다. 그래픽 인터페이스가 설정을 읽었더라도 포트 점유로 코어가 시작 직후 종료될 수 있습니다. 클라이언트 로그에서 시작 실패, 설정 구문 오류, address already in use를 찾아 실제로 수신 대기 중인 포트도 확인하세요.

아래에서는 로컬 혼합 프록시 포트 7890을 예로 듭니다. 이는 예시일 뿐 모든 클라이언트의 기본 설정은 아닙니다. 클라이언트의 포트 설정이나 적용된 설정에서 mixed-port, port, socks-port 값을 확인하세요. 제어 인터페이스는 9090을 사용하는 경우가 있습니다. 이 포트는 코어 관리용이므로 브라우저의 HTTP 프록시 포트로 지정하면 안 됩니다.

7890 포트를 사용 중인 프로세스 확인

Windows에서는 PowerShell에서 수신 주소와 프로세스 ID를 확인한 뒤 해당 프로그램을 조회할 수 있습니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

두 번째 명령의 1234는 예시입니다. 첫 번째 명령에서 실제로 확인한 프로세스 ID로 바꾸세요. macOS와 일반적인 Linux 시스템에서는 다음 명령을 사용할 수 있습니다.

lsof -nP -iTCP:7890 -sTCP:LISTEN

수신 프로세스가 다른 프록시 클라이언트라면 해당 프로그램을 정상 종료한 뒤 현재 클라이언트를 시작하세요. 정체를 모르는 시스템 프로세스를 강제 종료하지 마세요. 포트를 7891로 바꾼다면 앱의 수동 프록시 설정도 함께 수정해야 합니다. 일반적인 로컬 사용이라면 루프백 주소에서 수신하도록 설정하면 충분하며, 문제 해결을 위해 LAN 접근을 켤 필요는 없습니다.

4단계: 프록시를 명시해 요청 범위 좁히기

TUN을 잠시 끄고 노드 하나를 직접 선택하세요. 지정한 로컬 프록시 주소로 요청을 보내면 앱이 시스템 프록시 설정을 따르는지에 관한 불확실성을 줄일 수 있습니다. 다만 요청 결과는 여전히 현재 코어 모드와 규칙의 영향을 받습니다. 테스트 중 연결 패널을 열어 트래픽이 DIRECT로 분류되지 않았는지 확인하세요.

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 --max-time 15 \
  --output /dev/null --write-out "%{http_code}\n" \
  https://cp.cloudflare.com/generate_204

이 명령은 macOS 또는 Linux 셸에서 사용할 수 있습니다. Windows PowerShell에서는 아래 한 줄 명령으로 curl.exe를 명시적으로 실행하세요.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output NUL --write-out "%{http_code}\n" https://cp.cloudflare.com/generate_204

204 응답: 이번 요청에서 로컬 프록시를 통해 대상에 접속한 것입니다. 연결 패널에서 적용된 프록시 그룹과 외부 연결 경로를 추가로 확인하세요.
즉시 연결 거부: 먼저 로컬 포트, 수신 주소, 코어 프로세스를 확인하세요. 로컬 연결이 이미 설정된 상태라면 이후 원격 연결에서 거부됐을 수도 있으므로 로그를 함께 살펴봐야 합니다.
대기 후 시간 초과: 원격 연결, DNS, 핸드셰이크, 테스트 대상을 확인하세요. curl 결과만으로 특정 프로토콜의 고장이라고 단정하지 마세요.

특정 노선에서 테스트 주소 접속이 제한될 수도 있으므로, 접속 가능 여부를 아는 다른 HTTPS 주소로 교차 확인하세요. 테스트 시간 제한이 1000밀리초라면 문제를 살펴보는 동안 5000밀리초로 높여 두 번 순차 테스트할 수 있습니다. 이는 문제 해결을 위한 예시이며 권장 기본값은 아닙니다. 시간 제한을 늘리면 대기 시간만 길어질 뿐 인증 오류나 사용할 수 없는 진입점을 고치지는 못합니다.

5단계: 로그 키워드로 DNS, 인증, 프로토콜 문제 찾기

로그 수준을 일시적으로 info로 설정하고, 정보가 부족할 때만 debug를 사용하세요. 요청을 한 번만 재현한 뒤 시간대에 맞는 기록을 찾습니다. 확인이 끝나면 로그 수준을 원래대로 되돌려 불필요한 로그가 계속 쌓이지 않도록 하세요. 로그를 공유하기 전에는 구독 주소, 비밀번호, 토큰 등 계정 정보를 삭제하세요.

로그 단서	먼저 확인할 항목	다음 조치
`lookup`、`no such host`	노드 진입 도메인 또는 대상 도메인 조회 실패	어떤 도메인을 조회 중인지 구분하고, DNS 업스트림에 연결할 수 있는지와 노드 도메인이 여전히 유효한지 확인하세요.
`i/o timeout`、`context deadline exceeded`	연결 또는 요청 시간 초과	앞뒤 로그를 확인해 DNS, TCP, TLS 중 어느 단계에서 멈췄는지 파악한 뒤 다른 네트워크에서도 비교하세요.
`connection refused`	대상 주소의 포트에서 연결을 받지 않음	거부가 로컬에서 발생했는지 원격에서 발생했는지 확인하고, 포트 설정과 서비스 상태를 점검하세요.
`authentication failed`	인증 정보 또는 프로토콜 매개변수 불일치	원본 구독을 업데이트하고 인증 정보를 확인하세요. 노드 표시 이름만 직접 바꾸는 것으로는 해결되지 않습니다.
`TLS handshake`、`x509`	시각, 인증서, SNI 또는 핸드셰이크 연결	먼저 시스템 시간을 동기화한 다음 설정의 서버 이름과 서버 측 요구 사항을 확인하세요.
`unsupported`、`unknown proxy type`	코어에서 지원하지 않는 프로토콜 또는 설정 항목	실제로 실행 중인 코어의 종류와 버전을 확인하고 구독과 호환되는 클라이언트를 사용하세요.

진입 도메인 조회와 대상 도메인 조회는 별개입니다

코어가 노드 서버에 연결하려면 먼저 노드 서버 도메인을 올바르게 조회해야 합니다. 브라우저에서 방문하는 사이트 도메인은 그다음 단계에서 조회됩니다. 두 도메인은 서로 다른 경로로 조회될 수 있습니다. 노드 진입점의 도메인 조회부터 실패한다면 웹사이트 분기 규칙을 계속 바꿔도 대개 도움이 되지 않습니다. nslookup으로 노드 진입 도메인을 조회해 볼 수 있지만, 시스템 조회에 성공했다고 코어의 DNS 설정까지 정상이라는 뜻은 아닙니다.

mihomo의 DNS 설정에는 nameserver, default-nameserver, proxy-server-nameserver가 관련될 수 있습니다. 지원 범위는 현재 사용하는 코어의 문서를 확인하세요. 연결이 끊긴 프록시 하나로 모든 DNS 요청을 강제로 보내면 DNS 조회와 연결이 서로를 기다리는 문제가 생길 수 있습니다.

프로토콜 매개변수는 관련 항목을 함께 확인하세요

구형 Clash 코어가 mihomo의 기능을 모두 지원한다고 볼 수는 없습니다. 설정에 Hysteria2 같은 프로토콜이 포함되어 있다면 현재 실행 중인 코어가 이를 지원하는지 확인하세요. UDP 기반 전송은 현재 네트워크에서 제한될 수도 있습니다. TCP 기반 노드는 연결되는데 UDP 기반 노드가 모두 실패한다면, 무작정 비밀번호를 바꾸기보다 핫스팟으로 비교하는 편이 원인을 찾는 데 도움이 됩니다. 서버 포트, 인증, SNI, 전송 방식은 원본 구독 설정을 기준으로 확인하세요. 설정 변환 과정에서 일부 항목이 누락될 수 있습니다.

6단계: 기본 프록시 연결을 복구한 뒤 TUN과 규칙 확인

프록시 주소를 명시한 요청은 성공하고 TUN을 켰을 때만 실패한다면 라우팅, 권한, DNS 가로채기, 다른 가상 네트워크 어댑터를 확인해야 합니다. TUN은 시스템 네트워크 트래픽을 가로채는 기능이지 노드의 연결 가능성을 높이는 스위치가 아닙니다. 만료된 계정을 되살리거나 서버 포트 오류를 해결할 수는 없습니다.

다른 VPN, 프록시 클라이언트, 라우팅을 변경할 수 있는 프로그램을 종료해 트래픽을 가로채는 기능이 동시에 작동하지 않도록 하세요.
클라이언트에서 요구하는 서비스 모드 또는 시스템 권한을 확인한 뒤 TUN만 따로 켜고 연결 로그를 보관하세요.
DNS 요청이 올바르게 가로채지는지, 프록시 서버 자체의 연결이 다시 터널 안으로 들어가지는 않는지 확인하세요.
TUN을 사용할 때만 일부 HTTPS 사이트에서 멈춘다면 경로 MTU 등의 문제를 살펴보세요. 기존 값을 기록한 뒤 한 항목씩 테스트하고, MTU 조정을 모든 시간 초과 문제의 첫 번째 해결책으로 삼지 마세요.

규칙 모드에서는 실제로 어떤 프록시 그룹이 선택되었는지도 확인해야 합니다. select 그룹이 다른 자동 그룹을 선택했을 수 있고, 자동 그룹은 이전 테스트 결과를 계속 사용할 수도 있습니다. 노드를 직접 선택한 뒤 연결 경로를 확인하면 그룹이 중첩되어 생기는 혼란을 줄일 수 있습니다. 비교를 위해 잠시 전역 모드를 사용할 수도 있지만, 다른 앱의 트래픽 경로가 바뀌지 않도록 테스트 후 원래 모드로 되돌리세요.

문제 해결 결과 기록 및 설정 복구 순서

문제가 계속되는데 ‘전체 시간 초과’라는 설명만으로는 원인을 찾기 어렵습니다. 아래 정보를 정리하면 서비스 제공업체에 진입점 상태를 문의하거나 클라이언트 관리자가 코어 또는 시스템 트래픽 가로채기 문제인지 판단하는 데 도움이 됩니다.

운영체제 버전, 클라이언트 버전, 실제 코어 이름과 버전을 확인하세요. 기기의 ‘정보’ 화면이나 시작 로그에서 확인할 수 있습니다.
문제가 시작된 시각과 그 전에 구독 업데이트, 시스템 업그레이드, 네트워크 변경, TUN 활성화가 있었는지 기록하세요.
같은 노드를 기존 네트워크와 휴대폰 핫스팟에서 각각 사용한 결과, 프록시 주소를 명시한 요청의 응답을 기록하세요.
오류 앞뒤 문맥을 포함한 로그 일부를 개인정보를 가린 상태로 준비하고, 대상 요청 시각, TUN 사용 여부, 실제 적용된 프록시 그룹을 함께 적으세요.

복구할 때는 먼저 프록시 주소를 명시해 노드 하나로 요청을 완료한 다음 시스템 프록시를 확인하고, 필요한 경우에만 TUN과 자동 프록시 그룹을 켜세요. ‘로컬 네트워크와 계정 → 시스템 시간 → 코어와 포트 → DNS와 핸드셰이크 → 트래픽 가로채기와 규칙’ 순서로 확인하면 진입점 장애, 테스트 오진, 로컬 설정 문제를 구분할 수 있습니다. 호환되는 클라이언트를 다시 선택해야 한다면 Clash 클라이언트 다운로드 센터를 확인하세요. 가져오기와 기본 설정은 사용 안내를 참고하세요.