Clash 노드 시간 초과로 연결할 수 없을 때: 클라이언트 설정부터 로컬 네트워크까지 점검 순서

먼저 어떤 종류의 시간 초과인지 판단하기

Clash에 시간 초과가 표시된다고 해서 반드시 노드 서버에 문제가 있는 것은 아닙니다. 속도 측정 요청은 클라이언트 커널, 도메인 확인, 로컬 네트워크, 노드 진입점, 테스트 사이트를 차례로 거칩니다. 이 중 어느 한 단계라도 제한 시간 안에 응답하지 않으면 Timeout이 표시될 수 있습니다. 먼저 범위를 좁힌 뒤 설정을 변경하는 편이 구독을 반복해서 갱신하는 것보다 효과적입니다.

비교 테스트로 노드 문제와 로컬 문제 구분하기

1. 현재 구독은 그대로 두고, 지역과 진입점이 서로 다른 노드를 최소 3개 연속으로 테스트합니다.
2. Clash의 시스템 프록시와 TUN을 끈 뒤 평소 접속 가능한 웹사이트를 직접 열어 기본 네트워크가 정상인지 확인합니다.
3. Clash 커널을 다시 시작하고 시스템 프록시만 켠 다음 브라우저 접속을 테스트합니다.
4. 같은 구독을 다른 기기나 다른 네트워크(예: 휴대폰 핫스팟)에 임시로 가져와 결과를 비교합니다.

같은 노드가 가정용 인터넷에서는 시간 초과되지만 휴대폰 핫스팟에서는 작동한다면, 문제는 로컬 기기·라우터·현재 네트워크 출구에 있을 가능성이 큽니다. 여러 기기와 다른 네트워크에서 동일한 노드만 실패하고 같은 구독의 다른 노드는 정상이라면, 해당 노드의 진입점·포트·프로토콜 매개변수로 범위를 좁히는 것이 일반적입니다.

1단계: 클라이언트 커널, 설정, 프록시 포트 확인

모든 노드에서 시간 초과가 발생하면 먼저 Clash Meta（mihomo）커널이 정상적으로 시작되었는지 확인합니다. 그래픽 인터페이스가 열린다고 해서 커널이 포트를 실제로 수신 대기 중이라는 뜻은 아닙니다. 로그에 address already in use, configuration file test failed가 표시되거나 계속 재시작된다면 먼저 포트 충돌과 설정 오류를 해결해야 합니다.

커널 상태와 현재 설정 확인

Clash Verge Rev 2.4.2의 일반적인 화면을 기준으로, 「설정」→「Clash 설정」에서 현재 커널과 포트를 확인하고 「구독」에서 사용 중인 설정을 확인할 수 있습니다. 클라이언트마다 「커널」, 「설정」 또는 「Profiles」처럼 이름이 다를 수 있지만 기준은 같습니다. 설정이 활성화되어 있고 커널 상태가 실행 중이며 로그에 반복 오류가 없어야 합니다.

• Mixed Port: 일반적으로 7890을 사용하며 HTTP와 SOCKS5 요청을 모두 받습니다.
• HTTP Port: 이전 설정에서 7890이 자주 사용됩니다.
• SOCKS Port: 이전 설정에서 7891이 자주 사용됩니다.
• External Controller: 일반적인 수신 주소는 127.0.0.1:9090이며, 제어 인터페이스이지 앱용 프록시 포트가 아닙니다.

브라우저 프록시에 제어 포트 9090을 입력하지 마세요. 설정에 mixed-port: 7890만 선언되어 있다면 브라우저나 시스템 프록시는 127.0.0.1:7890을 사용해야 합니다. 포트를 변경한 뒤에는 시스템 프록시, 브라우저 확장 프로그램, 기타 수동 설정도 함께 업데이트해야 합니다.

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

포트 사용 중인지 확인

Windows에서는 PowerShell에서 7890 포트를 이미 다른 프로세스가 수신 대기 중인지 확인할 수 있습니다:

Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890).OwningProcess

macOS와 Linux에서는 다음 명령을 사용할 수 있습니다:

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

이전 버전의 Clash, 다른 프록시 도구 또는 남아 있는 백그라운드 프로세스가 같은 포트를 사용 중이라면 충돌하는 프로그램을 먼저 종료한 뒤 현재 클라이언트를 다시 시작하세요. 두 프로그램이 동시에 시스템 프록시를 설정하도록 두지 마세요. 인터페이스에 표시된 포트와 운영체제가 실제로 사용하는 포트가 달라질 수 있습니다.

