Clash 인터넷 속도 느림
단계별 점검

먼저 연결 지연, 다운로드 속도 저하, 특정 사이트만 느린 경우를 구분하세요

Clash 패널의 지연 시간은 지정한 주소를 한 번 탐지한 결과일 뿐입니다. 다운로드 대역폭이나 모든 웹사이트의 접속 품질을 나타내지는 않습니다. 지연 시간이 80ms인 노드라도 출구 구간이 혼잡하면 속도가 매우 낮을 수 있고, 180ms인 노드는 오히려 다운로드 속도가 더 안정적일 수 있습니다. 먼저 증상을 구체적으로 파악한 뒤 확인할 항목을 정하세요.

테스트 전에 클라우드 동기화, 게임 플랫폼 업데이트 등 대용량 작업을 일시 중지하세요. 기기 한 대, 네트워크 한 개, 대상 주소 한 개를 고정하고 각 조건에서 최소 3회 측정합니다. 시간대, 규칙 모드, 실제 연결 노드, 다운로드 속도, 오류 메시지를 기록하세요. 속도를 측정하는 동안 노드를 계속 바꾸면 연결마다 출구가 달라져 결과를 비교하기 어렵습니다.

1단계: 로컬 포트와 실제 트래픽 경로 확인

예시 포트를 현재 사용 중인 포트로 착각하지 마세요

클라이언트의 포트 설정에서 현재 HTTP, SOCKS 또는 혼합 포트를 확인하세요. 흔히 쓰는 예시는 7890이지만 클라이언트에 따라 다른 포트를 사용하기도 합니다. HTTP 포트를 SOCKS 포트로 사용할 수는 없습니다. mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받습니다.

다음은 mihomo의 포트 수신 관계를 설명하는 설정 예시입니다. 노드, 정책 그룹, 규칙을 포함한 전체 구독 설정이 아닙니다. 그래픽 클라이언트는 실행 설정을 자동 생성할 수 있으므로 클라이언트 설정에서 먼저 수정하세요. 구독을 업데이트하면 수동 변경 사항이 덮어써질 수 있습니다.

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

• mixed-port: 7890: 로컬 앱은 127.0.0.1:7890에 연결해 프록시를 사용할 수 있습니다.
• allow-lan: false: LAN에 프록시 포트를 공개하지 않습니다. 로컬 속도 문제를 확인할 때는 켤 필요가 없습니다.
• mode: rule: 규칙에 따라 정책을 선택합니다. 모든 연결이 프록시를 통과한다는 뜻은 아닙니다.
• log-level: info: 일반적인 문제 해결에 필요한 정보를 기록합니다. 디버그 로그를 장시간 대량으로 남기지 마세요.

먼저 프록시를 명시해 요청해 보세요

Windows PowerShell에서는 curl.exe를 사용하세요. 일부 환경에서는 curl이 다른 명령으로 해석될 수 있습니다. 아래 요청은 HTTP 프록시 포트와 HTTPS 터널이 작동하는지 확인하기 위한 것으로, 대용량 파일 속도 측정용은 아닙니다. 실제 포트가 7890이 아니라면 명령에 있는 포트 번호를 바꾸세요.

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -I https://example.com/

macOS와 Linux에서는 명령의 curl.exe를 curl로 바꾸면 됩니다. 클라이언트의 ‘연결’ 페이지에서 example.com을 필터링해 적용된 규칙, 정책 그룹, 최종 출구를 확인하세요. 로컬 프록시를 명시해도 요청이 코어에 전달된다는 것만 확인할 수 있습니다. 규칙에 따라 대상이 DIRECT로 연결될 수도 있습니다.

로컬 포트에 연결할 수 없다는 오류가 나오면 원격 노드를 바꾸기 전에 코어가 실행 중인지, 포트가 다른 프로세스에 점유되어 있는지 확인하세요. Windows에서는 아래 명령으로 포트 리스닝 상태와 PID를 확인할 수 있습니다. 출력이 없으면 해당 포트에서 TCP 연결을 수신 중이지 않은 경우가 일반적입니다. PID가 표시되면 작업 관리자의 ‘세부 정보’ 탭에서 프로세스를 확인하세요.

netstat -ano | findstr LISTENING | findstr :7890

2단계: 노드 부하와 정책 그룹 선택 확인

