Clash 속도 저하 해결 방법: 노드·라우팅·기기 설정 점검

테스트 조건부터 고정하세요: 지연 시간, 첫 바이트, 다운로드 속도를 따로 기록

Clash 대시보드에 표시되는 지연 시간은 대역폭이 아닙니다. URL 지연 시간 테스트는 해당 노드를 통해 지정된 테스트 주소에 접속할 때 걸리는 시간을 나타내며, 측정 범위는 클라이언트와 코어 구현에 따라 다릅니다. 이 결과만으로 대용량 파일 다운로드 속도나 모든 웹사이트의 이용 환경을 판단할 수는 없습니다. “노드 지연 시간은 80ms인데 동영상이 계속 버퍼링된다”면 지연 시간 순으로만 비교하지 말고 연결 수립, 첫 바이트 도착, 지속 전송 속도를 각각 확인해야 합니다.

이 글은 Clash 또는 mihomo 코어를 사용하는 클라이언트에 해당합니다. Clash Meta는 mihomo의 이전 이름입니다. 코어 버전에 따라 지원하는 프로토콜, DNS 필드, TUN 옵션이 다를 수 있으므로 시작 전에 클라이언트와 코어 버전을 기록하고 현재 설정을 백업하세요. 점검 중에는 구독, 테스트 주소, 클라이언트 버전을 그대로 유지하고 코어 업데이트, DNS 변경, 노드 교체를 한꺼번에 하지 마세요.

재현 가능한 테스트 기록 만들기

• 환경 고정: 같은 기기, 같은 네트워크, 같은 다운로드 주소를 사용하세요. 클라우드 동기화, 시스템 업데이트, 기타 대용량 작업은 일시 중지합니다.
• 정책 고정: 실제로 연결되는 프록시 그룹에서 노드 하나를 선택하세요. 테스트 중 자동 속도 측정 그룹이나 부하 분산 그룹이 노드를 바꾸지 않도록 합니다.
• 횟수 고정: 조건별로 연속 3회 테스트한 뒤 중앙값을 기록하고, 지속 다운로드는 최소 30초 동안 확인하세요. 테스트 과정에서 데이터 사용량이 커질 수 있습니다.
• 항목 고정: 테스트 시간, 대상 도메인, 규칙, 프록시 경로, 지연 시간, 다운로드 속도, 도중에 멈췄는지 기록하세요.

표의 수치는 기록 및 결과 해석 방법을 보여 주기 위한 예시이며, 이 사이트에서 직접 측정한 결과가 아닙니다. 단위에 유의하세요. 8MB/s는 약 64Mbps이며, 실제 전송에는 프로토콜 오버헤드도 발생합니다. 인터넷 속도가 100Mbps라고 해서 다운로드 프로그램에 100MB/s로 표시되는 것은 아닙니다.

1단계: 노드 품질 확인 — 특정 노드 문제와 대상 사이트의 속도 제한 구분

같은 구독에서 노드 2~3개를 골라 동일한 대상을 테스트하세요. 노드 이름에 표시된 지역이 실제 진입 위치와 일치한다고 볼 수 없으며, 이름과 출구 경로가 반드시 같은 것도 아닙니다. 대체 노드를 고를 때는 이름만 다른 노드보다 진입 지점이나 회선이 다른 노드를 우선 비교하세요.

지연 시간 테스트가 시간 초과되어도 노드를 전혀 사용할 수 없다는 뜻은 아닙니다

테스트 주소에 연결할 수 없거나 대상 서버가 요청을 거부하거나 TLS 핸드셰이크에 실패하면 시간 초과가 발생할 수 있습니다. 먼저 테스트 URL을 확인한 다음 브라우저에서 실제로 이용하려는 사이트에 접속해 보세요. 반대로 속도 측정 주소에 빠르게 응답해도 해당 요청이 성공했다는 뜻일 뿐, 동영상 조각 파일, 다운로드 도메인, 로그인 API까지 정상이라는 보장은 없습니다.

1. 클라이언트의 ‘프록시’ 페이지에서 노드를 직접 선택한 뒤 ‘연결’ 페이지에서 새 요청이 실제로 해당 노드를 통과하는지 확인하세요. 페이지 이름은 클라이언트 버전에 따라 다를 수 있습니다.
2. 같은 HTTPS 파일 주소로 3회 테스트한 다음, 별도의 두 번째 사이트에서도 확인하세요. 특정 사이트만 느리고 다른 사이트는 정상이라면 사이트 속도 제한, CDN, 출구 회선의 상호 연결을 먼저 살펴보세요.
3. 저녁 혼잡 시간대와 그 외 시간대의 결과를 각각 기록하세요. 같은 노드가 저녁에만 지속적으로 느려진다면 로컬 설정보다 노드 처리 용량이나 공유 회선 혼잡을 먼저 확인할 필요가 있습니다.
4. 노드를 바꾼 뒤 테스트 연결을 새로 만드세요. 기존 HTTP/2, HTTP/3 또는 다운로드 연결은 이전 경로를 계속 사용할 수 있습니다. 필요한 경우 해당 테스트 연결만 종료하세요.

