Clash 속도 느릴 때 단계별 점검: 노드부터 회선·기기 설정까지

시작하기 전에: 웹페이지 로딩 지연, 다운로드 속도 저하, 연결 끊김 구분하기

‘Clash 속도가 느리다’는 증상은 크게 세 가지로 나뉩니다. 웹페이지가 처음 열릴 때 오래 걸리거나, 다운로드 속도가 계속 낮거나, 동영상 재생 중 자주 멈출 수 있습니다. 각각 DNS 조회와 연결 수립 시간, 지속적인 전송 속도, 연결 안정성 문제일 가능성이 큽니다. 증상을 먼저 구분한 뒤 설정을 조정하면 불필요한 시도를 줄일 수 있습니다.

• 처음 열 때만 느리고 이후에는 정상: DNS 조회, 연결 수립 시간, 대상 사이트의 응답을 먼저 확인하세요. 노드 대역폭 부족이라고 단정하지 마세요.
• 대용량 파일 다운로드가 계속 느림: 노드와 통신사 회선을 비교하고, 서버가 단일 연결 속도를 제한하는지도 확인하세요.
• 속도가 들쭉날쭉하고 자주 다시 연결됨: Wi-Fi 상태, 패킷 손실, 노드 부하, 백그라운드 네트워크 전환을 확인하세요.
• 특정 앱에서만 느림: 해당 앱이 프록시를 거치는지, 실제로 어떤 규칙이 매칭되는지 먼저 확인하세요.

테스트 조건 고정하기

클라우드 동기화, 시스템 업데이트, 다른 다운로드를 일시 중지하세요. 같은 대상과 기기에서 같은 시간 동안 테스트하고, 한 번에 변수 하나만 바꾸세요. 테스트는 조건별로 3회, 회당 약 30초씩 진행하는 것을 권장합니다. 데이터 요금이 발생한다면 테스트에 따른 사용량도 먼저 확인하세요.

현재 사용 중인 클라이언트 이름, 코어 종류, 프록시 모드, 시스템 프록시 및 TUN 설정 상태를 기록하세요. Clash는 클라이언트 생태계에서 널리 쓰이는 이름이며, mihomo는 기존 Clash.Meta에서 이어져 발전한 코어입니다. 클라이언트와 코어에 따라 지원 설정이나 메뉴 이름이 다를 수 있습니다.

1단계: 노드 품질 — 지연 시간보다 지속 전송 속도 확인

프록시 화면의 지연 시간 테스트는 보통 지정된 URL에 요청을 보내 노드 연결 가능 여부와 응답 시간을 확인합니다. 결과는 테스트 주소, 연결 재사용 여부, 클라이언트 구현 방식에 따라 달라지며 모든 사이트에 대한 노드 속도 순위를 나타내는 것은 아닙니다. 지연 시간이 60ms인 노드가 180ms인 노드보다 다운로드 속도가 빠르다고 보장할 수 없습니다.

노드 두 개 비교하기

1. 클라이언트의 ‘프록시’ 화면에서 대상 사이트에 실제로 적용되는 프록시 그룹을 찾으세요. 그룹 안에 중첩된 프록시 그룹이 있다면 펼쳐서 최종 노드를 확인하세요.
2. 노드 A를 선택하고 대상 사이트에 새로 연결한 뒤 최초 응답 시간, 안정적인 다운로드 속도, 끊김 여부를 기록하세요.
3. 노드 B로 바꾼 다음 새 연결을 만들고 동일한 조건으로 테스트하세요. 기존 연결은 이전 출구를 계속 사용할 수 있으므로 노드만 바꾼 채 기존 다운로드 작업을 관찰해서는 안 됩니다.
4. 노드 A로 다시 돌아가 테스트하세요. 대상 서버가 일시적으로 느려진 탓에 잘못 판단하는 일을 방지할 수 있습니다.

예를 들어 A의 테스트 지연 시간은 70ms지만 안정적인 다운로드 속도는 1.2 MB/s이고, B는 지연 시간 160ms에 다운로드 속도 7 MB/s일 수 있습니다. 대용량 파일을 받을 때는 B가 더 적합하지만, 상호작용이 많은 요청은 실제 응답 시간과 지터도 확인해야 합니다. 노드 이름에 표시된 지역과 배율은 선택을 위한 참고 정보일 뿐, 실제 네트워크 경로나 사용 가능한 대역폭을 증명하지 않습니다.

노드 단계에서 확인할 수 있는 점

