Clash 속도가 느릴 때: 노드·경로·로컬 설정 3단계 점검

먼저 “느린 속도”가 어디에서 발생하는지 확인하기

Clash에는 연결됨으로 표시되지만 웹 페이지가 느리게 열리거나 동영상이 자주 버퍼링되고 다운로드 속도가 낮을 수 있습니다. 이 문제가 반드시 노드 성능 때문인 것은 아닙니다. 전체 연결에는 로컬 앱, Clash 코어, DNS 확인, 프록시 노드, 통신사 경로, 대상 웹사이트가 포함됩니다. 어느 한 구간에서든 정체가 발생하면 iPhone에서는 “Clash를 켜면 느려지는” 현상으로 나타날 수 있습니다.

점검 전에 변수를 고정하세요. 같은 Wi-Fi, 같은 속도 측정 사이트, 같은 브라우저, 같은 프록시 노드를 사용하고, 각 테스트는 최소 30초 동안 진행해 연속 3회 측정합니다. 노드와 네트워크를 동시에 바꾸면 무엇 때문에 개선됐는지 판단할 수 없습니다.

기준 데이터 네 가지 기록하기

예를 들어 직접 연결 다운로드 속도가 280 Mbps이고 프록시 사용 후 85 Mbps로 안정된다면 병목은 프록시 경로나 노드에 있을 가능성이 큽니다. 직접 연결 자체가 18 Mbps에 불과하다면 프록시로 현재 접속 네트워크의 한계를 넘기 어렵습니다. 속도 측정 결과는 정상인데 웹 페이지를 처음 여는 데 3~5초가 걸린다면 대역폭 테스트를 반복하기보다 DNS를 먼저 확인하세요.

1단계: 노드 자체의 부하와 프로토콜 확인

먼저 Clash의 정책 그룹 화면에서 실제로 선택된 노드를 확인하세요. “자동 선택”이나 “페일오버” 정책 그룹을 사용하는 경우 홈 화면에 표시되는 그룹명이 최종 출구 노드와 일치하지 않을 수 있습니다. 「프록시」 또는 「정책」 화면으로 들어가 해당 정책 그룹을 펼친 뒤 선택된 구체적인 노드를 확인해야 합니다.

고정 파일로 지속 처리량 테스트하기

1. 현재 노드를 그대로 유지하고 진행 중인 클라우드 동기화, 시스템 업데이트, 동영상 재생을 종료합니다.
2. 반복해서 접속할 수 있는 100MB~500MB 테스트 파일을 선택하고 30초 후 안정화된 속도를 확인합니다.
3. 2분 후 같은 테스트를 두 번 더 반복해 최저값, 중앙값, 최고값을 기록합니다.
4. DNS, 규칙 모드, 로컬 네트워크는 변경하지 말고 노드만 바꾼 뒤 동일한 테스트를 진행합니다.

어떤 노드의 3회 결과가 각각 72Mbps, 69Mbps, 74Mbps라면 비교적 안정적입니다. 반대로 8Mbps, 91Mbps, 17Mbps처럼 크게 출렁이면 노드 부하, 상위 회선 공유 또는 패킷 손실이 흔한 원인입니다. 이 경우 기기 내 규칙을 계속 조정해도 효과가 크지 않습니다.

노드 프로토콜과 기기 성능

프로토콜마다 암호화, 캡슐화, 전송 방식이 달라 CPU 사용량도 다릅니다. 최신 iPhone은 일반적인 Shadowsocks, Trojan, VLESS, WireGuard 트래픽을 대체로 무리 없이 처리하지만, 구형 기기는 높은 대역폭이나 복잡한 암호화, 지속적인 발열 상황에서 클럭이 낮아질 수 있습니다. 테스트 중 iOS 「설정」→「배터리」에서 Clash 클라이언트의 배터리 사용량이 계속 높은지 확인하고, 기기가 눈에 띄게 뜨겁지 않은지도 점검하세요.

• 단일 노드만 느림: 노드 부하, 노드 출구 또는 노드 설정 문제일 가능성을 먼저 확인합니다.
• 같은 지역의 모든 노드가 느림: 해당 지역의 진입점, 출구 또는 통신사 간 연동 구간이 혼잡할 수 있습니다.
• 모든 프로토콜이 느림: 중간 경로와 로컬 네트워크를 계속 점검하세요.
• 특정 프로토콜만 느림: 해당 프로토콜의 전송 매개변수, UDP 지원 여부, 서버 설정을 확인하세요.

2단계: 노드 문제와 중간 경로 문제 구분하기

