V2Ray 속도 느림 해결: 노드·회선·로컬 설정 점검

첫 화면 지연, 낮은 처리량, 간헐적 끊김 구분하기

‘속도가 느리다’는 말에는 최소 세 가지 상황이 있습니다. 웹페이지를 열고 콘텐츠가 뜰 때까지 오래 걸리는 경우, 페이지는 열리지만 다운로드가 계속 느린 경우, 처음에는 정상이다가 중간에 멈추는 경우입니다. 각각 DNS 조회와 연결 설정, 가용 대역폭, 연결 안정성 문제일 수 있습니다. 클라이언트에 표시되는 지연 시간은 보통 특정 탐지 과정만 측정하므로 실제 웹페이지 접속이나 지속 다운로드 테스트를 대신할 수 없습니다.

시스템 업데이트, 클라우드 업로드, 다른 다운로드를 먼저 일시 중지하세요. 같은 기기에서 평소 방문하는 HTTPS 페이지와 테스트를 지속할 만큼 용량이 충분한 고정 파일 하나를 선택합니다. 노드, 브라우저, 테스트 대상을 동시에 바꾸면 어떤 변경이 영향을 줬는지 파악하기 어렵습니다.

이 수치는 테스트 방법을 정하기 위한 기준이며, 이 사이트에서 측정한 결과나 성능 보장이 아닙니다. 파일이 너무 작으면 테스트가 일찍 끝나 지속 처리량을 확인할 수 없습니다. 데이터 요금제가 제한적이라면 관찰 시간을 줄이고 모든 그룹에서 동일하게 적용하세요. 다운로드 도구의 MB/s와 통신사의 Mbps는 단위가 다릅니다. 이론상 1 MB/s는 8 Mbps이며, 실제 전송에는 프로토콜 오버헤드도 발생합니다.

• 첫 화면이 늦게 뜸: DNS 조회, 연결 설정, 첫 바이트까지 걸린 시간을 기록하고 처음 접속할 때만 느린지 확인하세요.
• 지속 처리량이 낮음: 안정적으로 전송되는 구간의 데이터량을 확인하고 시작 순간의 최고 속도를 결과로 간주하지 마세요.
• 간헐적으로 끊김: 끊긴 시각, 화면 꺼짐 여부, 네트워크 전환 여부, 당시 커널 로그를 기록하세요.

1단계: 노드 부하와 출구 경로 비교

노드 이름에 표시된 지역만으로 전체 회선 경로를 알 수는 없습니다. 같은 지역으로 표시된 두 노드도 데이터센터, 진입점, 출구가 다를 수 있고 이름이 다른 노드가 같은 진입점을 공유할 수도 있습니다. 구독을 갱신해도 설정만 새로고침될 뿐 서버 대역폭이 늘어나지는 않습니다. 같은 네트워크와 비슷한 시간대에 동일한 대상을 이용해 사용 가능한 노드 두 개를 비교하세요.

v2rayN에서는 서버 목록에서 노드를 선택한 뒤 마우스 오른쪽 버튼 메뉴의 속도 테스트 기능으로 먼저 확인할 수 있습니다. 메뉴 이름은 버전에 따라 다를 수 있습니다. v2rayNG에서는 기본 목록에서 노드를 선택하고 연결을 다시 설정한 다음 같은 앱에서 테스트하세요. 내장 테스트와 실제 접속은 테스트 대상이나 동시 연결 수 등이 다를 수 있으므로 실제 사용 환경에서 다시 확인하는 것이 좋습니다.

서버를 관리할 수 있다면 같은 시간대의 CPU, 대역폭 사용량, 연결 수를 확인하세요. 서버를 관리할 수 없다면 ‘노드 측 병목으로 추정’이라고 기록하고 클라이언트 속도만으로 서버가 과판매됐다고 단정하지 마세요. 시간대별 결과는 참고 자료일 뿐, 동일한 조건에서의 비교를 대신하지 못합니다.

2단계: 접속 네트워크와 통신사 간 경로를 따로 확인

노드와 테스트 대상을 그대로 둔 채 안드로이드 기기를 Wi-Fi에서 모바일 데이터로 전환하고 v2rayNG에 다시 연결한 다음 테스트를 진행하세요. 네트워크를 바꾸면 기존 연결이 끊기므로 이전 페이지의 캐시나 기존 다운로드 작업은 새 네트워크의 결과로 볼 수 없습니다. 데스크톱에서는 모바일 핫스팟으로 비교할 수 있지만, 핫스팟 신호와 데이터 요금제 제한도 고려해야 합니다.

Wi-Fi에서만 느리다면 먼저 라우터 가까이에서 테스트하고 5GHz와 2.4GHz 대역을 비교하세요. 거리가 멀거나 벽이 많으면 5GHz가 더 불안정할 수도 있습니다. 같은 Wi-Fi에서 프록시를 사용하지 않는 서비스도 느리다면 프록시 커널을 계속 조정하기보다 무선 간섭, 라우터 부하, 광대역 업로드 포화 여부를 먼저 확인하세요.

