Clash Meta
문제 해결 가이드

노드 시간 초과: DNS·연결·핸드셰이크 나눠 확인

속도 테스트 실패가 모든 요청의 실패를 뜻하지는 않습니다

클라이언트의 지연 시간 측정은 보통 지정한 프록시를 거쳐 테스트 주소에 요청을 보내며, 해당 탐색 요청의 결과를 보여 줍니다. 서버 포트에 연결할 수 있는지만 단순히 측정하는 것이 아닙니다. 테스트 주소에 접속할 수 없거나 예상한 응답을 받지 못하거나 서버가 잦은 테스트를 제한하면 시간 초과로 표시될 수 있습니다. 먼저 같은 출구로 실제 필요한 웹사이트에 접속하고 연결 로그를 확인하세요. 실제 접속이 정상이라면 구독을 바로 삭제하지 말고 테스트 주소와 측정 간격을 확인하세요.

실패 범위를 단일 출구, 같은 서비스 제공업체의 모든 출구, 모든 제공업체의 출구로 나눠 보세요. 하나만 실패하면 해당 서버와 설정값을 먼저 확인하세요. 한 그룹이 동시에 실패하면 계정 상태, 구독 갱신, 서버 점검 여부를 확인하세요. 모든 출구가 실패하면 로컬 네트워크, DNS, 시스템 시간, 방화벽을 다시 확인하세요. 휴대폰 핫스팟은 다른 네트워크와 비교할 때 유용하지만, 네트워크를 바꾼 뒤에는 연결을 새로 설정해야 합니다. 이전 연결의 실패가 새 네트워크에서도 이어진다고 볼 수 없습니다.

오류가 발생한 단계에 따라 로그 읽기

lookup 또는 no such host는 대개 서버 도메인 이름 확인 문제를 가리킵니다. connection refused는 대상이 연결을 거부했다는 뜻이며, 포트가 열려 있지 않거나 서비스 설정이 맞지 않을 때 흔히 발생합니다. 연결 시간 초과는 제한 시간 내에 특정 단계가 완료되지 않았다는 뜻일 뿐, 계정이 만료됐다는 증거는 아닙니다. 로그가 TLS 또는 프로토콜 핸드셰이크 단계까지 진행됐다면 DNS를 계속 바꾸기보다 인증, SNI, 전송 방식, 시스템 시간을 확인하세요.

프록시를 직접 관리하는 경우 type, 서버 주소, 포트, 인증 정보, 전송 계층 설정을 하나씩 확인하세요. TLS 서버 이름이 연결 주소와 다를 수 있으며 WebSocket 경로와 Host 값도 임의로 바꿔 쓸 수 없습니다. 제공업체의 mihomo 설정을 기준으로 대소문자와 필드 계층을 그대로 유지하세요. 구독 변환 후 알 수 없는 필드나 지원되지 않는 프로토콜 오류가 발생하면 클라이언트 이름만 보고 호환성을 판단하지 말고 실제 커널을 확인하세요.

프로토콜 기능과 네트워크 제한 구분

일부 출구는 UDP를 사용하므로 일반 TCP 웹사이트에 접속된다고 해서 해당 출구의 전송 경로까지 정상이라고 볼 수 없습니다. 반대로 TCP 프록시가 정상인데 게임이 실패한다면 앱이 UDP를 사용하거나 프록시가 해당 트래픽을 지원하지 않거나 정책 그룹이 예상한 출구를 선택하지 않았을 수 있습니다. 먼저 일반 HTTPS 요청으로 기준을 확인한 뒤 UDP가 필요한 앱을 별도로 테스트하세요. 두 가지 요구 사항을 하나의 지연 시간으로 판단하지 마세요.

시스템 날짜와 시간대, 자동 시간 설정 상태를 확인하세요. 시간이 맞지 않으면 인증서가 아직 유효하지 않거나 만료된 것으로 처리될 수 있습니다. 특정 Wi-Fi에서만 인증서 오류가 발생한다면 인증 포털이나 네트워크 검사 장비도 원인일 수 있습니다. skip-cert-verify를 만능 해결책으로 사용하지 마세요. 연결의 신뢰 경계를 바꾸는 설정일 뿐 서버 이름, 인증서 체인, 인증 매개변수 문제를 해결하지는 않습니다.

