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

먼저 ‘속도 저하’를 측정 가능한 문제로 나누기

Clash 화면에 표시되는 지연 시간, 웹 페이지 로딩 시간, 파일 다운로드 속도는 서로 다른 지표입니다. 지연 시간 측정은 보통 작은 HTTP 리소스 하나를 요청해 연결 설정과 응답에 걸리는 시간을 확인합니다. 다운로드 속도는 대상 서버의 대역폭, 국제 회선, TCP 혼잡 제어, 프로토콜 오버헤드, 로컬 무선 네트워크의 영향을 함께 받습니다. 노드에 68ms가 표시된다고 해서 대역폭을 반드시 모두 활용할 수 있는 것은 아니며, 145ms인 노드라고 해서 동영상이 반드시 끊기는 것도 아닙니다.

점검하기 전에 변수를 고정하세요. 노드를 바꾸고 DNS를 수정하면서 동시에 TUN을 켠 뒤 한 번의 측정 결과로 결론을 내리지 마세요. 먼저 현재 네트워크, 프록시 모드, 노드 이름, 테스트 시간을 기록한 다음 ‘직접 연결 기준값—단일 노드 지연 시간—단일 연결 다운로드—다중 연결 다운로드’ 순서로 테스트하는 것이 좋습니다. 각 항목은 최소 3회 측정하고 최고값이 아닌 중앙값을 사용하세요.

재현 가능한 기준 데이터 만들기

Clash의 시스템 프록시와 TUN 모드를 잠시 끄고 같은 기기에서 직접 연결 속도를 측정하세요. 500Mbps 회선의 직접 연결 속도가 35Mbps에 그친다면 먼저 Wi-Fi, 랜 케이블 또는 통신사 네트워크를 점검해야 합니다.
Clash를 다시 켜고 ‘규칙’ 모드를 선택한 뒤 노드 하나를 고정하세요. 구성원이 자동으로 바뀌는 정책 그룹은 사용하지 마세요.
클라우드 드라이브 동기화, 시스템 업데이트, 게임 플랫폼 다운로드, 브라우저 백그라운드 동영상을 중지해 대역폭을 확보하세요.
09:00, 20:00, 23:00에 각각 테스트하세요. 저녁 피크 시간에 속도가 크게 떨어진다면 클라이언트 설정 오류보다 회선 혼잡일 가능성이 높습니다.
지연 시간, 다운로드 속도, 업로드 속도, 패킷 손실 양상, 대상 사이트를 기록하세요. 같은 테스트 대상에서 얻은 데이터만 서로 비교할 수 있습니다.

테스트 항목	예시 결과	주로 판단하는 항목
직접 연결 다운로드	468 Mbps	로컬 접속 네트워크의 정상 여부
노드 지연 시간	82 / 86 / 80 ms	연결 안정성과 기본 왕복 시간
프록시 단일 연결 다운로드	6.8 MB/s	단일 연결의 회선 품질
프록시 다중 연결 다운로드	22.4 MB/s	노드 총 대역폭과 동시 연결 처리 능력

1단계: 노드 품질과 프로토콜 오버헤드 점검

기준값을 확인했다면 먼저 가장 쉽게 교체할 수 있는 노드 계층을 점검하세요. 구독의 지역명은 단순한 라벨일 뿐이므로 ‘홍콩 01’이나 ‘일본 02’만으로는 진입 지점, 출구 통신사, 저녁 피크 시간대의 용량을 알 수 없습니다. 실제로 유용한 자료는 연속 측정 결과, 시간대별 성능, 해당 노드로 대상 사이트에 접속할 때 거치는 실제 경로입니다.

지연 시간은 최저값보다 안정성을 확인하기

클라이언트의 프록시 또는 정책 화면에서 지연 시간을 측정할 때는 3~5회 연속으로 테스트하세요. 결과가 75, 79, 81ms라면 42, 180, 시간 초과, 96ms가 나온 노드보다 일반적으로 안정적입니다. 후자의 노드는 42ms가 한 번 나왔더라도 실제 사용 중 재전송이나 연결 끊김이 자주 발생할 수 있습니다. 테스트 URL도 결과에 영향을 주므로 비교하는 동안 계속 바꾸지 말고 클라이언트 기본 주소나 작은 파일을 안정적으로 반환하는 HTTPS 주소를 고정해 사용하세요.

