Clash 속도 저하 단계별 진단: 노드·회선·로컬 설정부터 구분하기

먼저 기준을 세우기: 지연 시간·대역폭·안정성은 서로 다른 지표입니다

Clash 패널의 지연 시간은 보통 한 번의 HTTP 연결 테스트에 걸린 시간입니다. 노드에 연결할 수 있는지와 연결에 대략 얼마나 걸리는지는 알려 주지만, 다운로드 속도를 직접 의미하지는 않습니다. 지연 시간이 85ms인 노드가 8Mbps밖에 내지 못할 수 있고, 160ms인 노드가 안정적으로 90Mbps를 낼 수도 있습니다. 전자는 응답은 빠르지만 출구 회선이 혼잡하고, 후자는 거리는 멀어도 대역폭이 충분한 경우입니다.

본격적으로 점검하기 전에 테스트 조건을 고정하세요. 노드를 바꾸면서 DNS를 수정하거나 TUN을 켜지 마세요. 변수가 동시에 바뀌면 속도가 회복되어도 어떤 설정이 영향을 주었는지 알 수 없습니다. 현재 설정을 먼저 보존하고 테스트 시간, 노드 이름, 프록시 모드, 다운로드 속도와 지연 시간을 기록하는 것이 좋습니다.

기준 데이터 네 가지

직접 연결 기준: Clash의 시스템 프록시와 TUN을 끄고 인터넷 서비스 제공업체의 속도 측정 페이지에 접속합니다. 직접 연결 속도가 20Mbps뿐이라면 프록시로 100Mbps를 안정적으로 채우기는 어렵습니다.
국내 다운로드 기준: 한국 내 미러에서 200MB 이상 파일을 다운로드하고 30초 후의 안정적인 속도를 확인해 Wi-Fi와 로컬 인터넷 회선 문제를 배제합니다.
노드 지연 시간: 같은 지역의 노드 3~5개를 각각 세 번 테스트합니다. 첫 번째 결과는 제외하고 두 번째와 세 번째 결과의 범위를 기록하세요.
프록시 처리량: 하나의 노드를 선택해 같은 테스트 파일을 다운로드하고 매번 최소 60초 동안 측정합니다. 시작 직후의 순간 속도를 안정적인 속도로 착각하지 않도록 합니다.

단위를 변환할 때 주의하세요. 속도 측정 페이지는 보통 Mbps, 다운로드 프로그램은 MB/s를 사용하며 둘은 약 8배 차이가 납니다. 80Mbps의 이론상 다운로드 속도는 약 10MB/s이고, 프로토콜·TCP·암호화 오버헤드를 고려하면 실제 8~9.5MB/s 정도는 정상 범위입니다.

1단계: 노드 자체가 느려진 것인지 확인하기

노드 계층의 문제는 프록시 서버 자체나 노드 제공업체의 출구에서 발생합니다. 같은 구독에서 일부 노드만 느리고 같은 지역의 다른 노드로 바꾸자마자 회복되거나, 해당 노드만 하루 종일 느린 것이 대표적인 증상입니다.

지연 시간만으로 정렬하지 마세요

자동 선택 정책 그룹은 보통 테스트 URL의 응답 시간을 기준으로 노드를 선택합니다. 연결 가능 여부를 확인하는 데는 적합하지만 지속적인 전송 성능은 측정하지 못합니다. 테스트 URL이 반환하는 데이터가 매우 작기 때문에 대역폭이 얼마 남지 않은 노드도 좋은 지연 시간 수치를 보일 수 있습니다.

세 번 측정한 결과를 예로 들어 보겠습니다. 노드 A의 지연 시간은 72, 81, 76ms이고 다운로드 속도는 2.1MB/s로 안정적입니다. 노드 B는 145, 151, 148ms이지만 다운로드 속도는 11.4MB/s로 안정적입니다. 웹 브라우징에서 첫 응답을 중시한다면 A가 더 빠르게 느껴질 수 있지만, 대용량 파일 다운로드나 고화질 동영상 시청에는 B가 더 적합합니다.

노드 과부하 확인하기

오전에는 정상인데 저녁 특정 시간대가 되면 낮 속도의 3분의 1 이하로 떨어집니다.
지연 시간이 약 100ms에서 주기적으로 500ms 이상으로 튀고 연결 재설정이 함께 발생합니다.
같은 지역의 여러 노드 중 하나만 지속적으로 느립니다.
짧은 연결의 웹페이지는 열리지만 수십 초 동안 다운로드하면 속도가 계속 떨어집니다.
다른 프로토콜이나 다른 진입점으로 바꾸면 회복되지만 로컬 설정은 전혀 바뀌지 않았습니다.