제공업체에 문의할 때는 오류가 발생한 시간과 시간대, 네트워크 종류, 프로토콜 이름, 민감 정보를 가린 오류 로그를 전달하세요. 구독 전체 주소, QR 코드, 비밀번호가 포함된 설정은 보내지 마세요. 네트워크를 바꾸면 해결된다면 접속 경로와 관련된 문제일 가능성이 있습니다. 같은 출구가 여러 기기와 네트워크에서 모두 실패할 때 서버 측 점검을 요청할 근거가 더 확실해집니다. 시간 제한을 늘리면 느린 응답을 확인할 수는 있지만, 수신 중이 아닌 포트나 잘못된 인증이 해결되지는 않습니다.

속도 저하: 대역폭·지연 시간·부하 구분

재현 가능한 비교 조건부터 설정하세요

속도 저하는 웹페이지 첫 화면 로딩 지연, 동영상 버퍼링, 낮은 다운로드 속도, 조작 지연 등 서로 다른 현상을 가리킬 수 있습니다. 하나의 기준으로 판단하지 마세요. 기기, 네트워크, 대상, 출구를 고정한 뒤 변경 전후를 비교하세요. 웹사이트를 처음 열 때만 느리고 이후 전송은 정상이라면 DNS, 연결 설정, 핸드셰이크를 먼저 확인하세요. 다운로드 내내 느릴 때는 가용 대역폭, 서버 부하, 대상 사이트의 제한을 살펴보세요. 모든 노드를 반복해서 측정하는 것보다 증상을 기록하는 편이 유용합니다.

먼저 직접 접속할 수 있는 리소스로 로컬 네트워크의 기준 속도를 확인한 뒤 프록시를 거쳐 같은 리소스에 접속하세요. 프록시가 필요한 대상이라면 사용 가능한 두 출구를 비교하세요. 테스트 중에는 시스템 업데이트, 클라우드 동기화, 기타 대용량 작업을 일시 중지해 여러 기기의 대역폭 공유로 인한 오판을 방지하세요. Wi-Fi 신호, 라우터 부하, 모바일 네트워크 혼잡은 프록시보다 앞단의 문제이므로 클라이언트를 바꿔도 해결되지 않습니다.

지연 시간 측정은 처리량 순위가 아닙니다

지연 시간이 낮은 출구라고 해서 처리량이 높거나 모든 웹사이트에 적합한 것은 아닙니다. 자동 선택 정책은 대개 테스트 요청을 기준으로 동작하며 지속적으로 다운로드 대역폭을 측정하지 않습니다. 특정 웹사이트만 느리다면 해당 사이트의 CDN, 계정 제한, 출구에서 대상까지의 경로를 확인하세요. 모든 대상이 느리다면 접속 네트워크와 서버 전반의 상태를 살펴보세요. 대용량 파일 다운로드 한 번의 결과를 모든 앱의 사용 경험에 확대 적용하지 마세요.

연결 기록에서 실제 트래픽이 거친 정책 그룹을 확인하세요. 규칙에서 자동 그룹을 선택했더라도 자동 그룹 안에서 다시 다른 선택 그룹을 참조할 수 있습니다. 화면에 표시된 상위 그룹 이름이 최종 출구를 뜻하지는 않습니다. 정책을 변경해도 이미 설정된 장시간 연결은 이전 경로를 계속 사용할 수 있으므로 대상 앱 연결을 닫거나 해당 연결만 끊고 다시 시도하세요. 중요한 다운로드나 원격 세션 중에 모든 연결을 지우면 문제 해결 과정에서 추가 중단이 발생할 수 있습니다.

DNS·프로토콜·TUN 부하 확인

