Clash 노드 시간 초과로 연결되지 않을 때: 구독부터 DNS까지 문제 해결 순서

먼저 ‘시간 초과’가 발생한 계층을 확인하세요

Clash 클라이언트에 Timeout이 표시되었다고 해서 반드시 노드 자체가 만료된 것은 아닙니다. 구독 다운로드, 설정 로드, 노드 핸드셰이크, DNS 조회, 규칙 매칭, 시스템 프록시 전달, TUN 라우팅 등에서도 비슷한 증상이 나타날 수 있습니다. 먼저 문제가 발생한 범위를 기록한 뒤 항목별로 확인하는 편이 설정을 즉시 삭제하거나 재설치하는 것보다 대체로 빠릅니다.

먼저 세 가지 현상을 구분해야 합니다. 구독이 업데이트되는지, 노드 지연 시간 테스트에 결과가 나오는지, 브라우저나 다른 앱에서 대상 웹사이트에 접속할 수 있는지입니다. 세 경우는 서로 다른 경로를 사용합니다. 구독 업데이트 실패는 구독 주소, 네트워크 진입점 또는 인증서 시간 문제인 경우가 많습니다. 모든 노드의 지연 시간이 동시에 Timeout이면 현재 네트워크 제한, DNS, 실행되지 않은 코어 또는 접근할 수 없는 테스트 주소를 의심할 수 있습니다. 일부 노드만 실패한다면 노드 회선, 포트 또는 프로토콜 매개변수 문제일 가능성이 높습니다.

첫 번째 단계: 구독 유효성 및 설정 로드 결과 확인

구독은 설정의 출처일 뿐, 노드 자체와는 다릅니다. 구독 주소 만료, 계정 상태 변경, 로그인 페이지가 반환되는 다운로드 요청, 서버의 일시적 오류 등으로 인해 클라이언트가 빈 내용이나 잘못된 형식을 받을 수 있습니다. 이때 노드 테스트를 계속하는 것은 의미가 없으므로, 먼저 클라이언트가 실제로 파싱 가능한 YAML 설정을 다운로드했는지 확인해야 합니다.

업데이트 시간과 오류 문구 확인

1. 설정 또는 구독 페이지에서 최근 업데이트 시간을 확인하고 이번 업데이트가 실제로 성공했는지 확인하세요.
2. 클라이언트에 HTTP 상태 코드가 표시되면 401, 403, 404, 429 또는 5xx를 각각 기록하세요. 상태 코드마다 인증, 주소, 요청 빈도 제한 또는 서버 장애를 뜻하므로 대응 방향이 다릅니다.
3. 구독 이름 아래에 프록시 노드와 정책 그룹이 있으며 빈 설정만 표시되는 것은 아닌지 확인하세요.
4. 업데이트 후 현재 설정을 다시 한 번 선택하고 Clash 코어에서 YAML 파싱 오류를 보고하지 않는지 확인하세요.

설정 파싱 오류는 들여쓰기, 중복 필드, 인식할 수 없는 프록시 유형, 또는 클라이언트 코어 버전이 구독에 사용된 필드를 지원하지 않을 때 흔히 발생합니다. Clash Meta（mihomo）설정을 사용할 때는 해당 필드를 지원하는 클라이언트로 로드해야 합니다. 클래식 Clash 코어와 mihomo는 지원 기능 범위가 다르므로 클라이언트 외형의 이름만 보고 호환성을 판단할 수 없습니다.

설정을 직접 수정했다면 먼저 서버의 원본 구독으로 되돌려 비교해 보세요. YAML은 공백으로 계층을 표현하므로 Tab, 잘못된 들여쓰기, 복사 과정에서 섞인 기호 때문에 로드가 실패할 수 있습니다. 클라이언트가 관리하는 구독의 캐시 파일을 직접 편집하면 다음 업데이트 때 덮어써질 수도 있으므로, 사용자 지정 규칙은 클라이언트가 지원하는 오버라이드, 확장 또는 설정 병합 영역에 추가해야 합니다.

두 번째 단계: 노드, 포트 및 현재 네트워크의 연결 가능 여부 판단

노드 지연 시간 테스트는 보통 지정한 노드를 통해 테스트 URL을 요청하고 응답 시간을 측정합니다. 테스트 실패는 도메인 조회, TCP 연결, TLS 핸드셰이크, 프록시 프로토콜 핸드셰이크 또는 대상 웹페이지 응답 단계에서 발생할 수 있습니다. 일부 클라이언트는 Timeout만 표시하므로 정확한 위치를 파악하려면 로그를 함께 확인해야 합니다.

