프록시 노드 선택법: 지연 시간 테스트·트래픽 배율·지역·전송 프로토콜 비교

먼저 연결 가능 여부를 확인하고 지연 시간과 비용 비교

노드를 고를 때는 목적 서비스 접속 가능 여부, 연결 안정성, 데이터 사용 요금 순으로 확인한 뒤 지연 시간이 가장 짧은 노드를 선택하세요. Clash 노드 목록의 밀리초 값은 특정 시점에 측정한 결과일 뿐, 다운로드 속도나 출구 지역, 서비스 이용 가능 여부까지 보여주지는 않습니다. 웹 브라우징, 동영상 재생, 원격 터미널은 각각 필요한 네트워크 조건도 다릅니다.

비교를 시작하기 전에 클라이언트에서 사용하는 코어를 확인하세요. 기본 Clash와 Clash Meta(현재 이름은 mihomo)는 지원하는 프로토콜이 다릅니다. 구독에 Hysteria2나 REALITY 매개변수가 포함된 VLESS 노드가 있다면 해당 프로토콜을 지원하는 코어가 필요합니다. 노드 가져오기에 실패했다면 회선 품질이 나쁘다고 단정하기 전에 호환성이나 설정 문제부터 확인하세요.

1. 사용 목적 정하기: 웹 브라우징은 첫 화면 로딩과 요청 응답을, 동영상은 지속적인 전송량을, SSH 같은 대화형 연결은 지연 시간 변동과 연결 끊김을 확인하세요.
2. 조건 통일하기: 같은 기기와 같은 Wi-Fi 또는 유선 네트워크에서 비교하고, 클라우드 동기화와 백그라운드 업데이트는 일시 중지하세요.
3. 라우팅 확인하기: 비교하려는 노드로 대상 요청이 실제 연결되는지 확인하세요. DIRECT 규칙으로 직접 연결되거나 다른 프록시 그룹이 선택된 상태일 수 있습니다.
4. 대안 마련하기: 주 노드 외에도 회선이나 서버가 다른 노드를 하나 더 준비하세요. 이름만 다른 노드가 실제로는 같은 장애 지점을 공유할 수 있습니다.

1. 지연 시간 테스트: 테스트 URL, 반복 결과, 실제 요청 확인

밀리초 값은 다운로드 속도도 ICMP ping도 아닙니다

mihomo의 URL 테스트는 지정한 프록시를 통해 테스트 주소에 접속해 HTTP 탐색에 걸린 시간을 측정합니다. 결과에는 클라이언트와 노드 사이의 경로, 프록시 핸드셰이크, 노드와 테스트 사이트 사이의 경로, 테스트 엔드포인트의 응답이 모두 영향을 줍니다. 새 연결인지 기존 연결을 재사용하는지에 따라서도 결과가 달라질 수 있으므로 노드 목록의 값을 순수한 네트워크 왕복 시간으로 보면 안 됩니다.

예를 들어 테스트 URL이 https://www.gstatic.com/generate_204라면 해당 노드에서 이 엔드포인트에 접속한 결과를 보여줍니다. 테스트에 성공해도 다른 웹사이트나 동영상 서비스, API에 정상 접속할 수 있다는 뜻은 아닙니다. 테스트 시간 초과도 노드가 완전히 오프라인이라는 의미는 아닙니다. 테스트 사이트가 차단되거나 도메인 조회에 문제가 있거나 일시적으로 혼잡해도 실패할 수 있습니다.

• 노드를 비교할 때는 테스트 URL을 동일하게 사용하고 시간 초과 조건도 통일하세요.
• 각 노드를 연속으로 5회 테스트해 성공 횟수, 일반적인 소요 시간, 최장 소요 시간을 기록하세요. 가장 짧은 결과만 보지 마세요.
• 평일 낮과 저녁에 각각 테스트하세요. 부하가 낮을 때만 잘 작동하는 노드는 저녁 동영상 시청에 적합하지 않을 수 있습니다.
• 화면에 timeout이 표시되면 먼저 해당 노드로 실제 목적지에 접속해 보세요. 탐색 엔드포인트 문제인지 회선 문제인지 구분할 수 있습니다.

예를 들어 한 노드의 5회 측정값이 80, 82, 85, 83, 900밀리초이고 다른 노드는 110, 112, 109, 115, 111밀리초라고 해보겠습니다. 첫 번째 노드는 최솟값이 더 낮지만 한 차례 큰 지연이 발생했습니다. 대화형 연결에 사용할 노드라면 80밀리초만 보고 바로 순위를 매기지 말고 이런 급격한 지연이 반복되는지 확인하세요.

