Clash 연결 속도 느릴 때 해결 방법: 노드·회선·기기 설정 점검

Clash 노드 목록에는 지연 시간이 80ms로 표시되는데 동영상은 계속 버퍼링되고, 180ms인 노드로 바꾸니 오히려 다운로드가 빨라질 때가 있습니다. 모순이 아닙니다. 지연 시간 측정, 지속 전송 속도, 앱 로딩 시간은 서로 다른 항목을 측정합니다. 속도가 느릴 때는 먼저 어느 구간에서 문제가 생기는지 확인한 뒤 노드, 회선, 기기 순으로 점검하세요. DNS, 규칙, TUN 설정을 계속 바꾸는 것보다 원인을 찾기 쉽습니다.

1. 지연 시간, 전송 속도, 웹페이지 첫 로딩 구분하기

Clash 계열 클라이언트의 ‘지연 시간’은 보통 노드를 거쳐 테스트 주소에 요청을 한 번 보내 측정합니다. ICMP ping과 같지 않으며 사용 가능한 대역폭을 직접 나타내지도 않습니다. 테스트 주소, 제한 시간, 연결 재사용 여부에 따라 결과가 달라집니다. 테스트 주소를 다른 사이트로 바꾸면 수치가 달라질 수 있지만, 동영상 플랫폼 이용 경험이 나아지는 것은 아닐 수 있습니다.

증상	우선 점검 항목	기록할 항목
페이지를 열기까지 오래 걸리지만 열린 뒤에는 정상	DNS, 연결 설정, 규칙 적용	첫 바이트 수신 시간, 연결 로그
다운로드 속도가 계속 낮음	노드 부하, 출구 대역폭, 원본 서버 속도 제한	30초 이상 측정한 평균 속도
일정한 간격으로 멈춤	패킷 손실, 무선 네트워크, 노드 전환	실패 횟수, 멈춘 시각
특정 앱만 느림	앱 프록시 설정, UDP, 분기 규칙	프로세스, 대상 도메인, 실제 출구

반복 가능한 속도 측정 조건 만들기

클라우드 동기화, 게임 업데이트, 다른 기기의 대용량 다운로드를 일시 중지하세요. 노트북은 전원에 연결하고 안정적인 Wi-Fi나 유선 연결을 사용합니다.
같은 기기와 다운로드 출처, 연결 방식을 유지하세요. 테스트가 허용되고 용량이 충분한 파일을 골라 30초 이상 연속으로 전송합니다.
각 조건에서 3회 측정하고 중앙값을 기록하세요. 시작 직후 몇 초간의 캐시 속도만 보거나 여러 노드를 동시에 측정하지 마세요.
직접 연결과 프록시 결과를 각각 기록하세요. 대상에 직접 연결할 수 없다면 직접 연결이 가능한 비교용 사이트를 사용하세요. 연결 실패를 대역폭 0으로 계산하면 안 됩니다.

단위에 유의하세요. 100Mbps의 이론상 전송 한도는 약 12.5MB/s이며, 실제 속도는 프로토콜 오버헤드만큼 낮아집니다. 다운로드 도구에 10MB/s가 표시된다고 해서 100Mbps 회선의 10분의 1만 사용 중인 것은 아닙니다. 브라우저의 다중 연결 다운로드와 단일 연결 다운로드 속도도 크게 다를 수 있으니 따로 기록하세요.

2. 1단계: 노드 품질과 실제 선택된 정책 확인

먼저 클라이언트의 ‘연결’ 페이지에서 테스트 중인 도메인을 찾아 적용된 규칙, 정책 그룹, 최종 노드를 확인하세요. 규칙 모드에서는 화면에서 프록시 그룹을 바꿔도 현재 요청에 반영되지 않을 수 있습니다. 중첩된 정책 그룹이 다른 자동 선택 그룹을 가리킬 수도 있습니다. 이미 연결된 세션은 선택을 바꿔도 바로 다시 연결되지 않는 경우가 많으므로, 테스트 전에 다운로드를 멈추고 요청을 새로 시작하세요. 필요한 경우 해당 기존 연결만 종료합니다.

지연 시간만 보지 말고 노드 세 개를 비교하세요

