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

1. 페이지 로딩 지연, 다운로드 속도 저하, 연결 끊김 구분하기

Clash에서 노드 지연 시간이 정상으로 표시되는데도 동영상이 계속 버퍼링될 수 있습니다. 노드 카드의 지연 시간은 보통 테스트 요청 한 번의 결과로, 당시 테스트 주소에 응답한 속도만 보여 줍니다. 실제 다운로드 속도는 노드 부하, 구간별 회선 상태, 대상 사이트의 속도 제한, 로컬 무선 네트워크에도 영향을 받습니다. 문제를 진단하기 전에 ‘느리다’는 현상을 반복해서 확인할 수 있도록 구체화하세요.

증상	우선 확인 항목	비교 방법
처음 열 때 오래 걸리지만, 이후에는 정상	DNS, 연결 설정, TLS 핸드셰이크	첫 방문과 재방문의 소요 시간 비교
페이지는 열리지만 대용량 파일 다운로드가 계속 느림	노드 처리량, 회선 혼잡, 서버 속도 제한	같은 파일을 다른 노드로, 다시 다른 네트워크로 비교
특정 앱만 느리거나 연결되지 않음	앱의 프록시 지원, 적용된 규칙, UDP 경로	해당 앱의 실제 연결 기록 확인
프록시를 쓰지 않는 사이트와 프록시 사이트 모두 느림	Wi-Fi, 라우터, 인터넷 회선, 백그라운드 트래픽	프록시를 잠시 끄고 로컬 네트워크 테스트

반복 가능한 기준 상태 만들기

클라우드 드라이브 동기화, 게임 다운로드, 시스템 업데이트를 일시 중지하고 기기와 위치, 대상 파일을 동일하게 유지하세요.
클라이언트의 ‘프록시’ 페이지에서 현재 정책 그룹을 펼친 다음 노드 하나를 직접 선택하세요. 테스트 중 자동 선택 그룹이 출구 노드를 바꾸지 않도록 합니다.
같은 대상을 연속으로 3회 테스트하고 시작 시각, 첫 화면이 뜰 때까지 걸린 시간, 안정적인 다운로드 속도를 매번 기록하세요. 대용량 파일은 약 30초간 속도를 관찰하되 데이터 사용량에 유의하세요.
한 번에 변수 하나만 바꾸고 ‘노드 → 네트워크 연결 방식 → 로컬 설정’ 순서로 비교하세요.

2. 노드 점검: 지연 시간이 짧아도 대역폭이 충분한 것은 아닙니다

먼저 클라이언트의 ‘프록시’ 페이지를 열어 현재 규칙에서 사용하는 정책 그룹을 찾고, 구체적인 노드를 선택하세요. Clash Verge Rev 같은 GUI 클라이언트에서는 보통 사이드바의 ‘프록시’, ‘연결’, ‘로그’에서 관련 정보를 확인할 수 있습니다. 다른 클라이언트는 메뉴 이름이 다를 수 있으니 현재 화면을 기준으로 확인하세요. 노드 카드만 보지 말고 ‘연결’ 페이지에서 테스트 요청이 실제로 방금 선택한 노드를 통과하는지도 확인해야 합니다.

세 가지 비교로 노드 문제 확인하기

같은 지역의 다른 노드로 바꾸기: 대상은 그대로 두고 같은 지역에 있는 노드 두 개를 비교하세요. 한 노드만 계속 느리다면 해당 노드의 부하나 속도 제한, 출구와 관련된 문제일 가능성이 큽니다.
다른 지역 출구로 바꾸기: 한 지역의 노드가 전반적으로 느리다가 다른 지역에서 정상으로 돌아온다면, 경로나 대상 사이트에서 해당 출구까지 연결되는 구간을 추가로 살펴볼 필요가 있습니다. 이것만으로 로컬 클라이언트 설정이 손상됐다고 볼 수는 없습니다.
대상 파일 바꾸기: 같은 노드로 다른 사이트는 정상적으로 이용되는데 특정 다운로드 소스만 느리다면 해당 사이트의 계정별 속도 제한, CDN 할당, 단일 연결 제한을 확인하세요.

전체 노드 속도 테스트를 연달아 실행한 직후 다운로드 속도를 비교하지 마세요. 일괄 테스트는 짧은 시간 동안 요청량을 늘릴 수 있고, 일부 클라이언트에서는 ‘지연 시간 테스트’와 ‘다운로드 속도 테스트’가 서로 다른 기능입니다. 먼저 테스트를 중단한 뒤 노드 하나씩 비교하세요. 구독에 트래픽 한도가 있다면 대규모 처리량 테스트만으로도 할당량이 소모될 수 있습니다.