curl로 같은 요청이 어느 로컬 포트를 거치는지 확인하기

아래 명령은 로컬 HTTP 프록시 127.0.0.1:7890에 명시적으로 연결합니다. 클라이언트가 실제로 해당 주소에서 HTTP 또는 mixed-port 서비스를 제공해야 합니다. 포트가 7890이 아니라면 현재 설정에 맞춰 바꾸세요. Rule 모드에서는 로컬 프록시를 명시해도 규칙이 적용되므로, 클라이언트 연결 목록에서 최종 출구 정책을 확인해야 합니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "status=%{http_code} first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

macOS와 Linux에서 사용하는 명령입니다. Windows에서는 curl.exe를 사용하고 /dev/null을 NUL로 바꾸면 나머지 매개변수는 동일합니다. 이 테스트 주소가 정상 응답하면 보통 HTTP 204를 반환합니다. time_starttransfer는 첫 바이트를 받기까지 걸린 전체 시간이고 time_total은 요청 전체에 걸린 시간입니다. 둘 다 별도의 ‘노드 ping’ 값은 아닙니다.

204 응답은 본문이 작아 요청 완료 여부를 확인하기 좋지만 전송량 측정에는 적합하지 않습니다. 다운로드 속도는 출처가 확실하고 크기가 알려져 있으며 테스트가 허용된 파일로 측정하세요. 파일과 테스트 시간도 동일하게 유지해야 합니다. 단위도 통일하세요. 1 MB/s는 약 8 Mbps이므로 두 단위의 숫자를 그대로 비교하면 안 됩니다.

2. 트래픽 배율: 차감량을 계산한 뒤 용도 결정

트래픽 배율은 서비스 제공업체의 요금 계산 방식이지 프로토콜 매개변수나 속도 배수가 아닙니다. 배율이 2배인 노드라고 해서 일반 노드보다 속도가 두 배 빠른 것은 아닙니다. 흔히 ‘과금 대상 트래픽 × 배율’로 계산하지만, 업로드도 과금되는지, GB와 GiB를 어떻게 정의하는지, 시간대별로 조정되는지는 서비스 제공업체의 안내를 확인하세요.

남은 데이터로 사용 가능한 트래픽 계산하기

남은 요금제 데이터가 60 GB이고 배율 2배인 노드를 사용한다고 가정해 보겠습니다. 설명한 과금 대상 트래픽만 차감하는 방식이라면 약 30 GB의 과금 대상 트래픽을 사용할 수 있습니다. 배율 0.5배 노드라면 약 120 GB에 해당합니다. 이 계산은 비용을 가늠하는 데 도움이 되지만 요금제 만료일이나 속도 제한, 기타 서비스 약관을 바꾸지는 않습니다.

• 웹과 메시지: 보통 응답 속도와 안정성이 더 중요하므로 신뢰할 수 있는 회선이라면 배율이 높은 노드도 고려할 수 있습니다.
• 동영상과 대용량 파일: 먼저 배율을 확인한 뒤 장시간 전송량을 테스트하세요. 속도 테스트도 데이터를 소모할 수 있습니다.
• 백그라운드 백업: 프록시를 거쳐야 하는지 확인하고, 규칙 때문에 대량 업로드가 모두 배율이 높은 회선을 통과하지 않도록 주의하세요.

3. 지역 선택: 노드 진입 지점, 출구 IP, 목적 서비스 구분하기

지역은 지도에서 가장 가까운 곳이 아니라 목적 서비스의 요구사항에 맞춰 선택해야 합니다. 구독 이름에 ‘일본’이라고 표시되어 있어도 출구 지역을 뜻할 수 있으며, 클라이언트가 직접 연결하는 서버까지 일본에 있다는 의미는 아닙니다. 중계 회선은 먼저 국내 진입 지점을 거친 다음 해외 출구로 연결될 수 있습니다. 물리적으로 가까운 노드라도 통신사 경로가 우회하면 더 먼 노드보다 느릴 수 있습니다.

목적 서비스에서 실제로 감지하는 출구 확인하기

1. 현재 프록시 그룹에서 테스트할 노드를 선택하고 목적 웹사이트를 열어 새 연결을 만드세요.
2. 클라이언트의 연결 목록에서 해당 요청에 적용된 규칙과 프록시 체인을 확인해 다른 경로를 거치지 않는지 살펴보세요.
3. 신뢰할 수 있는 IP 조회 페이지에서 출구 IP와 지역을 확인한 뒤 목적 서비스가 예상한 콘텐츠를 제공하는지도 확인하세요.
4. 기존 장기 연결이 이전 출구를 계속 사용한다면 관련 앱을 종료한 후 다시 실행하세요. 일부 클라이언트에서는 기존 연결을 직접 끊을 수도 있습니다.

