1단계: 재현 가능한 속도 기준선부터 설정하기

Clash에 표시되는 노드 지연 시간, 웹페이지 로딩 시간, 다운로드 속도는 서로 다른 지표입니다. 지연 시간 테스트는 보통 한 번의 HTTP 요청이나 TCP 연결 응답 시간만 측정하므로 노드에 연결할 수 있는지는 보여 주지만, 지속적인 처리량을 직접 나타내지는 못합니다. 지연 시간이 80밀리초인 노드도 대역폭이 부족할 수 있고, 180밀리초인 노드가 대용량 파일 다운로드에서는 더 빠를 수도 있습니다. 따라서 문제를 점검할 때는 노드 목록의 밀리초 수치만 보지 마세요.

먼저 기기, 네트워크, 테스트 대상을 고정하세요. 파일 동기화, 시스템 업데이트, 게임 다운로드, 사진 업로드를 진행 중인 프로그램을 종료한 뒤 안정적인 웹사이트와 충분히 큰 테스트 파일을 선택합니다. 각 테스트는 최소 수십 초 동안 진행하고 첫 화면 로딩 시간, 안정적인 다운로드 속도, 중간 멈춤 발생 여부를 기록하세요. 짧은 속도 측정은 캐시, 연결 예열, 서버 측 속도 제한의 영향을 받기 쉽습니다.

  1. Clash의 시스템 프록시 또는 TUN 모드를 잠시 끄고 현재 네트워크의 직접 연결 성능을 측정합니다.
  2. Clash를 켠 뒤 노드 하나와 프록시 모드 하나를 고정하고 같은 대상으로 다시 테스트합니다.
  3. 같은 지역의 다른 노드로 바꾼 다음 동일한 테스트를 한 차례 더 진행합니다.
  4. 지연 시간, 다운로드 속도, 업로드 속도, 패킷 손실 여부, 웹페이지 분석 시간을 각각 기록합니다.

직접 연결 자체가 이미明显하게 느리다면 Clash 설정을 바로 바꾸지 말고 먼저 로컬 광대역, 모바일 네트워크 또는 Wi-Fi를 점검하세요. 프록시 연결만 느리다면 노드, 진입 경로, 출구 경로, 클라이언트 설정을 차례로 확인합니다. 특정 웹사이트만 느리고 다른 프록시 트래픽은 정상이라면 대상 사이트, 라우팅 정책 또는 해당 사이트와 출구 주소 사이의 연결 품질이 원인일 수도 있습니다.

2단계: 노드 지연 시간·대역폭·부하 구분하기

노드는 가장 흔한 속도 병목이지만, ‘노드 사용 가능’은 연결을 수립할 수 있다는 뜻일 뿐입니다. 실제 속도는 서버 대역폭, 동시 접속 부하, 프로토콜 구현, 통신사 진입 경로 품질, 출구에서 대상 사이트까지의 라우팅에 따라 달라집니다. 피크 시간대에 느려졌다가 새벽에 회복된다면 부하나 경로 혼잡일 가능성이 높고, 하루 종일 꾸준히 느리다면 노드 속도 제한, 경로 품질, 기기 처리 성능을 점검해야 합니다.

지연 시간 테스트를 종합 속도 측정으로 착각하지 않기

Clash 클라이언트는 보통 테스트 주소 하나를 사용해 노드 지연 시간을 계산합니다. 결과는 테스트 주소, 연결 재사용, DNS 캐시, 시간 초과 설정의 영향을 받습니다. 지연 시간은 낮지만 처리량이 낮다면 노드 대역폭 부족일 수 있고, 지연 시간이 가끔 크게 튄다면 경로 불안정일 수 있습니다. 많은 노드가 동시에 시간 초과를 표시한다면 노드를 하나씩 반복해서 클릭하기보다 구독, 네트워크 권한, DNS 또는 서버 상태를 점검해야 합니다.

