Clash Android 느린 속도 해결 방법: 노드·회선·로컬 설정 3단계 점검

먼저 재현 가능한 속도 측정 기준을 만들기

Clash에 “연결됨”이라고 표시되는 것은 Android VPN 인터페이스 또는 로컬 프록시가 시작되었다는 뜻일 뿐, 현재 노드가 안정적인 처리량을 제공한다는 의미는 아닙니다. 점검 전에 테스트 조건을 고정해야 합니다. 그렇지 않으면 Wi-Fi, 모바일 네트워크, 노드, 대상 웹사이트가 동시에 바뀌어 속도 저하가 어느 단계에서 발생했는지 판단하기 어렵습니다.

네 가지 결과로 문제 범위 구분하기

Clash를 끄고 현재 Wi-Fi에서 한 번 속도를 측정한 뒤 다운로드, 업로드, 유휴 상태 지연 시간을 기록합니다.
같은 Wi-Fi를 유지한 채 Clash를 실행하고 현재 노드를 선택해 다시 측정합니다.
Clash를 계속 켜 둔 상태에서 다른 지역, 다른 프로토콜 또는 다른 회선으로 전환한 뒤 다시 측정합니다.
Wi-Fi를 끄고 4G 또는 5G를 사용해 현재 노드와 대체 노드 테스트를 반복합니다.

각 조건은 최소 두 번씩, 한 번에 20~30초 동안 측정합니다. 속도 측정 서버, 측정 시간대, 대상 파일은 동일하게 유지해야 합니다. 다운로드 속도의 단위도 통일하세요. 100 Mbps는 약 12.5 MB/s이며, 브라우저에 8 MB/s로 표시될 때 회선 속도는 약 64 Mbps입니다. MB/s와 통신사가 표시한 Mbps를 그대로 비교하면 안 됩니다.

테스트 조건	예시 결과	우선 판단
Clash 끄기, Wi-Fi 속도 측정	286 Mbps, 지연 시간 18 ms	로컬 인터넷 회선 기준 정상
Clash 켜기, 노드 A	22 Mbps, 지연 시간 96 ms	노드 또는 중계 회선 제한 가능성
Clash 켜기, 노드 B	173 Mbps, 지연 시간 72 ms	클라이언트 설정은 대체로 정상이며 노드 A에 문제
모바일 네트워크, 노드 A	118 Mbps, 지연 시간 88 ms	가정용 인터넷에서 노드 A로 가는 경로가 혼잡할 가능성

1단계: 노드 품질과 프록시 그룹 선택 확인

같은 네트워크에서 일부 노드만 느리다면 문제는 대개 노드 단계에 있습니다. 흔한 원인으로는 높은 노드 부하, 부족한 출구 대역폭, 프로토콜 핸드셰이크 재전송, 구독에서 만료된 노드, 화면에서 예상한 노드와 실제 선택된 노드의 불일치 등이 있습니다.

프록시 화면에서 실제 출구 확인

일반적인 Clash Meta Android 클라이언트에서는 「프록시」 화면으로 들어가 규칙에서 참조하는 프록시 그룹을 펼친 다음 선택 표시가 있는 실제 노드를 확인할 수 있습니다. 최상위 그룹 이름만 보지 마세요. 예를 들어 규칙이 「노드 선택」을 가리키고, 「노드 선택」 내부에서 다시 「자동 선택」을 참조한다면 최종 출구는 URL Test에 의해 자동으로 바뀔 수 있습니다. 방금 수동으로 선택한 지역이 실제 출구가 아닐 수 있습니다.

「프록시」→ 현재 프록시 그룹으로 들어가 실제 선택된 노드 이름을 기록합니다.
오른쪽 상단의 속도 테스트 메뉴를 누르거나 프록시 그룹에서 지연 시간 테스트를 실행합니다.
서로 다른 세 지역 또는 회선 식별자를 가진 노드 세 개를 선택해 실제 다운로드 속도를 차례로 측정합니다.
측정 중에는 자동 전환을 꺼서 테스트 도중 출구가 바뀌지 않게 합니다.
「로그」로 들어가 대상 도메인이 예상한 규칙과 프록시 그룹에 매칭되었는지 확인합니다.