먼저 교차 테스트를 진행하세요

• 같은 구독에서 지역과 진입점이 서로 다른 노드 3~5개를 선택해 한 노드만 테스트하는 상황을 피하세요.
• 같은 기기에서 가정용 네트워크와 휴대폰 핫스팟을 전환해 보세요. 핫스팟에서는 되지만 기존 네트워크의 모든 노드가 시간 초과라면 기존 네트워크의 DNS, 라우팅, 포트 제한 및 게이트웨이 설정을 중점적으로 확인하세요.
• 같은 네트워크에서 다른 기기로 테스트하세요. 한 기기에서만 실패한다면 대개 해당 기기의 권한, 프록시 설정 또는 방화벽에 문제가 있습니다.
• 클라이언트에서 지연 시간 테스트 주소를 바꿀 수 있다면 안정적인 HTTPS 주소로 다시 테스트하세요. 특정 테스트 사이트 하나에 접근할 수 없다고 해서 노드가 반드시 만료된 것은 아닙니다.

ping 결과를 프록시 노드 상태와 바로 동일시하지 마세요. 서버가 ICMP에 응답하지 않더라도 프록시 프로토콜에서 사용하는 TCP 또는 UDP 포트는 허용할 수 있습니다. 반대로 서버에 ping이 된다고 해서 해당 프록시 포트가 열려 있거나 인증 및 프로토콜 핸드셰이크가 성공했다는 뜻도 아닙니다.

TCP와 UDP 문제를 구분하세요

일반적인 웹페이지는 주로 TCP와 TLS를 사용하지만, 일부 게임·음성 통화·QUIC·DNS 환경에서는 UDP를 사용합니다. 웹페이지는 열리지만 특정 앱에서 시간 초과가 발생한다면 노드나 프로토콜이 사용 가능한 UDP 전달을 제공하지 않거나 TUN의 UDP 라우팅이 적용되지 않았을 수 있습니다. 먼저 일반 HTTPS 웹페이지로 TCP 프록시를 확인한 다음 UDP가 필요한 앱을 별도로 검증해 두 문제를 섞지 않도록 하세요.

특정 네트워크에서 모든 노드가 동시에 실패하고 네트워크를 바꾸자 즉시 복구된다면 노드를 하나씩 삭제할 필요는 대개 없습니다. 먼저 라우터를 재부팅하고 네트워크 연결을 끊었다가 다시 연결한 뒤, 다른 VPN·가속기·보안 프로그램의 네트워크 필터 기능이 활성화되어 있는지 확인하세요. 여러 도구가 동시에 가상 네트워크 카드나 라우팅 테이블을 만들거나 수정하면 데이터가 의도한 Clash 인터페이스로 들어가지 않을 수 있습니다.

세 번째 단계: 시스템 시간 및 인증서 검증 환경 동기화

프록시 연결, 구독 다운로드 및 HTTPS 접속에는 TLS 인증서 검증이 포함될 수 있습니다. 시스템 날짜, 시간대 또는 시간 오차가 너무 크면 인증서가 아직 유효하지 않거나 이미 만료된 것으로 판단됩니다. 클라이언트 로그에 certificate, x509, handshake 등의 문구가 나타날 수도 있고, 단순히 연결 실패로만 표시될 수도 있습니다.

1. 시스템의 날짜 및 시간 자동 설정 기능을 켜세요.
2. 시간대가 현재 위치와 일치하는지 확인하세요. 특히 UTC 오프셋을 수동으로 선택한 경우 주의해야 합니다.
3. 즉시 동기화를 한 번 실행한 뒤 Clash 클라이언트를 완전히 종료하고 다시 시작하세요.
4. 기기가 조직 정책으로 관리된다면 시간 동기화 서비스에 접속할 수 있는지 확인하고 시스템 인증서 저장소가 정상인지 점검하세요.

듀얼 부팅 기기, 장시간 절전 모드였던 노트북, 초기화 후 복원한 휴대폰, 오랫동안 인터넷에 연결하지 않은 기기에서는 시간 오차가 더 쉽게 발생합니다. 시간을 동기화한 후에는 브라우저 페이지만 새로 고치지 말고 구독을 다시 업데이트하고 노드를 테스트해야 합니다.

네 번째 단계: DNS 조회, Fake-IP 및 오염된 캐시 점검

