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

높은 지연 시간, 낮은 처리량, 연결 끊김부터 구분하기

Clash 속도 저하는 원인이 하나로 정해진 문제가 아닙니다. 웹페이지가 처음 열릴 때 느리다면 DNS 조회나 연결 설정이 지연되는 것일 수 있습니다. 다운로드 속도가 계속 수백 KB/s에 머문다면 처리량이 병목일 가능성이 높습니다. 동영상이 처음에는 잘 재생되다가 몇 분 뒤 버퍼링된다면 회선 상태 변화, 출구 혼잡, 앱이 실제로 사용하는 연결을 확인해야 합니다. 먼저 증상을 기록한 뒤 설정을 바꾸면 문제를 여러 변수로 키우는 일을 피할 수 있습니다.

Clash는 프록시 코어이며, mihomo는 Clash Meta 계열에서 발전한 호환 코어입니다. 데스크톱 및 모바일 클라이언트는 여기에 인터페이스, 시스템 프록시, 설정 관리 기능을 더합니다. 같은 이름의 설정도 클라이언트에 따라 위치가 다를 수 있으므로 점검할 때는 클라이언트 이름과 버전, 코어 버전을 함께 기록하세요. 단순히 '최신 버전 설치'라고만 적어서는 부족합니다.

기준값 만들기: 대상·시간·연결 방식을 고정하기

속도 테스트 버튼은 대개 지정된 URL의 응답 시간만 측정합니다. 모든 사이트가 정상적으로 접속되는지 확인하는 기능도, 대역폭 측정도 아닙니다. 자동 선택 그룹은 테스트 도중 노드를 바꿀 수 있습니다. 문제를 점검할 때는 먼저 수동 선택이 가능한 프록시 그룹으로 전환해 노드를 고정하세요. 백그라운드 다운로드와 클라우드 동기화를 중지한 다음 비교 테스트를 진행합니다.

1. 현재 상태를 기록하세요. 설정을 백업하고 규칙 모드, 시스템 프록시, TUN 사용 여부, 현재 출구 노드를 적어 둡니다. 프록시 클라이언트가 하나만 실행 중인지 확인하세요.
2. 로컬 네트워크를 테스트하세요. 직접 접속할 수 있는 신뢰할 만한 다운로드 사이트에서 한 번 테스트합니다. 직접 연결도 느리다면 유선 네트워크, 공유기 가까이에서 연결한 Wi-Fi, 휴대폰 핫스팟을 비교하세요.
3. 프록시 테스트 대상을 고정하세요. 속도 테스트를 허용하고 파일 크기가 충분한 HTTPS 다운로드 자료를 선택합니다. 테스트는 매번 약 30초 동안 진행하고 처음 5초간의 변동은 제외한 뒤 3회 연속 측정합니다.
4. 앱이 실제로 사용하는 경로를 기록하세요. 클라이언트의 '연결' 화면에서 대상 도메인을 찾아 요청이 의도한 프록시 그룹을 거치는지 확인합니다. 기본 화면에 표시된 노드 이름만 확인해서는 안 됩니다.
5. 한 번에 변수 하나만 바꾸세요. 노드를 바꿀 때 DNS까지 바꾸지 말고, TUN을 테스트할 때 핫스팟으로 전환하지 마세요. 각 테스트가 끝나면 이전 다운로드를 중지하고 새 연결을 시작합니다.

다음은 기록 형식의 예시이며, 이 사이트에서 직접 측정한 결과가 아닙니다. 실제로 작성할 때는 본인의 데이터를 사용하고 테스트 파일, 기기, 시간대를 동일하게 유지하세요. 순간 최고 속도로 전체 테스트 결과를 대신하지 마세요.

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

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

지연 시간 테스트는 작은 요청을 주고받는 데 걸리는 시간을 보여 줍니다. 노드 응답은 빠르더라도 출구 대역폭이 부족하거나 동시 연결 제한이 엄격할 수 있고, 대상 사이트까지의 경로가 좋지 않을 수도 있습니다. 반대로 지리적으로 멀리 있는 노드는 지연 시간이 조금 더 길어도 지속 처리량이 안정적일 수 있습니다. 웹페이지 이용과 대용량 파일 다운로드를 각각 테스트하고, 지연 시간 순위만으로 결론을 내리지 마세요.