지연 시간 테스트 결과가 80 ms, 95 ms, 110 ms처럼 비슷하게 나왔다고 해서 가장 낮은 하나만 선택해서는 안 됩니다. 세 차례 연속 테스트했을 때 어떤 노드가 72 ms, 310 ms, 시간 초과로 나타난다면 지터가 큰 것입니다. 다른 노드가 105~118 ms로 안정적이라면 실제 웹과 동영상 사용 경험은 대체로 더 안정적입니다.

노드 부하와 속도 제한 확인

노드가 저녁 시간대에 느려졌다가 새벽에 회복된다면 노드 동시 접속 수나 상위 회선 혼잡과 관련 있을 가능성이 큽니다. 08:00, 20:00, 23:30에 같은 노드의 속도를 기록해 보세요. 다른 노드는 120 Mbps 이상을 유지하는데 결과가 160 Mbps에서 18 Mbps로 떨어진다면 Android 설정을 반복해서 수정하기보다 노드를 먼저 바꾸는 것이 좋습니다.

또 다른 전형적인 특징은 작은 파일은 정상적으로 열리지만 큰 파일 다운로드가 일정한 속도에서 멈추는 경우입니다. 웹페이지 첫 화면은 빠른데 다운로드가 계속 2.0 MB/s 안팎에 머문다면 노드 측 대역폭 배분, 구독 요금제의 속도 제한 또는 단일 연결 제한일 수 있습니다. 서로 다른 출처의 큰 파일 두 개를 테스트하고 다중 연결을 지원하는 다운로드 작업도 시도하면 대상 사이트의 제한인지 노드 전체 처리량 부족인지 구분할 수 있습니다.

구독 업데이트 후 만료된 항목 제외

「구성」 화면에서 현재 구독을 업데이트한 뒤 구성을 다시 선택합니다. 구독 제공업체가 서버 주소를 변경했는데 휴대폰이 캐시된 구성을 계속 사용하면 기존 노드가 간헐적으로만 연결되거나, 핸드셰이크가 느리거나, 속도가 매우 낮게 나타날 수 있습니다. 업데이트 후에는 프록시 그룹도 다시 확인하세요. 노드 이름이 바뀌면서 기존 수동 선택이 첫 번째 항목으로 돌아갈 수 있습니다.

2단계: 통신사 회선과 망 간 혼잡 판단

노드 자체는 정상인데 가정용 Wi-Fi에서만 뚜렷하게 느리고 모바일 네트워크에서는 회복된다면, 문제는 로컬 통신사와 프록시 입구 사이에 있을 수 있습니다. 두 노드가 같은 지역에 있어도 입구 통신사, 중계 방식, 귀환 경로는 완전히 다를 수 있습니다.

네트워크 전환으로 입구 경로 확인

가장 효과적인 비교 방법은 Clash를 반복해서 재시작하는 것이 아니라 노드는 그대로 두고 접속 네트워크만 바꾸는 것입니다. 예를 들어 노드 C가 가정용 인터넷에서는 14 Mbps, 5G에서는 126 Mbps이고 Clash를 끈 상태에서는 두 네트워크 모두 약 200 Mbps가 나온다면, 휴대폰 성능이나 노드 출구가 주된 제한 요인일 가능성은 낮습니다. 가정용 인터넷에서 노드 입구로 이어지는 경로를 우선 의심해야 합니다.