노드를 선택할 때는 먼저 지역별로 그룹화한 뒤 같은 지역에서 최소 3개 노드를 비교해 보세요. 테스트에는 웹페이지, 소용량 파일, 지속 다운로드를 모두 포함해야 합니다. 동영상 재생에서는 순간 최고 속도보다 버퍼링이 안정적인지도 확인하세요. 클라이언트가 URL Test, Fallback 또는 부하 분산 정책 그룹을 지원한다면 선택 기준도 이해해야 합니다. URL Test는 테스트 응답이 빠른 노드를 우선하고, Fallback은 장애 전환에 중점을 두며, 부하 분산은 연결마다 다른 노드를 사용할 수 있습니다.

정책 그룹이 실제로 대상 노드를 선택했는지 확인하기

설정에는 여러 단계의 정책 그룹이 자주 사용됩니다. 예를 들어 애플리케이션 규칙이 먼저 ‘해외 웹사이트’로 들어가고, 이 그룹이 다시 ‘자동 선택’을 참조한 뒤 최종적으로 특정 노드를 가리킬 수 있습니다. 화면에서 특정 그룹을 전환했다고 해서 현재 요청이 반드시 그 그룹을 거치는 것은 아닙니다. 연결 기록이나 로그를 열어 대상 도메인이 어떤 규칙에 일치했는지, 어느 정책 그룹으로 들어갔는지, 최종적으로 어떤 노드를 사용했는지 확인하세요.

대상 도메인 → 규칙 일치 → 정책 그룹 → 하위 정책 그룹 → 특정 노드

트래픽이 DIRECT에 일치했다면 속도 측정 결과는 실제로 직접 연결 기준입니다. REJECT에 일치하면 요청이 거부되고, 자동 정책 그룹에 일치하면 클라이언트가 백그라운드에서 노드를 다시 선택할 수 있습니다. 점검 중에는 정책 그룹에서 특정 노드를 임시로 고정해 자동 전환이 결과에 영향을 주지 않도록 하세요. 테스트가 끝나면 기존 정책으로 되돌립니다.

3단계: 진입 경로와 출구 경로의 혼잡 여부 판단하기

프록시 연결에는 최소 세 구간의 경로가 포함됩니다. 기기에서 로컬 통신사까지, 통신사에서 프록시 노드까지, 프록시 노드에서 대상 웹사이트까지입니다. 어느 한 구간에서든 속도가 떨어질 수 있습니다. 노드와의 거리가 가깝다는 것은 지리적으로 더 가까울 가능성을 보여 줄 뿐, 통신사 간 상호 연결 경로가 더 짧다는 뜻은 아닙니다. 서로 다른 유선 또는 모바일 네트워크에서 같은 노드에 접속하면 결과가 완전히 다를 수 있습니다.

가장 실용적인 판단 방법은 교차 테스트입니다. 노드는 그대로 두고 기기를 가정용 Wi-Fi에서 모바일 핫스팟으로 바꿔 보세요. 또는 네트워크는 그대로 두고 다른 지역이나 다른 진입 유형의 노드로 바꿉니다. 네트워크를 바꾼 뒤 같은 노드가 회복된다면 로컬 통신사에서 노드까지의 경로 문제일 가능성이 높고, 노드를 바꾼 뒤 회복된다면 기존 노드의 부하나 라우팅을 의심할 수 있습니다.

  • 낮에는 정상이고 저녁에 느려짐: 피크 시간대 혼잡, 공유 대역폭 부하, 통신사 상호 연결 구간의 부담을 우선 의심합니다.
  • 웹페이지는 빠르고 다운로드는 느림: 노드의 지속 대역폭, 대상 사이트의 속도 제한, 단일 연결 성능을 확인합니다.
  • 다운로드는 빠르지만 동영상이 자주 버퍼링됨: 스트리밍 대상의 출구 라우팅, 정책 일치, 연결 안정성을 점검합니다.
  • 처음 열 때만 느리고 이후에는 정상: DNS, TLS 연결 수립, 최초 라우팅 선택을 중점적으로 확인합니다.
  • 속도가 주기적으로 0까지 떨어짐: 패킷 손실, 무선 간섭, 노드 재시작, 연결 전환, 기기 절전 정책을 확인합니다.

