Clash 속도 느릴 때 해결 방법: 노드·회선·로컬 설정 점검

테스트 조건을 통일하고 지연 시간과 처리량을 구분하세요

Clash 노드 옆에 표시되는 지연 시간은 한 번의 탐색 요청에 걸린 시간일 뿐입니다. 지속적인 다운로드 속도를 나타내거나 동영상 플랫폼, 코드 저장소, 웹사이트가 모두 같은 경로를 이용한다는 뜻은 아닙니다. 지연 시간은 80ms인데 다운로드 속도가 200KB/s라면, 먼저 실제 연결 상태를 기록한 뒤 어느 부분을 바꿀지 판단하세요.

이 글의 TUN 설정은 mihomo 커널을 사용하는 클라이언트를 기준으로 설명합니다. 기존 Clash 커널과 클라이언트마다 제공하는 옵션은 서로 다를 수 있습니다. 시작하기 전에 클라이언트의 ‘정보’ 또는 ‘커널’ 화면에서 클라이언트명, 버전, 커널 버전, 현재 설정 이름을 확인하세요. 다른 커널의 설정 항목을 그대로 복사하는 일을 방지할 수 있습니다.

재현 가능한 기준값 만들기

클라우드 동기화, 시스템 업데이트, 다른 대용량 다운로드를 일시 중지하세요. 컴퓨터는 가능하면 유선으로 연결하고, Wi-Fi를 쓴다면 위치와 주파수 대역을 고정하세요.
안정적인 직접 연결 사이트 하나와 프록시가 필요한 대상 하나를 정하세요. 매번 같은 파일과 같은 테스트 시간을 사용하고, 측정할 때마다 서버를 바꾸지 마세요.
규칙 모드와 정책 그룹은 그대로 두고 노드를 직접 선택하세요. 조건별로 3회씩, 매회 30초 동안 측정한 뒤 중앙값을 기록하세요.
로딩 시작까지 걸린 시간, 안정적인 다운로드 속도, 연결 끊김 여부와 연결 패널에 표시된 규칙·정책 그룹·최종 노드를 기록하세요.

아래 표는 기록 방법의 예시이며 특정 서비스의 실측 결과가 아닙니다. 실제 문제를 점검할 때는 같은 기기에서 같은 테스트 리소스를 사용해 얻은 결과를 기록하세요.

테스트 조건	최초 응답 시간	안정적인 속도	관찰 결과
가정용 네트워크, 노드 A	0.9초	1.2 MB/s	계속 느림
가정용 네트워크, 노드 B	0.8초	8.5 MB/s	속도 안정적
모바일 핫스팟, 노드 A	0.7초	7.8 MB/s	접속 네트워크 변경 후 개선

1단계: 노드와 실제 출구 확인

연결 패널을 먼저 확인한 뒤 노드를 바꾸세요

클라이언트의 ‘연결’ 패널에서 다운로드 중인 요청을 찾으세요. 대상 도메인, 일치한 규칙, 정책 경로, 출구 노드를 확인합니다. 정책 그룹에서 노드만 바꿔도 이미 연결된 세션의 출구가 바뀌지 않을 수 있습니다. 브라우저의 장기 연결, 동영상 연결, 다운로드 작업이 기존 연결을 계속 사용할 수 있습니다.

노드를 바꿀 때마다 테스트 작업을 중지하고 새로 시작하세요. 필요하면 해당 테스트 연결만 종료하고, 원격 데스크톱이나 회의 중에는 모든 연결을 끊지 마세요. 패널에 DIRECT가 표시된다면 현재 문제는 선택한 프록시 노드의 처리량이 아닙니다. 먼저 규칙이 제대로 적용됐는지 확인하세요.

