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

먼저 구분하기: 속도 테스트 시간 초과, 프록시 연결 실패, 웹사이트 접속 실패

Clash에서 노드가 시간 초과로 표시된다고 해서 노드 서버가 중단된 것은 아닙니다. 지연 시간 테스트는 보통 노드를 통해 테스트 주소에 요청을 보내므로 로컬 네트워크, 노드 연결, 프록시 핸드셰이크, 외부 DNS 조회, 테스트 사이트 상태에 모두 영향을 받습니다. 어느 한 단계라도 실패하면 시간 초과로 표시될 수 있습니다. 먼저 실패 지점을 확인한 다음 해당 설정을 조정하세요. DNS, 포트, 코어를 무작정 바꿔 가며 테스트하지 마세요.

Clash는 코어와 설정 생태계를 통칭하며, 클라이언트는 인터페이스, 구독 관리, 시스템 프록시 등의 기능을 담당합니다. Clash Meta는 이후 mihomo라는 이름을 사용합니다. 클라이언트마다 메뉴 위치, 설정 병합 방식, 코어 기능이 다를 수 있습니다. 문제를 진단할 때는 구독 파일의 내용만 보지 말고 현재 실행 중인 코어의 로그와 실제 적용된 설정을 기준으로 확인하세요.

1단계: 구독 업데이트 성공 및 설정 활성화 확인

노드 사용 여부를 판단하기 전에 클라이언트가 새 설정을 실제로 불러왔는지 확인하세요. 구독 업데이트 성공, 설정 파싱 성공, 해당 설정으로 전환은 각각 별개의 작업입니다. 원격 구독 업데이트가 실패하면 클라이언트가 로컬 캐시를 계속 사용할 수 있으므로, 목록에 노드가 보인다고 해서 이번 업데이트가 성공한 것은 아닙니다.

1. 업데이트 시간과 결과를 확인하세요. 현재 클라이언트의 구독 또는 설정 목록에서 사용 중인 항목을 찾아 업데이트한 뒤 HTTP 상태 코드나 오류 메시지를 기록하세요. 클라이언트마다 메뉴 이름은 다릅니다. 자동 업데이트 간격을 최근 업데이트 성공 시각으로 오해하지 마세요.
2. 응답 내용이 설정 파일인지 확인하세요. HTTP 200은 요청이 성공했다는 뜻일 뿐입니다. 로그인 페이지나 트래픽 소진 안내 페이지도 200을 반환할 수 있습니다. 로그에 YAML 파싱 오류가 있다면 들여쓰기를 무작정 지우기보다 먼저 응답 내용의 종류를 확인하세요.
3. 설정이 선택되고 다시 불러와졌는지 확인하세요. 전환 후 정책 그룹에 예상한 노드가 표시되는지 확인하고, 로그에서 알 수 없는 필드, 누락된 프록시 그룹, 중복 이름, 지원되지 않는 프록시 유형이 있는지 살펴보세요.
4. 기본 설정과 노드 제공자를 구분하세요. proxy-providers를 사용하는 설정은 노드를 별도로 가져오는 과정도 거칩니다. 기본 설정 업데이트가 완료되었다고 해서 제공자에서 노드까지 정상적으로 가져온 것은 아닙니다.

구독 다운로드에도 프록시가 필요한 경우는?

기존 노드가 작동하지 않는데 구독 업데이트가 해당 노드를 거치도록 설정되어 있으면 업데이트 경로가 막힐 수 있습니다. 먼저 현재 네트워크에서 구독 도메인에 직접 연결할 수 있는지 확인하세요. 클라이언트에 구독 업데이트 프록시 옵션이 있다면, 검증된 경로로 임시 전환할 수 있습니다. 기본 설정의 proxy-providers 가져오기와 클라이언트 자체의 구독 다운로드는 서로 다른 방식일 수 있으므로 로그를 각각 확인하세요.

토큰이 포함된 구독 링크를 공개 진단 사이트에 붙여 넣지 마세요. 도움을 요청할 때는 상태 코드, 민감한 정보를 가린 오류 메시지, 업데이트 시각만 공유하세요. 전체 구독 주소는 접근 자격 증명과 같습니다.

2단계: 로컬 네트워크 및 네트워크 변경에 따른 차이 확인

모든 노드가 갑자기 동시에 실패했다면 노드들이 공유하는 로컬 네트워크부터 확인하세요. 시스템 프록시와 TUN을 잠시 끄고 현재 네트워크에서 원래 직접 접속할 수 있는 웹페이지를 열어 보세요. 기본 네트워크 연결도 되지 않으면 Wi-Fi, 유선 연결, 인증 포털, 라우터 문제부터 해결해야 합니다. 테스트가 끝나면 필요한 프록시 설정을 다시 켜세요.