명령줄의 ping은 제한적인 참고 자료만 제공합니다. 일부 서버는 ICMP 응답 우선순위를 낮추거나 아예 응답하지 않지만 TCP와 UDP 서비스는 정상 작동할 수 있습니다. 경로 추적은 어느 구간에서 경로가 크게 달라지는지 확인하는 데 도움이 되지만, 특정 홉이 응답하지 않는다는 이유만으로 장애를 판정할 수는 없습니다. 더 신뢰할 수 있는 결론은 여러 시간대, 여러 네트워크, 여러 노드의 비교 결과에서 나옵니다.

4단계: DNS 조회와 연결 대기 시간 점검하기

DNS 문제는 네트워크 속도 저하로 오해하기 쉽습니다. 대표적인 증상은 웹 주소를 입력한 뒤 오랫동안 빈 화면이 표시되지만 페이지 로딩이 시작되면 속도가 정상인 경우, 일부 도메인만 열리고 다른 도메인은 계속 시간 초과되는 경우, 네트워크를 바꾸자마자 회복되는 경우입니다. 이때 병목은 프록시 노드의 데이터 전송이 아니라 도메인 조회 단계에서 발생했을 수 있습니다.

Clash 또는 mihomo 설정은 DNS를 직접 처리할 수 있으며, 실행 모드에 따라 일반 DNS, 암호화 DNS, Fake IP, Redir Host 등의 방식을 사용합니다. 클라이언트마다 표시되는 스위치 이름은 다를 수 있지만 최종 동작은 코어 설정과 클라이언트가 생성한 설정이 함께 결정합니다. 변경하기 전에 현재 설정에서 DNS 활성화 여부, 수신 주소, 기본 리졸버, 상위 DNS 서버를 먼저 확인하세요.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.example/dns-query

위 조각은 필드 간 관계를 설명하기 위한 예시일 뿐이며, 예시 주소를 실제로 사용할 수 있는 서비스로 간주해서는 안 됩니다. 실제 점검에서는 안정적으로 접속할 수 있는 리졸버를 사용하고, 시스템이나 라우터가 DNS 요청을 다른 곳으로 강제 전달하지 않는지 확인하세요. 상위 암호화 DNS가 도메인 조회를 먼저 필요로 한다면 bootstrap 또는 기본 조회 경로도 정상적으로 작동해야 합니다.

Fake IP 모드에서 자주 발생하는 오판

Fake IP는 도메인에 예약 주소를 반환한 뒤 코어가 해당 주소를 원래 도메인에 다시 매핑하고 규칙을 적용하는 방식입니다. 도메인 트래픽을 일관되게 처리하는 데 유리하지만 일부 LAN 기기, 특수 애플리케이션, 실제 주소에 의존하는 서비스는 필터 목록에 추가해야 할 수 있습니다. 프린터, 라우터 관리 페이지, LAN 저장 장치 또는 일부 애플리케이션에서만 문제가 발생한다면 fake-ip-filter와 LAN 우회 규칙을 확인하세요. 이를 바로 노드 속도 저하로 단정해서는 안 됩니다.

시스템에 이전 DNS 캐시가 남아 있을 수도 있습니다. 설정을 바꾼 뒤 관련 애플리케이션을 다시 시작하고, 필요하면 시스템 DNS 캐시를 삭제한 다음 다시 테스트하세요. 브라우저가 자체 보안 DNS를 사용하면 브라우저와 다른 프로그램이 서로 다른 조회 경로를 사용할 수도 있습니다. 점검할 때는 시스템, 브라우저, Clash 중 누가 각각 DNS 조회를 담당하는지 확인해 여러 구성 요소가 동시에 DNS를 덮어쓰는 일을 피하세요.

