Clash 노드 연결 시간 초과·연결 실패 해결 방법: 구독부터 DNS까지 단계별 점검

속도 테스트 시간 초과와 실제 연결 실패를 구분하세요

Clash 클라이언트에 “Timeout”이 표시되면 보통 제한 시간 안에 테스트 요청이 완료되지 않았다는 뜻입니다. 서버가 반드시 오프라인이라는 의미는 아닙니다. 테스트 대상에 접속할 수 없거나 DNS 조회에 실패했거나 노드 인증 정보가 만료되어도 비슷한 결과가 나올 수 있습니다. 반대로 속도 테스트에서 지연 시간이 표시되더라도 당시 테스트 요청이 성공했다는 뜻일 뿐, 모든 웹사이트와 UDP 트래픽, 앱이 정상 작동한다는 보장은 없습니다.

실패가 설정 가져오기, 로컬 포트 수신, 도메인 조회, 노드 핸드셰이크, 규칙 선택 중 어느 단계에서 발생하는지 찾는 것이 점검의 목적입니다. 먼저 현재 설정과 로그를 저장한 뒤 노드 하나, 대상 사이트 하나, 연결 방식 하나만 정해 테스트하세요. 구독 업데이트, DNS 변경, TUN 활성화를 한꺼번에 진행하면 어떤 변경이 효과가 있었는지 판단하기 어렵습니다.

최소한의 테스트 기록 남기기

• 환경: 운영체제, Clash 클라이언트 버전, 코어 버전과 함께 Wi-Fi, 모바일 네트워크, 유선 네트워크 중 어떤 연결을 사용했는지 기록합니다. 인터페이스 버전과 mihomo 코어 버전은 따로 적어 두세요.
• 설정: 현재 Profile 이름, 구독을 마지막으로 성공적으로 업데이트한 시각, 프록시 모드, 전략 그룹에서 선택한 노드를 기록합니다.
• 증상: “모든 노드에서 시간 초과”, “노드 하나만 실패”, “속도 테스트는 성공하지만 브라우저는 실패”, “브라우저는 정상인데 특정 앱만 실패”처럼 구분합니다.
• 시간: 예를 들어 14:30:00에 요청을 보내고, 이어지는 30초 분량의 로그를 저장합니다. 기록 형식의 예시일 뿐, 미리 정해진 테스트 결과가 아닙니다.

1단계: 구독이 유효하고 설정이 적용됐는지 확인

구독 링크는 설정을 가져오는 경로이지 노드 연결 자체가 아닙니다. 구독 업데이트 성공이 노드 사용 가능을 뜻하지는 않습니다. 가져온 설정에 이미 만료된 계정 정보가 포함됐거나 제공업체가 회선을 점검 중일 수도 있습니다. 먼저 Clash 클라이언트의 설정 목록에서 현재 활성화된 Profile을 확인하고, 해당 설정을 업데이트한 뒤 결과와 업데이트 시각을 살펴보세요.

1. 계정 상태 확인. 구독 제공업체의 계정 페이지에서 이용 기간, 남은 데이터, 기기 제한을 확인합니다. 데이터가 소진됐거나 계정이 정지됐다면 로컬 포트를 조정해도 해결되지 않습니다.
2. 구독 응답 확인. HTTP 401 또는 403은 보통 인증이나 접근 정책과 관련 있고, 404는 주소가 만료됐을 가능성이 있으며, 429는 요청이 제한됐다는 뜻입니다. 설정 내용 대신 로그인 페이지가 반환됐다면 YAML로 가져오지 마세요.
3. 불러오기 결과 확인. 업데이트 후 노드 목록이 예상대로 바뀌었는지 확인하고 YAML 구문 오류, 알 수 없는 필드, 지원하지 않는 프로토콜 안내가 표시되는지도 살펴보세요. 일부 Clash 클라이언트는 업데이트에 실패해도 기존 설정을 계속 사용합니다.
4. 최종 적용 설정 확인. 설정 병합, 오버라이드, 스크립트가 포트, DNS, 규칙을 변경할 수 있습니다. 이후 점검은 구독 원문이 아니라 실제로 불러온 결과를 기준으로 진행하세요.

전체 실패와 단일 노드 실패 구분하기

노드 하나만 실패하면 먼저 같은 전략 그룹에서 다른 노드를 선택해 다시 테스트한 뒤, 문제가 있는 노드의 서버 주소, 포트, 인증 정보를 확인하세요. 모든 노드가 실패한다면 로컬 네트워크, 시스템 시간, DNS, 로컬 코어처럼 공통으로 사용하는 요소부터 점검합니다. 서로 다른 노드가 실제로 같은 서버 도메인을 사용한다면 동일한 DNS 오류의 영향을 받을 수도 있습니다.

