속도 테스트 실패와 실제 연결 실패를 구분하세요
Clash 클라이언트에서 표시되는 ‘시간 초과’는 지정된 테스트 주소로 보낸 요청이 제한 시간 안에 완료되지 않았다는 뜻입니다. 노드 서버가 반드시 오프라인이라는 뜻도, 이 결과만으로 구독이 만료됐다고 단정할 수도 없습니다. 테스트 주소, DNS, 노드 핸드셰이크, 대상 사이트 응답 중 어느 단계에서든 지연되면 속도 테스트가 시간 초과로 끝날 수 있습니다.
이 글에서는 ‘로컬 네트워크 → 시스템 시간 → 코어 및 포트 → 트래픽 경로 → DNS → 프로토콜 설정 → 서버’ 순서로 점검합니다. 기본 Clash 설정 방식과 Clash Meta(현재 mihomo) 코어를 사용하는 클라이언트에 적용할 수 있으며, 각 필드의 지원 여부는 현재 실행 중인 코어를 기준으로 확인하세요.
| 증상 | 우선 점검 항목 | 다음 단계에서 확인할 사항 |
|---|---|---|
| 속도 테스트는 시간 초과지만 웹페이지는 열림 | 테스트 주소 및 제한 시간 | 웹 요청이 직결이 아닌 해당 노드를 거치는지 확인 |
| 모든 노드 연결 실패 | 로컬 네트워크, 코어, DNS | 같은 시간대의 첫 번째 오류 확인 |
| 특정 노드 하나만 연결 실패 | 노드 설정 및 서버 상태 | 같은 구독의 정상 노드와 비교 |
| 속도 테스트는 정상인데 앱은 작동하지 않음 | 시스템 프록시, 규칙, TUN | 연결 페이지에서 실제 출구 노드 확인 |
| 웹은 정상인데 게임이나 통화는 실패 | UDP 지원 및 트래픽 처리 여부 | TCP 테스트와 실제 UDP 트래픽 구분 |
1단계: 로컬 네트워크와 시스템 시간 확인
먼저 프록시 없이 연결되는지 확인
- 현재 설정을 기록한 다음 클라이언트의 시스템 프록시와 TUN을 끄세요. 모바일에서는 앱 화면을 닫은 뒤에도 터널이 계속 실행 중이지 않도록 해당 VPN 연결이 끊겼는지 확인해야 합니다.
- 평소 프록시 없이 접속할 수 있는 웹사이트를 엽니다. 호텔, 학교 또는 공공 Wi-Fi에 인증 페이지가 표시되면 먼저 로그인하세요. Wi-Fi 아이콘이 보인다고 인터넷 연결까지 확인된 것은 아닙니다.
- 휴대폰 핫스팟에서도 같은 테스트를 반복하세요. 기기, 설정, 노드는 그대로 두고 연결 네트워크만 바꿉니다.
프록시를 꺼도 인터넷에 직접 연결되지 않는다면 먼저 로컬 네트워크 문제를 해결하세요. 집 인터넷에서는 실패하지만 핫스팟에서는 정상이라면 접속 네트워크의 DNS, 라우팅 또는 UDP 정책 문제일 가능성이 높습니다. 다만 로그로 확인해야 하며 서버에서 차단했다고 바로 단정해서는 안 됩니다. 운영체제의 네트워크 진단은 특정 테스트 주소에 의존할 수 있으므로 ‘인터넷에 연결되지 않음’이라는 표시만으로 판단하지 마세요.
인증서 오류를 확인하기 전에 시스템 시간부터 맞추세요
TLS 인증서 검증에는 시스템 시간이 필요합니다. Windows 11에서는 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 자동 시간 설정을 켜고 동기화하세요. macOS에서는 ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’으로 이동합니다. 시간대뿐 아니라 실제 날짜, 연도, 분 단위 시간도 확인하세요.
로그에 certificate has expired or is not yet valid가 표시되면 먼저 기기의 시간과 서버 인증서의 유효 기간을 확인하세요. 인증서 검증을 끄는 것은 일반적인 해결책이 아닙니다. 서버 신원 확인이 약해질 뿐 아니라 비밀번호 오류, 포트 연결 실패, 프로토콜 불일치도 해결하지 못합니다.
2단계: 코어 실행 여부와 로컬 포트 확인
그래픽 인터페이스가 실행된다고 해서 프록시 코어가 설정을 정상적으로 불러온 것은 아닙니다. 클라이언트 로그에서 설정 파싱 오류, 코어의 반복 종료, address already in use 메시지를 먼저 찾으세요. 설정을 불러오지 못해도 노드 목록에는 캐시된 항목이 표시될 수 있지만, 실제로는 로컬 프록시 포트가 열려 있지 않을 수 있습니다.
프록시 포트와 컨트롤 포트 구분
port: HTTP 프록시 포트입니다.socks-port: SOCKS 프록시 포트입니다.mixed-port: HTTP와 SOCKS 프록시 요청을 모두 받는 포트입니다.external-controller: 컨트롤 API가 수신 대기하는 주소입니다. 브라우저의 프록시 설정에 입력하면 안 됩니다.
현재 적용된 설정에서 mixed-port: 7890을 사용한다면 아래 명령으로 포트를 수신 중인 프로세스를 확인할 수 있습니다. Windows에서는 PowerShell, macOS에서는 터미널을 사용하세요. 결과가 없다면 노드를 계속 바꾸기보다 코어 로그부터 확인해야 합니다.
# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
# macOS
lsof -nP -iTCP:7890 -sTCP:LISTENWindows에서는 Get-Process -Id 프로세스번호를 실행해 해당 프로그램을 확인할 수 있습니다. ‘프로세스번호’를 앞 단계에서 확인한 실제 숫자로 바꾸세요. 이전 클라이언트가 포트를 점유 중이라면 종료하거나 포트를 변경한 뒤 시스템 프록시 설정도 함께 수정합니다. 출처를 알 수 없는 시스템 프로세스를 종료하거나 TUN을 두 개 동시에 실행하지 마세요.
3단계: 요청이 어떤 규칙과 노드를 거치는지 확인
시스템 프록시는 해당 설정을 따르는 앱에만 적용됩니다. 일부 명령줄 프로그램, 게임, 자체 네트워크 스택을 사용하는 앱은 이를 무시할 수 있습니다. TUN은 가상 네트워크 인터페이스를 통해 설정된 경로의 트래픽을 처리하며, 라우팅, 권한, 제외 항목에 따라 동작이 달라집니다. 두 기능은 같은 설정이 아니며, 시스템 프록시가 켜져 있다는 사실만으로 모든 트래픽이 코어에 전달된다고 볼 수 없습니다.
프록시를 명시한 요청으로 비교 테스트
먼저 클라이언트에서 테스트할 노드를 선택하고 관련 정책 그룹이 실제로 해당 노드를 가리키는지 확인한 다음, HTTP 프록시를 명시해 요청을 보내세요. 아래 명령은 로컬 7890 포트에 연결하며 연결 제한 시간은 10초, 전체 제한 시간은 15초입니다. Windows에서는 curl.exe, macOS와 Linux에서는 curl을 사용하세요.
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 15 -I https://example.com/테스트 주소는 동일한 요청을 재현하기 위한 것이며 노드 상태를 판단하는 유일한 기준은 아닙니다. HTTP 상태 코드가 반환되면 해당 요청이 최소한 그 단계까지 진행된 것입니다. 403은 대상 사이트가 접근을 거부했을 수 있다는 뜻이지, 프록시 연결 실패를 의미하지는 않습니다. 127.0.0.1:7890에 연결할 수 없다는 메시지가 나오면 먼저 로컬 포트가 열려 있는지 확인하세요. 프록시 터널이 연결된 뒤 실패한다면 핸드셰이크, DNS, 원격 서버 응답을 점검합니다.
- 클라이언트의 연결 페이지를 열고 방금 요청한 도메인을 찾으세요.
- 적용된 규칙, 정책 그룹, 최종 노드를 확인해 요청이
DIRECT로 직결된 것은 아닌지 살펴보세요. - 연결 페이지에 요청이 전혀 보이지 않는다면 먼저 진입 경로와 포트를 확인하세요. 연결 기록은 빠르게 사라질 수 있으므로 로그도 함께 살펴보세요.
- 필요하면 잠시 전역 모드로 전환해 테스트 노드를 직접 선택하고 비교한 뒤 규칙 모드로 되돌리세요.
프록시를 명시한 요청은 성공하는데 특정 앱만 실패한다면 구독을 반복해서 업데이트하지 말고 앱의 프록시 설정과 TUN 라우팅을 확인하세요. TUN을 켠 뒤에만 실패한다면 TUN을 끄고 프록시 지정 요청은 유지한 채, 관리자 권한, 다른 VPN, 가상 네트워크 어댑터, 라우팅 충돌을 하나씩 점검할 수 있습니다.
4단계: DNS 오류를 두 가지 조회 경로로 나눠 확인
프록시 연결에는 노드 서버의 도메인과 사용자가 접속하려는 대상 도메인, 최소 두 종류의 도메인이 관여할 수 있습니다. 전자에서 조회에 실패하면 터널을 만들 수 없고, 후자에서 실패하면 노드 핸드셰이크는 성공해도 일부 웹사이트가 열리지 않을 수 있습니다. 두 도메인의 조회 경로가 같다고 볼 수는 없습니다.
노드 도메인: 터널 연결에 필요한 조건부터 확인
로그에서 조회에 실패한 도메인이 노드의 server 값과 같은지 확인하세요. mihomo의 proxy-server-nameserver로 노드 도메인을 조회할 DNS 서버를 지정할 수 있습니다. default-nameserver는 DNS 서버 자체의 도메인을 조회할 때 필요한 초기 조회와 관련됩니다. 아직 연결되지 않은 프록시 경로에 노드 도메인 조회를 전적으로 의존하면 순환 참조가 발생할 수 있습니다.
Windows의 Resolve-DnsName과 macOS의 dig로 시스템의 DNS 조회 결과를 확인할 수 있습니다. 다만 이는 해당 도구가 사용한 조회 경로의 결과일 뿐, mihomo 내장 DNS도 같은 결과를 반환한다는 뜻은 아닙니다. 유효 설정의 DNS 필드와 코어 로그도 함께 확인하세요.
대상 도메인: Fake-IP, DNS 가로채기, 앱 캐시 확인
fake-ip모드에서는198.18.0.0/16범위의 가상 주소가 반환될 수 있습니다. 이 주소는 웹사이트의 실제 서버 주소가 아닙니다.- Fake-IP 주소는 해당 코어가 트래픽을 처리해 도메인으로 다시 연결해야 합니다. 클라이언트를 바꾼 뒤 남은 시스템 또는 앱의 DNS 캐시 때문에 요청이 잘못된 경로로 전달될 수 있습니다.
- TUN의 DNS 가로채기는 설정에 맞는 DNS 요청을 처리할 수 있지만, 앱에 내장된 DoH가 일반적인 53번 포트를 거친다고 보장할 수는 없습니다.
nameserver-policy,nameserver,fallback을 실제 설정과 함께 확인하세요. DNS 서버를 더 추가한다고 조회가 반드시 빨라지거나 안정적으로 바뀌는 것은 아닙니다.
DNS 모드를 변경한 뒤에는 설정을 다시 불러오고 영향을 받는 앱을 재시작하세요. Windows에서는 필요에 따라 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비울 수 있지만, 브라우저 내부 캐시까지 모두 지워지지는 않습니다. IPv6를 끈 뒤에만 문제가 해결됐다면 AAAA 조회, IPv6 출구 또는 라우팅을 추가로 확인해야 합니다. 모든 IPv6 환경에서 IPv6를 꺼야 한다는 뜻은 아닙니다.
5단계: 프로토콜 설정과 코어 지원 여부 확인
로컬 포트가 정상이고 요청이 실제로 대상 노드에 전달되며 노드 도메인도 조회된다면 프로토콜 설정을 항목별로 확인하세요. YAML 파서가 설정을 읽었다는 사실은 문법이 유효하다는 뜻일 뿐입니다. 현재 코어가 해당 필드를 지원하지 않거나, 인증 정보가 만료됐거나, 서버 수신 방식이 변경된 경우에도 연결에 실패할 수 있습니다.
| 설정 항목 | 세부 확인 사항 | 흔히 하는 오판 |
|---|---|---|
| 서버 주소 | server、port | 구독을 업데이트한 뒤에도 이전 포트를 사용 |
| 인증 및 암호화 | UUID, 비밀번호, 암호화 방식 | 복사할 때 공백이 들어갔거나 이전 인증 정보를 사용 |
| TLS | SNI, 인증서, ALPN | 노드 표시 이름을 SNI로 착각 |
| 전송 계층 | WebSocket 경로, Host, gRPC 서비스 이름 | 서버 주소와 비밀번호만 복사하고 전송 설정을 빠뜨림 |
| Reality | 공개 키, short-id, 서버 이름 | 다른 노드의 설정을 섞어 사용 |
| UDP 프로토콜 | 코어 지원 여부, 네트워크 허용 여부, 서버 수신 상태 | TCP 포트 테스트만으로 UDP도 정상이라고 판단 |
예를 들어 Hysteria2, TUIC처럼 UDP 기반 연결은 UDP가 제한된 네트워크에서 실패할 수 있지만 같은 네트워크의 TCP 노드는 정상일 수 있습니다. TCP 포트 연결 테스트로 이런 프로토콜의 전체 핸드셰이크를 확인할 수는 없습니다. 반대로 일반 HTTP 지연 테스트가 성공해도 게임이나 음성 통화에 필요한 UDP 전달까지 지원한다는 뜻은 아닙니다.
클라이언트 버전과 실제 코어 버전을 기록하세요. 두 버전 번호는 서로 다릅니다. 기본 Clash와 mihomo는 프로토콜 지원 범위가 다르고, 오래된 코어는 새 필드를 인식하지 못할 수 있습니다. unsupported proxy type 또는 필드 파싱 오류가 발생하면 제한 시간을 늘리지 말고 설정 형식과 코어의 지원 여부를 확인하세요.
6단계: 노드, 테스트 주소, 서버 상태 판단
변수를 최소화해 교차 테스트
- 같은 기기·같은 네트워크에서 노드만 변경: 노드 하나만 실패한다면 해당 노드의 설정, 사용 한도, 서버 점검 상태를 먼저 확인하세요.
- 같은 기기·같은 노드에서 네트워크만 변경: 핫스팟에서는 정상인데 유선 인터넷에서 실패한다면 접속 네트워크 경로와 프로토콜 제한을 추가로 점검하세요.
- 같은 네트워크·같은 노드에서 기기만 변경: 다른 기기에서는 정상이라면 문제가 발생한 기기의 오버라이드, 코어, 프록시 진입 경로, 캐시를 확인하세요.
- 같은 노드에서 대상 사이트만 변경: 테스트 주소 하나에서만 실패한다면 대상 사이트의 정책과 테스트 URL을 확인하세요. 한 사이트의 문제를 노드 전체의 오프라인 상태로 확대 해석하지 마세요.
속도 테스트 제한 시간을 진단 변수로 활용할 수 있습니다. 예를 들어 5초에서 10초로 잠시 늘려 연결에 시간이 더 걸리는 문제인지 확인하세요. 이 방법은 인증 오류, 만료된 인증서, 차단된 포트를 해결하지 못합니다. 제한 시간을 늘려야 가끔 성공한다면 패킷 손실, 혼잡, 핸드셰이크 로그를 계속 확인해야 합니다.
구독 업데이트 성공은 설정을 가져왔다는 뜻일 뿐 모든 노드가 온라인이라는 뜻은 아닙니다. 서비스 제공자의 계정 상태, 트래픽 한도, 점검 공지를 확인하세요. 업데이트한 뒤에는 현재 활성화된 설정, 노드 매개변수, 업데이트 시간이 실제로 바뀌었는지도 확인해야 합니다. 오류를 확인하려고 짧은 간격으로 계속 속도 테스트를 하지 마세요. 시간을 기록해 요청을 몇 차례 반복하는 편이 원인을 찾기 쉽습니다.
마무리 로그 점검: 오류 단계는 남기고 접속 정보는 가리기
로그 수준을 일시적으로 debug로 변경한 뒤 오류를 한 번 재현하고 시간을 기록하세요. 확인 후에는 평소 로그 수준으로 되돌립니다. 디버그 로그에는 접속 도메인과 연결 정보가 포함될 수 있으므로 외부에 공유할 때는 관련 시간대의 내용만 추려내세요.
connection refused: 보통 연결이 명시적으로 거부됐다는 뜻입니다. 오류가 로컬 프록시 포트를 가리키는지 원격 노드 포트를 가리키는지 먼저 확인하세요.i/o timeout,context deadline exceeded: 특정 단계가 제한 시간을 넘겼다는 뜻입니다. 앞뒤 로그를 확인해 DNS 조회, 연결 시도, 요청 중 어느 단계에서 발생했는지 파악하세요.no such host: 먼저 조회에 실패한 도메인과 해당 도메인이 어떤 DNS 경로를 사용했는지 확인하세요.authentication failed: 인증 정보와 계정 상태를 우선 확인하세요. 클라이언트를 다시 설치해도 서버의 인증 결과는 바뀌지 않습니다.EOF, 연결 재설정: 연결이 예기치 않게 종료됐다는 뜻입니다. 이 한 줄만으로 원인을 단정할 수 없으므로 핸드셰이크 단계와 서버 기록을 함께 확인해야 합니다.
점검이 끝나면 규칙 모드, 로그 수준, 임시 변경 사항을 원래대로 되돌리고 재현 가능한 기록을 보관하세요. 이후 ‘속도 테스트 시간 초과’가 다시 발생해도 재설치부터 시작하지 않고 이미 확인한 네트워크, 포트, DNS 상태를 바탕으로 점검할 수 있습니다. 프록시 연결과 설정 가져오기는 빠른 시작 가이드를, 자주 묻는 설정 질문은 도움말 센터를 참고하세요.