5단계: 시스템 프록시·규칙 모드·TUN 모드 비교하기

시스템 프록시는 운영체제의 프록시 설정을 통해 애플리케이션에 HTTP 또는 HTTPS 요청을 Clash로 전달하도록 알립니다. 시스템 프록시를 따르는 브라우저와 데스크톱 프로그램은 처리할 수 있지만, 일부 게임, 명령줄 프로그램, 스토어 앱, 자체 네트워크 스택을 구현한 소프트웨어는 이 설정을 무시할 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 만들어 더 낮은 계층에서 TCP, UDP, DNS 트래픽을 폭넓게 처리합니다. 적용 범위가 넓은 대신 권한, 라우팅 테이블, 운영체제 네트워크 구성 요소에 더 크게 의존합니다.

브라우저 속도는 정상인데 게임, 터미널 다운로드 도구 또는 특정 애플리케이션만 느리다면 먼저 해당 애플리케이션이 프록시에 들어오는지 확인하세요. Clash의 연결 목록에서 요청이 표시되는지 확인하고 대상 주소, 프로토콜, 규칙, 최종 노드를 살펴봅니다. 연결 목록에 기록이 없다면 대개 트래픽이 코어에 들어오지 않은 것입니다. 기록은 있지만 DIRECT를 사용한다면 규칙이 직접 연결을 선택한 것이고, 기록이 있으며 노드를 거쳤을 때만 노드와 경로를 계속 분석할 수 있습니다.

규칙 모드와 글로벌 모드 비교 방법

규칙 모드는 도메인, IP, 프로세스 또는 규칙 세트에 따라 DIRECT, REJECT, 특정 정책 그룹 중 하나를 선택합니다. 글로벌 모드는 보통 대부분의 트래픽을 지정한 프록시 정책으로 전달합니다. 특정 웹사이트를 점검할 때 잠시 글로벌 모드로 전환해 비교해 보세요. 글로벌 모드에서는 회복되지만 규칙 모드에서만 느리다면 규칙 일치, 정책 그룹, DNS를 확인해야 합니다. 두 모드 모두 느리다면 노드나 경로를 우선 의심할 수 있습니다.

글로벌 모드는 임시 진단에만 사용하고 규칙을 수정하는 대신 사용해서는 안 됩니다. 테스트가 끝나면 규칙 모드로 되돌리고 로그에서 차이를 만든 구체적인 규칙을 찾으세요. 앞선 규칙에 일치하지 않은 요청이 최종적으로 도달하는 설정 하단의 MATCH 규칙도 확인해야 합니다.

TUN 모드에서 속도가 떨어질 때 확인할 항목

  • 클라이언트에 가상 네트워크 카드 생성과 라우팅 수정에 필요한 시스템 권한이 있는지 확인합니다.
  • 다른 VPN, 가상 머신 네트워크 카드, 게임 가속 도구, 보안 소프트웨어가 동시에 라우팅을 수정하고 있지 않은지 확인합니다.
  • MTU 설정이 현재 네트워크에 적합한지 확인합니다. 패킷이 너무 크면 분할되거나 폐기될 수 있습니다.
  • UDP가 안정적인지 관찰합니다. 일부 네트워크 환경에서는 UDP 제한이 QUIC, 게임, 실시간 통신에 영향을 줄 수 있습니다.
  • TUN을 끄고 시스템 프록시만 활성화했을 때의 속도를 비교해 문제가 가상 인터페이스와 관련 있는지 판단합니다.

일부 브라우저는 UDP 기반 HTTP/3를 우선 사용할 수 있습니다. 경로의 UDP 지원이 불안정하면 웹페이지 연결 수립이 느려지거나 동영상이 끊기고 속도 측정 결과가 흔들릴 수 있습니다. 연결 로그에서 프로토콜을 확인한 뒤 짧은 비교 테스트를 진행하세요. 여러 네트워크 기능을 한꺼번에 영구적으로 끄지 말고, 어떤 변경이 실제 결과에 영향을 주었는지 먼저 확인해야 합니다.