IP 데이터베이스와 목적 서비스의 지역 판정은 서로 다를 수 있습니다. 조회 페이지에 일본으로 표시되더라도 모든 스트리밍 서비스, 결제 시스템, 계정 시스템이 일본으로 판정하는 것은 아닙니다. 서비스는 계정 지역, 결제 정보, 기기 위치, 로그인 기록, IP 위험 정보 등을 함께 참고할 수 있습니다. 국가만 바꾼다고 접속 제한이 풀리는 것은 아닙니다.

용도에 따라 여러 지역의 노드 유지하기

• 원격 근무: 조직의 접속 정책을 우선 따르고 출구 지역을 되도록 일정하게 유지하세요. 여러 지역에서 자주 로그인하면 추가 인증이 발생할 수 있습니다.
• 지역 제한 콘텐츠: 홈페이지 접속만 확인하지 말고 목적 서비스에서 필요한 콘텐츠를 직접 테스트하세요.
• 일반 브라우징: 이용 가능한 노드 중 혼잡 시간대 성능을 비교하고, 지역 표시는 보조 조건으로만 활용하세요.
• 게임: 게임 트래픽이 실제로 프록시를 통과하는지, 노드와 규칙이 필요한 UDP를 지원하는지 먼저 확인하세요. 브라우저에서 웹페이지가 열린다고 게임 연결도 된다는 뜻은 아닙니다.

브라우저와 명령줄에서 확인되는 출구가 다르다면 브라우저 프록시 확장 프로그램, 시스템 프록시, TUN 라우팅, 앱 자체 프록시 설정부터 점검하세요. 라우팅을 확인하기 전에 노드를 계속 바꾸면 노드 자체가 아니라 서로 다른 트래픽 경로를 비교하게 됩니다.

4. 전송 프로토콜: Trojan·VLESS·Hysteria2 선택법

프로토콜은 연결을 설정하고 데이터를 전송하는 방식을 결정하지만 회선 품질을 대신하지는 않습니다. 같은 프로토콜도 서로 다른 서버와 네트워크에 구축될 수 있으며, 하나의 서버가 여러 프로토콜 연결을 제공할 수도 있습니다. 먼저 클라이언트 호환성을 확인한 뒤 사용하는 네트워크에서 연결 성공률, 지속 전송량, 연결 복구 성능을 비교하세요.

Trojan과 VLESS: 프로토콜 이름만으로 판단하지 않기

Trojan 노드는 TCP와 TLS 조합으로 제공되는 경우가 많습니다. VLESS는 보안 계층과 전송 설정까지 확인해야 합니다. REALITY는 보안 계층 방식이지 ‘전송 속도 등급’이 아닙니다. WebSocket이나 gRPC 같은 전송 방식도 연결 특성에 영향을 줍니다. ‘VLESS가 Trojan보다 최신’이라는 이유만으로 현재 네트워크에서 더 빠르다고 결론 내릴 수는 없습니다.

가져온 뒤 TLS 또는 핸드셰이크 오류가 발생하면 시스템 시간, 서버 주소, 포트, SNI, 인증 정보, 구독 데이터가 완전한지 확인하세요. REALITY를 사용하는 경우 서버가 요구하는 관련 매개변수도 일치해야 합니다. 오류를 없애려고 인증서 검증을 끄지 마세요. 먼저 주소나 인증서, 매개변수 불일치 문제를 해결해야 합니다.

Hysteria2: 먼저 UDP 연결을 확인하고 전송량 측정하기

Hysteria2는 지연 시간이 길거나 패킷 손실이 있는 일부 네트워크에서 높은 전송량을 낼 수 있지만, 실제 결과는 네트워크와 서버 설정에 따라 달라집니다. 학교나 회사 네트워크, 공용 Wi-Fi에서 UDP를 제한하면 TCP 기반 노드는 연결되지만 Hysteria2는 연결되지 않을 수 있습니다. 이때는 다른 네트워크에서 다시 테스트하고 사용 가능한 TCP 기반 노드도 유지하세요.

