Clash 속도 저하 계층별 점검법: 노드·경로·로컬 설정 중 원인부터 구분하기

먼저 ‘느림’을 정의하기: 지연 시간, 대역폭, 응답 시간은 서로 다르다

Clash 또는 mihomo 패널에서 지연 시간이 수십 ms로 표시돼도 웹페이지가 느리게 열릴 수 있습니다. 반대로 지연 시간이 180ms인 노드가 회선을 안정적으로 가득 채우기도 합니다. 지연 시간, 패킷 손실, 사용 가능한 대역폭, 웹사이트 응답 시간은 서로 다른 구간을 나타내기 때문입니다. 점검 전에 노드 목록의 숫자 하나만 보면 경로 혼잡을 클라이언트 문제로 오인하기 쉽습니다.

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

노드를 바꾸기 전에 테스트 조건부터 고정하세요. 파일 동기화, 업데이트 다운로드, 동영상 재생 중인 앱을 닫고 같은 기기를 같은 라우터에 연결한 뒤, 웹페이지 첫 로딩 시간을 확인할 대상과 지속 다운로드용 대상을 하나씩 정합니다. 매 라운드 최소 3회 테스트해 중앙값을 기록하고, 한 번의 최고 속도로 결론 내리지 마세요.

1. 클라이언트에서 ‘직접 연결’ 모드로 전환하고 로컬 회선의 지연 시간과 다운로드 속도를 기록합니다.
2. ‘규칙’ 모드로 되돌린 뒤 동일한 테스트 노드와 테스트 주소를 고정합니다.
3. 오전과 저녁 20:00~23:00에 각각 테스트해 시간대별 차이를 비교합니다.
4. 클라이언트의 현재 모드, 노드 이름, 다운로드 속도, 첫 로딩 대기 시간, 타임아웃 발생 여부를 기록합니다.

1단계: 노드 측 지연 시간·부하·프로토콜 상태 확인

노드 문제는 보통 같은 정책 그룹에서 일부 노드만 눈에 띄게 느려지고, 다른 지역이나 다른 진입점으로 바꾸면 즉시 회복되는 형태로 나타납니다. 여기서는 ‘지연 시간 테스트를 통과한다’는 것과 ‘노드가 안정적인 전송 속도를 제공한다’는 결론을 구분해야 합니다. Clash 패널의 지연 시간 테스트는 대개 지정된 URL에 연결해 응답 시간을 측정합니다. 연결이 끊긴 노드를 걸러낼 수는 있지만 대용량 파일 다운로드 속도를 직접 보여주지는 않습니다.

정책 그룹으로 동일 조건에서 가로 비교하기

클라이언트의 ‘프록시’ 페이지에서 현재 규칙이 실제로 참조하는 정책 그룹을 찾습니다. 일반적인 데스크톱 클라이언트에서는 ‘프록시’ → ‘노드 선택’으로 그룹 내 노드를 확인할 수 있습니다. Clash Verge Rev를 사용한다면 ‘설정’ → ‘Clash 설정’에서 현재 실행 모드를 확인한 다음 ‘프록시’ 페이지로 돌아와 노드를 바꾸세요. 노드를 바꾸면서 DNS, TUN 또는 규칙까지 동시에 수정하지 마세요. 어떤 변경이 효과를 냈는지 판단할 수 없게 됩니다.

• 먼저 같은 지역의 노드 3개를 선택하고 각각 지연 시간 테스트를 3회 실행합니다.
• 지연 시간이 100ms 이상 크게 흔들리거나 연속으로 타임아웃이 발생하면 노드 또는 진입점 불안정으로 우선 판단합니다.
• 지연 시간이 안정적이지만 다운로드 속도가 낮다면 최소 60초 동안 지속 다운로드를 테스트합니다.
• 같은 지역의 노드가 모두 느리면 비교 대상으로 다른 지역 노드 하나를 추가합니다.
• 특정 노드 하나만 느리다면 로컬 매개변수를 계속 조정하기보다 노드를 바꾸는 편이 대체로 효과적입니다.

배율은 속도가 아니다

구독 패널에 표시되는 ‘0.5배’, ‘1배’, ‘2배’는 보통 트래픽 과금 배율이지 속도 배수가 아닙니다. 2배 노드가 1배 노드보다 자동으로 두 배 빠른 것은 아닙니다. 다른 경로를 사용할 수도 있고, 단순히 트래픽 차감 비율만 다를 수도 있습니다. 속도는 실제 측정한 전송량, 패킷 손실, 시간대별 안정성을 기준으로 판단해야 합니다.

