V2Ray 속도 저하 원인 찾기: 노드·회선·로컬 설정 3단계 점검

“지연 시간은 정상인데 다운로드가 느리다”, “낮에는 되는데 밤에는 몇 Mbps밖에 안 나온다”, “같은 구독인데 컴퓨터에서는 빠르고 안드로이드에서는 느리다”는 모두 속도 문제처럼 보입니다. 하지만 실제 원인은 전혀 다른 구간에 있을 수 있습니다. 클라이언트에 표시되는 지연 시간만으로는 결론을 내릴 수 없습니다. 지연 시간은 보통 짧은 요청 한 번의 왕복 시간만 반영하며, 지속 전송 성능이나 노드의 외부 회선 대역폭, 회선 패킷 손실, 로컬 라우팅이 정상인지까지 직접 보여 주지 않기 때문입니다.

재현 가능한 속도 측정 기준선부터 만들기

점검 전에 노드 변경, DNS 수정, Mux 활성화, 라우팅 조정을 동시에 하지 마세요. 한 번에 네 가지 변수가 바뀌면 속도가 회복돼도 실제 원인을 알 수 없습니다. 먼저 직접 연결 속도, 프록시 속도, 측정 시각, 노드 이름, 클라이언트와 코어 버전을 기록하고 같은 기기·같은 네트워크·같은 측정 대상에서 반복 테스트하세요.

완전한 요청은 ‘노드’에서 웹사이트로 바로 이동하지 않습니다. 애플리케이션, 시스템 프록시, 로컬 코어, 접속 회선, 원격 노드, 대상 사이트를 차례로 거칩니다. 어느 한 구간에서 대기, 패킷 손실 또는 잘못된 라우팅이 발생해도 최종적으로는 로딩 지연으로 나타납니다.

위 숫자는 점검 기록의 예시일 뿐 속도 기준이 아닙니다. 중요한 것은 비교 가능한 데이터를 남기는 것입니다. 세 번 연속 측정한 뒤明显하게 튀는 한 번을 제외하고 나머지 두 번의 범위를 기록하세요. 첫 번째가 92 Mbps, 두 번째가 89 Mbps, 세 번째가 갑자기 8 Mbps라면 곧바로 노드가 속도를 제한한다고 단정하기보다 일시적인 패킷 손실이나 측정 대상의 변동을 먼저 의심해야 합니다.

1. 동기화, 다운로드 또는 업로드 중인 프로그램을 종료하고 다른 기기가 가정 네트워크를 모두 사용하고 있지 않은지 확인하세요.
2. 먼저 시스템 프록시를 끄고 직접 연결을 측정한 다음, 같은 노드를 활성화해 프록시 테스트를 진행하세요.
3. 연결 방식을 고정하세요. 직접 연결은 유선으로 테스트하고 프록시 테스트는 신호가 약한 무선 네트워크로 진행하는 식으로 조건을 바꾸면 안 됩니다.
4. 클라이언트 지연 시간만 기록하지 말고 첫 바이트까지의 대기 시간, 지속 다운로드 속도, 저녁 혼잡 시간대의 상태를 함께 기록하세요.
5. 매번 설정 하나만 변경하고, 변경 후에는 코어를 재시작하거나 다시 연결해 기존 연결이 계속 재사용되지 않게 하세요.

1단계: 노드 부하와 프로토콜 오버헤드 확인

노드 단계에서는 두 가지를 확인해야 합니다. 원격 서버가 과부하 상태인지, 현재 노드 설정에 불필요한 오버헤드가 있는지입니다. 지연 시간이 짧다고 대역폭이 충분한 것은 아닙니다. 서버는 80ms 안에 탐색 요청에 응답하면서도 CPU, 외부 회선 대역폭 또는 동시 연결 수가 한계에 도달해 지속 처리량은 매우 낮을 수 있습니다.

가장 효과적인 비교 방법은 지연 시간을 열 번 연속 측정하는 것이 아닙니다. 같은 구독에서 지역이 비슷하고 프로토콜 매개변수가 명확한 노드 두 개를 골라 5분 안에 같은 작업을 각각 수행하세요. A 노드가 75 Mbps로 안정적인데 B 노드가 9 Mbps에 그치고 두 노드 모두 같은 기기와 로컬 네트워크를 거쳤다면 B 노드의 부하나 외부 회선 품질을 더 의심할 수 있습니다.

