Clash 속도 저하 원인 찾기: 노드·회선·로컬 설정 3단계 진단법

왜 3단계로 나눠 진단해야 할까: 무작정 노드부터 바꾸지 말기

속도가 느려지는 것은 Clash / Clash Meta(mihomo 커널) 사용 중 가장 흔한 문제 제보지만, "느려졌다"는 현상 뒤에는 세 단계 중 어느 곳에서든 문제가 생겼을 수 있습니다 — 노드 자체 품질 저하, 국경 간 전송 회선의 혼잡, 또는 로컬 클라이언트 설정의 부적절함. 많은 사용자의 첫 반응은 노드를 바꾸는 것이지만, 몇 개를 바꿔도 여전히 느리면 구독(서브스크립션) 자체에 문제가 있는지 의심하게 되고, 계속 시도해도 근본 원인을 찾지 못하는 경우가 많습니다. 이는 단계별 검증을 하지 않았기 때문입니다: 세 단계의 문제는 겉으로 보이는 증상이 거의 동일합니다("끊김", "느림", "로딩 안 됨" 등)하지만 진단 방법은 완전히 다르므로, 뒤섞어 테스트하면 시간만 낭비하게 됩니다.

이 글은 먼 곳부터 가까운 곳 순서로 단계를 나눠 설명합니다: 먼저 노드 자체가 건강한지(지연, 패킷 손실, 배율) 확인하고, 다음으로 국경 간 회선이 혼잡한지(피크 시간대, 출구 대역폭) 확인하며, 마지막으로 로컬 설정이 발목을 잡고 있는지(DNS, 규칙 매칭, TUN 모드와 시스템 프록시 충돌) 점검합니다. 각 단계마다 곧바로 실행할 수 있는 판단 방법을 제시하며, "노드를 한번 바꿔보세요" 같은 뭉뚱그린 조언은 하지 않습니다.

1단계: 노드 품질 — 지연, 패킷 손실, 배율

노드 품질은 가장 검증하기 쉽고 가장 먼저 확인해야 할 단계입니다. 클라이언트 화면에서 노드 오른쪽에 표시되는 지연 값은 정책 그룹의 url-test 측정 결과로, 로컬 기기에서 노드를 거쳐 테스트 주소까지의 왕복 시간을 반영합니다. 수치 자체는 참고용일 뿐이며, 더 중요한 것은 값이 안정적인지 여부입니다.

지연 외에도 패킷 손실률과 트래픽 배율에 주목해야 합니다. 패킷 손실률이 높으면 TCP 재전송이 반복되어 웹페이지 로딩이 끊기거나 영상 버퍼링이 빈번해지지만, 지연 값 자체는 그리 높지 않을 수 있습니다 — 이 때문에 지연 수치만 보고 "노드가 괜찮다"고 판단했다가 실제로는 매우 끊기는 경우가 많습니다. 트래픽 배율은 실제로 체감하는 가용 대역폭에 직접 영향을 미칩니다. 같은 공유 노드라도 배율이 낮으면 대개 대역폭을 점유하는 사용자가 적다는 뜻이며, 피크 시간대에는 그 차이가 더 두드러집니다.

노드가 안정적인지 검증하는 간단한 방법은 url-test 정책 그룹의 측정 간격을 짧게 조정하고, 테스트 주소를 목표 서비스와 더 가까운 곳으로 바꾼 다음, 순간적인 값만 보지 말고 몇 분간 지속적으로 지연 곡선을 관찰하는 것입니다:

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies: [노드A, 노드B, 노드C]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

tolerance는 허용 오차 범위를 나타내며, 이 범위 안의 지연 차이는 전환을 유발하지 않아 노드가 임계값 근처에서 빈번하게 흔들리는 것을 막을 수 있습니다. interval은 측정 빈도를 제어하는데, 너무 짧으면 노드 측 부담이 커지고 너무 길면 지연 변화를 즉시 반영하지 못하므로, 일반적으로 180~300초 사이로 설정하는 것이 적절합니다.

2단계: 국제 회선과 피크 시간대 혼잡

특정 노드 자체의 지연이 낮고 패킷 손실이 적다는 것을 확인했는데도 특정 시간대에 눈에 띄게 느려진다면, 문제는 노드 서버 자체가 아니라 국경 간 전송 회선에 있을 가능성이 큽니다. 국제 출구 대역폭은 한정된 자원이며, 저녁 20:00~23:00 같은 피크 시간대에는 같은 그룹의 사용자들이 한꺼번에 접속하면서 국제 출구 전체 대역폭 압박이 겹쳐, 노드 서버 자체 부하가 정상이더라도 실제 체감 속도는 떨어지게 됩니다.

이런 문제를 파악하는 방법은 간단합니다. 같은 노드로 여러 시간대에 반복해서 속도를 측정하고 결과를 기록하세요. 지연과 속도가 명확한 "낮과 밤의 패턴"을 보인다면 — 예를 들어 새벽에는 정상이고 저녁에 집중적으로 느려진다면 — 회선 혼잡 문제로 판단할 수 있습니다. 반대로 하루 중 어느 시간대든 계속 느리다면, 1단계로 돌아가 노드 자체를 다시 점검해야 할 가능성이 큽니다.

