Clash 속도 느릴 때 해결 방법: 노드·네트워크 경로·로컬 설정 점검

먼저 테스트 조건을 고정하세요: 지연 시간, 처리량, 첫 화면 대기 시간 구분

먼저 트래픽 경로를 확인하고, 노드와 네트워크 경로를 비교한 다음, 마지막으로 로컬 연결 설정과 DNS를 조정하세요.Clash 패널에 표시되는 밀리초 값은 다운로드 속도가 아닙니다. 노드 지연 시간은 보통 지정된 테스트 주소에 요청을 한 번 보내 측정하며, 연결 재사용 여부와 대상 사이트, 테스트 방식에 따라서도 달라집니다. 따라서 대용량 파일 전송 성능을 그대로 나타내지는 않습니다.

먼저 ‘느리다’는 증상을 반복해서 확인할 수 있도록 구체적으로 적어 두세요. 예를 들어 ‘같은 영상이 1080p에서 자주 끊긴다’, ‘웹페이지를 처음 열 때는 5초 기다리지만 새로고침은 빠르다’, ‘다운로드 초반은 정상인데 이후 계속 느려진다’처럼 기록하면 됩니다. 증상마다 확인할 부분이 다르므로 규칙, DNS, TUN을 한꺼번에 바꾸지 마세요.

반복 테스트에 쓸 기록 만들기

• 클라이언트 버전과 실제 사용 중인 코어의 이름 및 버전을 기록하세요. 클라이언트 화면에 표시되는 버전은 mihomo 코어 버전과 다를 수 있습니다.
• 다운로드 파일, 웹페이지, 노드를 하나씩 정해 두고 클라우드 동기화, 시스템 업데이트, 다른 속도 측정 작업은 일시 중지하세요.
• 매회 30~60초 동안 테스트하고 세 번 반복하세요. 테스트 시간, 네트워크 유형, 노드, 적용된 규칙, 지속 속도를 기록합니다.
• 단위를 구분하세요. 100 Mbps는 이론상 12.5 MB/s이며, 실제 전송 속도는 프로토콜 오버헤드만큼 낮아집니다.

1단계: 노드의 지속 전송 성능 확인

클라이언트의 ‘프록시’ 또는 ‘프록시 그룹’ 화면에서 먼저 특정 노드를 선택하세요. 자동 선택 그룹은 테스트 중 구성원을 바꿀 수 있습니다. 같은 정책 그룹에서 테스트한 것처럼 보여도 실제로는 출구가 달랐을 수 있습니다. ‘자동 선택’이라고만 적기보다 최종 선택된 노드 이름을 기록하는 편이 유용합니다.

지연 시간이 짧다고 다운로드 속도가 빠른 것은 아닙니다

예를 들어 노드 A의 테스트 지연 시간은 45ms, 노드 B는 120ms라고 해도 A가 동영상 재생에 더 적합하다고 단정할 수는 없습니다. A는 대역폭이 제한되거나 출구가 혼잡할 수 있고, B는 지속 전송 속도가 더 안정적일 수 있습니다. 여기의 수치는 비교 방법을 설명하기 위한 예시이며, 사이트에서 직접 측정한 결과가 아닙니다.

1. 같은 수동 선택 그룹에서 노드 A를 고르고, 정해 둔 대상에 접속해 지속 속도를 세 번 기록하세요.
2. 모드와 DNS는 그대로 두고 노드만 B로 바꿔 같은 테스트를 반복하세요.
3. 출처가 다른 다운로드 대상도 테스트하세요. 특정 사이트만 느리다면 대상 CDN, 계정별 속도 제한, 해당 사이트와 출구 간 연결을 먼저 확인하세요.
4. 구독 서비스의 잔여 데이터, 만료일, 기기 제한을 확인하세요. 설정을 가져올 수 있다고 해서 서버에서 정상적으로 계속 사용할 수 있다는 뜻은 아닙니다.

모든 노드에서 대용량 속도 측정을 동시에 실행하지 마세요. 동시 측정은 로컬 대역폭을 나눠 쓰고 구독 데이터를 소모할 수 있습니다. 노드 목록의 연결 테스트는 접속 불가 항목을 빠르게 걸러내는 용도입니다. 처리량을 비교하려면 노드를 하나씩 테스트해야 결과를 해석하기 쉽습니다.

