Clash 속도 저하 원인별 진단: 노드 품질, 경로 라우팅, 기기 설정을 차례로 점검

어디가 느린지 먼저 구분하기: 접속, 전송, 연결 불안정

Clash 속도 저하는 원인이 하나로 정해져 있지 않습니다. 웹페이지를 열 때 몇 초씩 걸리지만 파일 다운로드는 빠르다면 DNS, 연결 설정, 대상 서비스의 응답부터 살펴보세요. 다운로드가 처음에는 빠르다가 느려진다면 회선 혼잡, 노드 속도 제한, 패킷 손실을 확인하는 편이 좋습니다. 특정 앱만 느릴 때는 프록시를 거치는지, 어떤 규칙이 적용됐는지 먼저 확인하세요. 증상을 구분하면 TUN을 켜거나 DNS를 바꾸는 것보다 효율적으로 원인을 찾을 수 있습니다.

여기서 Clash는 클라이언트와 프록시 사용 환경을 뜻하며, 실제 지원 기능은 실행 중인 코어에 따라 달라집니다. mihomo를 사용하는 클라이언트와 구버전 Clash 클라이언트는 DNS, TUN, 프로토콜 지원이 다를 수 있습니다. 점검을 시작하기 전에 클라이언트의 ‘정보’ 또는 코어 정보 화면에서 클라이언트 버전과 코어 버전을 확인하세요. 앱 이름만으로 지원 범위를 판단하면 안 됩니다.

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

• 네트워크 조건 고정: 같은 컴퓨터와 라우터를 사용하고, 가능하면 유선 연결이나 라우터 가까이에서 Wi-Fi를 이용하세요. 클라우드 동기화, 시스템 업데이트, 다른 다운로드는 일시 중지합니다.
• 대상 고정: 같은 웹페이지와 같은 파일 출처를 사용하세요. 속도 측정 사이트마다 서버와 동시 연결 수가 달라 결과를 직접 비교할 수 없습니다.
• 정책 고정: 규칙 모드, 실제로 사용한 프록시 그룹과 노드 이름을 기록하세요. 테스트 중 자동 선택 그룹이 노드를 바꾸지 않도록 합니다.
• 측정 시간 고정: 약 30초 동안 연속 전송하고 안정 구간의 속도를 기록하세요. 3회 반복하고 첫 1초의 최고 속도만 기록하지 않습니다.
• 시각과 상태 기록: 테스트 시각, 시스템 프록시 또는 TUN 상태, 지연 시간과 처리량의 단위를 적어 두세요.

노드 단계: 지연 시간이 짧아도 다운로드 대역폭이 높다는 뜻은 아닙니다

클라이언트의 노드 지연 시간은 보통 코어가 해당 노드를 통해 지정된 URL에 요청을 보내 측정합니다. 결과는 테스트 대상, 연결 재사용 여부, 노드 출구, 서비스 응답 시간에 따라 달라집니다. 노드 대역폭을 측정한 값이 아니며 ICMP ping과 같다고 볼 수도 없습니다. 구독 설정에 표시된 ‘배수’, ‘고속’ 같은 이름도 실제 전송 테스트를 대신하지 못합니다.

같은 조건으로 노드 2~3개 비교하기

1. 요청이 실제로 전달되는 프록시 그룹을 열고 노드 A를 임시로 직접 선택하세요. 현재 정책이 중첩 프록시 그룹을 가리킨다면 최종적으로 어떤 노드에 연결되는지도 확인해야 합니다.
2. 같은 지연 시간 테스트 URL에 연속으로 3회 요청해 최소값뿐 아니라 편차와 시간 초과 여부도 확인하세요.
3. 같은 파일 출처에서 약 30초간 전송하세요. 이전 다운로드를 종료한 다음 노드 B로 바꿔 테스트합니다.
4. 클라이언트의 연결 목록에서 요청이 선택한 노드를 실제로 통과하는지 확인하세요. 규칙에 따라 테스트 도메인이 다른 정책으로 분기되지 않도록 합니다.