Wi-Fi는 느리고 모바일 네트워크는 빠름: 가정용 인터넷의 망 간 경로, 라우터, IPv6를 확인합니다.
Wi-Fi와 모바일 네트워크 모두 느림: 노드 부하, 프로토콜 또는 클라이언트 설정을 확인합니다.
특정 웹사이트만 느림: 규칙 매칭, 대상 사이트의 출구 제한, DNS 결과를 확인합니다.
모든 노드가 저녁에 함께 느림: 로컬 접속망 또는 상위 중계 회선의 시간대별 혼잡일 수 있습니다.

직접 연결 규칙과 프록시 규칙 비교

「로그」 화면에서 속도가 이상한 웹사이트를 열고 연결 기록의 규칙 이름과 최종 정책을 확인합니다. 프록시로 보내야 할 도메인이 DIRECT에 매칭되면 트래픽이 로컬 통신사를 통해 직접 나갑니다. 반대로 직접 연결해야 할 대형 다운로드 사이트가 먼 노드로 보내지면 우회와 대역폭 소모가 늘어납니다.

예를 들어 규칙 세트가 소프트웨어 미러 사이트를 프록시 그룹으로 잘못 분류하면 원래 20 ms였던 로컬 경로가 “휴대폰 → 해외 노드 → 중국 본토 미러” 경로로 바뀔 수 있습니다. 이때 노드 속도 테스트는 정상인데 특정 사이트의 다운로드만 느립니다. 해당 도메인을 잠시 직접 연결 규칙에 추가한 뒤 다시 측정하면 분기 라인 문제인지 확인할 수 있습니다.

rules:
  - DOMAIN-SUFFIX,example-download.com,DIRECT
  - DOMAIN-SUFFIX,example-video.com,PROXY
  - MATCH,노드 선택

규칙을 수정할 때는 클라이언트의 오버라이드 기능이나 별도 규칙 제공자를 우선 사용하세요. 그래야 구독을 업데이트할 때마다 로컬 변경 사항이 사라지는 것을 막을 수 있습니다. 테스트가 끝나면 로그에서 도메인이 실제로 새 규칙에 매칭되었는지 확인하세요. 앞선 우선순위가 높은 규칙에 먼저 가로채인 것이 아니어야 합니다.

IPv4와 IPv6 경로 차이 확인

일부 네트워크에서는 IPv6 직접 연결 속도가 매우 좋지만 프록시 노드는 IPv4만 안정적으로 지원할 수 있습니다. 또는 DNS가 AAAA 레코드를 반환한 뒤 IPv6 연결이 시간 초과되고 IPv4로 폴백하는 경우도 있습니다. 보통 웹페이지 로딩 전에 2~5초 멈추지만 다운로드가 시작되면 속도는 정상적으로 나타납니다.

클라이언트의 「설정」→「네트워크」 또는 「설정」→「DNS」에서 IPv6 스위치를 확인하고 잠시 끈 뒤 다시 측정해 보세요. 클라이언트 버전에 따라 메뉴 이름은 조금 다를 수 있지만, 핵심은 DNS 해석과 mihomo 코어의 IPv6 지원 상태를 일치시키는 것입니다. 끈 뒤 첫 응답이 빨라진다면 라우터의 IPv6 프리픽스, DNS 응답, 노드 프로토콜 지원을 계속 확인하세요. 반복적인 재연결에 장기적으로 의존할 필요는 없습니다.

3단계: Android 로컬 설정 점검

여러 노드와 Wi-Fi, 모바일 네트워크에서 모두 비슷하게 낮은 속도가 나온다면 휴대폰 로컬 환경을 확인해야 합니다. Android의 절전 정책, VPN 충돌, TUN 매개변수, DNS, MTU, 기타 네트워크 도구가 mihomo 코어의 데이터 송수신에 영향을 줄 수 있습니다.

백그라운드 및 절전 제한 해제

Android 「설정」→「앱」→ 현재 Clash 클라이언트 →「배터리」로 이동해 백그라운드 실행 허용 또는 제한 없음으로 설정합니다. 이어서 「모바일 데이터 및 Wi-Fi」에서 백그라운드 데이터가 허용되었는지 확인합니다. 제조사별 경로는 「설정」→「배터리」→「앱 배터리 관리」일 수 있습니다. 절전 모드는 백그라운드 CPU와 네트워크 활동을 제한하며, 화면이 꺼졌을 때 특히 두드러집니다.