• 같은 구독에서 노드 2~3개를 골라 비교하세요. 이름이 비슷한 노드만 비교하기보다 진입점이나 회선이 다른 노드를 우선 선택합니다.
• 구독 서비스의 데이터 잔량, 속도 제한, 만료 여부를 확인하세요. 구독을 업데이트하면 노드 정보는 갱신될 수 있지만 서버 측 대역폭이 자동으로 늘어나지는 않습니다.
• 프록시 그룹의 중첩 구조를 확인하세요. 규칙이 Proxy를 가리키더라도 Proxy가 다른 자동 선택 그룹을 참조할 수 있습니다. 최종 노드까지 펼쳐서 확인해야 합니다.
• 노드를 바꾼 뒤에는 기존 다운로드를 중지하고 다시 시도하세요. 이미 연결된 세션은 이전 출구를 계속 사용할 수 있으므로 기존 연결 결과를 새 노드의 성능으로 보아서는 안 됩니다.

자동 전환이 비교 테스트에 영향을 주지 않도록 하기

url-test는 주로 지정 URL의 지연 시간을 기준으로 경로를 선택합니다. fallback은 순서에 따라 사용할 수 있는 항목을 선택하는 데 중점을 두며, load-balance는 서로 다른 연결을 여러 노드에 분산할 수 있습니다. 어느 방식도 특정 노드의 지속적인 다운로드 성능을 직접 입증하지는 않습니다. 이런 그룹을 사용 중이라면 기존 수동 선택 그룹에서 출구를 고정한 다음 같은 자료를 테스트하세요.

특정 노드만 느리고 같은 조건에서 다른 노드는 정상이라면 문제 범위를 좁힌 것입니다. 이때 클라이언트를 반복해서 재설치하거나 설정을 전부 지워도 얻는 것이 거의 없습니다. 해당 노드의 진입·출구 회선을 더 확인하거나 구체적인 테스트 기록을 구독 서비스 제공자에게 전달하세요.

2단계: 접속 회선, 출구 경로, 혼잡 시간대

프록시를 통한 요청은 최소한 기기에서 노드 진입점까지, 노드 내부 전달 구간, 출구에서 대상 사이트까지의 경로를 거칩니다. 노드 이름에 표시된 지역만으로는 진입 통신사나 중계 방식을 알기 어렵습니다. 이름이 다른 두 노드가 같은 진입점을 사용할 수도 있습니다. 이름만 바꾸고 경로가 그대로라면 혼잡을 피하지 못할 수 있습니다.

세 가지 비교로 원인 범위 좁히기

1. 같은 노드에서 네트워크를 바꿔 보세요. 가정용 인터넷과 휴대폰 핫스팟을 비교합니다. 핫스팟에서 눈에 띄게 개선된다면 접속 네트워크나 노드까지의 경로를 의심할 수 있지만, 통신사가 속도를 제한한다고 단정할 수는 없습니다.
2. 같은 네트워크에서 시간대를 바꿔 보세요. 예를 들어 오전 10시와 오후 9시에 각각 세 차례 테스트합니다. 여러 날 저녁마다 비슷하게 속도가 떨어져야 혼잡 시간대의 영향을 의심할 근거가 됩니다.
3. 같은 출구에서 대상을 바꿔 보세요. 서로 다른 서비스에서 제공하는 합법적인 다운로드 자료 두 개를 비교합니다. 한 사이트만 느리다면 해당 사이트의 CDN 배정, 단일 연결 제한, 프록시 출구 정책을 확인하세요.

속도 측정 사이트는 여러 연결을 동시에 사용하는 경우가 많지만, 브라우저의 파일 다운로드는 연결 하나 또는 소수만 사용할 수 있습니다. 따라서 두 결과가 다른 것은 드문 일이 아닙니다. 속도 측정 결과는 높은데 파일 하나만 느리다면 단일 연결 성능을 추가로 비교하세요. 클라이언트가 '속도를 잃는다'고 바로 단정해서는 안 됩니다. 동영상 서비스는 버퍼 상태와 비트레이트에 따라 다운로드 속도를 조절하므로 대역폭 기준으로 삼기에는 적합하지 않습니다.