예시에서는 A가 자주 발생하는 짧은 요청에 더 적합하고, B는 연속 다운로드에 유리할 수 있습니다. 하지만 대상 사이트로 나가는 경로가 다르므로 서비스에 따라 결과가 반대로 나올 수도 있습니다. 같은 시간대에 다른 노드는 정상인데 특정 노드만 느리다면 기기 설정을 바로 바꾸기보다 해당 노드의 부하와 속도 제한, 대상 사이트까지의 경로를 먼저 확인하세요.

자동 속도 측정 그룹이 하는 일과 한계

url-test는 주로 지정한 URL의 지연 시간을 기준으로 노드를 선택합니다. fallback은 일반적으로 순서에 따라 사용 가능한 노드를 선택합니다. 어느 쪽도 처리량이 가장 높은 노드를 보장하지는 않습니다. 문제를 진단할 때는 노드를 수동으로 고정하고, 원인을 확인한 뒤 자동 정책을 복원하세요. 측정 간격을 몇 초로 지나치게 짧게 설정하지 마세요. 잦은 탐색은 요청량을 늘리고 실제 사용 환경과 비교하기도 어렵게 만듭니다.

네트워크 경로 단계: 혼잡 시간대, 로컬 네트워크, 대상까지의 출구 경로

프록시 연결은 로컬 네트워크, 통신사, 노드 진입 지점, 노드 출구, 대상 서비스 순으로 이어집니다. 클라이언트에 표시된 지연 시간 하나만으로 어느 구간이 혼잡한지 알 수는 없습니다. 매일 저녁 느려졌다가 낮에 회복되고 여러 노드가 함께 느려진다면 구독을 계속 새로고침하기보다 시간대와 진입 경로를 비교하세요.

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

• 직접 연결과 프록시 연결: 먼저 프록시 없이 접속할 수 있는 자주 쓰는 사이트를 테스트하세요. 둘 다 느리면 Wi-Fi, 라우터 부하, 인터넷 회선을 먼저 확인합니다. 직접 연결은 정상인데 프록시만 전반적으로 느리다면 프록시 진입 지점과 통신사 경로를 살펴보세요.
• 유선 인터넷과 모바일 핫스팟: 같은 기기와 노드를 유지한 채 핫스팟으로 바꿔 테스트하세요. 핫스팟에서 뚜렷하게 개선되면 기존 네트워크나 통신사 경로를 의심할 수 있습니다. 다만 셀룰러 신호와 핫스팟 자체의 변동도 고려하세요.
• 서로 다른 대상: 같은 노드로 두 서비스를 이용해 보세요. 한 서비스만 느리다면 해당 서비스의 CDN, 출구 경로, 속도 제한, 계정 상태가 원인일 수 있습니다. 노드 전체가 작동하지 않는다고 단정할 수는 없습니다.

예를 들어 같은 노드가 10:00에는 7.5 MB/s를 안정적으로 기록했지만 21:00에는 0.8 MB/s로 떨어지고, 로컬 직접 연결 다운로드는 여전히 10 MB/s라면 혼잡 시간대의 프록시 경로나 노드 부하를 더 살펴볼 만합니다. 이 결과만으로 통신사가 속도를 제한한다고 단정할 수는 없습니다. 다른 진입 지점의 노드와 모바일 핫스팟 결과까지 더해야 결론의 신뢰도가 높아집니다.

패킷 손실과 라우팅 도구의 한계

게이트웨이에 연속으로 ping을 보내면 로컬 연결이 눈에 띄게 불안정한지 확인할 수 있습니다. 원격 IP에 대한 ping이나 traceroute는 경로 일부를 살펴보는 데 보조적으로 쓸 수 있습니다. 중간 라우터는 ICMP 응답 우선순위를 낮출 수 있으므로 특정 홉에서 응답이 없다고 실제 서비스 트래픽이 그 지점에서 손실된다고 볼 수는 없습니다. 일반 traceroute는 ‘기기에서 프록시 노드를 거쳐 대상에 도달하는’ 전체 경로를 자동으로 보여 주지 않으므로 프록시 터널 전체의 경로 보고서로 취급하면 안 됩니다.

