Clash 노드 시간 초과·속도 테스트 실패 해결: 구독 업데이트부터 DNS까지 점검 순서

먼저 구분하세요: 속도 테스트 실패, 노드 연결 오류, 규칙 미적용

시간 초과가 떴다고 바로 클라이언트를 다시 설치하지 마세요. 속도 테스트 결과가 의미하는 것은 커널이 지정된 시간 안에 선택한 노드를 통해 테스트 주소에 요청을 보내지 못했다는 것입니다. 테스트 주소에 접속할 수 없거나, 노드 연결이 실패하거나, DNS 확인에 문제가 있어도 같은 시간 초과가 발생할 수 있습니다. 먼저 문제가 발생하는 범위를 파악한 다음 설정을 변경하세요.

비교할 수 있도록 현재 상태를 기록하세요

1. 클라이언트 버전, 커널 이름과 버전, 현재 설정 이름, 오류 발생 시간을 기록하세요.
2. 설정 사본을 저장하세요. 현재 프록시 모드, 정책 그룹 선택, 시스템 프록시와 TUN 설정을 캡처해 두세요.
3. 노드 하나, 테스트 주소 하나, 실제 웹페이지 하나를 정한 뒤 매번 설정을 하나씩만 변경하세요.
4. 클라이언트의 '로그'와 '연결' 화면을 여세요. 클라이언트마다 메뉴 이름과 위치가 다를 수 있으니 실제 화면을 기준으로 확인하세요.

속도 테스트 단위는 보통 밀리초이며, 해당 요청에 걸린 시간을 뜻합니다. 다운로드 대역폭을 나타내는 값은 아닙니다. 시간 초과 기준을 3000밀리초에서 10000밀리초로 잠시 늘리면 요청 연결이 느린 것인지 확인할 수 있습니다. 이 값은 진단 설정의 예시일 뿐 실제 성능을 나타내거나 끊어진 노드를 복구하지는 않습니다.

1단계: 구독이 유효하고 새 설정이 활성화되어 있는지 확인

먼저 클라이언트의 '구독' 또는 '설정' 화면에서 수동 업데이트를 실행하세요. 업데이트 완료 시간이 바뀌었는지 확인한 다음, 방금 업데이트한 설정이 현재 활성화되어 있는지 확인하세요. 목록에 새 설정이 보여도 커널이 해당 설정을 불러왔다는 뜻은 아닙니다.

업데이트 결과에 따라 점검하세요

• 401 또는 403 응답: 구독 주소가 완전한지, 액세스 토큰이 변경되었는지, 구독 계정 상태에 문제가 없는지 확인하세요. 구체적인 의미는 서버 안내를 따르세요.
• 404 응답: 경로가 만료되었는지 확인하고, 기존 구독 관리 페이지에서 주소를 다시 복사하세요. 오래된 북마크는 사용하지 마세요.
• 200 응답이지만 가져오기에 실패: 응답 내용이 실제로 로그인 페이지나 오류 페이지인지 확인하세요. HTTP 요청이 성공해도 사용 가능한 설정 파일이 반환되었다는 뜻은 아닙니다.
• YAML 파싱 오류: 들여쓰기, 필드 형식, 클라이언트가 지원하는 구독 형식을 확인하세요. 개별 노드 링크를 전체 설정 파일처럼 불러오지 마세요.
• 구독 다운로드 시간 초과: 업데이트 요청이 현재 작동하지 않는 프록시를 사용하는지 확인하세요. 클라이언트에 구독 업데이트용 프록시 옵션이 있다면 요청 방식을 잠시 바꿔 다시 시도하세요.

업데이트한 다음에는 노드 이름과 개수, 정책 그룹 구성원이 예상과 일치하는지 확인하세요. 서버에서 노드 주소를 바꿨거나 로컬 오버라이드 규칙이 새 노드를 걸러냈을 수 있습니다. 설정을 불러오지 못했다면 먼저 오류를 해결하세요. 속도 테스트를 반복해서 눌러도 해결되지 않습니다.

2단계: 시스템 시간을 맞추고 기본 네트워크 문제 확인