iPhone과 프록시 노드 사이에는 가정용 공유기, 인터넷 통신사, 이동통신망, 통신사 간 연동 구간이 더 있습니다. 노드 자체가 한산해도 내 기기에서 노드까지의 경로가 원활하다는 뜻은 아닙니다. 가장 간단한 구분 방법은 노드를 그대로 두고 접속 네트워크만 바꾸는 것입니다.

Wi-Fi와 셀룰러 네트워크 교차 테스트하기

1. Wi-Fi에서 고정 노드를 선택하고 지연 시간 및 다운로드 테스트를 3회 진행합니다.
2. Wi-Fi를 끄고 4G 또는 5G를 사용해 같은 노드를 다시 테스트합니다.
3. 셀룰러 네트워크가 확실히 더 빠르면 광모뎀과 공유기를 재부팅하고, 인터넷 회선의 저녁 피크 시간대 성능을 확인하세요.
4. Wi-Fi가 더 빠르면 셀룰러 신호, 데이터 속도 제한, 현재 기지국 부하를 확인하세요.

예를 들어 같은 노드가 가정용 Wi-Fi에서 지연 시간 240ms, 다운로드 12Mbps를 보이고 5G에서는 지연 시간 96ms, 다운로드 83Mbps를 보인다면 노드 전체 장애라기보다 가정용 인터넷에서 해당 노드로 이어지는 경로가 좋지 않을 가능성이 큽니다. 반대로 두 네트워크 모두 약 10Mbps로 안정적인데 직접 연결 속도가 각각 200Mbps와 150Mbps라면 노드 측 제한일 가능성이 더 높습니다.

저녁 피크 시간대와 지속적인 패킷 손실 확인

회선 혼잡은 현지 시간 20:00~23:00에 집중되는 경우가 많습니다. 오전, 오후, 저녁에 한 번씩 같은 테스트를 진행하세요. 낮에는 안정적이고 밤에만 급격히 느려진다면 설정을 계속 바꾸기보다 먼저 진입 지역이나 다른 통신사 경로로 전환하는 편이 효과적입니다.

지연 시간이 가끔 80ms에서 180ms로 뛰는 것만으로 다운로드에 반드시 문제가 생기지는 않습니다. 하지만 몇 초마다 타임아웃이 발생하면 동영상, 음성 통화, 게임에서 끊김이 더 쉽게 나타납니다. 일부 클라이언트는 성공한 요청의 지연 시간만 표시하므로 타임아웃이 발생하는 노드도 정상적인 숫자로 보일 수 있습니다. 따라서 연결 로그에 timeout, connection reset, context deadline exceeded가 연속으로 나타나는지도 확인해야 합니다.

가정용 공유기와 Wi-Fi 확인

• 5GHz 또는 6GHz Wi-Fi를 우선 사용하고 혼잡한 2.4GHz 채널은 피하세요.
• 공유기 가까이에서 다시 측정해 벽으로 인한 차단과 약한 신호 때문에 발생하는 재전송을 배제하세요.
• 중복 처리를 피하기 위해 공유기의 보조 프록시, 자녀 보호 기능, 트래픽 셰이핑을 잠시 끄세요.
• 로컬 네트워크의 다른 기기에서 사진을 업로드하거나 클라우드 드라이브를 동기화하거나 대규모 업데이트를 다운로드하고 있지 않은지 확인하세요.
• 공유기와 iPhone에서 모두 프록시를 사용한다면 테스트 중에는 한 단계만 남겨 트래픽이 중복 전달되지 않게 하세요.

3단계: Clash 로컬 설정 확인

여러 노드와 여러 접속 네트워크에서 모두 속도가 느릴 때 Clash의 로컬 설정을 확인하세요. 핵심은 스위치 열 개를 한꺼번에 바꾸는 것이 아니라, 한 번에 한 항목만 변경하고 재측정한 뒤 유지 여부를 결정하는 것입니다.

먼저 규칙 모드와 글로벌 모드 비교하기

클라이언트의 「프록시」 또는 「모드」 화면에서 Rule을 Global로 임시 전환하고 같은 노드로 테스트하세요. 글로벌 모드가 확실히 빠르다면 규칙 모드에서 속도 측정 도메인이 DIRECT로 연결되거나, 다른 정책 그룹이 선택되었거나, 적절하지 않은 규칙이 적용됐을 가능성이 있습니다. 테스트가 끝나면 Rule로 되돌리고 연결 로그에서 규칙 적중 결과를 확인하세요.

