Clash 노드 연결 시간 초과 및 접속 오류: 구독·DNS·포트·시스템 프록시 점검 순서

1. 노드 시간 초과, 구독 오류, 트래픽 미전달 구분하기

Timeout이 표시되어도 클라이언트를 바로 재설치하지 마세요.노드 지연 시간 테스트 실패는 정해진 시간 안에 테스트가 완료되지 않았다는 뜻일 뿐입니다. 구독 업데이트 실패, 브라우저에서 프록시 미사용, 원격 노드 접속 불가는 서로 다른 원인으로 발생합니다. 증상을 정확히 구분해야 다음 조치를 올바르게 선택할 수 있습니다.

다른 프록시나 VPN은 잠시 끄고, 사용 중인 클라이언트 이름과 버전, 커널 버전, 현재 설정 이름을 기록하세요. Clash는 프록시 커널과 설정 생태계를 통칭하는 이름으로 널리 쓰입니다. 현재 많은 클라이언트는 mihomo를 사용하며, mihomo는 기존 Clash.Meta의 개발을 이어가는 커널입니다. 커널마다 지원하는 프로토콜과 설정 항목이 다르므로 특정 클라이언트의 메뉴나 설정 기능을 모든 제품의 공통 기준으로 보면 안 됩니다.

2. 로컬 네트워크 연결, 시스템 시간 및 구독 상태 확인

네트워크 로그인 페이지와 시간 오차부터 점검

1. 클라이언트의 시스템 프록시와 TUN을 잠시 끈 다음, 원래 바로 접속할 수 있던 웹사이트를 테스트하세요. 학교나 호텔, 공공 Wi-Fi에서 웹 로그인 인증이 필요하면 먼저 인증을 완료합니다.
2. Windows 11에서는 「설정」→「시간 및 언어」→「날짜 및 시간」을 열고 「자동으로 시간 설정」을 확인한 뒤 「지금 동기화」를 클릭하세요. macOS에서는 「시스템 설정」→「일반」→「날짜 및 시간」에서 날짜와 시간이 자동으로 설정되어 있는지 확인합니다.
3. 현재 Wi-Fi 대신 휴대폰 핫스팟에 연결하고 설정과 노드는 그대로 둔 채 다시 테스트하세요. 네트워크를 바꾼 뒤에만 문제가 해결된다면 로컬 네트워크 경로나 네트워크 정책이 원인일 가능성이 높습니다.

시스템 시간이 크게 어긋나면 TLS 인증서 검증이 실패하거나 시간 기반 인증에 문제가 생길 수 있습니다. 로그에 certificate has expired 또는 certificate is not yet valid가 있으면 기기 시간과 인증서 유효 기간을 먼저 확인하세요. 인증서 검증을 건너뛰어 문제를 숨기지 마세요. connection refused는 보통 연결이 명시적으로 거부되었다는 뜻이며, 계속 응답을 기다리는 시간 초과와는 다릅니다.

구독 업데이트 성공 및 활성화 여부 확인

Clash Verge Rev의 일반적인 화면을 기준으로 설명합니다. 「구독」을 열어 현재 구독 카드를 찾은 다음 업데이트하세요. 해당 설정이 선택되어 있는지도 확인합니다. 버전에 따라 버튼 위치는 다를 수 있으므로 업데이트 결과와 시간, 노드 목록이 예상대로 바뀌었는지 확인하는 것이 중요합니다. 새 파일을 다운로드했다고 해서 설정이 성공적으로 적용된 것은 아닙니다. 설정 문법 오류가 있으면 클라이언트가 이전에 정상적으로 적용된 설정을 계속 사용할 수도 있습니다.

• 401 또는 403 응답:서비스 계정, 이용 기간, 구독 링크가 재설정되었는지 확인하세요. HTTP 상태 코드만으로 요금제가 만료되었다고 단정할 수는 없습니다.
• 200 응답이지만 가져오기 오류 발생:응답 내용이 정상적인 Clash YAML 설정이 아니라 로그인 페이지, 오류 안내 또는 호환되지 않는 형식인지 확인하세요.
• 노드는 표시되지만 모두 사용할 수 없음:이전 설정이 로컬에 남아 있을 수 있습니다. 계정이 만료되어도 노드 이름은 자동으로 사라지지 않을 수 있으므로 서비스 계정 페이지에서 잔여 트래픽과 만료일을 확인하세요.
• 프록시를 통해 구독 업데이트 실패:클라이언트에 구독 업데이트 프록시 옵션이 있다면, 연결할 수 없는 노드를 먼저 연결해야 업데이트할 수 있는 상황인지 확인하세요. 현재 네트워크 환경에 따라 프록시 없이 직접 업데이트해 보세요.

