Clash 속도 저하 해결

먼저 구분하기: 페이지 로딩이 느린가, 다운로드가 느린가, 연결이 끊기는가

FlClash는 Clash Meta(mihomo) 코어로 프록시 연결을 처리합니다. 웹페이지에 접속할 때는 도메인 조회, 규칙 매칭, 노드 연결, 원격 요청, 데이터 전송이 차례로 이루어질 수 있습니다. 어느 한 단계가 느려져도 ‘Clash 속도가 느리다’고 느낄 수 있지만, 원인에 따라 해결 방법은 다릅니다. 설정을 바꾸기 전에 증상을 기록하면 회선 문제를 DNS 문제로 오인하는 일을 줄일 수 있습니다.

먼저 클라우드 동기화, 시스템 업데이트, 다른 다운로드를 일시 중지하세요. 기기 한 대, 네트워크 하나, 대상 파일 하나로 테스트 조건을 통일합니다. 가정용 인터넷 속도는 보통 Mbps로 표시되지만 다운로드 도구는 MB/s로 표시할 수 있습니다. 이론상 100 Mbps는 약 12.5 MB/s이며, 실제 전송 속도는 프로토콜 오버헤드, 무선 신호, 원격 서버의 제한에도 영향을 받으므로 두 수치를 그대로 비교하면 안 됩니다.

노드 단계: 정책 그룹을 고정하고 같은 대상으로 비교

지연 시간이 낮다고 다운로드 속도까지 빠른 것은 아닙니다. 클라이언트의 지연 시간 측정은 대개 지정된 주소에 한 번 요청을 보내는 데 걸린 시간을 확인합니다. 측정 주소, 캐시, 연결 수립 과정에 영향을 받으므로 지속적인 대역폭을 그대로 나타내지 않습니다. 지연 시간이 60ms인 노드가 혼잡할 수도 있고, 160ms인 노드가 다운로드 속도를 높게 유지할 수도 있습니다.

A → B → A 순서로 테스트

1. 정책 그룹을 열고 노드 A를 직접 선택합니다. 자동 선택 또는 장애 조치 그룹을 사용 중이라면 테스트 중 아웃바운드가 자동으로 바뀌지 않는지 먼저 확인하세요.
2. 같은 대상에 접속해 테스트가 허용된 같은 파일을 다운로드합니다. 매회 약 30초간 확인하고, 시작 전 대기 시간과 안정화된 뒤의 속도를 각각 기록합니다.
3. 노드 B로 바꾼 뒤 테스트 페이지를 닫거나 다운로드를 중지하고 새 연결을 시작해 다시 측정합니다. 마지막으로 A로 돌아가 처음의 저속 현상이 일시적이었는지 확인합니다.
4. FlClash 연결 기록에서 도메인, 규칙, 아웃바운드 체인을 확인합니다. 이미 연결된 장시간 연결은 기존 노드를 계속 사용할 수 있으며, 정책 그룹을 바꿔도 기존 연결이 모두 즉시 이전되지는 않습니다.

예를 들어 A가 두 번 모두 약 1.2 MB/s이고 B가 8 MB/s라면, 우선 ‘이 대상과 시간대에서는 B의 경로가 더 나은 성능을 보였다’고 판단할 수 있습니다. 이는 설명을 위한 예시이며 이 사이트에서 측정한 결과가 아닙니다. A의 출구 노드에서 해당 사이트까지 경로가 우회하거나, 원격 서버가 출구 IP별로 속도를 제한하거나, 노드의 공유 대역폭이 부족해도 같은 현상이 나타날 수 있습니다. 두 번째 대상에서도 확인하세요.

규칙 모드에서는 같은 웹페이지의 기본 문서, 이미지, 동영상이 서로 다른 정책 그룹을 사용할 수 있습니다. 화면 오른쪽 위에서 선택된 노드만 확인해서는 안 됩니다. 전체 모드와 규칙 모드를 잠시 비교할 수 있지만, 전체 모드의 정책 그룹에서도 실제로 같은 노드가 선택됐는지 확인하세요. 전체 모드는 정상인데 규칙 모드만 느리다면 느린 요청이 직접 연결, 다른 노드 또는 부적절한 규칙 순서를 사용하는지 살펴봅니다. 규칙 매칭 방식은 고급 설정의 규칙 설명도 함께 확인하세요.