6단계: 기기 성능·무선 네트워크·백그라운드 프로그램 배제하기

프록시 코어는 암호화, 복호화, 규칙 일치, DNS 처리, 연결 전달을 수행해야 합니다. 최신 데스크톱 기기는 일반적인 트래픽을 처리할 수 있지만, 저전력 라우터, 오래된 스마트폰, 리소스가 제한된 서버, 많은 연결을 동시에 처리하는 기기에서는 CPU 사용량이 한계에 가까워질 수 있습니다. 이때 병목은 로컬 처리 성능에 있으므로 노드를 바꿔도 속도가 나아지지 않을 수 있습니다.

속도 측정 중 작업 관리자나 시스템 모니터링 도구를 열어 Clash 클라이언트, 코어 프로세스, 브라우저, 보안 소프트웨어의 CPU, 메모리, 디스크, 네트워크 사용량을 관찰하세요. 속도가 떨어질 때 특정 코어가 계속 최대 사용량이라면 불필요하게 복잡한 규칙을 줄이고, 과도한 로그를 끄며, 동시 연결 수를 줄이거나 성능이 더 좋은 기기에서 비교 테스트를 진행하세요.

Wi-Fi도 흔한 변수입니다. 2.4GHz 대역은 주변 네트워크, Bluetooth 기기, 가전제품의 간섭을 받기 쉽고, 라우터에서 멀어지면 기기가 데이터를 계속 재전송할 수 있습니다. 기준선 테스트는 유선 또는 안정적인 5GHz·6GHz 네트워크에서 우선 진행하세요. 유선은 정상이고 무선만 느리다면 프록시 프로토콜을 바꾸기보다 먼저 채널, 거리, 라우터 위치를 조정해야 합니다.

백그라운드 프로그램은 업로드 대역폭을 점유하고, 업로드 포화는 다운로드 지연 시간도 높일 수 있습니다. 클라우드 드라이브 동기화, 사진 백업, 화상 회의, 토렌트 업로드가 이런 현상을 만들 수 있습니다. 다운로드 대역폭에 여유가 있어도 대기열 지연 때문에 웹페이지와 상호작용 요청이 느리게 느껴질 수 있습니다. 백그라운드 작업을 일시 중지하고 잠시 기다린 다음 동일한 테스트를 실행하세요.

설정 규모와 로그 수준

대규모 규칙 세트와 잦은 구독 업데이트는 로딩 시간을 늘릴 수 있지만, 정상적인 설정이라면 모든 요청에 눈에 띄는 지연이 발생해서는 안 됩니다. 클라이언트가 시작된 뒤 오랫동안 멈춘다면 규칙 세트가 중복되는지, 같은 리소스를 설정에서 여러 번 참조하는지, 로그 수준이 지나치게 높게 설정되어 있는지 확인하세요. 디버그 로그는 짧은 진단에 적합하며, 연결 정보를 계속 대량으로 기록하면 디스크 쓰기와 화면 렌더링 부담이 커집니다.

구독을 업데이트한 뒤 갑자기 느려졌다면 정책 그룹 이름과 노드 이름이 바뀌었는지도 확인해야 합니다. 클라이언트가 정책 그룹의 기본 항목으로 되돌아갔거나 자동 테스트가 다른 노드를 선택했을 수 있습니다. 구독을 반복해서 다시 가져오기보다 업데이트 전후의 최종 설정과 현재 선택 항목을 각각 확인하는 편이 차이를 찾기 쉽습니다.

순서대로 진행하는 10분 문제 해결 절차