노드 이름은 보통 제공업체가 붙인 표시일 뿐, 실제 위치나 전송 경로를 증명하지 않습니다. 문제를 확인할 때는 정책 그룹에서 특정 노드를 고정한 다음 연결 세부 정보를 살펴보세요. 테스트 그룹에서 url-test, fallback 또는 load-balance를 사용하면 새 연결이 자동으로 노드를 바꾸거나 출구를 분산할 수 있습니다. 정책 그룹 이름만으로 고정 노드라고 판단하지 마세요.

1. 현재 적용 중인 정책 그룹에서 노드 A를 선택하세요. 자동 그룹이라면 기존 수동 선택 그룹을 임시로 사용할 수 있습니다. 먼저 설정을 백업하고 구독 전체를 덮어쓰지 마세요.
2. 기존 다운로드 작업을 종료한 뒤 새 연결을 시작하세요. 노드를 바꿔도 이미 수립된 TCP 연결이 새 출구로 옮겨가지는 않습니다.
3. 같은 다운로드 소스로 3회 측정하고, 매회 약 30초 동안 확인하세요. 시작 직후 최고 속도만 보지 말고 속도가 안정된 구간의 수치를 기록하세요.
4. 노드 B로 같은 절차를 반복하세요. 이름만 비슷한 노드로 바꾸기보다 A와 회선이나 제공업체가 다른 노드를 우선 선택하세요.
5. 다른 시간대에도 다시 측정하세요. 저녁에는 느리고 낮에는 정상이라면 용량 부족이나 경로 혼잡을 의심할 수 있지만, 그것만으로 서버 부하가 높다고 단정할 수는 없습니다.

테스트 소스가 아니라 노드가 느린지 확인하는 방법

노드 A에서 서로 다른 다운로드 소스 두 곳이 모두 느리고, 같은 기기와 네트워크에서 B는 정상이라면 A의 입구·출구 구간이나 리소스 제한을 우선 의심할 수 있습니다. 모든 노드에서 특정 다운로드 소스만 느리다면 해당 사이트의 단일 연결 속도 제한, 계정 제한, CDN 라우팅을 확인하세요. 공용 속도 측정 사이트의 다중 연결 결과는 브라우저에서 파일 하나를 다운로드하는 속도를 그대로 반영하지 않습니다.

3단계: 로컬 네트워크와 원격 회선 구분

“직접 연결은 정상인데 프록시만 느린” 원인은 여러 가지일 수 있습니다. 로컬 통신사에서 노드 입구까지의 경로 혼잡, 노드 출구에서 대상 사이트까지의 품질 저하, 프록시 프로토콜에 사용되는 연결 제한 등이 있습니다. 같은 기기에서 네트워크 접속 방식을 바꿔 비교하면 원인을 구분하는 데 도움이 됩니다.

Windows에서는 먼저 ipconfig로 현재 기본 게이트웨이를 확인한 뒤 실제 게이트웨이 주소를 대상으로 ping -n 30을 실행하세요. macOS와 Linux에서는 ping -c 30을 사용할 수 있습니다. 예시 게이트웨이 주소를 자신의 라우터 주소로 그대로 사용하지 마세요. 네트워크를 거의 사용하지 않을 때도 LAN 지연 시간이 크게 흔들리거나 지속적인 패킷 손실이 발생하면 Wi-Fi 채널, 거리, 케이블, 라우터 부하부터 확인하세요.

노드 입구에 대한 Ping이나 경로 추적 결과는 참고 자료로만 활용하세요. 일부 서버는 ICMP에 응답하지 않으며 중간 라우터가 탐지 패킷을 제한할 수도 있습니다. 특정 홉에서 패킷 손실이 표시되더라도 이후 홉과 최종 대상이 정상이라면 실제 데이터 전달이 손실된다고 볼 수 없습니다. 경로 추적 화면만 보고 노드 장애를 단정하지 마세요.

업로드나 다운로드 중에만 느려지는 경우

유휴 상태에서는 정상이지만 파일을 업로드하면 웹페이지와 음성 통화가 함께 끊긴다면 업로드 대역폭이 가득 차 대기열이 길어진 것일 수 있습니다. 먼저 업로드 속도 제한을 사용 가능한 업로드 대역폭의 약 80~90%로 설정한 뒤 다시 테스트하세요. 이 범위는 문제 해결의 출발점이지 정해진 최적값은 아닙니다. 대기열 관리를 지원하는 라우터라면 추가로 조정할 수 있습니다. 클라이언트, 라우터, 노드를 한꺼번에 바꾸면 어느 변경이 개선에 영향을 줬는지 알기 어렵습니다.