기기가 정상적으로 인터넷에 연결되는지 확인한 다음 시스템 날짜와 시간, 자동 동기화 상태를 점검하세요. 인증서 검증에는 정확한 시간이 필요하며 일부 인증 방식도 시간 오차에 민감합니다. 표시된 시간대가 다르다고 반드시 문제가 있는 것은 아닙니다. 중요한 것은 시스템의 실제 시간이 정확한지 여부입니다.

• Windows: '설정' → '시간 및 언어' → '날짜 및 시간'에서 '시간 자동 설정'을 확인한 뒤 '지금 동기화'를 실행하세요.
• macOS: '시스템 설정' → '일반' → '날짜 및 시간'에서 날짜와 시간을 자동으로 설정하는 옵션을 확인하세요.
• Android: 시스템 설정에서 '날짜 및 시간'으로 이동해 자동 시간 설정을 켜세요. 메뉴 위치는 시스템 버전과 기기에 따라 다를 수 있습니다.

로그에 certificate has expired 또는 certificate is not yet valid가 표시되면 먼저 기기의 시간을 확인하고 서버 인증서의 유효 기간을 점검하세요. 오류를 피하려고 인증서 검증을 끄지 마세요. 실제 문제를 숨기고 연결 보안을 낮출 수 있습니다.

네트워크를 바꿔 문제 범위 확인

같은 노드와 설정을 유지한 채 컴퓨터를 현재 네트워크에서 휴대폰 핫스팟으로 바꿔 다시 테스트하세요. 핫스팟에서는 되지만 원래 네트워크에서는 안 된다면 원래 네트워크의 접속 제한, 인증 페이지, 라우터 설정부터 확인하세요. 두 네트워크 모두 실패하면 로컬 환경과 노드를 계속 점검하세요. 네트워크 변경은 문제 범위를 좁히는 데 도움이 될 뿐, 한 번의 결과만으로 서버 오류를 단정할 수는 없습니다.

3단계: 커널 실행 상태, 포트 충돌, 시스템 프록시 확인

클라이언트 화면에서 커널이 정상 실행 중인지 확인하세요. 그래픽 창이 열려 있다고 mihomo가 정상적으로 시작된 것은 아닙니다. 로그의 address already in use는 보통 수신 주소나 포트를 다른 프로세스가 사용 중이라는 뜻입니다. 노드를 테스트하기 전에 시작 오류부터 해결하세요.

실제로 수신 중인 포트 확인

mixed-port는 HTTP와 SOCKS5 프록시 연결을 모두 제공합니다. 아래에서는 로컬 혼합 포트 7890을 예로 듭니다. 실제 포트는 클라이언트 설정이나 현재 적용 중인 설정에서 확인하세요. 이 예시 값이 모든 클라이언트의 기본값은 아닙니다.

# 설정 조각 예시이며 전체 설정이 아닙니다
mixed-port: 7890
allow-lan: false

Windows 명령 프롬프트에서 포트가 수신 중인지 확인하세요:

netstat -ano | findstr LISTENING | findstr :7890

macOS 또는 해당 도구가 설치된 Linux 시스템에서 확인하세요:

lsof -nP -iTCP:7890 -sTCP:LISTEN

다른 프로세스가 포트를 사용 중이라면 먼저 프로세스 번호로 프로그램을 확인한 다음, 불필요한 프로그램을 정상 종료하거나 Clash의 포트를 변경하세요. 정체를 알 수 없는 시스템 프로세스를 강제 종료하지 마세요. 포트를 변경한 뒤에는 앱에 직접 입력한 프록시 주소도 함께 업데이트해야 합니다.

로컬 프록시 연결과 원격 노드 구분하기

Windows에서는 다음 명령으로 로컬 HTTP 프록시를 명시해 요청을 보낼 수 있습니다. 테스트 주소는 명령 형식을 보여 주기 위한 예시입니다. 비교 테스트에는 접속 가능 여부를 확인한 HTTPS 주소를 사용하세요.

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