회선 단계: 시간대·네트워크·대상 사이트 비교

여러 노드가 모두 느리다고 해서 로컬 설정이 잘못된 것은 아닙니다. 노드마다 같은 진입점, 출구 또는 상위 회선을 공유할 수 있으므로 이름이 다르다고 네트워크 경로까지 독립적인 것은 아닙니다. 문제 범위를 좁히려면 다른 네트워크나 다른 시간대에서도 테스트해야 합니다.

• 시간대 비교: 같은 노드와 대상을 사용해 10:00, 20:00, 23:00에 각각 테스트합니다. 저녁 시간에만 속도가 계속 떨어진다면 2~3일간 추이를 기록해 혼잡 시간대가 있는지 판단하세요.
• 접속망 비교: 같은 컴퓨터를 가정용 Wi-Fi에서 휴대폰 핫스팟으로 전환해 테스트합니다. 데이터 요금에 유의하고 짧게만 테스트하세요. 핫스팟에서는 정상인데 유선 인터넷에서 계속 느리다면 로컬 라우터, 인터넷 회선, 관련 연동 경로를 먼저 확인하세요.
• 대상 비교: 서로 다른 사이트의 합법적인 다운로드 파일을 두 개 이상 테스트합니다. 특정 사이트만 느리다면 해당 사이트의 CDN 연결, 계정별 속도 제한, 출구 IP와 관련된 문제일 수 있습니다.
• 로컬 네트워크 비교: 가능하면 유선 LAN을 사용하거나 라우터 가까이에서 테스트합니다. 직접 연결과 프록시 다운로드가 모두 느리다면 무선 간섭과 로컬 대역폭 사용량부터 점검하세요.

Ping 패킷 손실은 단서로만 활용하세요. 라우터가 ICMP 속도를 제한할 수 있고, 중간 홉에서 응답이 없다고 실제 서비스 연결까지 끊긴 것은 아닙니다. 프록시 프로토콜, UDP 포워딩, 일반 Ping은 서로 다른 경로를 사용할 수도 있습니다. 특정 홉에 별표가 표시된다는 이유만으로 설정 전체를 바꾸지 말고, 실제 다운로드가 멈추는지와 연결 로그에 재시도가 기록되는지를 함께 확인하세요.

로컬 기기 단계: 시스템 프록시와 다른 네트워크 도구

시스템 프록시는 해당 설정을 사용하는 앱에만 영향을 주며 모든 트래픽을 처리하지는 않습니다. TUN 모드는 가상 네트워크 어댑터와 라우팅을 통해 조건에 맞는 IP 트래픽을 처리합니다. 브라우저에서 접속된다고 게임이나 명령줄 프로그램도 프록시를 사용하는 것은 아닙니다. 반대로 터미널의 프록시 환경 변수가 이전 클라이언트 포트로 요청을 보낼 수도 있습니다.

먼저 확인 가능한 프록시 경로 만들기

1. 다른 프록시 클라이언트와 불필요한 VPN을 일시 중지하고 원래 상태를 기록합니다. 회사나 기관에서 관리하는 기기라면 조직에서 요구하는 보안 구성 요소를 임의로 끄지 말고 관리 정책을 먼저 확인하세요.
2. FlClash에서 현재 실행 중인 설정의 실제 수신 포트를 확인하세요. 예시 포트를 고정 기본값으로 간주하지 마세요. 브라우저 확장 프로그램에서 별도의 프록시를 지정했는지도 살펴봅니다.
3. Windows에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 시스템 프록시를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 → ‘세부사항’ → ‘프록시’를 확인하세요. OS 버전에 따라 메뉴 이름이 조금 다를 수 있습니다.
4. TUN을 끄고 시스템 프록시만 켠 상태에서 시스템 프록시를 지원하는 브라우저로 다시 테스트합니다. 다음으로 시스템 프록시를 끄고 TUN만 따로 테스트해 두 경로를 동시에 변경하지 않도록 합니다.