또한 "중계 경유"와 "착지 직결" 두 가지 회선 구조를 구분해야 합니다. 전자는 트래픽이 중간 노드를 거쳐 한 번 더 전달되고, 후자는 착지 서버가 목표 사이트로 직접 접속합니다. 중계 구조는 홉 수가 늘어나는 동시에 추가 혼잡 지점이 생길 수 있으므로, 같은 지역에 여러 노드를 선택할 수 있다면 각각 테스트해서 홉 수가 적고 지연 곡선이 더 안정적인 노드를 일상용으로 삼고, 지연이 높지만 가끔 급하게 필요한 노드는 대안으로 남겨두는 것이 좋습니다. 이때는 정책 그룹의 수동 선택 모드로 구분해서 사용하고, 자동 측정에 의존해 둘 사이를 오가며 전환하지 않는 것이 낫습니다.

3단계: 로컬 설정 — DNS, 규칙 매칭, 모드 충돌

노드와 회선 두 단계를 모두 배제했는데도 속도 문제가 여전하다면, 로컬 클라이언트 설정 문제일 가능성이 큽니다. 이 단계는 가장 쉽게 간과되지만, 가장 흔한 "은근한 속도 저하" 원인이기도 합니다.

DNS 해석 방식

DNS 설정이 적절하지 않으면 도메인 해석이 잘못된 경로를 거치게 되어, 프록시 규칙 자체가 정확하더라도 접속 경험이 느려지거나 "일부 사이트는 열리는데 일부는 안 열리는" 상황이 발생할 수 있습니다. mihomo 커널은 fake-ip 모드와 독립적인 DNS 서버를 함께 사용하도록 권장하여, 해석 요청이 로컬 통신사 DNS로 유출되거나 오염되는 것을 막습니다:

dns:
  enable: true
  ipv6: false
  default-nameserver: [223.5.5.5, 119.29.29.29]
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - "https://doh.pub/dns-query"
    - "https://dns.alidns.com/dns-query"
  fallback:
    - "https://1.1.1.1/dns-query"

redir-host 모드를 사용 중이라면 해석 결과가 로컬 네트워크 환경에 좌우되어 통신사 DNS 오염이나 하이재킹의 영향을 받기 쉬우므로, 특별한 이유가 없다면 fake-ip로 전환하는 것을 권장합니다.

규칙 매칭과 정책 그룹 선택

규칙 파일의 순서가 잘못되었거나 규칙 세트가 제때 갱신되지 않으면, 원래 프록시를 거쳐야 할 트래픽이 DIRECT 직결로 판정되거나, 반대로 로컬 서비스 트래픽까지 프록시 그룹으로 들어가 버리는 경우가 생깁니다. 두 경우 모두 "속도가 느려졌다"는 증상으로 나타납니다. 클라이언트의 연결 로그나 트래픽 패널에서 특정 연결이 실제로 어떤 규칙에 매칭되어 어떤 정책 그룹을 탔는지 확인해, 주관적인 느낌이 아니라 실제 매칭 결과로 예상과 일치하는지 판단하는 것이 좋습니다.

TUN 모드와 시스템 프록시 충돌

TUN 모드와 시스템 프록시를 동시에 켜거나, TUN 모드에서 MTU를 지나치게 크게 설정해 패킷 조각 재전송이 발생하면 속도가 눈에 띄게 떨어질 수 있습니다. 일반적으로는 둘 중 하나만 선택하는 것을 권장합니다: 브라우저 외 애플리케이션까지 포함해 전체 트래픽을 처리해야 할 때는 TUN 모드를, 브라우저 등 일부 애플리케이션만 프록시를 태우면 될 때는 시스템 프록시를 사용해, 두 가지 처리 방식이 겹쳐 경로가 혼란스러워지는 것을 피하세요.

3단계 진단 흐름 정리와 자가 점검 체크리스트

위의 세 단계를 하나로 이어 실제로 따라 할 수 있는 진단 순서로 만들면, 문제를 찾는 시간을 크게 줄이고 노드만 계속 바꾸다가 근본 원인을 찾지 못하는 상황을 피할 수 있습니다.

1. 먼저 노드 확인

   같은 지역의 노드 2~3개를 번갈아 사용하며 지연 곡선과 패킷 손실 상황을 지속적으로 관찰해, 노드 자체가 만료되었거나 부하가 과도한지 배제합니다.

2. 다음으로 회선 확인

   이미 건강하다고 확인된 노드로 피크 시간대와 비피크 시간대에 각각 한 번씩 측정해, 명확한 시간대별 속도 저하 패턴이 있는지 판단합니다.

3. 마지막으로 로컬 설정 확인

   DNS 모드가 fake-ip인지 확인하고, 연결 로그에서 규칙 매칭이 예상과 일치하는지 살펴보며, TUN 모드와 시스템 프록시가 동시에 켜져 있지 않은지 확인합니다.

4. 결과를 기록한 뒤 결론 내리기

   세 단계의 테스트 결과를 각각 기록해 두고, 그것을 바탕으로 노드를 바꿀지, 사용 시간대를 바꿀지, 로컬 설정을 조정할지 결정하세요. 여러 곳을 동시에 바꾸면 어느 조치가 실제로 효과가 있었는지 알 수 없게 됩니다.

반복적으로 나타나는 "속도 저하" 문제는 대부분 이 세 단계 중 하나로 귀결되며, 흔히 단일 원인이 아니라 여러 단계가 겹쳐 체감 지연이 증폭되는 경우가 많습니다. 순서대로 하나씩 검증하는 것이 감으로 노드를 계속 바꾸는 것보다 시간을 절약하고, 구독 제공자나 커뮤니티에 구체적인 현상을 설명하기도 훨씬 쉬워집니다.