80ms 미만: 웹 페이지, 메신저, 지연 시간에 민감한 상호작용에 대체로 적합하지만 대역폭은 별도로 확인해야 합니다.
80~180ms: 국제 연결에서 흔한 범위입니다. 동영상과 다운로드가 원활한지는 주로 회선 안정성에 달려 있습니다.
250ms 초과: 웹 페이지의 첫 응답, 원격 터미널, 실시간 작업이 눈에 띄게 느려질 수 있습니다.
시간 초과가 잦음: 단순히 ‘지연 시간이 높다’기보다 노드 또는 테스트 대상에 도달할 수 없거나 경로가 불안정한 상태로 우선 판단하세요.

배율은 트래픽 과금에 영향을 줄 뿐, 속도를 직접 의미하지 않습니다

노드 이름의 ‘0.5×’, ‘1×’, ‘2×’는 보통 구독 서비스의 트래픽 과금 배율을 뜻합니다. 1GB를 다운로드하면 2× 노드는 사용량에 2GB로 계산될 수 있지만, 배율 자체가 더 빠른 속도를 보장하지는 않습니다. 고배율 노드가 더 비싼 회선을 의미하는 경우도 있고 단순한 리소스 분류 방식일 수도 있으므로, 최종 판단은 같은 시간과 대상에서 측정한 실제 결과를 기준으로 해야 합니다.

프로토콜과 암호화는 CPU를 사용합니다

최신 데스크톱 프로세서에서는 일반적인 프록시 프로토콜의 처리 오버헤드가 보통 첫 번째 병목은 아닙니다. 하지만 구형 라우터, 저전력 미니 PC, 보급형 Android 기기는 고속 전송 중 단일 코어가 최대치에 도달할 수 있습니다. 속도 측정 중 시스템 작업 관리자나 활성 상태 보기를 열어 확인하세요. mihomo, Clash 또는 클라이언트 코어가 CPU 코어 하나의 사용률 상한에 계속 가까이 붙고 속도가 더 이상 증가하지 않는다면 기기 성능, 프로토콜 매개변수, 암호화 오버헤드를 점검해야 합니다.

중복 실행 중인 프록시 코어를 종료하고 현재 클라이언트만 프록시 포트를 수신 대기하는지 확인하세요.
데스크톱에서는 현재 클라이언트가 지원하는 안정 버전의 mihomo 코어를 우선 사용하고, 출처가 불분명한 오래된 코어 파일을 함께 사용하지 마세요.
라우터에서 실행 중이라면 같은 구독을 데스크톱 클라이언트에 가져와 다시 테스트하세요. 데스크톱은 빠르고 라우터만 느리다면 병목은 대개 라우터의 CPU, 메모리 또는 네트워크 인터페이스에 있습니다.
속도 측정을 위해 구독에서 내려온 프로토콜 필드, 예를 들어 전송 계층, 서버 이름, Reality 매개변수를 임의로 수정하지 마세요. 이 값은 서버 측 설정과 일치해야 합니다.

2단계: 진입·출구 경로와 저녁 피크 회선 혼잡 판단

노드 자체를 사용할 수 있다고 해서 현재 통신사에서 노드 진입 지점까지의 경로가 항상 원활한 것은 아닙니다. 가정용 회선에서 프록시 진입 지점까지, 진입 지점에서 출구까지, 출구에서 대상 사이트까지는 서로 다른 세 구간입니다. 어느 한 구간이라도 혼잡하면 지연 시간은 정상인데 다운로드 속도만 낮거나, 낮에는 정상인데 밤에 크게 느려지는 현상이 나타날 수 있습니다.

시간대와 네트워크를 교차 테스트해 혼잡 위치 찾기

가장 효과적인 방법은 수십 개의 노드를 계속 바꾸는 것이 아니라 소규모 대조 테스트를 하는 것입니다. 같은 지역의 노드 2개와 다른 지역의 노드 2개를 선택해 동일한 테스트 대상에서 결과를 기록하세요. 그런 다음 컴퓨터를 가정용 Wi-Fi에서 휴대폰 핫스팟으로 바꾸고 같은 노드를 다시 측정합니다. 가정용 회선에서는 3MB/s인데 휴대폰 핫스팟에서는 14MB/s라면 로컬 통신사와 진입 지점 사이의 경로 문제일 가능성이 큽니다. 두 접속 네트워크 모두 느리다면 노드 용량이나 출구 품질을 계속 확인해야 합니다.

현상	가능성이 높은 원인	다음 단계
낮에는 18MB/s, 저녁에는 2MB/s	저녁 피크 시간대의 회선 또는 노드 용량 혼잡	진입 회선을 바꾸거나 한산한 시간에 재측정
지연 시간은 안정적이지만 단일 연결은 느리고 다중 연결은 빠름	단일 연결 제한 또는 국제 구간 패킷 손실	회선을 바꾸고 실제 애플리케이션에서 테스트
모든 노드가 동시에 느려짐	로컬 네트워크, 구독 진입 지점 또는 상위 네트워크 장애	직접 연결과 휴대폰 핫스팟 테스트
특정 대상 사이트 하나만 느림	대상 사이트의 출구, 분할 라우팅 또는 CDN 경로	규칙 적중 여부와 출구 지역 확인

