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

Clash 속도가 느리다고 해서 반드시 노드 대역폭이 부족한 것은 아닙니다. 웹페이지가 처음 열릴 때 오래 기다려야 하거나, 동영상 재생 중 버퍼링이 반복되거나, 다운로드 속도가 계속 낮다면 각각 DNS 조회, 회선 혼잡, 로컬 트래픽 처리 문제일 수 있습니다. 먼저 증상을 구분한 뒤 단계별로 확인하세요. DNS, 노드, TUN 설정을 한꺼번에 바꾸는 것보다 원인을 찾기 쉽습니다.

시작 전: 반복 가능한 속도 측정 기준 만들기

클라우드 드라이브 동기화, 시스템 업데이트, 대용량 다운로드를 먼저 일시 중지하세요. 한 대의 기기, 하나의 네트워크, 하나의 대상 주소를 정해 측정합니다. 규칙 모드를 사용한다면 연결 세부 정보에서 실제로 어떤 규칙, 정책 그룹, 노드가 선택됐는지도 확인하세요. 의도한 노드를 거치지 않은 테스트로는 해당 노드의 성능을 판단할 수 없습니다.

환경 기록: 클라이언트 버전, 커널 버전, 운영체제 버전, 현재 네트워크 유형, 노드 이름, 시스템 프록시와 TUN의 활성화 여부를 기록하세요. 커널 버전은 클라이언트의 정보 화면이나 시작 로그에서 확인할 수 있습니다.
정책 고정: 클라이언트의 프록시 또는 정책 그룹 화면에서 노드를 직접 선택해 테스트 중 자동 정책 그룹이 회선을 바꾸지 않도록 하세요. 설정상 수동 고정이 불가능하다면 연결할 때마다 실제 선택된 노드를 기록하세요.
항목별 측정: 웹페이지 첫 응답 시간, 지속 다운로드 속도, 실패 횟수를 기록하세요. 각 항목을 3회씩 측정하고 측정 사이에는 약 30초 간격을 두세요. 한 번 나온 최고 속도를 안정적인 속도로 간주하지 마세요.
단위 통일: 이론상 100 Mbps는 약 12.5 MB/s입니다. 실제 속도는 프로토콜 오버헤드의 영향도 받습니다. 클라이언트에 표시되는 MB/s와 인터넷 요금제의 Mbps는 그대로 비교할 수 없습니다.

관찰된 증상	우선 점검 항목	비교 방법
처음 열 때만 느리고 이후에는 정상	DNS, 연결 설정, 대상 사이트 응답	첫 요청과 재요청을 비교하고 DNS 시간 초과 로그 확인
지연 시간은 낮지만 다운로드는 느림	노드 처리량, 회선 용량, 대상 사이트의 속도 제한	같은 파일을 다른 노드에서 받고, 다운로드 대상도 바꿔 보기
저녁 시간에만 눈에 띄게 느려짐	중계 회선 또는 출구 회선의 피크 시간대 혼잡	노드를 고정하고 시간대를 바꿔 반복 측정
TUN을 켰을 때만 느림	라우팅, DNS 가로채기, 다른 VPN과의 충돌	시스템 프록시를 지원한다고 확인된 앱으로 한 가지 변수만 바꿔 비교
직접 연결도 느림	Wi-Fi, 인터넷 회선, 기기 부하	프록시를 종료하고 원래 직접 연결할 수 있는 서비스를 테스트

1단계: 노드 품질과 실제 처리량

노드 지연 시간만으로 다운로드 속도를 알 수 없습니다

클라이언트의 지연 시간 테스트는 보통 지정된 URL에 요청을 보내 해당 탐색 경로의 응답을 측정합니다. 지속적인 데이터 전송 능력을 나타내는 것은 아닙니다. 지연 시간이 60 ms로 표시되는 노드도 출구 대역폭을 공유해 다운로드가 느릴 수 있고, 160 ms인 노드가 더 안정적인 처리량을 제공할 수도 있습니다. url-test 정책 그룹도 자동 대역폭 측정기는 아닙니다.

같은 지역의 노드 2~3개를 골라 동일한 자료를 다운로드하고, 노드별로 3회씩 측정하세요. 측정 주소, 동시 연결 수, 측정 시간은 동일하게 유지합니다. 특정 노드만 유난히 느리다면 노드 문제를 먼저 확인하세요. 모든 노드가 느리다면 공통 진입점이나 중계 회선을 사용하는지 살펴보세요.

프록시 포트를 지정해 다시 측정하기