테스트할 때 5분 동안 화면을 켜 둔 다음 5분 동안 잠금 상태로 두고 같은 지속 다운로드 작업을 비교합니다. 화면이 켜져 있을 때 90 Mbps였다가 잠금 후 6 Mbps로 떨어지고 다시 켜면 회복된다면 백그라운드 스케줄링이 속도를 제한하는 것으로 볼 수 있습니다.

VPN 및 네트워크 도구 충돌 제외

Android에서는 일반적으로 같은 사용자 공간에서 시스템 VPN 인터페이스 하나만 활성화할 수 있습니다. 광고 차단기, 기업용 VPN, Private DNS 도구, 다른 프록시 클라이언트가 Clash와 인터페이스를 두고 경쟁할 수 있습니다. 시스템 「설정」→「네트워크 및 인터넷」→「VPN」에서 현재 활성 연결이 대상 클라이언트 하나뿐인지 확인하고, 항상 사용으로 설정된 다른 VPN이 있는지도 점검합니다.

Private DNS 자체가 반드시 처리량을 낮추는 것은 아니지만 서버에 연결할 수 없으면 도메인 해석을 기다리게 됩니다. 「설정」→「네트워크 및 인터넷」→「Private DNS」에서 잠시 자동으로 전환한 뒤 웹페이지 최초 실행 시간을 측정하세요. 다운로드 속도는 그대로인데 웹페이지 대기 시간이 4초에서 1초 미만으로 줄었다면 문제는 노드 대역폭이 아니라 DNS에 있습니다.

시스템 프록시와 TUN 모드 비교

시스템 프록시 모드는 Android 프록시 설정을 따르는 앱만 처리합니다. 일부 게임, QUIC 트래픽, 자체 네트워크 스택을 구현한 앱은 우회할 수 있습니다. TUN 모드는 Android VPN 인터페이스를 통해 더 넓은 범위의 트래픽을 가로채지만 가상 네트워크 카드 처리 계층이 추가됩니다. 점검할 때 노드, DNS, TUN을 동시에 바꾸지 말고 변수 하나만 전환하세요.

「설정」→「네트워크」 또는 「설정」→「TUN」에서 현재 상태를 기록합니다.
같은 노드를 사용해 일반 VPN 인계 방식으로 30초 동안 속도를 측정합니다.
TUN을 활성화한 뒤 Android VPN 권한을 다시 부여하고 같은 테스트를 실행합니다.
다운로드 속도, 업로드 속도, 지연 시간, 대상 앱이 제대로 인계되었는지를 비교합니다.

일반 모드가 140 Mbps인데 TUN 모드가 38 Mbps뿐이라면 MTU, 프로토콜 스택, DNS 가로채기를 계속 확인해야 합니다. 곧바로 노드 문제라고 단정하지 마세요. 반대로 브라우저는 정상인데 특정 앱만 프록시를 사용하지 않는다면 TUN 모드가 해결하는 것은 회선 속도가 아니라 트래픽 인계 범위일 수 있습니다.

MTU를 조정해 패킷 분할 문제 해결

MTU가 맞지 않으면 패킷이 분할되거나 버려질 수 있습니다. 작은 웹페이지는 정상인데 이미지와 동영상이 멈추거나 업로드 속도가 비정상적으로 낮아지는 것이 흔한 증상입니다. TUN의 일반적인 MTU는 1500부터 테스트할 수 있으며, 모바일 네트워크, 추가 터널, 일부 광대역 환경에서는 1480, 1420, 1400을 차례로 시험해 보세요. 매번 값 하나만 바꾸고 코어를 완전히 중지한 뒤 다시 시작해야 합니다.