규칙은 위에서 아래로 매칭되며 한 번 적중하면 더 이상 진행하지 않습니다. 도메인 규칙, 규칙 세트, GEO 계열 규칙의 순서가 적절하지 않으면 대상 웹사이트가 잘못된 출구로 연결될 수 있습니다. 다운로드 사이트 도메인은 직접 연결되지만 리소스 도메인은 프록시를 거치면 페이지는 정상적으로 열려도 파일 다운로드가 느려질 수 있습니다.

빈번한 상태 점검 줄이기

노드 상태 점검이 대역폭을 바로 모두 사용하는 것은 아니지만, 노드가 많고 간격이 짧으면 네트워크 확장을 계속 깨우고 추가 연결을 만듭니다. 노드 80개가 포함된 정책 그룹을 30초마다 점검하도록 설정하면 한 시간에 최대 9,600건의 요청이 발생할 수 있습니다. 일상적인 사용에서는 interval을 먼저 600초로 늘리고, 규칙 제공자 업데이트 간격은 86400초로 설정할 수 있습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 노드 A
      - 노드 B
      - 노드 C
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

rule-providers:
  common:
    type: http
    behavior: classical
    path: ./ruleset/common.yaml
    url: https://example.com/rules/common.yaml
    interval: 86400

테스트 주소는 안정적이고 응답 내용이 작으며 현재 네트워크에서 접속 가능한 URL을 선택해야 합니다. 여러 대형 정책 그룹에 30초 또는 60초 주기의 점검을 동시에 설정하지 마세요. 클라이언트에서 「설정」→「매개변수 설정」→「상태 점검」 경로를 제공한다면 사용하지 않는 정책 그룹의 자동 테스트를 먼저 끌 수 있습니다.

TUN 모드와 MTU 확인

TUN 모드는 더 많은 시스템 트래픽을 인계하므로 투명 프록시가 필요한 앱에 적합하지만, 잘못된 MTU는 패킷 분할, 재전송 또는 일부 웹사이트의 느린 로딩을 일으킬 수 있습니다. 일반적으로 1500, 1400, 1280을 테스트합니다. 여러 값을 한꺼번에 건너뛰지 말고 현재 설정을 기록한 뒤 1400으로 바꿔 다시 측정하세요. 문제가 셀룰러 네트워크나 특정 WireGuard 경로에서만 발생한다면 1280도 테스트할 수 있습니다.

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  strict-route: false

이 작성 방식은 Clash.Meta 또는 mihomo 설정 문법을 지원하는 클라이언트에 적용됩니다. 구버전 Clash 코어는 모든 필드를 지원하지 않을 수 있습니다. iOS 클라이언트에서는 해당 옵션이 그래픽 인터페이스의 「설정」→「매개변수 설정」→「TUN」에 있을 수도 있습니다. 변경 후에는 시스템 VPN 연결을 끊었다가 다시 연결해 네트워크 확장이 설정을 새로 불러오게 하세요.

중복 프록시가 없는지 확인

iOS에서는 일반적으로 한 번에 하나의 주요 VPN 설정만 활성화할 수 있지만, 브라우저 프록시, 공유기 프록시, Clash가 여러 단계의 전달 구조를 만들 수 있습니다. iOS 「설정」→「일반」→「VPN 및 기기 관리」→「VPN」으로 이동해 예상한 클라이언트가 연결되어 있는지 확인하세요. 그런 다음 「설정」→「Wi-Fi」→현재 네트워크→「프록시 구성」을 열고, 평소 Clash가 트래픽을 관리한다면 일반적으로 “끔”으로 유지해야 합니다.

DNS 지연과 대역폭 저하는 따로 처리하기

DNS는 주로 도메인 확인과 최초 연결에 영향을 줍니다. 대표적인 증상은 URL을 입력한 뒤 몇 초를 기다려야 하지만 페이지가 로드되기 시작하면 이미지와 동영상 속도는 정상인 경우입니다. 대용량 파일 다운로드가 시작된 뒤에도 수백 KB/s에 머문다면 DNS만 바꿔서는 지속적인 대역폭 병목을 해결하기 어렵습니다.

IP와 도메인별 동작으로 판단하기

• 모든 웹사이트의 첫 로딩만 느리고 새로 고침 후 빨라짐: DNS 타임아웃과 캐시를 먼저 확인하세요.
• 특정 도메인만 느림: 해당 도메인의 규칙 적중, IPv6 결과, CDN 경로를 확인하세요.
• 속도 측정 사이트의 지연 시간은 정상인데 다운로드가 느림: 노드와 경로 계층으로 돌아가 점검하세요.
• 로그에 DNS timeout이 반복됨: 접속 가능한 nameserver로 바꾸고 리스닝 주소를 확인하세요.