지역 간 거리가 유일한 기준은 아닙니다

물리적으로 가까우면 대체로 지연 시간을 줄이는 데 유리하지만 회선 품질에 따라 결과가 달라질 수 있습니다. 상하이 사용자가 홍콩 노드에 연결한다고 해서 항상 도쿄 노드보다 빠른 것은 아닙니다. 특정 도쿄 회선이 더 안정적인 통신사 연동을 제공한다면 저녁 피크 시간대 성능이 더 좋을 수도 있습니다. 지역을 선택할 때는 대상 서비스의 CDN 라우팅과 접속 제한도 고려해야 합니다. 소프트웨어 저장소 다운로드, 동영상 재생, 원격 근무에 최적인 노드는 서로 다를 수 있으므로 모든 트래픽을 하나의 노드에 계속 몰아넣기보다 용도별 정책 그룹을 만드는 편이 좋습니다.

3단계: 분할 라우팅 규칙, 프록시 포트, TUN 모드 확인

노드와 회선에 뚜렷한 이상이 없다면 로컬 설정을 점검하세요. 흔한 문제는 프록시 코어가 ‘속도 제한’을 하는 것이 아니라, 대상 트래픽이 예상한 정책을 따르지 않거나 애플리케이션이 시스템 프록시를 우회하거나 여러 프록시 프로그램이 서로 설정을 덮어쓰거나 TUN과 보안 소프트웨어가 패킷을 동시에 처리하는 경우입니다.

먼저 연결 기록에서 규칙 적중 여부 확인

클라이언트의 ‘연결’ 또는 ‘로그’ 화면을 열고 속도가 이상한 웹 사이트에 접속한 뒤 도메인, 규칙 이름, 최종 정책을 확인하세요. 클라이언트마다 메뉴 이름은 조금씩 다르지만, 일반적인 경로는 ‘연결’ → 요청 선택 → ‘규칙’ 및 ‘프록시 체인’ 확인 또는 ‘로그’ → 수준을 Info로 변경 → 요청 재실행입니다. 대상 사이트가 DIRECT에 적중했다면 프록시를 거치지 않은 것입니다. 자동 정책 그룹에 적중했다면 해당 그룹에서 현재 어떤 노드를 선택했는지도 확인해야 합니다.

Clash 규칙은 위에서 아래 순서로 매칭되며, 먼저 적중한 규칙이 적용됩니다. 지나치게 광범위한 규칙을 앞에 배치하면 뒤의 정밀한 규칙을 덮어쓸 수 있습니다. 예를 들어 로컬 네트워크와 중국 본토 규칙을 프록시 규칙보다 앞에 두는 것은 대체로 합리적이지만, 사용자 정의 DOMAIN-SUFFIX의 위치가 잘못되면 대상 도메인이 잘못된 정책으로 라우팅될 수 있습니다.

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-KEYWORD,example,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

규칙을 수정한 뒤에는 설정을 다시 불러오고 연결 화면에서 기존 연결을 닫은 다음 테스트하세요. 기존 TCP 연결은 정책이 바뀌어도 새 노드로 자동 이동하지 않는 경우가 많습니다. 브라우저의 장기 연결, HTTP/2, HTTP/3 때문에 이전 경로가 계속 유지될 수 있으므로 필요하면 브라우저를 완전히 종료한 뒤 다시 실행하세요.

포트가 중복 전달되지 않는지 확인

일반적인 로컬 포트는 HTTP 프록시 7890, SOCKS5 프록시 7891이며, 두 기능을 합친 mixed-port: 7890도 사용됩니다. 실제 포트는 현재 설정을 기준으로 확인하세요. 브라우저 확장 프로그램, 다운로드 도구, 터미널 환경 변수는 현재 수신 대기 중인 포트를 가리켜야 합니다. ‘애플리케이션이 이전 클라이언트로 프록시를 보내고, 이전 클라이언트가 다시 새 클라이언트로 전달하는’ 연쇄 프록시를 피하세요.

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

클라이언트에서 ‘설정’ → ‘환경 설정’으로 이동해 혼합 포트, 시스템 프록시, 로컬 네트워크 연결 옵션을 찾을 수 있습니다. 메뉴 경로가 다르면 현재 설정의 mixed-port를 직접 확인하세요. 다른 기기의 접속이 실제로 필요할 때만 로컬 네트워크 연결을 활성화하고, 운영체제 방화벽 규칙과 수신 대기 주소가 서로 일치하는지 확인하세요.

