1. 속도 측정 실패와 실제 연결 실패 구분하기
Clash 클라이언트의 지연 시간 테스트는 보통 코어가 지정된 노드를 통해 테스트 URL에 요청을 보내고, 걸린 시간을 측정해 결과를 표시합니다. 단순한 ICMP ping도, 다운로드 속도 측정도 아닙니다. 목록에 모두 timeout이 표시되더라도 제한 시간 안에 테스트가 끝나지 않았다는 뜻일 뿐, 모든 서버가 동시에 오프라인이라고 단정할 수는 없습니다.
테스트 주소에 연결할 수 없거나, 노드 도메인 이름을 확인하지 못하거나, TLS 핸드셰이크가 실패하거나, 인증 정보가 잘못된 경우에도 화면에는 비슷한 결과가 나타날 수 있습니다. 먼저 현재 설정을 보존한 다음 노드 하나를 선택하고, 해당 시간대의 코어 로그를 확인한 뒤 같은 노드로 실제 웹페이지에 접속해 보세요.
- 현재 구독 이름, 선택한 노드, 테스트 시간, 클라이언트에 표시된 코어 이름과 버전을 기록하세요.
- 자동 전환을 잠시 중지하고 직접 선택할 수 있는 정책 그룹에서 노드 하나를 고정하세요. 브라우저 요청이 실제로 해당 노드를 통과하는지도 확인합니다.
- 속도 측정과 웹페이지 접속을 각각 한 번만 실행한 뒤, 연결 기록에서 규칙, 정책 그룹, 아웃바운드 경로를 확인하세요.
- 웹페이지는 정상적으로 열리는데 속도 측정만 실패한다면 테스트 URL, 테스트 시간 제한, 서버 측 테스트 요청 제한 여부부터 확인하세요. 클라이언트를 먼저 재설치할 필요는 없습니다.
2. 구독 유효 기간·트래픽·현재 설정 확인하기
구독을 업데이트할 수 있다고 해서 계정에 사용할 트래픽이 남아 있다는 뜻은 아닙니다. 반대로 구독 업데이트에 실패해도 로컬에 캐시된 노드가 모두 무효가 된 것은 아닙니다. 구독 다운로드와 노드 연결은 서로 다른 경로이므로 각각 확인해야 합니다.
서버 측과 로컬 상태를 순서대로 확인하세요
- 계정 상태: 서비스 제공업체의 계정 페이지에서 요금제 만료일, 남은 트래픽, 기기 또는 동시 접속 제한, 점검 공지를 확인하세요. 클라이언트에 표시된 구독 사용량은 마지막 업데이트 당시의 캐시일 수 있습니다.
- 업데이트 결과: 구독 업데이트 로그와 마지막 성공 시간을 확인하세요. HTTP
401또는403은 인증 또는 접근이 제한되었음을 나타냅니다. 구체적인 원인은 서비스 제공업체의 안내를 함께 확인해야 하며, 상태 코드만으로 요금제 만료를 단정할 수는 없습니다. - 응답 내용: HTTP
200이어도 로그인 페이지나 오류 문구가 반환될 수 있습니다. 설정이 정상적으로 파싱되고 노드 수가 적절하며 설정이 실제로 활성화되어야 해당 내용이 코어 로딩 과정에 반영되었다고 볼 수 있습니다. - 설정 출처: 현재 사용 중인 설정이 오래된 로컬 사본이 아닌지 확인하세요.
proxy-providers를 사용하는 경우 해당 제공자가 정상적으로 업데이트되었는지도 확인해야 합니다. 기본 설정 파일의 수정 시간만 확인해서는 충분하지 않습니다.
서비스 제공업체가 서버 주소, 포트 또는 인증 정보를 변경했는데 클라이언트가 이전 캐시를 계속 사용하면 오래된 노드가 한꺼번에 실패할 수 있습니다. 먼저 구독을 정상적으로 업데이트한 뒤 현재 적용된 설정의 노드 정보를 확인하세요. 구독 목록에 ‘업데이트 완료’라고 표시되는 것만 보고 점검을 끝내면 안 됩니다.
3. 시스템 시간을 맞춘 뒤 TLS 및 인증 오류 확인하기
시스템 날짜가 잘못되면 인증서 유효 기간을 판단하는 데 영향을 줍니다. 로그의 certificate has expired or is not yet valid 오류는 서버 인증서 문제일 수도 있고, 기기 시계가 틀린 탓일 수도 있습니다. 시간 검증이 필요한 일부 인증 절차도 정확한 시각에 의존합니다. 먼저 시간을 동기화하면 기기 문제를 노드 프로토콜 오류로 오인하는 일을 줄일 수 있습니다.
| 플랫폼 | 확인 방법 | 중점 확인 사항 |
|---|---|---|
| Windows 11 | ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’ → ‘지금 동기화’ | 자동 시간 설정을 켜고 동기화가 성공했는지 확인 |
| macOS | ‘시스템 설정’ → ‘일반’ → ‘날짜 및 시간’ | 날짜 및 시간 자동 설정을 켜고 시간 서버 확인 |
| systemd를 사용하는 Linux | timedatectl status |
시스템 시계 동기화 상태와 NTP 서비스 상태 확인 |
Windows에서는 아래의 읽기 전용 명령을 실행해 시간 서비스 상태와 동기화 출처를 확인할 수도 있습니다. 서비스가 실행 중이 아니면 명령에서 오류가 날 수 있습니다. 이때는 오류를 노드 문제로 간주하지 말고 시스템 설정에서 처리하세요.
w32tm /query /status시간대는 현지 시간 표시 방식에 영향을 주지만, TLS 검증은 실제 시각을 기준으로 합니다. 시간대를 다른 지역으로 바꾸는 것만으로 잘못된 시스템 시계를 바로잡을 수는 없습니다. 시간을 동기화한 뒤 다시 연결해 보세요. 그래도 인증서 오류가 발생한다면 서버 인증서, 노드의 SNI, 네트워크에서 인증서를 가로채는지 확인하세요.
문제를 숨기려고 skip-cert-verify를 true로 설정하는 것은 권장하지 않습니다. 인증서 검증을 끄면 서버 신원 확인이 불가능해지고, 만료된 계정이나 잘못된 비밀번호, 전송 프로토콜 비호환 문제도 해결되지 않습니다.
4. 클라이언트 이름이 아닌 실제 코어 확인하기
클라이언트는 인터페이스와 설정, 시스템 프록시를 관리하고 실제 연결은 코어가 담당합니다. 기본 Clash와 Clash Meta(현 mihomo)는 지원하는 프로토콜 범위가 다릅니다. 같은 클라이언트에서도 코어를 바꾸거나 업데이트할 수 있으므로, 설정을 가져올 수 있다고 해서 현재 실행 중인 코어가 모든 프로토콜을 처리할 수 있는 것은 아닙니다.
로딩 로그에서 세 가지 정보 확인하기
- 코어 정보: 클라이언트의 코어 정보 화면이나 시작 로그에서 이름과 버전을 확인하고, 설치 패키지 버전이 아닌 현재 실제로 실행 중인 코어를 기록하세요.
- 노드 유형: 설정의
type을 확인하세요. 예를 들어 Hysteria2, TUIC, VLESS 및 REALITY 관련 설정은 해당 기능을 지원하는 코어와 버전이 필요합니다. 구버전 기본 Clash와의 호환성을 전제로 삼지 마세요. - 전체 매개변수: 서버 주소, 포트, 비밀번호 또는 UUID, 전송 방식, TLS, SNI와 프로토콜 전용 필드를 확인하세요. 프로토콜 이름이 같아도 모든 확장 옵션을 서로 바꿔 쓸 수 있는 것은 아닙니다.
unsupported proxy type, 알 수 없는 암호화 방식, 설정 파싱 오류가 나타나면 먼저 호환성과 설정 문제를 해결하세요. 이런 오류는 노드가 실제 네트워크 연결을 시작하기 전에 발생하는 경우가 많아 속도 측정 시간 제한을 늘려도 도움이 되지 않습니다. 로그 문구는 코어 버전에 따라 달라질 수 있으므로 특정 오류 문장만 검색하기보다 필드와 주변 문맥을 확인하세요.
Shadowsocks의 cipher는 서버 설정과 일치해야 합니다. VMess와 VLESS의 사용자 식별자는 서로 바꿔 쓸 수 없습니다. WebSocket을 사용하는 노드는 경로와 Host도 확인해야 합니다. REALITY 노드는 서비스 제공업체가 안내한 공개 키, 짧은 ID, 서버 이름 등의 매개변수를 확인하세요. 구독을 변환하는 과정에서 이런 필드가 빠졌다면 노드 이름을 바꾸거나 속도를 다시 측정해도 복구되지 않습니다.
5. 로그로 DNS·포트·핸드셰이크 문제 구분하기
구독, 시간, 호환성을 확인한 다음 요청이 어느 단계에서 멈추는지 살펴보세요. DNS, TUN, 포트, 규칙을 한꺼번에 바꾸면 문제가 해결되더라도 원인을 알기 어렵습니다. 로그 수준을 일시적으로 높여 문제를 한 번 재현한 뒤 원래 설정으로 되돌리세요. 클라이언트에 따라 설정 재정의에서 이 항목을 제어할 수 있으므로 최종 적용 설정을 확인해야 합니다.
log-level: debug| 로그 단서 | 일반적인 의미 | 다음 단계 |
|---|---|---|
no such host |
노드 도메인을 확인했지만 사용할 수 있는 결과를 얻지 못함 | 노드 도메인과 코어가 노드 주소를 조회할 때 사용하는 DNS 경로 확인 |
connection refused |
대상 서버나 중간 장비에서 연결을 명시적으로 거부함 | 주소, 포트, 서버의 수신 대기 상태 확인 |
i/o timeout |
읽기 또는 쓰기 단계가 제한 시간 안에 완료되지 않음 | 주변 로그를 확인해 연결 시도 중 시간 초과인지 핸드셰이크 후 시간 초과인지 구분 |
x509 관련 오류 |
인증서 검증 실패 | 시스템 시간, 서버 이름, 인증서 체인 확인 |
| 인증 실패 또는 핸드셰이크 종료 | 인증 정보, 전송 매개변수, 서버 정책 문제일 수 있음 | 구독의 원본 매개변수와 서버 로그를 대조해 추가 확인 |
노드 서버 도메인 조회와 웹페이지 대상 도메인 조회는 별개의 단계입니다. mihomo에서 proxy-server-nameserver를 설정했다면 프록시 노드 도메인을 제대로 조회하는지 확인하세요. 브라우저 DNS만 바꿔도 코어가 노드에 연결할 때 사용하는 조회 경로에는 영향을 주지 않을 수 있습니다.
TCP 포트 확인으로 문제 범위를 좁힐 수 있습니다. 예를 들어 Windows PowerShell에서 아래 명령은 example.com의 TCP 443 포트를 확인합니다. 이 도메인은 명령 형식을 보여 주기 위한 예시이므로 실제 점검 시에는 구독에 기재된 서버와 포트로 바꾸세요. 예시 결과가 노드 상태를 나타내는 것은 아닙니다.
Test-NetConnection -ComputerName example.com -Port 443TCP 확인에 성공해도 TCP 연결이 성립했다는 뜻일 뿐, 프록시 인증이나 TLS 핸드셰이크 성공을 보장하지는 않습니다. Hysteria2, TUIC 등 QUIC 기반 연결은 UDP를 사용하므로 TCP 테스트로 서비스 가용성을 확인할 수도 없습니다. TCP 443에 접속된다는 이유만으로 현재 네트워크가 UDP를 제한할 가능성을 배제하지 마세요.
6. 시스템 프록시·TUN·현재 네트워크 영향 구분하기
코어의 내장 노드 테스트와 브라우저 접속은 서로 다른 경로를 사용할 수 있습니다. 브라우저는 시스템 프록시, 확장 프로그램, 앱 자체 설정의 영향을 받습니다. TUN은 가상 네트워크 어댑터, 라우팅, DNS 가로채기와 관련됩니다. 코어 자체가 노드에 연결하지 못한다면 브라우저 프록시를 반복해서 바꿔도 대개 해결되지 않습니다. 노드 테스트는 성공하지만 웹페이지가 열리지 않을 때는 앱 트래픽이 코어를 통과하는지 확인하세요.
먼저 로컬 프록시를 명시적으로 지정해 테스트하기
실제로 사용하는 혼합 포트가 7890이라면 아래 명령으로 시스템 프록시 설정을 거치지 않고 로컬 HTTP 프록시에 직접 요청할 수 있습니다. 포트가 7890이 아니라면 현재 수신 대기 중인 포트로 바꿔야 합니다. Windows에서는 curl.exe를 사용하면 일부 PowerShell 환경에서 같은 이름의 별칭이 명령 실행을 방해하는 일을 피할 수 있습니다.
curl --verbose --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/이 명령도 코어 규칙을 따르며 특정 노드를 자동으로 강제 선택하지 않습니다. 연결 기록에서 대상 요청이 DIRECT가 아니라 의도한 프록시 그룹을 통과하는지 확인하세요. 명령의 10초와 20초는 각각 연결 단계와 전체 요청의 시간 제한이며, 노드 성능을 판단하는 기준은 아닙니다. 실패했다면 단순히 ‘열리지 않음’이라고만 기록하지 말고 어느 단계에서 오류가 발생했는지 남기세요.
같은 기기에서 네트워크를 바꿔 비교하기
- 변수를 여러 개 동시에 바꾸지 않도록 같은 기기, 같은 설정, 같은 노드로 집 Wi-Fi와 휴대폰 핫스팟을 비교하세요.
- 한 네트워크에서만 실패한다면 해당 네트워크의 로그인 인증, UDP 제한, 라우팅 또는 방화벽 정책을 확인하세요. 곧바로 구독을 다시 가져올 필요는 없습니다.
- 다른 VPN이나 네트워크 필터링 도구를 사용 중이라면 상태를 기록하고, 허용된 환경에서 하나씩 비활성화해 테스트하세요. 보안 기능을 모두 한꺼번에 끄지는 마세요.
- 로그에서 연결 대상이 IPv4인지 IPv6인지 확인하세요. 해당 주소 계열에 실제로 접속할 수 없다는 점을 확인한 뒤에만 관련 설정을 하나씩 시험하고, 다른 문제를 가리기 위해 IPv6를 전역적으로 끄지는 마세요.
로컬 프록시를 명시한 테스트는 성공하지만 TUN을 켠 뒤 실패한다면 TUN 라우팅, DNS 가로채기 설정, 다른 가상 네트워크 어댑터와의 충돌을 확인하세요. 설정을 바꾸기 전에 저장하고 테스트 후에는 원래대로 복구합니다. 기본 설정은사용 가이드를 참고하세요. TUN을 모든 시간 초과 문제의 기본 해결책으로 여겨서는 안 됩니다.
7. 변수를 최소화해 재검증하고 재현 기록 정리하기
한 가지 문제를 해결한 뒤 처음 선택한 노드와 같은 테스트 주소로 다시 확인하세요. 시간 제한을 늘린 뒤 간헐적으로만 성공한다면 지연이나 패킷 손실의 영향을 받을 수 있으므로 실제 접속이 안정적인지 추가로 살펴봐야 합니다. 목록에 지연 시간이 표시됐다고 해서 점검이 끝난 것은 아닙니다.
- 구독 단계: 계정이 유효하고 사용할 트래픽이 남아 있으며, 현재 노드가 가장 최근에 성공적으로 업데이트된 구독에서 가져와 실제 적용되었는지 확인하세요.
- 기기 단계: 시스템 시계가 동기화되었는지 확인하고 코어 이름과 버전을 기록한 뒤 설정 로딩 오류가 없는지 확인하세요.
- 연결 단계: 노드 도메인 조회, 대상 주소와 포트를 확인하고 로그에서 가장 먼저 실패한 지점을 찾으세요.
- 요청 단계: 테스트 URL과 실제 웹페이지 접속을 확인하고, 연결 기록에서 의도한 노드가 선택되었는지 살펴보세요.
- 환경 단계: 필요한 경우 다른 네트워크와 비교하고 시스템 프록시와 TUN 상태를 각각 기록하세요. 두 설정을 동시에 바꾸지 마세요.
서비스 제공업체나 클라이언트 관리팀에 문의할 때는 운영체제 버전, 클라이언트와 코어 버전, 재현 시각과 시간대, 노드 프로토콜 유형, 민감 정보를 가린 오류 로그, 네트워크를 바꿨을 때의 비교 결과를 함께 전달하세요. 서비스 제공업체는 계정 권한과 서버 수신 대기 상태를 확인하는 데 적합하고, 클라이언트 관리팀은 설정 파싱, 코어 호출, 라우팅 처리 문제를 확인하는 데 적합합니다. 문제 발생 지점에 맞는 담당자에게 문의하면 ‘모두 timeout’ 화면만 보내는 것보다 원인을 찾기 쉽습니다.
문제 해결 후에는 임시로 높였던 로그 수준을 원래대로 되돌리고 민감 정보가 포함된 디버그 파일을 삭제한 뒤 정상 작동하는 설정의 백업을 보관하세요. 다음에 같은 문제가 발생하면 ‘구독 및 인증 정보 → 시스템 시간 → 코어 호환성 → DNS 및 연결 → 앱 접속 경로’ 순서로 확인하는 편이 노드를 무작정 하나씩 시험하는 것보다 공통 원인을 찾기 쉽습니다.