기기 단계: 시스템 프록시, 규칙, 실제 연결부터 확인하기

시스템 프록시는 시스템 프록시 설정을 읽는 앱에만 영향을 주는 경우가 많으며 모든 TCP·UDP 트래픽을 자동으로 처리하지는 않습니다. 터미널, 게임, 일부 독립 네트워크 구성 요소는 시스템 프록시를 무시할 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 조건에 맞는 트래픽을 전달합니다. 적용 범위는 더 넓지만 라우팅, 권한, DNS 연동도 함께 고려해야 합니다.

연결 기록에서 트래픽 경로 확인하기

1. 클라이언트가 규칙 모드인지 확인한 다음 문제가 발생하는 웹페이지나 앱을 엽니다.
2. 클라이언트의 연결 목록에서 대상 도메인 또는 IP, 적용된 규칙, 정책 경로, 전송량을 확인하세요. 화면의 메뉴 이름은 ‘연결’ 또는 ‘Connections’일 수 있습니다.
3. 요청에 DIRECT가 적용됐다면 앞서 설정한 도메인 규칙, 규칙 세트, 로컬 네트워크 규칙이 의도한 대로 적용되는지 확인하세요.
4. 요청이 프록시를 통과하지만 다른 노드 그룹을 사용한다면 메인 화면에서 가장 눈에 띄는 그룹만 바꾸지 말고 규칙이 지정한 정책 그룹을 확인하세요.
5. 해당 연결이 보이지 않으면 앱 자체의 프록시 설정, 프록시 우회 목록, 트래픽이 현재 코어에 실제로 들어오는지부터 확인하세요.

규칙은 순서대로 적용되며, 앞쪽 규칙이 일치하면 일반적으로 뒤쪽 규칙은 더 이상 확인하지 않습니다. 점검 중에는 일시적으로 전역 모드로 바꾸고 같은 노드로 비교해 볼 수 있습니다. 전역 모드에서 정상으로 돌아오면 규칙과 정책 그룹을 집중적으로 확인하세요. 전역 모드는 다른 앱의 트래픽 경로도 바꾸므로 테스트가 끝나면 원래 모드로 복원해야 합니다.

명시적 프록시 요청으로 앱 설정 차이 배제하기

아래 명령은 로컬 HTTP 혼합 프록시 포트가 7890인 경우에 사용할 수 있습니다. 실행 중인 설정에서 mixed-port 값을 먼저 확인하고, 실제 포트가 다르면 명령의 포트도 변경하세요. macOS와 Linux에서는 curl을 사용할 수 있습니다. Windows PowerShell에서는 이전 환경의 명령 별칭과 혼동하지 않도록 curl.exe를 권장합니다.

curl --proxy http://127.0.0.1:7890 --noproxy "" \
  --connect-timeout 10 --max-time 20 \
  -o /dev/null -sS \
  -w 'connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

curl.exe --proxy http://127.0.0.1:7890 --noproxy "" --connect-timeout 10 --max-time 20 -o NUL -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

이 204 요청은 연결과 응답 시간을 확인하는 용도이며 다운로드 대역폭을 측정하지 않습니다. 로컬 HTTP 프록시를 통하면 time_connect는 주로 로컬 프록시 포트에 연결하는 데 걸린 시간을 나타내므로 노드 왕복 지연 시간으로 보면 안 됩니다. TLS와 첫 바이트까지 걸린 시간은 요청 시작부터 누적된 값이며 각 단계의 독립적인 소요 시간도 아닙니다. 명령은 정상인데 브라우저만 느리다면 브라우저 프록시 설정, 확장 프로그램, 내장 보안 DNS, 캐시를 확인하세요.