macOS 또는 Linux에서는 명령 앞부분의 curl.exe를 curl로 바꾸세요. 127.0.0.1:7890에 연결할 수 없다는 메시지가 바로 나오면 로컬 수신 상태와 포트를 먼저 확인하세요. 요청이 커널에 전달됐다면 연결 패널에서 최종적으로 어떤 정책과 노드를 거쳤는지 확인하세요. 프록시를 명시하면 요청이 프록시 입구로 들어간다는 것만 확인할 수 있으며, 규칙에 따라 원격 프록시가 선택된다는 보장은 없습니다.

프록시를 명시한 테스트는 성공하지만 브라우저에서 연결되지 않는다면 클라이언트의 '시스템 프록시' 설정, 브라우저 자체 프록시 설정, 시스템 프록시를 덮어쓰는 다른 네트워크 도구를 확인하세요. TUN 모드에는 서비스 권한과 라우팅도 관련되므로 이 단계에서 시스템 프록시와 함께 반복해서 전환하지 않는 편이 좋습니다.

4단계: 서버 도메인과 대상 도메인의 DNS를 따로 확인

DNS 문제는 최소 두 곳으로 나눠 확인해야 합니다. 하나는 노드 서버 도메인을 주소로 변환하는 과정이고, 다른 하나는 접속하려는 웹사이트 도메인을 변환하는 과정입니다. 전자에 실패하면 프록시 연결 자체가 성립하지 않을 수 있습니다. 후자에 실패하면 노드 속도 테스트는 정상인데 특정 웹페이지가 열리지 않을 수 있습니다.

먼저 노드 서버 도메인 확인

현재 설정에서 노드의 server 필드를 확인하세요. 값이 도메인이라면 nslookup 또는 Resolve-DnsName으로 시스템의 DNS 조회 결과를 확인할 수 있습니다. 명령에는 실제 서버 도메인을 입력하세요. 구독 링크나 경로가 포함된 URL 전체를 입력하면 안 됩니다.

• 시스템 DNS 조회가 실패하고 클라이언트에서도 조회 오류가 발생함: 먼저 로컬 DNS와 네트워크 연결 상태를 확인하세요.
• 시스템 DNS 조회는 정상인데 클라이언트에서 실패함: 커널이 사용하는 DNS 업스트림과 접근 방식을 확인하세요. 두 경로가 서로 다를 수 있습니다.
• 암호화 DNS를 설정함: 해당 엔드포인트에 접속할 수 있는지 확인하세요. 엔드포인트 도메인도 먼저 조회할 수 있어야 할 수 있습니다.
• mihomo 사용 중: 해당 버전에서 proxy-server-nameserver 설정을 확인하세요. 이 설정은 프록시 서버 도메인 조회에 사용할 업스트림을 지정합니다. 지원 여부는 현재 커널 설정 문서를 참고하세요.

다음으로 Fake-IP와 앱 캐시 확인

Fake-IP 모드에서는 DNS가 가상 주소를 반환하는 것이 정상일 수 있습니다. 일반적인 설정에서는 198.18.0.0/16 대역을 사용하므로, 이런 주소가 보인다고 바로 DNS 오류로 판단할 수는 없습니다. 커널 연결 기록을 함께 확인해 앱 요청이 제대로 가로채졌는지, 도메인 매핑이 여전히 유효한지 살펴보세요.

브라우저의 보안 DNS, 앱 내장 DNS, 시스템 DNS는 서로 다른 경로를 사용할 수 있습니다. 특정 앱에서만 문제가 생긴다면 설정 파일 전체를 곧바로 바꾸지 말고 해당 앱의 DNS 설정부터 확인하세요. 비교를 위해 앱의 사용자 지정 DNS를 잠시 끄고 결과를 기록한 다음, 장기적으로 사용할 설정을 결정하세요.

DNS 옵션은 한 번에 하나씩만 변경하고 설정을 다시 불러온 뒤 테스트 앱을 완전히 종료했다가 다시 여세요. Windows에서는 ipconfig /flushdns로 시스템 DNS 캐시를 지울 수 있지만, 브라우저 자체 캐시까지 자동으로 지우거나 커널의 캐시 관리를 대신하지는 않습니다. Fake-IP와 다른 모드를 전환할 때는 이전 연결과 매핑도 함께 확인하세요.