자동 속도 측정 그룹이 ‘지연 시간은 낮지만 대역폭은 낮은’ 노드를 선택할 수 있다

url-test 정책 그룹은 테스트 URL의 응답 결과에 따라 노드를 자동으로 선택합니다. 테스트 대상이 반환하는 데이터가 매우 작으면 핸드셰이크가 빠른 노드가 선택될 수 있지만 지속 대역폭은 좋지 않을 수 있습니다. 전환이 너무 자주 일어나지 않도록 테스트 간격을 적절히 늘리고, 안정성이 비슷한 노드끼리 같은 그룹에 넣으세요. 모든 지역을 한 그룹에 섞는 것은 피하는 편이 좋습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 노드-A
      - 노드-B
      - 노드-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

interval: 300은 300초마다 한 번씩 테스트한다는 뜻이며, tolerance: 80은 지연 시간 차이가 작을 때 잦은 전환을 줄이는 데 사용됩니다. 여기서 URL은 연결 가능 여부와 응답만 테스트하며, 전체 대역폭 측정용으로 사용해서는 안 됩니다. 구독에서 생성된 설정을 수정하기 전에 클라이언트가 구독을 업데이트할 때 로컬 변경 사항을 덮어쓰는지도 확인하세요.

2단계: 경로 측면에서 피크 시간 혼잡·패킷 손실·라우팅 변화 확인

경로 문제는 로컬 통신사, 망간 연동, 진입 서버, 출구 서버 사이에서 발생합니다. 낮에는 정상인데 저녁 20시 이후 지연 시간이 늘거나, 모바일 네트워크는 정상인데 가정용 인터넷만 느려지는 등 뚜렷한 시간대 특성을 보이는 경우가 많습니다. 이때 클라이언트를 반복해서 재설치하거나 설정을 삭제해도 결과는 달라지지 않습니다.

시간대와 접속 네트워크를 교차 검증하기

테스트 중에는 노드와 클라이언트 설정을 그대로 두고 네트워크만 바꿔야 합니다. 먼저 가정용 Wi-Fi로 테스트한 뒤 휴대폰 핫스팟으로 테스트하세요. 핫스팟에서 속도가 12Mbps에서 90Mbps로 회복된다면 클라이언트와 노드가 더 높은 전송량을 제공할 수 있다는 뜻입니다. 문제는 가정용 회선에서 노드 진입점까지의 경로에 있을 가능성이 높습니다.

단일 저지연 수치보다 지연 시간 변동이 더 중요하다

연속 테스트 결과가 58ms, 61ms, 64ms라면 28ms, 190ms, 타임아웃이 번갈아 나타나는 경우보다 대체로 안정적입니다. 후자의 경우 더 낮은 수치가 한 번 나왔더라도 지터와 패킷 손실로 TCP 재전송이 발생해 다운로드 속도가 떨어집니다. 동영상, 원격 데스크톱, 게임은 지터에도 더 민감합니다.

Windows에서는 먼저 PowerShell로 노드 진입점 포트에 TCP 연결을 설정할 수 있는지 확인합니다. 예시의 호스트와 포트를 구독 노드가 실제로 사용하는 값으로 바꾸세요:

Test-NetConnection example.com -Port 443
ping example.com -n 20

macOS 또는 Linux에서는 연속적으로 지연 시간을 관찰할 수 있습니다:

ping -c 20 example.com
curl -x http://127.0.0.1:7890 -o /dev/null -s -w "connect=%{time_connect} total=%{time_total}\n" https://www.gstatic.com/generate_204

예시의 7890은 일반적인 혼합 포트일 뿐 고정값이 아닙니다. 실제 포트는 클라이언트의 ‘설정’ → ‘포트 설정’ 또는 설정 파일의 mixed-port 필드에서 확인해야 합니다. 명령이 연결 거부를 반환하면 원격 노드가 고장 났다고 단정하기 전에 mihomo 실행 여부와 포트 일치 여부를 먼저 확인하세요.

3단계: 로컬 설정에서 DNS·규칙 적용·프록시 충돌 확인

여러 노드의 성능이 비슷하고 네트워크를 바꿔도 문제가 계속된다면 로컬 설정을 다시 살펴봐야 합니다. 흔한 증상으로는 웹페이지 첫 로딩 지연, 특정 앱이 프록시를 사용하지 않음, 규칙 모드만 느리고 전역 모드는 정상, TUN을 켠 뒤 속도가 급격히 저하됨 등이 있습니다. 로컬 계층은 ‘연결이 커널에 들어오는지, 규칙이 올바른 정책을 선택하는지, DNS가 원활한지’ 순서로 확인하세요.

노드 이름만 보지 말고 연결 로그부터 확인하기

