Clash 속도 저하 점검 체크리스트: 노드, 회선, 로컬 설정 단계별 진단

속도 저하는 프록시 도구를 사용할 때 가장 자주 접하는 문제지만, "느리다"는 현상 뒤에는 서로 완전히 다른 세 가지 원인이 숨어 있을 수 있습니다. 노드 자체의 품질, 노드와 로컬 사이의 국제 회선 상태, 그리고 로컬 클라이언트의 세부 설정입니다. 많은 사람이 가장 먼저 노드를 바꾸지만 몇 번을 바꿔도 문제가 그대로인 경우가 많은데, 사실은 단계별로 점검하지 않고 시행착오만 반복한 것입니다. 이 글에서는 점검 과정을 세 단계로 나누고 구체적인 절차를 함께 제시하여, 운에 의존하지 않고 문제의 원인을 정확히 찾아낼 수 있도록 돕습니다.

1단계: 노드 품질 자체의 문제

노드 품질은 가장 기본적인 단계이면서 동시에 가장 오판하기 쉬운 부분입니다. 같은 구독 안의 노드라도 품질 차이가 매우 클 수 있습니다. 어떤 노드는 대역폭이 넉넉하고 지연이 안정적이지만, 어떤 노드는 공유 출구로서 피크 시간대에 심하게 혼잡합니다. 노드에 문제가 있는지 판단할 때는 클라이언트에 표시되는 지연 수치만 볼 것이 아니라 실제 처리량도 함께 살펴봐야 합니다.

지연 테스트를 올바르게 읽는 법

대부분의 Clash 클라이언트는 프록시 목록에 지연 테스트 버튼을 제공하며, 클릭하면 각 노드 옆에 밀리초 단위 수치가 표시됩니다. 이 수치는 클라이언트에서 노드 서버까지 왕복 요청 시간을 측정한 것으로, 보통 특정 테스트 주소(예: www.gstatic.com/generate_204)에 대한 HTTP 요청을 기반으로 합니다. 지연이 낮으면 연결이 빠르게 성립된다는 뜻이지만 **대역폭이 크다는 의미는 아닙니다**. 지연 80ms인 노드가 지연 40ms인 노드보다 더 빠를 수도 있습니다. 대역폭과 지연은 서로 독립적인 지표이기 때문입니다.

• 지연이 계속 300ms를 넘고 테스트가 자주 타임아웃된다면: 노드 회선 품질이 좋지 않거나 서버 부하가 과도할 가능성이 크므로 교체를 권장합니다.
• 지연은 정상인데 다운로드 속도가 오르지 않는다면: 노드 대역폭이 제한되어 있거나, 공유 출구가 피크 시간대에 많은 사용자에게 점유되고 있을 수 있습니다.
• 지연 변동이 매우 크다면(같은 노드를 여러 번 테스트했을 때 수백 밀리초씩 차이가 난다면): 회선이 불안정한 상태로, 평소에는 사용 가능해도 영상 통화나 대용량 다운로드 시 속도 저하나 끊김이 자주 발생합니다.

실제 다운로드 속도 테스트로 검증하기

지연 테스트는 1차 선별에만 쓸 수 있으며, 노드가 실제로 높은 부하를 견딜 수 있는지 판단하려면 실제 다운로드 속도 테스트가 필요합니다. 브라우저로 속도 측정 사이트에 접속하거나, 명령줄 도구로 용량이 명확한 파일을 다운로드하여 걸린 시간을 MB/s로 환산할 수 있습니다. 테스트할 때는 변수를 통제해야 합니다. 동시에 한 노드만 테스트하고, 다른 기기가 대역폭을 점유해 결과를 방해하지 않도록 주의하세요.

# Windows PowerShell에서 다운로드 속도를 테스트하는 간단한 방법
Measure-Command { Invoke-WebRequest -Uri "https://your-test-file-url" -OutFile "test.bin" }

측정한 속도와 지연 수치가 심하게 어긋난다면(지연은 낮지만 다운로드가 느린 경우), 노드 대역폭이나 서버 측 부하 문제로 거의 확정할 수 있습니다. 이런 경우에는 같은 구독 안에서 지연이 비슷한 다른 노드로 바꾸는 것이 현재 노드를 계속 붙잡고 있는 것보다 훨씬 효과적입니다.

2단계: 국제 회선 상태