• 네트워크 인증을 확인하세요: 호텔, 학교, 공공 Wi-Fi는 브라우저에서 먼저 로그인해야 할 수 있습니다. 프록시가 켜져 있으면 인증 페이지로 제대로 이동하지 않을 수 있습니다.
• 시스템 시간을 확인하세요: 날짜, 시간대 또는 시계가 크게 틀리면 인증서 유효 기간을 확인하는 과정에서 오류가 날 수 있습니다. 시스템 자동 시간 설정을 켠 뒤 TLS 기반 노드를 다시 테스트하세요.
• 휴대폰 핫스팟으로 잠시 전환하세요: 기기, 설정, 노드는 그대로 두고 네트워크만 바꿉니다. 핫스팟에서는 연결되지만 기존 네트워크에서는 실패한다면 기존 네트워크의 DNS, 외부 연결 정책, IPv6 경로를 우선 확인하세요.
• 중복 연결을 막는 프로그램을 확인하세요: 라우팅을 여러 도구가 동시에 변경하지 않도록 다른 VPN, 프록시 클라이언트, 트래픽 필터링 도구를 잠시 종료하세요. 문제 해결을 위해 시스템 방화벽을 장기간 끄지는 마세요.

핫스팟 테스트는 원인 범위를 좁혀 줄 뿐, 통신사 차단을 단독으로 입증하지는 못합니다. 휴대폰 네트워크와 유선 인터넷은 DNS 응답, IPv4/IPv6 외부 주소, 라우팅 경로가 다를 수 있습니다. 지연 테스트를 반복해서 누르는 것보다 두 테스트의 차이를 기록하는 편이 유용합니다.

3단계: 수신 포트와 앱 트래픽의 코어 유입 여부 확인

원격 노드를 점검하기 전에 로컬 프록시 진입점부터 확인하세요. 포트 점유, 코어 시작 실패, 시스템 프록시가 이전 포트를 가리키는 문제는 모두 앱에서 프록시에 연결할 수 없는 것처럼 보이게 합니다. 아래는 로컬 진입점의 수신 관계를 보여 주는 예시일 뿐, 노드까지 포함한 완전한 설정은 아닙니다.

# 현재 설정의 최상위에 병합하세요. 같은 이름의 키를 중복 선언하지 마세요.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받습니다. 이 예시에서 사용하는 포트는 7890입니다. external-controller는 제어 인터페이스이며 브라우저용 프록시 진입점이 아닙니다. 일반적으로 제어 포트로 쓰이는 9090을 앱의 HTTP 프록시 설정에 입력하면 안 됩니다.

7890 포트를 사용 중인 프로세스 확인

Windows에서는 PowerShell에서 수신 중인 항목을 확인한 다음, 표시된 프로세스 ID로 해당 프로그램을 찾을 수 있습니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

macOS에서는 시스템의 lsof를, Linux에서는 ss를 사용할 수 있습니다. 프로세스 세부 정보를 확인하려면 적절한 권한이 필요할 수 있습니다:

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

# Linux
ss -lntp 'sport = :7890'

다른 프록시 인스턴스가 포트를 사용 중이라면 먼저 어느 인스턴스가 서비스를 제공하는지 확인한 뒤, 중복 프로세스를 종료하거나 포트를 변경하세요. 포트를 바꾸면 시스템 프록시와 앱 설정도 함께 업데이트해야 합니다. 로그에 address already in use가 표시되면 노드를 바꾸기 전에 포트 충돌부터 해결하세요.

시스템 프록시 설정을 우회해 로컬 진입점을 직접 테스트

curl --noproxy "" -x http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://example.com/

Windows PowerShell에서는 위의 curl을 curl.exe로 입력하는 것이 좋습니다. 일부 환경에서 같은 이름의 별칭이 사용될 수 있기 때문입니다. --noproxy ""는 이번 요청에 적용되는 프록시 우회 목록을 비웁니다. 5초는 연결 대기 시간, 15초는 요청 전체 제한 시간입니다.

127.0.0.1:7890에 연결할 수 없다는 메시지가 나오면 코어와 수신 포트를 먼저 확인하세요. 200, 301 등의 HTTP 응답이 돌아오면 이번 요청에 응답이 도착했다는 뜻입니다. 다만 연결 로그에서 최종 정책을 확인해야 합니다. 규칙에 따라 DIRECT로 연결되었을 수 있으므로 응답 코드만으로 프록시 노드가 정상이라고 판단할 수 없습니다.