• 같은 시간, 같은 네트워크에서 특정 노드 하나만 느리다면 해당 노드의 부하, 진입점, 출구 또는 관련 경로를 우선 의심하세요.
• 여러 노드에서 같은 사이트만 느리고 다른 사이트는 정상이라면 클라이언트를 바로 재설치하기보다 대상 서비스, 출구 지역, 규칙을 확인하세요.
• 구독 업데이트 후 속도가 달라졌다면 노드가 교체되었는지, 프록시 그룹에서 다른 노드를 선택했는지 확인하세요. 구독을 업데이트해도 대역폭이 늘어나지는 않습니다.

2단계: 통신사 회선 — 네트워크와 시간대 비교

노드와 기기 사이의 경로에는 로컬 접속망, 통신사 네트워크, 노드 진입점이 포함됩니다. 노드 이름이 같아도 유선 인터넷과 모바일 데이터는 서로 다른 경로를 거칠 수 있습니다. 저녁 시간대의 혼잡, 통신사 간 연결, 중간 라우팅 변경으로 속도가 떨어질 수 있습니다.

다음 순서로 원인 범위 좁히기

1. 먼저 Wi-Fi 환경 확인: 공유기 가까이에서 테스트하거나 유선으로 다시 확인하세요. 신호가 좋다면 5GHz Wi-Fi가 대체로 고속 전송에 적합하지만, 벽을 통과하는 범위는 2.4GHz보다 좁을 수 있습니다.
2. 다음으로 접속 네트워크 변경: 같은 컴퓨터와 노드를 유지한 채 휴대전화 핫스팟에 연결해 테스트하세요. 모바일 데이터 요금에 유의하고 컴퓨터의 백그라운드 업데이트는 중지하세요.
3. 마지막으로 시간대 비교: 낮과 저녁에 동일한 테스트를 각각 기록하세요. 날짜와 노드가 다른 결과를 바로 비교하지 마세요.

같은 노드가 가정용 인터넷에서 0.8 MB/s에 그치다가 휴대전화 핫스팟에서 6 MB/s로 빨라졌다고 가정해 보겠습니다. 이 경우 접속 네트워크나 중간 경로를 먼저 살펴볼 수 있지만, 특정 통신사가 속도를 제한한다고 단정할 수는 없습니다. 핫스팟은 접속 방식, 출구, 라우팅을 모두 바꾸므로 추가 비교가 필요합니다.

시스템의 ping이나 경로 추적 도구로 기본 네트워크 상태를 확인할 수 있지만, ICMP 트래픽은 HTTP 시스템 프록시를 거치지 않을 수 있습니다. 노드 진입점에서 ICMP 응답을 보내지 않을 수도 있습니다. 한 번의 시간 초과나 중간 홉의 높은 지연 시간만으로 프록시 경로의 패킷 손실을 입증할 수는 없습니다. 최종 목적지의 상태와 실제 서비스 트래픽을 함께 확인하세요.

3단계: 규칙 매칭 — 느린 연결의 출구 확인

Clash 규칙 모드에서는 연결이 규칙 순서대로 검사되며, 일반적으로 처음 매칭된 규칙의 정책이 적용됩니다. 구독에 노드가 있어도 모든 앱이 해당 노드를 사용하는 것은 아닙니다. 대상 연결에 DIRECT가 적용되거나 수동으로 선택한 것과 다른 프록시 그룹에 연결될 수 있습니다.

연결 기록에서 실제 경로 확인하기

1. 클라이언트의 ‘연결’ 화면을 열고 대상 사이트에 다시 요청을 보내세요. 연결이 오래 유지되는 경우 해당 페이지를 닫거나 작업을 일시 중지한 뒤 다시 시도하세요.
2. 도메인, 대상 IP 또는 프로세스로 필터링해 매칭된 규칙, 정책 경로, 최종 노드를 확인하세요. 일부 클라이언트에서는 전체 정보를 보려면 연결 상세 정보를 펼쳐야 합니다.
3. 웹페이지의 기본 도메인뿐 아니라 리소스 도메인도 확인하세요. 페이지는 열리지만 이미지나 동영상이 느리다면 리소스 도메인에 다른 규칙이 적용되었을 수 있습니다.
4. 연결 화면에 기록이 없다면 앱이 시스템 프록시를 사용하거나 TUN으로 트래픽이 처리되는지 먼저 확인하세요. 연결이 너무 빨리 끝났거나 화면의 필터 조건 때문에 표시되지 않을 수도 있습니다.

대상 연결이 실제로 클라이언트에 들어오는 것을 확인한 뒤, 잠시 전역 모드로 전환하고 노드를 명시적으로 선택해 새 연결을 테스트할 수 있습니다. 같은 리소스의 속도가 뚜렷하게 개선되면 기존 규칙, 프록시 그룹, 출구 차이를 중점적으로 확인하세요. 전역 모드로 전환해도 원래 클라이언트를 거치지 않던 앱까지 자동으로 처리되지는 않습니다. 한 번 개선되었다는 이유만으로 규칙 파일이 손상되었다고 단정하지 마세요.