같은 지역의 서로 다른 노드: 특정 노드만 혼잡한지 확인할 수 있습니다. 가능하면 진입점이나 회선 식별자가 다른 노드를 선택하세요.
서로 다른 지역의 노드: 대상 서비스가 특정 출구 지역이나 통신사 간 경로에 영향을 받는지 확인하세요.
같은 노드를 다른 시간대에 측정: 낮과 저녁에 각각 테스트하세요. 저녁에만 속도가 크게 떨어진다면 용량 부족이나 통신사 간 연결 혼잡일 가능성이 큽니다. 이때 기기 MTU부터 바꾸지는 마세요.

예를 들어 노드 A는 지연 시간 65ms, 지속 다운로드 속도 1.2MB/s이고 노드 B는 145ms, 8.0MB/s라면, 이 결과로는 B가 해당 대용량 파일 전송에 더 적합하다고 볼 수 있습니다. 그렇다고 모든 게임이나 웹페이지에서 B가 더 낫다는 뜻은 아닙니다. 테스트 주소와 시각, 노드를 함께 기록해 서로 다른 조건의 수치를 직접 비교하지 않도록 하세요.

구독 업데이트는 설정과 노드 정보가 최신인지 갱신하는 기능이지, 회선 용량을 늘려 주지는 않습니다. 먼저 구독이 만료되지 않았는지, 트래픽을 모두 사용하지 않았는지, 서버에 속도 제한 안내가 없는지 확인한 뒤 한 번 수동으로 업데이트하세요. 업데이트에 실패해도 정상 작동 중인 설정은 유지하고 오류 내용을 확인하세요. 구독을 반복해서 삭제하고 다시 만들 필요는 없습니다.

3. 2단계: 진입 네트워크, 출구 회선, 대상 사이트를 나눠 확인

프록시 연결은 최소한 기기에서 노드 진입점까지, 노드에서 대상 사이트까지 두 구간을 거칩니다. 노드를 바꾸면 여러 조건이 동시에 바뀌므로, 바꾼 뒤 빨라졌다는 사실만으로 원인을 확정할 수 없습니다. 노드는 그대로 둔 채 컴퓨터의 네트워크만 가정용 인터넷에서 휴대폰 핫스팟으로 바꾼 다음 같은 작업을 반복하는 것이 가장 효과적인 비교 방법입니다.

비교 결과	가능성이 높은 원인	다음 단계
가정용 인터넷은 느리고 핫스팟은 확연히 빠름	로컬 접속망 또는 노드 진입점까지의 경로	유선으로 다시 측정하고 진입 회선별로 비교
두 네트워크 모두 특정 노드만 느림	노드 용량 또는 노드 출구 경로	같은 지역의 다른 노드로 바꾸고 시간대 기록
다른 사이트는 정상인데 특정 사이트만 느림	대상 사이트의 속도 제한, CDN 또는 출구 구간의 통신사 연결	같은 사이트에서 지역을 바꿔 보고 서비스 상태 확인
같은 네트워크의 여러 기기에서 모두 느림	공용 네트워크 환경 또는 공유 회선	라우터 부하와 업로드 사용량 확인

패킷 손실은 중간 홉이 아니라 최종 목적지를 기준으로 확인

Windows에서는 아래 명령으로 공용 IP 하나에 대한 기본 연결 상태를 확인할 수 있습니다. 이 주소는 네트워크 테스트 대상일 뿐, 설정에 DNS로 입력하라는 뜻이 아니며 노드 경로를 나타내지도 않습니다. TUN이 켜져 있을 때 테스트 트래픽이 커널을 통과하는지는 라우팅과 ICMP 지원 여부에 따라 달라집니다. 직접 연결 상태를 기준으로 삼으려면 먼저 TUN을 일시 중지하고 시스템 라우팅이 복구됐는지 확인하세요.

ping -n 30 1.1.1.1
tracert -d 1.1.1.1

중간 라우터가 ICMP 응답을 제한할 수 있습니다. 특정 홉에서 시간 초과가 표시돼도 최종 목적지에 도달한다면 그 결과만으로 경로에서 패킷이 손실된다고 단정할 수 없습니다. 최종 목적지가 응답하지 않는다고 해서 웹사이트에 접속할 수 없는 것도 아닙니다. 업로드 대역폭을 모두 사용하면 다운로드 확인 패킷과 웹 요청이 대기할 수 있으므로, 업로드 작업을 잠시 멈추고 다시 측정하세요. 이런 문제는 대개 프록시 프로토콜을 바꿀 필요가 없습니다.