새 도메인을 열 때마다 잠시 멈춘다면 DNS 요청이 여러 번 시간 초과된 뒤 다른 경로로 재시도되는지 확인하세요. 업스트림을 여러 개 설정한다고 자동으로 더 빨라지지는 않습니다. 하나가 연결되지 않거나 부트스트랩 DNS 설정이 잘못됐거나 불안정한 출구로 질의가 전송되면 새 연결이 늦어질 수 있습니다. 우선 현재 네트워크에서 사용할 수 있는 DNS 경로 하나로 기준을 확인한 뒤 필요한 분기를 추가하세요. 캐시는 반복 조회에만 영향을 주며 최초 조회 경로 문제를 해결하지 못합니다.

브라우저가 HTTP/3를 먼저 시도했지만 출구나 현재 네트워크의 UDP 경로가 불안정해 TCP로 전환되면 처음에는 멈칫하다가 나중에 회복되는 것처럼 보일 수 있습니다. 비교를 위해 해당 앱에서 QUIC를 일시적으로 끌 수 있지만, 음성 통화, 게임, 일부 프로토콜은 UDP에 의존하므로 UDP를 모두 영구 차단하는 방식은 최적화가 아닙니다. 진단 중에는 연결 유형과 대상 포트를 함께 살펴 느린 요청이 실제로 UDP를 사용하는지 확인하세요.

TUN은 더 많은 트래픽을 처리하므로 켜면 시스템 프록시가 포착하지 못한 백그라운드 트래픽이 새로 드러날 수 있습니다. 보안 소프트웨어, 다른 VPN, 가상 네트워크 어댑터와 경로가 충돌할 수도 있습니다. 같은 대상을 ‘명시적 HTTP 프록시’와 ‘TUN 연결’로 각각 비교하세요. 전자는 정상이고 후자만 느리다면 구독을 바꾸기보다 라우팅과 네트워크 스택을 먼저 확인하세요. stack을 변경하기 전에 현재 커널과 플랫폼의 지원 여부를 확인하고 원래 값을 기록해 두세요.

작은 요청은 정상이지만 큰 응답이 멈춘다면 경로 MTU나 중간 네트워크 장비를 의심할 수 있습니다. 다만 먼저 대상의 속도 제한과 패킷 손실을 배제하세요. MTU는 실제 터널 인터페이스에 맞춰 조정하고 변경 전후를 비교해야 합니다. 임의의 값을 모든 네트워크 어댑터에 적용하지 마세요. 방화벽을 반복해서 끄는 것도 속도 개선 방법이 아닙니다. 실제 차단 기록을 확인한 뒤 클라이언트와 관련된 프로그램이나 인터페이스 규칙만 조정하세요.

문제 해결이 끝나면 재현 가능한 기록을 남기세요. 같은 대상과 시간대에서 두 출구, 두 가지 접속 방식으로 측정한 결과와 TUN 사용 여부를 기록하면 됩니다. 특정 서버 경로에서 문제가 계속 발생한다면 해당 정보를 제공업체에 전달하는 것이 더 효과적입니다. 근거 없이 캐시를 비우거나 소프트웨어를 다시 설치하거나 동시 연결 수를 늘리는 방법을 기본 속도 개선 절차로 삼지 마세요.

시스템 프록시가 작동하지 않음: 앱 연결 방식 확인

시스템 프록시는 모든 네트워크 트래픽을 가로채지 않습니다

시스템 프록시는 앱에 제공되는 연결 설정이며 실제 사용 여부는 앱과 네트워크 라이브러리에 따라 다릅니다. 브라우저는 정상인데 명령줄 도구, 게임, 스토어 앱이 실패해도 반드시 규칙 오류인 것은 아닙니다. 프록시 주소를 명시한 명령으로 커널 진입점을 먼저 확인한 뒤 대상 앱이 시스템 설정을 읽는지 살펴보세요. 어떤 앱은 HTTP 또는 SOCKS 주소를 별도로 입력해야 하고, 어떤 앱은 환경 변수를 사용하며, 일부는 TUN을 통해 처리하는 편이 낫습니다. 하나의 설정으로 모든 프로세스가 프록시를 사용한다고 가정하지 마세요.