대역폭 매개변수는 높을수록 좋은 것이 아닙니다. 대역폭 설정은 실제 회선 용량과 서버 제한에 맞추세요. 지나치게 높은 값은 혼잡을 악화시킬 수 있습니다. 먼저 서비스 제공업체가 제공한 유효한 설정을 유지하고, 관련 혼잡 제어 설정을 이해한 뒤 조정하세요. 자신의 회선과 맞지 않는 ‘고속 설정’을 그대로 적용하지 마세요.

네 가지 기준으로 반복 가능한 노드 선별하기

처음부터 구독에 있는 모든 노드의 대역폭을 전부 측정할 필요는 없습니다. 먼저 소수의 후보를 기본 점검한 뒤 자주 사용하는 서비스로 테스트하세요. 아래 절차는 노드를 직접 고를 때뿐 아니라 자동 선택 프록시 그룹이 요구사항에 맞는지 확인할 때도 유용합니다.

1. 후보 3개 선택: 목적 지역 조건을 충족하고 배율이 부담스럽지 않으며 코어가 인식하는 노드를 고르세요. 가능하면 서로 다른 회선을 포함하세요.
2. 규칙 확인: 목적 요청에 적용된 규칙과 출구를 확인하세요. 비교를 위해 일시적으로 Global 모드를 사용했다면 테스트 후 원래 Rule 모드로 되돌리세요.
3. 짧은 요청 반복 테스트: 각 노드에서 같은 테스트 URL을 5회 측정하고 실패 횟수와 결과 편차를 기록하세요.
4. 실제 사용 환경에서 테스트: 자주 쓰는 웹사이트를 열고 같은 동영상을 재생하거나 원격 터미널에 접속해 연결 끊김과 재접속 여부를 확인하세요.
5. 혼잡 시간대 추가 테스트: 평소 가장 자주 사용하는 시간대에 한 번 더 테스트하세요. 낮에 나온 결과를 하루 전체의 성능으로 보면 안 됩니다.
6. 주 노드와 예비 노드 확보: 주 노드는 안정성과 비용 조건을 충족해야 하며, 예비 노드도 주 노드에 문제가 생겼을 때 같은 작업을 수행할 수 있어야 합니다.

자동 선택 그룹이 목적 서비스에 최적인 것은 아닙니다

mihomo의 url-test 그룹은 설정된 테스트 URL, 테스트 간격, 허용 오차 등을 기준으로 노드를 선택합니다. 탐색 결과를 최적화할 뿐 스트리밍 지역이나 트래픽 배율, 계정 로그인 패턴을 자동으로 고려하지는 않습니다. 배율과 지역이 서로 다른 노드를 한 그룹에 넣으면 자동 전환에 따라 출구와 비용이 달라질 수 있습니다.

먼저 용도에 맞춰 후보를 선별한 다음 자동 선택 그룹이 그 후보 안에서 비교하도록 설정하는 것이 안전합니다. 예를 들어 특정 지역 서비스용으로는 같은 지역의 노드를, 대용량 작업용으로는 요금을 감당할 수 있는 노드를 따로 구성하세요. 설정 항목의 의미는 사이트의 고급 설정 가이드에서 확인할 수 있습니다. 최초 가져오기와 프록시 모드 사용법은 사용 가이드를 참고하세요.

최종 기록은 복잡한 점수표일 필요가 없습니다. 네트워크 환경, 테스트 시간, 목적 서비스, 성공 횟수, 결과 편차, 배율만 적어 두면 됩니다. 자주 사용하는 시간대에 안정적으로 작업을 마칠 수 있고 비용을 예측할 수 있는 노드가 가끔 최저 지연 시간을 기록하는 노드보다 일상적인 출구로 적합합니다.

기술 문서 및 확인 자료

클라이언트마다 버튼 이름은 다를 수 있으므로 프로토콜과 테스트 동작은 사용 중인 코어의 문서를 우선 확인하세요. 다음 자료는 URL 테스트 항목, 프록시 프로토콜 설정, Hysteria2 대역폭 설정을 확인하기 위한 것으로, 특정 노드의 품질을 보증하지 않습니다.

• mihomo 문서: 자동 선택 그룹 url-test에서 테스트 주소, 간격, 허용 오차를 확인하세요.
• mihomo 문서: 아웃바운드 프록시에서 Trojan, VLESS, Hysteria2의 설정 항목과 지원 여부를 확인하세요.
• Hysteria 2 문서: 전체 클라이언트 설정에서 QUIC 및 대역폭 관련 설정을 확인하세요. 기본 클라이언트 설정 형식은 mihomo YAML에 그대로 붙여 넣을 수 없습니다.