클라이언트의 연결 또는 로그 페이지를 열고 문제가 발생한 웹사이트에 다시 접속합니다. 일반적인 클라이언트에서는 ‘로그’ 또는 ‘연결’ 페이지에서 대상 도메인, 적용된 규칙, 최종 정책을 확인할 수 있습니다. 다음 세 가지를 확인하세요. 도메인이 mihomo에 포착됐는지, 어떤 규칙이 적용됐는지, 최종적으로 어떤 정책 그룹과 노드를 사용했는지입니다.

• 연결 기록에 대상 앱의 트래픽이 전혀 없다면 시스템 프록시 또는 TUN 적용 범위를 확인합니다.
• 대상 도메인에 DIRECT가 적용됐지만 프록시를 사용해야 한다면 규칙 순서와 규칙 세트 업데이트 상태를 확인합니다.
• 잘못된 지역의 정책 그룹이 적용됐다면 ‘프록시’ 페이지로 돌아가 그룹 내 현재 선택 항목을 확인합니다.
• 로그에 DNS 타임아웃이 계속 나타나면 먼저 DNS 해석 경로를 처리합니다.
• 동일한 요청이 반복해서 연결된다면 시스템에 다른 프록시 프로그램이 실행 중인지 확인합니다.

Clash 규칙은 위에서 아래로 매칭되며 먼저 일치한 규칙이 적용됩니다. 지나치게 포괄적인 규칙을 앞에 두면 뒤의 정밀한 도메인 규칙이 무효화될 수 있습니다. 예를 들어 GEOIP,CN,DIRECT는 일반적으로 도메인 규칙 뒤, 최종 MATCH 앞에 배치해야 합니다. 수정할 때는 한 번에 한 종류의 규칙만 이동하고, 다시 불러온 뒤 연결 로그에서 결과를 확인하세요.

rules:
  - DOMAIN-SUFFIX,example.net,프록시 노드
  - DOMAIN-KEYWORD,stream,미디어 정책
  - GEOIP,CN,DIRECT
  - MATCH,프록시 노드

전역 모드로 짧게 비교하기

규칙 모드가 매우 느릴 때는 같은 노드로 같은 대상에 접속하면서 잠시 전역 모드로 전환해 볼 수 있습니다. 전역 모드에서 즉시 회복되고 규칙 모드만 계속 느리다면 문제는 대개 노드 대역폭이 아니라 규칙 적용, DNS 분할 라우팅 또는 일부 리소스가 다른 경로를 사용하는 데 있습니다. 테스트가 끝나면 규칙 모드로 되돌리고 로그를 바탕으로 규칙을 수정하세요. 설정 문제를 가리기 위해 전역 모드를 장기간 사용하는 것은 권장하지 않습니다.

DNS가 느리면 ‘처음에는 멈췄다가 이후에는 빠른’ 증상이 나타난다

도메인 해석 타임아웃은 첫 요청을 지연시킵니다. 특히 여러 nameserver의 품질 차이가 크거나, IPv6 해석은 되지만 연결할 수 없거나, 시스템 DNS와 mihomo DNS 경로를 함께 사용할 때 브라우저가 실패한 연결의 재시도를 기다릴 수 있습니다. 설정에서 DNS 처리를 통일하고 클라이언트가 설정을 정상적으로 불러왔는지 확인하세요.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

ipv6: false는 IPv6 폴백 때문에 대기하는지 확인할 때 유용하지만 모든 네트워크에서 IPv6을 영구적으로 꺼야 한다는 뜻은 아닙니다. 로컬 네트워크와 프록시 경로가 모두 IPv6을 완전히 지원한다면 다시 활성화한 뒤 테스트하세요. fake-ip은 도메인 트래픽을 더 일찍 규칙 판단에 넣을 수 있지만, 로컬 네트워크 장치·일부 게임·실제 주소에 의존하는 서비스에는 fake-ip-filter 예외가 필요할 수 있습니다.

시스템 프록시와 브라우저 프록시가 중첩되지 않았는지 확인

데스크톱 환경에서 흔한 충돌은 클라이언트가 이미 시스템 프록시를 설정했는데 브라우저 확장 프로그램이 트래픽을 다른 포트로 전달하는 경우입니다. 또는 이전 클라이언트를 종료한 뒤에도 시스템 프록시 주소가 남아 있을 수 있습니다. 이때 요청이 두 번 우회되거나 로컬에서 실패 재시도가 발생할 수 있습니다.