Windows의 사용자 프록시, 자동 프록시 스크립트, WinHTTP 설정은 서로 다른 진입점입니다. netsh winhttp show proxy로 WinHTTP 상태를 확인할 수 있지만 현재 브라우저가 사용하는 설정을 보여 주는 것은 아닙니다. 앱 하나를 고치려고 모든 시스템 서비스에 프록시를 설정하지 마세요. 서비스 계정, 업데이트 구성 요소, 사용자 세션마다 필요한 네트워크가 다를 수 있습니다. 실패한 프로그램이 어떤 네트워크 라이브러리를 사용하는지 파악한 뒤 적절한 설정 방법을 선택하세요.

로컬 주소·포트·환경 변수 확인

로컬 앱은 보통 127.0.0.1과 실제 수신 포트를 사용합니다. 시스템 프록시에 이전 포트가 남아 있거나 SOCKS 전용 입력란에 HTTP 주소를 넣으면 연결되지 않습니다. allow-lan: false여도 같은 기기의 루프백 연결은 가능합니다. 하지만 다른 기기에서 해당 기기 자신의 127.0.0.1을 컴퓨터 주소로 사용할 수는 없습니다. 로컬 네트워크에서 공유해야 하는 경우에만 수신 주소, 방화벽, 신뢰 경계를 추가로 확인하세요.

터미널 환경 변수는 새로 실행한 하위 프로세스에 전달됩니다. 클라이언트에서 포트를 바꿔도 이미 열려 있는 터미널에는 이전 값이 남아 있을 수 있습니다. 시스템 프록시를 꺼도 직접 설정한 환경 변수가 자동으로 삭제되지는 않습니다. 다음 예시는 Unix 계열 셸의 현재 세션에서 비교하기 위한 것으로 영구 설정을 변경하지 않습니다. 기존 변수를 확인하고 출처를 기록한 뒤 테스트 값을 설정하세요. 복구할 때는 셸 시작 파일, 개발 도구 설정, 프로젝트 스크립트에서 프록시 값을 다시 주입하는지도 확인해야 합니다.

env | grep -i proxy
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -I --max-time 20 https://example.com
unset http_proxy https_proxy

여기서 https_proxy 값이 http://로 시작하는 것은 HTTPS 대상의 연결을 위해 앱이 로컬 HTTP 프록시에 접속한 뒤 HTTPS 터널을 만든다는 뜻입니다. 대상 통신이 암호화되지 않는다는 뜻은 아닙니다. 도구마다 환경 변수의 대소문자와 우선순위 처리 방식이 다르며 ALL_PROXY와 NO_PROXY도 동작에 영향을 줄 수 있습니다. 확인할 때는 이런 변수도 살펴보고 지나치게 넓은 우회 도메인이나 네트워크 대역이 있는지 확인하세요.

UWP·컨테이너·TUN 환경 확인

Windows의 일부 스토어 앱은 루프백 연결이 제한돼 있어 시스템 프록시가 올바르더라도 로컬 프록시 포트에 연결하지 못할 수 있습니다. 먼저 일반 데스크톱 앱이 같은 포트로 정상 연결되는지 확인한 뒤 해당 앱에 루프백 예외를 추가하거나 TUN을 사용하는 방안을 검토하세요. 모든 앱에 한꺼번에 예외를 적용하지 마세요. 명령과 적용 범위는 UWP 루프백 제한 문제 해결을 참고하세요. 이 문제는 원격 프록시 인증을 변경할 필요가 없습니다.

컨테이너, 가상 머신, WSL은 별도의 네트워크 환경을 사용하므로 내부의 루프백 주소가 호스트를 가리키지 않을 수 있습니다. 현재 네트워크 모드에서 호스트에 연결 가능한 주소를 찾고 방화벽과 수신 범위를 확인하세요. 로컬 프록시를 모든 인터페이스에 바로 공개하지 마세요. 같은 네트워크의 다른 기기가 공유 프록시를 사용할 수 있습니다. 꼭 공개해야 한다면 신뢰할 수 있는 접속자만 허용하고 클라이언트가 지원하는 접근 제어를 설정하세요.