3단계: 시스템 프록시, 규칙, 로컬 수신 포트

앱 트래픽이 클라이언트를 거치는지 먼저 확인하기

시스템 프록시는 기기의 모든 트래픽을 가로채지 않습니다. 시스템 프록시를 사용하지 않는 앱도 있고, 명령줄 도구는 자체 옵션이나 환경 변수만 따를 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 트래픽을 처리하지만, 플랫폼 구현 방식과 라우팅 및 제외 항목의 영향을 받습니다. 브라우저는 정상인데 게임이나 명령줄 도구가 느리다면 우선 연결 방식을 확인하세요. 바로 노드 탓으로 돌릴 필요는 없습니다.

Windows 11에서는 '설정' → '네트워크 및 인터넷' → '프록시'에서 수동 프록시 주소와 포트를 확인할 수 있습니다. macOS 13 이상에서는 '시스템 설정' → '네트워크' → 현재 네트워크 서비스 → '세부사항' → '프록시'에서 확인합니다. 클라이언트에서 시스템 프록시를 켜면 보통 해당 값이 자동으로 설정됩니다. 직접 수정하기 전에 기존 값을 기록하세요.

아래는 수신 설정의 일부이며 전체 설정은 아닙니다. 7890은 예시 값일 뿐이므로 테스트할 때는 클라이언트에서 실제로 적용 중인 포트를 확인하세요. 일부 클라이언트는 인터페이스에서 설정 파일을 생성하므로 구독 파일을 직접 수정해도 다음 업데이트 때 덮어써질 수 있습니다.

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

mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받을 수 있습니다. 앱이 이전 포트를 계속 사용하면 연결에 실패하거나, 실패 후 직접 연결로 전환될 수 있습니다. allow-lan: false는 로컬 네트워크의 접근을 제한하는 설정으로, 이 값을 바꿔도 기기의 인터넷 속도는 빨라지지 않습니다.

규칙 모드에서 실제로 적용된 규칙 확인하기

클라이언트의 '연결' 화면에서 도메인, 대상 IP, 적용된 규칙, 출구 경로를 확인하세요. 한국 내 다운로드 사이트가 프록시를 거치면 속도가 오히려 느려질 수 있습니다. 프록시를 사용해야 하는 대상이 DIRECT로 연결되면 오래 기다리는 현상이 나타날 수도 있습니다. 규칙은 대개 위에서부터 순서대로 적용되므로 앞쪽의 포괄적인 규칙이 뒤쪽의 세부 규칙보다 먼저 적용될 수 있습니다. 구독의 프록시 그룹 이름은 규칙에서 참조하는 이름과 일치해야 합니다.

짧은 비교 테스트에는 전역 모드를 사용할 수 있지만, 이는 진단용일 뿐입니다. 전역 모드에서는 정상이고 규칙 모드에서 느리다면 전역 모드로 문제를 덮기보다 규칙과 프록시 그룹을 점검하세요. 설정 항목의 의미는 프록시 모드 안내와 포트 안내를 참고하세요.

DNS, TUN, 기기 부하 집중 점검

DNS는 '페이지를 여는 데 느린' 문제를 설명할 수 있지만 모든 속도 저하의 원인은 아닙니다

DNS 조회는 연결을 시작하기 전에 이뤄지며, 캐시와 연결 재사용으로 두 번째 접속은 빨라질 수 있습니다. 페이지가 로드되기까지 몇 초씩 걸리지만 다운로드가 시작된 뒤에는 속도가 정상이라면 DNS 조회와 연결 설정에 걸린 시간을 순서대로 확인하세요. 반면 이미 연결된 세션의 전송 속도가 계속 느리다면 DNS만 바꿔서는 해결되지 않는 경우가 많습니다.

