Clash 노드 시간 초과로 연결되지 않을 때: 이 순서대로 점검하면 가장 빠릅니다

먼저 유형을 나누세요: 모든 노드 시간 초과인가, 일부 노드 시간 초과인가

점검 전에 지연 시간 테스트를 반복해서 클릭하지 마세요. 노드 시간 초과는 결과일 뿐, 노드가 이미 만료되었다는 뜻은 아닙니다. 구독 만료, 현재 네트워크 단절, 잘못된 시스템 시간, DNS 이상, 포트 충돌, 호환되지 않는 설정값도 모두 timeout으로 표시될 수 있습니다. 먼저 문제가 전체인지 일부인지 확인하면 이후 점검 시간을 줄일 수 있습니다.

모든 노드 시간 초과

같은 구독의 홍콩, 일본, 미국 등 서로 다른 지역 노드가 동시에 시간 초과된다면 공통 요소부터 확인하세요. 구독 상태, 직접 연결 네트워크, Clash 코어 실행 여부, 시스템 프록시 또는 TUN 설정, 현재 네트워크의 프로토콜 제한이 공통 요소입니다. 수십 개 노드가 동시에 고장 날 가능성보다 로컬 환경 전체에 문제가 있을 가능성이 일반적으로 더 높습니다.

어떤 프록시 그룹으로 전환해도 모든 노드가 timeout으로 표시됩니다.
지연 시간 테스트가 5~10초 후 일괄 실패합니다.
로그에 네트워크 연결 불가, DNS 조회 실패 또는 연결 거부가 연속해서 나타납니다.
Clash를 종료한 뒤에도 일반 웹페이지가 직접 연결로 열리지 않습니다.

일부 노드만 시간 초과

같은 구독에서 지연 시간이 45ms, 120ms 등으로 측정되는 노드가 있다면 클라이언트 코어, 기본 네트워크, 구독 형식은 대체로 정상입니다. 이때는 문제가 발생한 노드 자체를 확인하세요. 서버 오프라인, 포트 변경, 프로토콜 설정 변경, 현재 통신사에서의 회선 차단, 해당 노드에서 헬스 체크 주소에 접근할 수 없는 경우 등이 원인일 수 있습니다.

증상	우선 확인할 계층	다음 단계
모든 노드가 동시에 시간 초과	구독, 직접 연결 네트워크, 코어 실행 상태	이 글의 순서대로 첫 단계부터 진행
같은 지역의 일부 노드만 시간 초과	노드 서버 및 해당 지역 회선	같은 지역의 다른 노드로 교차 테스트
지연 시간은 정상이지만 웹페이지가 열리지 않음	규칙, 프록시 그룹, DNS, 시스템 프록시	요청이 실제로 사용한 출구 노드 확인
Wi-Fi에서는 시간 초과, 휴대폰 핫스팟에서는 정상	라우터, 로컬 네트워크 DNS, 통신사 회선	핫스팟 결과를 보존하고 현재 네트워크 확인

1단계: 구독이 유효하고 설정이 업데이트되었는지 확인

먼저 클라이언트의 구독 또는 설정 페이지로 이동하세요. 일반적인 메뉴 이름은 「구독」, 「설정」, 「Profiles」 또는 「설정 관리」입니다. 현재 설정의 업데이트 시간, 잔여 트래픽, 만료일을 확인하세요. 클라이언트마다 메뉴가 조금씩 다르므로 「설정」→「구독 관리」 또는 「Profiles」→ 현재 설정 →「업데이트」와 같은 경로를 찾아보면 됩니다.

구독이 만료되지 않았고 잔여 트래픽이 0GB가 아닌지 확인하세요.
구독을 한 번 수동으로 업데이트하고 성공 또는 실패 메시지를 기록하세요.
업데이트가 완료되면 해당 설정을 다시 불러오세요. 이전 설정 화면에 그대로 머물러 있지 마세요.
프록시 그룹으로 이동해 노드 목록이 실제로 갱신되었는지 확인하세요.
구독 URL을 공개 속도 측정 사이트나 스크린샷에 붙여 넣지 마세요.