1. 클라이언트의 ‘설정’ → ‘시스템 프록시’로 이동해 현재 스위치 상태를 확인합니다.
2. ‘설정’ → ‘포트 설정’으로 이동해 HTTP, SOCKS 또는 mixed 포트를 기록합니다.
3. 브라우저 프록시 확장 프로그램을 확인하고 일시적으로 시스템 프록시를 따르도록 설정합니다.
4. 운영체제 네트워크 프록시를 확인하고 주소가 보통 127.0.0.1인지, 포트가 클라이언트와 일치하는지 확인합니다.
5. 다른 프록시 클라이언트를 완전히 종료한 뒤 첫 로딩과 지속 다운로드를 다시 테스트합니다.

설정이 mixed-port: 7890을 사용한다면 HTTP와 SOCKS 클라이언트 모두 해당 포트에 연결할 수 있습니다. 같은 브라우저 요청을 SOCKS 확장 프로그램에 먼저 전달한 뒤 다시 시스템 HTTP 프록시로 보내지 마세요. 브라우저 프록시만 필요한 경우 시스템 프록시가 이미 적용됐다면 확장 프로그램은 보통 직접 연결 또는 시스템 설정 따르기로 두면 됩니다.

TUN 모드 집중 점검: 앱 적용 범위·MTU·UDP

TUN 모드는 가상 네트워크 어댑터를 통해 시스템 프록시를 따르지 않는 앱 트래픽을 가로챕니다. 게임 클라이언트, 명령줄 도구, 일부 스토어 앱에 적합하지만 라우팅, DNS 하이재킹, 패킷 처리 단계가 추가됩니다. ‘TUN을 끄면 정상이고 켜면 느려지는’ 경우에는 모든 구독 노드를 먼저 바꾸기보다 TUN 설정을 확인해야 합니다.

TUN 경로만 영향을 받는지 먼저 확인

1. 노드 하나를 고정하고 시스템 프록시를 켠 상태에서 TUN을 끈 채 브라우저를 테스트합니다.
2. 노드는 그대로 둔 채 TUN을 켜고 같은 주소를 테스트합니다.
3. 연결 페이지에서 두 테스트가 동일한 규칙과 동일한 노드에 적용됐는지 확인합니다.
4. TUN을 켠 뒤에만 속도가 떨어진다면 가상 네트워크 어댑터 충돌, MTU, 네트워크 스택을 확인합니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed는 mihomo에서 흔히 사용하는 호환 설정입니다. 기기에서 VPN, 가상 머신, 컨테이너 네트워크 또는 게임 가속 도구를 함께 실행하면 자동 라우팅이 잘못된 네트워크 어댑터를 출구로 선택할 수 있습니다. 이때는 가상 네트워크 어댑터를 만드는 다른 프로그램을 먼저 종료하고 클라이언트를 재시작해 테스트하세요. stack, MTU, DNS 하이재킹을 동시에 수정하면 구체적인 원인을 찾기 어렵습니다.

MTU가 맞지 않을 때 나타나는 대표 증상

MTU 문제는 작은 웹페이지는 열리지만 대용량 파일에서 멈추거나 특정 사이트 업로드가 실패하게 만들 수 있습니다. 먼저 보수적인 값부터 비교하세요. 예를 들어 TUN 설정에서 mtu: 1400을 테스트하고 효과가 확인되면 조금씩 조정합니다. 적절한 값은 운영체제, 광대역 접속 방식, 상위 터널에 따라 다르므로 1400은 점검 시작점일 뿐입니다.

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  auto-detect-interface: true

MTU를 변경한 뒤 대용량 파일 다운로드가 뚜렷하게 회복되고 노드와 규칙은 바뀌지 않았다면, 조각화 또는 경로 MTU 탐지가 문제에 관여했을 가능성이 있습니다. 개선되지 않으면 원래 설정으로 되돌리고 DNS와 경로를 계속 확인하세요. 값을 계속 낮추는 것은 권장하지 않습니다.

구독 및 커널 상태: 오래된 설정과 버전 불일치 배제

구독 업데이트에 실패해도 모든 노드가 반드시 오프라인이 되는 것은 아닙니다. 클라이언트가 캐시된 설정을 계속 사용하면서 노드 진입점, 규칙 세트 또는 DNS 매개변수가 오랫동안 갱신되지 않을 수 있습니다. 점검할 때는 ‘구독 업데이트 시간’과 ‘현재 실행 중인 설정’이 같은 내용인지 확인하세요. 구독을 업데이트한 뒤에는 적용 또는 다시 불러오기도 실행해야 합니다. 다운로드가 완료된 것만 보고 커널이 전환됐다고 판단해서는 안 됩니다.

구독 업데이트 시간과 설정 로드 결과 확인