2단계: 시스템 프록시에서 TUN 모드로 범위 좁히기

기본 점검에서는 먼저 시스템 프록시를 사용하고 처음부터 TUN을 켜지 마세요. 시스템 프록시는 연결 경로가 짧아 노드 연결 가능 여부를 확인하기 쉽습니다. Clash Verge Rev 2.4.2를 기준으로 「설정」→「시스템 설정」→「시스템 프록시」로 이동해 켠 뒤, 시스템 프록시 서버가 127.0.0.1인지, 포트가 Mixed Port와 일치하는지 확인합니다.

브라우저는 정상인데 앱은 여전히 직접 연결

시스템 프록시는 운영체제의 프록시 설정을 읽는 앱에만 적용됩니다. 일부 게임, 명령줄 도구, 가상 머신과 자체 네트워크 스택을 사용하는 소프트웨어는 시스템 프록시를 무시합니다. 따라서 브라우저가 정상적으로 접속된다고 해서 모든 앱의 트래픽이 프록시를 통과한다는 의미는 아닙니다.

• 먼저 Clash의 「연결」 패널에서 대상 도메인이나 프로세스를 검색합니다.
• 기록이 전혀 보이지 않는다면 일반적으로 트래픽이 Clash로 들어오지 않은 것입니다.
• 기록은 보이지만 상태가 계속 연결 중이라면 노드 진입점과 DNS를 추가로 확인합니다.
• 기록에 DIRECT가 표시되면 노드를 바꾸지 말고 규칙 매칭 결과를 확인해야 합니다.

TUN을 켠 뒤 모든 연결이 시간 초과

TUN 모드는 가상 네트워크 어댑터와 라우팅 규칙으로 더 많은 트래픽을 가로채 처리합니다. Windows에서는 일반적으로 관리자 권한과 정상적으로 로드되는 가상 네트워크 어댑터 드라이버가 필요합니다. macOS는 처음 활성화할 때 네트워크 확장을 승인해야 하며, Linux는 /dev/net/tun과 적절한 네트워크 관리 권한이 필요합니다.

TUN을 끈 뒤 시스템 프록시가 작동한다면 노드 자체는 정상일 가능성이 높습니다. 이때는 구독을 계속 수정하지 말고 TUN만 따로 점검해야 합니다. 다음 순서로 복구하세요:

1. TUN을 끄고 클라이언트를 종료한 뒤 시스템 네트워크가 복구되는지 확인합니다.
2. 클라이언트를 다시 시작하고 먼저 Mixed Port 프록시가 작동하는지 확인합니다.
3. 필요한 권한으로 클라이언트를 실행한 다음 TUN을 켭니다.
4. VPN, 가상 머신 브리지, 트래픽 필터 또는 다른 TUN 소프트웨어가 동시에 실행 중인지 확인합니다.
5. 도메인은 열리지 않지만 IP 주소로 접속할 수 있다면 DNS 점검으로 넘어갑니다.

3단계: DNS와 노드 진입점 도메인 확인

노드 주소는 IP일 수도 있고 도메인일 수도 있습니다. 서버 주소로 도메인을 사용할 경우 Clash는 먼저 로컬 확인자나 설정에 지정된 기본 확인자를 통해 진입점 IP를 얻어야 합니다. 진입점 도메인 확인에 실패하면 프록시 프로토콜 매개변수가 정확하더라도 같은 진입점을 사용하는 모든 노드가 함께 시간 초과될 수 있습니다.

먼저 운영체제 수준에서 도메인 확인 점검

Windows에서는 다음을 실행합니다:

nslookup node.example.com
Resolve-DnsName node.example.com

macOS 또는 Linux에서는 다음을 실행합니다:

dig node.example.com
nslookup node.example.com

node.example.com은 설정에 있는 노드의 실제 server 값으로 바꿔야 합니다. NXDOMAIN, 시간 초과 또는 A/AAAA 레코드 없음이 반환되면 먼저 구독의 진입점 도메인이 아직 유효한지 확인합니다. 여러 실패 노드가 하나의 진입점 도메인을 공유한다면 특히 중요한 점검입니다.

진입점 확인과 프록시 내부 DNS 구분

Clash의 DNS 설정은 앱 도메인 확인을 담당하는 동시에 노드 진입점 확인에도 관여할 수 있습니다. mihomo 설정의 default-nameserver는 주로 DNS 서버 자체와 노드 진입점 같은 기본 대상의 확인에 사용되므로, 일반적으로 직접 접속 가능한 IP 형식의 DNS 주소를 지정해야 합니다. 그래야 프록시 진입점을 확인하려면 프록시가 필요한 순환 의존을 피할 수 있습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query