구독 업데이트 실패 여부를 판단하는 방법

업데이트 중 HTTP 401 또는 403이 나타나면 구독 인증 정보가 만료되었거나 링크가 재설정되었거나 서버에서 접근을 제한했을 가능성이 큽니다. HTTP 404는 주소가 존재하지 않는다는 뜻입니다. 5xx 응답이 계속되면 구독 서버의 일시적인 장애를 의심해야 합니다. connection timeout이 표시되면 직접 연결로 구독 URL에 접근할 수 있는지 계속 확인하세요. 많은 클라이언트가 기본적으로 직접 연결을 사용해 설정을 업데이트하기 때문입니다.

구독 업데이트가 성공했다고 해서 노드 설정값이 반드시 유효한 것은 아닙니다. 설정 세부 정보를 열어 노드 수가 갑자기 0개가 되었는지, 새 설정이 여전히 이전 provider 캐시를 참조하는지 확인하세요. 프록시 컬렉션을 사용하는 설정은 다음과 같은 구조일 수 있으며, 실제 노드 목록은 기본 설정이 아니라 provider 파일에서 가져옵니다:

proxy-providers:
  provider-main:
    type: http
    url: "구독 주소"
    path: ./providers/provider-main.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

interval: 3600은 3600초마다 업데이트를 시도한다는 뜻입니다. 헬스 체크의 interval: 600은 600초마다 확인한다는 의미입니다. 기본 설정은 업데이트되었지만 provider 캐시가 그대로라면 만료된 노드가 계속 표시될 수 있습니다. 클라이언트의 프록시 제공자 페이지에서 한 번 수동 업데이트한 다음 코어를 재시작하세요.

2단계: 프록시를 끄고 직접 연결 네트워크 확인

Clash는 현재 네트워크를 통해 프록시 서버와 연결을 설정합니다. 기본 네트워크가 끊긴 상태라면 모든 노드가 자연스럽게 시간 초과됩니다. 먼저 클라이언트에서 「시스템 프록시」를 끄고, TUN 모드를 사용 중이라면 TUN도 잠시 끄세요. 브라우저를 완전히 종료한 뒤 다시 열고 평소 직접 연결하는 웹사이트에 접속하세요.

최소 테스트 두 가지

시스템 프록시와 TUN을 끄고 현재 Wi-Fi로 직접 연결 웹사이트를 엽니다.
Clash 설정은 그대로 둔 채 컴퓨터나 휴대폰을 휴대폰 핫스팟에 연결한 뒤 같은 노드들을 다시 테스트합니다.

현재 Wi-Fi에서는 모두 시간 초과되지만 휴대폰 핫스팟에서는 즉시 정상으로 돌아온다면, 예를 들어 노드 지연 시간이 timeout에서 80~250ms로 바뀐다면 문제는 원래 네트워크, 라우터 또는 통신사 경로에 있으며 Clash 설정에는 없습니다. 먼저 광모뎀이나 라우터를 재시작하고, 라우터의 인터넷 연결 상태와 DNS 설정을 확인한 다음 네트워크 관리자에게 외부 연결 제한이 설정되어 있는지 문의하세요.

Windows에서는 터미널을 열어 기본 연결 테스트를 실행할 수도 있습니다. 여기서 확인하는 것은 로컬 네트워크와 DNS이며 프록시 노드 속도가 아닙니다:

ping 1.1.1.1
nslookup example.com

ping이 차단되었다고 해서 반드시 인터넷이 끊긴 것은 아닙니다. 하지만 도메인 조회에 실패하고 브라우저의 직접 연결로도 웹페이지가 열리지 않는다면 먼저 네트워크를 복구해야 합니다. macOS와 Linux에서도 터미널에서 같은 명령을 사용할 수 있으며, 일부 시스템에서는 nslookup 대신 dig example.com을 사용해야 합니다.