TUN은 가상 인터페이스와 라우팅을 통해 트래픽을 처리하며 보통 추가 권한이나 서비스 구성 요소가 필요합니다. 활성화 후 로그에서 장치 생성, 경로 설치, DNS 가로채기 상태를 확인하세요. VPN 두 개가 동시에 기본 경로를 수정하거나 가상 머신 대역과 터널 대역이 겹치면 특정 대상에 접속할 수 없게 될 수 있습니다. 다른 트래픽 가로채기 프로그램을 중지해 비교한 뒤 복구되면 명시적인 경로를 통해 함께 사용할 수 있는지 살펴보세요. 네트워크 어댑터를 계속 재설치하지 마세요.

마지막으로 대상 앱에서 새 요청을 보내고 연결 화면에서 프로세스 또는 대상, 적용된 규칙, 출구를 확인하세요. 웹사이트에 표시된 출구가 바뀌었다는 사실은 해당 웹사이트의 연결 경로가 정상이라는 것만 증명합니다. 복구 후 브라우저, 명령줄, 이전에 실패한 앱을 각각 테스트하세요. 클라이언트를 종료한 뒤 시스템 프록시 설정이 복구되는지도 확인해 중지된 포트를 가리키는 설정이 남지 않도록 하세요.

모바일 문제: VPN·백그라운드·네트워크 전환

Android: VPN 서비스 상태부터 확인

Android 클라이언트는 보통 시스템 VPN 서비스를 통해 트래픽을 처리합니다. 같은 사용자나 프로필에서 다른 VPN, 일부 로컬 필터링 도구, 기업 보안 앱이 이 기능을 사용 중일 수 있습니다. 다른 트래픽 가로채기 앱을 먼저 종료한 뒤 Clash Plus, Clash Meta for Android 또는 FlClash에서 다시 연결하고 시스템 VPN 표시와 권한 상태를 확인하세요. 앱 첫 화면의 버튼 색상만으로 백그라운드 서비스가 계속 실행 중이라고 판단하지 마세요.

특정 앱만 실패한다면 앱별 분기 목록을 확인하세요. 제외 목록에 추가된 앱은 예상한 대로 프록시를 거치지 않습니다. 선택한 앱만 프록시를 사용하는 모드에서는 선택하지 않은 앱도 처리되지 않습니다. 업무용 프로필과 개인 프로필은 앱과 VPN 환경이 다를 수 있으므로 개인 프로필의 연결이 정상이라고 업무용 프로필에서도 같은 경로를 사용한다고 볼 수 없습니다. 먼저 문제가 발생한 앱이 어느 프로필에 속하는지 확인하고 회사 정책 조정이 필요한지 판단하세요.

화면 잠금 후 연결 끊김: 절전 제한과 라우팅 상태 구분

화면이 켜져 있을 때는 정상이고 잠근 뒤 연결이 끊긴다면 VPN 서비스가 계속 실행 중인지 먼저 확인한 다음 백그라운드 활동, 백그라운드 데이터, 자동 시작을 제한하는 시스템 설정을 살펴보세요. Android 제조사마다 설정 경로가 다를 수 있습니다. ‘설정 → 앱 → 해당 클라이언트 → 배터리’에서 백그라운드 실행 권한을 찾고 모바일 데이터 제한도 확인하세요. 한 번에 하나씩 변경하고 화면을 잠근 뒤 다시 테스트하세요. 모든 절전 기능을 한꺼번에 끄면 실제로 필요한 예외를 찾기 어렵습니다.

시스템에서 상시 VPN 또는 VPN을 통하지 않는 연결 차단을 켠 경우, 서비스가 종료되면 기기 전체가 오프라인처럼 보일 수 있습니다. 이는 노드가 갑자기 실패했다기보다 차단 정책과 서비스 상태가 함께 작용한 결과일 수 있습니다. 임시로 네트워크를 복구하기 전에 해당 옵션의 보호 목적을 이해하고 시스템 VPN 설정에서 조정한 뒤 클라이언트를 복구해 다시 확인하세요. 전체 점검 절차는 Android 백그라운드 및 배터리 최적화 문제 해결을 참고하세요.