• ‘구독’ 또는 ‘설정’ 페이지에서 마지막 업데이트 시간을 확인해 몇 주 전 캐시가 아닌지 확인합니다.
• 수동 업데이트 후 HTTP 타임아웃, 인증 실패 또는 빈 콘텐츠가 나타나는지 확인합니다.
• 업데이트가 완료되면 해당 설정을 선택하고 다시 불러옵니다.
• 로그 페이지에서 설정 해석이 성공했고 정책 그룹과 규칙 세트가 생성됐는지 확인합니다.
• 구독에 오버라이드 기능이 포함되어 있다면 로컬 오버라이드가 현재 필드와 여전히 호환되는지 확인합니다.

구버전 Clash 설정을 mihomo로 이전할 때 기본 프록시, 정책 그룹, 규칙 구조는 대체로 사용할 수 있지만 일부 확장 필드, TUN 매개변수, 규칙 세트 동작은 버전에 따라 달라질 수 있습니다. 설정 로드 오류가 발생하면 구독 전체를 삭제하기보다 로그를 보고 먼저 문제가 된 필드를 찾으세요. 커널 버전은 클라이언트의 ‘설정’ → ‘커널’ 또는 ‘정보’ 페이지에서 확인할 수 있습니다. 클라이언트마다 메뉴 이름은 조금씩 다를 수 있습니다.

10분 문제 해결 절차와 결과 판단

문제가 발생한 순간에는 아래 순서대로 범위를 빠르게 좁힐 수 있습니다. 핵심은 매 라운드마다 변수 하나만 바꾸고 변경 전후 결과를 기록하는 것입니다.

1. 1분: 백그라운드 다운로드를 중지하고 직접 연결 모드로 로컬 기준 속도를 한 번 측정합니다.
2. 2~3분: 규칙 모드로 되돌리고 테스트 노드를 고정한 뒤 지연 시간, 첫 로딩 시간, 60초 다운로드 속도를 기록합니다.
3. 4분: 같은 지역의 다른 노드로 전환합니다. 기존 노드만 느리다면 노드 측 문제로 분류합니다.
4. 5분: 다른 지역 노드로 전환합니다. 모든 프록시 노드가 느리지만 직접 연결은 정상이라면 경로 또는 로컬 설정을 계속 확인합니다.
5. 6분: 휴대폰 핫스팟으로 같은 노드를 다시 테스트합니다. 핫스팟에서 회복되면 가정용 인터넷 경로를 우선 의심합니다.
6. 7분: 연결 로그를 확인해 규칙, 정책 그룹, 대상 노드를 대조합니다.
7. 8분: 잠시 전역 모드로 전환합니다. 전역 모드에서 회복되면 규칙과 DNS를 중점적으로 확인합니다.
8. 9분: 브라우저 프록시 확장 프로그램과 다른 프록시 클라이언트를 종료해 로컬 중첩을 제거합니다.
9. 10분: TUN을 켜고 끈 상태를 비교합니다. TUN에서만 느리다면 가상 네트워크 어댑터, MTU, DNS 하이재킹을 추가로 확인합니다.

문제 해결 기록에 남겨야 할 데이터

구독 서비스 제공업체, 네트워크 관리자 또는 클라이언트 프로젝트에 문제를 전달할 때 ‘속도가 느리다’만으로는 재현하기 어렵습니다. 비교 가능한 데이터를 제공하되 구독 주소, 노드 비밀번호, 전체 설정은 공개하지 마세요. 테스트 날짜와 시간대, 접속 네트워크, 클라이언트 버전, mihomo 커널 버전, 노드 지역, 실행 모드, 테스트 결과를 기록하는 것이 좋습니다.

테스트 시간: 2026-06-20 21:30
접속 네트워크: 가정용 인터넷, 유선 연결
실행 모드: 규칙 모드, TUN 켜짐
로컬 직접 연결: 286Mbps
노드 A: 지연 시간 72ms, 지속 다운로드 18Mbps
노드 B: 지연 시간 81ms, 지속 다운로드 96Mbps
휴대폰 핫스팟 + 노드 A: 74Mbps
적용 규칙: MATCH → 프록시 노드
증상: 저녁에 속도 저하, 낮에는 회복

이 기록만으로도 판단을 뒷받침할 수 있습니다. 가정용 인터넷의 저녁 경로에서 노드 A의 성능이 낮았고, 노드 B와 휴대폰 핫스팟 비교 결과는 클라이언트의 기본 설정이 완전히 고장 난 것은 아님을 보여줍니다. 설정을 반복해서 초기화하는 것보다 이런 계층별 근거가 실제로 교체하거나 조정해야 할 구간을 찾는 데 더 효과적입니다.