공용 Wi-Fi에서 추가로 확인할 사항

호텔, 공항, 학교 네트워크에는 인증 페이지가 있는 경우가 많습니다. Wi-Fi에 연결되어 인터넷이 되는 것처럼 보여도 실제로는 브라우저에서 로그인을 완료해야 합니다. 프록시를 끈 뒤 일반 HTTP 페이지에 접속해 인증 화면으로 이동하는지 확인하세요. 인증을 완료하기 전에는 Clash의 연결이 차단되거나 리디렉션되어 모든 노드가 시간 초과되는 것처럼 보일 수 있습니다.

3단계: 시스템 시간을 맞춘 뒤 코어와 로컬 포트 확인

시스템 시간 오차는 핸드셰이크를 방해합니다

TLS 인증서 검증은 날짜와 시간에 의존합니다. 시스템 시간이 몇 분 또는 몇 시간만 어긋나도 구독 요청, WebSocket TLS, gRPC TLS 및 기타 암호화 연결이 실패할 수 있습니다. Windows에서 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 자동 시간 설정과 자동 시간대 설정을 켠 다음 지금 동기화를 클릭하세요. macOS에서는 「시스템 설정」→「일반」→「날짜 및 시간」으로 이동해 자동 설정을 켜면 됩니다.

동기화가 끝나면 클라이언트를 완전히 종료한 뒤 다시 시작하세요. 노드만 전환하지 마세요. 이전 연결과 DNS 캐시가 코어 프로세스에 남아 있을 수 있습니다. 로그에 certificate has expired, not yet valid 또는 handshake failure가 나타난다면 시간과 인증서 체인을 우선 확인해야 합니다.

Clash 또는 mihomo 코어가 실행 중인지 확인

그래픽 인터페이스가 열린다고 해서 코어 프로세스가 정상이라는 뜻은 아닙니다. 「설정」→「코어」 또는 「설정」→「Clash 코어」로 이동해 상태가 실행 중인지 확인하세요. Clash Meta의 후속 코어인 mihomo를 사용하는 클라이언트에서는 로그와 프로세스 이름이 mihomo로 표시될 수 있습니다. 코어가 반복해서 시작되지 않는다면 마지막 재시도 메시지만 보지 말고 로그의 첫 번째 error를 확인하세요.

포트 충돌 확인

일반적인 로컬 HTTP 및 SOCKS 혼합 포트는 7890이며, 제어 포트는 보통 9090입니다. 정확한 값은 현재 YAML과 클라이언트 설정을 기준으로 확인하세요. 다음은 흔히 사용하는 설정 형식입니다:

mixed-port: 7890
external-controller: 127.0.0.1:9090
allow-lan: false
mode: rule
log-level: info

다른 프록시 프로그램이 이미 7890을 사용 중이면 Clash가 해당 포트를 수신하지 못할 수 있습니다. Windows에서는 터미널에서 다음을 실행하세요:

netstat -ano | findstr :7890
netstat -ano | findstr :9090

macOS 또는 Linux에서는 다음을 실행할 수 있습니다:

lsof -nP -iTCP:7890
lsof -nP -iTCP:9090

오래된 프로세스가 포트를 사용 중이라면 먼저 해당 프록시 프로그램을 종료하거나 「설정」→「포트 설정」에서 mixed port를 7891처럼 사용 중이지 않은 포트로 변경하세요. 변경 후에는 시스템 프록시도 새 포트를 사용하도록 동기화해야 합니다. YAML만 수정하고 시스템 프록시를 업데이트하지 않으면 브라우저가 계속 이전 주소인 127.0.0.1:7890에 연결합니다.

4단계: 노드 프로토콜 설정과 구성 호환성 확인