데스크톱에서는 curl에 HTTP 프록시를 직접 지정해 명령줄 프로그램이 시스템 프록시 설정을 읽지 않는 문제를 배제할 수 있습니다. 아래 예시는수신 대기 중임을 확인한 로컬 HTTP 또는 mixed 포트 7890을 사용합니다. 7890이 모든 클라이언트의 기본 포트는 아니므로 현재 포트를 먼저 확인하세요. 이 명령은 공개 테스트 엔드포인트에서 약 10 MB의 데이터를 다운로드하므로 해당 데이터가 소모됩니다.

# macOS / Linux; 로컬에 curl이 설치되어 있어야 합니다
curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --max-time 60 --write-out 'connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n' 'https://speed.cloudflare.com/__down?bytes=10000000'

# Windows PowerShell; curl.exe를 명시적으로 호출합니다
curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --max-time 60 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n" "https://speed.cloudflare.com/__down?bytes=10000000"

speed_download의 단위는 초당 바이트입니다. 예를 들어 2500000 B/s는 약 2.5 MB/s입니다. 이는 수치 예시일 뿐, 이 사이트에서 측정한 결과가 아닙니다. 용량이 작은 파일은 연결 설정의 영향을 받기 쉬우므로 결과는 우선 비교용으로만 사용하세요. 실제 문제가 발생하는 웹사이트에서도 확인해야 하며, 하나의 속도 측정 서비스만으로 모든 서비스의 성능을 판단할 수 없습니다.

2단계: 진입점·중계·출구 회선

노드 이름이 다르다고 네트워크 경로까지 완전히 분리되는 것은 아닙니다. 서로 다른 지역으로 표시된 노드도 같은 접속 진입점이나 중계 자원을 공유할 수 있습니다. 여러 노드가 같은 시간대에 함께 느려진다면 지역만 바꾸는 것으로는 해결되지 않을 수 있습니다.

시간대와 네트워크를 교차 비교하기

시간대 비교: 예를 들어 오전 10시와 오후 9시에 같은 노드로 동일한 자료를 테스트하세요. 저녁 시간에만 속도가 지속적으로 떨어진다면 로컬 DNS를 바로 바꾸기보다 피크 시간대의 혼잡을 먼저 의심하세요.
접속 네트워크 비교: 같은 기기를 가정용 인터넷과 휴대폰 핫스팟에 각각 연결해 보세요. 핫스팟을 테스트하기 전에 데이터 사용량을 확인하고 백그라운드 다운로드를 중지하세요. 가정용 네트워크에서만 문제가 생긴다면 라우터, 통신사 경로, Wi-Fi를 점검하세요.
진입점 비교: 서비스 제공자가 서로 다른 진입점이나 회선 유형을 명확히 안내한다면 같은 대상 지역에서 비교해 보세요. 이름에 '전용 회선' 같은 문구가 있다고 해서 실제 성능이 보장되는 것은 아닙니다.
대상 비교: 같은 노드로 서로 다른 웹사이트 두 곳에 접속해 보세요. 한 곳에서만 느리다면 대상 CDN, 계정별 속도 제한, 출구 지역 또는 사이트 자체 부하가 원인일 수 있습니다.

로컬 기기에서 노드 서버로 ping을 실행해도 도달 가능성에 관한 제한적인 단서만 얻을 수 있습니다. 일부 서버는 ICMP에 응답하지 않으며, 중간 라우터에 따라 ICMP 응답 우선순위가 낮을 수 있습니다. 중간 홉에서 패킷 손실률이 높게 표시되더라도 이후 홉과 최종 대상이 정상이라면 실제 서비스 트래픽도 해당 구간에서 손실된다고 단정할 수 없습니다. 실제 HTTPS 요청과 지속 전송 결과를 함께 확인하세요.

같은 노드가 두 접속 네트워크에서 모두 느리고 별도의 회선은 정상이라면, 우선 안정적인 회선으로 전환한 뒤 서비스 제공자에게 테스트 시간, 접속 통신사, 노드 이름, 측정 결과를 전달하세요. 전체 구독 주소, 노드 비밀번호, 인증 정보가 포함된 설정은 보내지 마세요.

3단계: DNS와 TUN 로컬 설정

DNS 조회 지연과 데이터 전송 속도 저하 구분하기

DNS 문제는 처음 접속할 때 오래 기다리거나, 간헐적으로 주소를 조회하지 못하거나, 도메인이 적절하지 않은 주소로 연결되는 증상으로 나타나는 경우가 많습니다. 이미 연결된 다운로드가 계속 낮은 속도로 전송되는 현상까지 설명하는 경우는 드뭅니다. 설정을 바꾸기 전에 클라이언트 로그에서 DNS 시간 초과, 상위 DNS 서버 연결 실패, 조회 실패가 반복되는지 확인하세요.