원격 규칙 세트와 프록시 그룹은 rule-providers 또는 proxy-providers를 통해 별도로 가져올 수 있습니다. 기본 구독 업데이트에 성공했다고 해서 이러한 리소스도 다운로드된 것은 아닙니다. 로그에서 리소스 다운로드 오류를 확인하세요. 특히 리소스 다운로드에 프록시가 필요한데 시작 시점에는 사용할 프록시가 없는 의존성 문제에 유의해야 합니다.

2단계: 시스템 시간 동기화 및 기본 네트워크 확인

시스템 날짜가 크게 어긋나면 TLS 인증서 유효기간 검증이 실패할 수 있고, 시간에 의존하는 인증 절차에도 문제가 생길 수 있습니다. 이런 오류는 노드 핸드셰이크 단계나 구독 다운로드 단계에서 발생할 수 있습니다. 작업 표시줄에 표시된 시각만 보지 말고 연월일과 실제 시각이 맞는지 확인하세요.

• Windows 11: 「설정」→「시간 및 언어」→「날짜 및 시간」으로 이동해 「자동으로 시간 설정」을 켠 다음, 「시계 동기화」에서 「지금 동기화」를 실행합니다.
• macOS: 「시스템 설정」→「일반」→「날짜 및 시간」으로 이동해 날짜 및 시간 자동 설정을 켭니다. 시스템 버전에 따라 메뉴 이름이 조금 다를 수 있습니다.
• Linux: timedatectl status로 시각과 동기화 상태를 확인합니다. systemd를 사용하고 시간 동기화를 지원하는 시스템에서는 sudo timedatectl set-ntp true로 동기화를 켤 수 있습니다.

Clash 클라이언트의 시스템 프록시와 TUN을 잠시 끈 다음, 현재 네트워크에서 직접 접속할 수 있는 사이트를 열어 기본 인터넷 연결이 되는지 확인하세요. 공용 Wi-Fi에서 웹 로그인이 필요하다면 먼저 인증을 완료해야 합니다. 기본 네트워크 연결이 되지 않는 상태에서 프록시 규칙을 바꾸면 혼란만 커집니다.

비교를 위해 네트워크 변경하기

같은 기기와 설정으로 기존 네트워크와 휴대폰 핫스팟을 각각 테스트하세요. 기존 네트워크에서만 실패한다면 해당 네트워크의 DNS, 외부 연결 제한, 방화벽이 원인일 가능성이 큽니다. 두 네트워크에서 모두 실패한다면 기기와 설정을 점검하세요. 이 비교는 원인 범위를 좁히는 데 도움이 되지만 특정 차단 방식이 원인이라고 단정할 수는 없습니다.

ping에 응답이 없다는 사실만으로 노드가 오프라인이라고 판단할 수는 없습니다. 서버가 ICMP 응답을 보내지 않을 수 있습니다. 노드가 TCP, UDP 또는 다른 전송 방식으로 작동한다면 실제 프로토콜의 연결 로그를 함께 확인하세요.

3단계: 프록시 포트와 연결 경로 확인

브라우저가 로컬 프록시에 연결되지 않는 문제와 원격 노드 시간 초과는 서로 다른 유형의 문제입니다. 전자는 코어가 시작되지 않았거나, 수신 포트가 점유됐거나, 시스템 프록시가 이전 포트를 가리킬 때 자주 발생합니다. 현재 적용된 설정에서 mixed-port를 찾거나 port와 socks-port를 각각 확인하세요. 아래에서는 혼합 포트 7890을 예로 들지만, 실제로 수신 중인 포트에 맞게 바꿔야 합니다.

수신 중인 프로세스 확인

Windows에서는 PowerShell에서 아래 명령을 실행한 뒤, 출력의 OwningProcess에 해당하는 프로세스를 조회해 예상한 코어가 포트를 수신 중인지 확인하세요.

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id (Get-NetTCPConnection -LocalPort 7890 -State Listen).OwningProcess

macOS에서는 lsof, Linux에서는 ss를 사용할 수 있습니다. 권한이 부족하면 프로세스 정보가 표시되지 않을 수 있습니다.

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

수신 중인 프로세스가 없다면 먼저 코어 시작 로그를 확인하세요. address already in use가 표시되면 같은 포트를 점유한 이전 인스턴스를 종료하거나 현재 Clash 클라이언트의 수신 포트를 변경합니다. 출처를 알 수 없는 시스템 프로세스를 무작정 종료하지 말고 이름과 출처부터 확인하세요. 포트를 바꾼 뒤에는 시스템 프록시 주소도 함께 점검해야 합니다. 그렇지 않으면 브라우저가 계속 이전 포트에 연결할 수 있습니다.

프록시를 직접 지정해 테스트하기: 시스템 프록시 설정 우회