curl로 대기 시간과 전송 속도 따로 확인하기

다운로드를 허용하고 파일 크기를 알 수 있으며 전송이 충분히 오래 이어지는 HTTPS 파일을 테스트하면 웹페이지를 반복해서 새로고침하는 것보다 결과를 비교하기 쉽습니다. 몇 KB짜리 페이지로 대역폭을 추정하거나 브라우저 로그인, CAPTCHA, 짧은 만료 시간이 있는 서명 URL을 사용하지 마세요. 다음 명령은 macOS와 Linux의 일반적인 셸에서 사용할 수 있습니다. 확인한 다운로드 주소를 입력하며 파일은 디스크에 저장하지 않습니다.

printf '테스트 파일의 HTTPS 주소를 입력하세요:'
IFS= read -r test_url
curl --noproxy "" \
  --proxy http://127.0.0.1:7890 \
  --location \
  --connect-timeout 10 \
  --max-time 30 \
  --output /dev/null \
  --write-out '\nhttp=%{http_code}\nfirst_byte=%{time_starttransfer}s\ntotal=%{time_total}s\nbytes=%{size_download}\nspeed=%{speed_download} B/s\n' \
  "$test_url"

• http: 403, 429 또는 오류 페이지가 아니라 정상적인 콘텐츠 응답인지 먼저 확인하세요. 206은 서버가 일부 콘텐츠를 반환했다는 뜻일 수 있습니다.
• first_byte: 요청 시작부터 첫 바이트를 받을 때까지의 시간입니다. 앞선 연결 및 핸드셰이크 과정이 포함되며 DNS 조회 시간만을 나타내지는 않습니다.
• total: 이번 요청에 걸린 전체 시간입니다. 리디렉션, 서버 대기, 실제 전송 시간이 모두 영향을 줍니다.
• speed: 이번 전송에서 보고된 평균 다운로드 바이트 수/초입니다. 실제 콘텐츠 크기와 테스트 시간도 함께 고려하세요.

대용량 파일 전송이 30초 안에 끝나지 않으면 명령이 시간 초과 오류로 종료될 수 있습니다. 이는 --max-time 30에 설정된 정상적인 제한입니다. 전체 시간 초과를 회선 단절로 판단하지 말고 다운로드된 바이트 수를 함께 확인하세요. 테스트 파일이 몇 초 만에 전송된다면 더 큰 파일을 선택하거나 짧은 테스트였다고 명확히 기록하세요.

HTTP 프록시를 통해 HTTPS 대상에 접속할 때 대상 도메인의 DNS 조회는 보통 프록시 경로에서 처리됩니다. curl의 로컬 DNS 측정 시간은 mihomo 내부에서 대상 주소를 조회하는 데 걸린 시간을 그대로 나타내지 않습니다. 첫 바이트 수신이 느리다면 코어 로그, 규칙 적용 결과, 실제 DNS 설정을 함께 살펴보세요. 하나의 시간 값만으로 판단해서는 안 됩니다.

로컬 설정: 시스템 프록시, TUN, DNS를 따로 확인

먼저 한 가지 연결 방식으로 기준값 측정하기

시스템 프록시는 주로 시스템 설정을 읽는 앱에 영향을 줍니다. 터미널, 일부 게임, 자체 네트워크 스택을 사용하는 프로그램은 시스템 프록시를 따르지 않을 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 조건에 맞는 IP 트래픽을 처리하지만 규칙, 제외 항목, 권한, 플랫폼 구현의 영향을 받습니다. 모든 연결이 원격 프록시를 통과한다는 뜻은 아닙니다.

1. 다른 VPN, 게임 가속기, 프록시 프로그램을 일시 중지하세요. 시스템 프록시 설정이 중복되었거나 여러 가상 네트워크 인터페이스가 트래픽을 처리하고 있지 않은지 확인하세요.
2. 먼저 TUN을 끄고 앞서 안내한 curl 명시적 프록시 명령으로 기준값을 측정하세요. 이때 앱이 시스템 프록시 설정을 읽는지 여부에는 영향을 받지 않습니다.
3. 그다음 시스템 프록시를 켜고 브라우저에서 확인하세요. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 시스템 설정을 확인하고, 브라우저 프록시 확장 프로그램이 설정을 덮어쓰는지도 살펴보세요.
4. 프록시를 지원하지 않는 앱의 트래픽을 처리해야 할 때 TUN을 켜세요. 클라이언트 서비스가 설치되어 있는지, 필요한 권한을 허용했는지 확인하고 새 연결로 속도를 비교하세요.

