문제 해결예상 읽기 시간 8분

Clash 속도 느림 단계별 진단: 노드·경로·로컬 설정

프록시 속도가 느리면 흔히 "노드가 안 좋다"고 단정하지만, 실제 병목은 전송 프로토콜, 로컬 DNS, 심지어 분기 규칙에 있을 수 있습니다. 이 글에서는 "노드 자체 → 전송 경로 → 로컬 설정" 3단계 순서로 진단 방법을 단계별로 정리하고, 구체적인 조치 방법까지 함께 다룹니다.

진단 전에 문제 범위를 먼저 파악하세요

설정을 바로 손대기 전에 먼저 2분만 투자해서 증상을 구체적으로 확인하면 이후 불필요한 시도를 크게 줄일 수 있습니다. "속도가 느리다"는 표현은 매우 포괄적인데, 실제로는 최소 세 가지 서로 다른 증상으로 나뉘고, 각각 원인이 거의 완전히 다릅니다.

  • 웹사이트·앱 로딩은 느리지만 한번 로딩되면 재생은 매끄러움 — 대부분 지연(RTT)이 높은 경우로, 대역폭 부족이 아닙니다. 노드 거리와 경로 품질을 먼저 확인하세요.
  • 다운로드·재생 중 속도가 계속 오르지 않고 끊김이 반복됨 — 대역폭 부족이나 경로 혼잡일 가능성이 높습니다. 노드 부하와 전송 프로토콜을 확인하세요.
  • 특정 사이트나 앱만 느리고 나머지는 정상 — 문제는 프록시 자체가 아니라 분기 규칙이 해당 트래픽을 적절하지 않은 아웃바운드로 보내고 있거나, 해당 사이트가 프록시 IP 자체에 속도 제한을 걸고 있는 경우가 많습니다.

증상을 분류한 뒤, 어느 단계부터 진단할지 정하면 됩니다. 확신이 서지 않는다면 아래 3단계 순서를 그대로 따라가세요. 이 순서는 "진단 비용이 낮은 것부터 높은 것 순"으로 설계되어 있습니다. 가장 검증하기 쉬운 노드 문제를 먼저 배제하고, 그다음 경로 설정을 확인한 뒤, 마지막에 로컬 시스템 설정까지 손을 대는 방식입니다.

참고

진단 중에는 한 번에 하나의 변수만 바꾸고 테스트하세요. 노드, 프로토콜, DNS를 동시에 바꾸면 문제가 해결돼도 어떤 조치가 효과가 있었는지 알 수 없습니다.

1단계 진단: 노드 자체의 속도 병목

노드는 전체 경로의 출발점이자 가장 검증하기 쉬운, 그래서 가장 먼저 배제해야 하는 단계입니다. 대부분의 구독은 여러 지역, 여러 경로의 노드를 제공하며, 속도 차이는 생각보다 큰 경우가 많습니다.

지연 테스트로 1차 필터링

클라이언트의 노드 목록에는 보통 지연 테스트 버튼이 있습니다(Clash Meta 커널 기준으로는 url-test 기반 헬스 체크). 클릭하면 각 노드에 HTTP 요청을 보내 응답 시간을 기록합니다. 지연 테스트는 "연결이 되는지, 연결 수립이 빠른지"를 반영하는 지표로, 실제 전송 속도와 완전히 일치하지는 않지만, 지연이 지속적으로 500ms를 넘거나 바로 타임아웃되는 노드는 기본적으로 배제할 수 있습니다.

  • 지연 150ms 이하: 웹 서핑, 메신저 등에 일반적으로 사용 가능
  • 지연 150~400ms: 사용은 가능하지만 영상·게임에서 끊김이 느껴질 수 있음
  • 지연 400ms 초과 또는 타임아웃 빈번: 다른 노드로 우선 교체하고, 해당 노드에서 이후 문제를 계속 진단하지 않는 것을 권장

노드 과부하 여부 배제하기

공유 노드는 피크 시간대(대부분 구독은 저녁 19:00~24:00이 피크)에 여러 사용자가 대역폭을 나눠 쓰면서, 지연 테스트 결과는 정상이지만 실제 다운로드 속도는 매우 낮게 나오는 경우가 있습니다. 이런 경우 지연 테스트로는 문제를 파악할 수 없으므로 직접 실측을 해봐야 합니다. 해당 노드로 전환한 뒤 속도가 안정적인 것으로 알려진 정적 리소스(예: 공개된 속도 테스트 파일)에 접속해서 노드별, 시간대별 다운로드 속도 차이를 비교하세요. 같은 노드가 비피크 시간대에는 확실히 더 빠르다면 부하 문제로 판단할 수 있고, 설정 문제가 아닙니다.