구독이 유효하고 직접 연결도 정상이며 코어까지 실행 중이라면 노드 설정값을 확인하세요. 노드 이름만 보고 프로토콜을 추측하지 마세요. 서버에서 제공한 내용을 기준으로 서버 주소, 포트, UUID 또는 비밀번호, 전송 방식, TLS, SNI, ALPN, Reality 설정을 중점적으로 확인해야 합니다.

시간 초과를 일으키기 쉬운 설정 차이

server와 port: 서버를 이전한 뒤에도 예전 주소나 포트를 사용하고 있습니다.
network: 서버는 WebSocket을 사용하는데 클라이언트는 TCP 직접 연결로 설정되어 있습니다.
servername 또는 sni: TLS 핸드셰이크에 잘못된 도메인이 사용되었습니다.
ws-opts.path: WebSocket 경로에 앞쪽 슬래시가 없거나 이전 값이 남아 있습니다.
grpc-opts.grpc-service-name: gRPC 서비스 이름이 서버와 일치하지 않습니다.
Reality 설정: public-key, short-id 또는 servername이 일치하지 않습니다.
UDP: 노드에서 UDP를 활성화하지 않았는데 UDP가 필요한 요청에 사용되고 있습니다.

이전 버전의 Clash 코어는 일부 새로운 필드를 인식하지 못해 설정을 불러오는 단계에서 바로 오류를 내거나 호환되지 않는 노드를 건너뛸 수 있습니다. 설정에 Reality, Hysteria2, TUIC 등의 유형이 포함되어 있다면 해당 프로토콜을 지원하는 mihomo 버전을 사용 중인지 확인하세요. 버전이 너무 오래되었다면 클라이언트의 「설정」→「코어」→「코어 업데이트」를 통해 먼저 업데이트한 뒤 설정을 다시 불러오세요.

로그에 unsupported proxy type, field not found 또는 설정 파싱 실패가 나타난다면 문제는 설정 로딩 계층에서 발생한 것이며 아직 노드 연결 단계에 진입하지 않은 상태입니다. 이때 지연 시간 테스트를 반복해도 의미가 없으므로 코어 호환성이나 구독 형식을 먼저 해결해야 합니다.

헬스 체크 시간 초과가 모든 웹사이트에 접속할 수 없다는 뜻은 아닙니다

클라이언트의 지연 시간 테스트는 보통 HTTP 204를 반환하는 가벼운 페이지처럼 지정된 URL에 접속합니다. 테스트 주소 자체가 노드의 출구, DNS 또는 현재 네트워크에 의해 별도로 제한될 수 있습니다. 테스트 URL을 다른 안정적인 HTTPS 주소로 임시 변경해 교차 확인할 수 있지만, 대용량 다운로드 주소를 헬스 체크에 사용하면 트래픽과 테스트 시간이 늘어나므로 피하세요.

노드가 실제로 사용 가능한지 판단하려면 헬스 체크 지연 시간, 로그의 연결 결과, 실제 웹 요청이라는 세 가지를 함께 확인해야 합니다. 한 번 5000ms 시간 초과가 발생한 것은 제한 시간 안에 해당 테스트가 완료되지 않았다는 뜻일 뿐입니다. 세 번 연속 시간 초과되고 실제 요청도 실패해야 노드나 회선 장애에 가깝다고 판단할 수 있습니다.

5단계: 시스템 프록시, TUN, DNS가 속한 계층 확인

시스템 프록시 모드

시스템 프록시 모드는 시스템 프록시 설정을 따르는 앱의 트래픽을 주로 가로챕니다. 먼저 클라이언트의 「설정」→「시스템 프록시」로 이동해 기능을 껐다가 다시 켜고, 프록시 주소가 127.0.0.1인지와 포트가 mixed port와 일치하는지 확인하세요. 브라우저 확장 프로그램, 다른 프록시 소프트웨어, 수동 PAC 설정이 시스템 설정을 덮어쓸 수 있으므로 점검 중에는 이러한 추가 진입점을 잠시 비활성화하세요.

