Clash 속도 느릴 때 해결 방법: 노드 품질·회선 혼잡·로컬 설정 점검

먼저 지연 시간, 다운로드 속도, 웹페이지 첫 로딩을 구분하세요

Clash 클라이언트에 표시되는 지연 시간은 보통 코어가 지정된 프록시를 통해 테스트 주소에 접속해 측정한 값이며, 지속적인 다운로드 대역폭과는 다릅니다. 테스트 주소와 제한 시간, 클라이언트 구현 방식에 따라 수치가 달라질 수 있습니다. 지연 시간이 80ms인 노드라도 출구 대역폭 제한으로 다운로드 속도가 매우 낮을 수 있고, 220ms인 원거리 노드는 오히려 지속 처리량이 더 높을 수도 있습니다.

진단을 시작하기 전에 ‘느리다’는 현상을 구체적으로 기록하세요. 운영체제, 클라이언트 이름, 코어 버전, 현재 설정, 프록시 모드, 실제 선택된 노드와 문제가 발생한 네트워크 환경을 적어 둡니다. 클라이언트 버전과 코어 버전은 별개이므로 버전 정보나 시작 로그에서 각각 확인하세요. ‘최신 버전’이라고만 기록하면 안 됩니다.

증상	우선 기록할 항목	먼저 확인할 계층
웹페이지 첫 접속은 느리지만 새로고침하면 빨라짐	도메인 조회 시간, 연결 설정, 첫 바이트 수신 시간	DNS, 연결 재사용, 대상 사이트
대용량 파일 다운로드가 계속 느림	30초간 평균 속도	노드 용량, 회선, 로컬 대역폭
동영상이 간헐적으로 버퍼링됨	버퍼링 발생 시간, 실제 미디어 도메인, 정책 적용 경로	출구에서 미디어 CDN까지의 경로
특정 앱만 느림	앱 연결이 클라이언트에 표시되는지	프록시 적용 범위와 규칙 매칭

테스트 조건을 고정하고 한 번에 여러 항목을 바꾸지 마세요

백그라운드 대용량 다운로드, 클라우드 동기화, 다른 속도 측정 작업을 먼저 중지하세요. 무선 네트워크는 가능한 한 같은 위치에서 테스트하고, 여건이 되면 유선 연결로도 한 번 측정합니다. 라우터에서 실행 중인 다른 VPN, 투명 프록시, 트래픽 분산 서비스도 테스트 조건에 기록하세요. 두 단계 프록시의 결과를 단일 연결 결과로 오해하지 않도록 주의해야 합니다.

로컬 기준 속도 측정: 클라이언트의 시스템 프록시와 TUN을 끄고 브라우저에 별도 프록시가 설정되어 있지 않은지 확인합니다. 그런 다음 로컬 네트워크에서 바로 접속할 수 있는 속도 측정 서비스에 접속해 다운로드, 업로드, 지연 시간을 기록하세요. 이 단계는 인터넷 회선 속도를 확인하기 위한 것이며 프록시 출구의 성능을 나타내지는 않습니다.
테스트 대상을 고정: 테스트가 허용된 HTTPS 다운로드 리소스 하나를 선택하고, 모든 노드에서 같은 URL과 다운로드 방식, 동시 연결 수를 사용하세요. 서로 다른 속도 측정 서버가 추가 변수가 되지 않도록 합니다.
출구를 고정: 실제로 적용되는 정책 그룹을 수동 선택한 단일 노드로 설정하세요. 테스트 중 자동 선택이나 장애 조치로 출구가 바뀌지 않도록 합니다.
세 차례 반복: 매회 약 30초간 측정하고 회차 사이에 약 15초 간격을 둡니다. 중앙값과 측정 시간대를 기록하세요. 대용량 테스트는 구독 데이터 사용량을 늘리므로 필요한 만큼만 진행합니다.

노드를 바꾼 뒤에는 기존 다운로드를 중지하고 새 연결을 시작해야 합니다. 이미 연결된 TCP 세션은 정책 그룹을 바꿔도 다른 출구로 자동 이동하지 않는 경우가 대부분입니다. 연결을 정리해야 한다면 진행 중인 다른 작업을 중단하지 않도록 테스트 앱에 해당하는 연결만 종료하세요.

