노드 고르는 법: 지연·배율, 지역과 프로토콜 유형의 우선순위

순서부터 정하기: 지역 → 프로토콜 유형 → 배율 → 지연

노드 목록에는 항목이 많지만 실제 사용 경험에 영향을 주는 것은 네 가지뿐입니다. 노드가 있는 지역, 프로토콜과 전송 조합, 트래픽 배율, 그리고 앞의 두 가지와 로컬 회선이 함께 결정하는 지연입니다. 이 네 가지를 같은 층위에 놓고 계속 비교하면 고민만 길어집니다.

더 효과적인 방법은 먼저 제외하고 그다음 정렬하는 것입니다. 지역은 왕복 시간의 물리적 하한을 정하고, 프로토콜 조합은 혼잡할 때 이 회선이 간섭을 받기 쉬운지를 정하며, 배율은 그 트래픽에 지불하는 비용을 정합니다. 지연은 앞의 세 가지가 현재 네트워크 환경에 반영된 결과일 뿐입니다.

네 가지 기준에서 바로 참고할 수 있는 수치는 아래와 같으며, 각 항목은 뒤에서 자세히 다룹니다.

지역: 지연 하한과 회선 품질을 함께 결정

물리적 거리는 피할 수 없습니다. 데이터 패킷이 로컬 출구에서 상대 데이터센터까지 갔다가 돌아오는 시간은 광섬유 안에서의 왕복만으로 이미 지연의 바닥값을 정하며, 프로토콜 차원의 최적화는 그 위에 더하는 것에 불과합니다.

아래 표는 일반적인 데이터센터 위치를 기준으로 정리한 경험 구간입니다. 실제 수치는 로컬 인터넷 회선, 통신사 국제 구간, 저녁 피크 혼잡 상태에 따라 달라지며, 같은 지역 안에서도 회선별 차이가 지역 간 차이보다 클 수 있습니다.

지역의 역할은 범위를 좁히는 것이지 최종 선택을 정하는 것이 아닙니다. 먼저 물리적 거리로 후보를 근거리, 차근거리, 원거리 세 그룹으로 나누고, 각 그룹 안에서 구체적인 회선을 비교하면 훨씬 효율적입니다.

프로토콜 유형: 전송 계층을 먼저, 보안 계층을 다음에

클라이언트 목록의 노드 이름에는 보통 세 가지 정보가 담겨 있습니다. 프로토콜, 전송 방식, 보안 계층입니다. 예를 들어 VLESS + TCP + Reality, 또는 VMess + WebSocket + TLS 같은 식입니다. 프로토콜은 인증과 암호화 방식을 정하고, 전송 방식은 데이터 패킷이 네트워크에서 어떤 모습으로 흐르는지를 정합니다.

일반 사용자가 각 조합의 구현 세부를 이해할 필요는 없고, 세 가지만 판단하면 됩니다. 이 회선에 자체 도메인이 필요한지, TLS 인증서에 의존하는지, 그리고 자주 쓰는 클라이언트에서 정상적으로 불러와지는지입니다.

세 조합은 정상적인 네트워크에서 속도 차이가 보통 10% 미만이며, 실제로 차이를 만드는 것은 저녁 피크나 망 간 이동 시의 안정성입니다. 프로토콜 유형은 명백히 맞지 않는 조합을 걸러내는 데 적합하고, 세밀하게 고르는 데는 적합하지 않습니다.

노드가 어떤 조합인지 판단할 때는 구독의 공유 링크 파라미터를 보는 것이 가장 빠릅니다.

• security: 보안 계층으로 값은 none / tls / reality이며 핸드셰이크 방식을 결정합니다.
• type: 전송 방식으로 값은 tcp / ws / grpc / http입니다.
• flow: 흐름 제어 방식으로, xtls-rprx-vision은 VLESS + TCP + Reality 또는 VLESS + TCP + TLS에서만 유효합니다.
• sni: 핸드셰이크에 사용하는 대상 도메인으로, Reality와 TLS 모두 이 값에 의존합니다.
• path와 host: WebSocket, HTTP 전송 전용이며, 값이 없으면 연결은 되지만 트래픽이 전달되지 않는 상황이 생깁니다.

배율: 트래픽 비용을 계산한 뒤 정렬하기

배율은 서버가 트래픽에 적용하는 과금 계수입니다. 1.0×는 실제로 1 GB를 전송하면 요금제에서 1 GB가 차감된다는 뜻이고, 2.0×는 같은 1 GB 전송에 2 GB가 차감된다는 뜻입니다. 배율과 속도는 반드시 연결되지 않으며, 배율이 높은 회선이 더 빠르지도 않습니다.