DNS 단계: 느린 이름 해석, Fake-IP, 브라우저 보안 DNS

DNS는 첫 접속과 도메인별 트래픽 분기에 영향을 주는 경우가 많으며, 이미 연결된 대용량 전송의 처리량을 직접 높이지는 않습니다. 페이지를 처음 열 때 3초가 걸리고 새로고침은 빠르다면 DNS 해석, 연결 재사용, 캐시가 원인일 수 있습니다. 이 현상만으로 DNS 장애라고 단정하지 말고 로그에 해석 시간 초과가 있는지, 연결이 예상한 도메인을 가져왔는지 함께 확인하세요.

실제로 사용되는 DNS 해석 경로부터 확인하기

• 구독 파일의 원본 내용만 확인하지 말고 실행 중인 설정에서 dns.enable, enhanced-mode, 상위 DNS 서버와 관련 정책을 살펴보세요.
• 브라우저에서 DNS over HTTPS를 사용하면 브라우저 자체 경로로 DNS를 해석할 수 있습니다. 우선 비교를 위해 잠시 끈 뒤 최종적으로 사용할 해석 경로를 결정하세요.
• 상위 DNS 서버에 실제로 연결할 수 있는지 확인하세요. 접근할 수 없는 DNS 서버를 설정하면 응답을 기다리거나 대체 서버로 전환하느라 지연될 수 있습니다.
• DNS 서버 주소가 도메인 이름이라면 그 도메인을 해석하는 부트스트랩 DNS 설정도 확인하세요. DNS 해석이 서로를 기다리는 순환 구조를 피해야 합니다.

Fake-IP는 매핑된 주소로 도메인과 연결을 연계해 코어가 도메인 규칙을 적용하도록 돕습니다. 흔히 사용하는 설정 범위는 198.18.0.1/16이며 실제 웹 서버 주소가 아닙니다. 앱이 이 범위의 주소를 받았다고 노드에 문제가 있다는 뜻은 아닙니다. 일부 로컬 네트워크 서비스나 특수 앱은 fake-ip-filter 등으로 별도 처리해야 할 수 있지만, 모든 도메인을 제외하면 예상한 도메인 식별 동작이 달라질 수 있습니다.

Fake-IP와 redir-host를 이유 없이 번갈아 바꾸지 마세요. 한 번에 설정 하나만 변경하고 관련 연결을 다시 시작한 뒤, 필요하다면 클라이언트가 제공하는 방법으로 DNS 캐시를 비우고 같은 테스트를 반복하세요. 시스템 DNS 도구의 결과가 브라우저나 프록시 코어의 결과와 일치하지 않을 수도 있습니다. 명시적 HTTP 프록시 요청은 대상 호스트 이름을 프록시에서 처리하는 경우가 많으므로 로컬에서 nslookup 한 번 실행하는 것만으로 전체 DNS 해석 경로를 검증할 수는 없습니다.

TUN 단계: 적용 범위, UDP, 라우팅 충돌

TUN은 트래픽을 전달하는 방식이지 대역폭을 높이는 스위치가 아닙니다. 시스템 프록시에서 일반 웹페이지가 정상이라면 TUN을 켠다고 반드시 더 빨라지지는 않습니다. 반대로 시스템 프록시를 사용하지 않는 앱은 TUN이 트래픽을 처리해야만 프록시를 통과할 수 있습니다. 이때 속도가 개선되는 것은 노드 용량이 늘어서가 아니라 트래픽 경로가 바뀌었기 때문입니다.

두 모드를 비교할 때는 같은 노드를 사용하세요