VMess와 VLESS는 모두 연결 설정의 일부일 뿐이며, 실제 오버헤드는 전송 계층, 암호화, TLS, 패킷 크기, 회선 품질에 따라서도 달라집니다. 프로토콜 이름이 ‘더 최신’처럼 보인다고 반드시 더 빠르다고 가정하지 마세요. 프로토콜 이름만 비교하기보다 설정이 정확한지, 서버가 지원하는지, 연결이 안정적인지를 확인하는 것이 중요합니다. 구독 노드는 제공자가 안내한 전체 매개변수로 가져오고, 보안 설정을 임의로 삭제하거나 다른 노드의 포트와 전송 매개변수를 섞지 마세요.

• 먼저 구독을 업데이트해 전체 설정을 받은 뒤, 현재 선택한 노드를 테스트하고 있는지, 이전 그룹에 있던 같은 이름의 노드를 테스트하는 것은 아닌지 확인하세요.
• 테스트 중에는 전송 매개변수를 동일하게 유지하고 노드만 바꾸세요. 노드 차이와 프로토콜 차이가 섞이지 않도록 해야 합니다.
• 대용량 작업만 느리다면 단일 연결 작업과 다중 연결 작업을 각각 테스트해 단일 연결 병목이明显하게 나타나는지 확인하세요.
• 노드 연결 직후에는 빠르다가 몇 분 후 느려진다면 코어 로그의 시각을 기록하고 서버가 자주 연결을 끊었다가 다시 연결하는지 확인하세요.

2단계: 네트워크 간 회선과 혼잡 시간대 파악

여러 노드가 동시에 느려졌다가 다음 날 아침 회복된다면 회선 문제에 가까운 경우가 많습니다. 네트워크 간 전송은 여러 라우터를 거치므로 저녁 혼잡 시간대에 대기, 지터, 패킷 손실이 발생할 수 있습니다. 이때 클라이언트에 ‘연결됨’으로 표시되는 것은 정상입니다. 연결 자체는 유지되지만 각 패킷이 도착하는 데 더 오래 걸리고, 손실된 데이터는 다시 전송되기 때문입니다.

회선 단계에서는 시간대별 비교가 중요합니다. 08:00, 14:00, 21:30에 같은 노드로 테스트하고 지연 시간, 1분간 연속 다운로드의 평균 속도,明显한 변동 여부를 기록하세요. 예를 들어 아침 91 Mbps, 오후 84 Mbps, 밤 18 Mbps라는 기록은 단순히 ‘노드가 18 Mbps밖에 안 나온다’는 설명보다 문제를 훨씬 잘 보여 줍니다.

서로 다른 지역의 노드가 모두 밤에 느려지지만 하락 폭이 다르다면 지리적으로 가장 가까운 곳만 고르기보다 라우팅이 안정적인 지역을 우선 선택하세요. 거리는 이론적인 지연 시간에는 영향을 주지만 실제 경로가 반드시 더 짧다는 뜻은 아닙니다. 통신사 간 연동, 노드 접속망, 중간 라우팅의 변화로 더 먼 노드가 더 안정적인 처리량을 제공할 수도 있습니다.

현상으로 지연 시간·지터·패킷 손실 구분하기

• 지연 시간 증가: 페이지의 첫 응답이 느려지지만 안정적으로 다운로드가 시작되면 속도는 허용 가능한 수준일 수 있습니다.
• 지터가 큼: 속도 곡선이 크게 오르내리며 음성 통화, 실시간 요청, 짧은 연결에서 끊김이 더 뚜렷하게 느껴집니다.
• 패킷 손실에 따른 재전송: 다운로드 속도 그래프가 톱니처럼 나타나고 로그에 시간 초과, 연결 재설정 또는 컨텍스트 취소가 함께 기록될 수 있습니다.
• 경로 혼잡: 특정 시간대에 집중적으로 발생하며 같은 지역의 다른 노드로 바꿔도 개선되지 않을 수 있고, 회선 방향을 바꾸면 나아질 수 있습니다.

