용도에 맞는 노드를 먼저 추린 뒤 지연 시간을 비교하세요
Clash에 구독을 추가하면 노드 목록에 지역, 배율, 회선 이름, 프로토콜이 한꺼번에 표시되는 경우가 많습니다. 모든 노드를 최대 속도로 테스트할 필요는 없습니다. 먼저 필요한 웹사이트의 접속 지역을 확인하고, 트래픽 비용이 맞지 않는 노드를 제외한 다음 연결 가능 여부와 안정성을 비교하면 불필요한 테스트를 줄일 수 있습니다.
이 글에서 ‘프록시 서비스’는 프록시 구독을 제공하는 업체를 뜻합니다. 노드 이름은 업체가 지정하며, 클라이언트가 인증한 회선 정보가 아닙니다. ‘전용 회선’, ‘고속’, ‘네이티브’ 같은 표기는 후보를 추리는 참고 정보일 뿐입니다. 실제 연결 상태와 출구 IP, 업체 안내를 확인하세요.
- 웹 검색과 자료 조사: 요청이 꾸준히 안정적이고 페이지가 빨리 열리는 노드를 우선하세요. 최고 다운로드 속도까지 추구할 필요는 없습니다.
- 동영상 시청과 대용량 파일 전송: 배율과 잔여 데이터부터 확인한 뒤 지속 전송 속도를 살펴보세요. 수십 ms 차이는 대개 핵심 요소가 아닙니다.
- 원격 데스크톱과 음성 통화: 지연 시간의 변동, 연결 끊김, UDP 지원 여부를 확인하세요. 앱의 트래픽이 프록시를 통과하는지도 따로 확인해야 합니다.
- 지역 제한이 있는 서비스: 먼저 대상 서비스가 인식하는 출구 지역과 계정 조건을 확인하고, 지연 시간 순위는 나중에 고려하세요.
Clash의 지연 시간 테스트는 무엇을 측정할까요?
Clash 및 mihomo 클라이언트의 지연 시간 테스트는 보통 지정한 프록시를 통해 테스트 URL에 HTTP 또는 HTTPS 요청을 보내고 응답 시간을 기록합니다. 노드 서버에 ICMP Ping을 보내는 단순 테스트도, 다운로드 대역폭 측정도 아닙니다. 테스트 URL, 연결 재사용 방식, 코어 버전, 클라이언트 설정에 따라 결과가 달라질 수 있어 직접 비교하기 어려울 수 있습니다.
지연 시간이 짧다고 다운로드가 빠른 것은 아닙니다
연결 설정, TLS 핸드셰이크, 응답 대기 시간이 측정값에 영향을 줄 수 있습니다. 작은 요청이 빨리 끝나더라도 혼잡 시간대에 충분한 대역폭을 제공한다는 뜻은 아닙니다. 반대로 거리가 먼 회선은 지연 시간이 길어도 지속 다운로드가 더 안정적일 수 있습니다.
예를 들어 후보 A가 45ms, 후보 B가 95ms로 표시되어도 이번 테스트 조건에서 응답 시간이 달랐다는 의미일 뿐입니다. A의 다운로드 속도가 B의 두 배라고 볼 수 없으며, 특정 동영상 사이트가 A에서 반드시 정상 재생된다고 단정할 수도 없습니다.
같은 조건으로 세 차례 비교하세요
- 시스템 업데이트, 클라우드 드라이브 동기화, 다른 다운로드를 일시 중지하고 같은 Wi-Fi 또는 유선 네트워크를 유지하세요.
- 클라이언트의 ‘프록시’ 페이지에서 비교할 정책 그룹을 찾고 그룹 안의 지연 시간 테스트 버튼을 사용하세요. 클라이언트에 따라 이 페이지가 ‘프록시 그룹’으로 표시될 수 있습니다.
- 후보 노드를 세 차례 연속 테스트하고 각 테스트 사이에 약 10초 간격을 두세요. 최저값만 캡처하지 말고 시간 초과 횟수와 측정값 범위를 기록하세요.
- 후보 노드로 전환한 뒤 대상 웹사이트를 실제로 열어 첫 화면 로딩, 로그인, 연속 작업이 정상인지 확인하세요.
예를 들어 세 차례 측정값이 62, 65, 63ms인 노드와 40, 260ms, 시간 초과로 나온 노드가 있다면 첫 번째 노드가 상호작용 작업에 더 적합한 경우가 많습니다. 이는 측정값 예시이며, 이 사이트가 특정 회선을 실제 측정해 보장하는 수치가 아닙니다. unified-delay 등 지연 시간 계산에 영향을 주는 옵션이 켜져 있다면 같은 설정을 유지한 상태에서 비교하세요.
트래픽 배율 계산: 0.5배, 1배, 2배
배율은 보통 서비스 업체의 과금 계수이며 속도 배수가 아닙니다. 2배 노드라고 해서 대역폭이 1배 노드의 두 배라는 뜻은 아니며, 0.5배라고 연결 속도가 절반으로 줄어드는 것도 아닙니다. 업로드와 다운로드 중 어느 쪽을 기준으로 하는지, 또는 둘을 합산하는지는 업체의 트래픽 안내를 확인하세요.
| 노드 배율 | 과금 기준 트래픽이 10GB일 때 | 선택할 때 확인할 점 |
|---|---|---|
| 0.5배 | 약 5GB 차감 | 일상적인 사용에 필요한 전송량을 충족하는지 먼저 확인하기 좋습니다 |
| 1배 | 약 10GB 차감 | 비용 비교의 기준으로 사용 |
| 2배 | 약 20GB 차감 | 특정 지역이나 회선 품질이 추가 사용량만큼 가치가 있는지 확인 |
위 표는 서비스 업체의 과금 기준 트래픽을 10GB로 통일해 배율 계산만 보여 줍니다. 실제로 10GB 파일을 다운로드하면 업로드 트래픽, 프로토콜 오버헤드, 재시도 트래픽이 추가될 수 있고, 관리 페이지의 통계 반영도 늦을 수 있습니다. 클라이언트와 계정 페이지의 사용량이 즉시 바이트 단위까지 일치한다고 기대하지 마세요.
속도 테스트에도 트래픽이 사용됩니다
십진 단위 기준으로 100Mbps 속도로 60초간 다운로드하면 데이터 사용량은 약 750MB입니다. 전부 2배 과금 대상이라면 약 1.5GB가 차감됩니다. 수십 개 노드의 대역폭 테스트를 한꺼번에 실행하면 지연 시간 테스트를 몇 차례 하는 것보다 트래픽을 더 많이 사용합니다.
- 지연 시간과 실제 웹페이지 테스트로 후보를 두세 개로 좁힌 뒤 짧게 전송 속도를 측정하세요.
- 배율을 확인해야 한다면 다른 기기의 트래픽을 멈추고 관리 페이지의 잔여량을 기록한 다음, 통제된 다운로드를 한 번 진행하세요. 통계가 갱신된 뒤 사용량을 비교하면 됩니다.
- 구독을 새로고침한 뒤 노드 이름과 업체 안내를 다시 확인하세요. 배율이 항상 고정되어 있는 것은 아닙니다.
노드 지역 선택: 진입점, 출구, 대상 서비스
노드 이름에 표시된 ‘홍콩’, ‘일본’, ‘미국’은 대개 출구 지역을 가리키지만, 클라이언트가 처음 연결하는 진입점은 다른 지역에 있을 수 있습니다. 중계 회선은 가까운 진입점에 먼저 접속한 뒤 다른 경로를 거쳐 해외 출구에 도달하기도 합니다. 따라서 지리적 거리는 1차 판단 기준일 뿐, 실제 테스트를 대신할 수 없습니다.
일반적인 웹 검색은 네트워크 경로부터 확인하세요
중국 본토 사용자는 홍콩, 일본, 싱가포르 등을 우선 후보로 삼을 수 있지만, 통신사와 거주 도시, 접속 시간대에 따라 결과가 달라집니다. 오후 9시의 상태는 오전 10시와 다를 수 있습니다. 평소 사용하는 시간대에 한 번 더 테스트하고, 낮에 한 번 측정한 결과를 장기적인 기준으로 삼지 마세요.
지역 제한 서비스는 라벨보다 출구 지역 인식을 확인하세요
같은 출구 IP도 데이터베이스에 따라 서로 다른 지역으로 분류될 수 있습니다. 대상 서비스는 계정 지역, 결제 수단, 기기 위치, 로그인 기록을 함께 확인해 이용 권한을 판단하기도 합니다. 노드에 특정 지역이 표시되어도 그 지역의 모든 콘텐츠에 접근할 수 있다는 뜻은 아닙니다.
- 대상 서비스를 직접 열어 확인하고 IP 조회 페이지 결과만으로 결론 내리지 마세요.
- 해당 서비스의 규칙이 실제로 선택한 정책 그룹을 통과하는지 확인하세요. 조회 페이지는 프록시를 사용하지만 대상 앱은 직접 연결하는 상황을 피해야 합니다.
- 로그인이나 결제 시에는 가능한 한 출구를 안정적으로 유지하세요. 여러 지역을 자주 오가면 추가 인증이 요구될 수 있습니다.
- 예비 회선이 필요하다면 번호가 가까운 노드보다 진입점과 출구 자원이 다른 노드를 우선 고려하세요.
Trojan, VMess, Hysteria2 비교와 선택 기준
프로토콜은 클라이언트와 프록시 서버의 통신 방식을 정합니다. 회선 품질은 진입점 혼잡도, 국제망 경로, 서버 부하, 출구 대역폭에도 좌우됩니다. 특정 프로토콜을 곧바로 ‘가장 빠른 방식’으로 볼 수는 없습니다. 프로토콜을 비교하기 전에 현재 클라이언트 코어가 구독 설정의 필드를 지원하는지 확인하세요.
| 프로토콜 | 연결 방식 | 사용 전 확인 사항 |
|---|---|---|
| Trojan | 일반적으로 TCP와 TLS를 사용해 프록시 데이터를 전송합니다 | 서버 이름, 인증서 검증, 전송 설정이 서로 맞는지 확인하세요. UDP 포워딩 지원 여부도 별도로 확인해야 합니다. |
| VMess | 여러 전송 방식 조합을 지원하며 구독 설정에 WebSocket, TLS 등이 포함될 수 있습니다 | UUID, 전송 경로, Host, TLS 설정이 모두 있는지, 시스템 시간이 정확한지 확인하세요. |
| Hysteria2 | QUIC 기반이며 UDP를 사용합니다 | 로컬 네트워크에서 UDP를 허용하는지, 코어가 지원하는지, 서버 포트와 매개변수가 올바른지 확인하세요. |
UDP가 제한되어 있다면 Hysteria2 노드만 계속 바꿔 보지 마세요
일부 사무실 네트워크, 게스트 Wi-Fi, 통신사 경로는 UDP를 제한합니다. 같은 네트워크에서 여러 Hysteria2 노드가 모두 실패하고 TCP 기반 노드는 작동한다면 휴대폰 핫스팟에 연결해 비교 테스트하는 것이 좋습니다. Hysteria2는 일부 불안정한 네트워크에서 더 나은 성능을 보일 수 있지만, 모든 패킷 손실이나 속도 제한 환경에서 우세하다고 보장할 수는 없습니다.
포트 번호가 같아도 전송 방식은 다를 수 있습니다
Trojan은 TCP 443, Hysteria2는 UDP 443에서 구성할 수 있으며 구체적인 포트는 서버 설정에 따라 달라집니다. TCP 443을 허용한다고 UDP 443까지 허용되는 것은 아닙니다. 브라우저에서 HTTPS 웹사이트가 열린다고 해서 Hysteria2에 필요한 UDP 경로도 정상이라고 단정할 수 없습니다.
Hysteria2를 사용하려면 현재 해당 프로토콜을 지원하는 mihomo처럼 호환되는 코어가 필요합니다. 클라이언트 이름에 Clash가 들어간다고 구버전 코어도 설정을 읽을 수 있다고 가정하지 마세요. 가져온 뒤 ‘지원하지 않는 프록시 유형’이 표시되면 먼저 클라이언트의 ‘정보’ 페이지에서 코어 정보를 확인하세요. 그다음 호환되는 클라이언트를 업데이트하거나 업체에 호환 설정을 요청하세요. 노드 유형 이름만 바꾸는 것으로 해결하려 하지 마세요.
후보 노드를 정책 그룹에 넣고 규칙이 적용되는지 확인하세요
노드를 선택해도 앱의 연결이 해당 노드를 통과하지 않을 수 있습니다. Clash 규칙 모드는 규칙에 지정된 정책 그룹으로 연결을 전달합니다. ‘수동 선택’ 그룹을 바꿔도 다른 모든 그룹이 함께 바뀌는 것은 아닙니다. 문제를 확인할 때는 속도 테스트 결과보다 연결 기록의 규칙과 경로를 먼저 살펴보세요.
- 클라이언트에서 ‘규칙’ 모드를 선택하고 ‘프록시’ 페이지에서 대상 규칙에 지정된 정책 그룹을 확인하세요.
- 해당 정책 그룹을 후보 노드로 전환하세요. 그룹 안에 중첩된 정책 그룹이 있다면 그다음 단계의 선택도 확인해야 합니다.
- 대상 웹페이지의 기존 연결을 닫고 다시 로드하세요. 필요하면 연결 페이지에서 관련 연결을 종료해 이전 경로를 사용하는 세션이 남지 않도록 합니다.
- ‘연결’ 페이지에서 대상 도메인, 적용된 규칙, 프록시 체인을 확인해 실제 출구가 예상한 대로인지 살펴보세요.
수동 선택, 자동 속도 테스트, 장애 조치의 차이
select: 후보를 직접 선택하는 방식으로, 출구를 고정하거나 노드를 하나씩 비교 테스트할 때 적합합니다.url-test: 설정된 테스트 URL과 정책에 따라 노드를 선택합니다. 보통 측정 지연 시간이 짧은 노드를 우선하며, 트래픽 배율이나 콘텐츠 지역 권한은 평가하지 않습니다.fallback: 후보 순서와 상태 점검 결과에 따라 사용할 수 있는 항목을 찾습니다. 정해 둔 우선순위에 따라 예비 회선을 준비할 때 적합합니다.
자동 속도 테스트 그룹은 지연 시간이 짧지만 배율이 높은 노드를 선택하거나 지역 요건에 맞지 않는 출구로 전환할 수 있습니다. 같은 용도에 쓰고 허용 가능한 배율과 지역 범위가 비슷한 노드끼리 묶으면 모든 노드를 한 그룹에 넣는 것보다 관리하기 쉽습니다.
평소 노드 선택을 위한 5단계 점검 목록
- 용도 정하기: 웹 검색, 지속적인 다운로드, 특정 지역 서비스 중 무엇을 위한 노드인지 정하고 요구에 맞지 않는 후보를 먼저 제외하세요.
- 비용 계산하기: 배율, 잔여 데이터, 과금 기준을 확인하세요. 대역폭 테스트 점수로 트래픽 예산을 대신하지 마세요.
- 안정성 확인하기: 같은 조건에서 지연 시간을 세 차례 측정하고 평소 사용하는 시간대에도 확인해 시간 초과와 변동을 기록하세요.
- 서비스 직접 테스트하기: 실제로 로그인하고 재생하거나 다운로드해 규칙 적용과 출구 지역을 확인하세요. 목록에 표시된 초록색 수치만 보지 마세요.
- 예비 노드 준비하기: 다른 회선의 후보를 남겨 두세요. 문제가 생기면 먼저 바꿔 연결해 비교한 뒤 로컬 네트워크, 구독 설정, 서버 장애 중 무엇이 원인인지 구분하세요.
최종 선택을 영구적인 순위표로 만들 필요는 없습니다. 일상적인 사용에는 응답이 안정적이고 배율이 부담스럽지 않으며 출구가 필요한 조건에 맞는 주 노드 하나와 검증된 예비 노드 하나가 매일 최저 지연 시간을 찾아다니는 것보다 실용적입니다. 네트워크를 바꾸거나 구독을 새로고침한 뒤, 또는 혼잡 시간대에 문제가 생기면 이 다섯 단계를 빠르게 다시 확인하세요.