이 내용은 설정 계층을 설명하기 위한 것이며 모든 네트워크에 동일한 확인자가 적합하다는 뜻은 아닙니다. 기업망, 학교 네트워크 또는 내부 도메인을 사용하는 환경에서는 로컬 DNS를 유지해야 할 수 있습니다. 변경 전 원래 설정을 저장하고, 변경 후 다시 불러온 다음 로그에 lookup, no such host 또는 DNS 요청 시간 초과가 나타나는지 확인하세요.

IPv6 진입점만 실패한다면 현재 네트워크에 사용 가능한 IPv6 라우팅이 있는지 일시적으로 확인할 수 있습니다. AAAA 레코드가 조회된다고 해서 로컬 기기가 반드시 IPv6에 연결할 수 있는 것은 아닙니다. 문제를 가리기 위해 IPv6를 무작정 끈 상태로 장기간 사용하지 말고 라우터, 통신사 경로, 노드 진입점의 실제 지원 여부를 추가로 확인하세요.

4단계: 단일 노드 시간 초과 시 프로토콜 매개변수 확인

특정 노드 하나만 실패하고 같은 구독의 다른 노드는 작동한다면 로컬 시스템 프록시와 기본 DNS에는 대체로 큰 문제가 없습니다. 해당 노드의 서버 주소, 포트, 프로토콜 필드를 중점적으로 확인하세요. 구독을 다시 가져오면 수동 편집으로 필드가 누락된 문제는 배제할 수 있지만, 서버 오프라인이나 구독 제공처 자체의 데이터 오류를 고칠 수는 없습니다.

tls, udp 또는 skip-cert-verify를 경험에 의존해 함부로 바꾸지 마세요. 이러한 필드는 서버 설정과 일치해야 합니다. 특히 인증서 검증 건너뛰기를 만능 해결책으로 사용해서는 안 됩니다. 오류를 잠시 숨길 수는 있지만 SNI, 인증서 유효 기간 또는 잘못된 시스템 시간을 해결하지는 못합니다.

로컬 기기의 시간 확인

TLS 핸드셰이크에는 정확한 시간이 필요합니다. Windows에서는 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 자동 시간 설정을 켜고 즉시 동기화를 실행합니다. macOS에서는 「시스템 설정」→「일반」→「날짜 및 시간」에서 자동 설정을 켭니다. 시스템 시간이 몇 분만 어긋나도 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판단될 수 있습니다.

노드 포트에 도달할 수 있는지 확인

Windows PowerShell에서는 노드 서버와 포트에 대해 TCP 탐색을 실행할 수 있습니다:

Test-NetConnection node.example.com -Port 443

macOS 또는 Linux에서는 다음을 사용할 수 있습니다:

nc -vz node.example.com 443

TCP 테스트 성공은 진입점 포트와 연결을 수립할 수 있다는 뜻일 뿐이며 UUID, 비밀번호, TLS 또는 전송 매개변수가 올바르다는 의미는 아닙니다. 테스트 실패는 서버가 수신 대기하지 않거나 진입점 주소가 만료되었거나 방화벽이 패킷을 버리거나 현재 네트워크가 제한하는 경우일 수 있습니다. 일부 UDP 프로토콜은 TCP 탐색만으로 판단할 수 없으므로 커널 로그와 다른 네트워크에서의 비교 테스트를 함께 확인해야 합니다.

5단계: 방화벽, 라우터, 현재 네트워크 점검

모든 노드가 실패하지만 다른 기기에서는 설정이 정상적으로 작동한다면 로컬 보안 정책을 확인해야 합니다. Windows 방화벽이 그래픽 인터페이스의 인터넷 연결은 허용하면서 실제로 실행 중인 mihomo 커널은 차단할 수 있습니다. 타사 보안 소프트웨어도 프로세스 경로별로 규칙을 만들 수 있어, 클라이언트 업데이트 후 커널 파일 경로가 바뀌면 기존 허용 규칙이 더 이상 적용되지 않을 수 있습니다.

Windows 점검 순서

1. 「Windows 보안」→「방화벽 및 네트워크 보호」→「방화벽을 통해 앱 허용」을 엽니다.
2. 현재 Clash 클라이언트와 mihomo 커널이 사용 중인 네트워크 유형에서 액세스 권한을 얻었는지 확인합니다.
3. 「설정」→「네트워크 및 인터넷」→「프록시」로 이동해 더 이상 유효하지 않은 수동 프록시가 남아 있는지 확인합니다.
4. 다른 VPN, 프록시, 네트워크 필터 프로그램을 종료한 뒤 Clash를 다시 시작합니다.
5. 휴대폰 핫스팟으로 다시 테스트해 문제가 현재 라우터나 광대역 회선에서만 발생하는지 판단합니다.