노드 이름의 ‘배율’은 보통 구독 트래픽 사용량을 계산하기 위한 값이며 속도 등급을 뜻하지 않습니다. 0.5배 노드가 반드시 느린 것은 아니고, 2배 노드라고 속도가 두 배가 되는 것도 아닙니다. 노드를 고를 때는 지연 시간, 안정적인 처리량, 패킷 손실, 트래픽 비용을 따로 확인해야 합니다.

노드 계층의 해결 방법

프록시 모드와 테스트 파일을 그대로 유지한 채 같은 지역의 다른 노드로 먼저 바꿔 봅니다.
자동 선택을 끄고 일시적으로 하나의 노드에 고정해 테스트 중 정책 그룹이 자동으로 전환되지 않게 합니다.
구독을 한 번 업데이트해 서비스 제공업체가 노드 주소, 포트, 프로토콜 매개변수를 변경하지 않았는지 확인합니다.
노드 하나만 비정상이라면 테스트 시간과 안정적인 속도를 기록한 뒤 노드 제공업체에 문의하세요.

2단계: 해외 회선과 통신사 경로가 혼잡한지 확인하기

회선 계층은 로컬 인터넷 회선과 프록시 노드 사이에 있습니다. 노드 서버 자체의 대역폭이 충분해도 현재 통신사에서 해당 진입점까지 경로가 우회되거나 패킷 손실이 발생하고, 저녁 피크 시간대에 혼잡하면 실제 속도는 떨어질 수 있습니다. 이때 같은 데이터센터의 여러 노드로 바꿔도 결과가 비슷한 경우가 많습니다.

회선 문제를 보여 주는 세 가지 특징

시간대와 관련됨: 평일 오전에는 70Mbps가 나오지만 20:00~23:00에는 10Mbps에 그칩니다.
통신사와 관련됨: 같은 노드가 가정용 인터넷에서는 느리지만 휴대폰 핫스팟으로 전환하면 뚜렷하게 회복됩니다.
지역과 관련됨: 특정 지역의 노드 그룹 전체가 느리고 다른 지역으로 바꾸면 처리량이 회복됩니다.

일반 ping은 ICMP 패킷을 사용하며 일부 서버는 ICMP의 우선순위를 낮추거나 응답하지 않습니다. 따라서 ‘ping 패킷 손실 100%’가 반드시 프록시를 사용할 수 없다는 뜻은 아니며, ‘ping 40ms’라고 해서 TCP나 UDP 전송이 원활하다는 보장도 없습니다. Clash의 HTTP 지연 시간 테스트가 실제 프록시 연결에 더 가깝지만, 여전히 소량의 트래픽만 확인하는 방식입니다.

비교 테스트로 통신사 경로 찾기

노드 하나와 200MB 이상의 다운로드 주소 하나를 고정하고 가정용 인터넷으로 60초간 테스트합니다.
노드는 그대로 둔 채 4G 또는 5G 휴대폰 핫스팟으로 전환해 다시 60초간 테스트합니다.
오전과 저녁 피크 시간대에 각각 반복하고 최고 속도가 아닌 안정적인 속도를 기록합니다.
핫스팟에서는 8MB/s가 나오는데 가정용 인터넷에서는 900KB/s뿐이라면, 로컬 Clash 설정은 보통 우선적으로 의심할 대상이 아닙니다.

같은 지역의 노드가 전반적으로 혼잡하다면 같은 그룹에서 하나씩 계속 시험하기보다 먼저 지역을 바꾸세요. 물리적으로 가까우면 지연 시간이 낮을 가능성이 있지만, 직선거리가 회선 품질보다 중요하지는 않습니다. 실제 선택은 현재 통신사 환경에서 측정한 결과를 기준으로 해야 합니다.

테스트 증상	가능성이 높은 계층	다음 단계
노드 하나만 느리고 다른 노드는 정상	노드 계층	같은 지역의 다른 노드로 고정
같은 지역 전체가 느리고 다른 지역에서 회복	회선 계층	진입 지역을 바꾸고 혼잡 시간대 피하기
가정용 인터넷은 느리지만 휴대폰 핫스팟은 정상	통신사 경로	네트워크를 재연결하거나 회선 진입점 변경
모든 노드가 느리지만 TUN을 끄면 회복	로컬 설정 계층	TUN, DNS, 보안 프로그램 확인

3단계: Clash 클라이언트와 로컬 네트워크 설정 점검하기

모든 노드가 동시에 느려지고 네트워크를 바꿔도 차이가 크지 않다면 로컬 계층을 확인해야 합니다. 주요 점검 대상은 시스템 프록시 포트, 프록시 모드, TUN, DNS, 브라우저 프록시 확장 프로그램, 보안 프로그램, 가상 네트워크 어댑터입니다. 점검할 때는 한 번에 하나만 변경하는 원칙을 지키세요.

먼저 프록시 모드와 포트 확인하기

