사용 목적을 먼저 정하고 네 가지 지표를 비교하세요
구독 목록에서 후보 노드를 두세 개 고르세요. 지연 시간 목록의 1위 노드를 곧바로 기본값으로 고정하지 않는 것이 좋습니다. 웹 서핑, 대용량 다운로드, 지역 제한 서비스, 원격 연결은 각각 필요한 네트워크 조건이 다릅니다. 속도 측정 사이트가 빨리 열린다고 해서 모든 사이트에서도 같은 성능을 보장하는 것은 아닙니다.
Clash 클라이언트는 설정을 표시하고 정책을 전환하며, Clash 또는 Clash Meta(mihomo) 코어는 프록시 연결을 설정하고 규칙을 적용합니다. 구독에 표시된 노드 이름, 배수, 지역 정보는 서비스 제공자가 입력한 것입니다. 코어가 이런 정보의 정확성을 자동으로 검증하거나, 구독 잔액에 맞춰 가장 저렴한 경로를 골라 주지는 않습니다.
| 지표 | 확인할 항목 | 흔히 착각하는 점 |
|---|---|---|
| 지연 시간 | 연속 측정 결과, 실패 횟수, 실제 서비스 응답 | 한 번 기록된 최저값이 하루 종일 안정적이라는 뜻은 아닙니다 |
| 배수 | 서비스 제공자의 과금 규칙과 잔여 트래픽 | 배수가 높다고 속도가 빠른 것은 아닙니다 |
| 지역 | 실제 출구 IP와 대상 서비스의 지역 판별 결과 | 노드 이름이 실제 출구 지역과 다를 수 있습니다 |
| 프로토콜 | 코어 지원 여부, 네트워크 제한, 서버 구현 | 프로토콜 이름만으로 성능을 순위 매길 수 없습니다 |
지연 시간 읽는 법: 최저 밀리초보다 변동 폭을 살펴보세요
클라이언트 속도 측정은 다운로드 대역폭 테스트가 아닙니다
일반적인 노드 지연 시간 테스트는 프록시를 통해 지정한 URL에 접속해 요청이 완료될 때까지 걸린 시간을 측정합니다. 테스트 주소, 연결 재사용, DNS 캐시, 코어 구현, 클라이언트 표시 방식에 따라 결과가 달라질 수 있습니다. 서버에 ICMP ping을 직접 보내는 것과는 다르며, 화면에 표시된 80ms를 초당 다운로드 속도로 환산할 수도 없습니다.
노드를 비교할 때는 테스트 URL, 타임아웃 기준, 로컬 네트워크를 동일하게 유지하세요. 먼저 한 차례 측정한 뒤 약 30초 간격으로 다시 측정하고, 결과를 최소 다섯 번 기록합니다. 대용량 파일을 동시에 다운로드하지 마세요. 로컬 Wi-Fi 혼잡이나 업로드 대역폭 포화도 노드 속도가 들쭉날쭉한 것처럼 보이게 합니다.
- 중앙값을 확인하세요: 다섯 번 측정한 값을 정렬해 가운데 값을 고르면, 한 번의 이례적인 저속 결과에 현혹되지 않습니다.
- 변동 폭을 확인하세요: 70ms에서 900ms까지 튀는 노드보다 약 180ms를 꾸준히 유지하는 노드가 더 쾌적할 수 있습니다.
- 실패 횟수를 확인하세요: 시간 초과를 0ms로 취급하지 마세요. 실패로 기록하고 횟수를 따로 계산합니다.
- 시간대별로 확인하세요: 평일 낮과 현지 저녁 피크 시간대에 각각 측정하고, 조건을 동일하게 유지하세요.
막연한 ‘빠른 느낌’ 대신 측정 기록을 활용하세요
아래는 계산 방법을 설명하기 위한 예시이며, 이 사이트에서 실제 회선을 측정한 결과가 아닙니다. 노드 A의 측정값은 62, 65, 71, 680ms, 시간 초과이고, 노드 B는 165, 172, 178, 181, 190ms입니다. A는 성공한 측정값이 더 낮지만 한 번 시간 초과가 있었고 큰 폭의 지연도 한 번 나타났습니다. 웹 폼, 원격 데스크톱, 잦은 API 요청에는 B가 더 유력한 후보일 수 있습니다.
이어서 실제 사용 환경에서도 확인하세요. 자주 쓰는 페이지 세 곳을 열고 한 번 로그인하거나, 동영상을 10분간 연속 재생하거나, 원격 연결을 15분간 유지해 봅니다. 측정 URL에는 접속되는데 실제 서비스가 작동하지 않는다면 대상 사이트의 제한, 출구 IP 평판, 규칙 적용 경로 또는 지역 판별 문제가 원인일 수 있습니다. 이를 곧바로 ‘노드 지연 시간이 너무 높다’고 단정하지 마세요.
트래픽 배수 계산법: 먼저 요금제의 차감 규칙을 확인하세요
배수는 대개 서비스 제공자가 정한 과금 표시이며, Clash 코어의 표준 성능 지표가 아닙니다. 서비스 제공자가 실제 사용량에 배수를 곱해 요금제 잔여량에서 차감한다면, 과금 트래픽 1GB에 2배 노드를 사용했을 때 약 2GB가 차감되고, 0.5배 노드를 사용하면 약 0.5GB가 차감됩니다. 단, 서비스 제공자가 실제로 이 계산식을 사용하는 경우에 한합니다.
요금제 차감량 = 서비스 제공자가 집계한 과금 트래픽 × 노드 배수
과금 트래픽 10GB × 0.5배 = 차감량 5GB
과금 트래픽 10GB × 1배 = 차감량 10GB
과금 트래픽 10GB × 2배 = 차감량 20GB실제 차감량에는 업로드 트래픽, 프로토콜 오버헤드, 집계 갱신 주기, GB와 GiB의 단위 차이가 반영될 수 있습니다. 요금제 관리 페이지의 규칙과 기록을 기준으로 삼고, 클라이언트의 연결 통계를 청구 내역으로 간주하지 마세요. 노드 이름에 포함된 ‘표준’, ‘전용’, ‘고속’도 통일된 과금 기준이 아닙니다.
대용량 트래픽에는 낮은 배수가 유리하지만 안정성도 확인하세요
- 동영상, 시스템 업데이트, 클라우드 드라이브 다운로드: 낮은 배수의 회선을 먼저 테스트하고, 지속적인 전송 속도가 필요한 수준인지 확인하세요.
- 웹, 메시지, 코드 저장소: 트래픽이 적으므로 연결 성공률과 응답 지연 시간을 우선 고려할 수 있습니다.
- 특정 지역 서비스: 먼저 출구 지역 조건을 충족한 뒤 배수를 비교하세요. 트래픽을 아끼더라도 서비스를 이용할 수 없으면 의미가 없습니다.
2배 회선은 12MiB/s, 1배 회선은 8MiB/s라고 가정해 보겠습니다. 이는 속도와 요금제 잔여량 사이의 선택이지, 앞쪽 회선이 무조건 더 낫다는 뜻은 아닙니다. 백그라운드 다운로드라면 완료 시간이 길어도 더 경제적일 수 있고, 긴급 파일을 잠깐 받는 경우에는 높은 배수 회선을 단시간 사용할 수 있습니다. 속도 측정용 다운로드도 잔여량을 소모하므로, 수 GB짜리 테스트 파일을 반복해서 받을 필요는 없습니다.
노드 지역 선택법: 이름만 보지 말고 실제 출구를 확인하세요
노드 이름의 ‘홍콩’, ‘일본’, ‘미국’은 출구 위치를 나타낼 수도 있고 상품 분류에 불과할 수도 있습니다. 연결 진입점, 국경 간 전송 경로, 최종 출구가 서로 다른 곳에 있을 수 있습니다. 진입점이 가까워도 출구까지 가까운 것은 아니며, 진입점까지의 지연 시간이 낮다고 대상 서비스까지의 전체 경로가 짧다는 뜻도 아닙니다.
- 후보 노드를 직접 선택한 뒤 연결 패널에서 확인 사이트 요청이 해당 노드를 통과했는지 확인하세요. DIRECT나 다른 정책 그룹으로 연결된 것은 아닌지도 살펴봅니다.
- 해당 연결을 통해 공인 출구 IP를 조회하고, IP 주소와 지역 데이터베이스 결과, 네트워크 사업자 정보를 기록하세요.
- 실제 대상 서비스를 열어 콘텐츠, 지역 안내, 로그인 결과를 확인하세요. 데이터베이스의 지역 표시는 참고 정보일 뿐입니다.
- 연결을 다시 설정해 출구가 바뀌는지 살펴보세요. 동적 출구는 일상적인 웹 서핑에는 적합할 수 있지만, 계정에 새로운 지역에서 로그인했다는 확인 절차가 발생할 수 있습니다.
지역 제한 서비스는 IP 유형, 계정 등록 지역, 결제 정보, 기기 위치도 확인하는 경우가 많습니다. IP 데이터베이스에 ‘일본’으로 표시된다고 해서 모든 서비스가 일본 IP로 인식하거나 해당 출구에 이용 권한을 부여하는 것은 아닙니다. 클라이언트에서 지역을 바꾸는 것은 네트워크 출구 조건 중 일부만 변경합니다.
프로토콜 비교법: 먼저 코어와 네트워크 조건을 확인하세요
프로토콜은 연결 방식과 일부 전송 특성을 결정하지만, 노드 성능은 서버 부하, 진입점 대역폭, 라우팅, 혼잡 제어, 클라이언트 기기 성능에도 영향을 받습니다. 프로토콜 이름을 속도 등급처럼 보지 마세요. 같은 프로토콜을 쓰더라도 회선에 따라 체감 성능이 크게 다를 수 있으며, 이는 프로토콜 간 차이보다 클 수도 있습니다.
| 프로토콜 | 확인할 항목 | 선택 시 중점 사항 |
|---|---|---|
| Shadowsocks | 암호화 방식, 플러그인, 코어 지원 여부 | 설정이 일치하고 실제 회선이 안정적인지 |
| Trojan | TLS, 서버 이름, 인증서 설정 | 핸드셰이크 성공 여부와 인증서 검증 상태 |
| VLESS | 전송 방식, TLS 또는 REALITY 매개변수 | 해당 기능을 지원하는 코어 사용 |
| Hysteria2 | UDP 연결 가능 여부, 인증, TLS 매개변수 | 제한된 네트워크에서 연결을 설정할 수 있는지 |
| TUIC | UDP 연결 가능 여부, 서버·클라이언트 호환성 | 세션 안정성과 기기 리소스 사용량 |
Hysteria2와 TUIC은 QUIC 기반 전송을 사용하므로 하위 계층의 UDP에 의존합니다. UDP가 제한된 공용 Wi-Fi나 기업 네트워크에서는 연결에 실패할 수 있지만, 그렇다고 구독에 포함된 모든 노드에 문제가 있다는 뜻은 아닙니다. TCP 전송을 사용하는 후보 회선도 하나 남겨 두고 같은 네트워크에서 비교해 보세요.
VLESS, Hysteria2, TUIC 노드는 사용 중인 코어가 해당 프로토콜을 지원하는지 확인해야 합니다. 클라이언트 화면에 노드 이름이 표시된다고 해서 현재 코어가 모든 프로토콜 매개변수를 올바르게 불러온다는 뜻은 아닙니다. 코어 이름, 설정 로드 로그, 오류 메시지를 확인하세요. 구버전 Clash와 mihomo의 지원 기능을 같은 것으로 보면 안 됩니다. 업그레이드를 고려한다면 기존 설정을 백업한 뒤 클라이언트 선택 가이드를 참고하세요.
프로토콜 계층의 UDP 전송과 앱의 UDP 트래픽이 프록시를 통과하는지는 서로 다른 문제입니다. 예를 들어 게임 앱의 UDP 트래픽은 노드 기능, 규칙, 트래픽 처리 방식에도 좌우됩니다. TUN을 켜도 서버의 UDP 미지원, 출구 제한, 회선 혼잡이 자동으로 해결되지는 않습니다.
같은 절차로 노드를 검증해 잘못된 프록시 경로를 측정하지 마세요
1단계: 정책 그룹과 테스트 경로 고정하기
클라이언트의 노드 패널에서 관련 정책 그룹을 수동 선택으로 바꾸세요. url-test가 자동으로 노드를 고르는 상태라면 측정 도중 노드가 바뀔 수 있습니다. 연결 패널에서 대상 도메인, 적용 규칙, 프록시 체인을 확인해 요청이 실제 후보 노드를 통과하는지 확인하세요. 규칙 모드는 켜 둬도 되지만 테스트 도메인은 예상한 정책 그룹에 연결되어야 합니다.
시스템 프록시는 해당 설정을 읽는 앱에만 적용됩니다. 터미널 명령은 브라우저와 달리 프록시 설정을 따르지 않을 수 있으므로 로컬 HTTP 또는 mixed 포트를 명시할 수 있습니다. 아래 예시는 클라이언트가 127.0.0.1:7890에서 수신한다고 가정합니다. 현재 설정의 port 또는 mixed-port를 먼저 확인하고, 실제 포트가 다르면 명령도 맞게 수정하세요.
curl --proxy http://127.0.0.1:7890 \
--connect-timeout 10 \
--max-time 20 \
--output /dev/null \
--silent --show-error \
--write-out "HTTP=%{http_code} TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" \
https://www.example.com/일반적인 Unix 셸에서 사용할 수 있는 명령 예시이며, 주소에는 문서용 도메인을 사용했습니다. 실제 비교에서는 자주 이용하며 접속이 허용된 HTTPS 페이지로 바꾸세요. Windows PowerShell에서는 curl.exe를 사용해 명령을 한 줄로 입력하고, 출력 대상을 NUL로 바꿀 수 있습니다. 프록시를 명시하면 로컬 프록시 포트까지 요청을 보내는 것만 보장됩니다. 최종 출구는 여전히 코어 규칙에 따라 달라지므로 연결 패널도 함께 확인해야 합니다.
time_starttransfer는 요청 시작부터 첫 바이트를 받을 때까지 걸린 시간으로, 연결 설정 등의 단계가 포함됩니다. time_total은 요청 전체에 걸린 시간입니다. 클라이언트의 노드 측정값을 그대로 재현하는 값은 아니며, 실제 요청 경로를 검증하는 보조 지표입니다. HTTP 403 응답은 요청이 대상 사이트에 도달했지만 거부되었을 가능성을 뜻합니다. 200이 아닌 모든 응답을 프록시 연결 끊김으로 간주하지 마세요.
2단계: 전체 비교 결과 기록하기
- 기기, 네트워크, 테스트 주소를 동일하게 유지하고 다른 대용량 작업은 중단하세요.
- 노드별로 지연 시간 다섯 번, 실패 횟수, 배수, 실제 출구 지역을 기록하세요.
- 같은 서비스로 10~15분간 테스트하고 끊김, 재연결, 로그인 오류를 기록하세요.
- 저녁 피크 시간대에 한 번 더 반복하고, 안정적으로 통과한 노드를 남기세요. 한 번의 최고 기록으로 순위를 매기지 마세요.
후보 노드가 모두 실패하면 먼저 구독 잔액, 설정 활성화 상태, 로컬 수신 포트, 네트워크 연결을 확인한 뒤 DNS와 규칙을 살펴보세요. 브라우저만 실패하거나 터미널만 실패한다면 프록시 진입점부터 확인하세요. 자세한 내용은 문제 해결에서 확인할 수 있습니다. DNS, TUN, 규칙, 노드를 한꺼번에 바꾸면 어떤 변경으로 문제가 해결됐는지 파악하기 어렵습니다.
일상용·지역용·예비용 노드를 따로 준비하세요
테스트가 끝난 뒤 수십 개 회선을 즐겨찾기에 추가할 필요는 없습니다. 일상용 기본 노드는 피크 시간에도 안정적이고 배수가 적절한 것으로 고르세요. 지역별 서비스가 필요하다면 실제 서비스로 검증한 출구를 하나 남기고, 예비 노드는 다른 진입점이나 네트워크 경로를 사용하며 현재 네트워크에서도 독립적으로 작동하는지 확인하세요.
- 일상적인 웹 서핑: 안정적인 응답을 우선하고 배수는 적절한 수준으로 선택하세요. 수십 ms 차이 때문에 자주 전환하지 마세요.
- 동영상과 다운로드: 지속적인 전송 속도와 요금제 차감량을 우선 확인하세요. 짧은 요청의 측정 결과만 보지 마세요.
- 원격 업무: 장시간 연결의 안정성과 출구 지역 고정이 중요합니다. 중요한 작업을 시작하기 전에 현재 출구를 확인하세요.
- 제한된 네트워크용 예비 노드: 같은 회선에 이름만 다른 노드를 추가하는 대신, 검증된 다른 전송 방식을 준비하세요.
자동 전환이 필요하다면 url-test는 테스트 결과에 따라 노드를 선택하고, fallback은 대개 목록 순서대로 사용 가능한 노드를 찾습니다. 둘 다 테스트 URL에 접속할 수 있어야 작동하며 트래픽 배수, 계정의 지역 제한, 실제 서비스 로그인 상태는 고려하지 않습니다. load-balance는 설정된 정책에 따라 연결을 분산하지만, 단일 다운로드에서 모든 노드의 대역폭을 합산해 주지는 않습니다. 출구가 중요한 서비스에는 노드를 수동으로 고정하는 편이 제어하기 쉽습니다.
구독을 업데이트한 뒤 노드 이름, 배수, 정책 그룹 선택을 다시 확인하세요. 기존 노드가 삭제되거나 이름이 바뀌거나 출구가 이전됐을 수 있습니다. 최종적으로 남길 노드는 ‘지연 시간이 가장 낮은’ 단 하나의 승자가 아닙니다. 용도가 분명하고 비용을 계산할 수 있으며 경로를 검증할 수 있는 노드 조합이 중요합니다. 사용 경험이 달라졌을 때 같은 절차로 다시 확인해야 로컬 네트워크, 회선 부하, 대상 서비스 중 무엇이 영향을 줬는지 구분할 수 있습니다.