프로토콜을 바꿀 때는 서버 조건을 맞춰 비교하세요

지원 프로토콜은 코어, 노드 설정, 서버 모두에 따라 달라집니다. 서비스 제공자가 해당 프로토콜 접속 지점을 제공해야 비교할 수 있으며, 구독의 유형 필드를 임의로 다른 프로토콜로 바꾸면 안 됩니다. 공정하게 비교하려면 같은 서비스 제공자와 비슷한 지역, 같은 대상과 시간대를 유지하고 제공되는 접속 지점끼리 테스트하세요.

현재 네트워크에서 UDP 기반 접속은 불안정하고 TCP 접속은 안정적이라면, 이는 네트워크 경로에 차이가 있다는 단서일 뿐입니다. 원본 Clash, Clash Meta, mihomo는 지원하는 프로토콜이 완전히 같지 않습니다. ‘지원하지 않는 프록시 유형’ 오류가 발생하면 비밀번호나 노드 이름을 계속 바꾸기보다 먼저 코어를 확인하세요.

2단계: 로컬 접속, 네트워크 경로, 출구 혼잡 구분

노드에 연결되지만 저녁에 속도가 눈에 띄게 떨어진다면 경로의 특정 구간이 혼잡한 경우가 흔합니다. 전체 경로는 최소한 기기에서 라우터까지, 현지 통신사에서 노드까지, 노드 출구에서 대상 사이트까지로 나뉩니다. 노드 서버의 지연 시간만 측정해서는 전체 경로를 확인할 수 없습니다.

두 가지 비교 테스트로 문제 범위 좁히기

• 같은 기기에서 네트워크 변경: 컴퓨터를 집 인터넷과 휴대전화 핫스팟에 각각 연결하고 노드와 대상은 그대로 유지하세요. 핫스팟에서는 정상인데 집 인터넷에서만 문제가 생기면 인터넷 경로, 라우터, Wi-Fi를 중점적으로 확인하세요.
• 같은 네트워크에서 시간대 변경: 비혼잡 시간대와 저녁에 각각 세 번 측정하세요. 여러 노드가 저녁 시간대에만 느려진다면 다른 서비스 제공자나 접속 회선과 비교해 보세요.
• 같은 출구에서 대상 변경: 한 대상만 느리고 다른 대상은 정상이라면 대상 서비스의 지역별 연결, 출구 IP 제한, CDN 경로를 확인하세요.
• 같은 네트워크에서 유선으로 변경: 유선은 안정적인데 무선에서만 끊긴다면 먼저 무선 신호와 채널 간섭을 해결하세요. 노드를 바꿔도 무선 구간의 패킷 손실은 해결되지 않습니다.

Windows에서는 ping -n 20 192.168.1.1, macOS 또는 Linux에서는 ping -c 20 192.168.1.1을 실행해 로컬 게이트웨이 연결이 안정적인지 확인할 수 있습니다. 여기서는 게이트웨이가 192.168.1.1이라고 가정합니다. 실제 주소는 시스템 네트워크 설정에서 확인하세요. 게이트웨이가 ICMP에 응답하지 않는다면 시간 초과만으로 네트워크가 끊겼다고 판단해서는 안 됩니다.

tracert 또는 traceroute로 경로를 파악할 수 있지만, 일반 명령의 트래픽이 앱 프록시를 통과하거나 동영상과 같은 전송 방식을 사용하는 것은 아닙니다. 중간 라우터가 ICMP 응답을 제한할 수도 있으므로 특정 홉에서 응답이 없더라도 이후 홉이 정상이라면 그 라우터가 실제 서비스 트래픽을 버린다고 볼 수 없습니다.

3단계: 규칙 적용과 앱 연결 여부 확인

클라이언트의 ‘연결’ 화면으로 이동하세요. 일부 인터페이스에서는 ‘활성 연결’이라고 표시됩니다. 필터를 초기화한 뒤 대상 웹페이지를 다시 여세요. 대상 도메인 또는 IP, 적용 규칙, 정책 경로, 최종 아웃바운드를 확인합니다. 규칙 모드는 순서대로 일치 여부를 확인하므로 일반 규칙 목록에서는 앞선 규칙이 뒤에 있는 규칙의 적용 여부에 영향을 줍니다.