DNS 장애의 흔한 증상은 노드 지연 시간은 가끔 정상인데 도메인을 열면 시간 초과가 발생하는 경우, 알려진 IP에 직접 접속하면 응답하지만 도메인 접속은 실패하는 경우, 로그에 lookup, resolve, nameserver 또는 context deadline exceeded가 연속으로 나타나는 경우입니다. Clash의 DNS 모듈은 프록시 노드 서버 도메인을 조회할 수도 있고 규칙에 따라 라우팅되는 대상 도메인을 처리할 수도 있으므로, DNS 오류는 여러 단계에 영향을 줄 수 있습니다.

먼저 시스템 DNS가 작동하는지 확인하세요

프록시를 종료하거나 시스템 프록시를 잠시 끈 뒤 운영체제 기본 도구로 일반 도메인을 조회하세요. 이 명령은 조회 결과 주소가 반환되는지만 확인하며, 해당 웹사이트 접속이 반드시 완료된다는 뜻은 아닙니다.

nslookup www.example.com

조회 자체가 시간 초과되면 네트워크를 다시 연결하고 시스템 DNS 캐시를 갱신하거나 라우터와 기기의 네트워크 설정에서 DNS 주소를 확인해 보세요. 시스템 조회는 정상인데 Clash 로그의 DNS 조회가 실패한다면 설정의 dns, nameserver, fallback, proxy-server-nameserver 등의 필드가 현재 코어에서 지원되는지 확인하세요.

Fake-IP 모드의 적용 범위를 이해하세요

mihomo에서 흔히 사용하는 강화 DNS 모드에는 fake-ip와 redir-host가 있습니다. Fake-IP는 먼저 앱에 예약 주소를 반환한 뒤 코어가 도메인 매핑을 저장하고 이후 라우팅을 처리합니다. 예약 주소가 보인다고 해서 반드시 DNS 오류인 것은 아닙니다. 실제로 확인해야 할 것은 요청이 Clash로 들어갔는지, 매핑이 존재하는지, 대상 도메인이 규칙에 따라 올바른 출구를 선택했는지입니다.

일부 로컬 네트워크 기기 검색, 기업 내부망 도메인, 프린터 주소 및 실제 DNS 반환값에 의존하는 프로그램은 Fake-IP를 그대로 사용하기에 적합하지 않습니다. 필요에 따라 Fake-IP 필터 규칙을 설정하거나 내부망 도메인에 지정된 리졸버를 사용하세요. 필터 범위는 최대한 명확하게 설정해야 하며, 지나치게 넓은 와일드카드 규칙은 도메인 매핑과 라우팅 효과를 떨어뜨립니다.

노드 서버 도메인은 별도로 조회해야 합니다

프록시 노드의 서버 필드 자체가 도메인이라면 코어는 프록시 채널을 연결하기 전에 먼저 해당 도메인을 조회해야 합니다. 이 조회가 아직 연결되지 않은 프록시에 의존하도록 설정되어 있으면 순환 대기가 발생할 수 있습니다. mihomo는 프록시 서버 도메인 조회를 위한 관련 DNS 설정 기능을 제공하지만, 구체적인 필드는 현재 코어 버전에 맞아야 합니다. 문제를 확인할 때 로그가 노드 서버 도메인 조회 단계에서 계속 멈춰 있는지 살펴보세요.

다섯 번째 단계: 시스템 프록시, 규칙 모드 및 TUN 적용 범위 확인

노드는 정상인데 앱이 프록시를 거치지 않는다면 대개 트래픽 적용 방식의 문제입니다. Clash의 시스템 프록시 스위치는 주로 운영체제 프록시 설정을 따르는 프로그램에 HTTP 또는 SOCKS 진입점을 제공합니다. 일부 게임, 명령줄 프로그램, 스토어 앱 및 자체 네트워크 스택을 구현한 소프트웨어는 시스템 프록시를 무시할 수 있습니다. TUN 모드는 가상 네트워크 카드와 라우팅을 통해 더 많은 트래픽을 가로채지만 추가 권한이 필요하며 다른 VPN이나 가상 네트워크 카드와 충돌하기도 쉽습니다.

먼저 규칙 모드로 정책 선택을 확인하세요

Rule 모드에서는 트래픽이 설정의 규칙을 위에서 아래로 매칭하고, 일치하는 규칙을 찾으면 해당 정책 그룹으로 전달됩니다. 노드 자체가 정상이어도 규칙이 대상 도메인을 DIRECT, REJECT 또는 유효한 노드가 선택되지 않은 정책 그룹으로 보내면 접속은 실패합니다. 연결 기록이나 로그를 열어 대상 도메인이 어떤 규칙과 일치했는지, 최종적으로 어떤 정책 그룹과 노드를 사용했는지 확인하세요.