mihomo를 사용한다면 최종 적용 설정에서 dns.enable, dns.enhanced-mode, dns.nameserver와 TUN을 사용할 때의 tun.dns-hijack을 확인하세요. 이는 점검할 항목이지, 모두 특정 값으로 바꿔야 한다는 뜻은 아닙니다. GUI 클라이언트는 설정 덮어쓰기나 병합을 통해 실행 파일을 생성할 수 있습니다. 구독 캐시 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 사라질 수 있습니다.

상위 DNS 서버 연결 확인: 암호화 DNS도 사용할 수 있는 네트워크 경로가 필요합니다. 암호화 DNS가 프록시에 의존하는데 프록시 서버 도메인도 같은 DNS 경로에 의존한다면 시작 단계에서 의존성 문제가 생길 수 있습니다. 일반 도메인과 프록시 서버 도메인의 DNS 설정을 구분하는 방법은 커널 문서를 확인하세요.
모드의 의미 확인: fake-ip는 주소 매핑에 사용하는 가상 주소를 반환하며, 이것만으로 DNS 오류라고 볼 수는 없습니다. 198.18.0.0/16 범위의 주소가 반환된다는 이유만으로 DNS를 바꾸지 마세요. 실제 주소 풀은 적용 중인 설정을 기준으로 확인해야 합니다.
브라우저 동작 확인: 브라우저의 보안 DNS는 별도의 HTTPS 조회를 사용할 수 있으므로 기존 53 포트 가로채기의 영향을 받지 않을 수 있습니다. 비교를 위해 브라우저의 보안 DNS를 잠시 끄고 테스트한 뒤 원래 설정으로 복구하세요.
여러 항목을 한꺼번에 바꾸지 않기: DNS 조회 경로는 한 번에 하나만 변경하고 연결을 새로 만든 뒤 첫 접속 시간을 비교하세요. 시스템, 브라우저, 라우터, 클라이언트의 DNS를 동시에 바꾸지 마세요.

시스템 프록시와 TUN을 변수 하나씩 비교하기

시스템 프록시는 앱이 프록시 설정을 지원하고 실제로 읽어야 작동합니다. TUN은 가상 네트워크 어댑터와 라우팅을 통해 트래픽을 처리하므로 적용 범위가 다릅니다. HTTP 프록시를 지원한다고 확인된 브라우저나 앞에서 안내한 curl 명령을 사용하세요. 먼저 TUN을 끄고 프록시를 명시한 요청이 작동하는지 확인한 다음 TUN으로 트래픽을 처리해 테스트하세요. 두 연결에서 최종적으로 같은 노드를 사용했는지 확인합니다.

현재 설정을 저장한 뒤 다른 VPN, 게임 가속 프로그램, 네트워크 필터링 도구를 종료하세요. 여러 가상 네트워크 어댑터가 동시에 라우팅을 차지하는 상황을 방지할 수 있습니다.
TUN을 끄고 확인된 로컬 프록시 포트를 사용해 같은 HTTPS 자료를 테스트한 뒤 속도와 오류를 기록하세요.
TUN을 켜고 일반 네트워크 요청으로 다시 테스트한 뒤, 연결 세부 정보에서 트래픽이 실제로 처리되는지 확인하세요. 프록시를 명시한 명령만으로는 TUN이 정상 작동한다고 판단할 수 없습니다.
TUN을 켰을 때만 문제가 발생한다면 모든 노드를 먼저 바꾸지 말고 권한, 라우팅, DNS 가로채기, 클라이언트 로그를 확인하세요.

4단계: 시스템 부하와 로컬 네트워크

기기가 리소스 한계에 도달했는지 확인하기

Windows에서는 Ctrl + Shift + Esc를 눌러 작업 관리자를 열고 '프로세스'와 '성능'에서 CPU, 네트워크, 디스크 사용량을 확인하세요. macOS에서는 '활성 상태 보기'를 열어 'CPU'와 '네트워크'를 확인할 수 있습니다. 테스트 중에는 인터페이스 프로세스만 보지 말고 클라이언트 커널 프로세스도 살펴보세요. CPU 코어 하나가 계속 최대치에 가까워도 전체 CPU 사용률은 높지 않을 수 있습니다.