규칙 모드와 전역 모드를 짧게 비교 테스트

1. ‘프록시’ 화면에서 현재 정책 그룹에 선택된 노드를 기록하세요.
2. 규칙 모드에서 대상 연결의 실제 아웃바운드를 기록하세요. 의도치 않게 DIRECT가 적용되지는 않았는지, 다른 그룹의 느린 노드가 선택되지는 않았는지 확인합니다.
3. 전역 모드로 잠시 전환한 뒤 전역 정책에서 같은 노드를 선택하세요.
4. 대상 앱의 기존 연결을 종료하고 요청을 새로 보내세요. 모드를 전환해도 이미 열린 연결이 곧바로 새 경로를 사용하는 것은 아닙니다.
5. 테스트 후 규칙 모드로 되돌리세요. 전역 모드는 정상이고 규칙 모드에서만 문제가 생긴다면 규칙과 정책 선택을 먼저 수정하세요.

전역 모드가 기기의 모든 트래픽을 자동으로 연결하는 것은 아닙니다. 전역 모드는 트래픽이 코어에 들어온 뒤 어떤 아웃바운드를 사용할지 결정합니다. 앱이 코어로 들어오는지는 시스템 프록시, 앱 자체의 프록시 설정, TUN 연결 여부에 달려 있습니다. 브라우저는 정상인데 게임이나 명령줄 앱에서 문제가 생긴다면 노드가 고장 났다고 단정하지 말고 먼저 트래픽이 들어오는 경로를 확인하세요.

명시적 프록시로 시스템 프록시 설정 차이 우회

아래 명령은 로컬 HTTP 또는 mixed 프록시 포트 7890를 통해 작은 페이지를 요청합니다. 먼저 클라이언트에서 실제 포트를 확인하세요. SOCKS 전용 포트에는 이 명령을 그대로 사용할 수 없습니다. Windows PowerShell에서는 일부 환경에서 curl이 다른 명령으로 해석될 수 있으므로 curl.exe를 사용하세요. macOS와 Linux에서는 curl을 사용합니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output /dev/null --silent --show-error --write-out "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Windows에서는 명령 앞부분을 curl.exe로 바꾸고 /dev/null을 NUL로 변경하세요. 예시 주소는 요청이 완료되는지 확인하기 위한 용도이며, 대역폭 측정에는 적합하지 않습니다. 명시적 프록시를 사용할 때 time_connect는 주로 로컬 프록시에 연결하는 시간을 나타냅니다. 첫 바이트까지 걸린 시간에는 프록시 터널 수립, 원격 연결, 서버 응답까지 포함되므로 이를 ‘노드 지연 시간’이라고 할 수는 없습니다.

DNS 점검: 첫 페이지 접속 지연과 해석 경로 차이

웹페이지를 처음 열 때는 느리지만 새로고침하면 빨라지는 경우 DNS가 원인일 수 있습니다. 다만 TLS 연결 수립이나 웹 캐시도 비슷한 현상을 일으킵니다. 먼저 ‘로그’ 화면에서 로그 수준을 일시적으로 debug로 설정한 다음 문제를 한 번 재현하세요. 대상 도메인의 이름 해석 실패, 시간 초과, 반복 요청을 확인합니다. 점검이 끝나면 로그가 과도하게 쌓이지 않도록 원래 수준으로 되돌리세요.

시스템 DNS와 코어 DNS 구분

시스템에서 실행한 nslookup example.com 결과가 mihomo 내부에서 사용되는 결과와 같다고 볼 수는 없습니다. 브라우저에서 보안 DNS를 사용할 수도 있고, 코어에서 fake-ip를 활성화했거나 TUN에 DNS 가로채기가 설정되어 있을 수도 있습니다. 먼저 요청을 어느 구성요소가 해석하는지 확인한 뒤 해당 계층을 조정하세요.