TUN을 켠 뒤에만 속도가 느려진다면 라우팅 충돌, DNS 가로채기 설정, 가상 네트워크 인터페이스 상태를 우선 확인하세요. MTU를 먼저 조정하지 마세요. 작은 요청은 정상인데 큰 응답이나 특정 연결이 반복해서 멈추는 등 재현 가능한 증상이 있고 다른 원인을 배제한 뒤에야 경로 MTU를 점검하는 것이 좋습니다. 값을 바꾸기 전에 기존 설정을 기록하고 한 번에 한 항목만 수정하세요.

DNS 서버를 많이 설정한다고 더 빨라지는 것은 아닙니다

mihomo의 dns.nameserver, dns.proxy-server-nameserver, dns.nameserver-policy는 서로 다른 대상을 처리합니다. 노드 서버 도메인의 조회와 대상 웹사이트 도메인의 조회도 서로 다릅니다. 현재 코어 문서와 구독 설정을 기준으로 수정하고, 노드 도메인 조회가 아직 연결되지 않은 프록시 경로에 의존하지 않도록 주의하세요.

fake-ip를 사용하면 클라이언트에 매핑된 주소가 전달되는 것이 정상 동작일 수 있습니다. 이를 곧바로 DNS 오류라고 판단하지 마세요. 일부 앱만 호환되지 않는다면 DNS 모듈 전체를 끄기보다 해당 도메인에 fake-ip-filter를 적용할 수 있는지 검토하세요. IPv6도 IPv6 경로 유무를 비교해 원인을 확인하고, 모든 속도 저하 문제의 해결책으로 IPv6를 끄지는 마세요.

설정을 불러올 수 없다면 속도 측정보다 먼저 코어 오류를 확인하세요. mihomo 명령줄을 사용하는 경우 설정 파일이 있는 디렉터리에서 아래 검사를 실행할 수 있습니다. 그래픽 클라이언트에서는 자체 설정 검사 기능과 로그 메뉴를 이용하세요. 구문 검사를 통과해도 설정을 파싱할 수 있다는 뜻일 뿐, 노드가 작동하거나 규칙이 예상대로 적용된다는 보장은 없습니다.

mihomo -t -f config.yaml

마무리: 변경은 최소화하고 재현 가능한 결론 내리기

효과적인 문제 해결이라면 “어떤 조건을 바꾼 뒤 어떤 지표가 달라졌는지” 설명할 수 있어야 합니다. 예를 들어 같은 기기, 노드, 파일을 사용했을 때 가정용 인터넷에서는 느리고 모바일 핫스팟에서는 정상이라면 접속 네트워크에서 노드 입구까지의 경로를 우선 확인하세요. 같은 네트워크에서 노드 A는 두 대상 모두 느리고 노드 B는 정상이라면 제공업체에 A의 회선과 리소스를 확인해 달라고 요청하세요.

• 브라우저만 느린 경우: 확장 프로그램의 프록시 설정, 사이트 캐시, 해당 사이트에 실제로 적용된 규칙을 확인하세요. 클라이언트 전체를 먼저 재설치할 필요는 없습니다.
• 모든 노드가 느린 경우: 직접 연결 기준값, 로컬 포트, 백그라운드 트래픽, 다른 네트워크 프로그램을 확인한 다음 공통 서비스 제공업체의 제한을 살펴보세요.
• 자동 정책 그룹만 느린 경우: 노드를 고정해 다시 측정하고 탐지 주소, 노드 전환 방식, 새 연결의 실제 출구를 확인하세요.
• 구독 업데이트 후 느려진 경우: 정책 그룹, 규칙 순서, 노드 변경 사항을 비교하고 백업을 보관하세요. 구독 파일 크기만 비교해서는 안 됩니다.
• 다른 사람의 도움이 필요한 경우: 운영체제 버전, 클라이언트 버전, 코어 버전, 시간대, 접속 네트워크, 재현 절차, 민감 정보를 삭제한 로그를 제공하세요.