Global 모드는 대부분의 트래픽을 지정한 정책으로 보내므로 진단에는 적합하지만 규칙 문제를 대신하는 용도로는 적합하지 않습니다. Global에서는 되지만 Rule에서는 되지 않는다면 규칙 순서, 규칙 집합 로드 상태 및 정책 그룹 선택을 확인하세요. 두 모드 모두 실패한다면 노드, DNS 및 로컬 포트 점검으로 돌아가야 합니다.

시스템 프록시 점검 순서

1. 클라이언트 창이 열려 있기만 한 것이 아니라 Clash 코어가 실행 중인지 확인하세요.
2. 시스템 프록시 스위치가 켜져 있고 운영체제의 프록시 주소가 로컬 수신 포트를 가리키는지 확인하세요.
3. 설정의 mixed-port, port 또는 socks-port가 클라이언트에 표시된 값과 일치하는지 확인하세요.
4. 브라우저에 별도로 설치하거나 설정한 다른 프록시 진입점을 끄고 요청이 이전 포트로 전달되지 않게 하세요.
5. 대상 앱을 다시 시작하세요. 일부 프로그램은 시작할 때만 시스템 프록시 설정을 읽습니다.

TUN 모드 점검 순서

1. 클라이언트가 가상 네트워크 카드 생성, 라우팅 수정 또는 네트워크 서비스 설치에 필요한 시스템 권한을 얻었는지 확인하세요.
2. 다른 VPN, 가상 머신 네트워크 도구 및 가속기를 잠시 종료한 뒤 TUN을 다시 활성화하세요.
3. 시스템에 해당 가상 네트워크 카드가 나타났는지 확인하고 기본 라우팅이 다른 프로그램에 의해 반복해서 덮어써지지 않는지 점검하세요.
4. TUN을 켠 뒤 전체 네트워크가 끊기면 먼저 TUN을 꺼서 네트워크를 복구한 다음 DNS 가로채기, 라우팅 제외 항목 및 인터페이스 자동 선택을 확인하세요.
5. 로컬 네트워크 접속에 문제가 있을 때는 사설 주소가 직접 연결되어야 하는지, 로컬 네트워크 대역이 잘못 프록시로 전달되고 있지 않은지 확인하세요.

시스템 프록시는 작동하지만 TUN이 작동하지 않는다면 노드와 기본 프록시 프로토콜에는 대개 문제가 없으므로 권한, 가상 네트워크 카드, 라우팅 및 DNS 적용을 중점적으로 확인해야 합니다. TUN은 작동하지만 시스템 프록시가 작동하지 않는다면 로컬 수신 포트, 시스템 프록시 주소 및 앱이 프록시 설정을 읽는지 확인하세요.

여섯 번째 단계: 로컬 수신 포트, 방화벽 및 포트 충돌 확인

Clash 코어는 로컬에서 HTTP, SOCKS 또는 mixed 포트를 수신해야 합니다. 다른 프로세스가 포트를 사용 중이면 코어가 시작되지 않거나 자동으로 종료될 수 있습니다. 로컬 보안 정책이 프로그램의 수신 또는 네트워크 연결을 차단하면 클라이언트 화면은 남아 있어도 요청이 완료되지 않을 수 있습니다.

먼저 클라이언트 로그에서 address already in use, bind, permission denied, connection refused 등의 정보를 찾으세요. address already in use는 보통 포트 충돌을 의미합니다. connection refused가 127.0.0.1 접속 중 나타나면 해당 포트에서 서비스를 수신하는 프로세스가 없다는 뜻인 경우가 많습니다. 원격 연결에서 refused가 나타나면 노드 포트가 닫혔거나 서버가 연결을 적극적으로 거부하는 상황일 수 있습니다.

설정에서 일반적으로 7890을 mixed 포트로 사용한다면 아래 요청으로 로컬 프록시 진입점을 확인할 수 있습니다. 실제로 실행할 때는 포트를 클라이언트에 현재 표시된 값으로 반드시 바꾸세요.

curl -x http://127.0.0.1:7890 https://www.example.com/ -I

이 요청이 성공하면 명령줄 프로그램이 로컬 프록시 포트에 연결해 HTTPS 요청을 한 번 완료할 수 있다는 뜻입니다. 브라우저에서 여전히 실패한다면 브라우저 프록시, 인증서 경고 또는 확장 프로그램 설정을 확인하세요. 로컬 포트에 즉시 연결할 수 없다는 메시지가 나오면 원격 노드를 계속 바꾸기보다 먼저 코어 상태와 포트 수신을 해결해야 합니다.

