연결은 되지만 웹페이지가 처음 열릴 때 느리거나, 동영상이 버퍼링되거나, 다운로드 속도가 떨어지는 경우에 적합합니다. 먼저 테스트 대상과 조건을 고정한 뒤 노드, 접속 네트워크, 클라이언트 설정을 비교하세요. 한 번에 한 항목만 변경하면 노드 출구의 혼잡, 경로 품질 저하, 로컬 프록시 미적용을 구분할 수 있습니다. 지연 시간이 짧다고 처리량도 높은 것은 아니며, 비교할 기록 없이 프로토콜만 반복해서 바꾸는 일도 피할 수 있습니다.
먼저 ‘느리다’의 의미부터 확인: 연결 대기, 첫 바이트, 지속 다운로드
먼저 설정을 바꾸지 마세요. 웹페이지가 오래 로딩되다가 열린 뒤에는 원활한 경우와 다운로드가 빠르게 시작한 뒤 계속 느린 경우는 원인이 다릅니다. 전자는 도메인 이름 확인, 프록시 핸드셰이크, 대상 사이트의 응답을 살펴봐야 합니다. 후자는 지속 처리량, 혼잡, 기기 부하를 비교하는 편이 중요합니다. 특정 사이트만 느리다면 먼저 해당 사이트의 속도 제한, 계정 정책, 콘텐츠 전송 노드 차이도 확인하세요.
| 증상 | 우선 확인할 항목 | 첫 번째 조치 |
|---|---|---|
| 페이지가 열리기까지 오래 걸림 | 이름 확인, 핸드셰이크, 첫 바이트까지 걸린 시간 | 같은 노드에서 같은 URL을 반복 방문해 첫 요청과 이후 요청 비교 |
| 다운로드 속도가 계속 낮음 | 노드 대역폭, 경로 혼잡, 대상 서버의 속도 제한 | 파일과 동시 연결 수를 고정하고 다른 노드로 다시 측정 |
| 속도가 오르내리거나 멈춤 | 무선 간섭, 패킷 손실, 백그라운드 연결 끊김 | 노드를 고정하고 유선 네트워크나 모바일 핫스팟으로 전환 |
| 특정 앱만 느림 | 프록시 진입 경로, 앱별 설정, 앱 자체의 프로토콜 | 해당 앱의 트래픽이 실제로 프록시 코어를 통과하는지 확인 |
단위를 통일한 뒤 비교하세요. 통신사 대역폭은 보통 Mbps로 표시하고 다운로드 프로그램은 MB/s로 표시할 수 있습니다. 이론상 100 Mbps는 약 12.5 MB/s이며, 실제 속도에서는 프로토콜 오버헤드를 빼야 합니다. 지연 시간은 밀리초 단위로 대기 시간을 나타낼 뿐 초당 전송량을 뜻하지 않습니다. 노드 목록에서 지연 시간이 수십 밀리초로 나와도 서버 출구에 충분한 대역폭이 남아 있다는 의미는 아닙니다.
비교 기준 만들기: 같은 대상, 단일 작업, 3회 측정
테스트가 허용되고 크기가 충분한 파일 하나를 정한 다음 동기화 드라이브, 업데이트 다운로드, 다른 속도 측정 작업을 종료하세요. 클라이언트 버전, 사용 중인 코어 버전, 노드 라벨, 접속 네트워크, 측정 시간을 기록합니다. 노드 라벨은 개인 기록에만 사용하고 구독 URL, 사용자 식별 정보, 전체 연결 링크를 공개 문의에 붙이지 마세요.
이 수치는 테스트 방법의 예시이며 이 사이트의 실측 결과가 아닙니다. 다음 네 가지 조건을 기록하세요. 기존 노드와 기존 네트워크, 다른 노드와 기존 네트워크, 기존 노드와 다른 네트워크, 그리고 가능하다면 다른 기기입니다. 테스트 대상과 다운로드 동시 연결 수는 동일하게 유지하세요. 브라우저의 단일 연결 다운로드와 다중 스레드 속도 측정 도구의 총속도를 직접 비교하지 마세요.
- 같은 시간대에 노드 A와 노드 B를 번갈아 측정하세요. 서로 다른 시간의 부하 변화를 노드 차이로 착각하지 않도록 합니다.
- 같은 기기를 다른 네트워크에 연결한 뒤 노드 A를 측정하세요. 모바일 핫스팟은 통신사와 무선 환경이 달라지므로 접속 경로 전체가 바뀐 결과로 봐야 합니다.
- 기존 네트워크에서 기기를 바꾸되, 가능하면 같은 노드와 코어 설정을 유지해 문제가 기기를 따라가는지 확인하세요.
- 저녁에만 느리고 낮에는 정상이라면 두 시간대에 같은 방법으로 측정하세요. 한 번의 결과만으로 서버의 속도 제한이라고 단정하지 마세요.
1단계: 노드 부하와 출구 제한
로컬 네트워크를 고정한 상태에서 먼저 노드를 바꾸세요. 프로토콜부터 바꿀 필요는 없습니다. 노드 A가 여러 대상에서 계속 느리고 같은 시간대에 노드 B는 정상 속도를 회복한다면 A에 연결된 서버, 출구 또는 경로 쪽 문제일 가능성이 큽니다. 클라이언트에서는 서버의 실제 CPU 사용률, 공유 대역폭, 사용자별 속도 제한을 보통 확인할 수 없습니다. 따라서 ‘노드 부하가 높다’는 것은 검증이 필요한 추정이지, 속도 측정 결과에서 직접 확인되는 값이 아닙니다.
- 서로 다른 출구 비교: 같은 지역의 두 노드가 같은 서버나 상위 회선을 공유할 수 있습니다. 공통 병목을 줄이려면 출구가 다르다고 확인된 노드를 우선 선택하세요.
- 서로 다른 대상 비교: 같은 노드에서 서로 다른 서비스 두 곳 모두 느리다면 노드와 경로를 점검하는 편이 좋습니다. 특정 대상만 느리다면 대상 측의 제한도 고려하세요.
- 사용량과 요금제 확인: 서비스 제공업체의 계정 페이지에서 트래픽 한도, 만료 여부, 속도 제한 정책을 확인하세요. 클라이언트에 연결됨으로 표시되어도 계정에 속도 제한이 걸리지 않았다는 뜻은 아닙니다.
- 단일 연결과 다중 연결 비교: 다중 연결의 총속도가 훨씬 높아도 동시 연결 수에 따라 결과가 달라졌다는 것만 알 수 있습니다. 단일 연결 제한, 왕복 지연 시간, 패킷 손실이 원인일 수도 있습니다.
VMess와 VLESS는 프록시 프로토콜이지 대역폭 등급이 아닙니다. 프로토콜을 바꾸면 서버, 전송 방식, TLS 설정도 함께 바뀌는 경우가 많으므로 속도 차이를 모두 프로토콜 탓으로 돌릴 수 없습니다. 노드에 특정 전송 방식이나 보안 설정이 필요하다면 서버 설정을 따르세요. 속도 측정을 위해 인증서 검증을 끄거나 전송 필드를 임의로 바꾸지 마세요.
결론: 먼저 노드를 바꾸고 로컬 설정은 유지
같은 네트워크와 같은 대상에서 다른 노드가 3회 연속 정상 속도를 회복한다면, 우선 사용할 수 있는 노드를 유지하고 비교 기록을 제출하세요. 이때 DNS, 라우팅, 시스템 네트워크 설정까지 한꺼번에 초기화할 필요는 없습니다.
2단계: 접속 네트워크, 패킷 손실, 네트워크 간 경로
같은 노드에서 네트워크를 바꾼 뒤 속도가 크게 개선되면 접속 네트워크나 해당 노드까지의 경로와 관련된 문제일 수 있습니다. 다만 가정 내 무선 간섭, 광대역 회선의 업로드 포화, 통신사 간 연결 혼잡 중 무엇인지는 아직 구분할 수 없습니다. 먼저 유선으로 연결하거나 라우터 가까이에서 신호가 안정적인 무선 네트워크를 사용하고, 백업 업로드를 멈춘 뒤 다시 측정하세요. 업로드가 포화되면 대기열이 길어져 웹페이지와 다운로드가 모두 느려질 수 있습니다.
Windows PowerShell에서 서버 포트의 TCP 연결 가능 여부를 확인할 수 있습니다. 아래는 명령어 형식의 예입니다. example.com은 예시 도메인이므로 실제 노드 서버 주소로 바꿔야 합니다. 443도 노드의 실제 포트로 바꾸세요. TLS에서 흔히 쓰는 포트가 모든 노드의 고정 포트인 것은 아닙니다.
Test-NetConnection -ComputerName example.com -Port 443 -InformationLevel DetailedTcpTestSucceeded가 참이면 이번 TCP 연결이 성공했다는 뜻일 뿐, 프록시 인증, TLS, 전송 경로, 대상 사이트 접속까지 성공했다는 의미는 아닙니다. 이 명령은 로컬 기기에서 서버 포트를 직접 확인하므로 UDP만 사용하는 서비스의 진단에도 적합하지 않습니다. 도메인이 CDN을 통해 연결된다면 실제로는 엣지 노드까지의 연결만 반영될 수도 있습니다.
- 포트 연결이 간헐적으로 실패함: 실제 주소와 포트를 확인하고 로컬 방화벽 알림을 살펴본 뒤 다른 네트워크에서도 비교하세요. 곧바로 서버 장애라고 단정하지 마세요.
- ping은 시간 초과지만 프록시는 정상: 서버나 중간 장비가 ICMP에 응답하지 않을 수 있습니다. ICMP 패킷 손실을 프록시 TCP 트래픽의 패킷 손실과 동일하게 볼 수는 없습니다.
- 경로 추적 중간 홉에서 패킷 손실: 이후 홉과 목적지는 정상이라면 중간 장비가 탐색 응답을 제한하는 경우일 수 있습니다. 이것만으로 실제 전달 과정에서 패킷이 손실된다고 볼 수는 없습니다.
- 혼잡 시간대에만 속도 저하: 같은 대상과 노드의 시간대별 측정 결과를 기록하세요. 클라이언트를 계속 재설치하기보다 경로가 다른 노드로 바꿔보세요.
3단계: 시스템 프록시, 라우팅, DNS가 예상대로 적용되는지 확인
시스템 프록시는 해당 설정을 따르는 앱에만 영향을 주며 기기의 모든 트래픽이 코어를 통과한다는 뜻은 아닙니다. v2rayN에서 먼저 ‘시스템 프록시’ → ‘시스템 프록시 자동 구성’을 확인한 다음, ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트를 확인하세요. 버전에 따라 메뉴 이름이나 위치가 달라질 수 있으니 현재 화면에 표시된 수신 설정을 기준으로 삼으세요. TUN 모드와 시스템 프록시는 서로 다른 연결 방식이므로 문제를 점검할 때는 진입 경로를 하나로 명확히 정해두세요.
로컬에 127.0.0.1:10808 SOCKS 인바운드 리스너가 있는 것을 확인했다면 Windows 터미널에서 아래처럼 명시적으로 프록시 요청을 보낼 수 있습니다. 해당 포트는 예시이므로 리스너 종류를 확인하지 않고 그대로 사용하지 마세요. HTTP 프록시 전용 포트는 SOCKS 포트로 사용할 수 없습니다. 예시 페이지는 작은 요청을 확인하기 위한 것으로, 대용량 파일의 처리량을 평가하는 용도가 아닙니다.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --write-out "connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/socks5h는 대상 도메인 처리를 SOCKS 프록시에 맡기지만, 최종적으로 어디서 이름을 확인하는지는 코어의 라우팅, DNS, 출구 설정에 따라 달라집니다. 여기서 time_connect는 주로 로컬 프록시 진입점에 연결하는 데 걸린 시간이며, 클라이언트와 원격 노드 사이의 실제 지연 시간이 아닙니다. 첫 바이트까지 걸린 시간에는 프록시 협상, 대상 연결, 대상 서버의 응답이 포함되므로 DNS 소요 시간만을 나타내지 않습니다.
| 설정 항목 | 확인 방법 | 결과 해석 |
|---|---|---|
| 프록시 진입점 | 명시적 SOCKS 요청과 브라우저 접속 비교 | SOCKS 요청은 정상인데 브라우저만 느리다면 브라우저 프록시와 확장 프로그램 설정을 확인하세요 |
| 라우팅 분기 | 클라이언트 라우팅 설정에서 규칙과 해당 출구를 확인 | 코어에 들어온 트래픽도 규칙에 따라 직접 연결되거나 다른 출구로 전달될 수 있습니다 |
| DNS | 현재 DNS 설정을 기록한 뒤 이름 확인 단계 하나만 바꿔 다시 측정 | 이름 확인은 첫 접속 시간과 대상 주소 선택에 영향을 주지만 출구 속도 제한을 자동으로 해제하지는 않습니다 |
| 기기 부하 | 작업 관리자에서 CPU, 네트워크, 백그라운드 업로드 확인 | CPU 코어 하나가 거의 최대치에 도달해도 전체 CPU 사용률은 높지 않을 수 있습니다 |
Android의 v2rayNG에서는 ‘설정’ → ‘앱별 프록시’에서 대상 앱이 예상한 프록시 범위에 포함되는지 확인하고 시스템 VPN 권한이 계속 유효한지도 점검하세요. 화면을 꺼둔 뒤에만 느려지거나 연결이 끊긴다면 시스템 ‘설정’ → ‘앱’ → ‘v2rayNG’ → ‘배터리’에서 백그라운드 활동을 허용하세요. 제조사마다 메뉴 이름은 다를 수 있습니다. 화면이 켜져 있을 때도 계속 느리다면 원인을 절전 설정 탓으로만 돌려서는 안 됩니다.
로그로 핸드셰이크 실패와 낮은 처리량 구분하기
로그는 요청이 어느 단계에서 실패했는지 파악하는 데 쓰이며 대역폭 측정기가 아닙니다. 재현된 시간을 먼저 기록하고 그 시간 전후의 관련 행만 확인하세요. v2rayN은 클라이언트 인터페이스이며 실제 오류는 실행 중인 코어에서 발생합니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용하므로 로그 표현이 다를 수 있습니다. 점검이 끝나면 평소 로그 수준으로 되돌려 상세 기록으로 인한 디스크 쓰기가 계속 늘지 않도록 하세요.
오류: context deadline exceeded
원인: 작업이 제한 시간을 초과한 상태입니다. 이름 확인, 연결 시도, 핸드셰이크 단계에서 발생할 수 있으며 이 한 줄만으로는 위치를 특정할 수 없습니다. 해결 방법: 주변 로그에서 대상과 작업 유형을 확인하고 주소와 포트를 점검한 다음, 같은 노드에서 네트워크를 바꿔 다시 발생하는지 확인하세요.
오류: connection refused
원인: 연결이 상대방에 의해 명시적으로 거부되었습니다. 대상 포트에서 수신 대기 중인 서비스가 없거나 잘못된 포트에 연결했을 때 흔히 발생합니다. 해결 방법: 로그에 표시된 주소가 로컬 인바운드인지 원격 서버인지 먼저 구분한 다음, 클라이언트 리스너나 노드 포트를 각각 확인하세요.
오류: x509: certificate has expired or is not yet valid
원인: 인증서 유효 기간과 현재 시간이 맞지 않습니다. 시스템 시간이 틀렸거나 서버 인증서에 문제가 있을 수 있습니다. 해결 방법: 시스템 자동 시간 동기화를 켜고 다시 시도하세요. 계속 실패하면 인증서 문제를 서비스 제공업체에 문의하고 검증을 끄지 마세요.
로그에서 요청 연결이 정상적으로 수립된 것으로 나오는데 다운로드 속도만 낮다면 노드와 경로 비교로 돌아가세요. 관련 없는 간헐적 경고를 이유로 설정을 반복해서 바꾸지 마세요. 로그를 공유하기 전에 구독 URL, 접속 자격 증명, 사용자 식별 정보, 불필요한 서버 정보를 가리고 시간, 오류 유형, 비식별 처리한 출구 라벨만 남기세요.
결론: 문제가 따라가는 항목부터 해당 계층을 점검
노드를 따라 문제가 발생하면 출구와 서버를 우선 확인하세요. 네트워크를 따라가면 접속 환경과 경로를, 기기나 앱을 따라가면 프록시 진입점, 라우팅 분기, 백그라운드 제한을 먼저 살펴보세요. 비교 결과는 원인 범위를 좁힐 뿐 서버 모니터링을 대신하지는 않습니다.
자주 묻는 질문: 낮은 지연 시간, 속도 측정 차이, 업데이트 후 속도 저하
노드 지연 시간은 50ms인데 다운로드는 왜 느린가요?
50ms는 특정 테스트에서 측정한 대기 시간일 뿐입니다. 테스트가 TCP 연결 수립만 측정했는지 실제 연결까지 확인했는지 먼저 살펴본 뒤, 같은 파일을 세 차례 연속 다운로드해 비교하세요. 지연 시간은 안정적인데 처리량이 낮다면 노드 출구, 대상의 속도 제한, 동시 연결 조건을 우선 확인하세요. 지연 시간만으로 노드를 정렬해 선택하지 마세요.
속도 측정은 빠른데 브라우저에서 웹페이지가 느리다면 무엇부터 바꿔야 하나요?
먼저 속도 측정을 멈추고 같은 브라우저에서 같은 URL을 반복해서 열어보세요. 브라우저가 시스템 프록시를 따르는지, 확장 프로그램이 프록시 설정을 덮어쓰는지 확인한 뒤 명시적 SOCKS 요청과 비교하세요. 속도 측정 서버와 대상 웹페이지는 전체 경로가 같지 않으므로 측정 결과가 빠르다고 웹페이지의 DNS, 핸드셰이크, 서버 응답까지 빠르다고 볼 수는 없습니다.
구독 정보를 업데이트한 뒤 속도가 느려졌는데 바로 재설치해야 하나요?
먼저 업데이트 전후의 서버 주소, 포트, 전송 방식, 보안 설정을 확인하고 현재 선택한 노드가 원래 의도한 노드인지 살펴보세요. 구독 업데이트는 주로 서버 설정을 바꾸며 라우팅은 별도로 관리되는 경우가 많습니다. 현재 버전과 설정 기록을 보존하고 다른 노드로 다시 측정하세요. 문제가 클라이언트 버전을 따라가는 것이 분명할 때만 버전별로 추가 비교를 진행하세요.
Android에서 화면이 켜져 있을 때는 정상인데 잠금 후 속도가 떨어지면 어떻게 하나요?
같은 노드를 유지한 채 화면이 켜져 있을 때와 잠겼을 때 각각 증상을 재현하세요. v2rayNG의 VPN 연결 상태를 확인하고 시스템 앱 배터리 설정에서 백그라운드 활동을 허용하세요. 모바일 데이터에서만 발생한다면 데이터 절약 모드와 백그라운드 데이터 권한도 확인하세요. 옵션을 한 번에 하나씩 바꾼 뒤 다시 측정하세요.
DNS를 바꾸면 다운로드 속도가 두 배로 빨라지나요?
항상 그렇다고 보장할 수는 없습니다. DNS는 이름 확인 대기 시간과 콘텐츠 전송 주소 선택에 영향을 줄 수 있지만, 이미 수립된 연결의 대역폭을 직접 높이지는 않습니다. 기존 설정을 기록하고 같은 노드에서 첫 접속과 지속 다운로드를 비교하세요. 첫 접속만 개선됐다면 그 범위에 한정해 결론을 내리고 출구 대역폭이 향상됐다고 해석하지 마세요.