구독 주소에는 접근 토큰이 포함되는 경우가 많습니다. 전체 링크를 공개 포럼이나 스크린샷, 로그 파일에 붙여 넣지 마세요. 다시 가져와야 한다면 서비스 계정 페이지에서 현재 유효한 링크를 복사하고, 비교할 수 있도록 기존 설정을 먼저 보존하세요.

3. 로컬 포트 확인 및 커널의 실제 수신 여부 점검

앱은 실제로 수신 중인 포트에 연결해야 합니다.아래에서는 127.0.0.1:7890을 예시 주소로 사용합니다. 7890이 모든 클라이언트의 고정 기본 포트는 아닙니다. 클라이언트 설정이나 현재 적용 중인 설정에서 mixed-port, port, socks-port를 확인한 뒤 명령에 실제 포트를 입력하세요. external-controller는 관리 인터페이스이므로 웹 프록시 포트로 사용할 수 없습니다.

Windows: 수신 포트와 해당 프로세스 확인

PowerShell을 열고 다음 명령을 실행하세요. 첫 번째 명령은 로컬 TCP 연결을 확인하고, 두 번째 명령은 수신 프로세스의 ID를 표시합니다.

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

TcpTestSucceeded : True는 해당 포트에 연결할 수 있다는 뜻일 뿐입니다. 「작업 관리자」→「세부 정보」에서 PID로 해당 프로세스를 찾으세요. PID가 다른 프록시 프로그램을 가리킨다면 포트 충돌일 수 있습니다. 수신 중인 포트가 없다면 원격 노드를 바꾸기보다 커널 시작 오류나 설정 로드 오류부터 확인하세요.

macOS 및 Linux: 동일한 수신 포트 확인

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

# Linux
ss -lntp 'sport = :7890'

시스템 권한에 따라 프로세스 정보가 표시되지 않을 수 있습니다. 로그에 address already in use가 나타나면 포트를 점유한 이전 프로세스를 종료하거나, 7893처럼 사용 가능한 포트로 프록시 포트를 변경하세요. 변경 후에는 시스템 프록시, 브라우저 확장 프로그램, 터미널 프록시 환경 변수도 모두 함께 업데이트해야 합니다. YAML만 바꾸면 안 됩니다.

4. 프록시를 명시해 시스템 프록시와 노드 오류 구분

로컬 포트에 연결할 수 있다면 프록시를 명시한 요청을 한 번 실행하세요. 이 테스트는 앱이 시스템 프록시 설정을 읽는지 알 수 없는 문제를 우회하지만, 클라이언트의 현재 모드와 분기 규칙에는 영향을 받습니다. 특정 노드를 확인하려면 잠시 전역 모드로 전환해 해당 노드를 직접 선택하세요. 테스트가 끝나면 원래 규칙 모드로 되돌립니다.

# Windows PowerShell; 이전 환경의 동명 별칭을 피하려면 curl.exe 사용
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com

# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com

여기서 5초는 연결 시간 제한이고 15초는 전체 요청의 제한 시간이며, 실제 측정된 지연 시간은 아닙니다. 예시 명령은 해당 포트가 HTTP 프록시를 지원해야 합니다. SOCKS 포트만 제공되는 경우 해당 포트와 socks5h:// 프로토콜을 사용하세요. example.com은 고정 테스트 대상일 뿐입니다. 결과가 이상하면 직접 접속 가능한지 확인한 다른 HTTPS 사이트에서도 교차 테스트하세요.