특정 노드만 느림: 같은 정책 그룹에서 노드 2~3개를 비교하세요. 한 노드만 계속 느리다면 해당 노드의 부하, 속도 제한 또는 출구 품질을 먼저 의심할 수 있습니다.
자동 그룹에서 노드가 계속 바뀜: 테스트하는 동안 수동 선택 그룹을 사용하세요. url-test는 주로 탐색 지연 시간을 기준으로 노드를 선택하며, 대역폭을 측정하는 기능은 아닙니다.
특정 사이트만 느림: 다른 대상 리소스로 다시 테스트하세요. 사이트 자체의 속도 제한, CDN 라우팅, 노드 출구와 대상 사이트 간의 연결 상태도 속도에 영향을 줄 수 있습니다.

규칙 모드와 전역 모드는 짧게 비교하세요

대상이 잘못 직접 연결되고 있다고 의심되면 잠시 전역 모드로 전환하고 GLOBAL 출구를 직접 선택한 뒤 테스트 연결을 새로 만드세요. 전역 모드에서는 정상인데 규칙 모드에서만 느리다면 규칙 모드로 돌아가 도메인 규칙, 규칙 세트 업데이트, 정책 그룹의 연결 대상을 확인하세요. 전역 모드로 바꿔도 노드 대역폭이 늘어나지는 않으며, 클라이언트로 전달되지 않은 트래픽까지 모두 처리되는 것도 아닙니다.

속도 측정을 위해 구독의 모든 규칙을 바로 수정하지 마세요. 먼저 적용된 규칙을 기록한 다음 클라이언트에서 지원하는 로컬 재정의 기능으로 대상 도메인을 수정하세요. 구독으로 생성된 파일을 직접 편집하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다.

2단계: 접속 네트워크와 원격 경로 비교

노드 이름에 표시된 지역만으로는 전체 전송 경로를 알 수 없습니다. 연결이 먼저 입구 서버나 중계 서버를 거친 뒤, 다른 출구를 통해 대상에 접속할 수 있습니다. 클라이언트 연결 패널에서는 어떤 출구를 선택했는지 확인할 수 있지만 서버 측의 모든 중계 경로까지 표시되지는 않을 수 있습니다.

교차 테스트로 문제 범위 좁히기

같은 네트워크에서 노드 변경: 가정용 네트워크는 그대로 두고 노드만 바꾸세요. 특정 입구를 사용하는 노드만 느리고 다른 입구는 정상이라면 해당 노드들의 공통점을 기록하세요.
같은 노드에서 네트워크 변경: 노드와 대상은 그대로 두고 가정용 인터넷을 모바일 핫스팟으로 바꿔 보세요. 먼저 대용량 작업을 중지해 모바일 데이터 사용량을 관리하세요.
같은 조합으로 시간대 변경: 혼잡하지 않은 시간대와 저녁 시간대에 각각 다시 측정하세요. 저녁에만 속도가 떨어진다면 접속 네트워크, 입구 또는 중계 구간의 혼잡을 살펴볼 필요가 있습니다.

노드 A가 가정용 네트워크에서는 느리고 핫스팟에서는 빠른 반면, 노드 B는 두 네트워크 모두 정상이라면 ‘가정용 네트워크에서 노드 A까지의 경로’ 문제일 가능성이 큽니다. 그렇다고 노드 A 서버의 대역폭이 부족하다고 단정할 수는 없습니다. 두 네트워크에서 모든 노드가 느리지만 직접 다운로드는 정상이라면 클라이언트, 로컬 프록시 경로 또는 테스트 대상의 제한을 확인하세요.

Ping, 경로 추적, 다운로드 속도는 각각 따로 확인하세요

프록시 입구에 Ping이나 경로 추적을 실행해도 확인할 수 있는 것은 네트워크 단서 일부뿐입니다. 중간 라우터가 ICMP 응답을 제한할 수 있습니다. 특정 홉에서 패킷 손실이 표시돼도 이후 목적지에서 같은 손실이 나타나지 않는다면 해당 홉이 실제 전달 트래픽을 버린다고 단정하기 어렵습니다. 일반적인 경로 추적으로는 암호화된 프록시 연결 안쪽의 서버 중계 경로도 확인할 수 없습니다.