• 시스템, 브라우저의 보안 DNS, 클라이언트 DNS에 각각 별도 설정이 있는지 확인하세요. 브라우저 내장 암호화 DNS가 클라이언트가 예상한 조회 경로를 우회할 수 있습니다.
• fake-ip를 사용할 때 시스템에 매핑 주소가 표시된다고 해서 DNS 조회가 실패한 것은 아닙니다. 예를 들어 198.18.0.0/16 범위는 fake-ip 주소 풀로 사용될 수 있으므로 실제 설정과 함께 판단해야 합니다.
• IPv6 경로에 문제가 의심된다면 IPv4와 IPv6를 임시로 비교하고 설정을 복구하는 방법도 기록하세요. 사이트 하나가 느리다는 이유만으로 시스템 전체에서 IPv6를 영구적으로 끄지 마세요.

TUN 설정은 변수 하나씩 비교하기

먼저 시스템 프록시 방식에서 HTTP 프록시를 지원하는 브라우저를 테스트한 다음, 노드와 대상은 그대로 두고 TUN을 테스트하세요. TUN 모드에서만 느리다면 다른 VPN, 가상 머신 네트워크, 라우팅 충돌, 클라이언트 로그를 확인합니다. 트래픽 처리 방식을 바꾼 뒤에도 대상이 같은 출구를 사용하는지 확인하세요. 그렇지 않으면 두 테스트 결과를 직접 비교할 수 없습니다.

MTU가 맞지 않으면 작은 요청은 정상인데 큰 응답에서 멈추는 증상이 나타날 수 있지만, 이것만으로 원인을 확정할 수는 없습니다. 누군가 말하는 '최적 MTU' 값을 그대로 복사하지 마세요. 확인이 꼭 필요하다면 기존 값을 기록하고 해당 설정을 지원하는 클라이언트에서 한 번에 한 항목씩 조정한 뒤 연결을 다시 맺어 테스트합니다. 개선되지 않으면 원래 값으로 되돌리세요. TUN의 stack 지원 여부와 동작은 플랫폼 및 코어 버전에 따라 달라지므로 특정 스택이 항상 더 빠르다고 볼 수 없습니다.

CPU 사용량과 로그 기록도 처리량에 영향을 줍니다

Windows의 '작업 관리자' → '성능' → 'CPU'에서 그래프를 논리 프로세서별로 바꿔 볼 수 있습니다. macOS에서는 '활성 상태 보기' → 'CPU'에서 클라이언트와 코어 프로세스를 확인하세요. 전체 사용률이 낮아 보여도 특정 코어 하나는 이미 거의 최대 부하일 수 있습니다. 오래된 기기, 복잡한 규칙, 동시 연결은 처리 부담을 키울 수 있습니다.

평소 진단에는 info 로그 수준을 사용하고, 자세한 내용이 필요할 때만 잠시 debug로 바꿔 문제를 한 번 재현한 뒤 원래대로 되돌리세요. 디버그 로그를 계속 대량으로 기록하면 처리 부담이 늘고 민감한 접속 정보가 남을 수 있습니다. 자료를 제출하기 전에는 구독 링크, 토큰, 노드 비밀번호, 개인 도메인을 가리세요.

결과 정리: 증거를 남기고 임시 설정 복구하기

점검을 마칠 때는 '같은 파일과 네트워크에서 노드 A는 세 번 연속 약 1 MB/s, 노드 B는 약 7 MB/s'처럼 재현 가능한 결론을 정리해야 합니다. '저녁에 너무 느리다'는 기록만 남겨서는 부족합니다. 수치는 예시이며, 조건을 빠짐없이 기록하고 결과를 반복해서 확인할 수 있어야 합니다. 서비스 제공자에게 문의할 때는 시간대가 포함된 발생 시각, 접속 통신사, 노드 식별 정보, 클라이언트와 코어 버전을 전달하세요. 전체 구독 정보는 보내지 마세요.

마지막으로 임시로 사용한 전역 모드, 디버그 로그, 네트워크 설정을 원래대로 되돌리고 구독을 업데이트한 뒤에도 설정이 예상대로 적용되는지 확인하세요. 속도 테스트에는 실제 데이터가 사용되므로 휴대폰 핫스팟이나 종량제 서비스를 이용한다면 테스트 시간을 조절해야 합니다. 원인을 찾지 못했다면 연결 문제 안내에 따라 계속 점검하거나 사용 가이드에서 기본 설정 절차를 확인하세요.