4. 3단계: 시스템 프록시, TUN, 앱 설정 간 충돌 확인

시스템 프록시와 TUN은 트래픽을 처리하는 방식이 다릅니다. 시스템 프록시는 주로 시스템 프록시 설정을 따르는 앱에 적용됩니다. TUN은 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리합니다. 둘을 함께 켰다고 반드시 충돌하는 것은 아니지만, 문제를 진단할 때는 한 가지 방식만 남겨야 트래픽이 어디로 흐르는지 확인하기 쉽습니다.

먼저 시스템 프록시만 테스트

다른 VPN 및 프록시 도구를 종료하고 현재 클라이언트의 TUN을 끈 뒤 시스템 프록시만 유지하세요.
Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열어 수동 프록시나 스크립트 설정이 의도한 값인지 확인하세요. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 → ‘세부사항’ → ‘프록시’로 이동해 다른 도구의 주소가 남아 있는지 확인합니다.
클라이언트가 실제로 사용하는 수신 포트를 확인하세요. 아래 예시는 로컬 HTTP 또는 mixed 포트 7890을 사용합니다. 흔히 볼 수 있는 예시 값일 뿐 모든 클라이언트의 기본 포트는 아닙니다.
명시적 프록시 요청 결과와 브라우저 결과를 비교하세요. Windows PowerShell에서는 이전 버전 환경의 curl 별칭과 동작이 달라질 수 있으므로 curl.exe를 사용하세요.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://www.example.com/

이 간단한 페이지는 요청이 완료되는지, 첫 바이트를 받기까지 비정상적으로 오래 걸리는지 확인하는 용도이며 최대 다운로드 대역폭을 측정하지는 않습니다. HTTP 프록시 요청에서 time_connect는 주로 로컬 프록시와 연결을 설정하는 시간을 나타내므로 원격 노드의 지연 시간으로 볼 수 없습니다. time_starttransfer에는 이후 협상과 서버 응답 대기 시간이 포함됩니다. macOS나 Linux에서는 curl을 사용하고 NUL을 /dev/null로 바꾸세요.

이어서 TUN만 따로 테스트

시스템 프록시를 끄고 TUN을 켠 다음 같은 노드와 대상 사이트를 유지해 새 연결을 만드세요. TUN에서만 느리다면 클라이언트 서비스 권한, 가상 인터페이스, 라우팅, 다른 VPN의 잔여 설정을 확인합니다. 명시적 프록시 요청은 빠른데 브라우저만 느리다면 노드를 다시 구입하기보다 브라우저 프록시 확장 프로그램, 보안 DNS, 캐시를 먼저 점검하세요.

게임, 음성 통화, 일부 동영상 연결은 UDP를 사용할 수 있습니다. HTTP 프록시 테스트에 성공해도 해당 TCP 요청이 동작한다는 뜻일 뿐 UDP 경로가 정상이라는 의미는 아닙니다. 앱 트래픽이 실제로 처리되는지, 노드 프로토콜이 해당 트래픽 전달을 지원하는지, 서버가 UDP를 허용하는지 확인하고 연결 기록에서 실제 트래픽도 점검하세요. 모든 UDP를 끄는 것을 일반적인 속도 개선 방법으로 삼지 마세요.

5. DNS와 MTU: 해당 증상이 있을 때만 조정

첫 접속이 느리다면 먼저 DNS 경로 확인

페이지를 처음 열 때는 느리지만 새로고침하면 정상이라면 로그에 DNS 조회 시간 초과가 반복되는지, DNS 상위 서버에 연결할 수 있는지 확인하세요. mihomo에서 fake-ip 모드를 사용할 때 가상 주소가 반환되는 것은 정상일 수 있습니다. 198.18.0.0/16 범위의 주소가 보인다는 이유만으로 DNS 오류라고 판단하지 마세요. 브라우저의 보안 DNS, 운영체제 DNS, 커널 DNS는 서로 다른 경로를 사용할 수 있으므로 실제 트래픽 처리 방식에 따라 확인해야 합니다.