더 많은 트래픽을 가로채야 할 때만 TUN 모드 활성화

시스템 프록시는 운영체제의 프록시 설정을 따르는 애플리케이션에 주로 영향을 줍니다. 일부 게임, 명령줄 프로그램, 자체 네트워크 스택을 사용하는 소프트웨어는 이를 우회합니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 가로채므로 ‘브라우저는 정상인데 다른 앱은 직접 연결되는’ 문제를 해결할 수 있지만, 노드 속도를 자동으로 높여 주지는 않습니다. 오히려 드라이버 충돌, 잘못된 라우팅, 부적절한 MTU, 중복 가로채기로 처리량이 낮아질 수 있습니다.

먼저 TUN을 끄고 시스템 프록시만 켠 상태에서 속도를 측정하세요. 그런 다음 시스템 프록시를 끄고 TUN만 켜서 다시 측정하면 두 경로를 구분하기 쉽습니다.
TUN을 켠 뒤 웹 페이지는 정상인데 대용량 파일 전송이 멈춘다면 MTU를 확인하세요. 일반적인 테스트 범위는 1280~1500이지만 접속 네트워크에 따라 단계적으로 조정해야 하며, 다른 사람의 값을 그대로 적용해서는 안 됩니다.
다른 VPN, 네트워크 가속기, 패킷 캡처 도구, 가상 네트워크 카드 소프트웨어를 잠시 종료해 라우팅 우선순위 충돌을 배제하세요.
TUN 설정을 수정한 뒤 코어를 재시작하고, 시스템 라우팅 테이블과 DNS 하이재킹 기능이 클라이언트 안내에 따라 적용되었는지 확인하세요.

DNS 설정: 느린 이름 해석, 오염, 잘못된 라우팅 해결

DNS는 대용량 파일 전송의 지속 속도를 보통 결정하지 않지만 첫 페이지 로딩 시간, CDN 주소 선택, 도메인 기반 분할 라우팅에는 영향을 줍니다. 대표적인 증상은 웹 사이트를 처음 열 때 수 초간 기다렸다가 새로 고침하면 빨라지는 경우, 같은 노드에서 도메인 접속은 느리지만 알고 있는 IP로 접속하면 정상인 경우, 연결 기록에 IP만 나타나고 도메인 규칙이 적중하지 않는 경우입니다.

시스템 DNS와 프록시 DNS가 충돌하지 않도록 하기

mihomo 코어를 사용할 때 DNS 설정에는 nameserver, proxy-server-nameserver, fallback, fake-ip 등이 포함될 수 있습니다. nameserver는 일반적인 조회에 사용되며, 프록시 서버의 도메인 자체는 먼저 사용 가능한 리졸버가 해석해야 합니다. 이 단계가 아직 연결되지 않은 프록시에 의존하면 DNS 조회 루프가 생길 수 있습니다. 구독에서 완전한 DNS 설정을 제공한다면 여러 공용 DNS를 한꺼번에 추가하기보다 먼저 원래 설정이 정상인지 확인하세요.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - 223.5.5.5

이 설정은 구조를 보여 주는 예시일 뿐 모든 구독 설정을 그대로 덮어쓰는 용도가 아닙니다. 네트워크가 IPv6를 지원하더라도 프록시 노드나 규칙이 IPv6를 제대로 처리하지 못하면 애플리케이션이 사용할 수 없는 주소를 먼저 시도하다가 시간 초과를 기다릴 수 있습니다. 점검 중에는 ipv6: false로 임시 설정해 비교할 수 있지만, 문제가 확인된 뒤에는 장기간 이 스위치에 의존하지 말고 실제 네트워크 환경에 따라 복원 여부를 결정하세요.

Fake-IP 모드에서 제외 항목 확인

fake-ip는 도메인에 예약 주소를 반환하고, 연결 단계에서 코어가 도메인을 복원해 규칙 매칭 능력을 높입니다. 로컬 네트워크 기기 검색, 프린터, 일부 게임 로그인, 실제 DNS 응답에 의존하는 애플리케이션은 제외 목록에 추가해야 할 수 있습니다. 특정 애플리케이션만 실행이 느리다면 먼저 로그에서 반복 DNS 조회, 연결 재시도, 로컬 네트워크 도메인의 프록시 처리 여부를 확인한 뒤 필요한 항목만 정확하게 제외하세요. 최상위 도메인 전체를 제외하는 것은 피해야 합니다.