Clash Verge Rev 2.3.x와 mihomo 1.19.x 조합의 화면을 예로 들면, 「설정」→「Clash 설정」에서 혼합 포트를 확인할 수 있습니다. 일반적으로 7890을 사용하지만 설정 파일에 따라 7897, 7899 또는 다른 포트일 수도 있습니다. 시스템 프록시가 가리키는 포트는 현재 코어가 수신 대기 중인 포트와 일치해야 합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

포트가 일치하지 않으면 대개 인터넷에 전혀 접속할 수 없습니다. 다만 브라우저 확장 프로그램, 시스템 프록시, 앱 내 프록시가 동시에 설정되어 있으면 요청이 우회되거나 프록시가 중복 적용되어 일부 프로그램만 비정상적으로 느려질 수도 있습니다. 테스트할 때는 하나의 진입점만 남기세요. 클라이언트의 시스템 프록시를 켜거나, 대상 앱이 HTTP/SOCKS 포트를 명확히 사용하도록 설정해야 합니다.

속도 측정 요청이 잘못된 정책 그룹으로 가지 않는지 확인하기

Rule 모드는 위에서부터 규칙을 대조하며 처음 일치한 뒤 멈춥니다. 속도 측정 사이트의 첫 페이지, 다운로드 도메인, 통계 도메인이 서로 다른 정책에 매칭될 수 있습니다. 다운로드 도메인이 DIRECT로 전송되고 페이지 자체는 프록시를 거친다면 측정 결과는 노드 속도를 나타내지 못합니다.

클라이언트의 연결 기록을 열고 현재 전송 중인 도메인을 찾아 해당 규칙과 정책 그룹을 확인하세요. 로그에서 요청이 어떤 규칙에 일치했고 최종적으로 어떤 노드를 사용했는지 확인할 수 있어야 합니다. 순수한 노드 테스트를 하려면 일시적으로 Global 모드로 전환해 하나의 노드에 고정하세요. 테스트가 끝나면 Rule로 돌아가 일상적인 트래픽이 모두 프록시를 통과하지 않게 합니다.

TUN 모드가 느릴 때 원인 나누기

TUN은 더 많은 시스템 트래픽을 가로채므로 시스템 프록시를 읽지 않는 프로그램이나 일부 게임에 적합합니다. 동시에 가상 네트워크 어댑터, 라우팅, DNS 처리 단계가 추가됩니다. 시스템 프록시 모드는 정상인데 TUN을 켠 뒤 눈에 띄게 느려진다면 다음 순서로 테스트하세요:

TUN을 끄고 시스템 프록시는 유지한 채 같은 다운로드 테스트를 반복합니다.
TUN을 다시 켜고 다른 VPN, 가속 프로그램, 이전 버전의 가상 네트워크 어댑터가 동시에 실행 중이지 않은지 확인합니다.
클라이언트의 TUN 설정에서 system과 mixed처럼 사용 가능한 스택을 전환하고, 전환할 때마다 코어를 재시작합니다.
MTU를 확인합니다. 기본값에서 일부 웹사이트가 멈춘다면 1500, 1400, 1280 순서로 테스트하고 변화를 기록하세요.
UDP를 사용하는 앱만 문제가 있다면 노드 프로토콜이 안정적인 UDP 포워딩을 지원하는지 별도로 확인합니다.

MTU를 감으로 지나치게 낮게 설정한 채 장기간 사용해서는 안 됩니다. 값이 너무 크면 조각화나 특정 연결의 멈춤이 발생할 수 있고, 너무 작으면 패킷 헤더 오버헤드가 커집니다. ‘웹페이지는 열리지만 대용량 파일 다운로드가 멈춤’, ‘일부 이미지가 계속 로드되지 않음’과 같은 증상이 있을 때만 단계별 테스트를 진행할 가치가 있습니다.

DNS가 느리다고 노드 대역폭이 느린 것은 아닙니다

DNS 문제는 주로 처음 페이지를 열 때와 도메인을 해석할 때 지연을 일으킵니다. 다운로드가 시작된 뒤에도 대역폭을 충분히 사용한다면 대체로 노드 처리량은 정상입니다. 새 웹사이트를 열 때마다 3~5초를 기다리지만 접속 후에는 빠르게 로드된다면 노드를 바꾸기보다 DNS를 먼저 점검하세요.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

이 설정은 문제 해결을 위한 예시일 뿐이며 현재 구독 설정을 그대로 덮어쓰면 안 됩니다. fake-ip을 사용할 때는 로컬 네트워크 장치, 기업 내부망, 실제 주소에 의존하는 일부 앱에 필터 규칙을 추가해야 할 수 있습니다. DNS 업스트림도 현재 네트워크에 맞춰 선택해야 하며, 국내 DNS 해석과 프록시 측 DNS 해석은 담당하는 역할이 다릅니다.