1. 기본 게이트웨이를 로컬 네트워크 탐지 대상으로 삼아 기기와 라우터 사이의 연결이 안정적인지 먼저 확인하세요.
2. Windows에서 ping -n 30을 실행하고 뒤에 실제 게이트웨이 주소를 입력하세요. 이어서 같은 방식으로 탐지가 허용된 노드 주소도 테스트합니다.
3. 지속적인 패킷 손실이나 큰 지터가 있는지 비교하는 동시에 실제 HTTPS 요청도 실행하세요. 탐지 패킷만으로 결론 내리지 마세요.
4. 같은 노드가 네트워크를 바꾼 뒤 반복해서 정상으로 돌아온다면 접속 네트워크나 통신사에서 진입점까지의 경로를 중점적으로 확인하세요.

저녁 시간대에 느려졌다가 새벽에 회복된다면 혼잡 여부를 확인할 필요가 있지만, 대상 사이트의 부하가 달라졌을 수도 있습니다. 테스트 대상 두 곳의 결과를 함께 기록하세요. 한 번의 속도 테스트만으로 MTU를 바꾸지 마세요. 특정 네트워크에서 연결 설정은 성공하지만 큰 데이터 전송이 반복해서 멈추는 등 재현 가능한 현상이 있을 때 경로 MTU와 터널 캡슐화를 추가로 확인하세요.

3단계: 프로토콜, 전송 방식, 서버 설정 확인

VMess와 VLESS는 프록시 프로토콜 이름이며, TCP, WebSocket, gRPC는 서로 다른 계층의 전송 방식입니다. TLS는 보안 전송을 담당합니다. 이 이름들을 하나의 속도 순위표처럼 비교해서는 안 됩니다. 실제 성능은 서버 구현, 네트워크 경로, 대상 사이트, 기기 성능에 따라 달라지므로 프로토콜 이름만으로 처리량을 보장할 수 없습니다.

v2rayNG는 Xray 커널을, v2flyNG는 V2Fly 커널을 사용하며 지원하는 필드와 기능이 다를 수 있습니다. v2rayN의 성능도 선택한 커널과 설정에 따라 달라집니다. 클라이언트를 바꾸는 일은 노드 주소 하나만 옮기는 것으로 끝나지 않습니다. 해당 커널이 구독에 포함된 프로토콜과 전송 조합을 지원하는지 확인하세요.

• 먼저 노드 정보 확인: 주소, 포트, 사용자 식별자, TLS 활성화 여부가 서버 설정과 일치해야 합니다. 포트가 443이라고 해서 TLS가 자동으로 활성화되는 것은 아닙니다.
• 다음으로 전송 설정 확인: WebSocket 경로와 Host, gRPC 서비스 이름, TLS 서버 이름 등은 서버에서 제공한 값에 맞게 입력하세요.
• 마지막으로 비교 테스트: 서버에서 다른 사용 가능한 진입점을 실제로 제공하는 경우에만 전송 방식을 비교하세요. 기존 노드의 WebSocket을 gRPC로 임의 변경하지 마세요.
• 기존 설정 보관: 설정을 내보낸 뒤 변경하고, 연결에 실패하면 즉시 원래대로 되돌리세요. 속도를 높이려고 인증서 검증을 끄지 마세요.

다중화도 모든 상황에 통하는 속도 향상 스위치는 아닙니다. 짧은 연결이 많은 경우 연결 설정을 반복하는 비용을 줄일 수 있지만, 일부 패킷 손실 환경이나 장시간 대용량 전송에서는 여러 요청이 하나의 하위 연결을 공유하면서 서로 영향을 줄 수 있습니다. 현재 커널과 프로토콜이 해당 설정을 지원한다면 다중화를 켠 경우와 끈 경우의 결과를 비교하세요. 동시 연결 수와 전송 방식을 동시에 변경하지 마세요.

4단계: 로컬 프록시, DNS, 분할 라우팅 설정 확인

Windows 시스템 프록시를 모든 프로그램이 따르는 것은 아닙니다. v2rayN 트레이 메뉴의 ‘시스템 프록시’에서 자동 설정을 선택할 수 있지만, 터미널은 여전히 직접 연결할 수 있습니다. 브라우저 확장 프로그램이 시스템 설정을 덮어쓸 수도 있습니다. 먼저 ‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 설정을 확인하세요. 버전에 따라 ‘기본 설정’이나 인바운드 관련 화면에 있을 수 있으니 실제 메뉴를 기준으로 확인합니다.

아래 명령은 Windows PowerShell에서 HTTP 프록시 진입점을 명시해 ‘프로그램이 시스템 프록시를 사용하지 않음’이라는 변수를 제외합니다. 먼저 로컬 리스닝 포트가 10809인지 확인한 뒤 명령을 복사하세요. 실제 포트가 다르면 명령을 수정해야 합니다. 10809는 예시일 뿐, 모든 v2rayN 설치 환경의 기본값은 아닙니다.

curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download} speed=%{speed_download}B/s\n" https://v2rayultra.com/

이 명령은 프록시 진입점을 확인하고 요청 단계별 시간을 살펴보기 위한 것이며 지속 처리량 테스트용이 아닙니다. time_connect는 여기서 주로 로컬 프록시까지의 연결 시간을 나타냅니다. time_starttransfer에는 이후 터널과 핸드셰이크, 대상 서버의 응답 대기 시간도 포함되므로 이를 ‘노드 지연 시간’이라고 부를 수는 없습니다. 대용량 파일을 테스트할 때는 접근 권한이 있는 고정 다운로드 주소를 사용하세요. 30초 제한에 도달하면 요청이 자동으로 종료될 수 있으므로 이를 노드 연결 끊김으로 오해하지 마세요.

• 라우팅 확인: 시스템 프록시는 트래픽을 커널로 전달할 뿐, 이후 분할 라우팅에 따라 직접 연결될 수도 있습니다. 액세스 로그에서 테스트 대상이 실제로 어떤 출구를 사용했는지 확인하세요. ‘전체 연결’을 ‘모든 대상이 프록시를 사용함’으로 간주하지 마세요.
• DNS 확인: 처음 접속할 때 느리고 다시 접속하면 빨라지는 경우 DNS 조회 시간 초과가 있는지 확인하세요. DNS 주소를 한꺼번에 모두 바꾸지 마세요. 안드로이드의 ‘비공개 DNS’와 클라이언트 DNS 설정은 따로 확인하고, 하나씩 변경한 뒤 다시 테스트하세요.
• 안드로이드 앱별 설정 확인: v2rayNG의 ‘설정’ → ‘앱별 프록시’에서 테스트 앱이 프록시 대상에 포함됐는지 확인하세요. 버전에 따라 메뉴 문구가 다를 수 있으며, 현재 프록시 목록을 선택했는지 우회 목록을 선택했는지도 확인해야 합니다.
• 백그라운드 제한 확인: 안드로이드 시스템의 ‘설정’ → ‘앱’ → ‘v2rayNG’ → ‘배터리’에서 백그라운드 제한을 확인하세요. 화면을 잠근 뒤에만 연결이 끊긴다면 백그라운드 실행을 일시적으로 허용해 테스트한 후 배터리 소모와 비교하세요.
• 기기 부하 확인: 데스크톱에서는 작업 관리자를 확인하고, 안드로이드에서는 발열과 성능 저하 여부를 살펴보세요. TUN 모드, 다른 VPN 서비스, 프록시 도구를 동시에 반복 전환하면 라우팅 변화가 문제를 가릴 수 있으므로 피하세요.

로그의 시간 초과·연결 재설정과 속도 저하의 관계

상세 로그는 짧은 시간 동안 문제를 확인할 때만 사용하세요. 요청이 발생한 시각을 기록한 뒤 같은 시간대와 대상의 로그를 찾습니다. 단일 오류는 백그라운드 앱의 요청 실패일 수도 있습니다. 로그 수준을 계속 지나치게 상세하게 설정하면 저장 공간과 처리 부하가 늘어날 수 있으니 점검이 끝나면 평소 수준으로 되돌리세요. 로그를 공유하기 전에 구독 주소, 사용자 식별자, 서버 정보를 숨기세요.

오류의 전체 문구는 운영체제와 커널 버전에 따라 다를 수 있습니다. 로그에 해당 요청이 전혀 없다면 원격 노드 설정을 계속 바꾸기보다 앱이 프록시를 통과하는지 먼저 확인하세요. 요청이 예상한 출구로 전달됐는데 전송이 계속 멈춘다면 앞서 기록한 노드·네트워크 비교 결과와 로그를 함께 분석하세요.

자주 묻는 질문과 점검을 마치는 기준

재현 가능한 차이를 찾아냈다면 점검을 마쳐도 됩니다. ‘시간, 접속 네트워크, 노드, 대상, 프록시 모드, 3회 측정 결과, 로그 일부’를 기록하세요. 더 낮아 보이는 지연 시간만 계속 추구할 필요는 없습니다. 추가 지원을 요청할 때 이 기록이 있으면 ‘모든 노드가 끊긴다’는 설명보다 문제를 파악하기 쉽습니다.

1. 프록시를 사용하지 않아도 느림: 접속 네트워크와 기기 부하부터 확인하세요.
2. 특정 노드 하나만 느림: 정상 작동하는 노드를 유지하고 비교 기록을 서비스 제공자에게 전달하세요.
3. 네트워크를 바꾸자 회복됨: 무선 연결, 통신사 경로, 공유 진입점을 중점적으로 확인하세요.
4. 프록시를 명시하면 정상인데 앱에서만 문제: 시스템 프록시, 앱별 프록시, 라우팅 규칙을 다시 확인하세요.
5. 특정 전송 설정에서만 실패: 성능을 따지기 전에 서버 설정과 커널 호환성을 확인하세요.