• fake-ip 사용 중: 흔히 쓰이는 198.18.0.0/16은 매핑 주소 범위입니다. 이 범위의 주소가 보인다고 DNS가 손상된 것은 아닙니다. 매핑과 연결이 정상인지 계속 확인하세요.
• DoH 사용 중: 리졸버 주소를 해석하고 연결하는 경로에 접근할 수 있어야 합니다. 프록시 노드 도메인을 해석하는 데 아직 연결되지 않은 프록시 연결에 의존하지 않도록 하세요.
• IPv6 사용 중: 시스템의 IPv6 연결, 대상의 AAAA 레코드, 트래픽 연결 설정을 확인하세요. 명확한 비교 테스트에서만 특정 계층의 IPv6를 일시적으로 끄고 테스트가 끝나면 다시 켜세요.
• 구독 설정 수정: 클라이언트가 지원하는 덮어쓰기나 확장 기능을 우선 사용하세요. 구독에서 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 사라질 수 있습니다.

DNS 설정 전체를 한꺼번에 가져와 적용하지 마세요. nameserver, proxy-server-nameserver 등의 필드가 지원되는지는 코어와 버전에 따라 확인해야 합니다. DNS 서버를 바꾼 뒤에는 대상 연결을 새로 만드세요. 웹페이지를 새로고침하는 것만으로 시스템, 브라우저, 코어의 캐시가 전부 지워지지는 않을 수 있습니다.

TUN과 로컬 성능: 트래픽 연결 경로에 문제가 있을 때만 조정

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 연결하므로 시스템 프록시 설정을 따르지 않는 앱을 처리할 때 유용하지만, 속도를 높이는 기능은 아닙니다. 명시적 프록시는 정상인데 TUN을 켠 뒤 모든 앱이 느려진다면 라우팅, DNS 가로채기, 다른 네트워크 프로그램과의 충돌을 중점적으로 확인하세요.

다음 네 항목을 순서대로 확인

1. 권한 및 서비스: 클라이언트에서 요구하는 서비스 모드나 관리자 권한이 활성화되어 있는지 확인하고, 로그에서 인터페이스 생성이나 경로 추가 실패 여부를 살펴보세요.
2. 중복 연결: 다른 VPN이나 프록시 클라이언트를 잠시 종료하고 트래픽 연결 지점을 하나만 남긴 뒤 다시 테스트하세요. 시스템 방화벽을 계속 꺼 두지는 마세요.
3. 프로세스 사용량: Windows ‘작업 관리자’ 또는 macOS ‘활성 상태 보기’에서 클라이언트와 코어 프로세스를 확인하세요. 전송 중 코어 하나가 계속 최대 사용량을 보인다면 로그 수준, 규칙 수, 코어 버전을 비교하세요.
4. MTU와 UDP: 작은 웹페이지는 열리지만 대용량 전송이 멈추거나 QUIC을 사용하는 앱만 문제가 생긴다면 경로 MTU, UDP 전달 여부, 관련 로그를 확인하세요. 특정 MTU 값을 모든 네트워크에 통하는 정답으로 여기지 마세요.

설정 기능을 지원하는 브라우저라면 QUIC을 잠시 끄고 브라우저를 완전히 종료한 뒤 다시 실행해 TCP 경로가 나아지는지 확인할 수 있습니다. 개선되더라도 UDP 경로를 더 점검할 필요가 있다는 뜻일 뿐, 특정 프로토콜이 반드시 더 빠르다는 증거는 아닙니다. 테스트가 끝나면 원래 설정으로 되돌려 임시 조치가 상시 설정으로 남지 않도록 하세요.

마무리: 확인된 근거에 따라 조치하고 설정을 무작정 추가하지 않기

문제를 문의할 때는 클라이언트와 코어 버전, 운영체제, 네트워크 유형, 발생 시간, 재현 절차, 민감 정보를 가린 로그를 함께 제공하세요. 공유 전에 구독 주소, 액세스 토큰, 노드 비밀번호, 관리 인터페이스 키를 삭제하세요. 설정 파일 전체를 그대로 공개하지 마세요.

클라이언트 선택은 선택 가이드를, 시스템 프록시와 TUN의 기본 설정은 사용 안내를 참고하세요. 최종 목표는 반복 테스트로 확인할 수 있는 차이를 찾는 것입니다. 어떤 노드, 네트워크 구간, 규칙, 트래픽 연결 방식이 속도 저하를 일으키는지 확인하세요. 원인을 찾으면 필요한 설정만 남기고 처음 사용한 테스트 대상들로 다시 측정하세요.