구독 업데이트로 선택이 바뀌었는지 확인하기

‘구독’ 또는 ‘설정’ 페이지에서 현재 활성화된 Profile을 확인하고 마지막 업데이트 시각과 결과를 살펴보세요. 구독을 업데이트하면 노드 이름이나 그룹 구성원이 바뀔 수 있어 기존에 직접 선택한 노드가 더는 유효하지 않을 수 있습니다. ‘프록시’ 페이지로 돌아가 선택을 다시 확인한 다음 ‘연결’ 페이지에서 실제 경로를 검증하세요. 계정 토큰이 포함된 구독 URL을 속도 테스트를 위해 공개 사이트에 붙여 넣지 마세요.

3. 회선 점검: 네트워크와 시간대별 비교로 혼잡 확인하기

노드 이름에 표시된 지역은 보통 출구 위치를 뜻하며, 진입 경로나 통신사 간 구간, 중계 경로까지 모두 나타내지는 않습니다. 같은 출구라도 통신사 네트워크에 따라 속도가 달라질 수 있습니다. 노드를 바꿔도 결과가 일정하지 않다면 DNS를 바로 바꾸기보다 네트워크 연결 방식을 비교하세요.

먼저 무선 구간 확인하기: 노드는 그대로 두고 컴퓨터를 라우터 가까이 옮기거나, 가능하면 유선으로 연결하세요. 같은 대상의 속도가 회복되는지 확인해 약한 신호나 무선 간섭을 프록시 회선 혼잡으로 오해하지 않도록 합니다.
다음으로 모바일 핫스팟과 비교하기: 같은 컴퓨터를 핫스팟에 연결하고 노드와 대상을 그대로 유지하세요. 핫스팟에서 눈에 띄게 빨라지면 기존 인터넷 회선 경로나 라우터, 접속 네트워크 쪽 문제일 가능성이 큽니다. 핫스팟 테스트에는 모바일 데이터가 사용됩니다.
시간대별 차이 기록하기: 예를 들어 10:00, 20:30, 23:30에 같은 테스트를 실행하세요. 저녁에만 전반적으로 느려진다면 공유 회선의 부하 증가와 관련 있을 수 있지만, 시간대별 차이만으로 혼잡이 발생한 위치를 단정할 수는 없습니다.

일반적인 ping은 보통 ICMP를 사용하므로 시스템 HTTP 프록시를 켜도 자동으로 프록시 노드를 통과하지 않습니다. 따라서 ping 결과만으로 프록시 다운로드 속도를 판단할 수 없습니다. 경로 추적도 중간 장비가 응답하지 않을 수 있으므로 특정 홉에서 시간 초과가 발생했다는 사실만으로 패킷 손실을 입증할 수는 없습니다. 같은 기기와 대상에서 네트워크를 바꿔 앱 수준으로 비교하는 편이 더 유용합니다.

4. DNS 점검: 설정을 바꾸기 전에 이름 확인 경로부터 확인하기

DNS 문제는 처음 페이지를 열 때 오래 걸리거나 일부 도메인이 접속되지 않거나 적절하지 않은 CDN 주소로 연결되는 형태로 나타나는 경우가 많습니다. 연결이 완료된 뒤에도 계속 낮은 처리량을 보이는 현상은 대개 DNS만으로 설명하기 어렵습니다. 다운로드가 계속 진행되지만 속도가 낮다면 먼저 노드와 회선을 비교하세요.

서로 다른 세 곳의 DNS 설정 확인하기

시스템 DNS: 클라이언트가 가로채지 않는 DNS 조회에 영향을 줍니다. Windows에서는 터미널에서 ipconfig /all을 실행해 현재 네트워크 어댑터의 DNS 서버를 확인할 수 있습니다.
코어 DNS: 현재 설정의 DNS 섹션을 열어 dns.enable, enhanced-mode, 상위 DNS 주소를 확인하세요. mihomo를 사용하는 클라이언트는 오버라이드로 최종 설정을 생성할 수도 있으므로 구독 원본 파일뿐 아니라 실제 실행 중인 설정도 확인해야 합니다.
브라우저 보안 DNS: 브라우저가 암호화 DNS를 별도로 사용할 수 있습니다. Chrome에서는 보통 ‘설정’ → ‘개인 정보 보호 및 보안’ → ‘보안’ → ‘보안 DNS 사용’에서 확인할 수 있습니다. 테스트할 때 기존 값을 기록하고 잠시 꺼서 비교한 뒤, 필요하면 원래대로 복원하세요.