로컬 기기와 네트워크: Wi-Fi, 브라우저, 백그라운드 작업 점검

모든 노드가 직접 연결 기준값에 미치지 못한다면 기기 계층으로 돌아가야 합니다. 혼잡한 환경의 2.4GHz Wi-Fi는 안정적인 처리량이 수십 Mbps에 그칠 수 있으며, 신호 막대가 가득해도 간섭이 적다는 뜻은 아닙니다. 가능하다면 랜 케이블 또는 5GHz·6GHz Wi-Fi로 비교 테스트하고 기기를 라우터 가까이 옮기세요. 랜 케이블에서 460Mbps가 나오는데 원래 위치의 Wi-Fi가 72Mbps라면 노드를 계속 바꿔도 문제가 해결되지 않습니다.

시스템 모니터링으로 병목 위치 확인

CPU: 프록시 코어의 단일 코어가 계속 최대 사용률에 도달하고 속도가 CPU 사용률에 맞춰 제한된다면 먼저 기기 성능과 프로토콜 처리를 점검하세요.
메모리: 시스템에서 메모리 스와핑이 자주 발생하면 브라우저, 다운로드 도구, 프록시 코어 모두 멈춤 현상이 나타날 수 있습니다.
디스크: 하드 디스크, 암호화 컨테이너, 실시간 동기화 폴더에 다운로드할 때 쓰기 속도가 병목이 될 수 있습니다.
백그라운드 트래픽: 운영체제 업데이트, 사진 백업, 게임 플랫폼이 업로드 대역폭을 모두 사용하면 다운로드 확인 패킷과 웹 응답도 느려질 수 있습니다.
브라우저 확장 프로그램: 프록시 확장 프로그램이 별도의 규칙이나 포트를 사용하면 시스템 프록시를 덮어쓸 수 있습니다. 새 브라우저 프로필로 한 번 비교 테스트를 진행해 보세요.

속도 측정 중에는 브라우저의 병렬 다운로드 실험 옵션과 타사 다운로드 확장 프로그램도 끄고 기본 설정으로 기준값을 확보하세요. 특정 브라우저만 느리고 시스템 다운로드 도구와 다른 브라우저는 정상이라면 문제는 대개 Clash 코어가 아니라 확장 프로그램, 캐시, HTTP/3, 브라우저 프록시 덮어쓰기에 있습니다.

증상별 10분 점검 순서

1분: 시스템 프록시와 TUN을 끄고 직접 연결 속도를 측정해 로컬 회선 기준값을 확인합니다.
2분: 다른 VPN, 프록시 클라이언트, 네트워크 가속 도구를 종료하고 Clash 클라이언트 하나만 남깁니다.
3분: 규칙 모드를 켜고 노드 하나를 고정한 뒤 지연 시간을 3회 연속 측정해 변동 폭을 기록합니다.
4분: 같은 대상에서 단일 연결과 다중 연결 다운로드를 테스트해 지연 시간 문제와 처리량 문제를 구분합니다.
5분: 다른 지역이면서 다른 진입 지점을 사용하는 노드로 다시 측정합니다. 같은 그룹의 인접 번호만 바꾸지 마세요.
6분: 연결 기록을 열어 대상 도메인에 적중한 규칙, 정책 그룹, 실제 노드를 확인합니다.
7분: 애플리케이션 프록시 포트와 mixed-port를 확인하고 이전 클라이언트가 남긴 프록시 설정을 정리합니다.
8분: 시스템 프록시와 TUN을 각각 테스트해 TUN 경로에서만 느려지는지 확인합니다.
9분: DNS 로그, IPv6, Fake-IP 제외 항목을 확인하고 첫 연결이 오래 기다리는지 살펴봅니다.
10분: 휴대폰 핫스팟 또는 유선 네트워크로 다시 측정해 통신사 경로 문제와 Wi-Fi 문제를 구분합니다.

최종 기록에는 최소한 테스트 날짜와 시간, 접속 네트워크, 클라이언트 코어, 프록시 모드, 노드, 지연 시간, 다운로드 속도, 규칙 적중 결과가 포함되어야 합니다. 낮에는 안정적이고 저녁에 느려진다면 회선을 우선 점검하세요. 모든 노드가 느리다면 로컬 네트워크와 설정을 먼저 확인하고, 특정 애플리케이션만 느리다면 해당 앱의 프록시 방식, DNS, 연결 프로토콜을 우선 점검하세요. 3단계 순서에 따라 대조 데이터를 남기는 것이 구독을 반복해서 갱신하거나 노드를 무작위로 바꾸는 것보다 실제 병목을 찾는 데 효과적입니다.