분기 그룹에 자동 속도 테스트와 장애 전환 추가하기

구독에 같은 지역 노드가 여러 개 있다면, proxy-groups에서 url-test 타입 그룹을 만들고 적절한 테스트 간격을 설정해 클라이언트가 자동으로 지연이 가장 낮은 노드를 선택하도록 하면, 수동 전환 빈도를 줄일 수 있습니다.

proxy-groups:
  - name: 자동선택-홍콩
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - HK-01
      - HK-02
      - HK-03

tolerance는 허용 오차 범위를 의미하며, 몇 밀리초 단위의 지연 변동으로 노드가 자주 바뀌어 연결이 반복적으로 끊기는 것을 막아줍니다.

2단계 진단: 전송 경로와 프로토콜 설정

노드 자체에 명확한 문제가 없다면, 다음으로 확인할 것은 "내 기기와 노드 사이의 데이터가 어떤 경로를 지나고, 어떤 프로토콜로 캡슐화되는가"입니다. 이 단계의 조정은 노드를 바꾸는 것보다 오히려 속도 향상에 더 효과적인 경우가 많습니다. 특히 네트워크 환경이 특정 프로토콜에 속도 제한이나 간섭을 걸고 있는 경우에는 더욱 그렇습니다.

전송 프로토콜 전환해보기

같은 노드가 여러 프로토콜(VMess, Trojan, Hysteria2, ShadowTLS 등)을 동시에 제공한다면, 같은 네트워크 환경에서도 프로토콜별 체감 속도가 크게 다를 수 있습니다. 일부 네트워크는 TCP 계열 프로토콜에 대해 더 엄격한 심층 패킷 검사(DPI)를 수행하는 반면, UDP 기반 프로토콜(Hysteria2, TUIC 등)은 손실률이 높은 경로에서 오히려 더 안정적인 경우가 있습니다. 자체적으로 전방 오류 정정과 혼잡 제어 메커니즘을 갖추고 있어 패킷 손실에 더 잘 대응하기 때문입니다. 구독에 여러 프로토콜 노드가 함께 제공된다면 다음 순서로 테스트해보세요.

  1. 먼저 TCP 계열 프로토콜(VMess/Trojan)의 실제 다운로드 속도를 측정합니다.
  2. 같은 시간대에 UDP 계열 프로토콜(Hysteria2/TUIC)의 성능을 측정합니다.
  3. 두 결과의 차이를 기록하고, 더 안정적인 프로토콜 계열을 고정해서 사용합니다.

속도 제한이나 간섭 여부 확인하기

일부 네트워크 환경은 감지된 프록시 트래픽을 차단하지 않고 속도 제한만 거는 경우가 있습니다. 이 경우 연결은 잘 되고 지연 테스트도 정상이지만, 전송 속도가 매우 낮은 고정값(예: 어떤 노드로 바꿔도 200KB/s 안팎에서 고정됨)으로 제한되는 증상이 나타납니다. 이런 상황에서는 노드를 바꿔도 의미가 없으며, TLS 위장 활성화나 간섭에 더 강한 프로토콜로 전환하는 등 전송 계층의 위장 방식 변경을 고려해야 합니다.

TUN 모드와 시스템 프록시의 차이 확인하기

TUN 모드는 시스템 네트워크 계층에서 모든 트래픽을 처리하는 방식으로, 브라우저가 아닌 앱(게임, 백그라운드 서비스)의 프록시 처리가 필요한 경우에 주로 사용됩니다. 이론적으로 시스템 프록시보다 느릴 이유는 없지만, 다른 가상 네트워크 어댑터나 보안 소프트웨어의 네트워크 후크가 동시에 작동 중이면 서로 간섭해 패킷 손실과 재전송이 발생할 수 있습니다. TUN 모드를 끄고 시스템 프록시 모드로 같은 노드의 속도를 비교 테스트해보세요. 시스템 프록시 모드가 확실히 더 빠르다면, 문제는 노드나 프로토콜이 아니라 로컬 네트워크 드라이버 계층에 있을 가능성이 높습니다.

증상가능성 높은 원인 계층권장 조치
노드를 바꿔도 속도가 똑같이 느림로컬 설정/네트워크 환경DNS, TUN, 시스템 네트워크 설정 확인
특정 시간대에만 느림노드 부하같은 지역의 다른 노드로 교체하거나 피크 시간대 회피
TCP 프로토콜은 느리고 UDP 프로토콜은 빠름전송 경로 간섭프로토콜 종류 전환
특정 사이트만 느림분기 규칙/대상 사이트 속도 제한규칙 매칭 확인, 아웃바운드 전략 변경

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