1. 설정 사본을 보관하고 노드, 규칙 모드, DNS 설정을 기록하세요.
2. 먼저 TUN을 끄고 시스템 프록시만 사용해 프록시를 지원하는 브라우저나 명시적 프록시 명령으로 테스트하세요.
3. 그다음 클라이언트 안내에 따라 서비스 모드를 켜거나 권한을 부여한 뒤 TUN을 활성화하세요. 라우팅과 연결 기록이 실제로 바뀌었는지 확인합니다.
4. TUN 모드에서만 문제가 발생한다면 다른 VPN, 가상 네트워크 어댑터, 라우팅 규칙, DNS 처리 기능이 충돌하는지 확인하세요.
5. 테스트가 끝나면 평소 설정으로 복원하세요. 트래픽 경로를 확인하기 전에 TUN 스택, DNS, 노드 프로토콜을 한꺼번에 바꾸지 마세요.

브라우저의 HTTP/3는 일반적으로 UDP 기반 QUIC을 사용합니다. 시스템 HTTP 프록시와 TUN이 이를 처리하는 방식은 다를 수 있으며 앱, 코어, 노드의 UDP 지원 여부에도 달려 있습니다. 동영상 로딩이나 일부 사이트에 문제가 있다면 앱에서 QUIC을 잠시 꺼 비교해 볼 수 있습니다. TCP는 정상인데 UDP만 문제가 생긴다면 UDP 경로를 점검하세요. 이 결과를 모든 다운로드에 일반화하지 마세요.

MTU 조정은 마지막에 검토하세요

작은 요청은 성공하지만 큰 데이터 전송이 반복해서 멈추고 특정 터널 조합에서만 문제가 생긴다면 경로 MTU를 추가로 확인할 수 있습니다. 일반적인 물리 이더넷의 MTU는 1500이지만 캡슐화로 사용할 수 있는 페이로드가 줄어들 수 있습니다. 관련 근거가 있다면 TUN의 MTU를 임시로 1400으로 설정해 비교하되, 되돌릴 수 있도록 기존 값을 기록하세요. 1400이 모든 환경에 최적인 값은 아닙니다. 개선되지 않으면 원래 설정으로 복원하고 패킷 손실과 라우팅을 계속 확인하세요.

기기의 CPU, 메모리, 보안 소프트웨어 작동 상태도 함께 살펴보세요. 특정 기기에서만 느리고 전송 중 CPU 코어 하나가 계속 최대 부하에 가깝다면 암호화 처리, 트래픽 검사, 클라이언트 오버헤드가 원인일 수 있습니다. 구형 기기에서는 여러 속도 측정 작업을 동시에 실행하면서 프로토콜을 비교하지 않는 편이 좋습니다. 회사 기기의 보안 정책은 관리자와 확인하고, 테스트를 위해 보호 기능을 임의로 끄지 마세요.

원인 좁히기: 한 번에 변수 하나만 변경하기

유효한 점검 결과는 가능한 원인을 나열하는 것이 아니라 ‘어느 단계에서 어떤 조건일 때 어떤 비교 결과가 달라졌는지’를 확인하는 것입니다. 설정을 바꿀 때마다 변경 전후 기록을 남기세요. 설정 세 가지를 동시에 바꾸면 속도가 회복되어도 무엇이 효과가 있었는지 알 수 없습니다.

노드 서비스 제공자나 클라이언트 유지관리자에게 문의할 때는 클라이언트와 코어 버전, 운영체제, 발생 시각, 네트워크 종류, 사용 모드, 대상 서비스, 테스트 결과 3회분, 관련 오류 메시지를 함께 전달하세요. 공개하기 전에 구독 주소, 인증 정보, 노드 비밀번호, 액세스 토큰을 삭제해야 합니다. 전체 설정과 로그에 이러한 정보가 포함될 수 있습니다.

권장 점검 순서는 요청이 실제로 프록시를 통과하는지 확인하고, 노드를 고정해 비교한 뒤, 시간대와 네트워크를 살펴보고, DNS·TUN·기기 부하를 점검하는 것입니다. 규칙 용어는 용어집에서 확인하고, 명확한 오류가 발생하면 문제 해결을 참고하세요. 구독 업데이트는 설정을 가져오는 기능이므로 기존 노드의 경로 혼잡을 직접 해결하는 방법은 아닙니다.