• 127.0.0.1에 연결할 수 없다는 메시지:로컬 수신 상태를 다시 확인하세요. 이 단계에는 원격 노드가 아직 관여하지 않습니다.
• 200 Connection established만 표시됨:HTTP 프록시가 터널 연결 응답을 보냈다는 뜻일 뿐입니다. TLS 연결과 최종 웹사이트 응답까지 완료되었는지 확인하세요.
• 최종 HTTP 응답을 받음:이번 요청의 연결 경로가 적어도 한 번은 완료되었다는 뜻입니다. 403이나 405가 반환되더라도 웹사이트의 접근 정책과 연결 시간 초과는 구분해야 합니다.
• 프록시를 명시하면 성공하지만 브라우저에서는 실패:브라우저 확장 프로그램, 시스템 프록시 예외 목록, 앱 자체의 프록시 설정부터 확인하세요.

시스템 프록시 스위치와 운영체제 설정 일치 여부 확인

Windows 11에서는 「설정」→「네트워크 및 인터넷」→「프록시」에서 수동 프록시 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. macOS에서는 「시스템 설정」→「네트워크」→현재 네트워크 연결의 「세부사항」→「프록시」에서 웹 프록시와 보안 웹 프록시를 확인합니다. 출처를 알 수 없는 자동 프록시 스크립트와 수동 프록시 설정을 동시에 사용하지 마세요.

클라이언트에서 「연결」과 「로그」 페이지를 함께 열고 웹페이지를 새로고침하세요. 관련 연결이 전혀 없다면 트래픽이 커널로 전달되지 않았거나 브라우저가 기존 연결을 재사용했을 수 있습니다. 해당 웹페이지를 닫았다가 다시 열어 확인하세요. 연결 기록이 있고 대상이 DIRECT라면 프록시 노드 장애로 오해하지 말고 적용된 규칙을 확인하세요.

5. DNS 이름 해석 실패와 fake-ip 경로 문제 구분

DNS는 두 단계로 나눠 확인해야 합니다. 첫째는 노드 서버 도메인이 해석되는지, 둘째는 웹사이트 도메인이 어떻게 해석되는지입니다. 노드 주소 자체를 해석할 수 없다면 웹사이트를 바꿔 테스트해도 의미가 없습니다. 웹사이트 도메인 해석에 문제가 있다고 모든 노드가 고장 났다고 단정할 수도 없습니다.

로그에서 도메인과 오류 발생 단계를 먼저 확인

클라이언트 로그를 열고 연결 오류를 확인할 수 있는 수준으로 로그 단계를 잠시 높인 뒤, 실패한 작업을 다시 실행하세요. 오류에 표시된 도메인과 포트, 시간을 기록합니다. no such host는 보통 도메인 이름 해석 실패를 가리킵니다. i/o timeout은 앞뒤 로그를 함께 보고 DNS 조회, 원격 연결, 프로토콜 핸드셰이크 중 어느 단계에서 발생했는지 판단해야 합니다. 마지막 Timeout 한 줄만으로는 정보가 부족한 경우가 많습니다.

# Windows: 시스템 이름 해석 경로 확인
Resolve-DnsName example.com

# macOS / Linux: nslookup을 사용할 수 있는 경우
nslookup example.com

이 명령은 주로 시스템이 사용하는 이름 해석 경로를 확인하며, mihomo 내장 DNS 결과와 반드시 같지는 않습니다. 시스템에서는 이름 해석에 성공하지만 커널에서 계속 실패한다면 브라우저 캐시를 반복해서 지우지 말고, 현재 적용 중인 설정의 dns 섹션과 DNS 서버 연결 상태, 노드 도메인 해석 설정을 추가로 확인하세요.

fake-ip 주소는 노드 서버 주소가 아닙니다

fake-ip 모드에서는 커널이 설정된 주소 풀에서 합성 주소를 할당할 수 있습니다. 흔히 사용되는 주소 풀의 예는 198.18.0.1/16입니다. 앱에 이런 주소가 전달되더라도 DNS가 오염되었다는 뜻은 아닙니다. 커널은 매핑 정보를 통해 도메인을 복원한 뒤 규칙에 따라 연결을 처리합니다. 실제로 해당 범위를 사용하는지는 현재 설정을 확인해야 합니다.

