V2Ray 속도 느릴 때 점검하는 법: 노드·회선·로컬 설정 3단계 진단

프록시 속도가 갑자기 떨어졌을 때 프로토콜을 바꾸거나 Mux를 켜고 클라이언트를 반복해서 재설치해도 대개 점검 시간이 줄어들지는 않습니다. 다운로드 속도는 노드 부하, 접속 회선, 망 간 혼잡, 대상 사이트 응답, 로컬 프록시 모드와 기기 성능이 함께 영향을 미친 결과입니다. 먼저 재현 가능한 테스트 조건을 만든 뒤 한 번에 하나의 변수만 바꿔야 합니다.

먼저 속도 측정 기준선을 정해 지연 시간과 대역폭을 혼동하지 않기

지연 시간과 처리량은 같은 지표가 아닙니다. 지연 시간 테스트는 한 번 왕복하는 데 걸리는 시간을 보여 주므로 노드가 연결을 안정적으로 수립할 수 있는지 판단하는 데 적합합니다. 다운로드 속도는 일정 시간 동안 전송할 수 있는 데이터 양을 나타내며 노드의 출구 대역폭, 대상 서버의 속도 제한, TCP 혼잡 제어의 영향도 받습니다. 지연 시간이 45ms인 노드가 처리량 8Mbps에 그칠 수도 있고, 130ms인 노드가 120Mbps를 안정적으로 낼 수도 있습니다.

테스트 전에 클라우드 드라이브 동기화, 시스템 업데이트, 브라우저 백그라운드 동영상을 일시 중지합니다. 같은 기기, 같은 접속 네트워크, 같은 대상 파일을 고정하고 세 번 연속 측정합니다. 첫 연결에는 DNS 조회와 TLS 핸드셰이크가 포함될 수 있으므로 두 번째와 세 번째 결과를 기록하는 것이 좋습니다. 세 번의 결과가 각각 92, 95, 90Mbps라면 노드가 비교적 안정적입니다. 반대로 88, 21, 76Mbps라면 최고값만 취하지 말고 부하와 패킷 손실을 계속 관찰해야 합니다.

1단계: 노드 자체의 혼잡 또는 제한 여부 확인

노드 계층의 문제에는 대개 세 가지 특징이 있습니다. 같은 네트워크에서 일부 노드만 느리고, 하루 종일 느리면서 여러 번 측정해도 비슷한 상한에 머물며, 연결 수를 늘리면 지연 시간이 급격히 증가합니다. 먼저 같은 지역의 서로 다른 노드를 선택해 비교하세요. 노드 A가 세 번 각각 18, 20, 19Mbps이고 노드 B가 86, 91, 88Mbps라면 로컬 네트워크와 클라이언트가 주요 병목일 가능성은 낮습니다.

지연 시간 목록은 초기 선별에만 사용해야 합니다. v2rayN의 지연 시간 테스트는 노드 응답 시간을 확인하지만 다운로드 성능을 직접 나타내지는 않습니다. 먼저 메인 화면에서 노드를 선택해 지연 시간 테스트를 실행한 뒤, 지연 시간이 비슷한 두 노드로 실제 다운로드를 진행하세요. 한 노드가 지연 시간 62ms, 처리량 15Mbps이고 다른 노드가 75ms, 처리량 96Mbps라면 다운로드에는 후자를 우선 선택해야 합니다.

1. 테스트 환경 고정

   다른 다운로드 작업을 종료하고 같은 유선 또는 무선 네트워크를 유지하세요. 테스트 중에는 접속 방식을 바꾸지 않습니다. 각 테스트는 최소 60초 동안 진행합니다.

2. 노드 정보 업데이트

   v2rayN 7.x 메인 화면에서 「구독 그룹」→「모든 구독 업데이트」로 이동해 노드 주소, 포트와 전송 매개변수가 최신 구독에서 가져온 것인지 확인합니다.

3. 지연 시간으로 필터링

   후보 노드에 TCP 지연 시간 테스트를 실행하고, 지속적으로 시간 초과가 발생하거나 변동 폭이 300ms를 넘는 노드를 먼저 제외하세요. 최저 지연 시간만으로 결론을 내리면 안 됩니다.

4. 처리량 실측

   후보 노드 세 개를 선택해 동일한 작업을 각각 세 차례 수행하고 평균 속도, 최저 속도와 로딩 시작까지 걸린 시간을 기록합니다.

5. 로그 확인

   「도움말」→「로그 보기」를 열고 테스트 중 핸드셰이크 시간 초과, 연결 재설정 또는 대상에 연결할 수 없음 메시지가 집중적으로 나타나는지 확인합니다.