배터리 사용량이 높아도 앱별 순위만 보고 판단하지 마세요. VPN 프로세스는 다른 앱의 터널 트래픽을 처리하므로 시스템 사용량 통계에 일부 네트워크 소비가 VPN 앱으로 집계될 수 있습니다. 비슷한 사용 시간대의 화면 켜짐 시간, 데이터 전송 활동, 네트워크 종류를 비교한 다음 지나치게 잦은 상태 확인, 구독 갱신, 재연결이 있는지 살펴보세요. 유휴 상태에서도 로그가 계속 쌓이면 모든 DNS 기능을 끄기보다 반복 요청의 출처를 먼저 찾으세요.

iOS: 터널과 온디맨드 연결 확인

iOS 사용자는 설치 파일 페이지에서 Clash Plus의 App Store 페이지로 이동할 수 있으며 공식 사이트는 clashplus.io입니다. 연결에 문제가 있으면 시스템 VPN 설정과 앱의 현재 설정이 일치하는지 확인하고 다른 네트워크 확장이 트래픽을 처리하는지도 살펴보세요. 앱을 백그라운드로 전환했다고 터널이 종료되는 것은 아닙니다. 시스템 VPN 상태와 새 요청의 결과를 함께 확인하세요.

온디맨드 연결을 활성화하면 네트워크가 바뀐 뒤 시스템이 터널을 자동으로 다시 만들 수 있습니다. 수동으로 연결을 끊은 직후 다시 연결되더라도 조작이 반영되지 않은 것은 아닐 수 있으므로 현재 온디맨드 규칙과 적용 네트워크를 확인하세요. Wi-Fi에서는 정상이고 셀룰러에서는 실패한다면 앱의 셀룰러 데이터 권한을 먼저 확인한 뒤 현재 네트워크에서 구독 주소와 출구에 접속할 수 있는지 살펴보세요. 휴대폰 네트워크를 전환하면 기존 연결의 원본 주소가 바뀌므로 일부 장시간 연결은 다시 설정해야 합니다.

네트워크 전환·인증 포털·로컬 네트워크 접속

Wi-Fi에서 셀룰러 네트워크로 전환한 뒤 시스템 네트워크가 안정될 때까지 기다리고 대상 요청을 새로 보내세요. 여전히 실패한다면 설정을 삭제하지 말고 VPN을 다시 연결하세요. 공용 Wi-Fi의 인증 페이지는 로컬 네트워크나 특정 도메인에 의존할 수 있습니다. 필요한 경우 프록시를 잠시 중지하고 인증을 마친 뒤 다시 켜세요. 시스템이 터널 외부 트래픽을 항상 차단한다면 앞서 설명한 VPN 정책도 확인해 터널이 연결되기 전에 인증 요청이 차단되지 않도록 하세요.

휴대폰 화면 미러링, 프린터, 홈 서버 연결이 실패하면 로컬 네트워크 주소가 원격 프록시로 잘못 전송되는지, VPN 설정에서 필요한 로컬 접속을 허용하는지 확인하세요. 프린터 한 대 때문에 모든 트래픽을 직접 연결로 바꾸지 마세요. 대상 로컬 IP 주소와 도메인을 기록하고 범위를 최소화한 규칙을 사용하세요. 앱이 기기 검색 프로토콜을 사용하는 경우 TCP 대상 하나만 규칙에 추가해도 충분하지 않을 수 있으므로 로컬 브로드캐스트나 멀티캐스트 동작도 고려해야 합니다.

모바일 문제를 재현할 때는 운영체제, 접속 네트워크, 화면 잠금 전후 상태, VPN 유지 여부, 실패한 앱의 범위를 기록하세요. 설정 전체를 공개해 도움을 요청하지 마세요. 복구한 뒤 화면이 켜진 상태의 접속, 짧은 화면 잠금, Wi-Fi와 셀룰러 전환, 로컬 네트워크 접속을 차례로 테스트하세요. 기본 개념은 문제 해결에서 확인하고 설정을 다시 가져오려면 입문 가이드의 설정 단계로 돌아가세요.