명시적 프록시 요청으로 브라우저 변수 분리하기

아래 Windows PowerShell 명령은 로컬 HTTP 프록시를 통해 예시 사이트에 접속해 첫 바이트 도착 시간과 전체 소요 시간을 확인합니다. 7890은 예시 포트입니다. 실행 전에 클라이언트에 표시된 실제 HTTP 또는 mixed 수신 포트로 바꿔야 하며, 모든 클라이언트의 기본 포트가 아닙니다. 이처럼 작은 페이지를 요청하는 테스트는 연결 과정을 확인하기 위한 것이며 최대 대역폭을 측정할 수는 없습니다.

curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --connect-timeout 10 --max-time 30 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s bytes_per_second=%{speed_download}\n" https://example.com/

여기서 time_connect는 주로 로컬 프록시까지의 연결 시간을 나타내며, 원격 노드까지의 지연 시간으로 볼 수 없습니다. HTTP 프록시를 통해 HTTPS에 접속하면 이후 측정 시간에는 프록시 터널 연결과 대상 서버의 TLS 핸드셰이크 단계 등이 포함됩니다. macOS와 Linux에서는 curl을 사용하고 NUL을 /dev/null로 바꾸세요. 명령은 정상인데 브라우저가 느리다면 구독을 바로 바꾸기보다 브라우저 확장 프로그램, 캐시, 보안 DNS를 확인하세요.

2단계: 회선 경로 확인 — 규칙을 확인한 뒤 네트워크 진입점 비교

노드를 선택했다고 해서 모든 앱의 트래픽이 해당 노드를 통과하는 것은 아닙니다. 규칙 모드에서는 연결이 먼저 규칙과 일치하는지 확인한 뒤 해당 정책이나 프록시 그룹으로 전달됩니다. 전체 전환 메뉴에서 노드를 선택해도 대상 요청이 실제로 다른 그룹에 연결된다면 속도 측정 결과를 비교할 수 없습니다. 다운로드 도메인, 동영상 조각 파일 도메인, 페이지의 기본 도메인에 각각 다른 규칙이 적용될 수 있으니 특히 주의하세요.

연결 기록에서 다음 세 가지 항목 확인

• 대상: 도메인, 대상 IP, 앱 프로세스가 현재 테스트와 일치하는지 확인하세요. 백그라운드 업데이트 요청을 잘못 확인하지 않도록 합니다.
• 규칙: DOMAIN-SUFFIX, GEOIP 또는 최종 규칙인 MATCH 등 적용된 규칙의 종류와 내용을 확인하세요.
• 프록시 경로: 최종 연결이 예상한 노드로 이어지는지 확인하세요. DIRECT, 다른 정책 그룹, 자동 그룹이 방금 선택한 다른 노드로 연결된 경우는 아닌지 살펴보세요.

잠시 전역 모드로 바꾸고 전역 그룹에서 동일한 노드를 직접 선택해 비교할 수 있습니다. 전역 모드에서는 속도가 눈에 띄게 회복되지만 규칙 모드에서 계속 느리다면 그룹 선택과 규칙 순서를 먼저 확인하세요. 전역 모드는 코어에 들어온 트래픽의 처리 방식만 바꿀 뿐, 시스템 프록시를 사용하지 않는 프로그램의 트래픽까지 자동으로 가져오지는 않습니다. TUN을 대신할 수도 없습니다. 테스트 후에는 전역 모드를 해제해 일상적인 접속 경로로 되돌리세요.

가정용 인터넷과 휴대폰 핫스팟 교차 테스트

노드와 테스트 대상을 그대로 둔 채 컴퓨터를 가정용 인터넷에서 휴대폰 핫스팟으로 전환하세요. 핫스팟에서는 안정적이고 가정용 인터넷에서만 느리다면 로컬 무선 연결, 라우터, 인터넷 접속망 또는 통신사에서 노드 진입점까지의 경로에 문제가 있을 가능성이 큽니다. Wi-Fi 대신 유선 연결도 테스트하세요. 유선 연결에서는 회복되지만 무선 연결에서 여전히 느리다면 프록시 규칙을 계속 바꾸기보다 무선 간섭과 신호 상태를 먼저 살펴보세요.