VMess, VLESS 또는 전송 방식을 바꾸는 것은 서버가 해당 설정을 제공할 때만 의미가 있습니다. 프로토콜은 클라이언트에서 일방적으로 바꾼다고 빨라지는 스위치가 아닙니다. 프로토콜을 비교할 때는 가능한 한 같은 서버, 같은 포트와 비슷한 보안 계층을 사용해야 합니다. 그렇지 않으면 기기 성능, 진입 회선과 출구 대역폭의 차이가 결과에 함께 반영됩니다.

2단계: 회선·시간대·접속 네트워크 비교

회선 혼잡에는 뚜렷한 시간대 패턴이 나타나는 경우가 많습니다. 낮에는 90Mbps로 안정적이지만 저녁 20:00~23:00에 15Mbps로 떨어지고 지연 시간이 70ms에서 220ms로 오른다면 피크 시간대 혼잡에 가깝습니다. 같은 지역의 여러 노드로 바꿔도 동시에 느려진다면 클라이언트 매개변수를 계속 바꾸기보다 접속 회선을 비교해야 합니다.

가장 효과적인 비교 방법은 같은 노드를 유지한 채 로컬 접속 네트워크만 바꾸는 것입니다. 예를 들어 노드를 고정했을 때 가정용 광대역에서 18Mbps, 다른 네트워크에서 82Mbps가 나온다면 병목은 로컬 통신사 네트워크, 라우팅 경로 또는 가정 내 장비에 있을 가능성이 높습니다. 두 네트워크 모두 18Mbps로 안정적이라면 노드 부하와 출구 제한을 다시 점검하세요.

3단계: 포트·DNS·라우팅·시스템 프록시 확인

같은 기기에서 모든 노드가 느리지만 동일한 네트워크를 사용하는 다른 기기는 정상이라면 로컬 설정을 점검해야 합니다. v2rayN의 일반적인 로컬 인바운드 포트는 10808이지만 실제 값은 「설정」→「매개변수 설정」의 구성을 기준으로 합니다. 브라우저, 다운로드 도구와 시스템 프록시는 현재 수신 대기 포트를 가리켜야 합니다. 이전 포트가 다른 프로그램에서 계속 사용 중이면 연결 실패가 발생하거나 프록시를 우회할 수 있습니다.

시스템 프록시와 TUN 모드는 트래픽 진입점이 다릅니다. 시스템 프록시는 시스템 프록시 설정을 따르는 애플리케이션만 제어하고, TUN 모드는 더 낮은 계층에서 트래픽을 가로챕니다. 점검할 때 여러 진입점을 동시에 적용하지 마세요. 먼저 TUN을 끄고 「시스템 프록시 자동 구성」만 활성화해 기준선을 측정한 뒤, 필요할 때 TUN을 별도로 테스트해야 차이가 캡처 방식 때문인지 노드 때문인지 판단할 수 있습니다.

1. 코어 확인

   「설정」→「매개변수 설정」→「Core 유형」으로 이동해 선택한 코어가 현재 구독의 VMess, VLESS와 전송 설정을 처리할 수 있는지 확인한 다음 코어를 재시작합니다.

2. 포트 확인

   「설정」→「매개변수 설정」에서 로컬 수신 대기 포트를 확인합니다. 10808이라면 브라우저나 다운로드 도구도 127.0.0.1:10808을 사용해야 합니다.

3. 프록시 모드 통일

   상태 표시줄의 「시스템 프록시」→「시스템 프록시 자동 구성」을 통해 테스트 환경을 만드세요. 시스템 프록시를 변경하는 다른 프로그램은 잠시 종료합니다.

4. 라우팅 단순화

   「설정」→「라우팅 설정」으로 이동해 우선 판단하기 쉬운 기본 규칙을 임시로 사용하고, 대상 요청이 프록시, 직결 또는 차단 중 어디로 처리되는지 확인합니다.

5. DNS 재테스트

   시스템 DNS 캐시를 삭제하고 코어를 재시작합니다. 로그에 DNS 해석 대기 시간이 길게 표시되면 로컬 DNS와 프록시 측 해석을 각각 테스트하고 더 안정적인 방식을 유지하세요.

테스트 조건: Windows 11 24H2, v2rayN 7.x
로컬 주소: 127.0.0.1
로컬 포트: 10808
회당 시간: 60초
테스트 횟수: 3회
기록 항목: TCP 지연 시간, 첫 바이트 시간, 평균 Mbps, 최저 Mbps, 오류 로그

라우팅 분기는 실제 경로를 직접 바꿉니다. 특정 다운로드 도메인이 잘못 직결로 판정되면 속도 측정 결과는 프록시 노드가 아닌 로컬 네트워크를 측정하게 됩니다. 반대로 직결해야 할 로컬 네트워크나 중국 본토 서비스를 모두 원격 노드로 보내면 우회 경로가 늘어납니다. 규칙을 확인할 때는 먼저 매칭 순서를 살펴보세요. 일반적으로 앞선 규칙이 아웃바운드를 먼저 결정하므로 이미 매칭된 요청을 뒤의 규칙이 다시 처리하지 않습니다.