방화벽을 일시적으로 끄는 것은 짧은 비교 테스트로만 사용해야 합니다. 규칙이 원인임을 확인했다면 방화벽을 다시 켜고 실제 커널 프로그램에 명확한 허용 규칙을 설정하세요. 장기간 꺼 둔 상태로 사용해서는 안 됩니다.

라우터와 네트워크 출구

라우터의 자녀 보호, 게스트 네트워크 격리, 기업 네트워크 출구 ACL, 공용 Wi-Fi 인증 페이지가 노드 연결에 영향을 줄 수 있습니다. 먼저 일반 HTTP 및 HTTPS 사이트를 열어 인증 절차가 완료되었는지 확인하세요. 휴대폰 핫스팟으로 연결하자마자 정상화된다면 라우터 DNS, IPv6, MTU, 액세스 제어, 상위 네트워크 제한을 차례로 확인합니다.

MTU 문제는 TCP 연결은 수립되지만 TLS 또는 대용량 패킷 단계에서 멈추는 형태로 나타나는 경우가 많습니다. TUN 환경에서 작은 웹페이지는 간헐적으로 열리지만 이미지와 다운로드가 계속 멈춘다면 MTU를 후속 점검 항목으로 고려할 수 있습니다. 다만 비교 결과 없이 함부로 변경해서는 안 됩니다. 먼저 기존 값을 기록하고 클라이언트가 지원하는 설정에 따라 조금씩 조정하며, 한 번에 작은 범위만 변경하세요.

로그 읽는 법: 오류 키워드로 단계 찾기

로그 수준은 일시적으로 info로 설정하는 것만으로도 대개 충분합니다. 규칙과 핸드셰이크 세부 정보를 추적해야 할 때만 잠시 debug를 사용하고 완료 후 되돌려 로그가 빠르게 쌓이지 않도록 하세요. 문제를 재현할 때 정확한 시간, 노드 이름, 대상 도메인을 기록한 뒤 같은 시각 전후의 정보를 검색합니다.

i/o timeout은 결과일 뿐 책임 주체를 직접 알려주지 않습니다. 앞에 표시된 대상 주소를 함께 확인해야 합니다. 시간 초과 대상이 노드 진입점이면 노드와 로컬 네트워크 출구를, DNS 서버이면 확인 경로를 점검하세요. 지연 시간 측정 사이트에서만 발생하고 다른 연결은 정상이라면 속도 측정 주소를 확인해야 합니다.

고정 점검 순서와 복구 기준

전체 과정은 8단계로 정리할 수 있습니다. 순서대로 실행하면서 각 단계의 결과를 기록하세요:

1. 직접 연결 네트워크 확인: 시스템 프록시와 TUN을 끄고 기본 네트워크가 정상인지 확인합니다.
2. 커널 실행 확인: 설정 로드, 포트 수신 대기, 시작 로그를 점검합니다.
3. 시스템 프록시만 활성화: 127.0.0.1:7890 등 실제 Mixed Port로 테스트합니다.
4. 노드 비교 테스트: 최소 3개 노드를 비교해 단일 노드 문제인지 전체 장애인지 구분합니다.
5. 진입점 확인: 노드 도메인을 조회하고 IPv4, IPv6, DNS 로그를 대조합니다.
6. 프로토콜 필드 확인: 단일 노드에 한해 포트, TLS, SNI, 전송 매개변수를 점검합니다.
7. 네트워크를 바꿔 재테스트: 휴대폰 핫스팟으로 로컬 기기, 라우터, 현재 네트워크 출구를 구분합니다.
8. 마지막으로 TUN 복구: 기본 프록시가 안정된 뒤 가상 네트워크 어댑터, 라우팅, DNS 적용을 점검합니다.

복구 기준은 노드 지연 시간에 숫자가 표시되는 것만이 아닙니다. 클라이언트 커널이 안정적으로 실행되고, 웹 요청이 연결 패널에 나타나며, 규칙이 예상대로 매칭되고, 여러 대상에 연속으로 접속해도 간헐적인 시간 초과가 없어야 합니다. 노드를 바꾼 뒤 새 연결이 새로운 정책을 사용해야 합니다. 속도 측정만 복구되고 실제 연결이 계속 실패한다면 점검은 끝나지 않은 것입니다.