Windows에서는 먼저 ipconfig를 실행해 현재 기본 게이트웨이를 확인한 다음 ping -n 30 192.168.1.1을 실행할 수 있습니다. 이 주소는 예시일 뿐이므로 실제 게이트웨이 주소로 바꿔야 합니다. 로컬 게이트웨이에서 이미 눈에 띄는 패킷 손실이나 수십 밀리초 단위의 반복적인 지연 변동이 발생한다면 프록시 설정 변경을 먼저 중단하세요. 다만 일부 라우터는 ICMP 응답 우선순위를 낮추므로 ping 한 번의 결과만으로 네트워크 장애라고 단정해서는 안 됩니다.

3단계: 기기 설정 확인 — 시스템 프록시, TUN, 포트 점검

시스템 프록시는 앱이 운영체제의 프록시 설정을 사용해야 동작합니다. 일부 명령줄 도구, 게임, 자체 네트워크 스택을 사용하는 프로그램은 이 설정을 따르지 않습니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 일치하는 IP 트래픽을 가져오지만, 라우팅 제외 항목, 권한, 다른 VPN의 영향을 받습니다. 지원되는 클라이언트에서는 두 기능을 함께 사용할 수 있습니다. 문제가 생기면 반드시 충돌한다고 단정하지 말고 하나씩 꺼서 원인을 분리하세요.

한 번에 한 가지 방식만 바꿔 테스트

1. 먼저 명시적 프록시 테스트: 앞에서 안내한 curl 명령으로 로컬 프록시 포트에 직접 연결해 시스템 프록시 설정의 영향을 배제하세요.
2. 다음은 시스템 프록시 테스트: TUN을 잠시 끄고 시스템 프록시를 켠 다음, 시스템 프록시를 따르는 브라우저로 같은 대상에 접속하세요. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 주소와 포트를 확인할 수 있습니다.
3. 마지막으로 TUN 테스트: 시스템 프록시를 잠시 끄고 클라이언트 안내에 따라 서비스를 설치하거나 권한을 허용한 뒤 TUN을 켜세요. 테스트 연결이 코어의 연결 목록에 나타나는지 확인한 다음 속도를 비교합니다.
4. 다른 트래픽 가로채기 프로그램 분리: 다른 VPN, 프록시 클라이언트, 네트워크 가속 프로그램을 하나씩 종료하세요. 회사 기기에 보안 정책이 적용되어 있다면 관리자에게 먼저 문의하고 드라이버를 바로 제거하거나 보안 기능을 끄지 마세요.

포트 충돌과 리소스 사용량 확인

클라이언트 로그에 수신 대기 실패가 표시되면 먼저 해당 포트가 사용 중인지 확인하세요. Windows에서 netstat -ano | findstr :7890을 실행한 다음, 로컬 주소의 포트가 정확히 7890인 LISTENING 항목이 있는지 확인하고 PID를 작업 관리자에서 찾아 어떤 프로세스인지 확인합니다. 일치하는 줄이 보인다는 이유만으로 프로세스를 종료하지 마세요. 다른 연결이거나 비슷한 번호의 포트일 수도 있습니다. 클라이언트 수신 포트를 바꾸면 시스템 프록시 설정과 명시적 프록시 명령의 포트도 함께 변경해야 합니다.

다운로드 중 작업 관리자의 CPU, 메모리, 네트워크 사용량도 확인하세요. 논리 프로세서 하나가 계속 100%에 가까우면 기기의 처리 성능이 전송 속도를 제한할 수 있습니다. 전체 CPU 평균 사용률이 낮아도 단일 스레드 병목이 없다고 단정할 수는 없습니다. 로그 수준을 debug로 계속 설정해 두면 기록량이 늘어나므로 점검이 끝나면 평소 수준으로 되돌리세요. 코어 버전이나 TUN 네트워크 스택을 비교하기 전에 기존 설정과 원상 복구 방법을 보관하세요.

DNS 및 프로토콜 점검: 첫 접속 지연, 동영상 느림, 간헐적 멈춤을 구분

DNS 문제는 처음 접속할 때 오래 기다리지만 연결이 수립된 뒤 다운로드는 정상인 형태로 나타나는 경우가 많습니다. 지속적인 저속 전송이 반드시 DNS와 관련된 것은 아닙니다. 먼저 연결 로그에서 이름 해석 시간 초과가 반복되는지 확인하고 도메인 해석, 원격 연결, TLS 핸드셰이크 단계를 구분하세요. DNS 주소를 다른 공개 DNS 서버로 바꾼다고 요청이 프록시를 통과하거나 회선이 빨라지는 것은 아닙니다.