5단계: 프로토콜 설정과 전송 조건을 항목별로 확인

일부 노드만 실패할 때는 해당 노드 자체를 집중적으로 확인하세요. 설정을 직접 조합하지 말고 구독 원본에서 다시 업데이트하세요. Clash 그래픽 클라이언트와 커널은 서로 다른 계층입니다. 화면에 특정 노드 유형이 표시되어도 현재 실행 중인 커널 버전이 그 유형이나 모든 필드를 지원한다는 뜻은 아닙니다.

QUIC 기반 노드 전송은 보통 UDP를 사용합니다. 현재 네트워크에서 UDP가 제한되어 있다면 로컬 HTTP 프록시 포트를 바꿔도 원격 전송 문제는 해결되지 않습니다. 다른 네트워크에서 비교하거나 서버가 제공하는 다른 전송 유형을 테스트하세요. 일반적인 TCP 포트 연결 테스트만으로 UDP 노드의 사용 가능 여부를 확인할 수는 없습니다.

TCP 연결에 성공해도 특정 수신 포트까지 연결이 성립했다는 뜻일 뿐입니다. 인증 실패, TLS 핸드셰이크 오류, 전송 경로 불일치가 있으면 프록시를 사용할 수 없습니다. '포트 연결 성공'만으로 프로토콜 전체가 정상 작동한다고 판단하지 마세요.

마지막 확인: 규칙, 로그, 실제 요청을 함께 살펴 문제 범위 좁히기

문제를 해결한 뒤에는 속도 테스트 색상만 확인하지 마세요. 실제 웹페이지를 열고 연결 패널에서 대상 도메인, 적용된 규칙, 정책 그룹, 최종 노드를 확인하세요. 규칙 모드에서 테스트 페이지가 DIRECT로 연결될 수 있습니다. 이 경우 페이지가 열려도 선택한 프록시 노드가 정상이라는 뜻은 아닙니다.

로그로 오류 발생 단계 찾기

• connection refused: 대상이 연결을 명시적으로 거부했습니다. 주소, 포트, 서비스의 수신 상태를 확인하세요.
• i/o timeout: 요청이 어느 단계에서 제시간에 완료되지 않았습니다. 앞뒤 로그를 보고 DNS 조회, 연결, 핸드셰이크 중 어디에서 시간 초과가 났는지 확인하세요.
• no such host: 도메인 철자와 DNS 조회 경로부터 확인하세요.
• authentication failed: 인증 설정과 계정 상태를 확인하세요. DNS만 계속 바꾸지 마세요.
• unsupported proxy type: 설정 유형과 커널 호환성을 확인하고, 먼저 설정 불러오기 오류를 해결하세요.

로그 수준을 일시적으로 높여야 한다면 재현 가능한 작업을 한 번만 기록한 뒤 평소 설정으로 되돌리세요. 점검이 끝나면 테스트 주소, 프록시 모드, 앱 DNS 설정을 원래대로 복구하고 실제로 효과가 있었던 변경만 유지하세요. 진단용 상태를 장기 설정으로 남기지 마세요.

문의를 보낼 때 함께 남길 정보

클라이언트와 커널 버전, 운영체제, 오류가 발생하는 범위, 네트워크 변경 결과, 오류 발생 시간, 민감 정보를 가린 로그 일부를 제공하세요. 구독 업데이트 가능 여부, 로컬 포트 수신 상태, 요청이 커널에 전달되었는지도 적어 주세요. 이 순서대로 기록하면 '노드가 전부 빨간색'이라는 설명보다 문제가 로컬 설정, DNS 경로, 노드 서비스 중 어디에 있는지 판단하기 쉽습니다.

점검 순서는 다음과 같이 정리할 수 있습니다: 구독을 업데이트하고 활성화했는지 → 시간과 네트워크가 정상인지 → 커널이 시작되고 포트를 사용할 수 있는지 → DNS 경로가 작동하는지 → 프로토콜 설정이 맞는지 → 실제 요청이 예상한 노드를 사용하는지. 반복해서 실패하는 단계가 확인되면 그 단계에서 멈추고 먼저 해결하세요.