3단계: Mux·DNS·라우팅 분할 점검

같은 노드가 다른 기기에서는 정상 속도를 낸다면 로컬 설정을 중점적으로 확인해야 합니다. v2rayN, v2rayNG, v2flyNG는 모두 애플리케이션 트래픽을 로컬 코어로 전달하지만 시스템 프록시 모드, VPN 모드, 라우팅 규칙, DNS 경로는 서로 다를 수 있습니다. 구독을 복사했다고 해서 두 기기의 최종 외부 연결 경로까지 완전히 같아지는 것은 아닙니다.

먼저 리스닝 포트를 확인하세요. 로컬 혼합 포트 10808을 예로 들면 브라우저나 시스템 프록시는 현재 클라이언트가 실제로 수신 중인 주소와 포트를 가리켜야 합니다. 이전 도구가 여전히 10808을 사용하면 클라이언트가 다른 포트로 전환되거나 코어가 시작되지 않을 수 있습니다. v2rayN에서는 「설정」→「매개변수 설정」에서 로컬 리스닝 설정을 확인하세요. 수정 후 저장하고 코어를 재시작한 다음 시스템 프록시가 같은 주소와 포트를 가리키는지 확인합니다.

Mux를 기본적으로 속도 향상 기능으로 보면 안 됩니다

Mux는 여러 논리 요청이 하나의 연결을 재사용하도록 해 반복적인 핸드셰이크를 줄일 수 있습니다. 하지만 패킷 손실이 뚜렷하거나 단일 연결이 제한된 환경에서는 여러 요청이 서로 기다리게 만들 수도 있습니다. 점검할 때는 엄격하게 비교하세요. 노드, 시간, 측정 대상을 고정하고 Mux를 끈 뒤 완전히 연결을 끊었다가 다시 연결해 세 번 측정합니다. 평균 속도가 24 Mbps에서 57 Mbps로 오르고 변동도 줄었다면 현재 회선에는 기존 재사용 설정이 맞지 않는 것입니다. 차이가 2~5%에 불과하다면 주요 원인으로 보지 않아야 합니다.

라우팅 규칙 때문에 ‘일부 웹사이트만 느린’ 현상이 생길 수 있습니다

라우팅 분할은 도메인, 주소 범위 또는 규칙 집합에 따라 직접 연결과 프록시 외부 연결을 선택합니다. 규칙 순서가 잘못되면 같은 페이지의 본문 문서는 프록시를 거치는데 이미지나 동영상 도메인은 직접 연결될 수 있습니다. 반대로 직접 연결해야 할 로컬 서비스를 원격 노드로 우회할 수도 있습니다. 그 결과 홈페이지는 열리지만 리소스 로딩이 오래 걸리거나 특정 사이트만 느려집니다.

1. 클라이언트가 제공하는 기본 프록시 모드로 임시 전환하고 문제가 사라지는지 기록하세요.
2. 기본 모드에서 속도가 회복된다면 사용자 지정 규칙을 그룹별로 활성화하세요. 복잡한 설정 전체를 한 번에 복원하지 마세요.
3. 도메인 규칙이 앞에 있는 포괄적인 규칙에 먼저 걸리는지 확인하세요. 특히 하나의 서비스가 여러 리소스 도메인을 사용하는 경우에 주의해야 합니다.
4. 라우팅을 수정한 뒤 설정을 다시 불러오고 테스트 페이지도 새로 여세요. 이전 연결이 기존 외부 연결 경로를 계속 사용하지 않게 해야 합니다.

DNS 지연과 전송 지연은 체감이 다릅니다

DNS 이상은 클릭한 뒤 오랫동안 아무 반응이 없는 형태로 나타나는 경우가 많습니다. 하지만 페이지 로딩이 시작되면 이후 속도는 괜찮을 수 있습니다. 지속 전송 병목은 다운로드가 이미 시작됐는데도 계속 낮은 속도를 유지하는 형태입니다. 테스트할 때 처음 열 때와 새로고침했을 때의 차이를 비교하고, 코어 로그에서 도메인 확인, 연결 수립, 시간 초과가 어떤 순서로 발생하는지 확인하세요.

코어 로그로 실제 속도 문제와 착시 구분