배율을 일상 사용량에 곱해 보면 판단이 훨씬 직관적입니다. 월 업로드·다운로드 합계가 60 GB라고 가정해 보겠습니다.

• 1.0× 회선: 요금제 트래픽 60 GB 소모.
• 1.5× 회선: 요금제 트래픽 90 GB 소모.
• 2.0× 회선: 요금제 트래픽 120 GB 소모.
• 3.0× 회선: 요금제 트래픽 180 GB 소모.

결론은 배율 2.0× 이상 노드는 비상용으로 두고, 일상 주력은 1.0×와 1.5× 사이에서 고르는 것입니다. 영상 시청이나 대용량 파일 다운로드처럼 트래픽이 많은 작업은 낮은 배율을 우선하고, 웹 브라우징이나 메신저처럼 트래픽이 적은 작업에서는 배율 차이가 거의 무시할 수준입니다.

지연: 무엇을 재고, 몇 번 재고, 얼마나 흔들리면 이상인가

클라이언트에서 측정할 수 있는 지연은 두 가지입니다. 하나는 TCP 핸드셰이크 지연으로, 노드 서버의 포트까지 도달 가능한지만 확인합니다. 다른 하나는 실제 연결 지연으로, 노드에서 실제로 요청을 한 번 보내고 결과를 돌려받습니다. 전자는 값이 더 작게 나오고 후자가 실제 체험에 가까우므로, 노드를 고를 때는 후자를 기준으로 삼습니다.

v2rayN에서는 노드를 선택한 뒤 마우스 오른쪽 버튼으로 「실제 연결 지연 테스트」를 고르면 메인 화면이 결과에 따라 다시 정렬됩니다. v2rayNG에서는 오른쪽 위 ⋮ 를 눌러 「모든 구성 지연 테스트」를 선택하면 목록 오른쪽에 값이 하나씩 채워집니다. 국가 간 회선에서는 기본 타임아웃이 짧게 잡혀 있을 수 있으므로 「설정」→「매개변수 설정」→「기본 설정」에서 늘린 뒤 다시 측정하세요.

한 번 나온 결과를 그대로 믿지 마세요. 같은 노드를 세 번 연속 측정해 중간값을 구하고, 인접한 노드와 비교합니다. 판단 기준은 아래 네 가지로 적용할 수 있습니다.

1. 세 번 모두 80 ms 이내: 일상 주력으로 지정해도 됩니다.
2. 세 번의 결과 편차가 30%를 넘거나 중간에 한 번 시간 초과가 발생: 회선이 흔들린다는 뜻이므로 예비로 내립니다.
3. 실제 연결 지연이 TCP 지연보다 뚜렷하게 높음, 예를 들어 두 배 이상: 노드 서버 부하가 높거나 복귀 경로가 우회하는 것이므로 같은 지역의 다른 노드로 바꿉니다.
4. 모든 노드가 동시에 느려짐: 문제는 보통 노드에 있지 않으므로 먼저 프록시를 끄고 로컬 네트워크 자체가 정상인지 확인한 뒤 다시 측정합니다.

따로 기록해 둘 만한 경우가 하나 더 있습니다. 어떤 노드는 낮에는 안정적이지만 저녁 피크마다 반드시 흔들리는 경우입니다. 이는 노드 고장이 아니라 회선 혼잡이므로, 바로 삭제하기보다 예비 그룹에 남겨 두는 편이 낫습니다.

적용: 두 플랫폼에서 같은 선택 결과 공유하기

데스크톱과 안드로이드에서 같은 구독 링크를 쓰면 노드 목록, 그룹, 정렬이 그대로 유지되므로 선택은 한 번만 하면 됩니다. 두 플랫폼의 차이는 주로 테스트 진입 위치와 일상적인 사용 방식에 있습니다.

이 순서를 습관으로 굳히세요. 새 구독을 가져오면 먼저 지역별로 그룹을 나누고, 배율 2.0× 이상 노드를 제외하고, 남은 노드마다 실제 연결 지연을 세 번 측정해 중간값으로 정렬한 뒤 상위 세 개를 상용 노드로 삼습니다. 이후에는 구독을 갱신할 때마다 한 번씩 다시 측정하면 됩니다.

한 가지 짚어 둘 점은 노드 품질이 시간에 따라 변하기 때문에 한 번의 선택 결과가 장기적인 결론이 되지는 않는다는 것입니다. 같은 데이터센터라도 시간대에 따라 성능이 완전히 달라질 수 있으므로, 한 번 정밀하게 고르는 것보다 주기적으로 다시 측정하는 편이 더 의미 있습니다.