명시적 프록시로 시스템 프록시 차이 확인하기

아래 Windows PowerShell 명령은 클라이언트의 HTTP 또는 혼합 프록시 포트가 7890이라고 가정합니다. 먼저 클라이언트 설정에서 포트를 확인하세요. 실제 포트가 7897이면 명령을 그에 맞게 바꾸세요. 이 요청은 단계별 소요 시간을 확인하기 위한 것으로, 최대 다운로드 속도를 측정하는 용도가 아닙니다.

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

여기서 time_connect는 주로 로컬 프록시까지 연결하는 데 걸린 시간을 나타내며, 원격 사이트까지의 지연 시간으로 볼 수 없습니다. TLS, 첫 바이트, 전체 시간은 모두 요청 시작부터 누적된 값이므로 서로 더할 수 없습니다. 명령은 정상인데 브라우저가 느리다면 브라우저 확장 프로그램, 별도 프록시 설정, 요청 프로토콜 차이를 확인하세요.

4단계: DNS 조회 — 조회 대기와 전송 병목 구분

DNS는 이미 연결된 상태에서의 지속적인 다운로드 속도보다 첫 접속, 도메인별 라우팅, 대상 IP 선택에 더 큰 영향을 줍니다. 파일이 몇 분 동안 안정적으로 전송되는데도 속도가 낮다면 DNS만 바꿔서는 대역폭 문제가 해결되지 않는 경우가 많습니다.

먼저 DNS 조회를 처리하는 주체 확인

현재 설정의 dns 항목, TUN의 DNS 가로채기 설정, 브라우저의 보안 DNS 활성화 여부를 확인하세요. 시스템 DNS, 브라우저 DoH, 코어 DNS는 서로 다른 경로를 사용할 수 있습니다. 시스템 프록시를 켜도 모든 시스템 DNS 요청이 Clash를 거치는 것은 아닙니다.

• Fake-IP 모드: 일반적으로 도메인에 대응하는 가상 IP를 반환한 뒤 코어가 원래 도메인을 연결에 연동해 처리합니다. 흔히 198.18.0.0/16 범위를 사용하지만, 실제 설정된 fake-ip-range를 기준으로 확인하세요.
• Redir-Host 모드: 실제 DNS 조회 결과의 IP 주소를 반환합니다. 이후 도메인 연동과 규칙 매칭 방식은 코어 및 트래픽 처리 방식에 따라 다를 수 있습니다.
• 사용자 지정 업스트림: 업스트림 서버에 연결할 수 있는지, DNS 요청이 순환 참조에 빠지는지 확인하세요. 유명한 퍼블릭 DNS 주소라는 이유만으로 선택하지 마세요.

Windows에서는 Resolve-DnsName example.com으로 시스템 DNS 경로의 결과를 확인할 수 있지만, 브라우저 자체 DoH 결과와 같다고 볼 수는 없습니다. Fake-IP가 적용될 때 설정된 범위의 가상 IP가 표시되는 것은 DNS 오류가 아닙니다. 이 IP를 대상 서버 주소로 간주해 네트워크 지연 시간을 평가해서도 안 됩니다.

변경 사항이 효과 있는지 확인하기

1. 현재 DNS 설정을 백업한 뒤, 연결할 수 없는 업스트림을 교체하는 등 한 가지 요소만 수정하세요. 모드와 전체 라우팅 규칙을 동시에 바꾸지 마세요.
2. 클라이언트가 지원하는 방식으로 설정을 다시 불러오고, 필요한 경우 코어를 재시작하세요. 로그에 DNS 업스트림 연결 오류가 없는지 확인하세요.
3. Windows에서 ipconfig /flushdns를 실행해 시스템 캐시를 비운 뒤 브라우저를 다시 열어 테스트하세요. 브라우저와 코어에는 각각 별도의 캐시가 남아 있을 수 있습니다.
4. 첫 접속과 재접속 결과를 비교하세요. 첫 접속 대기 시간만 줄고 지속 다운로드 속도는 그대로라면, 개선 효과는 DNS 조회나 연결 수립 단계에 한정됩니다.

느리다는 이유만으로 fake-ip-filter 항목을 무작정 늘리지 마세요. 이 설정은 특정 도메인에 Fake-IP를 반환하지 않도록 하는 기능으로, 주로 로컬 네트워크 기기 검색이나 특정 앱 호환성 문제에 쓰입니다. 일반적인 속도 향상 목록이 아닙니다. 수정하기 전에 문제가 발생하는 구체적인 도메인과 증상을 확인하세요.

