연결은 되지만 로딩이 느리다면 연결 설정 시간이 긴지, 다운로드가 계속 느린지부터 구분하세요. 테스트 대상을 고정한 뒤 노드, 인터넷 연결, 로컬 설정을 차례로 비교합니다. 노드를 이미 가져온 v2rayN, v2rayNG, v2flyNG 사용자에게 적합한 안내입니다. 단계별 결과를 기록하면 문제 범위를 좁히고 회선 혼잡을 클라이언트 설정 문제로 오인하는 일을 줄일 수 있습니다.
먼저 기준 잡기: 지연 시간과 다운로드 속도는 다릅니다
TCPing 수치가 낮다는 것은 지정한 주소와 포트에 TCP 연결이 빠르게 설정된다는 뜻일 뿐입니다. 프록시 인증, TLS 핸드셰이크, 대상 웹사이트 접속까지 성공한다는 의미는 아닙니다. 실제 연결 속도 테스트는 보통 프록시를 통해 테스트 주소에 요청을 보내므로 실제 접속에 더 가깝지만, 테스트 주소와 제한 시간, 캐시의 영향을 받습니다. 따라서 동영상이나 파일 다운로드 속도로 그대로 환산할 수는 없습니다.
클라우드 드라이브 동기화, 시스템 업데이트, 다른 다운로드를 먼저 일시 중지하고 같은 대상 리소스로 비교하세요. 네트워크 유형, 노드, 테스트 시간, 오류 메시지를 기록합니다. 아래 수치는 권장 테스트 조건과 단위 환산 예시이며, 이 사이트에서 특정 노드를 측정한 결과가 아닙니다.
브라우저에 표시되는 MB/s와 요금제에 표시된 Mbps는 서로 다른 단위입니다. 또한 ‘첫 페이지가 뜨기까지 오래 걸리지만 로딩 후 다운로드는 정상’인 경우와 ‘연결은 빠르지만 다운로드 속도가 계속 낮은’ 경우를 구분해야 합니다. 전자는 DNS 조회, 핸드셰이크, 라우팅을 먼저 확인하고, 후자는 대역폭, 혼잡, 노드 출구를 먼저 확인하세요.
- 특정 웹사이트만 느린 경우: 다른 서비스 제공업체의 대상도 추가해 대상 서비스의 속도 제한, 지역별 정책, CDN 차이를 확인하세요.
- 프록시를 사용하는 모든 웹사이트가 느린 경우: 노드와 회선을 비교하세요. 먼저 DNS 설정 전체를 바꾸지는 마세요.
- 직접 연결도 느린 경우: 프록시 성능을 판단하기 전에 로컬 Wi-Fi, 인터넷 회선 사용량, 라우터부터 확인하세요.
첫 번째 단계: 비교 테스트로 노드 부하 확인
클라이언트 속도는 VMess나 VLESS 같은 프로토콜 이름만으로 결정되지 않습니다. 서버 CPU, 출구 대역폭, 동시 연결 수, 서비스 제공업체의 속도 제한 정책이 병목이 될 수 있습니다. 노드 이름에 표시된 지역이 실제 진입 회선을 뜻하는 것도 아닙니다. 이름이 다른 두 노드가 같은 진입 지점이나 출구를 공유할 수도 있습니다.
-
테스트 대상 고정
속도 측정을 허용하고 용량이 충분한 HTTPS 리소스를 하나 선택한 뒤 브라우저나 명령줄 도구를 고정해 사용하세요. 여러 속도 측정 작업을 동시에 실행하면 같은 연결의 대역폭을 나눠 쓰게 되므로 피하세요.
-
사용할 노드 선택
v2rayN 기본 화면의 서버 목록에서 노드를 선택하고 마우스 오른쪽 버튼을 눌러 ‘활성 서버로 설정’을 선택합니다. 실제 활성 항목이 바뀌었는지 확인한 뒤 접속하세요. 목록에서 행을 강조 표시하는 것만으로는 노드가 전환되지 않을 수 있습니다.
-
실제 연결 테스트
서버 목록에서 마우스 오른쪽 버튼을 눌러 ‘서버 실제 연결 지연 시간 테스트’를 선택하세요. 버전에 따라 메뉴 문구가 조금 다를 수 있습니다. TCP 연결만 확인하는 테스트가 아니라 실제 연결 테스트를 선택하고, 시간 초과와 성공 횟수를 기록하세요.
-
노드를 바꿔 비교
진입 지점이나 회선이 다른 노드로 바꾸고 네트워크, 대상, 도구는 그대로 둔 채 각각 3회 측정하세요. 우연한 한 번의 결과로 판단하지 않도록 다른 시간대에도 다시 테스트합니다.
같은 네트워크에서 특정 노드만 계속 느리고 다른 진입 지점은 정상이라면 해당 노드나 회선에 문제가 있을 가능성이 큽니다. 낮에는 정상이지만 저녁에 전반적으로 속도가 떨어진다면 시간대에 따른 혼잡으로 우선 판단할 수 있습니다. 다만 클라이언트 측 결과만으로는 서버 부하와 통신사 경로 중 어느 쪽이 원인인지 단정할 수 없습니다. 서버 모니터링이나 더 많은 회선 표본이 필요합니다.
두 번째 단계: 인터넷 연결과 원격 회선을 분리해 확인
노드는 그대로 둔 채 인터넷 연결만 바꾸는 것이 부담이 적은 확인 방법입니다. 예를 들어 컴퓨터를 집 Wi-Fi에서 휴대폰 핫스팟으로 바꾸거나, Android 기기에서 Wi-Fi와 모바일 네트워크를 비교할 수 있습니다. 모바일 네트워크 테스트는 데이터를 사용하므로 파일 크기와 테스트 시간을 제한하세요. 한 번에 네트워크만 바꾸고 노드와 DNS를 동시에 변경하지 마세요.
| 관찰 결과 | 우선 의심할 항목 | 다음 확인 단계 |
|---|---|---|
| 같은 노드가 핫스팟에서는 빠르고 집 네트워크에서는 느림 | 로컬 인터넷 연결 또는 통신사에서 진입 지점까지의 경로 | 컴퓨터를 유선으로 연결하고 다른 기기의 다운로드를 일시 중지한 뒤 기존 노드를 다시 테스트 |
| 같은 네트워크에서 모든 노드가 느림 | 로컬 대역폭, 공유 진입 지점, 테스트 대상 | 먼저 직접 연결 리소스를 테스트한 뒤 진입 지점과 대상을 바꿔 비교 |
| 저녁에만 다운로드 속도가 계속 떨어짐 | 경로 혼잡 또는 공유 출구의 경쟁 | 같은 대상을 여러 시간대에 테스트해 기록하고 다른 회선과 비교 |
| 특정 대상만 느림 | 대상 서비스, 출구에서 대상까지의 경로, CDN | 다른 대상으로 다시 테스트하고 노드 전체를 사용할 수 없다고 단정하지 않기 |
Windows에서는 ping -n 20, macOS에서는 ping -c 20으로 기본 게이트웨이를 테스트할 수 있습니다. 게이트웨이 주소는 현재 네트워크 정보에서 확인하세요. 로컬 게이트웨이에서도 패킷 손실이 자주 발생한다면 먼저 무선 신호와 기기 부하를 해결하세요. 원격 서버는 ICMP를 제한할 수 있으며, 경로 추적에서 특정 홉이 응답하지 않는다고 해서 실제 서비스 트래픽이 그 지점에서 손실된다는 뜻은 아닙니다.
- Wi-Fi를 사용한다면 먼저 액세스 포인트 가까이 이동하세요. 가능하면 유선 네트워크로 바꿔 무선 간섭을 배제합니다.
- 경로 추적 결과는 경로를 파악하기 위한 단서로만 활용하고 실제 HTTPS 요청 결과와 함께 판단하세요. 중간 홉의 패킷 손실률만으로 결론을 내리지 마세요.
- 일부 대용량 페이지나 장시간 연결만 멈춘다면 경로 MTU 문제 등을 고려할 수 있습니다. 근거 없이 네트워크 어댑터 설정을 일괄 변경하지 마세요.
세 번째 단계: 앱 트래픽이 실제로 프록시를 통과하는지 확인
시스템 프록시는 해당 설정을 따르는 앱에만 적용되며 모든 프로그램의 트래픽이 프록시를 통과한다고 보장하지 않습니다. Tun 모드는 가상 네트워크 인터페이스로 트래픽을 처리하지만 라우팅 규칙과 제외 규칙의 영향을 받습니다. 문제를 진단할 때 두 연결 방식을 섞어 비교하지 마세요. 먼저 현재 테스트에서 어떤 방식을 사용하는지 확인한 뒤 요청에 실제로 적용된 아웃바운드를 살펴보세요.
v2rayN에서 ‘설정’ → ‘매개변수 설정’으로 이동해 로컬 수신 설정을 확인하고, ‘설정’ → ‘라우팅 설정’에서 규칙을 살펴볼 수 있습니다. 메뉴 이름은 버전에 따라 다를 수 있으므로 현재 화면에 표시된 항목을 기준으로 확인하세요. 아래 예시는 로컬 SOCKS 수신 주소가 127.0.0.1:10808이라고 가정합니다. 명령어 예시일 뿐이므로 실행 전에 실제 포트로 바꿔야 합니다.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output /dev/null --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} bytes_per_second=%{speed_download}\n" https://example.com/아래 명령은 macOS 및 Linux 셸용입니다. Windows PowerShell에서는 curl.exe를 사용하고 /dev/null을 NUL로 바꾸세요. example.com은 요청 과정을 확인하기 위한 예시일 뿐이며 페이지가 너무 작아 지속 대역폭을 평가하는 데 사용할 수 없습니다. 다운로드 테스트에는 접근 권한이 있는 안정적인 대용량 파일 주소를 사용하세요.
socks5h는 대상 도메인의 조회를 로컬에서 curl이 처리하는 대신 프록시 서버로 넘깁니다. 최종적으로 어떤 DNS를 사용하는지는 코어 설정에 따라 달라집니다.- 여기서
time_connect는 주로 로컬 프록시 진입점에 연결하는 단계를 나타내며, 원격 서버와의 전체 핸드셰이크 시간은 아닙니다. 첫 바이트 수신 시간에는 대상 서버의 처리 시간도 포함됩니다. - 명시적 프록시 요청은 정상인데 브라우저만 느리다면 노드를 바로 바꾸지 말고 브라우저 자체의 프록시 설정, 확장 프로그램, 보안 DNS를 확인하세요.
- 문제 해결 중에는 클라이언트에서 제공하는 전역 프록시 라우팅을 임시로 적용해 비교할 수 있습니다. 테스트가 끝나면 기존 규칙으로 되돌리세요. ‘시스템 프록시 설정’과 ‘전역 프록시 라우팅’은 서로 다른 단계의 설정입니다.
전송 방식, Mux, DNS: 한 번에 하나씩 변경
전송 방식은 서버 설정과 맞아야 합니다. WebSocket, gRPC 및 코어에서 지원하는 다른 전송 방식에 네트워크 전반에 통용되는 속도 순위는 없습니다. 리버스 프록시, 연결 유지 정책, 경로 품질에 따라 결과가 달라질 수 있습니다. 서비스 제공업체가 제공한 유효한 설정끼리 비교하고, 속도 측정을 위해 하나의 노드에서 전송 유형만 임의로 바꾸지 마세요.
| 설정 항목 | 가능한 영향 | 확인 방법 |
|---|---|---|
| Mux 연결 다중화 | 여러 번 연결을 설정하는 데 드는 비용을 줄일 수 있지만, 여러 요청이 하위 연결의 패킷 손실에 함께 영향을 받을 수도 있습니다. | 현재 코어와 프로토콜의 지원 여부를 확인하고, 동시 연결 수를 무작정 늘리지 않은 채 Mux를 켜고 끈 상태로 각각 테스트하세요. |
| DNS 및 조회 경로 | DNS 조회 시간 초과로 첫 접속이 늦어질 수 있고, 반환되는 주소가 다르면 CDN 경로도 달라질 수 있습니다. | 노드를 그대로 둔 채 첫 방문과 재방문을 비교하고 조회 로그도 확인하세요. |
| 라우팅 규칙 순서 | 앞에서 먼저 일치한 규칙에 따라 대상 트래픽이 직접 연결되거나 다른 아웃바운드로 전송될 수 있습니다. | 대상 도메인, IP 조건, 아웃바운드 태그를 확인하고 로그에서 실제로 적용된 규칙을 살펴보세요. |
| 로컬 리소스 사용량 | 코어, 다른 프로그램, 보안 소프트웨어의 리소스 사용량이 지나치게 높으면 처리 성능이 제한될 수 있습니다. | 다운로드 중 CPU와 네트워크 사용량을 확인하고 다른 작업을 일시 중지한 뒤 다시 측정하세요. |
Mux는 대역폭을 합산하거나 단일 회선의 용량을 늘려 주는 기능이 아닙니다. 먼저 Mux를 끈 상태로 기준을 측정한 다음, 짧은 요청을 많이 보내는 경우와 대용량 파일 하나를 다운로드하는 경우를 각각 비교하세요. 일부 프로토콜, 전송 방식, 코어 조합에는 다중화 관련 제한이 있으므로 오래된 설정을 모든 노드에 그대로 적용하면 안 됩니다.
DNS는 주로 이름 조회와 첫 연결에 영향을 주며, 이미 연결된 대용량 파일 다운로드 속도를 갑자기 높여 주지는 않습니다. 다만 조회 결과가 바뀌면 실제로 접속하는 CDN 주소도 달라질 수 있으므로 완전히 무시할 수는 없습니다. DNS 서버를 바꾸기 전에 기존 설정을 기록하고, 아직 연결되지 않은 프록시에 DNS 서버가 의존하는지도 확인하세요. 서로 의존해 시간 초과가 발생할 수 있습니다.
로그 오류: 실패부터 해결한 뒤 속도 확인
아래는 로그에 표시될 수 있는 오류 일부입니다. 전체 접두사는 시스템과 코어에 따라 달라집니다. 오류는 문제 범위를 좁히는 데 도움이 되지만, 보통 그 자체만으로 특정 원인을 입증하지는 못합니다. 발생 시간과 당시 노드를 기록하세요. 로그를 공유하기 전에는 구독 주소, 인증 정보, 개인 네트워크 정보를 삭제하세요.
connection refused
원인: 대상 주소의 포트가 연결을 거부했습니다. 로컬 코어가 수신 대기 중이 아니거나 원격 서비스가 실행되지 않았을 수 있습니다. 해결: 먼저 오류에 표시된 주소를 확인하세요. 로컬 주소라면 수신 포트와 코어 상태를 확인하고, 원격 주소라면 노드 포트와 서비스 상태를 확인하세요.
i/o timeout
원인: 읽기 또는 쓰기 단계에서 대기 시간이 초과되었습니다. DNS 조회, 회선, 대상 응답이 원인일 수 있습니다. 해결: 앞뒤 로그를 확인해 어느 단계에서 시간 초과가 발생했는지 파악한 뒤, 같은 노드에서 네트워크를 바꾸거나 같은 네트워크에서 노드를 바꿔 비교하세요. 제한 시간을 늘리는 것을 속도 개선책으로 삼지 마세요.
address already in use
원인: 다른 프로세스가 로컬 수신 포트를 이미 사용 중입니다. 해결: 중복 실행된 인스턴스를 종료하거나, 포트를 점유한 프로그램을 확인한 뒤 수신 포트를 바꾸세요. 명시적 프록시를 사용하는 앱의 포트도 함께 변경해야 합니다.
x509: certificate has expired or is not yet valid
원인: 시스템 시간이 올바르지 않거나 서버 인증서의 유효 기간이 지났습니다. 해결: 먼저 기기의 날짜와 시간대를 동기화하세요. 시간이 올바른데도 오류가 계속되면 인증서 검증을 끄지 말고 서비스 제공업체에 인증서 설정을 확인해 달라고 요청하세요.
자주 묻는 질문과 문제 해결 마무리
지연 시간은 낮은데 동영상이 끊기는 이유는 무엇인가요?
짧은 요청이 성공했다고 해서 지속적인 데이터 전송이 안정적이라는 뜻은 아닙니다. 화질을 고정하고 재생 버퍼를 살펴본 뒤 같은 노드로 다른 대상을 테스트하세요. 특정 동영상 서비스만 느리다면 지연 시간만으로 노드를 정렬하지 말고 노드 출구에서 해당 서비스까지의 경로를 비교하세요.
Mux를 켰더니 오히려 느려졌습니다. 동시 연결 수를 더 늘려야 하나요?
먼저 Mux를 끄고 같은 대상을 3회 테스트해 기준을 확인하세요. 끈 상태에서 안정적으로 개선된다면 계속 끈 상태로 두고 현재 코어와 서버 조합이 다중화를 지원하는지 확인하세요. 동시 연결 수를 늘리는 것이 반드시 다음 단계로 효과적인 것은 아닙니다.
Android 기기가 잠금 상태일 때 느려지고 화면을 켜면 다시 빨라지면 어떻게 하나요?
먼저 v2rayNG 또는 v2flyNG 연결이 유지되는지 확인한 다음, 시스템 앱 정보의 배터리 관리에서 백그라운드 실행을 허용하세요. 화면이 켜진 상태와 잠금 상태에서 같은 노드를 테스트합니다. 백그라운드에서만 문제가 발생한다면 배터리 절약 제한과 다른 VPN 서비스와의 충돌을 먼저 확인하세요.
구독을 업데이트하면 속도 저하가 해결되나요?
구독을 업데이트하면 서비스 제공업체가 변경한 주소와 매개변수를 가져올 수 있지만 대역폭이 늘어나는 것은 아닙니다. 업데이트 후 현재 활성 노드가 바뀌었는지 확인하고 기존 테스트 조건으로 비교하세요. 노드가 교체됐다면 새로운 테스트 대상으로 기록해야 합니다.
마지막으로 어떤 노드, 어떤 네트워크, 어떤 대상, 어느 시간대에 테스트했는지와 설정 변경 전후의 결과를 간단히 기록하세요. 한 번 잘 나온 속도 측정값보다 안정적으로 재현되는 차이가 더 유용합니다. 노드 간 차이가 없다면 회선을 확인하고, 회선 간 차이도 없다면 로컬 진입점, 라우팅, DNS를 살펴보세요. 설정을 하나 바꿀 때마다 다시 테스트하고 개선이 없으면 원래대로 되돌리세요.