노드 자체에 문제가 없더라도, 데이터가 로컬에서 노드 서버까지 가는 동안 여러 구간의 네트워크 링크를 거치며, 그중 한 구간이라도 혼잡하면 전체 속도가 느려집니다. 이 단계의 문제는 보통 다음과 같이 나타납니다. 여러 서비스 제공업체의 노드로 바꿔봐도 속도가 다 비슷하고, 특정 시간대(예: 저녁 피크 시간)에 더 심하게 느려지는 경향이 있습니다.

경로 추적으로 혼잡 지점 파악하기

경로 추적 도구는 로컬에서 목적지 서버까지 데이터 패킷이 거치는 모든 홉과 각 홉의 지연을 보여줍니다. 특정 홉에서 지연이 갑자기 급증하고 이후 모든 홉의 지연도 같이 높아진다면, 혼잡이 그 홉 근처에서 발생했다는 뜻입니다. 보통 국제 출구나 특정 중계 백본망의 문제로, 노드 자체로 해결할 수 있는 부분이 아닙니다.

# Windows에서 경로 추적하기
tracert 노드 서버의 IP 또는 도메인

# 그래픽 인터페이스를 선호한다면 WinMTR 같은 도구로 변동을 계속 관찰할 수도 있습니다

주의할 점은, 프록시 노드의 도메인을 직접 경로 추적하면 그 서버로 향하는 퍼블릭 경로만 확인할 수 있으며, 프록시 터널을 거친 실제 경로와 완전히 같지는 않습니다. 그래도 참고 가치는 있습니다. 이 경로 자체가 우회하거나 혼잡한 노드를 거친다면, 노드 서비스 제공업체를 바꿔도 대체로 비슷한 백본 구간을 거칠 가능성이 높습니다.

프로토콜 전환으로 회선 문제 완화하기

일부 국제 회선은 특정 프로토콜에 대한 간섭이나 속도 제한이 더 뚜렷하게 나타납니다. 특정 시간대에 어떤 프로토콜(예: 특정 TCP 직결)의 속도가 급격히 떨어지고 다른 프로토콜은 비교적 안정적이라면, 클라이언트에서 같은 입구에 대해 서로 다른 프로토콜의 노드를 각각 설정하여 테스트해보고, 실측상 더 안정적인 쪽을 일상적으로 사용하면 됩니다. 프로토콜 전환은 회선 단계 문제에 대응하는 일반적인 방법으로, 서비스 제공업체 교체 없이 낮은 비용으로 시도할 수 있습니다.

3단계: 로컬 클라이언트 및 시스템 설정

노드와 회선 문제를 배제한 뒤에도 상당 부분의 속도 문제는 로컬 설정에서 발생합니다. 이 단계는 가장 간과하기 쉽지만 점검 방법은 비교적 간단하며, 종종 한 번의 조정으로 해결됩니다.

분기 규칙이 트래픽을 저속 경로로 보내는지 확인하기

Clash의 분기 규칙은 각 연결이 프록시를 거칠지 직결할지, 프록시를 거친다면 어느 노드 그룹으로 갈지를 결정합니다. 규칙 파일 설정이 잘못되면 직결해야 할 트래픽이 강제로 프록시를 거치거나, 고속 노드 그룹을 써야 할 도메인이 저속 노드 그룹에 매칭되는 상황이 생길 수 있습니다. 클라이언트의 로그 페이지를 열어 특정 연결이 어떤 규칙에 매칭되고 어느 정책 그룹으로 떨어지는지 확인하는 것이 이런 문제를 찾는 가장 직접적인 방법입니다.

• 규칙 순서 오류: Clash의 규칙은 위에서 아래 순서로 매칭되며, 한 번 매칭되면 그 이하는 확인하지 않습니다. 너무 광범위한 규칙이 앞쪽에 있으면 더 정확한 규칙에 매칭돼야 할 트래픽을 가로챌 수 있습니다.
• 정책 그룹 안에 품질이 서로 다른 노드가 섞여 있는 경우: 어떤 정책 그룹이 "가장 빠른 노드 자동 선택" 방식을 쓰는데 그룹 내 노드 품질이 균일하지 않다면, 자동으로 선택된 노드가 현재 상황에 최적이 아닐 수 있습니다. 이미 검증된 안정적인 노드를 수동으로 지정하는 것이 좋습니다.
• 대용량 트래픽 상황을 따로 분리하지 않은 경우: 다운로드나 영상 시청 같은 상황이 웹 브라우징과 같은 정책 그룹을 공유하면, 매칭된 노드의 대역폭이 제한적일 때 서로 영향을 주게 됩니다. 정책 그룹을 적절히 나누면 각 상황에 맞는 최적 노드를 따로 찾을 수 있습니다.