일부 ‘속도 저하’는 연결이 반복해서 실패한 뒤 재시도하는 현상일 수 있습니다. 페이지가 결국 열리면 단순히 대역폭이 부족하다고 생각하기 쉽지만, 로그에는 DNS 확인 실패, 연결 시간 초과, 원격 재설정 또는 로컬 포트 충돌이 나타날 수 있습니다. 점검할 때는 먼저 속도 측정을 시작한 정확한 시각을 적고, 같은 1분 안에 기록된 오류를 확인해 이전 로그가 판단을 방해하지 않도록 하세요.

오류 한 번만으로 대역폭 문제라고 단정할 수는 없습니다. 예를 들어 노드 전환 중 context canceled가 한 번 발생하는 것은 설명 가능한 상황입니다. 몇 초마다 반복되고 속도가 0으로 떨어진다면 직전 연결 실패 기록을 계속 추적해야 합니다. 로그는 영어 오류가 보였다는 이유만으로 모든 설정을 즉시 바꾸지 말고 발생 빈도, 영향을 받는 노드 범위, 시간 패턴을 함께 분석해야 합니다.

• 노드 하나에서만 계속 시간 초과가 발생한다면 노드 매개변수, 상태, 원격 부하를 우선 확인하세요.
• 같은 네트워크의 모든 노드에서 시간 초과가 발생한다면 회선, 로컬 DNS, 방화벽, 리스닝 포트를 확인하세요.
• 컴퓨터에서는 정상인데 안드로이드에서 반복적으로 끊긴다면 v2rayNG 또는 v2flyNG의 백그라운드 실행 제한과 VPN 권한 상태를 확인하세요.
• 구독을 업데이트한 뒤 느려졌다면 현재 선택한 노드, 라우팅 그룹, 사용자 지정 매개변수에 이전 값이 남아 있지 않은지 확인하세요.

자주 묻는 속도 측정 질문과 최종 판단

3단계 비교를 마치면 문제를 ‘단일 노드 이상’, ‘특정 시간대의 회선 혼잡’, ‘한 기기에서만 발생하는 로컬 설정’ 중 하나로 분류할 수 있어야 합니다. 여전히 판단하기 어렵다면 최적화 매개변수를 계속 추가하지 말고 가장 단순한 작동 설정으로 돌아가세요. 연결이 확인된 노드 하나, 기본 라우팅, 기본 DNS 경로, Mux를 끈 상태로 비교하면 됩니다.

실행 가능한 최종 점검 목록

1. 직접 연결 속도가 정상인지 확인한 뒤 프록시 점검을 시작하세요.
2. 같은 지역에서 최소 두 노드를 비교하고 한 번의 지연 시간 측정으로 지속 속도를 대신하지 마세요.
3. 아침·저녁 시간대의 데이터를 기록하세요. 특정 시간대에 집중적으로 하락하면 회선 단계의 문제로 분류합니다.
4. 한 기기에서만 문제가 발생하면 10808과 같은 실제 리스닝 포트와 시스템 프록시를 확인하세요.
5. 경험에 따라 Mux를 켜고 끄지 말고 완전히 끈 상태로 한 번 비교하세요.
6. 기본 라우팅을 복원한 뒤 우회 경로를 만드는 라우팅 규칙을 그룹별로 찾아내세요.
7. 속도 측정 시각에 맞춰 코어 로그를 확인하고 낮은 대역폭과 반복 연결을 구분하세요.
8. 매번 항목 하나만 바꾸고 코어를 재시작한 뒤 새로운 측정 데이터를 저장하세요.

속도 문제를 점검할 때 핵심은 ‘가장 빠른 설정’을 찾는 것이 아니라 원인과 결과의 관계를 세우는 것입니다. 한 노드만 느리다면 노드를 처리하고, 여러 노드가 특정 시간대에 함께 느려진다면 회선을 관찰하며, 한 기기에서만 느리다면 포트·Mux·DNS·라우팅·백그라운드 정책을 다시 확인하세요. 이 단계별 테스트를 마친 뒤 구독 업데이트, 노드 전환, 클라이언트 조정 여부를 결정하는 편이 무작정 설정을 계속 바꾸는 것보다 대개 빠릅니다.