Fake-IP와 nameserver-policy 점검 범위

mihomo에서 dns.enhanced-mode: fake-ip는 가상 주소를 매핑해 코어가 도메인을 확인할 수 있도록 돕는 기능이며, 대역폭을 높이는 옵션이 아닙니다. nameserver-policy는 지정한 도메인에 사용할 DNS 서버를 설정합니다. 이는 DNS 조회 정책을 정하는 기능이지 실제 서비스 트래픽의 프록시 규칙과 같지 않습니다. DNS 상위 서버 주소를 도메인으로 지정했다면 해당 서버의 주소를 조회하고 연결하는 과정도 고려해 의존성 순환이 생기지 않도록 하세요.

• 브라우저에서 보안 DNS를 사용하면 요청 경로가 시스템 DNS와 달라질 수 있습니다. 브라우저의 보안 DNS를 잠시 끄고 비교 테스트를 한 뒤 결과를 기록하고 원래 설정으로 되돌리세요.
• TUN의 DNS 가로채기 설정은 규칙이 적용되는 DNS 트래픽만 가져옵니다. 일반적인 53번 포트 가로채기만으로 모든 앱 내부의 DoH 요청까지 직접 바꿀 수 있는 것은 아닙니다.
• DNS 설정을 바꾼 뒤에는 테스트 연결을 새로 만드세요. Windows의 ipconfig /flushdns는 시스템의 DNS 캐시만 지우며 브라우저, 앱, 코어의 모든 캐시를 비우는 명령은 아닙니다.
• IPv6 DNS 레코드, 시스템 라우팅, 프록시 지원을 함께 확인하세요. 설정에서 옵션 하나만 바꿨다고 앱의 IPv6 트래픽이 가로채졌다고 볼 수는 없습니다.

UDP, QUIC, MTU는 마지막에 점검

브라우저는 UDP 기반 HTTP/3를 사용할 수 있습니다. 현재 노드, 프로토콜 또는 트래픽 처리 경로에서 UDP 지원이 완전하지 않으면 일부 사이트가 반복적으로 다른 프로토콜로 전환되거나 로딩에 실패할 수 있습니다. 먼저 클라이언트 로그와 브라우저 네트워크 정보를 확인한 다음, 해당 브라우저나 대상에서만 일시적으로 TCP 연결과 비교하세요. 사이트 하나 때문에 UDP를 전체 차단하지 마세요.

작은 페이지는 정상인데 대용량 파일, 특정 HTTPS 요청 또는 TUN 모드에서 자주 멈추고 노드와 규칙 문제를 제외했다면 경로 MTU나 터널 캡슐화 문제를 의심해 볼 수 있습니다. 이 경우에만 기존 값을 기준으로 TUN MTU를 1400으로 임시 변경해 비교하세요. 이 값은 진단을 위한 후보일 뿐 모든 환경에 적합한 설정은 아닙니다. 개선되지 않으면 원래 값으로 되돌리고, MTU를 임의로 낮추는 일을 일반적인 속도 개선 방법으로 사용하지 마세요. 지원 필드와 적용 방식은 현재 코어 문서를 확인하고 프로토콜 안내서도 참고하세요.

결과 정리: 설정을 계속 추가하지 말고 증상에 따라 다음 단계 선택

한 번에 조건 하나만 바꾸고 테스트 후 ‘무엇을 바꿨는지, 결과가 어땠는지, 원래대로 되돌렸는지’를 기록하세요. 원인을 찾은 뒤에는 임시 전역 모드, 테스트용 DNS, 실험적인 MTU 설정을 취소하고 문제를 설명할 수 있는 최소한의 변경만 남기세요. 문의할 때는 클라이언트 및 코어 버전, 운영체제 버전, 트래픽 처리 모드, 테스트 시간대, 민감 정보를 가린 오류 로그를 제공하세요. 구독 주소, 노드 비밀번호, 컨트롤 인터페이스 키는 공개하지 마세요.

기존 클라이언트가 현재 시스템과 맞지 않는다면 먼저 클라이언트 비교에서 플랫폼과 코어 호환성을 확인한 뒤 사용 안내에 따라 최소한의 설정부터 다시 구성하세요. 클라이언트를 바꾸면 일부 호환성 문제는 해결될 수 있지만 노드, 회선, 기기 환경을 교차 검증하는 과정까지 대신할 수는 없습니다.