Clash 속도 느림 해결법: 노드·회선·로컬 설정 3단계 점검

왜 "속도 느림"은 단계별로 점검해야 할까

"Clash가 느리다"는 말은 매우 뭉뚱그린 표현으로, 그 뒤에는 완전히 다른 원인이 숨어 있을 수 있습니다. 노드 자체의 대역폭 부족, 해외 회선의 피크 시간대 혼잡, 프로토콜 암호화 오버헤드가 높은 경우, 혹은 순수하게 로컬 네트워크 스택 설정 오류(예: MTU 설정 오류로 인한 분할·재전송)일 수도 있습니다. 나눠서 점검하지 않으면 "노드를 10개나 바꿔봐도 다 느리니 클라이언트 자체가 문제"라는 잘못된 판단을 내리기 쉽습니다—실제로는 노드를 바꿔도 진짜 병목을 전혀 우회하지 못한 것일 수 있습니다.

이 글은 노드 → 회선 → 로컬 설정 순서로 3단계 점검을 진행하며, 각 단계마다 반복 실행 가능하고 결과를 비교할 수 있는 테스트 동작을 제시합니다. 3단계는 순차적인 관계입니다. 먼저 노드에 문제가 없는지 확인하고, 다음으로 회선에 문제가 없는지 확인한 뒤, 마지막에야 로컬 설정을 살펴봐야 합니다—순서를 거꾸로 하면 잘못된 지점에서 계속 헛수고를 반복하게 됩니다.

1단계: 노드 자체—지연, 패킷 손실, 대역폭 테스트

노드는 링크의 첫 번째 관문이자, 가장 오판하기 쉬운 부분입니다. 많은 사람이 속도를 측정할 때 클라이언트 화면의 "지연" 숫자만 보는데, 이 숫자는 보통 TCP 핸드셰이크나 간단한 프로브 패킷의 왕복 시간만 반영할 뿐 실제 처리량을 대표하지 않습니다. 지연이 매우 낮은 노드라도 대역폭이 여러 사용자와 공유되어 다운로드 속도가 형편없을 수 있습니다.

먼저 지연과 패킷 손실의 기본 점검을 진행하세요

클라이언트의 노드 목록에서 동일 그룹 노드에 대해 지연 테스트를 실행하고 값을 기록한 뒤, 의심되는 특정 노드로 전환하여 시스템 내장 도구로 연속 ping을 실행하고 눈에 띄는 패킷 손실이나 지연 흔들림이 있는지 관찰합니다:

ping -c 20 8.8.8.8
# packet loss와 avg 지연에 주목하세요. 손실률이 5%를 넘으면 보통 링크가 불안정하다는 뜻입니다

패킷 손실률이 높고 지연이 크게 흔들린다면(예: 80ms와 400ms 사이를 오간다면) 기본적으로 문제가 노드나 그 상위 회선에 있다고 판단할 수 있으며, 로컬 설정 문제가 아닙니다.

실제 대역폭 속도도 별도로 측정하세요

지연이 정상이라고 해서 대역폭이 충분하다는 뜻은 아니므로 실제 다운로드 속도를 별도로 측정해야 합니다. 흔한 방법은 명령줄 도구로 고정 크기의 테스트 파일을 다운로드하고, 소요 시간을 속도로 환산하는 것입니다:

curl -o /dev/null -w "%{speed_download} bytes/s\n" http://speedtest.example/testfile

같은 측정 동작을 서로 다른 2~3개 노드에서 각각 실행해보세요. 결과 차이가 뚜렷하다면(예: 한 노드는 5MB/s, 다른 노드는 300KB/s에 불과하다면) 문제는 특정 노드의 대역폭 배분에 있는 것이므로, 성능이 더 나은 노드로 전환하면 해결되며 회선이나 로컬 설정까지 더 파고들 필요는 없습니다.

2단계: 회선과 프로토콜—피크 혼잡과 프로토콜 오버헤드

같은 노드 그룹이 낮에는 속도가 정상이지만 저녁 피크 시간대에 일제히 느려진다면, 대부분 해외 회선이나 착지 서버실이 혼잡 시간대에 대역폭이 분산되기 때문이며, 특정 노드가 고장 난 것이 아닙니다. 이런 경우의 확인 방법은 매우 간단합니다: 비피크 시간대에 동일한 측정 동작을 반복해보세요. 속도가 뚜렷하게 회복된다면 시간대별 혼잡임을 기본적으로 확인한 것이며, 설정 문제가 아닙니다—이 경우 노드를 바꾸거나 설정을 변경해도 소용이 없고, 피크가 지나가길 기다리거나 부하가 더 가벼운 회선을 선택하는 수밖에 없습니다.

프로토콜 종류에 따른 추가 오버헤드

대리 프로토콜마다 핸드셰이크 방식과 암호화 오버헤드가 다르므로, 네트워크 환경이 일반적인 조건에서는 프로토콜 선택 자체도 속도 차이를 유발할 수 있습니다. 예를 들어 TLS 계층으로 겹겹이 캡슐화하는 일부 프로토콜은 취약한 네트워크 환경에서 재전송 비용이 더 높은 반면, 더 경량화된 프로토콜은 오버헤드가 적지만 식별되어 속도 제한을 받기 더 쉬울 수도 있습니다. 프로토콜 계층의 문제가 의심된다면, 같은 착지 서버실에서 같은 시간대에 해당 서버실이 제공하는 서로 다른 프로토콜 노드(제공업체가 동시에 제공하는 경우)를 각각 테스트하여 속도 차이가 뚜렷한지 비교해볼 수 있습니다.