성능이 낮은 라우터, 오래된 휴대폰, 가상 머신은 암호화 전송 중이거나 연결 수가 많을 때 성능 병목이 생기기 쉽습니다. 다중 스레드 다운로드를 일시 중지하고 단일 연결로 다시 측정하세요. CPU 사용률이 눈에 띄게 낮아지면서 속도가 달라진다면 동시 연결 수를 줄이거나 성능이 더 나은 기기를 사용하세요. 규칙과 기능을 계속 추가하는 것은 해결책이 아닙니다.

Wi-Fi, 백그라운드 트래픽, 포트 충돌 확인하기

Wi-Fi: 라우터 가까이에서 다시 테스트하고, 가능하면 유선 연결로 바꿔 보세요. 5 GHz 네트워크는 신호가 강할 때 대용량 전송 테스트에 더 적합한 경우가 많지만, 벽을 통과한 뒤의 성능은 실제로 비교해야 합니다.
백그라운드 작업: 클라우드 드라이브, 백업, 업데이트, 게임 플랫폼의 다운로드를 일시 중지하고 업로드 대역폭이 모두 사용 중인지 확인하세요. 업로드 혼잡도 웹페이지 응답과 다운로드 확인 패킷에 영향을 줄 수 있습니다.
로컬 포트 수신: 로그에 address already in use가 표시되면 먼저 포트 충돌을 해결하세요. Windows에서는 netstat -ano | findstr :7890을 실행해 관련 연결과 수신 대기 상태를 확인한 다음 PID를 확인할 수 있습니다. 포트 충돌은 시작 또는 트래픽 처리 문제이지, 노드의 속도 제한이 아닙니다.
보안 소프트웨어: HTTPS 검사, 네트워크 필터링, 트래픽 감시 기능이 작동하는지 확인하세요. 소프트웨어 문서에 따라 관련 기능만 잠시 비교 테스트하세요. 방화벽을 계속 꺼 두거나 모든 프로그램에 적용되는 허용 규칙을 추가하지 마세요.

클라이언트를 종료한 뒤에도 원래 직접 연결할 수 있던 사이트가 똑같이 느리다면 로컬 네트워크 문제부터 해결하세요. 반대로 일반 직접 연결의 속도 측정이 정상이더라도 프록시 경로가 정상이라는 뜻은 아닙니다. 두 종류의 트래픽은 서로 다른 서버와 통신사 간 연결 경로를 거칠 수 있습니다.

마무리 확인: 변경 효과 검증 및 기록 보관

설정을 한 번 변경한 뒤 테스트 연결을 새로 만드세요. 모드나 정책 그룹을 바꿔도 이미 연결된 모든 TCP 장기 연결이 즉시 다른 경로로 이동하는 것은 아닙니다. 브라우저가 기존 연결을 재사용하면 결과가 이전 노드에서 나온 것일 수 있습니다. 진행 중인 다운로드를 중지하고 요청을 다시 시작하세요. 필요한 경우 해당 연결만 종료하면 되며, 모든 앱의 세션을 지울 필요는 없습니다.

같은 조건으로 재측정: 같은 기기, 네트워크, 대상, 측정 방법으로 3회 반복하고 최고 속도만 보지 말고 중간값과 변동 폭을 비교하세요.
실제 사용 환경 확인: 문제가 있었던 동영상, 웹페이지, 다운로드 작업이 개선됐는지 확인하세요. 속도 측정 엔드포인트만 빨라지고 실제 서비스는 그대로라면 해당 서비스의 트래픽 분기, 대상 사이트, 프로토콜 경로를 추가로 점검해야 합니다.
효과가 있는 변경만 유지: 개선되지 않은 DNS, MTU, 정책 그룹 설정은 원래대로 되돌리세요. 그래야 다음 점검에서 원인을 알 수 없는 변수가 늘어나지 않습니다.
문의 정보 정리: 발생 시간, 클라이언트 및 커널 버전, 네트워크 유형, TUN 사용 여부, 비교 테스트 2건의 결과, 필요한 오류 로그를 기록하세요. 로그를 공유하기 전에 구독 주소, 인증 정보, 개인 접속 기록을 삭제하세요.

Clash 속도 저하를 점검할 때는 테스트 조건을 고정한 뒤 노드 처리량, 회선 변화, 로컬 DNS와 TUN, 시스템 환경 순서로 확인하는 것이 효율적입니다. 지연 시간 수치는 단서일 뿐입니다. 반복할 수 있고 비교 가능하며 원래대로 되돌릴 수 있는 테스트를 통해야 다음 설정 변경을 결정할 수 있습니다. 설정 항목과 규칙의 의미는 프로토콜 안내서에서 확인하고, 기본 연결 문제는 자주 묻는 질문을 참고하세요.