회선 문제를 문의할 때는 발생 시간과 시간대, 인터넷 서비스 제공업체, 노드 이름, 대상 도메인, 3회 측정 결과, 네트워크 변경 결과를 함께 제출하세요. 지연 시간 목록만 보내지 마세요. 로그를 공유하기 전에 구독 주소, 토큰, 노드 비밀번호, 개인 접속 기록을 삭제하세요.

3단계: 시스템 프록시·TUN·로컬 충돌 분리

먼저 로컬 수신 포트 확인

시스템 프록시는 일반적으로 시스템 프록시 설정을 따르는 앱의 트래픽을 로컬 HTTP 프록시로 전달합니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 트래픽을 처리합니다. 특정 설정에서는 두 기능을 함께 사용할 수 있지만, 문제를 점검할 때는 진입 경로와 라우팅을 동시에 바꾸지 않도록 따로 테스트하세요. 아래 예시는 실제 설정에 mixed-port: 7890가 있는 경우를 기준으로 합니다. 7890이 모든 클라이언트의 기본 포트는 아닙니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

Windows PowerShell에서 아래 명령을 실행해 포트가 수신 대기 중인지 확인한 뒤 프록시를 명시해 요청을 보내세요. 이 요청은 경로와 응답 시간을 확인하기 위한 것으로 대용량 파일의 대역폭 측정에는 적합하지 않습니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen

curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://example.com/

명령에 지정한 포트를 클라이언트의 실제 포트와 일치시키세요. 여기서 time_connect는 주로 로컬 프록시에 연결하는 데 걸린 시간을 나타내며 노드까지의 왕복 지연 시간이 아닙니다. time_starttransfer에는 이후 프록시 협상, TLS, 서버 응답 등의 단계가 포함됩니다. 특정 필드를 DNS 문제로 단정하지 말고 같은 요청에서 나타나는 변화를 비교하세요.

시스템 프록시와 TUN을 차례로 A/B 테스트하세요

TUN을 끄고 시스템 프록시만 켠 다음, HTTP 프록시를 지원하는 브라우저나 위의 명령으로 테스트하세요.
결과를 기록한 뒤 시스템 프록시를 끄고 TUN을 켜세요. 같은 대상에 새로 연결하고 연결 패널에 해당 요청이 실제로 표시되는지 확인하세요.
TUN에서만 느리다면 다른 VPN, 가속 프로그램 또는 가상 네트워크 어댑터 도구를 함께 사용하고 있는지 확인하세요. 한 번에 하나씩 일시 중지하고 다시 테스트하되, 여러 보안 기능을 동시에 끄지 마세요.
TUN이 시작되지 않는다면 먼저 서비스 권한, 가상 네트워크 어댑터 또는 경로 생성 오류를 해결하세요. 시작 실패와 처리량 저하는 서로 다른 문제입니다.

mihomo의 TUN 스택 옵션에는 system, gvisor, mixed가 있으며, 사용 가능 여부와 동작 방식은 플랫폼 및 커널 버전에 따라 달라집니다. mixed는 일반적으로 system TCP와 gVisor UDP를 조합합니다. 모든 기기에 가장 빠른 스택은 없습니다. 옵션은 한 번에 하나만 바꾸고 관련 커널을 다시 시작한 뒤 같은 작업으로 재측정하세요.

DNS와 UDP: 페이지 로딩 지연, 다운로드 속도 저하, 동영상 끊김 구분

처음 접속할 때만 느리다면 먼저 DNS 조회를 확인하세요

처음 접속할 때 몇 초간 멈췄다가 새로고침하면 바로 정상화되지만 파일 다운로드 속도는 정상이라면 DNS 조회 시간 초과와 연결 수립 과정을 먼저 확인하세요. 로그에 DNS 시간 초과가 반복되는지, 대상 도메인이 DNS 서버마다 크게 다른 CDN 주소로 응답되는지 살펴보세요. 브라우저 캐시나 연결 재사용으로 두 번째 접속이 빨라질 수도 있으므로 이 현상만으로 DNS 장애라고 단정하면 안 됩니다.