아래 명령은 로컬 HTTP 프록시를 직접 지정해 수신 포트, 프록시 전달, 대상 요청의 연결 여부를 확인합니다. Windows에서는 일부 PowerShell 환경에서 curl이 다른 명령으로 해석될 수 있으므로 curl.exe를 사용하는 것이 좋습니다. macOS와 Linux에서는 명령 이름을 curl로 바꾸면 됩니다.

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

• 연결이 즉시 거부됨: 먼저 노드를 바꾸지 말고 로컬 수신 주소와 포트, 코어 상태를 확인하세요.
• HTTP 응답을 받음: 해당 요청은 완료된 것입니다. 브라우저에서만 실패한다면 시스템 프록시, 브라우저 프록시 설정, 확장 프로그램을 확인하세요.
• 대기 후 시간 초과: 같은 시각의 로그를 확인해 노드 서버 연결 실패, TLS 핸드셰이크 실패, 대상 사이트 응답 시간 초과를 구분하세요.

여기서 10초는 연결 단계의 제한 시간이고 20초는 전체 요청 제한 시간이며, 지연 시간 측정값이 아닙니다. 테스트 결과는 현재 규칙의 영향을 받습니다. 대상이 DIRECT 규칙에 걸리면 직접 연결 경로만 검증한 것입니다. 특정 노드를 확인하려면 해당 전략을 임시로 선택하고 연결 기록을 살펴본 뒤, 테스트가 끝나면 원래 모드로 되돌리세요.

4단계: 실제 DNS 경로를 따라 조회 점검

DNS 문제는 최소한 두 가지로 나눠 확인해야 합니다. 노드 서버 도메인이 조회되는지, 대상 사이트 도메인이 조회되는지 살펴보세요. 전자가 실패하면 노드 연결 자체를 설정할 수 없습니다. 후자가 실패하면 노드 속도 테스트는 정상이어도 특정 사이트에 접속하지 못할 수 있습니다. 로그의 no such host, DNS 조회 시간 초과, 리졸버 연결 실패는 인터페이스에 표시되는 일반적인 “시간 초과” 안내보다 원인을 찾는 데 더 유용합니다.

먼저 시스템 DNS를 확인하고, 이어서 코어 DNS를 점검하세요

# Windows PowerShell: 시스템 DNS 응답 확인
Resolve-DnsName example.com

# 주요 데스크톱 운영체제에서 사용할 수 있는 기본 조회
nslookup example.com

예시 도메인을 로그에서 실제로 실패한 도메인으로 바꾸세요. 시스템 조회에 성공해도 Clash 클라이언트 코어가 사용하는 리졸버가 정상이라는 뜻은 아닙니다. 코어 자체 DNS, TUN의 DNS 가로채기, 앱의 암호화 DNS가 활성화되면 조회 경로가 달라질 수 있습니다. 실제 적용 설정의 dns.enable, nameserver와 로그를 대조해 하나씩 확인하세요.

위 필드의 지원 범위와 동작은 코어 버전에 따라 다르므로 변경 전에 해당 버전의 문서를 확인하세요. mihomo 설정을 해당 필드를 지원하지 않는 구형 코어에 그대로 적용하지 마세요. 공용 DNS를 여러 개 입력했다는 이유만으로 문제가 해결됐다고 판단해서도 안 됩니다. 리졸버 연결 가능 여부, 분기 정책, 부트스트랩 조회를 각각 확인해야 합니다.

Fake-IP 주소는 노드 서버 주소가 아닙니다

Fake-IP를 사용하면 조회 결과로 설정된 매핑 주소 대역, 예를 들어 198.18.0.0/16이 반환될 수 있습니다. 이는 도메인과 연결을 연동하기 위한 내부 매핑이며, 이런 주소가 보인다고 해서 DNS 변조를 뜻하는 것은 아닙니다. 이후 연결이 같은 코어로 전달되고 도메인이 올바르게 복원되는지가 중요합니다.

DNS 모드를 바꾼 뒤에도 앱이 이전 캐시를 사용한다면 영향을 받는 앱을 먼저 다시 시작한 다음 운영체제 방식으로 DNS 캐시를 지우세요. Windows에서는 ipconfig /flushdns를 실행할 수 있지만, 브라우저 자체 캐시나 코어 매핑까지 자동으로 지우지는 않습니다. Fake-IP와 호환되지 않는 LAN 서비스를 확인한 경우 로그를 바탕으로 해당 도메인만 fake-ip-filter에 추가하세요. 처음부터 모든 도메인을 우회하도록 설정할 필요는 없습니다.

5단계: 규칙 적용 결과와 전략 그룹 선택 확인

노드 지연 시간은 표시되는데 웹페이지가 열리지 않는다면 요청이 예상한 노드를 거치지 않는 것이 흔한 원인입니다. 규칙 모드에서는 설정 순서대로 규칙이 적용됩니다. 도메인, IP, 프로세스, 최종 기본 규칙에 따라 요청마다 서로 다른 전략이 선택될 수 있습니다. Clash 클라이언트의 연결 기록에서 대상 도메인, 적용된 규칙, 최종 전략 경로, 실제 출구 노드를 확인하세요.

