노드를 고를 때는 먼저 필요한 서비스에 접속할 수 있는지 확인한 뒤, 혼잡 시간대의 안정성, 실제 연결 지연 시간, 트래픽 비용을 비교하세요. 구독을 이미 가져와 여러 회선 중 주력 노드를 고르려는 사용자를 위한 안내입니다. TCPing으로 기본 연결 문제를 걸러내고, 같은 테스트 대상으로 실제 연결을 측정한 다음, 출구 지역·트래픽 배율·프로토콜 설정을 고려해 주력과 예비 회선을 각각 하나씩 선택하세요.
1. TCPing과 실제 연결 지연 시간: 측정 범위의 차이
노드 목록에 표시된 밀리초 값이 모두 같은 방식으로 측정된 것은 아닙니다. TCPing은 보통 내 기기에서 서버 주소와 포트까지 TCP 연결을 설정하는 데 걸리는 시간을 측정합니다. 프록시 인증 성공 여부나 서버에서 대상 웹사이트에 접속할 수 있는지는 확인하지 않습니다. 포트 연결은 되는데 웹페이지가 열리지 않는 상황도 충분히 발생할 수 있습니다.
실제 연결 지연 시간은 대개 해당 노드를 통해 지정한 테스트 주소로 요청을 보내 측정합니다. 프록시 핸드셰이크, 대상 사이트 연결, 응답 등의 과정이 포함됩니다. 정확한 측정 범위는 클라이언트와 코어 구현에 따라 다르므로 같은 클라이언트와 테스트 주소를 사용하고, 비슷한 시간대에 측정한 결과끼리 비교해야 합니다. 웹 이용 상황에 더 가까운 지표지만 다운로드 속도는 아니며, 모든 웹사이트의 성능을 나타내지도 않습니다.
| 테스트 방식 | 확인할 수 있는 내용 | 이 결과만으로는 알 수 없는 내용 |
|---|---|---|
| TCPing | 서버 진입 지점의 TCP 포트에 연결할 수 있는지, 연결 설정이 느린지 | 계정이 유효한지, 프록시 출구가 정상인지, 대상 웹사이트를 이용할 수 있는지 |
| 실제 연결 지연 시간 | 프록시를 통해 지정된 테스트 대상에 접속되는지와 대략적인 응답 시간 | 지속 다운로드 대역폭, 모든 서비스와의 호환성, 장시간 연결 안정성 |
| 다운로드 속도 테스트 | 지정된 대상과 시간 동안의 전송 성능 | 화상 회의의 지터, 서비스 이용 지역 조건, 하루 중 혼잡 시간대의 성능 |
2. v2rayN 노드 테스트: 조건을 통일한 뒤 비교하기
v2rayN 기본 창에서 후보 서버를 선택하고 마우스 오른쪽 버튼을 눌러 ‘실제 연결 지연 시간’이 포함된 테스트 항목을 실행하세요. 일부 버전에서는 ‘서버 실제 연결 지연 시간 테스트’로 표시됩니다. 기본 포트 테스트에는 ‘Tcping’이 포함된 항목을 선택하세요. 데스크톱 앱과 버전에 따라 메뉴 문구가 조금씩 다를 수 있으므로 테스트 종류를 기준으로 구분하고, 서로 다른 열의 결과를 섞어 순위를 매기지 마세요.
- 후보는 몇 개만 추리세요.지역과 트래픽 배율이 조건에 맞는 노드 3~5개를 고르고, 시스템 업데이트·클라우드 동기화·다른 다운로드를 일시 중지하세요. 같은 네트워크에 연결된 상태를 유지하세요.
- 테스트 대상을 통일하세요.‘설정’ → ‘매개변수 설정’에서 속도 측정 관련 항목을 찾으세요. 현재 버전에 ‘실제 연결 테스트 주소’ 설정이 있다면 모든 후보에 같은 주소를 사용하고, 테스트 중간에 변경하지 마세요.
- 연속으로 3회 측정하세요.매회 결과와 시간 초과 횟수를 기록하세요. 예를 들어 82, 88, 230밀리초가 나왔다면 최저값인 82밀리초만 기록해서는 안 됩니다. 결과의 편차도 함께 살펴보세요.
- 활성 서버로 설정하세요.우선 후보에서 마우스 오른쪽 버튼을 눌러 ‘활성 서버로 설정’을 선택하세요. 시스템 프록시 또는 현재 사용 중인 프록시 적용 방식이 활성화됐는지 확인한 뒤 실제로 이용할 웹사이트에 접속하세요.
- 로그를 확인하세요.로그 영역에서 연결 실패, 인증 오류, TLS 핸드셰이크 오류를 살펴보세요. 브라우저로 테스트할 때는 해당 요청이 직결 규칙에 따라 우회되지 않고 실제로 프록시를 통과하는지도 확인해야 합니다.
위의 82, 88, 230밀리초는 기록 방법을 보여주는 예시일 뿐, 특정 지역에서 측정한 결과가 아닙니다. 비교할 때는 중앙값, 시간 초과 횟수, 최악의 결과를 확인하세요. 가끔 빠르더라도 자주 실패하는 노드는 일상적인 주력으로 사용하기 어렵습니다.
이 수치는 실행하기 편하도록 제안한 선별 기준이지, 성능 합격선이 아닙니다. Android용 v2rayNG에서는 메인 화면 오른쪽 위 메뉴에서 ‘모든 구성의 실제 연결 테스트’와 같은 항목을 실행할 수 있습니다. 테스트 후에는 후보를 선택해 연결을 시작하고 실제 서비스를 확인해야 합니다. 네트워크 접속 방식별로 결과를 따로 기록하세요. 집의 유선 인터넷에서 얻은 순위를 모바일 네트워크에 그대로 적용할 수는 없습니다.
3. 노드 트래픽 배율: 낮은 배율과 낮은 지연 시간은 다른 기준
트래픽 배율은 보통 구독 서비스 서버에서 데이터 사용량을 계산할 때 적용합니다. 클라이언트의 노드 이름에 표시된 ‘0.5x’, ‘1x’, ‘2x’는 참고 정보일 뿐이며, 실제 차감량은 서버 정책과 사용량 페이지를 기준으로 확인해야 합니다. 배율이 높다고 지연 시간이 자동으로 낮아지는 것은 아닙니다. 회선 비용, 대역폭 자원, 서비스 제공자의 가격 정책 등이 반영된 값일 수 있습니다.
| 노드 트래픽 배율 | 기본 과금 트래픽을 가정한 경우 | 배율을 적용한 차감량 |
|---|---|---|
| 0.5배 | 1 GiB | 0.5 GiB |
| 1배 | 1 GiB | 1 GiB |
| 2배 | 1 GiB | 2 GiB |
표에서는 ‘과금 기준 트래픽 × 배율’이라는 단순 계산식을 사용했습니다. 일부 서비스는 업로드와 다운로드를 합산하며, 전송 오버헤드와 단위 변환, 통계 반영 지연도 사용량 페이지에 표시되는 값에 영향을 줍니다. 따라서 1 GiB로 표시된 파일을 다운로드해도 기본 사용량이 정확히 1 GiB만 늘어나는 것은 아닙니다.
- 동영상과 대용량 파일:먼저 안정적인 전송 속도를 확인한 다음 배율을 비교하세요. 필요한 성능을 충족한다면 속도 측정에서 더 높은 최고 속도를 내기 위해 더 많은 트래픽을 쓸 필요는 없습니다.
- 웹과 가벼운 업무:대체로 트래픽 사용량이 적으므로 최저 배율만 찾기보다 안정적인 응답과 적은 시간 초과를 우선하세요.
- 속도 측정 비용:속도 테스트는 실제 데이터를 전송합니다. 수십 개 노드에서 대역폭을 끝까지 사용하는 테스트를 반복하지 말고, 먼저 지연 시간 테스트로 후보를 줄이세요.
4. 지역 선택: 진입 위치, 출구 위치, 서비스 제한
노드 이름에 특정 지역이 적혀 있어도 전체 경로가 그 지역에 있는 것은 아닙니다. 진입 지점은 기기가 회선에 연결되는 위치이고, 출구는 대상 웹사이트에서 확인하는 공인 IP의 위치입니다. 그 사이에 중계가 있을 수도 있습니다. 지리적으로 가까우면 전파 지연 시간을 줄이는 데 유리한 경우가 많지만, 통신사 간 연결과 우회 경로, 혼잡도에 따라 실제 순위는 달라질 수 있습니다.
특정 지역에서만 이용할 수 있는 서비스가 필요하다면 해당 서비스 페이지에서 직접 접속 여부를 확인하세요. IP 위치 데이터베이스의 갱신이 늦을 수 있으며, 스트리밍 서비스 등은 계정 지역과 결제 정보, 프록시 감지 결과를 함께 고려할 수 있습니다. 노드 이름이나 IP 조회 결과 하나만으로 서비스 이용을 보장할 수는 없습니다.
가까운 출구를 선택하고 혼잡 시간대에 확인
권장네트워크 경로가 짧은 후보부터 실제 연결 테스트와 웹사이트 접속으로 확인하세요. 혼잡 시간대에 시간 초과가 적고 응답이 안정적인 노드를 주력으로 남기세요.
적합한 용도: 일상적인 웹 이용, 업무, 특정 지역 조건이 없는 서비스
서비스가 요구하는 지역의 출구
먼저 대상 서비스의 지역 조건을 충족한 다음 응답 시간과 전송 속도를 비교하세요. 로그인, 재생, 지속적인 이용까지 확인해야 합니다. 첫 화면이 열리는지만으로 판단하지 마세요.
적합한 용도: 지역 조건이 명확한 콘텐츠 및 계정 서비스
경로가 다른 예비 출구
예비 회선은 가능한 한 주력 회선과 진입 지점이나 상위 회선을 공유하지 않는 것으로 고르세요. 노드 이름이 달라도 같은 회선을 공유할 수 있으므로 서비스 안내를 확인해야 합니다.
적합한 용도: 혼잡 시간대에 전환하거나 주력 회선 점검 중 이어서 이용할 때
5. VLESS·VMess·Trojan: 전체 설정을 기준으로 호환성 확인
프로토콜 이름은 설정의 일부만 나타냅니다. 전송 방식, TLS 또는 REALITY, 보안 매개변수, 서버 구성, 회선 품질이 모두 결과에 영향을 줍니다. ‘VLESS가 항상 VMess보다 빠르다’는 신뢰할 만한 노드 선택 기준이 아닙니다. 같은 프로토콜도 회선에 따라 성능 차이가 크게 날 수 있습니다.
| 프로토콜 | 확인해야 할 항목 | 선택 시 고려할 점 |
|---|---|---|
| VLESS | UUID, 전송 방식, 보안 유형. REALITY를 사용한다면 공개 키, shortId, serverName 등의 매개변수도 확인하세요. | VLESS 자체에는 전송 암호화 기능이 없으므로 전체 보안 설정을 확인하세요. flow 값은 서버 설정과 일치해야 합니다. |
| VMess | UUID, 암호화 설정, 전송 방식. TLS를 사용하는 경우 서버 이름도 확인하세요. | 기기 시간과 서버 매개변수를 확인하고, 인증 실패를 회선 혼잡으로 오해하지 마세요. |
| Trojan | 비밀번호, 서버 주소, 포트, TLS 서버 이름, 전송 매개변수 | 일반적인 구성에서는 TLS를 사용합니다. 인증서 검증에 실패하면 이름, 인증서, 시스템 시간을 확인하세요. |
서버가 443 포트를 사용한다고 해서 해당 노드가 본질적으로 더 빠른 것은 아니며, 포트만으로 보안 여부를 판단할 수도 없습니다. 오류를 없애려고 ‘인증서 검증 건너뛰기’를 함부로 켜지 마세요. 먼저 구독에 지정된 서버 이름, 시스템 시간, 서버 인증서 구성을 확인하세요.
구성 방법: 기존 노드에 맞춰 클라이언트 코어 선택
VLESS + REALITY 노드
- 데스크톱에서는 v2rayN이 해당 구성을 지원하는 Xray 코어를 사용하는지 확인하세요.
- Android에서는 Xray 코어 기반의 v2rayNG를 사용할 수 있습니다. 클라이언트를 최신 상태로 유지하세요.
- 구독 매개변수를 모두 유지하고 보안 유형을 임의로 TLS로 바꿔 REALITY를 대체하지 마세요.
기존 VMess 또는 Trojan 노드
- 먼저 서버에서 지정한 프로토콜, 전송 방식, 보안 매개변수를 그대로 유지한 채 회선을 테스트하세요.
- v2flyNG는 V2Fly 코어를 사용합니다. 구체적인 설정 지원 여부는 해당 버전을 기준으로 확인해야 합니다.
- 가져올 때 지원하지 않는 필드라는 오류가 표시되면 프로토콜을 임의로 변경하지 말고 먼저 코어 호환성을 확인하세요.
프로토콜을 바꾸려고 클라이언트 설정을 수정하지 말고, 먼저 전체 설정과 코어 호환성을 확인한 다음 회선 성능을 비교하세요.
6. 지연 시간은 낮은데 사용하기 불편할 때: 증상별 점검
노드 선택의 마지막 단계는 속도 측정 결과를 정렬하는 것이 아니라 실제로 사용해 보는 것입니다. 같은 브라우저로 자주 방문하는 페이지에 접속하고, 파일을 한 번 다운로드하거나 동영상을 재생해 보세요. 회의가 필요하다면 장시간 연결이 쉽게 끊기는지도 확인하세요. 실시간 통신은 UDP 지원 여부와 앱 동작, 라우팅 규칙에도 영향을 받으므로 일반 HTTPS 테스트만으로는 충분히 확인할 수 없습니다.
TCPing은 30밀리초인데 실제 연결은 왜 계속 시간 초과되나요?
30밀리초라는 결과는 진입 포트 연결이 빠르다는 뜻일 뿐입니다. 먼저 정상 작동하는 다른 노드로 같은 대상을 테스트한 다음, 로그에서 인증·TLS·DNS 오류를 확인하세요. UUID 또는 비밀번호, 보안 유형, 전송 매개변수, 시스템 시간도 점검하세요.
지연 시간이 가장 낮은 노드인데 다운로드가 느린 이유는 무엇인가요?
짧은 요청에 빠르게 응답한다고 해서 지속적인 대역폭까지 충분한 것은 아닙니다. 최종 후보 두세 개만 같은 다운로드 대상에서 테스트하세요. 동시 다운로드는 끄고, 순간 최고 속도가 아니라 안정적인 속도를 기록한 뒤 저녁 혼잡 시간대에도 다시 확인하세요.
낮에는 괜찮은데 저녁에는 계속 로딩됩니다. 프로토콜을 바꿔야 하나요?
먼저 기존 설정은 그대로 두고 같은 대상과 네트워크에서 경로가 다른 예비 노드로 전환해 보세요. 혼잡 시간대에만 성능이 나빠진다면 대역폭과 경로 혼잡을 확인하는 편이 좋습니다. 프로토콜 이름을 바꿔도 공유 상위 회선의 혼잡은 해결되지 않습니다.
Android에서는 되는데 컴퓨터에서 같은 웹사이트가 열리지 않습니다. 노드 문제인가요?
먼저 두 기기가 같은 네트워크에 연결되어 있고 같은 노드를 사용하는지 비교하세요. 컴퓨터에서는 활성 서버와 시스템 프록시 상태를 확인한 다음, 직결 규칙이나 브라우저 자체 프록시 설정이 있는지 살펴보세요. 두 기기의 코어가 해당 설정을 지원하는지도 확인해야 합니다.
최종 선택 체크리스트
- 주력 노드 하나:필요한 서비스를 이용할 수 있고 평소와 혼잡 시간대 모두 안정적이며, 트래픽 배율도 감당할 수 있는 수준이어야 합니다.
- 예비 노드 하나:가능한 한 주력과 다른 경로를 사용하고, 목록에 표시된 지연 시간만 믿지 말고 직접 연결해 확인하세요.
- 테스트 기록:노드 별칭, 테스트 날짜, 접속 네트워크, 3회 측정 결과, 실제 사용 느낌을 저장하세요. 스크린샷을 찍기 전에는 구독 주소와 접속 자격 증명을 가리세요.
- 재측정:유선 인터넷이나 모바일 네트워크, 구독 회선을 바꾼 뒤에는 다시 비교하세요. 이전 순위를 장기적인 결론으로 여기지 마세요.
노드 선택은 다음 순서로 진행하면 됩니다. 서비스 이용 가능 여부 → 혼잡 시간대 안정성 → 응답 시간과 전송 속도 → 트래픽 배율 비용 → 예비 경로. 프로토콜과 지역은 선별 조건이며, 최종 판단은 실제 연결 결과를 기준으로 해야 합니다.