앞의 두 단계에서 문제를 찾지 못했다면, 로컬 설정이 발목을 잡고 있을 가능성이 큽니다. 이 단계는 진단 비용이 조금 더 높지만, 장기간 반복적으로 발생하는 속도 문제의 근본 원인인 경우가 많습니다.

DNS 설정 조정하기

DNS 해석이 느리면 "페이지 첫 로딩은 느리지만 리소스가 로드된 후에는 매끄러운" 착시 증상이 나타나 노드 문제로 오인하기 쉽습니다. 설정 파일에서 클라이언트에 별도의 DNS 서버를 지정하고, fake-ip 모드를 활성화해 불필요한 실제 DNS 조회 지연을 줄이는 것을 권장합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

nameserver는 중국 본토 도메인 해석용이고, fallback은 프록시 대상 도메인 해석용입니다. 이 둘을 분리해서 설정하면 중국 본토 사이트가 우회 경로로 해석되면서 발생하는 추가 지연을 막을 수 있습니다.

분기 규칙 정리하기

규칙 수가 너무 많거나 규칙 세트 용량이 너무 크면 연결마다 매칭에 걸리는 시간이 늘어나며, 성능이 낮은 기기(특히 라우터나 오래된 스마트폰)에서는 그 영향이 더 두드러집니다. 기능이 중복되는 규칙 세트를 여러 개 로드하고 있는지 확인하세요. 예를 들어 광고 필터링 규칙 두 세트나 지역 분기 규칙 여러 세트를 동시에 켜두는 경우, 중복 규칙을 합치거나 삭제하면 매칭 부담을 줄일 수 있습니다. 규칙 순서도 함께 점검하세요. 매칭 빈도가 높은 규칙(예: 중국 본토 직접 연결 도메인)을 목록 앞쪽에 배치하면 평균 매칭 횟수를 줄일 수 있습니다.

백그라운드에서 대역폭을 쓰는 프로그램 종료하기

클라우드 동기화 도구, 시스템 자동 업데이트, 백그라운드 다운로드 작업은 모두 출력 대역폭을 소모하며 프록시 트래픽과 경쟁합니다. 이 경우 "프록시 자체는 문제 없는데 전체 속도가 오르지 않는" 증상으로 나타납니다. 속도 테스트 전에 작업 관리자나 활동 모니터에서 네트워크 사용량을 확인하고, 대역폭을 많이 쓰는 백그라운드 프로세스를 일시 중지한 뒤 다시 테스트해보세요.

클라이언트 버전과 커널 상태 확인하기

오래된 버전의 클라이언트나 커널을 사용 중이라면 이후 버전에서 추가된 특정 프로토콜 성능 최적화가 빠져 있을 수 있습니다. 속도 문제가 오래 지속되고 위 진단으로도 원인을 찾지 못했다면, 새 버전이 있는지 확인하고 업데이트한 뒤 앞서 다룬 3단계 진단을 다시 진행해 문제가 해결되는지 확인하세요.

재사용 가능한 진단 절차 만들기

위 내용을 간단한 체크리스트로 정리해두면, 속도 문제가 생길 때마다 순서대로 확인해서 진단 시간을 크게 줄일 수 있습니다.

  1. 지연 테스트로 명확히 이상한 노드를 걸러낸다
  2. 같은 지역 노드끼리 실제 다운로드 속도를 비교해 부하 문제를 배제한다
  3. 프로토콜 종류를 전환해 TCP 계열과 UDP 계열의 성능을 비교한다
  4. TUN 모드를 끄고 비교 테스트해 로컬 네트워크 계층 간섭을 배제한다
  5. DNS 설정을 점검하고 조정해 해석 속도를 확인한다
  6. 분기 규칙을 정리해 매칭 부담을 줄인다
  7. 백그라운드에서 대역폭을 쓰는 프로그램을 확인한다
  8. 클라이언트와 커널 버전이 최신인지 확인한다

대부분의 속도 문제는 처음 세 단계에서 원인을 찾을 수 있습니다. 실제로 로컬 설정 단계까지 진단해야 하는 경우는 상대적으로 드물지만, 한번 발생하면 장기간 반복되는 문제의 근본 원인이 되는 경우가 많으므로, 노드만 계속 바꿔가며 대응하기보다 시간을 들여 한 번 제대로 진단해볼 가치가 있습니다.

Clash 다운로드