로컬 HTTP 또는 mixed 수신 포트가 실제로 7890인 경우를 예로 들면, 아래 명령으로 이번 요청이 해당 경로를 사용하도록 지정할 수 있습니다. Windows PowerShell에서는 curl.exe를 사용할 수 있고, macOS와 Linux에서는 보통 curl을 사용합니다. 포트가 다르면 먼저 명령을 수정하세요. 대상 주소는 요청 처리 단계를 확인하기 위한 것이며 대역폭 측정용 파일이 아닙니다.

curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --write-out "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Windows에서는 /dev/null을 NUL로 바꾸세요. 로컬 HTTP 프록시를 통해 HTTPS에 접속할 때 time_connect는 주로 로컬 프록시 진입점에 연결하는 시간을 나타내며, 원격 노드의 지연 시간으로 볼 수 없습니다. 첫 바이트 수신 시간에는 프록시 터널 수립, TLS, 원격 서버 응답 등 여러 단계가 포함됩니다. 이 명령은 변경 전후를 비교하는 데 적합하지만, 한 번 측정한 숫자만으로 DNS 장애를 단정하기에는 적합하지 않습니다.

TUN 단계: 먼저 트래픽 처리와 리소스를 확인한 뒤 스택 변경

시스템 프록시에서는 정상인데 TUN 모드에서만 눈에 띄게 느리다면 가상 네트워크 어댑터가 정상적으로 생성됐는지, 코어에 필요한 권한이 있는지 먼저 확인하세요. Windows, macOS, Linux는 권한과 서비스 처리 방식이 서로 다릅니다. Android는 시스템 VPN 권한을 사용하므로 같은 사용자 공간에서 다른 VPN을 동시에 실행할 수 없는 경우가 많습니다.

다음 순서로 확인하세요

• 실제 연결 확인: 앱에서 요청을 보낸 뒤 FlClash에 해당 연결이 표시되는지 확인합니다. 연결 기록이 없다면 노드부터 바꾸지 말고 라우팅 처리와 앱 우회 설정을 먼저 확인하세요.
• CPU 사용량 확인: 다운로드 중 코어 프로세스의 CPU 사용량을 살펴봅니다. 특정 코어가 계속 바쁘고 처리량도 일정한 상한에 도달할 때만 기기 성능과 데이터 처리 부하를 조사할 필요가 있습니다.
• TUN 스택 변경: mihomo에서 흔히 볼 수 있는 스택 옵션은 system, gvisor, mixed이며, 실제 지원 항목은 플랫폼, 코어, 클라이언트 버전에 따라 달라집니다. 한 번에 옵션 하나만 바꾸고, 화면 안내에 따라 TUN을 다시 활성화한 뒤 테스트하세요. 모든 플랫폼에서 가장 빠른 고정 설정은 없습니다.
• 마지막으로 MTU 확인: 작은 요청은 정상인데 대용량 다운로드가 멈추거나 특정 네트워크에서 TLS 연결이 반복해서 멈춘다면 경로 MTU를 점검합니다. MTU 변경을 일반적인 속도 향상 방법으로 사용하지 마세요.

MTU 문제를 뒷받침하는 근거가 있다면 설정에서 지원하는 경우 1400을 진단용 비교 값으로 사용하고, 기존 값을 기록한 뒤 테스트하세요. 개선되지 않으면 원래 값으로 복구합니다. MTU를 낮추면 같은 데이터를 전송하는 데 필요한 패킷 수가 늘어나며 대역폭이 높아진다고 보장할 수 없습니다. 서비스 모드, 가상 네트워크 어댑터, 라우팅을 변경하기 전에는 TUN 설정 안내를 읽어 다른 네트워크에 영향을 주는 설정이 남지 않도록 하세요.

DNS 단계: 조회 시간과 전송 대역폭은 다릅니다

DNS는 주로 웹사이트 첫 접속, 연결 수립, 주소 선택에 영향을 줍니다. 연결이 수립된 뒤에도 대용량 파일 다운로드가 계속 느리다면 DNS만 바꿔서는 해결되지 않는 경우가 많습니다. DNS가 원인인지 판단하려면 첫 요청과 반복 요청의 차이를 살펴보고 로그에 기록된 시간 초과, 조회 실패, 실제 목적지 주소도 함께 확인하세요.

Fake-IP와 real-ip는 어떻게 판단할까