Mux와 프로토콜 변경이 효과적인 경우

Mux는 여러 논리 연결을 더 적은 수의 하위 연결에 다중화합니다. 여러 개의 짧은 연결을 만들 때 발생하는 비용을 줄일 수 있어 작은 웹 리소스를 동시에 많이 열 때 유용할 수 있습니다. 하지만 단일 대용량 파일 다운로드가 더 빨라진다고 보장되지는 않습니다. 하위 연결에서 패킷 손실이 발생하면 여러 논리 스트림이 함께 대기할 수 있어 고대역폭·고손실 회선에서는 속도 변동이 오히려 커질 수 있습니다.

현재 환경에 Mux가 적합한지 판단하려면 같은 노드에서 Mux를 끈 상태와 켠 상태를 각각 테스트해 웹페이지 첫 화면과 대용량 파일 다운로드를 비교하세요. 끈 상태의 평균이 94Mbps, 켠 상태가 61Mbps인데 웹페이지 체감 차이가 작다면 끈 상태를 유지하는 것이 좋습니다. 반대로 짧은 연결이 많은 페이지의 첫 화면 표시 시간이 2.8초에서 1.7초로 줄고 대용량 파일 처리량이 크게 떨어지지 않는다면 유지할 수 있습니다.

• 단일 파일 다운로드가 느림: 먼저 Mux를 끈 상태와 비교하고, 시작 직후의 최고 속도만 보지 말고 지속 처리량을 관찰하세요.
• 웹페이지에 작은 리소스가 많음: 전체 로딩 시간을 기록하고 Mux를 켜기 전후의 첫 바이트 시간과 총 소요 시간을 비교하세요.
• 회선 패킷 손실이 뚜렷함: 먼저 노드 또는 경로 문제를 해결하세요. 다중화로 손실된 대역폭을 복구할 수는 없습니다.
• 프로토콜 변경을 고려 중: 구독에서 제공하고 서버 설정과 일치하는 VMess, VLESS 구성만 사용하세요. 클라이언트에서 인증과 전송 매개변수만 일방적으로 바꾸지 마세요.
• REALITY 구성: 서버 이름, 공개 키, 짧은 식별자와 흐름 제어 매개변수가 서로 일치해야 합니다. 연결에 성공했다고 해서 회선이 반드시 더 빠른 것은 아닙니다.

정해진 순서로 최종 원인 좁히기

점검의 목표는 순간적으로 가장 빠른 수치를 찾는 것이 아니라 병목이 어느 계층에 있는지 확인하는 것입니다. 노드 계층은 노드 간 차이를, 회선 계층은 시간대와 네트워크별 결과를, 로컬 계층은 기기 간 차이와 설정 매칭을 봅니다. 이 세 계층을 확인하면 대부분의 ‘연결은 되지만 속도가 느린’ 문제를 검증 가능한 범위로 좁힐 수 있습니다.

1. 원본 결과 기록

   현재 노드의 지연 시간과 처리량을 세 차례 기록하고 날짜, 시간대, 접속 네트워크와 프록시 모드를 함께 적어 막연한 체감에 의존하지 않도록 하세요.

2. 노드를 바꿔 가로 비교

   같은 네트워크에서 최소 세 개의 노드를 테스트하세요. 일부 노드만 느리다면 노드 부하, 출구 또는 구성 문제로 분류합니다.

3. 시간대를 바꿔 세로 비교

   같은 노드를 비피크 시간대와 20:00~23:00에 각각 테스트하세요. 여러 노드가 동시에 느려지면 회선 혼잡을 중점적으로 확인합니다.

4. 접속 네트워크 변경

   노드와 기기는 그대로 두고 네트워크만 바꾸세요. 네트워크에 따라 속도가 뚜렷하게 달라지면 기존 접속 회선과 라우팅 장비를 우선 확인합니다.

5. 로컬 설정 원상 복구

   10808 등의 실제 포트를 확인하고 라우팅을 단순화한 뒤 시스템 프록시와 TUN을 각각 테스트하고 Mux를 끈 상태와 비교하세요.

6. 안정적인 설정 유지

   세 차례 연속 측정에서 변동이 작은 조합을 선택하세요. 평균 80Mbps로 안정적인 설정이 최고 140Mbps, 최저 12Mbps로 크게 흔들리는 설정보다 일상 사용에 적합한 경우가 많습니다.

안드로이드에서도 같은 방법을 적용할 수 있습니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 먼저 구독 노드와 접속 네트워크를 동일하게 유지한 뒤 라우팅 모드, DNS와 로그를 각각 확인하세요. 코어마다 지원하는 구체적인 설정 기능이 다를 수 있으므로 가져오기에 성공한 뒤에도 프로토콜과 전송 매개변수가 올바르게 인식되었는지 확인해야 합니다.