Clash 속도 느릴 때 원인 찾기: 노드·경로·로컬 설정 3단계 진단법

왜 무작정 노드를 바꾸지 말고 단계별로 진단해야 할까

속도 저하는 거의 모든 우회 프록시 도구에서 흔히 제기되는 불만이지만, '느리다'는 현상 뒤에는 세 가지 전혀 다른 원인이 숨어 있습니다. 노드 자체의 품질, 기기에서 노드까지 이어지는 전송 경로, 그리고 로컬 클라이언트 설정입니다. 많은 사용자가 끊김이 발생하면 바로 노드를 바꾸는데, 3~5개를 바꿔도 여전히 느리면 '구독이 문제'라고 단정 짓곤 합니다. 하지만 실제로는 로컬 DNS 설정이나 규칙 매칭 오류에 계속 걸려 있어서 노드와는 전혀 관계가 없는 경우가 많습니다.

무작정 노드를 바꾸는 데는 두 가지 비용이 따릅니다. 하나는 배율이 높은 유료 노드의 트래픽을 낭비하는 것이고, 다른 하나는 진짜 원인을 가려버려서 같은 문제가 다시 재발한다는 점입니다. 단계별 진단의 장점은 각 단계마다 명확한 테스트 방법과 판단 기준이 있다는 것입니다. 한 단계를 마칠 때마다 하나의 원인군을 배제하거나 특정할 수 있어, 10분 정도면 범위를 구체적인 지점까지 좁힐 수 있습니다.

1단계: 노드 품질 점검

노드 품질은 프록시 서버 자체의 응답 속도, 부하 상태, 회선 대역폭을 의미하며 로컬 설정과는 무관합니다. 이 단계는 검증하기 가장 쉬우면서도 가장 먼저 배제해야 할 단계입니다.

1. 색상보다 지연 수치를 확인하세요

대부분의 Clash 클라이언트(Clash Meta 커널인 mihomo 기반 클라이언트 포함)는 노드 목록에 지연 시간 테스트 버튼이 있어, 클릭하면 각 노드의 응답 시간(ms)이 표시됩니다. 대략적인 판단 기준은 다음과 같습니다.

지연 시간 테스트는 '연결 응답 시간'을 측정하는 것이지 다운로드 속도를 측정하는 것은 아니지만, 둘은 밀접한 상관관계가 있습니다. 지연이 지속적으로 높은 노드는 다운로드 속도도 좋을 수 없습니다. 반대로 지연은 정상인데 실제 다운로드가 여전히 느리다면 문제는 이 단계에 있지 않으므로, 2단계로 넘어가 계속 확인하세요.

2. 지역이 다른 노드 2~3개로 교차 검증하기

노드 하나만 테스트하고 결론 내리지 마세요. 같은 구독에서 서버 위치와 지역이 다른 노드 2~3개를 골라 각각 속도를 테스트합니다. 전부 느리다면 경로나 로컬 설정 문제일 가능성이 크고, 특정 노드만 느리다면 그 노드 자체의 부하 문제이므로 정상인 노드로 바꾸면 되며 더 이상 진단할 필요가 없습니다.

3. 트래픽 배율과 남은 사용량 확인하기

일부 구독 서비스는 배율이 높은 노드에 속도 제한을 걸거나, 계정 트래픽이 한도에 가까워지면 일시적으로 속도를 낮추기도 합니다. 이런 경우 지연 시간 테스트는 정상으로 나오지만 실제 다운로드 속도는 뚜렷하게 제한됩니다. 클라이언트의 구독 정보에서 남은 트래픽과 만료일을 확인해, 요금제 차원의 제한을 배제하세요.

2단계: 전송 경로 점검

경로란 데이터가 로컬 기기에서 출발해 로컬 네트워크, 통신사 백본망을 거쳐 프록시 서버까지 도달하는 전체 경로를 뜻합니다. 이 단계의 문제는 대체로 프록시 소프트웨어로 해결할 수 있는 부분이 아니지만, 테스트를 통해 원인을 확인하면 소프트웨어를 잘못 탓하는 일을 줄일 수 있습니다.

1. 기준선을 위해 직접 연결 속도부터 측정하기

먼저 프록시를 끄고 로컬 네트워크의 다운로드 속도를 직접 측정해 보세요(통신사 속도 측정 도구를 쓰거나 큰 파일을 다운로드하며 시간을 재도 됩니다). 직접 연결 자체가 느리다면 로컬 인터넷이나 Wi-Fi 신호 문제이며 Clash와는 전혀 무관하므로, 먼저 네트워크 환경 자체를 해결해야 합니다.

2. mtr 또는 tracert로 경로 홉 수 확인하기

직접 연결은 정상인데 프록시를 켜면 느려진다면, 경로 추적 도구로 데이터 패킷이 지나는 지점을 살펴보세요. Windows에서는 명령 프롬프트에 다음을 입력합니다.

tracert 대상서버IP

macOS 또는 Linux에서는 다음을 사용합니다.

traceroute 대상서버IP

두 가지를 확인하세요. 어느 홉부터 지연이 급증하는지, 그리고 패킷 손실(별표 *로 표시)이 대량 발생하는지입니다. 해외 출구 구간의 지연이 서서히 증가하는 것은 물리적 거리에 따른 정상적인 감쇠입니다. 반면 특정 홉에서 갑자기 수백 밀리초로 튀어 오르고 이후 계속 높은 수준을 유지한다면, 해당 홉의 통신사 노드에서 혼잡이 발생하고 있다는 뜻입니다.

3. 전송 프로토콜을 바꿔보기