예를 들어 기록표에는 ‘노드 A: 2.1, 2.4, 2.2MB/s, 중앙값 2.2MB/s’처럼 적을 수 있습니다. 기록 방식의 예시일 뿐, 이 사이트에서 직접 측정한 결과는 아닙니다. 비교할 때 실패 횟수도 함께 기록하세요. 세 번 중 두 번 시간 초과가 발생했다면 한 번의 최고 속도보다 실제 사용 가능성을 더 잘 보여줍니다.

노드 품질: 단일 노드 처리량과 대상 사이트 응답 비교

노드 품질에는 접속 가능 여부, 서버 부하, 속도 제한 정책, 출구에서 대상 사이트까지의 연결 상태가 포함됩니다. 클라이언트의 ‘간편 속도 측정’이 지연 시간만 확인한다면 그 결과만으로 노드 대역폭을 판단할 수 없습니다. 같은 구독에서 후보 노드 두세 개를 골라 동일한 대상으로 각각 테스트한 다음, 실제 사용 환경에서도 확인하세요.

연결 기록에서 테스트가 실제 선택한 노드를 거쳤는지 확인하세요

클라이언트의 ‘연결’ 화면을 열고 새 다운로드 요청을 시작하세요.
대상 도메인이나 프로세스로 필터링해 매칭된 규칙과 전체 정책 경로를 확인하세요.
최종 출구가 방금 선택한 노드인지, DIRECT 또는 별도의 정책 그룹이 아닌지 확인하세요.
proxy-providers를 사용한다면 해당 프록시 모음의 업데이트 및 상태 확인 결과를 점검하세요. 이는 전체 설정 파일 업데이트와는 별개입니다.

노드 A가 여러 대상에서 느리고 같은 시간대에 노드 B는 훨씬 빠르다면 A의 부하, 대역폭 제한 또는 경로 문제를 먼저 의심하세요. 같은 노드에서 특정 사이트만 느리고 다른 다운로드는 정상이라면 출구에서 해당 사이트까지의 라우팅이나 CDN 배정 차이일 가능성이 큽니다. 노드 전체가 작동하지 않는다고 단정할 필요는 없습니다.

회선 혼잡: 시간대와 접속 네트워크를 교차 확인하세요

노드 이름의 지역 표기는 대개 출구 위치를 뜻하며, 로컬에서 진입점까지 그리고 출구까지 이어지는 전체 경로를 설명하지는 않습니다. 지역이 다른 두 노드가 같은 진입점이나 중계 경로를 사용할 수도 있습니다. 따라서 ‘지역을 바꿔도 느리다’는 이유만으로 회선 문제를 배제할 수 없습니다.

두 가지 기준으로 비교하세요

같은 네트워크, 다른 시간대: 예를 들어 같은 노드와 대상을 오전 10시와 오후 9시에 각각 측정하세요. 여러 날에 걸쳐 저녁 시간대에 속도가 뚜렷하게 떨어진다면 한 번의 일시적인 저속보다 피크 시간대 혼잡 가능성이 높습니다.
같은 시간대, 다른 네트워크: 몇 분 간격으로 가정용 인터넷과 휴대전화 핫스폿을 비교하세요. 클라이언트, 노드, 대상은 그대로 유지하고 핫스폿 신호 상태와 요금제 제한도 확인합니다.
같은 네트워크, 다른 진입 회선: 서비스 제공자가 회선 정보를 명확히 안내하는 경우 서로 다른 진입점을 사용하는 노드를 비교하세요. 노드 이름만 보고 회선이 서로 독립적이라고 판단하지 마세요.

가정용 인터넷에서 여러 노드가 모두 느리지만 핫스폿에서는 정상으로 돌아온다면 가정용 회선, 통신사 간 연결 또는 로컬 라우터 쪽에 문제가 있을 가능성이 큽니다. 같은 노드가 두 네트워크에서 모두 느리고 다른 노드는 정상이라면 해당 노드와 출구를 더 자세히 확인하세요. 이는 원인을 좁히는 단서이지, 한 번의 결과만으로 확정할 수 있는 결론은 아닙니다.

대용량 업로드 중 라우터 지연 시간이 급격히 늘어나는지도 확인할 수 있습니다. 업로드 대역폭이 가득 차면 대기열 지연이 발생해 웹페이지와 대화형 요청에도 영향을 줄 수 있습니다. 업로드를 멈춘 뒤 정상화된다면 대역폭 사용량과 라우터의 대기열 관리부터 점검하세요. 중간 라우터가 탐색 패킷에 응답하지 않는 경우는 흔합니다. 특정 홉의 패킷 손실률만으로 실제 서비스 연결의 손실을 판단해서는 안 됩니다.