5단계: 기기 설정 — 트래픽 처리, 리소스, 프로토콜 확인

노드, 네트워크, 규칙에 뚜렷한 문제가 없을 때는 기기 자체를 확인하세요. 이 단계에서는 ‘속도 향상’ 설정을 찾기보다 이중 프록시, 리소스 병목, 앱 수준의 재시도 여부를 살펴보는 것이 중요합니다.

TUN은 대역폭을 높이지 않습니다

TUN은 가상 네트워크 인터페이스로 트래픽을 처리하며, 시스템 프록시를 따르지 않는 앱을 연결할 때 유용합니다. 트래픽이 코어에 들어가는 방식이 달라질 뿐, 노드 요금제의 대역폭이 늘어나지는 않습니다. 프로토콜 스택, 라우팅, MTU 설정에 따라 호환성에 영향을 줄 수 있지만 모든 기기에 맞는 고정된 ‘최고 속도’ 설정은 없습니다.

시스템 프록시에서는 정상인데 TUN에서만 느리다면 같은 앱으로 증상을 재현한 뒤 라우팅 충돌, DNS 처리, 다른 가상 네트워크 어댑터, 코어 로그를 확인하세요. MTU, 프로토콜 스택, DNS 모드를 한꺼번에 바꾸지 마세요. 문제가 해결되더라도 무엇이 효과를 냈는지 알기 어렵습니다.

브라우저가 느리다면 UDP와 QUIC도 확인

HTTP/3는 일반적으로 UDP를 기반으로 하는 QUIC을 사용합니다. 앱이 시도한 UDP 경로가 연결되지 않으면 대기 후 다른 방식으로 전환될 수 있습니다. 노드 프로토콜, 서버, 트래픽 처리 방식이 해당 트래픽을 지원해야 합니다. 시스템 HTTP 프록시를 사용하는 브라우저 동작은 TUN으로 트래픽을 처리할 때와 다를 수 있습니다.

브라우저 개발자 도구의 네트워크 패널에서 프로토콜과 요청 시간을 확인하거나, 브라우저의 QUIC 관련 실험 기능을 잠시 끄고 비교할 수 있습니다. 테스트 후에는 설정을 되돌리세요. UDP 연결 실패나 전환 대기 등의 근거가 있을 때만 이 경로를 조사하고, 모든 속도 문제의 해결책으로 QUIC을 끄지 마세요.

재테스트와 기록: 다음 조치를 하나로 좁히기

설정을 바꿀 때마다 기존 대상과 테스트 시간을 유지해 3회 다시 테스트하세요. 효과가 있는 변경은 유지하고 도움이 되지 않는 시도는 되돌리세요. 한 번의 테스트로 내릴 수 있는 결론은 제한적입니다. 노드를 바꿔 효과가 있었다고 DNS도 반드시 바꿔야 하는 것은 아니며, 핫스팟에서 개선됐다고 클라이언트를 재설치해야 하는 것도 아닙니다.

1. 노드 간 차이가 뚜렷함: 안정적인 노드는 유지하고, 문제가 있는 노드와 발생 시각을 기록해 구독 서비스 제공자에게 문의하세요.
2. 네트워크나 시간대별 차이가 뚜렷함: 기기 DNS를 반복해서 바꾸기보다 접속 네트워크, 무선 환경, 노드 진입 회선을 먼저 조정하세요.
3. 규칙과 출구가 맞지 않음: 해당 도메인의 규칙이나 프록시 그룹을 조정한 뒤 기본 요청과 리소스 요청 모두 예상대로 처리되는지 확인하세요.
4. 첫 요청만 느림: DNS 조회, TLS 연결, 원격 서버의 첫 바이트 응답을 중심으로 확인하세요. 작은 웹페이지 요청으로 대역폭을 추정하지 마세요.
5. 특정 트래픽 처리 방식에서만 느림: 정상 작동하는 방식을 유지하고, 코어 버전, 재현 절차, 개인정보를 가린 로그를 준비해 추가로 원인을 확인하세요.

가장 유용한 결과는 ‘모든 설정을 건드려 봤다’가 아니라 ‘같은 대상이 노드 A에서는 느리고 노드 B에서는 정상이다’ 또는 ‘TUN 모드에서만 재현된다’와 같은 기록입니다. 이런 정보가 있으면 다음 점검 단계를 구체적으로 정할 수 있습니다. 기본 연결 상태부터 확인해야 한다면 연결 확인 절차에 따라 안정적인 비교 환경을 먼저 구성하세요.