4단계: 노드 도메인 조회와 대상 도메인 조회 구분

DNS 문제를 점검할 때는 먼저 “어떤 도메인”의 조회가 실패했는지 확인하세요. 노드의 server에 도메인이 설정되어 있다면 코어는 노드에 연결하기 전에 해당 도메인을 조회해야 합니다. 대상 웹사이트에 접속할 때도 별도의 DNS 조회가 발생할 수 있습니다. 노드 주소 조회 실패와 웹사이트 도메인 조회 실패를 하나의 원인으로 묶어서는 안 됩니다.

• 노드 도메인 조회 실패: 로그에 lookup, no such host, DNS 조회 시간 초과 등이 표시될 수 있습니다. 먼저 시스템 도구로 노드 도메인을 조회하고 A 또는 AAAA 레코드가 반환되는지 기록한 다음 코어 로그와 비교하세요.
• 대상 도메인 조회 실패: 노드 핸드셰이크는 성공했지만 이후 요청이 DNS 조회 오류로 중단될 수 있습니다. 로컬, 코어 DNS, 서버 외부 연결 중 어느 단계에서 실패했는지 확인하세요.
• IPv6 경로에서만 문제가 발생하는 경우: 로그에서 실제 연결에 IPv4 주소와 IPv6 주소 중 어느 쪽을 사용했는지 확인하세요. 시스템 도구에서 조회에 성공했다고 해당 주소 체계의 네트워크 경로가 정상이라는 뜻은 아닙니다. 코어가 같은 DNS 확인 도구를 사용한다는 보장도 없습니다.

아래는 mihomo에서 노드 도메인을 별도 리졸버로 조회할 때 사용하는 필드 관계를 보여 줍니다. 현재 코어가 해당 필드를 지원해야 합니다. 범용 DNS 권장 설정이 아니므로 기존 dns 맵에 병합하고 같은 단계에 dns를 두 번 선언하지 마세요.

dns:
  enable: true
  nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1

proxy-server-nameserver는 프록시 노드 도메인을 조회할 때 사용합니다. 예시에 나온 리졸버 주소가 현재 네트워크에서 연결된다는 보장은 없으므로, 연결 가능 여부를 확인한 리졸버를 선택하세요. 이미 DoH, Fake-IP, 도메인별 리졸버 설정을 사용 중이라면 기존 구조를 유지하고 문제와 직접 관련된 부분만 수정하세요.

5단계: 프로토콜 설정과 코어 지원 범위 비교

같은 주소와 포트로 TCP 연결이 된다고 해서 프록시 프로토콜 핸드셰이크까지 성공하는 것은 아닙니다. 로컬 진입점이 정상이고 노드 주소도 조회되는데 특정 유형의 노드만 실패한다면 프로토콜 지원 여부와 서버 설정을 확인하세요. 구형 Clash 코어와 mihomo가 지원하는 프로토콜 범위는 다릅니다. 클라이언트 화면에 노드 이름이 표시된다고 현재 실행 중인 코어가 해당 프로토콜을 사용할 수 있는 것은 아닙니다.

먼저 현재 코어용으로 서비스 제공자가 안내한 설정을 다시 가져오세요. 노드 이름만 보고 프로토콜을 추측하거나 이해하지 못한 설정을 임의로 삭제하지 마세요. 구독 변환을 사용한다면 변환 대상이 실제 코어와 일치하는지 확인하세요. 호환되지 않는 변환은 전송 또는 인증 필드를 누락시킬 수 있습니다.

TCP 연결 테스트로 확인할 수 있는 내용은 제한적입니다

Windows의 Test-NetConnection으로 지정한 주소와 포트에 TCP 연결을 시도할 수 있습니다. -ComputerName 뒤에는 설정에 사용된 실제 노드 도메인을, -Port 뒤에는 실제 포트를 입력하세요. 이 TCP 테스트 결과로 Hysteria2처럼 UDP 기반 프로토콜의 사용 가능 여부를 판단해서는 안 됩니다.

TCP 테스트에 성공해도 그 시점에 해당 포트로 연결할 수 있었다는 뜻일 뿐입니다. 비밀번호, TLS, 프록시 전송 과정은 여전히 실패할 수 있습니다. 반대로 노드가 ICMP에 응답하지 않는 경우도 흔합니다. ping 패킷 손실만으로 프록시 서비스를 사용할 수 없다고 단정할 수는 없습니다.

6단계: 서버 문제, 외부 연결 제한, 속도 테스트 대상 오류 확인

