먼저 구분할 점: 웹페이지가 느린가요, 다운로드가 계속 느린가요?
Clash에서 노드 지연 시간이 정상으로 표시되어도 다운로드 속도까지 정상이라는 뜻은 아닙니다. 목록의 속도 측정은 보통 노드를 통해 테스트 URL에 요청을 보내며, 연결 설정 시간과 대상 사이트의 응답, 연결 재사용 여부, 클라이언트의 측정 방식에 영향을 받습니다. 이는 대역폭 측정이 아니며 동영상 사이트나 파일 서버에서의 실제 체감 속도를 그대로 보여 주지도 않습니다.
문제 해결에 앞서 문제가 발생한 사이트 하나, 기기 하나, 노드 하나를 정해 두세요. 클라우드 동기화와 시스템 업데이트, 다른 다운로드는 잠시 중지하고 규칙 모드를 사용합니다. 연결 목록에서 대상 요청이 의도한 정책 그룹으로 전달되는지도 확인하세요. 요청이 실제로 DIRECT에 연결된다면 프록시 노드를 바꿔도 해당 연결을 검증할 수 없습니다.
| 증상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| 처음 열 때만 몇 초 느리고 이후에는 정상 | DNS, 연결 설정, 대상 사이트 응답 | DNS 조회 시간과 첫 바이트까지 걸린 시간 비교 |
| 파일 다운로드 속도가 계속 느림 | 노드 대역폭, 회선 혼잡, 원본 서버의 속도 제한 | 같은 파일을 두고 노드별로 비교 |
| 특정 앱 하나만 느림 | 프록시 적용 여부, 분기 규칙, 앱 프로토콜 | 해당 앱에서 새 연결을 생성해 확인 |
| 매일 저녁 눈에 띄게 느려짐 | 인터넷 회선, 통신사 경로, 노드 부하 | 저녁 시간과 한산한 시간대의 결과 기록 |
| TUN을 켠 뒤에만 느림 | 라우팅 충돌, DNS 가로채기, MTU | 시스템 프록시만 켠 상태와 비교 |
속도 측정 기준 잡기: 연결 경로·노드·대상 고정
프록시 포트와 실제 연결 경로 확인
아래 예시는 기기의 혼합 포트 7890을 사용합니다. 모든 클라이언트의 기본 포트가 같은 것은 아니므로 클라이언트의 포트 설정이나 현재 적용 중인 설정에서 mixed-port 값을 먼저 확인하세요. HTTP 프록시 요청에는 이 포트를 사용할 수 있습니다. 컨트롤 패널 API 포트는 실제 프록시 트래픽용 포트가 아니므로 서로 바꿔 쓸 수 없습니다.
Windows PowerShell에서 다음 명령을 실행할 수 있습니다. 로컬 프록시를 거쳐 작은 페이지에 접속하므로 연결 설정과 응답 시간을 비교하는 데 적합하지만, 최대 다운로드 대역폭을 측정하는 용도는 아닙니다. macOS 또는 Linux에서는 curl.exe를 curl로 바꾸면 됩니다.
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n" https://example.com/macOS와 Linux에서는 NUL도 /dev/null로 바꾸세요. 시간은 모두 초 단위이며 요청을 시작한 시점부터 누적됩니다. HTTP 프록시를 사용할 때 time_connect는 주로 로컬 프록시에 연결하는 데 걸린 시간입니다. time_appconnect에는 프록시 터널 설정과 TLS 핸드셰이크 대기도 포함되므로 노드 왕복 지연 시간으로 해석하면 안 됩니다. 도메인 이름은 보통 프록시 경로를 통해 조회되므로 이 명령만으로 로컬 DNS 속도를 판단할 수도 없습니다.
대역폭은 지속 전송으로 별도 측정
- 접근 권한이 있는 100MB 이상 크기의 고정 파일을 선택하고, 매번 같은 파일을 요청하세요.
- 먼저 단일 연결로 다운로드해 30~60초간 안정적으로 전송된 뒤의 속도를 확인하고, 다음으로 다운로드 관리자의 다중 연결 모드를 테스트하세요.
- 같은 노드를 계속 사용하세요. 정책 그룹이 노드를 자동으로 바꾼다면 테스트 중에는 노드를 수동 지정하고 연결을 새로 만드세요.
- 테스트 시간, 네트워크 연결 방식, 적용된 규칙, 노드, 속도 단위, 클라이언트 코어 정보를 기록하세요.
단위 변환에 유의하세요. 8 Mbps ≈ 1 MB/s이며, 100 Mbps 인터넷 회선의 이론상 최대 속도는 약 12.5 MB/s입니다. 실제 속도는 프로토콜 오버헤드의 영향을 받습니다. 속도 측정 사이트의 Mbps와 다운로드 관리자의 MB/s를 그대로 비교하지 마세요.
1단계: 노드 품질과 대상 서비스의 적합성 확인
노드 단계에서는 먼저 “특정 노드만 느린지” 확인합니다. 같은 지역의 노드 두 개를 골라 같은 대상에 각각 3회 접속해 보세요. 대륙 간 거리와 출구 지역, 콘텐츠 전송 위치가 동시에 바뀌지 않도록 우선 같은 지역끼리 비교하세요. 구독 정보에 서로 다른 회선이라고 표시된 노드가 있다면 추가로 비교할 수 있습니다. 이름이 다르다고 해서 실제 진입 경로, 서버, 출구까지 서로 다른 것은 아닙니다.
지연 시간이 짧은 노드가 반드시 처리량도 높지는 않습니다
아래는 결과를 해석하는 예시이며, 이 사이트에서 직접 측정했거나 특정 노드를 추천하는 내용이 아닙니다. 같은 시간대에 같은 파일을 내려받았을 때 노드 A는 지연 시간 65ms, 다운로드 속도 0.8MB/s이고 노드 B는 지연 시간 140ms, 다운로드 속도 8MB/s라고 가정해 보세요. 지속적인 다운로드에는 B가 더 적합할 수 있지만, 상호작용이 중요한 작업이라면 첫 바이트까지 걸리는 시간과 안정성도 비교해야 합니다. 지연 시간 숫자만 정렬하면 노드의 속도 제한과 혼잡도를 놓칠 수 있습니다.
- 여러 사이트에서 특정 노드만 느림: 해당 노드의 부하나 속도 제한, 노드 진입 경로를 먼저 의심하세요.
- 같은 노드에서 특정 사이트만 느림: 대상 사이트의 속도 제한과 출구 지역, CDN 할당을 확인하세요. 이것만으로 노드 전체가 작동하지 않는다고 판단할 수는 없습니다.
- 모든 노드가 느림: 회선과 기기 단계로 넘어가세요. 특히 가정 내 네트워크 사용량과 실제 출구가 서로 다른지 확인하세요.
정책을 바꿔도 이미 연결된 다운로드는 이전 노드를 계속 사용할 수 있습니다. 테스트를 취소하고 다시 시작하거나 연결 목록에서 해당 테스트 연결만 종료한 뒤 새 연결 경로를 확인하세요. 노드 변경 전후의 같은 장시간 연결을 속도 비교에 사용하지 마세요.
자동 선택 정책 그룹도 결과에 영향을 줍니다. url-test는 설정된 테스트 대상에 따라 노드를 선택하고, fallback은 정해진 순서에 따라 사용 가능한 노드를 고릅니다. load-balance는 연결을 분배하는 기능이지, 단일 파일 다운로드의 대역폭을 합산하는 기능이 아닙니다. 특정 노드를 평가할 때는 먼저 자동 선택 변수를 배제하세요.
2단계: 회선 혼잡과 로컬 네트워크 병목 구분
회선 단계에서는 ‘두 네트워크, 두 시간대’ 방식으로 비교하세요. 컴퓨터와 클라이언트 설정, 노드, 대상은 그대로 두고 가정용 인터넷에서 측정한 다음 휴대폰 핫스팟에서도 측정합니다. 이후 한산한 시간대에 다시 테스트하세요. 핫스팟을 사용하면 통신사 경로가 바뀌며 IPv4·IPv6 및 NAT 환경도 달라질 수 있습니다. 따라서 결과는 원인 범위를 좁히는 데 활용할 뿐, 특정 통신사의 제한을 입증하는 근거로 단정하지 마세요.
| 비교 결과 | 우선 확인할 항목 | 추가 검증 |
|---|---|---|
| 가정용 네트워크는 느리고 핫스팟은 정상 | Wi-Fi, 공유기, 가정용 회선에서 노드까지의 경로 | 컴퓨터를 유선으로 공유기에 직접 연결 |
| 두 네트워크 모두 저녁에만 느림 | 공유 노드 부하 또는 공통된 원격 구간 병목 | 진입 경로가 다른 회선의 노드로 변경 |
| 프록시 연결과 국내 직결이 동시에 느림 | 로컬 대역폭 사용량, 무선 간섭, 공유기 부하 | 업로드를 중지하고 다른 기기를 확인 |
| 서로 다른 노드에서 같은 리소스가 모두 느림 | 원본 서버 또는 콘텐츠 전달 경로 | 신뢰할 수 있는 다른 리소스와 비교 |
업로드 포화와 무선 연결 문제부터 배제
백업이나 라이브 방송, 동기화 작업이 업로드 대역폭을 모두 사용하면 다운로드 확인 패킷과 상호작용 요청도 대기할 수 있습니다. Windows 11에서는 ‘작업 관리자’ → ‘성능’ → 현재 연결된 ‘이더넷’ 또는 ‘Wi-Fi’에서 송수신 속도를 확인하세요. 그런 다음 ‘프로세스’ 탭에서 네트워크 사용량순으로 정렬합니다. 네트워크 사용량이 높은 작업을 일시 중지하고 약 30초 뒤 다시 측정하세요.
무선 환경에서는 먼저 공유기 가까이 이동한 뒤 유선 연결 결과와 비교하세요. 벽을 사이에 둔 환경에서는 5GHz가 2.4GHz보다 항상 좋은 것은 아닙니다. 실제 신호 세기와 간섭이 중요합니다. 유선 연결에서 정상으로 돌아온다면 Clash DNS 변경은 우선적으로 시도할 해결책이 아닙니다.
경로 추적 결과는 보조 자료로만 활용하세요. 중간 라우터는 ICMP 응답 우선순위를 낮출 수 있으므로 특정 홉에서 시간 초과나 패킷 손실이 표시되어도 실제 트래픽 전달까지 같은 문제가 있다고 볼 수는 없습니다. 최종 대상의 동작과 지속 다운로드 속도 그래프, 다른 네트워크에서의 결과를 함께 확인하세요.
3단계: 시스템 프록시, 규칙, TUN 연결 확인
느린 앱의 트래픽이 Clash를 거치는지 먼저 확인
시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용되며, 모든 트래픽을 자동으로 가로채지는 않습니다. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 확인할 수 있습니다. 클라이언트에서 시스템 프록시를 켠 뒤 이 화면에 표시된 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. 브라우저 확장 프로그램이나 앱 자체의 프록시 설정이 시스템 설정을 덮어쓸 수도 있습니다.
클라이언트의 연결 목록을 열고 요청을 다시 보내 대상 도메인 또는 IP, 적용된 규칙, 정책 경로, 업로드·다운로드량을 확인하세요. 연결 기록이 없다면 먼저 트래픽 가로채기 설정을 점검하고, 기록에 직결로 표시된다면 규칙 순서를 확인하세요. 규칙은 보통 위에서 아래 순서로 적용되므로 앞쪽의 범위가 넓은 규칙이나 MATCH가 뒤에 있는 규칙의 동작을 바꿀 수 있습니다.
TUN 비교 테스트에서는 변수 하나만 바꾸기
- 현재 설정을 백업하고 다른 VPN이나 가상 네트워크 어댑터를 만드는 프록시 도구를 종료하세요.
- TUN을 끄고 시스템 프록시만 켠 뒤 브라우저에서 같은 대상에 접속해 결과를 기록하세요.
- 시스템 프록시를 끈 다음 TUN을 켜세요. 클라이언트에 필요한 권한이 있는지, 트래픽이 실제로 연결 목록에 나타나는지 확인하세요.
- 같은 노드에서 얻은 결과를 비교하고 로그에서 라우팅, DNS, 연결 오류를 확인하세요.
위 단계는 문제 원인을 찾기 위한 비교 방법이며, 일상적으로 반드시 둘 중 하나만 사용하라는 뜻은 아닙니다. TUN 라우팅 설치와 DNS 가로채기 방식은 클라이언트마다 다르므로 현재 버전의 실제 설정을 기준으로 확인하세요. TUN을 켠다고 노드 대역폭이 늘어나는 것은 아닙니다. 주된 목적은 트래픽을 투명하게 가로채는 것입니다.
DNS 설정: 도메인 조회 대기 시간에 대응하며 대역폭 문제를 해결하지는 않음
DNS는 주로 도메인 조회와 주소 선택, 일부 트래픽 분기 판단에 영향을 줍니다. 연결이 성립한 뒤에는 빠르고 안정적으로 다운로드되지만 도메인을 처음 열 때마다 오래 기다린다면 DNS를 우선 확인하세요. 반대로 지속 전송 속도가 계속 낮다면 DNS 서버를 바꾸는 것만으로 해결하기 어려운 경우가 많습니다.
구독 원문뿐 아니라 현재 적용된 설정 확인
- 클라이언트의 덮어쓰기나 병합 기능으로
dns설정이 변경되었는지 확인하세요. 실제 실행 설정은 구독 파일과 다를 수 있습니다. - DNS 상위 서버에 연결할 수 있는지 확인하세요. 암호화 DNS를 사용한다면 연결 시간 초과 여부도 확인해야 합니다.
- mihomo의
respect-rules등의 옵션을 사용한다면 DNS 요청이 어떤 규칙으로 분기되는지, 프록시 서버의 도메인을 별도로 조회할 수 있는지 확인해 의존성 순환을 방지하세요. fake-ip를 사용하는 경우 일부 앱이 매핑된 주소를 받는 것은 정상일 수 있습니다. 모드를 바꾼 뒤에는 테스트 앱을 다시 시작해 이전 캐시가 영향을 주지 않도록 하세요.
Windows에서는 터미널에서 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지울 수 있습니다. 다만 브라우저 캐시나 코어 자체의 DNS 캐시는 함께 지워지지 않습니다. 캐시를 비운 뒤 첫 요청이 느려지는 것은 다시 조회하기 때문일 수 있으므로 그 한 번의 요청만 비교해서는 안 됩니다.
IPv6도 바로 영구적으로 끄기보다 비교 테스트를 하세요. 로그에서 IPv6 연결이 반복해서 시간 초과되고 IPv4는 정상이라면 IPv6 조회나 연결을 일시적으로 제한해 확인할 수 있습니다. 운영체제와 클라이언트, DNS 계층의 관련 설정은 서로 다른 항목입니다. 확인을 마친 뒤에는 원래 상태로 되돌리고 실제 문제에 맞게 설정을 수정하세요.
동시 연결 설정: 연결 경주와 다중 스레드 다운로드 구분
mihomo의 tcp-concurrent는 도메인 조회로 얻은 여러 주소에 TCP 연결을 동시에 시도해 먼저 연결되는 경로를 선택합니다. 일부 대상에서 연결 대기 시간을 줄일 수 있지만 노드의 대역폭 한도를 몇 배로 높여 주지는 않으며 파일 다운로드 스레드를 늘리는 기능도 아닙니다. 구버전 Clash나 다른 코어에서는 같은 이름의 옵션을 지원하지 않을 수 있으므로 클라이언트에 표시된 코어와 해당 문서를 먼저 확인하세요.
# mihomo 최상위 설정 조각. 기존 설정에 병합해야 합니다
tcp-concurrent: true완전한 설정 파일이 아닙니다. 코어가 해당 옵션을 지원하는지 확인하고 여러 주소에 연결할 때 대기 시간이 길다고 의심되는 경우에만 A/B 테스트를 하세요. 구독을 원격에서 관리한다면 클라이언트가 제공하는 지속형 덮어쓰기 기능을 우선 사용하세요. 구독 캐시를 직접 수정하면 다음 업데이트 때 원래 값으로 돌아갈 수 있습니다. 적용 후 로그에서 해당 항목이 인식됐는지 확인하고 첫 응답 시간을 비교하세요.
다운로드 연결 수를 적은 수부터 단계별로 테스트
분할 다운로드를 지원하는 리소스라면 연결 수를 1개, 4개, 8개 순으로 테스트하세요. 단일 연결 속도가 1MB/s이고 4개 연결의 합계가 약 4MB/s라면 동시 연결이 단일 연결의 제한을 완화한 것입니다. 다만 제한 원인이 원본 서버인지 회선인지 노드인지는 확정할 수 없습니다. 8개 연결에서 4개보다 느려지거나 웹 응답이 눈에 띄게 나빠지면 연결 수를 줄이세요. 스레드를 계속 늘릴 필요는 없습니다.
기기 자원도 함께 확인하세요. Windows 11에서는 ‘작업 관리자’ → ‘세부 정보’에서 프록시 코어 프로세스를 확인하고, macOS에서는 ‘활성 상태 보기’에서 CPU와 네트워크 사용량을 살펴볼 수 있습니다. 측정 중 코어 CPU 사용률이 계속 최대치에 도달하거나 기기가 과열되고 공유기 부하가 높다면 처리량 병목이 생길 수 있습니다. CPU 사용량이 낮다고 해서 회선이 정상이라고 단정할 수는 없습니다.
결론 정리: 반복 검증된 설정만 유지
문제 해결 결과는 “같은 노드가 핫스팟에서는 정상이지만 가정용 유선 인터넷에서는 저녁에 느림”처럼 구체적인 조건으로 정리하세요. “Clash가 불안정함”이라는 결론만으로는 다음에 무엇을 확인해야 할지 알기 어렵습니다.
- 일부 노드만 느림: 같은 대상을 비교한 결과를 보관하고 안정적인 노드로 바꾸세요. 구독 제공자에게 시간대와 회선 이름을 함께 전달하세요.
- 같은 네트워크에서 전반적으로 느림: 먼저 업로드 사용량과 무선 연결, 공유기 부하를 점검한 뒤 통신사 경로를 살펴보세요.
- TUN에서만 느림: 라우팅 충돌과 DNS 가로채기, MTU를 하나씩 테스트하고 여러 매개변수를 동시에 바꾸지 마세요.
- 처음 열 때만 느림: DNS 조회와 연결 설정을 먼저 확인하세요. 다운로드가 계속 느리다면 노드와 회선, 원본 서버를 다시 비교하세요.
- 설정 변경으로 속도가 안정적으로 개선되지 않음: 원래 값으로 되돌리고 임시 디버깅 항목을 삭제해 설명 가능한 변경만 최소한으로 남기세요.
문제를 전달할 때 클라이언트 버전, 코어 이름과 버전, 운영체제, 네트워크 유형, 발생 시간대, 프록시 모드, 세 차례 측정 결과를 함께 적으세요. 로그에는 필요한 부분만 남기고 구독 링크와 액세스 토큰, 노드 비밀번호 등 인증 정보는 가리세요. 포트와 트래픽 가로채기 방식은 포트 문제 해결 안내를 참고하세요. 처음 설정하는 경우에는 시스템 프록시 설정 단계부터 확인하세요.