문제 해결 예상 읽기 시간 8분

Clash 노드 타임아웃 연결 불가 해결법: 구독, 포트, 프로토콜 점검 순서

노드 전체 타임아웃이 노드 실패를 의미하지는 않습니다. 구독 유효성, 포트 점유, 시스템 프록시, 프로토콜·커널 매칭, DNS 오염 5단계로 원인을 찾고 각 단계별 해결법을 제시합니다.

점검 전 문제 범위부터 판단하기

지연 시간 목록이 온통 "timeout"으로 표시되면 반사적으로 노드 실패나 구독 만료를 의심하게 되지만, 이는 여러 가능한 원인 중 하나일 뿐입니다. 더 흔한 경우는 로컬 환경 문제입니다: 포트가 점유되었거나, 시스템 프록시가 적용되지 않았거나, 커널 버전이 프로토콜과 맞지 않거나, DNS 해석이 오염된 경우입니다. 이런 문제들은 지연 테스트 전체를 실패시켜 "모든 노드 사망"과 거의 동일하게 보이지만, 실제로는 노드 자체와 아무 관련이 없습니다.

먼저 최소한의 판단을 해보길 권합니다: 시스템 기본 브라우저를 열어 해외 사이트에 직접 접속해봅니다. 연결이 안 되고 프록시를 거치는 흔적도 없다면 링크 레이어가 뚫리지 않았을 가능성이 큽니다. 반면 클라이언트 화면에는 "연결됨"이라고 나오는데 웹페이지가 계속 로딩 중이라면, 아래 단계로 하나씩 점검해야 합니다. 처음부터 구독을 바꾸거나 노드를 삭제하는 건 단순한 문제를 복잡하게 만들 뿐이니 피하세요.

1단계: 구독 유효성 확인

구독 링크 자체의 만료는 가장 쉽게 간과되는 부분입니다. 특히 무료 구독이나 연장하지 않은 만료 구독에서 자주 발생합니다. 확인 방법은 간단합니다:

  • 클라이언트에서 "구독 업데이트"를 수동으로 눌러 노드 수 변화나 오류 메시지가 뜨는지 확인합니다.
  • 구독 링크를 브라우저 주소창에 붙여넣어 직접 접속해봅니다. 빈 텍스트, 404, 오류 JSON이 반환된다면 서버 측 구독이 이미 만료된 것이며 로컬 설정 문제가 아닙니다.
  • 구독 만료일과 잔여 트래픽을 확인합니다. 일부 패널은 이 두 항목을 Subscription-Userinfo 응답 헤더에 담아 보내며, 클라이언트 화면에 보통 표시됩니다.

구독이 실제로 만료되었다면 이후 단계를 아무리 점검해도 결과는 나오지 않습니다. 서비스 제공자에게 문의하거나 유효한 구독 링크로 교체하는 것이 유일한 방법입니다. 구독이 정상인데도 노드가 계속 타임아웃이라면 다음 단계로 넘어갑니다.

2단계: 로컬 포트 점유와 리스닝 상태

Clash 커널은 여러 로컬 포트를 리스닝합니다: HTTP 프록시 포트, SOCKS5 포트, 패널 통신용 외부 제어 포트(기본값 9090)입니다. 이 포트들이 다른 프로그램에 점유되면 커널 실행이 실패하거나 프록시 기능이 불완전해지는데, 이는 노드가 온라인처럼 보여도 실제로는 트래픽이 전혀 지나가지 않는 형태로 나타납니다.

점검 방법:

  1. 클라이언트 설정에서 포트 번호를 확인합니다. HTTP 포트(보통 7890)와 혼합 포트(보통 7891)를 기록해둡니다.
  2. 시스템 명령으로 해당 포트가 다른 프로세스에 점유되었는지 확인합니다. Windows에서는 netstat -ano | findstr 7890, macOS/Linux에서는 lsof -i:7890을 사용합니다.
  3. 점유가 확인되면 충돌하는 프로그램을 종료하거나, 클라이언트 설정에서 사용되지 않는 포트로 변경한 뒤 클라이언트를 재시작하고 다시 시도합니다.

같은 컴퓨터에서 두 개의 프록시 도구를 동시에 실행하는 경우가 흔한 원인입니다. 예를 들어 다른 우회 도구의 프로세스가 완전히 종료되지 않고 백그라운드에 남아 포트를 계속 점유하는 경우입니다.

3단계: 시스템 프록시와 TUN 모드 스위치

포트가 정상적으로 리스닝되고 있다고 해서 트래픽이 실제로 Clash로 향한다는 보장은 없습니다. 시스템 레벨의 프록시 스위치 역시 중요합니다:

  • 시스템 프록시 모드: 클라이언트는 시스템의 HTTP/HTTPS 프록시 설정을 자동으로 기록합니다. 이 스위치가 잘못 꺼져 있으면 브라우저와 대부분의 앱이 Clash를 우회해 원래 네트워크로 직접 나갑니다. 클라이언트 화면의 "시스템 프록시" 스위치가 켜져 있는지 확인하세요.
  • TUN 모드: TUN 모드는 가상 네트워크 카드를 통해 시스템 네트워크 계층에서 모든 트래픽을 인수하며, 개별 앱의 프록시 설정에 의존하지 않아 시스템 프록시를 따르지 않는 프로그램에 적합합니다. 일부 시스템에서 TUN 모드를 켜려면 추가 권한(네트워크 확장 권한, 관리자 권한)이 필요한데, 이 권한이 거부되면 TUN이 실행에 실패해도 화면에 명확한 안내가 뜨지 않을 수 있습니다.
  • 시스템 프록시를 따르지 않는 앱: 커맨드라인 도구, 일부 게임 클라이언트는 시스템 프록시 설정을 읽지 않습니다. 이런 경우 TUN 모드를 사용하거나 해당 프로그램의 프록시 파라미터를 별도로 설정해야 합니다.