enhanced-mode: fake-ip는 가상 주소 매핑으로 도메인 식별을 돕는 기능이며 노드 대역폭을 직접 늘려 주지는 않습니다. nameserver-policy는 지정한 도메인에 사용할 DNS 서버를 선택하는 설정이지 출구 정책 그룹이 아닙니다. 설정을 바꿀 때는 DNS 서버에 접속할 수 있는지, 반환된 주소가 현재 출구에 적합한지, DNS 요청이 실제로 어떤 경로를 이용하는지 함께 확인하세요.

브라우저의 보안 DNS는 자체 DoH 경로를 사용해 시스템 DNS를 우회할 수 있습니다. 진단할 때 보안 DNS 상태를 기록하고, 필요하다면 잠시 꺼서 비교한 뒤 테스트가 끝나면 다시 켜세요.
TUN의 dns-hijack는 주로 기존 53번 포트 요청을 가로채는 데 쓰입니다. 이것만으로 모든 DoH·DoT 트래픽까지 가로챈다고 볼 수는 없습니다.
fake-ip와 실제 주소 DNS 모드를 전환한 뒤에는 클라이언트에서 지원하는 방법으로 관련 DNS 캐시를 지우고 테스트 연결을 새로 만드세요. 이전 주소가 결과에 영향을 주지 않도록 해야 합니다.

동영상이 끊긴다면 UDP와 QUIC 확인

웹 페이지 다운로드는 정상인데 동영상, 음성 통화 또는 게임에 문제가 있다면 UDP를 따로 확인하세요. 브라우저는 UDP 기반 QUIC을 사용할 수 있으며 노드와 서버 측에서도 해당 전달 경로를 지원해야 합니다. 클라이언트 연결 패널에서 UDP 요청이 표시되는지 확인한 뒤, 클라이언트나 브라우저에서 지원하는 방법으로 QUIC을 잠시 꺼서 비교하세요. TCP로 전환한 뒤 달라지는 점을 살펴보세요.

전환 후 문제가 해결돼도 UDP 경로를 추가로 점검할 필요가 있다는 뜻일 뿐, 모든 UDP를 계속 차단해야 한다는 의미는 아닙니다. IPv6를 끄는 것도 일반적인 속도 개선 방법으로 간주하지 마세요. 먼저 AAAA 조회 결과, IPv6 기본 경로, 프록시 트래픽 처리 방식이 일치하는지 확인한 뒤 필요할 때만 주소 계열을 제한해 테스트하세요.

확인된 근거에 따라 원인을 좁히고 되돌릴 수 있는 설정을 유지하세요

세 단계의 비교를 마친 뒤 문제 범위를 최소한으로 좁히세요. 아래 대응 관계는 다음 점검 방향을 정하는 데 참고할 수 있으며, 서버나 네트워크 측의 추가 진단을 대신하지 않습니다.

반복해서 나타나는 현상	먼저 확인할 항목	다음 단계
특정 노드만 느리고 다른 노드는 정상	노드 부하 및 출구 경로	같은 대상으로 다시 측정하고 시간과 노드 정보를 제출
핫스팟으로 바꾸면 정상화	접속 네트워크에서 입구까지의 경로	시간대와 다른 입구를 비교
시스템 프록시는 빠르고 TUN은 느림	TUN 스택, 라우팅, 프로그램 간 충돌	한 번에 하나씩 바꾸며 항목별로 비교
처음 접속은 느리지만 다운로드는 정상	DNS와 연결 수립	DNS 시간 초과와 브라우저 보안 DNS 확인
전역 모드는 정상이고 규칙 모드는 느림	규칙 적용 결과와 정책 경로	대상 연결의 최종 출구 확인

기존 설정을 보관하거나 백업을 내보내고, 변경한 항목과 시간, 결과를 기록하세요. 업데이트 이후 문제가 시작됐다면 해당 항목을 먼저 이전 설정으로 되돌려 확인한 뒤 클라이언트나 커널 업데이트를 검토하세요. 문제가 해결되면 평소 사용하는 규칙 모드와 필요한 보안 설정, 로그 수준을 복원해 임시 테스트 설정이 계속 적용되지 않도록 하세요.