mihomo 문법을 지원하는 설정이라면 먼저 간단한 DNS 설정으로 비교 테스트를 진행할 수 있습니다. 다음 예시는 fake-ip를 활성화하고 두 개의 명시적인 DNS 서버를 주解析 서버로 사용하며 fallback을 과도하게 중첩하지 않습니다. 공용 DNS에 대한 접근성은 네트워크마다 다르므로 현재 지역에서 실제로 측정한 결과를 기준으로 판단하세요.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 223.5.5.5
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

1053은 Clash DNS에서 자주 사용하는 로컬 리스닝 포트 예시이며 외부 DNS 서비스 포트가 아닙니다. 클라이언트가 DNS를 자동으로 관리한다면 다른 로컬 서비스가 같은 포트를 사용하지 않게 하세요. 변경 전에 「설정」→「매개변수 설정」→「DNS」에서 현재 값을 저장하고, 테스트가 끝난 뒤 결과에 따라 복원 여부를 결정하세요.

IPv6만 따로 테스트하기

일부 네트워크는 AAAA 레코드를 반환하지만 실제 IPv6 경로 품질이 낮아 웹사이트가 먼저 대기한 뒤 IPv4로 돌아갈 수 있습니다. 비교를 위해 dns.ipv6을 false로 임시 설정해 보세요. 끈 뒤 첫 로딩 속도가 확실히 개선된다면 모든 문제를 노드 탓으로 돌리기보다 로컬 IPv6, 노드의 IPv6 지원, 대상 사이트의 IPv6 경로를 추가로 확인해야 합니다.

결과에 따라 다음 조치 선택하기

3단계 테스트를 마쳤다면 무작위로 설정을 계속 바꾸지 말고 비교 데이터에 따라 처리하세요. 다음 대응표를 이용하면 원인 범위를 빠르게 좁힐 수 있습니다.

최소 설정으로 최종 격리 테스트하기

문제가 여전히 확인되지 않는다면 노드 1개, 정책 그룹 1개, 규칙 2개만 포함한 임시 설정을 만들 수 있습니다. 리스닝 포트는 일반적으로 사용하는 7890을 지정하고 스크립트, 규칙 제공자, 트래픽 스니핑, 추가 상태 점검은 끄고 필요한 기능만 남기세요. 최소 설정에서 정상이라면 기존 설정에 충돌이나 추가 오버헤드가 있다는 뜻입니다. 최소 설정에서도 느리다면 노드, 경로, 기기 계층으로 돌아가 계속 점검해야 합니다.

mixed-port: 7890
mode: rule
log-level: info
ipv6: false

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 테스트 노드

rules:
  - MATCH,PROXY

테스트가 끝났다고 임시 설정을 그대로 장기 설정으로 사용하지 마세요. 임시 설정의 목적은 변수를 분리하는 것이며, 일상적으로 필요한 직접 연결, 로컬 네트워크, 개인정보 보호, 앱별 분기 규칙은 포함하지 않습니다. 기존 설정의 문제 범위를 확인한 뒤 DNS, 규칙 세트, TUN, 상태 점검을 그룹별로 복원하고 항목을 하나 복원할 때마다 같은 테스트를 진행하세요.

점검할 때 흔한 세 가지 오해

노드 지연 시간만 확인하기

지연 시간은 연결할 수 없거나 응답이 확연히 느린 노드를 걸러내는 데 유용하지만 대역폭, 패킷 손실, 저녁 피크 부하를 나타내지는 않습니다. 최소 30초 이상 지속되는 다운로드 테스트를 한 번은 추가하세요.

DNS, MTU, 규칙을 동시에 변경하기

여러 항목을 한 번에 바꾸면 속도가 회복되더라도 어떤 변경이 효과가 있었는지 알 수 없습니다. 올바른 방법은 기존 설정을 저장하고 한 번에 변수 하나만 바꾼 뒤 변경 전후 3회 결과를 기록하는 것입니다.

글로벌 모드를 장기적인 속도 향상 스위치로 사용하기

글로벌 모드는 비교 테스트에 적합할 뿐, 더 많은 트래픽을 같은 프록시로 통과시킨다고 해서 본질적으로 빠른 것은 아닙니다. 규칙 적중 문제가 원인임을 확인했다면 규칙이나 정책 그룹을 수정한 뒤 Rule 모드로 돌아가세요.