• TUN을 끈 뒤에도 앱이 합성 주소에 접속함:이전 DNS 캐시가 남아 있을 수 있습니다. 관련 앱을 종료하고 원래 DNS 경로를 복구한 다음 앱을 다시 실행하세요. Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비울 수 있습니다.
• 특정 LAN 앱에서만 문제가 발생함:실제 IP 주소나 LAN 기기 검색, 자체 DNS 기능이 필요한 앱인지 확인하세요. 모든 도메인을 예외로 등록하는 것보다 해당 도메인만 fake-ip 예외로 설정하는 편이 관리하기 쉽습니다.
• 암호화 DNS로 바꾼 뒤 시간 초과 발생:DNS 서버에 연결할 수 있는지, 해당 도메인을 확인할 때 별도의 초기 DNS 조회가 필요한지 확인하세요. 암호화 DNS라고 해서 모든 네트워크에서 접속 가능한 것은 아닙니다.

비교 테스트가 필요하면 백업 설정에서 클라이언트와 커널이 지원하는 다른 DNS 모드로 잠시 전환한 뒤 설정을 불러오고 테스트 앱을 다시 시작하세요. 한 번에 한 항목만 변경합니다. 원격 구독을 업데이트하면 직접 편집한 내용이 덮어써질 수 있습니다. 장기적인 수정은 클라이언트에서 제공하는 덮어쓰기 또는 병합 기능을 사용하세요. 각 설정 항목은 설정 참고 자료에서 확인할 수 있습니다.

6. TUN, 다른 VPN 및 네트워크 트래픽 처리 충돌 확인

시스템 프록시는 정상인데 TUN에 문제가 있다면 트래픽 처리 경로부터 확인하세요.TUN은 가상 네트워크 인터페이스와 라우팅을 통해 트래픽을 처리하므로 시스템 프록시와 적용 범위가 다릅니다. TUN을 켜도 만료된 구독이나 원격 서버 중단은 해결되지 않습니다. 테스트 전 다른 VPN, 네트워크 가속기, 유사한 가상 네트워크 어댑터 프로그램을 잠시 중지해 여러 프로그램이 기본 경로나 DNS를 동시에 변경하지 않도록 하세요.

1. 먼저 TUN을 끄고 시스템 프록시는 유지한 상태로 이전 절의 명시적 프록시 요청을 실행하세요. 성공하면 로컬 프록시 진입점과 선택한 노드가 적어도 이 요청은 처리할 수 있다는 뜻입니다.
2. 시스템 프록시를 끈 다음 TUN을 켜고 일반 브라우저에서 같은 테스트 웹사이트에 접속하면서 연결 기록을 확인하세요.
3. 두 번째 단계에서 실패하면 클라이언트에 서비스 미설치, 권한 부족, 가상 인터페이스 생성 실패 안내가 표시되는지 확인하세요. 데스크톱 클라이언트는 해당 시스템 서비스를 먼저 설치하거나 시작해야 할 수 있습니다.
4. 원래 스위치 상태로 되돌리고 클라이언트를 종료한 뒤에도 네트워크가 정상적으로 복구되는지 확인한 다음 TUN을 계속 사용할지 결정하세요.

Android에서는 일반적으로 동일한 사용자 환경에서 하나의 앱만 시스템 VPN 서비스를 사용할 수 있습니다. 다른 VPN을 시작하면 기존 연결이 대체될 수 있습니다. iOS 네트워크 확장도 운영체제와 클라이언트 구현의 제약을 받습니다. 모바일에서는 데스크톱의 7890 포트 확인 절차를 그대로 따르기보다 시스템 VPN 상태와 클라이언트 로그부터 확인하세요.

TUN 사용 중 일부 대형 웹페이지, 업로드 또는 동영상만 멈추고 작은 요청은 정상일 때에만 경로 MTU, UDP 지원 또는 특정 프로토콜 문제를 추가로 확인하세요. 출처가 불분명한 MTU 값을 그대로 복사하지 마세요. 재현 가능한 대상과 전송 유형, 네트워크 환경을 기록한 다음 설정을 하나씩 바꿔 비교 테스트하세요.

7. 원격 노드와 지연 시간 테스트 대상 확인

로컬 수신 상태와 트래픽 처리, DNS에 문제가 없다는 근거를 확보한 뒤 노드에 접속할 수 없는지 판단하세요. 같은 기기와 네트워크, 테스트 대상 웹사이트를 유지하고 노드만 바꿉니다. 한 노드는 계속 실패하고 다른 노드는 계속 성공한다면 실패한 노드 자체나 해당 노드까지의 네트워크 경로에 문제가 집중되어 있을 가능성이 높습니다.