fake-ip를 사용 중이라면 앱에 합성 주소가 보이는 것은 해당 모드가 정상적으로 동작하는 방식입니다. 주소가 공인 IP가 아니라는 이유만으로 DNS 오류라고 판단하지 마세요. 반대로 브라우저가 별도의 DNS를 사용하거나 앱에 이전 주소가 캐시되어 있거나 도메인이 가로채기 대상에서 제외되어 있으면 규칙이 예상과 다르게 적용될 수 있습니다.

설정을 바꾸기 전에 백업하고 한 번에 한 항목만 조정하세요. 구독 관리 클라이언트에서는 다음 업데이트 때 변경 사항이 덮어써지지 않도록 지원되는 오버라이드 기능을 우선 사용하세요. 상위 DNS 서버로 가는 경로도 이용 가능해야 합니다. 현재 프록시를 거쳐야만 접속할 수 있는 주소로 무작정 바꾸면 문제 진단이 더 복잡해질 수 있습니다. 구체적인 필드는 사용 중인 코어의 문서를 따르고, mihomo 설정을 오래된 모든 Clash 코어에 그대로 적용하지 마세요.

캐시를 비운 뒤 다시 비교하기

Windows에서 DNS를 바꾼 뒤 명령 프롬프트에서 아래 명령을 실행하고 테스트 앱을 완전히 종료한 다음 다시 여세요. 이 명령은 시스템 DNS 캐시만 비웁니다. 브라우저의 전체 캐시를 삭제하거나 회선 대역폭을 높이지는 않습니다.

ipconfig /flushdns

5. 규칙 점검: 실제 출구와 연결 모드 확인하기

클라이언트의 ‘연결’ 페이지를 열고 대상 사이트에 다시 접속한 뒤, 도메인으로 새 연결을 필터링해 적용된 규칙과 정책 그룹, 최종 노드를 확인하세요. Clash 규칙 기반 라우팅은 보통 위에서 아래 순서로 일치 항목을 찾습니다. 앞부분의 범위가 지나치게 넓은 규칙 때문에 원래 직접 연결되어야 할 서비스가 원격 노드를 경유하거나, 프록시를 사용해야 할 서비스가 직접 연결될 수 있습니다.

현재 모드가 Rule인지 확인하고 대상 연결에 적용된 규칙과 출구를 기록하세요.
잠시 Global로 전환하고 전역 정책 그룹에서 같은 테스트 노드를 선택한 뒤 동일한 대상에 접속하세요.
Global 모드에서는 정상인데 규칙 모드에서 문제가 생긴다면 분기 규칙과 그룹 선택을 집중적으로 확인하세요. 두 모드 모두 느리다면 노드, 경로, 대상 사이트를 다시 점검하세요.
테스트가 끝나면 Rule로 되돌려 로컬 서비스나 국내 업무 트래픽이 계속 우회하지 않도록 하세요.

아래는 규칙 순서를 간단히 보여 주는 예시입니다. ‘구체적인 도메인 규칙을 앞에, 기본 규칙은 뒤에 둔다’는 점만 설명합니다. 여기의 PROXY는 실제 설정에 존재하는 정책 그룹이어야 합니다. 이 내용으로 구독 설정 전체를 대체하지 마세요.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

노드나 규칙을 바꾼 뒤에도 기존의 장시간 연결은 이전 출구를 계속 사용할 수 있습니다. 다운로드를 잠시 멈췄다가 다시 시작하거나 ‘연결’ 페이지에서 대상 연결만 종료한 뒤 새 연결을 확인하세요. 모든 연결을 닫으면 회의나 파일 전송 같은 작업도 끊기므로 매번 기본 조치로 사용하지 않는 것이 좋습니다.

6. 로컬 트래픽 가로채기: 시스템 프록시, TUN, 앱 프로토콜

시스템 프록시는 시스템 프록시 설정을 따르는 앱에서 주로 사용되며 모든 프로그램의 트래픽을 자동으로 처리하지는 않습니다. TUN은 가상 네트워크 인터페이스를 통해 트래픽을 가로채며, 적용 범위는 라우팅과 권한, 제외 설정, 코어 구현에 따라 달라집니다. TUN은 대역폭을 높이는 스위치가 아닙니다. 브라우저가 이미 시스템 프록시를 제대로 통과한다면 TUN을 켜는 것만으로 노드 혼잡이 해결되지는 않습니다.