1. 노드 하나를 고정하세요. 수동 선택 전략 그룹에서 노드를 지정해 점검 중 자동 속도 테스트 그룹이 출구를 바꾸지 않도록 합니다.
2. 연결을 새로 만드세요. 기존 탭을 닫거나 앱을 다시 시작한 뒤 테스트합니다. 이미 연결된 장시간 연결은 전략을 바꿔도 새 노드를 바로 사용하지 않을 수 있습니다.
3. DIRECT 및 REJECT 확인. 요청이 직접 연결 또는 차단 전략에 걸리면 프록시 노드를 바꿔도 결과는 달라지지 않습니다. 먼저 해당 규칙을 확인하세요.
4. 잠시 전역 모드로 비교하세요. 전역 전략에서도 테스트할 노드가 선택돼 있는지 확인합니다. 전역 모드에서는 되지만 규칙 모드에서 실패한다면 규칙과 전략 그룹을 집중적으로 살펴보세요. 테스트가 끝나면 규칙 모드로 되돌립니다.

전역 모드라고 해서 모든 앱의 트래픽을 자동으로 처리하는 것은 아닙니다. 시스템 프록시만 켠 경우 시스템 프록시를 따르지 않는 앱은 직접 연결할 수 있습니다. 프록시를 직접 지정한 명령은 정상인데 게임, 명령줄 프로그램, 메신저 중 하나만 실패한다면 해당 앱의 HTTP/SOCKS 프록시 지원 여부를 확인한 뒤 TUN 사용을 검토하세요.

TUN과 UDP는 별도로 확인

TUN은 시스템 IP 트래픽을 가상 네트워크 인터페이스로 전달하므로 필요한 권한, 라우팅, DNS 가로채기 설정이 갖춰져야 합니다. 브라우저는 되는데 TUN이 작동하지 않는다면 서비스 설치 상태, 관리자 권한, 가상 인터페이스, 다른 VPN과의 라우팅 충돌을 확인하세요. 모든 문제를 노드 장애로 단정하지 마세요.

웹사이트의 HTTPS 테스트는 주로 TCP 경로를 확인하며 UDP 사용 가능 여부를 증명하지 않습니다. 게임, 음성 통화, 일부 QUIC 연결은 노드 프로토콜 지원, 서버의 전달 기능, 로컬 네트워크 환경에도 영향을 받습니다. 해당 앱을 따로 테스트하고 UDP 로그를 확인하세요. 설정에서 UDP를 켜기만 해서는 UDP 전달을 지원하지 않는 서버가 기능을 제공하게 되지 않습니다.

마지막 단계: 로그로 핸드셰이크 및 서버 문제 확인

구독, 시간, 포트, DNS, 규칙을 모두 확인한 다음 노드 핸드셰이크와 서버를 점검하세요. 로그 수준을 잠시 debug로 바꾸고 한 번 재현한 뒤 평소 설정으로 되돌릴 수 있습니다. Clash 클라이언트마다 메뉴 위치가 다르므로 특정 경로를 추측하지 말고 로그 화면에서 내보내기 기능을 찾으세요.

포트, 비밀번호, UUID, SNI, WebSocket 경로, Reality 매개변수처럼 서버와 연동되는 항목은 구독 제공업체가 제공한 유효 설정을 기준으로 해야 합니다. 항목 하나를 임의로 바꾸면 정상 작동하던 노드도 핸드셰이크에 실패할 수 있습니다. 네트워크를 두 곳에서 테스트해도 노드 하나만 계속 실패하고 다른 노드는 정상이라면, 우선 사용할 수 있는 노드로 전환한 뒤 제공업체에 문제를 알리세요.

문제 신고 시 네 가지 자료를 준비하세요

• 운영체제, Clash 클라이언트와 코어의 정확한 버전, 장애가 시작된 시각.
• 모든 노드에서 실패하는지 일부만 실패하는지, 시스템 프록시와 TUN 중 어느 방식에서 문제가 생기는지.
• 프록시 직접 지정 테스트 결과, 규칙 적용 결과, 네트워크를 바꾼 뒤의 비교 결과.
• “Timeout” 스크린샷 한 장이 아니라 실패한 요청 전후의 민감 정보를 가린 로그.

설정 가져오기와 연결 절차를 다시 확인하려면 사용 가이드를 참고하세요. DNS, 규칙, TUN 매개변수는 고급 설정에서 더 자세히 확인할 수 있습니다. 한 번에 한 항목만 변경하고 복구할 수 있도록 설정을 저장해 두면 반복해서 재설치하는 것보다 원인을 찾기 쉽습니다.