DNS 설정이 속도에 미치는 은근한 영향

DNS 해석이 느리거나 결과가 좋지 않으면 "속도가 느리다"는 착각을 일으킬 수 있습니다. 실제로는 도메인 해석 단계가 너무 오래 걸리거나, 해석된 IP 자체의 경로가 좋지 않은 경우입니다. Clash Meta(mihomo 코어)는 DNS 분기 설정을 지원하여 국내 도메인과 해외 도메인에 각각 다른 해석 서버를 지정할 수 있고, fake-ip 모드와 함께 사용하면 불필요한 실제 해석 오버헤드를 줄일 수 있습니다.

dns:
  enable: true
  ipv6: false
  default-nameserver: [223.5.5.5]
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

페이지를 열 때 "로딩 중" 표시가 실제 로딩 시간보다 눈에 띄게 길다면, 먼저 해석 단계가 전체 체감 속도를 늦추고 있는지 확인한 뒤 노드 문제를 검토하세요.

TUN 모드와 시스템 프록시의 차이

Clash는 시스템 프록시와 TUN 모드 두 가지 접속 방식을 제공합니다. 시스템 프록시는 HTTP/SOCKS 프록시 파라미터를 설정하여 작동하며, 시스템 프록시 설정을 읽을 수 있는 애플리케이션에만 적용됩니다. TUN 모드는 네트워크 카드 계층에서 모든 트래픽을 관리하므로 적용 범위가 더 넓지만, 시스템 리소스와 네트워크 스택에 요구하는 조건도 더 높습니다. 특정 애플리케이션에서만 느리고 다른 앱은 정상이라면, 대체로 그 앱이 프록시 설정을 거치지 않거나 별도로 직결로 설정된 경우이며 노드나 회선 문제가 아닙니다. 반대로 TUN 모드를 켠 뒤 모든 애플리케이션이 전반적으로 느려졌다면, 로컬 방화벽이나 보안 소프트웨어와 충돌이 있는지 확인하고, TUN 모드를 일시적으로 끈 뒤 속도를 비교해보면 문제가 이 접속 계층에서 발생한 것인지 빠르게 판단할 수 있습니다.

로컬 네트워크 환경의 간섭 요인

마지막으로 가장 기본적인 가능성도 놓치지 마세요. 라우터 자체의 부하, Wi-Fi 신호 강도, 같은 네트워크의 다른 기기가 대역폭을 점유하는 상황 모두 "Clash가 느려 보이는" 현상을 만들 수 있습니다. 클라이언트를 끈 상태에서 직결 속도를 측정하고, 프록시를 켠 상태의 속도와 비교하는 것은 로컬 네트워크 환경의 간섭을 배제하고 문제가 실제로 프록시 경로에 있는지 확인하는 데 반드시 필요한 단계입니다.

권장 점검 순서

위의 세 단계를 이어서, 여러 변수를 동시에 바꿔 혼란을 일으키지 않도록 다음 순서로 점검하는 것을 권장합니다.

1. 프록시를 끄고 직접 속도를 측정해 로컬 네트워크 자체에 문제가 없는지 확인합니다.
2. 프록시를 켠 뒤 현재 노드의 지연과 실제 다운로드 속도가 일치하는지 확인해, 노드 품질 문제인지 판단합니다.
3. 같은 구독 내 지연이 비슷한 다른 노드로 바꿔 비교 테스트를 진행하며, 문제가 노드에 따라 달라지는지 확인합니다.
4. 여러 노드가 모두 비슷하게 느리다면, 경로 추적으로 고정된 혼잡 지점이 있는지 확인해 문제가 회선 단계에 있는지 판단합니다.
5. 노드와 회선을 배제한 뒤에는 분기 규칙 매칭 상태, DNS 해석 시간, 시스템 프록시와 TUN 모드 접속 방식의 차이를 확인해 로컬 설정 문제를 찾습니다.

이 순서대로 진행하면 보통 10여 분 안에 문제를 특정 단계로 좁힐 수 있으며, 노드를 계속 바꾸면서도 근본 원인을 찾지 못하는 상황을 피할 수 있습니다. 평소에도 지연과 속도 측정 기록을 남겨두는 습관을 들이면, 문제가 발생했을 때 이상 지점을 더 빠르게 비교해낼 수 있습니다.