브라우저와 백그라운드 프로그램 간섭 배제하기

브라우저의 프록시 확장 프로그램을 끄고 확장 프로그램 포트와 시스템 프록시가 중복 적용되지 않게 합니다.
클라우드 드라이브 동기화, 시스템 업데이트, 게임 업데이트를 일시 중지하고 작업 관리자에서 실시간 네트워크 사용량을 확인합니다.
HTTP/3를 일시적으로 끈 뒤 다시 테스트해 UDP 경로 이상 여부를 확인하고, 검증이 끝나면 원래 설정으로 되돌립니다.
유선 연결 또는 5GHz·6GHz Wi-Fi를 사용하고 혼잡한 2.4GHz 대역에서는 속도를 측정하지 마세요.
로그 수준은 info로 유지하세요. debug를 장기간 사용하면 로그가 대량으로 생성되어 일상 설정으로 적합하지 않습니다.

증상에 따라 정해진 점검 절차 실행하기

실제로 문제를 처리할 때 모든 설정을 한 번씩 바꿀 필요는 없습니다. 증상에 따라 가장 짧은 경로를 먼저 선택한 뒤 비교 테스트로 결과를 확인하세요.

상황 1: 지연 시간은 짧지만 다운로드 속도가 수백 KB/s에 불과함

현재 노드에 고정하고 지연 시간 수치는 보지 않은 채 60초 동안 지속 다운로드를 테스트합니다.
같은 지역의 다른 노드로 전환합니다. 속도가 회복되면 기존 노드가 과부하 상태일 가능성이 높습니다.
같은 지역에서도 계속 느리다면 다른 지역으로 바꿔 회선 혼잡 여부를 판단합니다.
모든 지역에서 느리다면 TUN, 브라우저 확장 프로그램, 백그라운드 다운로드를 끄고 로컬 계층을 다시 측정합니다.

상황 2: 낮에는 빠르지만 저녁마다 느려짐

먼저 낮과 저녁 데이터를 한 세트로 보존하세요. 예를 들어 낮 11:00에는 78Mbps, 저녁 21:30에는 14Mbps인데 휴대폰 핫스팟에서는 같은 노드가 여전히 55Mbps라면, 이 결과는 Clash 클라이언트 오류보다 가정용 인터넷의 저녁 피크 시간대 경로 문제를 가리킵니다. 지역 진입점을 바꾸거나 회선 유형을 변경하고 혼잡 시간대를 피하는 방향으로 해결하세요.

상황 3: 브라우저는 빠르지만 게임이나 다운로드 프로그램은 느림

먼저 해당 프로그램이 시스템 프록시를 읽는지 확인하세요. 많은 게임과 일부 다운로드 프로그램은 HTTP 시스템 프록시를 사용하지 않으므로 TUN이나 앱 내 SOCKS5 설정이 필요합니다. 프로그램에서 수동 프록시를 지원한다면 127.0.0.1과 현재 SOCKS/mixed 포트(예: 7890)를 입력할 수 있습니다. 설정 후 연결 기록에서 트래픽이 실제로 mihomo로 들어가는지 확인하세요.

상황 4: Clash를 켠 뒤 국내 웹사이트도 느려짐

연결 기록을 확인해 국내 도메인이 DIRECT에 매칭되는지 확인하세요. 실수로 프록시 그룹에 들어갔다면 규칙 순서와 규칙 세트 업데이트 상태를 점검합니다. 문제를 숨기려고 모든 트래픽을 직접 연결로 바꾸지 말고, 잘못 매칭된 규칙을 찾아 규칙 세트가 정상적으로 로드되었는지 확인해야 합니다.

처리 우선순위: 위험이 낮은 작업부터 기본 매개변수까지

권장 순서는 구독 업데이트, 노드 고정, 같은 지역의 노드 교체, 지역 변경, 네트워크 비교, TUN 비교, 규칙과 포트 확인, 마지막으로 DNS와 MTU 조정입니다. 외부 변수에서 로컬 하위 계층으로 단계적으로 들어가는 순서라 되돌리기 쉽습니다.

각 테스트에서 최소 60초간의 안정적인 데이터를 보존하고 변경 후에는 코어를 재시작하세요. 설정 파일, DNS, TUN 스택, 노드를 동시에 바꾸면 결론을 재현할 수 없습니다. 점검이 끝나면 Rule 모드로 복원하고 임시 디버그 로그를 끄며 더 이상 사용하지 않는 수동 프록시 설정을 삭제하세요.

DIRECT, PROXY, 정책 그룹, 규칙 매칭, fake-ip의 관계를 더 이해하려면 용어집과 고급 설정을 확인하세요. 클라이언트를 처음 설정한다면 사용 가이드에 따라 구독, 시스템 프록시, 모드 선택을 다시 점검하세요.