앞 단계들을 대체로 확인한 뒤에 서버와 외부 연결을 중점적으로 살펴보세요. 이때는 지연 테스트 주소 하나만 반복해서 확인하지 말고, 같은 노드에서 대상을 바꿔 보고 같은 대상을 다른 노드로도 교차 테스트하세요.

1. 같은 노드로 대상 두 곳을 테스트하세요. 일반 웹페이지는 열리는데 지연 시간 테스트만 실패한다면 클라이언트에 설정된 테스트 URL, 응답 조건, 시간 초과 기준을 확인하세요. 테스트 대상의 문제와 노드 장애는 별개입니다.
2. 같은 대상에 다른 노드를 사용해 보세요. 특정 외부 연결 경로에서만 실패한다면 해당 경로에서 대상까지의 라우팅, 대상 사이트의 보안 정책, 서버 측 DNS 문제일 수 있습니다.
3. 계정 상태를 확인하세요. 이용 기간, 남은 트래픽, 동시 접속 기기 제한, 서비스 제공자의 점검 공지를 확인하세요. 구독을 다운로드할 수 있다고 해서 프록시 계정의 사용량이 남아 있다는 뜻은 아닙니다.
4. 민감 정보를 가린 증거를 서비스 제공자에게 전달하세요. 오류가 발생한 시각과 시간대, 노드 식별 정보, 코어 버전, 오류 유형, 네트워크 변경 결과, 대상 도메인을 전달하세요. 비밀번호, UUID, 전체 구독 링크, 전체 설정은 공유하지 마세요.

connection refused는 보통 연결이 명시적으로 거부되었음을 뜻합니다. 포트에서 서비스가 수신 대기 중이지 않거나 중간 장비가 연결을 거부한 경우가 많습니다. i/o timeout은 네트워크 작업이 제한 시간 안에 끝나지 않았다는 뜻이므로 연결, 핸드셰이크, 읽기·쓰기 중 어느 단계에서 발생했는지 로그를 살펴봐야 합니다. EOF는 데이터 스트림이 끝났다는 의미이며, 그 자체로 인증 실패인지 원격에서 연결을 끊었는지는 판단할 수 없습니다.

노드로 일반 웹사이트는 열리지만 특정 플랫폼에서 403, CAPTCHA 또는 지역 제한이 표시된다면 대상 사이트와 외부 연결 경로의 문제로 다루세요. 연결 시간 초과를 늘려도 애플리케이션 계층 제한은 해결되지 않으며, 로컬 포트 문제로 분류해서도 안 됩니다.

복구 확인: 실제 트래픽이 예상한 정책을 따르는지 확인

문제 해결 완료 기준은 지연 시간 숫자가 초록색으로 바뀌는 것이 아니라 실제 요청이 성공하고 예상한 경로로 연결되는 것입니다. 규칙 모드에서는 클라이언트가 규칙에 따라 정책을 선택합니다. 노드 테스트는 지정된 노드에 직접 요청하는 경우가 많아 실제 앱 트래픽과 경로가 다를 수 있습니다. 연결 화면이나 실행 로그에서 대상 도메인, 적용된 규칙, 최종 사용 노드를 확인하세요.

• 브라우저에서는 실패하지만 프록시를 명시한 요청은 성공하는 경우: 시스템 프록시 포트, 브라우저 자체의 프록시 설정, 확장 프로그램의 프록시 제어, 우회 목록을 확인하세요. 기존 연결은 이전 경로를 재사용할 수 있으므로 관련 연결을 닫고 다시 요청해 보세요.
• 브라우저는 정상인데 터미널에서는 실패하는 경우: 터미널 도구가 시스템 프록시 설정을 따르지 않을 수 있습니다. 먼저 이 글의 curl -x 명시적 프록시 방식으로 확인한 뒤 해당 도구가 지원하는 프록시 환경 변수를 설정할지 결정하세요.
• 더 많은 앱의 트래픽을 프록시로 연결해야 하는 경우: TUN은 시스템 프록시를 읽지 않는 일부 앱의 트래픽을 처리할 수 있지만 권한, 라우팅, DNS 설정에 영향을 받습니다. TUN을 켜도 만료된 구독, 잘못된 비밀번호, 작동하지 않는 노드는 해결되지 않습니다.
• 로그 수준을 임시로 변경했다면: 문제 해결 후 log-level을 평소 사용하는 info 또는 기존 설정으로 되돌리세요. 접속 대상 정보가 포함된 로그가 장기간 많이 쌓이지 않도록 주의하세요.