같은 프록시 서비스라도 대부분 여러 프로토콜의 노드를 제공합니다(예: Shadowsocks, VMess, Trojan, Hysteria2 등). 프로토콜마다 통신사 회선과의 호환성이 다르며, 특히 일부 회선은 UDP 트래픽에 뚜렷한 속도 제한을 걸어둡니다. Hysteria2처럼 QUIC/UDP 기반 프로토콜을 사용 중이라면 특정 네트워크 환경에서 TCP 계열 프로토콜보다 더 쉽게 제한에 걸릴 수 있습니다. 구독에 같은 지역이지만 프로토콜이 다른 노드가 있다면 교차 비교해 보세요.

4. 통신사 피크 시간대 유의하기

저녁 20시~23시는 국내 인터넷 출구 대역폭이 가장 혼잡한 시간대입니다. 같은 노드가 낮에는 빠른데 저녁에는 절반으로 뚝 떨어지는 현상은 흔합니다. 이는 경로 차원의 정상적인 변동이며 설정 오류가 아니므로, 다른 시간대에 다시 테스트해서 확인해 보세요.

3단계: 로컬 클라이언트 설정 점검

앞선 두 단계에서 원인이 배제됐다면, 남은 원인은 대체로 클라이언트 자체 설정에 몰려 있습니다. 이 단계의 문제는 눈에 잘 드러나지 않지만, 찾아내면 대부분 '스위치 하나만 바꾸면 해결'되는 가벼운 수정으로 끝나는 경우가 많습니다.

1. DNS가 이중 해석을 거치고 있는지 확인하기

enhanced-mode 설정이 잘못됐거나 시스템 DNS와 Clash 내부 DNS 설정이 충돌하면, 같은 도메인이 두 번 해석되거나 로컬 ISP DNS로 되돌아가면서 불필요한 지연이 늘어날 수 있습니다. 설정 파일의 dns 항목을 확인해 nameserver가 응답이 빠른 해석 서버를 가리키는지 확인하고, fallback이 빈번하게 트리거되지 않는지 확인하세요(자주 발생한다면 주 해석 노드가 불안정하다는 신호입니다).

2. 규칙 모드에서 잘못된 정책 그룹에 매칭되는지 확인하기

규칙(Rule) 모드에서는 규칙 매칭 오류로 요청이 속도 제한이 걸린 노드로 분류되거나, 직접 연결로 나갔다가 통신사에서 속도 제한을 받을 수 있습니다. 이 경우 겉으로는 '페이지 로딩이 느림'으로 나타나지만 클라이언트에는 노드가 정상으로 표시됩니다. 클라이언트의 연결 상세 패널(보통 '로그' 또는 '연결' 탭)을 열어 실제 접속한 도메인이 어느 규칙에 매칭됐는지, 어느 정책 그룹으로 흘렀는지 확인하고 예상과 다른 규칙에 걸리지 않았는지 점검하세요.

3. TUN 모드와 시스템 프록시를 동시에 켜서 충돌시키지 않기

TUN 모드는 네트워크 카드 계층에서 전체 트래픽을 가로채는 방식이고, 시스템 프록시는 애플리케이션 계층에서 HTTP/SOCKS 프록시를 설정하는 방식입니다. 둘의 원리가 다르기 때문에 클라이언트가 TUN 모드를 켠 상태에서 시스템 프록시도 함께 수동 설정하면 일부 트래픽이 중복 처리되거나 우회 경로를 타면서 원인을 알기 힘든 끊김이 발생할 수 있습니다. 둘 중 하나만 활성화하도록 확인하고, 보통 TUN 모드만 켜두면 전체 트래픽을 커버할 수 있습니다.

4. 혼합 포트와 로컬 방화벽

로컬 방화벽, 보안 소프트웨어, 또는 가상 네트워크 카드 드라이버 이상으로 Clash가 리스닝하는 혼합 포트(기본값 7890)에 대해 심층 패킷 검사가 걸려 전달 효율이 떨어지는 경우가 있습니다. 서드파티 보안 소프트웨어를 잠시 종료하고 테스트해 보세요. 속도가 눈에 띄게 회복된다면 해당 소프트웨어의 트래픽 검사가 전달 경로를 지연시키고 있다는 뜻이므로, Clash 관련 프로세스를 예외 목록에 추가해야 합니다.

5. 클라이언트 버전이 너무 오래됐을 때

오래된 버전의 클라이언트는 커널 전달 효율에 대한 최적화가 적용되지 않았을 수 있습니다. 특히 커널이 Clash Meta / mihomo 메인 라인 업데이트를 오랫동안 따라가지 못했다면 전달 효율이 눈에 띄게 떨어집니다. 클라이언트와 커널이 최근 배포된 버전인지 확인하고, 너무 오래됐다면 현재 유지보수 중인 버전으로 업데이트하는 것을 권장합니다.

10분 진단 흐름 요약

1. 노드 지연 시간 테스트를 열어 지역이 다른 노드 2~3개를 교차 비교하며 노드 자체 문제인지 확인합니다.
2. 프록시를 끄고 직접 연결 속도를 기준선으로 측정해 로컬 인터넷 문제를 배제합니다.
3. 경로 추적으로 이상 홉이 있는지 확인해 경로 혼잡 여부를 판단합니다.
4. DNS 설정, 규칙 매칭, TUN과 시스템 프록시의 충돌 여부를 확인해 로컬 설정을 점검합니다.
5. 보안 소프트웨어를 잠시 끄고 전달 효율을 테스트해 검사 기능에 의해 차단·지연되는지 확인합니다.

잘못 끼웠다면 한 단계 되돌아가면 됩니다. 3단계 진단은 본질적으로 범위를 단계적으로 좁혀가는 과정이므로, 모든 세부 사항을 한 번에 외울 필요는 없습니다. 순서대로 각 단계의 테스트를 진행하면 답은 대부분 중간에 드러납니다.