mihomo 코어에서의 분류 오버헤드

mihomo(Clash Meta) 코어를 사용할 때 규칙 세트 수가 지나치게 많거나 GeoIP/GeoSite 매칭 계층이 너무 깊으면, 각 연결마다 추가적인 판단 시간이 소모되며, 특히 규칙 세트가 합리적으로 정렬되지 않고 자주 쓰는 규칙이 목록 끝에 배치되어 있을 때 더 두드러집니다. 접속 빈도가 가장 높은 규칙(예: 직결 처리하는 국내 도메인)을 규칙 목록 앞쪽으로 옮겨 매칭 횟수를 줄이는 방법을 임시로 적용할 수 있습니다. 이는 회선과 프로토콜 계층 외의 소소한 최적화 포인트지만, 자주 방문하는 상황에서 체감 개선이 꽤 직접적입니다.

3단계: 로컬 설정—MTU, 분류 규칙, 시스템 프록시

앞 두 단계를 모두 점검했는데 문제를 발견하지 못했지만 모든 노드, 모든 시간대에 느리다면 문제는 로컬 네트워크 스택이나 클라이언트 설정에 있을 가능성이 큽니다. 이 단계는 노드 지연 테스트에서 드러나지 않기 때문에 가장 쉽게 놓치는 부분입니다.

TUN 모드에서 MTU 설정을 확인하세요

TUN 모드를 켜서 전역 트래픽을 인수할 때, MTU(최대 전송 단위) 설정이 실제 네트워크 카드와 맞지 않으면 큰 패킷이 강제로 분할되어 재조합 오버헤드가 추가되고, 지연이 높은 링크에서는 눈에 띄는 속도 저하나 간헐적인 끊김으로 나타납니다. 먼저 TUN의 MTU 값을 일반적인 1500으로 조정하거나 통신사 권장에 따라 1400 근처로 낮춰본 뒤 다시 속도를 측정해 비교해보세요:

tun:
  enable: true
  stack: system
  mtu: 1500

MTU를 조정한 후 속도가 뚜렷하게 개선되었다면 이전에 분할 문제가 실제로 존재했음을 의미하며, 변화가 없다면 이 요인은 배제하고 다음 단계로 넘어가면 됩니다.

분류 규칙이 트래픽을 우회시키고 있는지 확인하세요

일부 사용자 정의 규칙 세트 설정이 잘못되면 원래 직결해야 할 트래픽이 잘못 대리 노드로 분류되거나, 반대로 대리를 거쳐야 할 트래픽이 직결로 나가는 경우가 있으며, "특정 사이트는 느리고 다른 사이트는 정상"으로 나타납니다. 클라이언트의 연결 패널을 열어 현재 활성 연결이 실제로 매칭된 규칙과 아웃바운드 노드를 관찰해, 트래픽 흐름이 예상과 일치하는지 확인할 수 있습니다.

시스템 프록시와 브라우저 프록시가 중복 적용되고 있는지 확인하세요

시스템 프록시와 브라우저 확장 프록시를 동시에 켜두었거나, 브라우저에 수동으로 프록시 주소를 입력한 상태에서 TUN 모드까지 인수하고 있다면, 트래픽이 두 번 프록시를 거치며 불필요한 지연이 누적될 수 있습니다. 프록시 접속 방식은 하나만 유지하는 것을 권장합니다: TUN 모드로 전역 인수를 하든, 시스템 프록시를 쓰든 둘 중 하나만 쓰고, 브라우저 확장에 수동 설정한 프록시 주소를 함께 겹치지 마세요.

1. TUN 모드의 MTU 값이 본체 네트워크 카드 설정과 일치하는지 확인합니다.
2. 연결 패널로 자주 방문하는 도메인의 실제 분류 경로가 예상과 맞는지 대조합니다.
3. 브라우저 확장에 수동으로 입력된 프록시 주소를 끄고, 시스템 프록시나 TUN 모드와 중복되지 않도록 합니다.
4. 클라이언트를 재시작하고 대역폭 속도를 다시 측정해 조정 사항이 적용되었는지 확인합니다.

흔한 오판 사례 대조표

점검 과정에서 가장 흔히 나타나는 오판은 두 가지입니다. 하나는 "노드를 바꿔도 해결되지 않으면 소프트웨어 문제"라는 것, 다른 하나는 "지연 숫자가 낮으면 속도가 빠르다는 뜻"이라는 것입니다. 앞의 3단계 사고방식과 결합해 아래 몇 가지 대표 현상을 대조하면 빠르게 위치를 파악할 수 있습니다:

• 모든 노드를 바꿔도 느리고 시간대를 바꿔도 나아지지 않음 → 로컬 MTU와 프록시 중복 설정을 우선 확인
• 낮에는 정상, 저녁에 일제히 느려짐 → 회선 피크 혼잡, 대기하거나 부하가 더 가벼운 회선으로 전환
• 특정 노드만 계속 느리고 다른 노드는 정상 → 해당 노드의 대역폭이나 상위 회선 자체에 문제
• 지연 숫자는 매우 낮지만 다운로드 속도가 형편없음 → 지연 테스트는 핸드셰이크 속도만 반영하므로 별도로 대역폭을 측정해야 함

이 네 가지 현상을 한 번 대조해보면 대체로 10분 안에 문제가 어느 단계에 있는지 파악할 수 있어, 헛되이 노드를 계속 바꾸거나 클라이언트를 재설치하는 일을 피할 수 있습니다.