노드 테스트는 정상인데 특정 앱만 인터넷에 연결되지 않는다면 문제는 대개 노드에 있지 않습니다. 해당 앱이 시스템 프록시를 읽는지 또는 자체적으로 프록시 포트를 지정했는지 확인하세요. 먼저 브라우저로 검증한 뒤 문제가 있는 앱과 결과를 비교하면 됩니다.

TUN 모드

TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 가로채며 일반적으로 관리자 권한이 필요합니다. 시작에 실패하면 클라이언트 로그에 interface, route, permission 또는 device 관련 오류가 나타날 수 있습니다. Windows에서는 관리자 권한으로 클라이언트를 실행하고, macOS에서는 처음 활성화할 때 네트워크 확장 프로그램 또는 VPN 구성을 승인해야 합니다. 시스템에 다른 VPN이 있다면 라우팅 테이블과 가상 네트워크 카드 충돌을 피하기 위해 먼저 완전히 종료하세요.

TUN을 점검할 때는 이분법으로 확인하세요. TUN을 끄고 시스템 프록시만 켭니다. 브라우저가 다시 정상 작동한다면 노드 자체는 사용할 수 있고 문제는 TUN 권한, 라우팅 또는 DNS에 집중됩니다. 두 모드 모두 시간 초과라면 노드와 회선 계층을 계속 확인하세요.

DNS 이상을 식별하는 방법

노드 지연 시간은 정상인데 도메인을 입력하면 열리지 않고, 알고 있는 IP 주소에 직접 접속하면 응답이 있다면 DNS를 확인해야 합니다. mihomo 설정에서 흔히 사용하는 필드는 dns.enable, nameserver, fallback, fake-ip 등입니다. 원래 설정을 이해하지 못한 상태에서 모든 DNS 항목을 한꺼번에 변경하지 마세요.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

1053 포트도 반드시 사용 중이 아니어야 합니다. TUN과 fake-ip를 사용한다면 TUN을 끈 뒤 다시 테스트해 이전 라우팅과 캐시의 영향을 피하세요. Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지울 수 있으며, macOS에서는 네트워크나 시스템을 재시작한 뒤 다시 테스트하면 됩니다. 캐시 삭제는 보조 조치일 뿐 잘못된 상위 DNS 설정을 고치지는 못합니다.

6단계: 마지막에 노드를 교체하고 로그로 결론 확인

앞의 공통 요소가 모두 정상일 때만 노드 교체 단계로 넘어가세요. 같은 지역에서 서로 다른 노드 2~3개를 선택해 각 노드를 약 10초 간격으로 세 번씩 연속 테스트합니다. 한 번에 수십 개 노드를 테스트하지 마세요. 동시에 실행되는 헬스 체크가 네트워크 속도 제한을 유발할 수 있고 로그도 읽기 어려워집니다.

노드 A를 선택해 지연 시간을 테스트하고 실제 웹페이지를 엽니다.
같은 지역의 노드 B를 선택해 동일한 작업을 반복합니다.
다른 지역의 노드 C로 전환해 지역 회선 문제인지 판단합니다.
휴대폰 핫스팟으로도 전환해 서로 다른 네트워크의 비교 결과를 남깁니다.

가정용 인터넷에서는 노드 A와 B가 시간 초과되지만 휴대폰 핫스팟에서는 정상이라면 현재 통신사의 경로 문제일 가능성이 큽니다. 같은 노드가 두 네트워크에서 모두 시간 초과되고 같은 구독의 다른 노드는 정상이라면 노드 서버나 포트 문제일 가능성이 큽니다. 모든 지역의 노드가 두 네트워크에서 모두 시간 초과된다면 구독과 프로토콜 설정 계층으로 돌아가 다시 확인해야 합니다.

로그에서 확인할 키워드