속도 문제는 바깥쪽에서 안쪽으로 범위를 단계적으로 좁혀 가는 방식이 효과적입니다. 아래 절차에서는 YAML을 바로 수정하지 않아도 됩니다. 먼저 비교를 통해 문제가 어느 계층에 속하는지 확인한 뒤 해당 설정을 처리하세요.

  1. 직접 연결 측정: 프록시를 끈 상태에서 현재 네트워크를 테스트해 기본 네트워크에 뚜렷한 이상이 없는지 확인합니다.
  2. 노드 고정: 자동 선택을 끄고 노드 하나를 지정한 뒤 지연 시간과 지속 다운로드 속도를 기록합니다.
  3. 노드 변경: 같은 지역과 다른 지역의 노드를 하나씩 선택해 피크 시간대와 비피크 시간대의 성능을 비교합니다.
  4. 연결 확인: 대상 요청이 Clash에 들어오는지 확인하고 일치한 규칙, 정책 그룹, 최종 노드를 기록합니다.
  5. 네트워크 전환: 모바일 핫스팟이나 다른 광대역으로 같은 노드를 테스트해 진입 경로 문제인지 판단합니다.
  6. DNS 점검: 지연이 조회 단계에서 발생하는지 전송 단계에서 발생하는지 확인하고 시스템과 클라이언트의 조회 경로를 대조합니다.
  7. 모드 비교: 규칙 모드와 글로벌 모드, 시스템 프록시와 TUN 모드의 결과를 비교합니다.
  8. 리소스 확인: CPU, 메모리, 무선 신호, 백그라운드 업로드가 병목인지 살펴봅니다.
  9. 설정 다시 불러오기: 설정이 정상적으로 해석되었고 정책 그룹 선택과 구독 업데이트 결과가 예상과 일치하는지 확인합니다.
  10. 설정 복원: 테스트에만 사용한 글로벌 모드, 디버그 로그, 임시 DNS 변경을 되돌립니다.

최종 기록에는 테스트 시간, 네트워크 유형, 클라이언트 버전, 코어 유형, 프록시 모드, 노드 이름, 대상 웹사이트, 속도 결과를 포함해야 합니다. 노드 서비스 제공자나 클라이언트 프로젝트에 문제를 제출해야 할 때 이런 정보가 ‘그냥 느리다’는 설명보다 진단에 훨씬 유용합니다. 설정 내용을 공유할 때는 구독 주소, 인증 정보, 노드 자격 증명, 개인 네트워크 정보를 먼저 삭제하세요.

점검 결론: 어느 구간에서 느린지부터 찾기

Clash가 느리다고 해서 반드시 노드 지연 시간이 높은 것은 아닙니다. 전체 연결은 로컬 네트워크, DNS, 규칙 일치, 프록시 진입 경로, 노드 처리, 출구 라우팅, 대상 웹사이트로 구성됩니다. 먼저 직접 연결 기준선을 측정하고 노드를 고정한 다음, 네트워크·노드·모드를 차례로 바꿔 비교하면 노드 부하, 통신사 경로, DNS 대기, 기기 병목을 빠르게 구분할 수 있습니다.

같은 네트워크에서 모든 노드가 느리지만 네트워크를 바꾸면 회복된다면 로컬 네트워크와 통신사 경로를 우선 처리하세요. 일부 노드만 느리다면 노드 부하와 출구 경로를 중점적으로 확인합니다. 웹페이지 첫 로딩만 느리고 다운로드는 안정적이라면 DNS를 점검하세요. 특정 애플리케이션만 이상하다면 시스템 프록시나 TUN이 실제로 트래픽을 처리하는지 확인합니다. 계층별로 기록하고 한 번에 하나씩 변경한 뒤 임시 설정을 복원하면 단순한 문제를 여러 설정 충돌로 키우는 일을 피할 수 있습니다.

플랫폼에 맞는 설치 패키지 선택

다운로드 센터에서 운영체제와 아키텍처를 확인한 뒤 사용 문서에 따라 설치, 구독 가져오기, 기본 연결 점검을 진행하세요.

다운로드 페이지 사용법 보기