지연 시간 테스트만으로 전체 사용 가능 여부를 확인할 수는 없습니다

클라이언트의 지연 시간 테스트는 보통 노드를 통해 지정된 URL에 요청을 보냅니다. 테스트 URL과 시간 제한, 서버의 응답 정책이 모두 결과에 영향을 줍니다. 클라이언트에서 시간 제한을 설정할 수 있다면 예를 들어 3000밀리초에서 8000밀리초로 잠시 늘려 비교할 수 있습니다. 이는 대기 시간을 늘리는 것일 뿐 속도를 높이는 방법은 아닙니다. 간단한 테스트가 성공해도 동영상, UDP 또는 장시간 연결이 정상이라는 보장은 없습니다.

원격 TCP 포트에 연결할 수 있다는 것은 TCP 핸드셰이크에 도달했다는 뜻일 뿐 인증, TLS 또는 프록시 프로토콜 핸드셰이크 성공을 보장하지 않습니다. 일부 노드는 UDP 기반 전송을 사용하므로 TCP 포트 테스트가 적절하지 않을 수도 있습니다. ping 응답 여부로 노드 상태를 판단하지 마세요. 서버가 ICMP에는 응답하지 않더라도 프록시 서비스는 정상 작동할 수 있습니다.

• 노드 하나만 실패:구독을 업데이트하고 서비스 제공자가 해당 노드를 교체했는지 확인한 다음 점검 안내가 있는지 살펴보세요.
• 같은 네트워크에서는 모두 실패하지만 핫스팟에서는 정상:현재 네트워크의 외부 연결 제한과 DNS, 원격 노드까지의 경로를 중점적으로 확인하세요.
• 두 네트워크에서 모두 실패하고 로그에 프로토콜 미지원이 표시됨:설정 요구 사항과 커널 지원 여부를 확인하고 클라이언트 공식 배포 버전 중 호환되는 버전으로 업데이트하세요. 프로토콜 이름을 임의로 바꾸지 마세요.
• 로그에 인증 또는 TLS 오류가 표시됨:계정과 노드 매개변수, 시스템 시간을 확인하세요. 모든 핸드셰이크 실패를 네트워크 시간 초과로 뭉뚱그리지 마세요.

8. 문제 정보 정리 및 일반 설정 복구

문제가 해결되지 않았다면 아래 정보를 정리해서 문의하세요. “모든 노드가 시간 초과됩니다”라고만 알리는 것보다 정확한 답변을 받기 쉽습니다. 로그는 문제가 발생한 시점 전후 약 30~60초의 관련 부분만 남기고 구독 토큰과 비밀번호, UUID, 기타 인증 정보는 먼저 삭제하세요.

• 클라이언트 이름과 버전, 커널 버전, 운영체제 버전
• 문제 발생 시간과 시간대, Wi-Fi·유선 네트워크·휴대폰 핫스팟 중 사용한 연결 방식
• 구독 업데이트 실패, 노드 테스트 실패, 특정 앱 접속 실패 중 어떤 문제인지
• 실제 로컬 프록시 포트, 올바른 프로세스의 수신 여부, 명시적 프록시 요청 결과
• 시스템 프록시와 TUN의 활성화 상태, 규칙 모드 또는 전역 모드, 적용된 정책 그룹
• 노드와 네트워크, 테스트 대상을 바꾼 뒤의 결과. 매번 한 항목만 변경

테스트가 끝나면 평소 사용하는 규칙 모드와 원래 DNS, 필요한 프록시 스위치를 복구하고 임시 디버그 로그를 끄세요. 최종 판단은 재현 가능한 근거를 바탕으로 해야 합니다. 포트가 수신 중인지, 요청이 커널로 전달되는지, 도메인이 해석되는지, 원격 핸드셰이크가 완료되는지 순서대로 확인하세요. 이 순서대로 점검하면 “Clash에 연결할 수 없음” 문제를 조치 가능한 단계로 좁힐 수 있습니다. 처음 설정하는 경우 빠른 시작 가이드에서 기본 설정을 확인하고, 일반적인 클라이언트 문제는 도움말 센터에서 살펴보세요.