i/o timeout: 연결 또는 읽기·쓰기가 제한 시간 안에 완료되지 않았습니다.
connection refused: 대상 주소에는 도달했지만 해당 포트가 연결을 거부했습니다.
network is unreachable: 로컬 라우팅 또는 네트워크 인터페이스로 대상에 도달할 수 없습니다.
no such host: 도메인 조회에 실패했습니다.
TLS handshake timeout: TLS 핸드셰이크가 시간 초과되었습니다. 회선, SNI, 시간, 서버 설정을 확인하세요.
authentication failed: 인증 설정이 일치하지 않거나 인증 정보가 만료되었습니다.

로그 수준은 먼저 info를 사용하세요. 정보가 부족할 때만 잠시 debug로 전환해 한 번 재현한 뒤 원래대로 되돌립니다. 로그를 공유하기 전에는 구독 URL, UUID, 비밀번호, 토큰, 서버 인증 정보, 개인 네트워크 정보를 삭제하세요.

자주 하는 오판과 가장 빠른 해결 경로

오판 1: timeout이 보이면 즉시 재설치

재설치는 클라이언트 파일만 초기화할 뿐 구독 만료, 서버 오프라인, 통신사 회선, 잘못된 시스템 시간은 해결하지 못합니다. 기존 로그를 잃어 문제를 더 찾기 어려워질 수도 있습니다. 먼저 필요한 설정을 내보낸 뒤 기본 계층 점검을 진행하세요.

오판 2: 지연 시간이 짧을수록 반드시 연결된다

지연 시간 테스트는 특정 테스트 요청만 반영합니다. 40ms 헬스 체크가 정상이어도 대상 웹사이트 접속을 보장하지 않으며, 규칙이 요청을 해당 노드로 보낸다는 보장도 없습니다. 웹페이지가 열리지 않으면 연결 로그에서 도메인이 어떤 규칙에 일치했는지, 어느 프록시 그룹으로 들어갔는지, 최종적으로 어떤 노드가 선택되었는지 확인하세요.

오판 3: 실제 선택 결과를 확인하지 않고 프록시 그룹만 전환

규칙 모드에서는 요청이 먼저 규칙과 일치한 뒤 지정된 프록시 그룹으로 전달됩니다. 「노드 선택」이라는 그룹을 수동으로 바꿔도 대상 도메인이 다른 「자동 선택」 그룹에 일치할 수 있습니다. 로그에서 DOMAIN-SUFFIX, MATCH와 같은 규칙 결과를 확인할 수 있어야 합니다. 점검 중에는 교차 테스트를 위해 잠시 전역 모드를 사용할 수 있지만 테스트가 끝나면 원래 규칙 모드로 되돌리세요.

10분 빠른 점검 목록

1분차: 모든 노드 시간 초과인지 일부 노드 시간 초과인지 확인합니다.
2분차: 구독 만료일, 잔여 트래픽, 업데이트 시간을 확인합니다.
3분차: 프록시와 TUN을 끄고 직접 연결 네트워크를 확인합니다.
4분차: 휴대폰 핫스팟으로 전환해 네트워크를 비교합니다.
5분차: 시스템 시간을 동기화하고 코어를 재시작합니다.
6분차: 7890 등 로컬 포트가 사용 중인지 확인합니다.
7분차: 로그의 첫 번째 오류를 확인합니다.
8분차: 프로토콜, TLS, SNI, 전송 설정을 확인합니다.
9분차: TUN을 끄고 시스템 프록시만 사용해 다시 테스트합니다.
10분차: 다른 지역의 노드를 선택해 최종 교차 테스트를 진행합니다.

이 순서의 핵심은 모든 노드가 공유하는 요소를 먼저 확인한 뒤 개별 노드를 확인하는 것입니다. 모두 시간 초과되면 구독, 네트워크, 코어, 포트를 우선 처리하고, 일부만 시간 초과되면 노드 서버, 프로토콜 설정, 회선을 우선 확인하세요. 각 단계의 테스트 결과를 남겨 두면 같은 문제가 다시 발생했을 때 해당 계층으로 바로 이동할 수 있습니다.