규칙과 DNS: 느린 요청의 실제 경로 확인

진단할 때는 규칙 모드를 사용하고 실제로 매칭된 결과를 확인하세요. Clash와 mihomo의 규칙은 보통 순서대로 적용되므로 앞쪽 규칙이 뒤쪽 도메인 규칙보다 먼저 매칭될 수 있습니다. 마지막의 MATCH는 나머지 트래픽을 처리하는 규칙입니다. 대상 도메인을 그 뒤에 추가해도 대개 원하는 결과를 얻을 수 없습니다.

글로벌 모드는 잠시 비교할 때만 사용하세요

현재 설정을 이해한 상태라면 잠시 글로벌 모드로 전환하고, 글로벌 정책에서 사용할 노드를 직접 선택해 테스트할 수 있습니다. 같은 노드가 글로벌 모드에서는 정상인데 규칙 모드에서만 문제가 생긴다면 규칙 모드가 다른 정책 그룹, 직접 연결 출구 또는 체인 경로를 선택하는지 먼저 확인하세요. 테스트 후에는 기존 모드로 되돌리세요. 글로벌 모드를 사용하면 원래 직접 연결되어야 할 트래픽의 경로가 바뀔 수 있습니다.

DNS 대기와 콘텐츠 전송 지연을 구분하세요

첫 접속만 느리고 이후 요청은 빠른 경우: DNS 조회 시간, 캐시, 연결 재사용을 확인하세요. 모든 DNS 설정을 바로 바꾸지는 마세요.
특정 도메인 요청은 실패하지만 다른 사이트는 정상인 경우: 로그에 DNS 시간 초과가 표시되는지 확인하고 상위 DNS 서버에 접속할 수 있는지 점검하세요.
브라우저와 다른 앱의 동작이 다른 경우: 브라우저의 보안 DNS 설정을 확인하세요. 시스템의 DNS 조회 경로를 따르지 않을 수 있습니다.
Fake-IP를 사용한 뒤 198.18.0.0/16 범위의 주소가 표시되는 경우: 정상적인 가상 매핑일 수 있습니다. 해당 주소만 보고 DNS 장애라고 판단하지 마세요. 실제 사용 대역은 설정에 따라 달라집니다.

mihomo에서 dns.nameserver, dns.proxy-server-nameserver, dns.nameserver-policy는 각각 일반 DNS 조회, 프록시 서버 도메인 조회, 도메인별 DNS 서버 선택과 관련된 설정입니다. 실제 동작은 전체 설정에 따라 달라집니다. 인터넷에서 찾은 DNS 설정을 기존 구독 설정에 그대로 추가하지 마세요. 변경 전에 백업하고 한 번에 한 항목씩 수정한 뒤 설정을 다시 불러오고 테스트 연결을 새로 만드세요. 각 항목의 설명은 전체 매뉴얼의 DNS 섹션을 참고하세요.

시스템 프록시와 TUN: 앱 적용 범위와 로컬 부하 확인

시스템 프록시는 시스템 프록시 설정을 따르는 앱에서 주로 사용됩니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 많은 IP 트래픽을 처리하지만, 실제 적용 범위는 라우팅 제외 설정, 앱의 인터페이스 지정, 클라이언트 구현 방식에 따라 달라집니다. TUN은 속도 향상 기능이 아니며 노드 속도 제한을 우회할 수도 없습니다.

먼저 명시적 프록시로 문제 범위를 좁히세요

아래 명령은 로컬 HTTP 프록시 또는 혼합 프록시가 127.0.0.1:7890에서 대기 중인 경우를 전제로 합니다. 먼저 클라이언트의 포트 설정에서 실제 값을 확인하세요. 7890이 모든 클라이언트의 고정 포트는 아닙니다. Windows에서는 일부 PowerShell 환경에서 같은 이름의 별칭이 인수에 영향을 주지 않도록 curl.exe를 사용하세요.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 \
  --output /dev/null --silent --show-error \
  --write-out "connect=%{time_connect}\nTLS=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" \
  https://www.example.com/

macOS, Linux 등의 환경에서 사용할 수 있는 간단한 요청 진단 명령이며 대역폭 측정용은 아닙니다. Windows에서 사용하려면 curl을 curl.exe로 바꾸고 출력 대상을 NUL로 지정한 뒤 명령을 한 줄로 합치세요. 시간 단위는 초이며 각 항목은 요청 시작부터 누적된 시간입니다. 로컬 HTTP 프록시를 사용하면 time_connect는 주로 로컬 프록시 대기 포트까지의 연결 시간을 나타내며 원격 노드까지의 지연 시간은 아닙니다.