fake-ip는 앱에 도메인과 연결하기 위한 가상 주소를 반환한 뒤 코어가 연결을 처리합니다. redir-host는 실제 DNS 조회 주소를 사용합니다. 198.18.0.0/16 범위의 주소가 보인다고 해서 자동으로 문제가 있는 것은 아니며, 실제 사용 범위는 실행 중인 설정을 기준으로 확인해야 합니다. 낯선 주소라는 이유만으로 모드를 바꾸거나 두 모드를 단순히 ‘빠른 모드’와 ‘느린 모드’로 구분하지 마세요.

1. 구독 원문만 보지 말고 현재 적용 중인 DNS 설정을 확인하세요. 클라이언트의 덮어쓰기, 패치, 설정 병합으로 최종 dns 항목이 달라질 수 있습니다.
2. 브라우저에서 별도의 보안 DNS를 사용하는지 확인하세요. 브라우저가 자체 DoH 요청으로 도메인을 조회하면 시스템 DNS 테스트 결과가 브라우저의 실제 경로를 반영하지 않을 수 있습니다.
3. 암호화 DNS 업스트림에 실제로 연결할 수 있는지, DNS 서버 도메인의 최초 조회가 사용 불가능한 회선에 의존하는지도 확인하세요. 설정이 잘못되면 DNS 조회 의존 관계가 꼬이거나 응답을 계속 기다릴 수 있습니다.
4. DNS 설정을 변경한 뒤에는 클라이언트에서 지원하는 방법으로 DNS 캐시를 비우고 테스트 앱을 다시 시작하세요. 웹페이지 새로고침만으로는 기존 연결이나 앱 캐시가 계속 사용될 수 있습니다.

낯선 DNS 서버 목록을 그대로 복사해 전체 설정을 덮어쓰지 마세요. DNS 서버를 바꾸면 CDN 주소와 IPv4·IPv6 선택이 달라질 수 있으며, 잠시 빨라졌다고 해서 DNS 서버 자체가 더 빠르다고 볼 수는 없습니다. 로그에서 IPv6 연결이 반복 실패하고 IPv4는 안정적이라면 IPv6 경로를 따로 테스트하세요. 관련 설정을 일시적으로 바꾸면 가설을 확인할 수 있지만, 장기적으로는 라우팅을 수정하거나 실제 네트워크 환경에 맞게 주소 계열을 설정해야 합니다.

점검 결과 기록하기: 원인을 해당 단계로 좁히기

점검을 마칠 때는 재현 조건을 한 문장으로 설명할 수 있어야 합니다. 예를 들면 ‘가정용 인터넷에서 저녁에 노드 A를 사용하면 두 대상 모두 느리지만, 같은 설정으로 휴대폰 핫스팟을 사용하면 정상’과 같습니다. ‘모든 노드가 안 된다’보다 훨씬 유용한 정보입니다. 구독 서비스 제공자나 클라이언트 프로젝트에 문의할 때는 민감 정보를 가린 시간대, OS 버전, FlClash 및 코어 버전, 비교 테스트 절차를 첨부하면 됩니다.

로그는 문제 재현 전후의 필요한 수십 초만 추출하세요. 구독 주소, 노드 비밀번호, 인증 토큰, 비공개 접속 도메인은 먼저 삭제해야 합니다. 구독 링크 전체에는 접속 정보가 포함된 경우가 많으므로 공개된 문제 해결 자료에 올리지 마세요. 테스트가 끝나면 임시로 바꾼 모드, 정책 그룹, 시스템 프록시 설정을 복구하고 효과가 확인된 변경 사항만 유지하세요.

클라이언트에서 문제를 안정적으로 재현할 수 있다면 프로젝트의 정식 릴리스 버전으로 업데이트하는 방안을 검토하고, 업데이트 전후 버전과 테스트 결과를 기록하세요. 업데이트는 원인 파악을 대신하는 첫 단계가 아닙니다. 같은 노드와 대상에서 변수 하나만 바꿔 비교해야 개선 원인을 확인할 수 있습니다. 구독 가져오기나 아웃바운드 모드를 아직 확인하지 않았다면 먼저 설정 가이드를 따라 기본 동작을 확인한 뒤 속도를 측정하세요.