연결은 되지만 웹페이지가 처음 열릴 때 느리거나, 다운로드 속도가 낮거나, 연결이 간헐적으로 끊기는 경우에 적합합니다. 먼저 테스트 대상을 고정하고 연결 시간과 다운로드 속도를 구분한 뒤, 노드와 네트워크를 바꾸고 프록시 진입점과 로그를 확인해 원인을 좁혀 보세요. 명령어와 포트의 용도를 명시했으며, 지연 시간 측정값을 대역폭으로 간주하거나 모든 지연 현상을 프로토콜 탓으로 돌리지 않습니다.
먼저 구분하기: 연결 지연, 다운로드 지연, 백그라운드 연결 끊김
‘속도가 느리다’는 말은 적어도 세 가지 상황을 가리킵니다. 웹페이지를 눌렀을 때 한참 동안 빈 화면만 보인다면 DNS 조회, 연결 설정 또는 서버 응답이 지연될 수 있습니다. 페이지는 바로 열리지만 대용량 파일 다운로드가 느리다면 처리량 문제일 가능성이 큽니다. 안드로이드에서 화면이 켜져 있을 때는 작동하지만 잠금 후 연결이 끊긴다면 백그라운드 실행 제한을 먼저 확인해야 합니다. 각각 필요한 근거가 다르므로 노드 목록의 지연 시간 하나만으로 판단하지 마세요.
| 증상 | 먼저 기록할 항목 | 우선 점검할 항목 |
|---|---|---|
| 처음 열 때는 느리지만 새로고침하면 빠름 | 첫 요청과 반복 요청에 걸리는 시간 | DNS, 핸드셰이크, 연결 재사용, 캐시 |
| 페이지는 열리지만 대용량 파일 다운로드가 느림 | 같은 파일의 지속 다운로드 속도 | 노드 부하, 출구 대역폭, 네트워크 혼잡 |
| 특정 사이트만 느림 | 다른 대상 두 곳은 정상인지 확인 | 대상 사이트의 속도 제한, 출구 지역, 라우팅 규칙 |
| 화면을 잠그면 연결이 끊김 | 화면을 켰을 때 바로 다시 연결되는지 | 안드로이드 배터리 절약 정책, 백그라운드 권한 |
테스트 중에는 대역폭을 사용하는 클라우드 동기화와 다운로드를 중지하고, 같은 기기·대상·네트워크에서 측정하세요. 각 조건에서 세 번 반복하고 시간대와 실패 여부를 기록합니다. 브라우저 캐시가 적용된 결과, 여러 연결을 사용하는 속도 측정 사이트의 결과, 단일 연결 다운로드 속도를 한데 놓고 비교하지 마세요. 각각 측정하는 항목이 다릅니다.
1단계: 비교 테스트로 노드 부하 확인
노드에서 연결이 수립됐다는 사실은 그 시점에 사용할 수 있는 경로가 있었다는 뜻일 뿐입니다. 서버 CPU, 출구 대역폭, 동시 연결 수 또는 상위 네트워크가 병목일 수 있습니다. 클라이언트에서는 보통 이런 서버 측 지표를 확인할 수 없으므로, 시간 초과 한 번만으로 서버 과부하를 단정하지 말고 먼저 비교 테스트를 해 보세요.
-
테스트 대상 고정
접근 권한이 있는 동일한 HTTPS 페이지나 다운로드 파일을 선택하고 테스트 시간을 기록하세요. 먼저 프록시를 끈 상태에서도 평소 이용하는 웹사이트가 전반적으로 느리지 않은지 확인합니다. 그렇다면 가정용 또는 모바일 네트워크부터 점검하세요.
-
다른 노드로 전환
v2rayN 기본 화면의 노드 목록에서 다른 설정을 선택하고 마우스 오른쪽 버튼을 눌러 ‘활성 서버로 설정’을 선택한 뒤 다시 테스트하세요. 이름만 다른 동일 서버 설정보다는 출구가 다른 노드를 우선 사용하세요.
-
다른 대상과 교차 테스트
노드는 그대로 둔 채 다른 대상 두 곳에도 접속해 보세요. 한 사이트만 느리다면 해당 사이트의 속도 제한, CDN 연결 경로 선택 또는 출구에서 그 사이트까지의 경로 문제일 수 있습니다. 이 결과만으로 노드 전체 성능을 판단해서는 안 됩니다.
-
시간대를 바꿔 비교
다른 시간대에 같은 테스트를 반복하세요. 여러 대상이 혼잡 시간대에만 함께 느려진다면 공유 자원이나 경로 혼잡을 의심해 볼 수 있지만, 구체적인 부하를 확인하려면 서버 모니터링이 필요합니다.
노드를 바꾼 직후 속도가 회복됐다면 원래 노드 또는 관련 경로에 문제가 있을 가능성이 있습니다. 다만 ‘서버가 바쁜 것’인지 ‘네트워크 경로가 혼잡한 것’인지는 아직 구분할 수 없습니다. 같은 지역이어도 통신사 간 연결 경로가 다를 수 있으므로 지리적으로 가깝다고 실제 네트워크 경로가 짧은 것은 아닙니다. 원래 설정은 유지하고 다음 단계의 테스트를 이어가세요. 노드와 프로토콜, DNS를 한 번에 바꾸면 원인을 파악하기 어렵습니다.
2단계: 접속 네트워크를 바꿔 경로 문제 확인
프록시 요청은 기기에서 노드까지, 노드에서 대상 사이트까지 두 구간의 경로를 거칩니다. 집 안 무선 신호 간섭, 통신사 간 연결 혼잡, 서로 다른 네트워크 구간에서 발생하는 패킷 손실은 실제 처리량을 떨어뜨릴 수 있습니다. TCP는 패킷이 손실되면 재전송하고 전송 속도를 조정하므로, 속도가 일정하게 낮기보다 오르내리는 양상으로 나타날 수 있습니다.
- 같은 기기에서 네트워크 바꾸기: 노드와 대상은 그대로 두고 컴퓨터의 연결을 가정용 네트워크에서 휴대폰 핫스팟으로 바꿔 보세요. 핫스팟에서는 정상인데 가정용 네트워크에서 계속 느리다면 라우터, 무선 연결, 유선 인터넷 경로를 우선 점검하세요.
- 같은 네트워크에서 연결 방식 바꾸기: 가능하다면 유선 연결을 사용하거나 라우터 가까이에서 테스트하세요. 무선 신호가 약한 곳에서만 문제가 생긴다면 프로토콜 설정부터 바꿀 필요는 없습니다.
- 지연 시간과 대역폭 구분하기: 지연 시간이 짧은 노드도 출구가 혼잡할 수 있고, 지연 시간이 긴 노드도 다운로드 속도를 안정적으로 유지할 수 있습니다. 연결 테스트와 실제 서비스 이용 테스트를 함께 확인하세요.
- 경로 탐색 결과는 신중하게 해석하기: 노드가 ICMP 요청에 응답하지 않는다고 해서 프록시를 사용할 수 없는 것은 아닙니다. 경로 탐색 중간 구간에서만 패킷 손실이 보이고 다음 구간은 정상이라면 라우터가 탐색 요청에 대한 응답을 제한하는 경우가 흔합니다. 이를 곧바로 실제 트래픽 손실로 판단하지 마세요.
3단계: 프록시 진입점, 라우팅, DNS 확인
v2rayN은 클라이언트 인터페이스이며 실제 연결은 선택한 코어가 처리합니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 프로토콜이 작동하는지는 클라이언트 코어와 서버 설정의 호환성에 달려 있습니다. VMess와 VLESS는 프로토콜 종류이지 속도 등급이 아닙니다. 서버의 VMess 설정 이름만 VLESS로 바꿔 ‘속도를 높일’ 수는 없습니다.
- 시스템 프록시 확인: Windows에서는 v2rayN 트레이 메뉴에서 ‘시스템 프록시’ → ‘시스템 프록시 자동 구성’을 선택할 수 있습니다. 이 설정은 시스템 프록시 설정을 따르는 앱에만 적용되며 모든 프로그램이 자동으로 프록시를 사용하는 것은 아닙니다.
- 로컬 수신 주소 확인: v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트와 진입점 유형을 확인하세요. 버전에 따라 항목 이름이 다를 수 있습니다. 아래 명령은 SOCKS 또는 SOCKS를 지원하는 혼합 진입점이 실제로
127.0.0.1:10808에서 연결을 수신할 때만 그대로 사용할 수 있습니다. - 테스트 경로 하나만 유지: 다른 프록시 프로그램의 시스템 프록시나 가상 네트워크 인터페이스 처리를 일시 중지하세요. 수동 프록시와 TUN을 함께 사용해도 항상 문제가 되는 것은 아니지만, 원인을 찾을 때는 변수를 줄여 루프백이나 중복 처리를 방지해야 합니다.
- 실제 라우팅 확인: 대상 요청이 직접 연결이 아닌 프록시 출구로 전달되는지 확인하세요. 브라우저가 캐시된 기존 연결을 계속 재사용할 수 있으므로, 규칙을 바꾼 뒤에는 연결을 새로 만든 다음 테스트해야 합니다.
DNS 조회가 이뤄지는 위치도 구분해야 합니다. 노드 서버 도메인은 먼저 조회되어야 하며, 대상 사이트 도메인은 로컬 기기, 프록시 코어 또는 원격에서 조회될 수 있습니다. DNS 서버를 바꾸면 해당 조회 단계에만 도움이 될 수 있으며 서버 출구의 속도 제한을 해결하지는 못합니다. 처음 접속할 때만 지연된다면 로그에서 조회 오류를 먼저 확인한 뒤 해당 DNS 경로를 조정하세요.
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}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/아래 내용은 진단 예시이며 이 사이트에서 직접 측정한 결과가 아닙니다. 테스트 대상은 접근 권한이 있는 실제 HTTPS 주소로 바꾸세요. Windows 명령 프롬프트에서는 curl.exe를 사용하고 /dev/null은 NUL로 바꾸세요. socks5h는 대상 도메인 조회를 SOCKS 프록시에서 처리하도록 지정합니다. 로컬에서 도메인을 조회하는 경우와 테스트 경로가 다릅니다.
로그 오류: 연결 실패와 전송 속도 저하 구분하기
클라이언트의 로그 화면을 열고 문제를 한 번 재현한 뒤 같은 시각에 발생한 오류를 기록하세요. 시간 초과, 인증서 오류, 포트 사용 중은 각각 해결 방법이 다릅니다. 아래는 흔히 볼 수 있는 오류 내용입니다. 원인을 판단하려면 앞뒤 로그를 함께 확인해야 하며, 특정 키워드만 보고 설정 전체를 바꾸지 마세요.
i/o timeout
원인: 네트워크 읽기 또는 쓰기 과정에서 시간 초과가 발생한 경우입니다. 노드나 대상까지의 경로, 필터링, 서버 응답 문제일 수 있습니다. 해결: 오류에 표시된 주소와 출구를 확인하고 ‘같은 노드에서 네트워크 바꾸기’, ‘같은 네트워크에서 노드 바꾸기’ 방식으로 비교하세요. DNS 오류라고 바로 단정해서는 안 됩니다.
connection refused
원인: 대상 연결이 거부된 상태로, 해당 포트에서 연결을 수신하지 않거나 연결을 명시적으로 거부할 때 흔히 발생합니다. 해결: 주소가 로컬 루프백이면 클라이언트 코어가 실행 중인지, 포트가 일치하는지 확인하세요. 원격 노드 주소라면 노드 포트를 확인하고 서버 관리자에게 문의하세요.
address already in use
원인: 수신 대기하려는 로컬 주소와 포트를 다른 프로세스가 이미 사용 중입니다. 해결: 중복 실행된 클라이언트를 종료하거나 사용 중이지 않은 포트로 바꾸세요. 시스템 프록시와 앱의 포트 설정도 함께 업데이트해야 합니다.
x509: certificate has expired or is not yet valid
원인: 기기 시간이 맞지 않거나 서버 인증서의 유효 기간이 만료됐습니다. 해결: 먼저 시스템 날짜와 시간대를 동기화하세요. 시간이 정확하다면 서버에서 인증서를 갱신해야 합니다. 문제를 감추려고 인증서 검증을 건너뛰지 마세요.
로그 상세도를 일시적으로 높였다면 문제를 재현한 뒤 평소 수준으로 되돌리세요. 관리자에게 기록을 보낼 때는 시간, 오류 유형, 실패 단계를 남기고 구독 주소, 사용자 식별 정보, 인증 정보는 가리세요. 구독 주소에는 보통 접속 정보가 포함되어 있으므로 공개 게시판에 그대로 올리지 마세요.
안드로이드에서 추가 확인: VPN 권한과 백그라운드 제한
데스크톱에서는 정상인데 v2rayNG 또는 v2flyNG가 안드로이드에서 간헐적으로 끊긴다면 기기 설정을 별도로 확인하세요. 두 클라이언트 모두 안드로이드 VpnService를 통해 트래픽을 처리할 수 있습니다. 시스템에 VPN 아이콘이 표시된다는 것은 VPN 서비스가 실행 중이라는 뜻일 뿐, 프록시 노드 연결이 성공했거나 대상 앱의 트래픽이 프록시를 통과한다는 보장은 아닙니다.
화면이 켜져 있을 때는 정상인데 잠그면 메시지가 도착하지 않나요?
안드로이드에서 ‘설정’ → ‘앱’ → ‘v2rayNG’ 또는 ‘v2flyNG’ → ‘배터리’로 이동해 백그라운드 사용을 ‘제한 없음’ 또는 제조사에 해당하는 옵션으로 설정하세요. 시스템에 자동 시작 관리 기능이 있다면 해당 앱의 자동 시작도 허용해야 합니다. 제조사마다 메뉴 이름이 다르므로 설정 후 화면을 잠갔다가 다시 켜서 비교 테스트를 진행하세요.
특정 앱만 느리고 브라우저는 정상인가요?
클라이언트 ‘설정’에서 ‘앱별 프록시’ 목록과 현재 모드를 확인하세요. 선택 목록이 프록시를 적용할 앱을 뜻할 수도 있고, 우회 모드에서는 선택한 앱을 제외한다는 뜻일 수도 있습니다. 화면 안내에서 의미를 확인한 뒤 VPN 서비스를 다시 시작하고 테스트하세요.
연결을 눌렀는데 시스템 VPN 아이콘이 표시되지 않나요?
시스템 VPN을 사용 중인 다른 앱을 종료한 뒤 클라이언트를 시작하고 시스템에 표시되는 VPN 연결 요청을 승인하세요. 그래도 연결되지 않으면 클라이언트 로그와 시스템 VPN 설정을 확인하세요. 속도 측정 주소를 바꾸기보다 먼저 서비스가 시작되지 않는 문제를 해결해야 합니다.
웹페이지는 열리지만 음성 통화나 게임이 불안정한가요?
이런 서비스는 UDP에 의존할 수 있으므로 라우팅 규칙, 사용 중인 프로토콜, 서버 경로가 해당 트래픽을 지원하는지 확인해야 합니다. TCP 웹페이지 접속에 성공했다고 UDP까지 사용할 수 있는 것은 아닙니다. 문제가 발생한 앱과 상황을 기록하고 설정을 확인하세요. MTU를 무작정 바꾸지 마세요.
원인 좁히기: 설정은 한 번에 하나씩 변경
문제 해결의 목표는 누구에게나 통하는 ‘속도 향상 설정’을 찾는 것이 아니라 반복해서 확인할 수 있는 근거를 모으는 것입니다. 일반 연결에서 MTU, 동시 연결 수, 연결 재사용, 전송 방식을 임의로 바꾸면 증상이 달라질 수도 있지만 새로운 호환성 문제가 생길 수도 있습니다. 먼저 정상 작동하는 기준 설정을 보존하고, 근거에 따라 한 번에 하나씩 변경해야 효과를 판단할 수 있습니다.
- 노드 하나만 느림: 여러 대상에서 해당 노드의 속도를 기록한 뒤 서버 부하, 출구, 경로 상황과 비교하세요.
- 같은 노드가 특정 네트워크에서만 느림: 클라이언트를 재설치하기보다 접속 네트워크와 통신사 경로를 먼저 확인하세요.
- SOCKS를 지정한 요청은 정상인데 브라우저는 느림: 시스템 프록시, 브라우저 프록시 설정, 확장 프로그램, 라우팅 규칙 차이를 확인하세요.
- 모든 대상에서 첫 요청만 느림: 전체 시간만 보고 프로토콜을 바꾸지 말고 도메인 조회, 핸드셰이크, 서버 첫 바이트 응답 시간을 따로 확인하세요.
- 안드로이드 백그라운드에서만 연결 끊김: 배터리 관리, 백그라운드 권한, VPN 서비스 상태를 확인하고 화면을 잠근 뒤 다시 테스트하세요.
최종 기록에는 클라이언트 이름과 실제 버전, 사용 중인 코어, 네트워크 유형, 발생 시간, 대상 유형, 주요 오류를 포함하세요. 기록을 공유하기 위해 전체 설정을 공개하지 마세요. 재설치하거나 설정 경로를 다시 확인해야 한다면 아래 다운로드 페이지와 가이드를 참고해 표준 연결을 복구한 뒤 성능을 검증하세요.