방화벽 확인 사항

• 현재 Clash 클라이언트와 코어 프로그램이 현재 네트워크 유형에 접근하도록 허용되어 있는지 확인하세요.
• 클라이언트를 업그레이드하면 실행 파일 경로가 바뀔 수 있으므로 시스템 방화벽 규칙을 다시 확인해야 합니다.
• 회사나 학교 네트워크에서는 일부 외부 연결 포트를 제한할 수 있으므로 휴대폰 핫스팟으로 교차 확인해 보세요.
• 라우터의 자녀 보호, 접근 제어 및 DNS 필터도 노드 서버나 구독 주소에 영향을 줄 수 있습니다.
• ‘로컬 네트워크 연결 허용’을 켠 후에만 문제가 발생한다면 수신 주소와 로컬 네트워크 방화벽 규칙을 확인하세요. 신뢰할 수 없는 네트워크에 로컬 프록시 포트를 노출하지 마세요.

일곱 번째 단계: 로그로 실패 단계를 찾고 최소 조건으로 재테스트

로그의 가치는 실패가 어느 단계에서 발생했는지 확인하는 데 있습니다. 로그 수준을 일시적으로 info 또는 debug로 높여 문제를 한 번 재현한 뒤 원래 수준으로 되돌리세요. 장시간 많은 기록이 쌓이는 것을 방지할 수 있습니다. 로그를 공유하기 전에는 구독 주소, 인증 정보, 노드 자격 증명 및 개인 접속 기록이 포함될 수 있는 내용을 가려야 합니다.

최소 테스트 경로 구성

1. 정상적으로 로드되는 원본 구독 설정을 하나 보관하세요.
2. 사용 가능한 것으로 확인된 노드 하나와 안정적인 HTTPS 테스트 주소 하나를 선택하세요.
3. 먼저 TUN을 끄고 시스템 프록시만 사용해 브라우저 접속을 확인하세요.
4. 시스템 프록시가 작동한 후 Rule 모드를 켜고 규칙 매칭을 확인하세요.
5. 마지막으로 TUN을 켜고 시스템 프록시를 읽지 않는 앱을 테스트하세요.
6. 각 단계에서 로그 변화를 기록하고 문제가 다시 나타나면 새로운 변수를 추가하지 마세요.

이 순서대로 진행하면 문제를 설정 출처, 원격 노드, 도메인 조회, 로컬 프록시 및 전체 트래픽 적용이라는 다섯 가지 범위로 나눌 수 있습니다. 최소 설정에서도 여러 네트워크에서 모든 노드가 시간 초과된다면 구독 서비스 제공업체에 노드 상태와 프로토콜 매개변수를 확인해야 합니다. 원래 설정에서만 실패한다면 DNS, 규칙, 오버라이드 및 TUN 필드를 중점적으로 비교하세요.

노드 시간 초과 문제 해결 체크리스트

Clash 노드에 연결할 수 없을 때는 다음의 고정된 순서대로 진행하세요. 앞 항목이 정상임을 확인한 후 다음 항목으로 넘어가면 되며, 일반적으로 클라이언트를 반복해서 설치할 필요는 없습니다.

1. 기기 자체가 일반 웹사이트에 직접 연결할 수 있고 현재 네트워크가 끊기지 않았는지 확인하세요.
2. 구독 업데이트가 성공했고 설정에 노드와 정책 그룹이 있으며 코어 로드 과정에서 YAML 오류가 없는지 확인하세요.
3. 여러 노드를 테스트하고 다른 네트워크 또는 다른 기기로 교차 검증하세요.
4. 시간 및 시간대 자동 동기화를 켜고 TLS 인증서 검증 이상을 배제하세요.
5. 시스템 DNS, Clash DNS 및 노드 서버 도메인 조회를 각각 확인하세요.
6. 정책 그룹 선택, 규칙 매칭 및 프록시 모드가 예상대로 설정되어 있는지 확인하세요.
7. 먼저 시스템 프록시를 확인한 다음 TUN 권한, 가상 네트워크 카드 및 라우팅을 별도로 점검하세요.
8. 로컬 수신 포트를 확인하고 포트 사용 충돌과 방화벽 제한을 해결하세요.
9. 로그 키워드로 실패 단계를 파악한 뒤 최소 조건으로 재테스트하세요.