MTU 1500에서 업로드가 0.8 Mbps뿐이었다가 1400으로 바꾼 후 18 Mbps로 안정되고 다운로드 변화가 크지 않다면 더 안정적인 값을 유지할 수 있습니다. MTU가 지나치게 낮으면 헤더 오버헤드가 늘어나므로 바로 아주 작은 값으로 낮추지 말고 20~40바이트 단위로 찾아야 합니다.

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

사용 가능한 구성 필드는 클라이언트에 통합된 mihomo 코어 버전에 따라 달라집니다. 오버라이드를 사용하기 전에 「정보」 또는 「설정」→「코어」에서 버전 번호를 기록하세요. 예를 들어 클라이언트 2.11.15, mihomo 1.19.12처럼 기록한 뒤 수정 후 로그에 unknown field, parse error, TUN create failed가 나타나는지 확인합니다.

DNS 지연과 실제 대역폭 저하는 구분해서 처리

DNS 문제는 흔히 “인터넷이 느리다”라고 표현되지만, 주로 연결이 수립되기 전의 해석 단계에 영향을 줍니다. 주소를 입력한 뒤 몇 초간 기다리지만 페이지가 로딩되기 시작하면 빠르고, 이미 연결된 동영상 스트림과 대용량 파일 다운로드는 대체로 정상인 것이 전형적인 증상입니다.

첫 응답 대기 시간과 지속 다운로드 관찰

새 도메인을 처음 열 때만 느리고 새로 고침 후에는 빠름: DNS 캐시와 상위 DNS 해석을 우선 확인합니다.
도메인 해석은 빠르지만 대용량 파일이 계속 느림: 노드와 회선 처리량을 우선 확인합니다.
일부 도메인이 잘못된 주소를 반환함: fake-ip, 규칙 세트, DNS 분기를 확인합니다.
TUN을 켠 뒤에만 해석 시간 초과 발생: DNS 가로채기와 포트 점유를 확인합니다.

mihomo 구성에서 흔히 사용하는 로컬 혼합 프록시 포트는 7890이고 SOCKS 포트는 7891일 수 있으며, DNS 수신 포트는 보통 1053입니다. 이 값들이 반드시 고정되어야 하는 것은 아니지만 같은 포트를 두 서비스가 동시에 사용할 수는 없습니다. 로그에 address already in use가 나타나면 다른 프록시, DNS 전달기 또는 이전 코어 프로세스를 확인하세요.

mixed-port: 7890

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

위 주소는 구성 구조를 설명하기 위한 예시일 뿐입니다. 실제 상위 DNS를 선택할 때는 현재 네트워크에서 연결 가능한지, 프록시를 통해 질의해야 하는지를 고려해야 합니다. DNS 요청 자체가 불안정한 노드로 전달되면 노드 혼잡에 따라 해석 시간도 늘어납니다.

프로토콜, 코어, 기기 성능 점검

구형 또는 저전력 기기에서는 고처리량 암호화, 규칙 매칭, TUN 전달이 CPU를 크게 사용할 수 있습니다. 속도를 측정할 때 시스템 배터리 화면이나 성능 모니터를 확인하세요. 특정 코어 하나가 계속 최대 사용률에 가깝고 속도가 일정 수준에서 고정되며 기기 온도까지 오르면 기기 처리 능력이 제한 요인일 수 있습니다.

지역이 아니라 프로토콜 비교

같은 서비스의 노드라도 서로 다른 전송 프로토콜을 사용할 수 있습니다. 테스트할 때 입구 지역이 가깝고 회선 등급은 같지만 프로토콜이 다른 노드를 선택하면 변수를 줄일 수 있습니다. 현재 모바일 네트워크에서 한 프로토콜은 패킷 손실이 잦고 다른 프로토콜은 안정적이라면 지연 시간 숫자만 보고 억지로 선택하지 말고 현재 네트워크에 맞는 노드를 유지하세요.