명시적 프록시 요청은 정상이지만 일반 앱은 여전히 느리다면 앱이 시스템 프록시를 따르는지, 별도의 프록시 확장 프로그램이 설치되어 있는지, 시스템 프록시가 현재 클라이언트 포트를 가리키는지 확인하세요. 연결 거부 오류가 표시되면 먼저 코어 실행 여부, 대기 주소의 정확성, 포트 점유 여부를 확인하세요. DNS를 먼저 바꿀 필요는 없습니다.

두 가지 트래픽 처리 방식을 각각 테스트하세요

현재 설정을 저장한 뒤 TUN을 끄고 시스템 프록시만 켜서 같은 브라우저와 대상으로 테스트하세요.
그런 다음 시스템 프록시를 끄고 TUN만 켜세요. 테스트 요청이 연결 기록에 표시되는지 확인한 뒤 다시 측정합니다.
작업 관리자나 활성 상태 보기에서 코어의 CPU 사용량을 확인하고, 다른 VPN이나 가상 네트워크 인터페이스가 라우팅을 변경하고 있지 않은지도 점검하세요.
TUN을 사용할 때만 끊김이 발생한다면 클라이언트 로그, 라우팅 충돌, 현재 네트워크와의 호환성을 확인하세요. 그다음 클라이언트가 지원하는 범위에서 네트워크 스택 설정을 비교합니다.

CPU 코어 하나가 지속적으로 거의 100% 사용되고 처리량까지 제한되는 경우에만 로컬 처리 병목을 의심할 단서가 됩니다. TUN 네트워크 스택, MTU, DNS를 동시에 변경하지 마세요. 특히 MTU는 대용량 패킷 전송이 멈추는 등 근거가 있을 때 비교 테스트해야 하며, 특정 값을 모든 환경에 적용할 수 있는 정답으로 여겨서는 안 됩니다.

진단 결과를 재현 가능한 문제로 좁히세요

한 번에 한 항목만 변경하고 변경 전후 결과를 저장하세요. 아래의 결과별 대응을 다음 단계 결정에 참고하되 로그와 반복 테스트도 함께 확인해야 합니다.

반복해서 나타나는 결과	다음 단계
특정 노드만 느리고 다른 노드는 정상	같은 대상으로 테스트한 기록을 보관하고 해당 노드의 부하, 속도 제한, 출구 경로를 확인하세요.
모든 노드가 느리고 직접 연결 기준 속도도 느림	로컬 대역폭, 무선 신호, 업로드 사용량, 라우터 부하부터 확인하세요.
저녁에는 느리지만 낮에는 정상	시간대별 차이를 계속 기록하고 별도 진입 회선과 비교하세요.
규칙 모드에서는 느리고 글로벌 모드에서는 정상	매칭된 규칙, 정책 그룹 선택, 최종 출구가 동일한지 확인하세요.
시스템 프록시는 정상이고 TUN은 비정상	라우팅 충돌, 트래픽 처리 범위, 네트워크 스택, 리소스 사용량을 점검하세요.

클라이언트 유지 관리자나 구독 서비스에 문의할 때 운영체제 버전, 클라이언트와 코어 버전, 문제 발생 시간대, 접속 네트워크, 재현 절차, 민감 정보를 제거한 로그를 제공하세요. 구독 URL, 토큰, 인증 정보와 불필요한 접속 도메인은 삭제해야 합니다. 코어 호환성 문제나 명확한 수정 내역이 확인된 경우에만 클라이언트 또는 코어 업데이트를 다음 단계로 고려하고, 기존 설정을 복구할 수 있도록 보관하세요.

전체 점검 순서는 다음과 같습니다. 먼저 로컬 기준 속도를 측정하고, 노드를 고정해 처리량을 비교한 다음, 회선을 교차 검증하고 마지막으로 규칙, DNS, 트래픽 처리 방식을 확인하세요. 구독 오류나 비정상적인 지연 문제도 계속 살펴봐야 한다면 문제 해결 가이드의 지연 시간 점검을 참고하세요. 구독을 가져오고 활성화하는 방법이 확실하지 않다면 먼저 구독 가져오기 안내에서 기본 설정을 확인하세요.