명시적 프록시로 테스트해 트래픽 가로채기 문제 분리하기

먼저 클라이언트의 ‘설정’에서 포트 설정이나 실행 설정의 mixed-port를 찾으세요. 아래 명령은 혼합 포트가 7890이라고 가정합니다. 실제 포트가 7897이나 다른 값이라면 반드시 바꿔야 합니다. Windows에서는 curl.exe, macOS와 Linux에서는 curl을 사용하세요. 예시는 공개 테스트 도메인에만 접속하며 대용량 파일 대역폭을 측정하지 않습니다.

curl --proxy http://127.0.0.1:7890 -o /dev/null -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Windows에서는 위 명령의 curl을 curl.exe로 바꾸고 /dev/null을 NUL로 바꾸세요. 표시되는 시간은 요청 시작 시점부터 누적된 시간입니다. 로컬 프록시를 사용하면 time_connect는 주로 로컬 프록시에 연결하는 데 걸린 시간을 나타내므로 노드 왕복 지연 시간으로 볼 수 없습니다. first_byte에는 대상 서버의 처리 시간도 포함됩니다.

명시적 프록시는 정상인데 앱은 느림: 앱이 시스템 프록시를 사용하는지, 자체 프록시 주소가 설정되어 있는지, 새 요청이 ‘연결’ 페이지에 표시되는지 확인하세요.
TUN에서만 문제가 발생함: 서비스 모드나 관리자 권한, 라우팅 충돌, DNS 가로채기 상태를 확인하세요. 먼저 클라이언트 관련 설정을 기본값으로 되돌린 뒤 항목별로 비교하세요.
동영상이나 실시간 앱에서만 문제가 발생함: 일부 앱은 QUIC이나 다른 UDP 프로토콜을 사용합니다. HTTP 프록시 테스트가 정상이어도 UDP 경로가 정상이라는 뜻은 아닙니다. 노드와 클라이언트가 해당 트래픽을 지원하고 허용하는지 확인하세요.

처음부터 MTU를 무작위로 바꾸거나 IPv6를 끄거나 DNS 설정 전체를 교체하지 마세요. 특정 네트워크에서 큰 패킷이 멈추거나 특정 주소 유형이 계속 실패하는 등 반복해서 확인할 수 있는 근거가 있을 때만 해당 항목을 더 살펴보세요. 기기 성능이 의심된다면 작업 관리자나 활성 상태 보기에서 다운로드 중 코어 프로세스가 논리 코어 하나를 계속 점유하는지, 라우터가 동시에 많은 연결을 처리하는지 확인하세요.

7. 점검 기록을 남기고 근거에 따라 다음 단계 결정하기

한 차례 점검이 끝나면 조건을 알 수 없는 속도 테스트 스크린샷 수십 장보다 문제를 재현할 수 있는 최소한의 조합을 남기세요. 아래 항목만 기록해도 문제 범위를 판단하고 구독 서비스 제공자나 클라이언트 유지관리자에게 상황을 설명하는 데 도움이 됩니다.

환경: 운영체제, 클라이언트 이름, 클라이언트와 코어 버전. ‘정보’ 메뉴나 시작 로그에서 실제 값을 복사하세요.
경로: 유선 인터넷 또는 핫스팟, 테스트 시각, 노드 식별자, 대상 도메인. 계정 정보는 공개하지 마세요.
설정: Rule 또는 Global, 시스템 프록시 또는 TUN, 대상에 적용된 규칙과 최종 출구.
결과: 각 테스트 그룹의 3회 실행에서 기록한 대기 시간과 안정적인 속도, 노드나 네트워크를 바꾼 뒤 개선됐는지 여부.

로그를 제출해야 한다면 로그 레벨을 일시적으로 높여 한 번 재현한 뒤 평소 설정으로 되돌리세요. 공유하기 전에 구독 토큰, 노드 비밀번호, 개인 IP, 접속 기록을 가리세요. 기본 조작 방법은 Clash 설정 매뉴얼의 프록시 모드, 규칙 분기, TUN 항목을 참고하세요. 첫 연결을 아직 완료하지 않았다면 속도를 비교하기 전에 사용 설명서에 따라 설정이 활성화됐는지 확인하세요.