UDP와 QUIC도 별도로 관찰해야 합니다. TCP 기반 웹페이지가 정상이라고 해서 게임이나 HTTP/3까지 정상이라는 뜻은 아닙니다. 브라우저에서 QUIC를 잠시 끄거나 대상 도메인을 다른 노드로 보내 비교할 수 있습니다. QUIC를 끈 뒤 동영상 시작은 회복되지만 일반 다운로드에는 변화가 없다면 노드의 UDP 지원과 통신사 UDP 품질을 확인하세요.

코어 업데이트 전 테스트 기록 보관

클라이언트 버전과 mihomo 코어 버전은 프로토콜 구현, TUN 스택, DNS 동작에 영향을 줍니다. 업데이트 전에 Android 버전, 클라이언트 버전, 코어 버전, 현재 구성 업데이트 시각을 기록하세요. 업데이트 후 같은 노드와 같은 측정 조건으로 다시 테스트해야 변화가 소프트웨어 때문인지 네트워크 시간대 때문인지 판단할 수 있습니다.

업데이트 직후 전체적으로 속도가 떨어졌다면 「로그」에서 구성 호환성 오류를 확인하고 사용자 지정 오버라이드를 잠시 끄세요. 기존 구성의 폐기된 필드는 무시될 수도 있고 특정 모듈이 예상대로 시작되지 않게 만들 수도 있습니다. 기본 구독 구성으로 되돌린 후 속도가 정상이라면 DNS, TUN, 규칙 오버라이드를 하나씩 다시 추가해 충돌하는 필드를 빠르게 찾을 수 있습니다.

결과에 따른 최종 점검 순서

모든 설정을 한 번에 바꿀 필요는 없습니다. “노드 → 회선 → 로컬” 순서로 각 단계에서 변수 하나만 바꾸면 보통 15~30분 안에 범위를 좁힐 수 있습니다.

직접 연결 기준 기록: Clash를 끄고 Wi-Fi와 모바일 네트워크에서 각각 두 번씩 속도를 측정합니다.
실제 노드 확인: 「프록시」로 들어가 규칙에서 실제로 참조하는 프록시 그룹과 선택된 노드를 확인합니다.
노드 간 비교: 최소 세 개의 입구를 테스트하고 지연 시간, 다운로드, 업로드, 측정 시간대를 기록합니다.
구독 업데이트: 「구성」에서 현재 구독을 업데이트한 뒤 프록시 그룹 선택을 다시 확인합니다.
접속 네트워크 전환: 노드는 그대로 유지하고 Wi-Fi와 4G, 5G를 비교합니다.
규칙 로그 확인: 느린 대상이 예상한 DIRECT 또는 프록시 정책에 매칭되었는지 확인합니다.
Android 제한 확인: 백그라운드 배터리 제한을 해제하고 다른 VPN과 네트워크 도구를 중지합니다.
DNS와 처리량 구분: 첫 응답 대기 시간과 지속 다운로드를 비교해 해석 지연을 낮은 대역폭으로 오해하지 않습니다.
TUN 비교: 같은 조건에서 모드를 전환하고 필요하면 1500, 1480, 1420, 1400 MTU를 테스트합니다.
버전과 오버라이드 확인: 클라이언트와 mihomo 버전을 기록하고 사용자 지정 항목을 끈 뒤 다시 테스트합니다.

최종 판단은 세 가지로 정리할 수 있습니다. 특정 노드만 느리면 노드 품질을 바로 점검합니다. 같은 노드가 네트워크에 따라 크게 다르면 통신사 경로와 라우터를 중점적으로 확인합니다. 모든 노드와 모든 네트워크가 느리면 Android 백그라운드 제한, TUN, DNS, MTU, 코어 버전, 기기 성능을 우선 점검합니다. 테스트 표를 남겨 두는 편이 반복해서 연결을 끊었다가 다시 연결하는 것보다 효과적이며, 구독이나 네트워크 환경이 바뀐 뒤에도 쉽게 재확인할 수 있습니다.