정상 작동하는 DNS 설정을 기준으로 보존하고, 익숙하지 않은 상위 DNS 서버를 한꺼번에 여러 개 추가하지 마세요.
특히 프록시 연결에 필요한 도메인을 먼저 조회해야 하는 경우, 트래픽 분기 규칙으로 DNS 상위 서버에 순환 의존성이 생기지 않는지 확인하세요.
DNS 또는 fake-ip 설정을 바꾼 뒤에는 클라이언트 안내에 따라 설정을 다시 불러오고 기존 연결을 종료한 다음 테스트하세요. Windows에서는 ipconfig /flushdns로 시스템 DNS 캐시를 지울 수 있지만, 모든 앱과 커널의 캐시까지 삭제되지는 않습니다.

대용량 패킷이 멈추거나 TUN에서만 문제가 생길 때 MTU 확인

MTU는 링크에서 허용하는 최대 전송 단위입니다. 캡슐화 오버헤드가 있거나 경로 MTU 탐색이 차단되면 작은 요청은 성공해도 대용량 파일이나 일부 TLS 연결이 멈출 수 있습니다. 하지만 1500, 1480, 1400 중 어느 값도 모든 네트워크에 맞는 정답은 아니며, MTU를 낮춘다고 노드 대역폭이 자동으로 늘어나지도 않습니다.

Windows 명령 프롬프트에서 IPv4 단편화 금지 패킷을 테스트할 수 있습니다. 이더넷 MTU가 1500일 때 ICMP 데이터 1472바이트에 일반적인 IPv4 및 ICMP 헤더 28바이트를 더하면 총 1500바이트입니다. 테스트에 실패하면 비교를 위해 데이터 크기를 1400바이트로 바꿔 보세요.

ping -4 -f -l 1472 -n 4 1.1.1.1
ping -4 -f -l 1400 -n 4 1.1.1.1
netsh interface ipv4 show subinterfaces

대상에서 ICMP를 차단할 수 있으며, 두 ping 테스트가 프록시 터널의 실제 경로를 반영하지 않을 수도 있습니다. 따라서 결과는 참고 자료일 뿐입니다. TUN에서 대용량 패킷 문제가 실제로 확인됐다면 현재 TUN MTU 값을 먼저 기록하고, 현재 클라이언트나 mihomo의 TUN 설정에서만 일시적으로 1400으로 바꾼 뒤 관련 연결을 재시작해 테스트하세요. 개선되지 않으면 원래 값으로 되돌립니다. 모든 물리 네트워크 어댑터의 설정을 함께 바꾸지 말고, 이 IPv4 테스트 공식을 IPv6에 적용하지 마세요.

6. 결과를 정리하고 무작정 설정을 바꾸지 않기

세 단계로 비교하면 대개 문제 범위를 좁힐 수 있습니다. 서비스 제공업체나 클라이언트 관리자가 확인할 수 있도록 단순히 ‘속도가 느립니다’라고 하기보다 재현 가능한 절차를 전달하세요. 다음 항목을 정리하면 충분한 기록을 만들 수 있습니다.

실행 환경: 운영체제 버전, 클라이언트 버전, 커널 이름과 버전, TUN 사용 여부, 실제 수신 포트
테스트 조건: 날짜와 시간대, 가정용 인터넷 또는 휴대폰 핫스팟, 대상 서비스, 단일 연결 또는 다중 연결
비교 수치: 같은 노드에서 세 번 측정한 지속 속도의 중앙값, 노드 변경 전후 결과, 첫 바이트 대기 시간
트래픽 경로: 적용된 규칙, 최종 정책 노드, 실패 요청 전후의 필요한 로그. 인증 정보는 삭제하세요.

현재 클라이언트나 커널이 오랫동안 유지 관리되지 않았다면 구독과 사용자 지정 규칙을 백업한 뒤 시스템에 맞는 유지 관리 중인 클라이언트를 선택하세요. 이전 후에는 최소 설정으로 먼저 연결을 확인하고 오버라이드, 규칙, TUN 설정을 하나씩 추가해 이전 환경의 충돌을 그대로 가져오지 않도록 하세요. 기본 사용법은 Clash 설정 가이드를 참고하고, 연결 실패나 속도 측정 시간 초과는 지연 시간 측정 관련 자주 묻는 질문에서 확인하세요.