팁

트래픽이 실제로 Clash를 거치는지 확인하려면 클라이언트의 연결 패널(Connections)을 열고, 웹페이지에 접속할 때 해당 연결 기록이 나타나는지 확인하세요. 기록이 전혀 나타나지 않는다면 트래픽이 Clash에 아예 들어오지 않고 있다는 뜻이며, 문제는 이 단계에 있는 것이지 노드가 아닙니다.

4단계: 프로토콜과 커널 매칭

Clash 오리지널 커널은 제한된 몇 가지 프록시 프로토콜만 지원하는 반면, Clash Meta(즉 mihomo)는 Hysteria, Hysteria2, TUIC, VMess의 일부 변형 등 더 많은 프로토콜을 확장 지원합니다. 구독에 오리지널 커널이 인식하지 못하는 프로토콜 유형이 포함되어 있다면 해당 노드는 곧바로 사용 불가로 표시되거나 지연 테스트가 항상 타임아웃으로 나옵니다. 이는 네트워크 문제가 아니라 커널 성능 부족에서 비롯된 것입니다.

점검 방법:

  1. 클라이언트가 내부적으로 사용하는 커널 버전을 확인합니다. 대부분의 최신 클라이언트(Clash Verge Rev, FlClash, Clash Plus 등)는 기본적으로 Meta/mihomo 커널로 전환되어 있습니다.
  2. 구독 노드 목록의 프로토콜 필드를 확인합니다. hysteria2, tuic 등의 키워드가 보이는데 클라이언트가 여전히 구버전 오리지널 Clash 커널을 쓰고 있다면, 해당 프로토콜을 지원하는 클라이언트로 교체해야 합니다.
  3. 프로토콜 자체가 네트워크 환경에 요구사항을 두는 경우도 있습니다. 예를 들어 QUIC 기반 프로토콜은 일부 네트워크 환경에서 통신사에 의해 표적 제한이나 차단을 당해 해당 프로토콜의 노드들이 전반적으로 타임아웃되고 다른 프로토콜의 노드는 정상인 경우가 있습니다. 이런 경우는 로컬 설정을 계속 점검할 게 아니라 다른 프로토콜의 노드로 교체해야 합니다.

5단계: DNS 오염과 해석 이상

앞의 4단계가 모두 정상이어도 DNS 해석 과정에 문제가 있으면 노드가 타임아웃으로 나타날 수 있습니다. 원인은 이렇습니다: 클라이언트가 속도 테스트나 연결 수립 전에 노드의 도메인을 IP 주소로 먼저 해석해야 하는데, 이 단계가 오염되면 해석 결과가 잘못된 IP나 빈 결과로 나오고, 이후 연결은 자연히 실패합니다.

일반적인 해결 방법:

  • 설정 파일의 dns 필드에서 enhanced-mode: fake-ip를 활성화하고, 신뢰할 수 있는 상위 DNS(암호화된 DoH/DoT 서버 등)를 설정해 오염될 수 있는 기기 기본 DNS를 우회합니다.
  • nameserver 목록에 현지 통신사 기본 DNS가 포함되어 있는지 확인하고, 있다면 독립된 암호화 해석 주소로 교체합니다.
  • TUN 모드를 켜면 DNS 요청도 함께 인수되는데, 그래도 해석이 이상하다면 TUN 설정 블록의 dns-hijack 항목이 53번 포트 요청을 올바르게 가로채고 있는지 확인합니다.
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-range: 198.18.0.1/16

상위 DNS를 설정한 뒤 커널을 재시작해 적용하고, 다시 속도 테스트를 해서 노드 지연 시간이 정상 수치로 돌아왔는지 확인합니다.

5단계 점검 순서 요약

한 줄로 정리하면: 먼저 구독 자체가 데이터를 가져올 수 있는지 확인하고, 그다음 포트가 점유되지 않았는지, 시스템 프록시나 TUN이 실제로 트래픽을 인수하고 있는지 확인한 뒤, 프로토콜이 현재 커널에서 지원되는지 점검하고, 마지막으로 DNS 해석이 오염되었는지 살핍니다. 이 5단계는 "외부 데이터 소스"에서 "로컬 네트워크 스택"으로 순차적으로 진행되며, 어느 단계에서든 문제가 생기면 겉보기에 똑같은 "전체 타임아웃" 현상이 나타나지만 해결 방법은 완전히 다릅니다. 순서대로 점검하면 잘못된 방향에서 설정 파일만 반복해서 만지는 것을 피할 수 있습니다.

위 5단계를 모두 확인해도 노드가 여전히 타임아웃이라면, 네트워크 환경을 바꿔서(예: 휴대폰 테더링) 테스트해보세요. 현재 기기와 네트워크 환경의 간섭 요인을 분리해 문제 범위를 더 좁힐 수 있습니다.

클라이언트 다운로드