V2Ray 속도 느릴 때 해결 방법: 노드·회선·로컬 설정별 점검

핵심 내용

연결은 되지만 웹페이지가 느리게 열리거나 다운로드 속도가 일정하지 않은 경우에 적합한 점검 방법입니다. 테스트 대상과 로컬 프록시 진입점을 고정한 뒤 노드 비교, 네트워크 변경, 로그 확인을 통해 문제를 노드 출구, 접속 회선, PC 설정 중 하나로 좁혀 보세요. 마지막으로 DNS, 라우팅 규칙, Mux를 각각 확인하면 여러 설정을 한꺼번에 바꿔 원인을 놓치는 일을 막을 수 있습니다.

1. 첫 접속 지연, 다운로드 속도 저하, 간헐적 끊김 구분하기

“지연 시간은 80ms인데 다운로드가 왜 느릴까?” 두 현상은 함께 나타날 수 있습니다. 클라이언트의 지연 시간 테스트는 대개 특정 연결이나 요청 과정만 측정하므로 지속적인 전송 속도를 보여 주지는 않습니다. 노드 목록에 표시되는 속도 역시 테스트 주소와 시간, 동시 연결 수에 따라 달라집니다. 지연 시간 순으로 노드를 계속 바꾸기보다 증상을 먼저 구분하고 그에 맞는 항목을 측정하는 편이 효과적입니다.

나타나는 증상	우선 확인할 항목	첫 번째 비교 방법
처음 열 때 몇 초 걸리지만 새로고침하면 눈에 띄게 빨라짐	도메인 조회, 연결 설정, 원격 서버 응답	같은 도메인에 연속 요청을 보내 첫 바이트까지 걸린 시간 기록
페이지는 열리지만 대용량 파일 다운로드가 계속 느림	노드 출구 용량, 회선 처리량, 속도 제한	로컬 설정은 그대로 두고 같은 파일을 다른 노드로 다운로드
저녁에 느려졌다가 낮에는 정상으로 돌아옴	공유 노드 부하, 접속망 혼잡	같은 노드와 대상에 시간대를 달리해 재측정
모든 노드에서 연결이 끊겼다 이어짐	무선 네트워크, 라우터, 다른 터널링 프로그램	유선 연결이나 다른 접속망으로 바꿔 테스트

테스트 전에는 클라우드 드라이브 동기화, 시스템 업데이트, 다른 다운로드를 일시 중지하세요. 브라우저에 별도로 설치한 프록시 확장 프로그램도 끄고, 자주 사용하는 웹페이지 하나와 다운로드가 허용된 비교적 큰 파일 하나를 정해 두세요. 가능하면 같은 주소의 파일을 사용해야 합니다. 웹사이트마다 서버, 캐시, 속도 제한 정책이 다르므로 서로 다른 사이트의 속도를 직접 비교할 수는 없습니다.

3회

조건별로 반복 측정하고 중앙값 비교

30초

지속 다운로드를 관찰할 권장 시간

1개

한 번에 설정이나 네트워크 조건 하나만 변경

이 수치는 문제 진단을 위한 측정 권장 사항이며, 노드 성능 실측값이나 합격 기준이 아닙니다. 단위도 통일해야 합니다. 다운로드 프로그램에 표시된 10 MB/s는 십진법으로 약 80 Mbps입니다. 인터넷 요금제의 속도는 회선의 이론상 상한이며, 실제 파일 전송 속도는 프로토콜 오버헤드, 무선 신호, 원격 서비스의 제한에도 영향을 받습니다.

2. 노드 점검: 프로토콜 이름보다 부하와 출구 비교

같은 구독에서 출구가 서로 다른 노드 두 개를 고르고, 라우팅 모드와 테스트 대상, 측정 시간을 비슷하게 맞추세요. 노드 하나만 느리다면 해당 노드의 출구 대역폭, 공유 부하, 대상 사이트까지의 경로를 우선 의심할 수 있습니다. 두 노드가 모두 느리면 다른 공급처의 사용 가능한 노드로 비교해 보세요. 같은 상위 회선의 문제를 모든 노드의 문제로 오인하지 않도록 하기 위해서입니다.

현재 상태 기록: 노드 메모, 프로토콜, 전송 방식, 테스트 시간대, 다운로드 속도 중앙값을 적어 두세요. 기록을 공유할 때는 서버 주소, 사용자 식별 정보, 구독 링크를 삭제하세요.
테스트 대상 고정: v2rayN에서 활성 서버를 바꾼 다음 다운로드를 새로 시작하세요. 기존의 장시간 연결을 재사용하지 말고, 필요하면 브라우저를 완전히 종료했다가 다시 여세요.
교차 확인: 같은 노드로 서로 다른 사이트 두 곳을 테스트하세요. 한 사이트만 느리다면 노드 출구와 해당 사이트 사이의 연동 경로나 사이트 자체 제한이 원인일 수 있습니다.
기기 부하 확인: 작업 관리자나 활성 상태 보기를 살펴보세요. 코어 프로세스가 CPU를 계속 많이 사용한다면 먼저 PC 성능 병목을 확인해야 합니다. 원격 서버 문제라고 단정할 수는 없습니다.

VMess와 VLESS는 프록시 프로토콜 이름이며 TCP, WebSocket, gRPC 등은 전송 관련 옵션입니다. TLS는 전송 보안의 일부를 담당합니다. 이들은 서로 대체할 수 있는 ‘속도 설정’이 아닙니다. 같은 프로토콜이라도 진입점이나 출구가 다르면 속도 차이가 크게 날 수 있습니다. 전송 유형, 경로, TLS 매개변수는 서버 설정과 일치해야 하므로 로컬에서 임의로 바꾸면 안 됩니다.

정리: ‘노드 하나만 느린지’ 먼저 확인

같은 기기와 네트워크, 같은 대상을 사용했을 때 출구를 바꾼 뒤 세 차례 연속으로 속도가 눈에 띄게 개선된다면 더 빠른 노드를 우선 사용하고, 시간과 테스트 대상을 서비스 제공자에게 전달하세요. DNS, Mux, 시스템 네트워크 설정을 바로 바꿀 필요는 없습니다.

3. 회선 점검: 접속망을 바꿔 혼잡 여부 확인

노드에 연결된다고 해서 노드까지의 회선이 안정적이라는 뜻은 아닙니다. 무선 간섭, 가정용 라우터 부하, 통신사 간 연동, 저녁 시간대 혼잡은 재전송을 늘리고 처리량을 낮출 수 있습니다. 가장 유용한 비교는 같은 컴퓨터와 노드를 유지한 채 접속망만 바꾸는 것입니다. 예를 들어 가정용 인터넷에서 휴대전화 핫스팟으로 전환해 보세요. 노드와 네트워크를 동시에 바꾸는 것보다 결과를 해석하기 쉽습니다.

먼저 로컬 네트워크 확인: Windows에서는 ipconfig로 기본 게이트웨이를 확인하세요. macOS에서는 ‘시스템 설정’ → ‘네트워크’에서 현재 연결된 라우터 주소를 확인할 수 있습니다. 해당 주소에 연결을 테스트해 로컬 무선 구간이 안정적인지 살펴보세요.
다음으로 노드 진입점 확인: 탐색이 허용된 노드 주소에 연결 테스트를 수행하세요. 노드가 ICMP에 응답하지 않는다고 해서 프록시 연결도 실패한 것은 아닙니다. 실제 TCP 연결과 클라이언트 로그도 함께 확인해야 합니다.
마지막으로 접속망 변경: 사용 중인 다른 터널 연결을 끈 뒤 핫스팟으로 전환해 다시 테스트하세요. 핫스팟과 가정용 인터넷에서 같은 노드와 다운로드 주소를 사용하고, 연결을 새로 설정했는지도 기록하세요.

# Windows: 아래 주소를 실제 기본 게이트웨이로 바꾸세요
ping -n 30 192.168.1.1

# macOS: 아래 주소를 실제 기본 게이트웨이로 바꾸세요
ping -c 30 192.168.1.1

여기서 192.168.1.1은 흔히 사용하는 게이트웨이 주소일 뿐입니다. 기기에 표시되는 실제 주소를 사용하세요. 게이트웨이 연결도 반복해서 시간 초과된다면 라우터 가까이 이동하거나 유선으로 연결해 보세요. 게이트웨이는 안정적인데 모든 원격 연결이 느리다면 외부 경로를 계속 확인하면 됩니다. 한 번의 시간 초과나 중간 라우터 한 곳의 높은 패킷 손실만으로 회선 장애라고 단정하지 마세요. 일부 장비는 탐색용 패킷에 대한 응답 우선순위를 낮춥니다.

정리: 같은 노드에서 네트워크를 바꾼 뒤 회복되면 접속 경로부터 확인

가정용 인터넷에서는 느리고 핫스팟에서는 정상이라면 노드 설정은 그대로 둔 채 무선 환경과 통신사 경로를 확인하세요. 두 접속망 모두에서 특정 노드만 느리다면 점검의 초점을 해당 노드로 돌려야 합니다. PC 네트워크를 계속 초기화할 필요는 없습니다.

4. 로컬 진입점: 테스트 요청이 실제로 프록시를 통과하는지 확인

브라우저, 명령줄, 시스템 앱이 반드시 같은 프록시 설정을 사용하는 것은 아닙니다. v2rayN의 시스템 프록시는 시스템 프록시 설정을 읽는 앱에 주로 적용되며, TUN 모드는 트래픽을 처리하는 별도의 방식입니다. 점검할 때는 진입 방식을 하나로 명확히 정하세요. 브라우저 프록시 확장 프로그램, 시스템 프록시, 다른 터널 규칙을 동시에 겹쳐 사용하지 마세요.

v2rayN에서 ‘설정’ → ‘매개변수 설정’을 열고 로컬 리슨 주소, 포트, 인바운드 유형을 확인하세요. 버전에 따라 관련 항목이 기본 설정 페이지에 있을 수 있으므로 현재 화면의 메뉴 이름을 기준으로 확인하세요.
아래 명령은 127.0.0.1:10808에서 SOCKS를 지원하는 로컬 진입점이 활성화되어 있다고 가정합니다. 실제 포트가 다르면 먼저 명령을 수정하세요. HTTP만 지원하는 진입점에는 이 SOCKS 명령을 그대로 사용할 수 없습니다.
활성 노드를 선택하고 로그에 테스트 대상의 연결 기록이 나타나는지 확인하세요. 요청을 한 번 실행한 뒤 브라우저에서 접속한 결과와 비교하세요.

# Windows PowerShell
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://example.com/

# macOS 터미널
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}\n" https://example.com/

example.com은 여기서 간단한 웹페이지 요청을 시연하기 위한 예시이며 대역폭 테스트 서버가 아닙니다. socks5h는 대상 호스트 이름 처리를 SOCKS 프록시에 맡기므로 curl이 로컬에서 먼저 이름을 조회하지 않습니다. 그렇다고 코어가 최종적으로 어떤 DNS를 사용하는지까지 자동으로 정해지는 것은 아닙니다. 로컬 프록시를 거치는 경우 time_connect는 주로 로컬 프록시 진입점까지의 연결 시간을 나타내며, 노드 왕복 지연 시간으로 볼 수 없습니다. time_starttransfer에는 이후의 프록시 협상, 원격 연결, 서버 응답 등에 걸리는 시간이 포함됩니다.

`curl: (7) Failed to connect`

원인: 로컬 리슨이 시작되지 않았거나 주소 또는 포트가 잘못된 경우가 많습니다. 전체 로그에서 대상 위치를 확인할 수 있습니다. 해결: 먼저 코어가 실행 중인지 확인한 다음 매개변수 설정에 맞는 포트를 입력하고 인바운드 프로토콜을 확인하세요.

`curl: (28) Operation timed out`

원인: 설정된 제한 시간 안에 요청이 완료되지 않았습니다. 노드 연결, 도메인 조회, 원격 서버 응답 등이 원인일 수 있으므로 이 한 줄만으로 원인을 단정할 수 없습니다. 해결: 같은 시각의 코어 로그를 확인한 뒤 대상과 노드를 차례로 바꿔 비교하세요. 시간 초과 값을 키우는 것만으로 해결하려 하지 마세요.

`dial tcp: lookup`

원인: Go 계열 코어의 이름 조회 실패 로그에서 흔히 볼 수 있는 일부 메시지입니다. 원인 파악에는 뒤에 나오는 도메인과 오류 정보가 필요합니다. 해결: 먼저 조회에 실패한 주소가 노드 서버 도메인인지 접속 대상 도메인인지 구분한 뒤 해당 DNS 경로와 네트워크 연결 상태를 확인하세요.

5. DNS와 라우팅: 트래픽 경로를 먼저 확인하고 조회 설정 변경

웹페이지를 처음 열 때 느리다면 DNS를 확인해 볼 수 있지만, 모든 속도 저하의 원인은 아닙니다. 다운로드가 시작된 뒤에는 DNS만 바꿔도 같은 연결의 지속 전송 속도가 보통 직접 개선되지는 않습니다. 조회 결과가 바뀌면 이후 연결 대상 주소가 달라질 수는 있는데, 이는 별도의 영향입니다. 먼저 ‘도메인 조회에 오래 걸리는지’와 ‘연결 후 전송이 느린지’를 구분하세요.

확인 위치	확인할 내용	흔한 오해
노드 서버 주소	프록시에 연결하기 전에 서버 도메인을 사용 가능한 경로로 조회할 수 있는지	아직 연결되지 않은 프록시를 노드 자체의 도메인 조회 경로로 지정
접속 대상 도메인 조회	앱, 로컬 시스템, 코어 중 어디서 처리하는지와 예상한 방식이 일치하는지	시스템 DNS만 바꾸고 프록시 측 조회 결과와 비교
라우팅 규칙	대상이 어떤 규칙과 일치하며 실제로 어느 아웃바운드 태그를 사용하는지	시스템 프록시가 켜져 있으면 모든 요청이 같은 출구를 사용한다고 판단
브라우저 보안 DNS	브라우저가 별도의 암호화 DNS 조회를 보내는지	브라우저와 명령줄의 조회 방식 차이를 무작위 장애로 오해

v2rayN에서 ‘설정’ → ‘라우팅 설정’을 열어 현재 활성화된 규칙 세트를 확인하세요. 버전에 따라 메뉴 위치가 다르면 ‘라우팅 설정’이라는 항목을 찾으면 됩니다. V2Ray/Xray의 라우팅 규칙은 일반적으로 순서대로 일치 여부를 확인하며, outboundTag는 정의된 아웃바운드 태그와 일치해야 합니다. 로그에서 대상이 직접 연결 아웃바운드로 전달되는 것으로 보이면 프록시 노드를 계속 바꾸기 전에 규칙부터 확인하세요.

현재 규칙을 먼저 백업하세요. 임시로 조정할 때는 테스트 도메인 하나에만 적용하고, 테스트가 끝나면 원래대로 되돌리세요. 전체 라우팅 규칙을 바꾸면 결과를 해석하기 어려워집니다.
DNS 서버 자체에 연결할 수 있는지 확인하세요. 암호화 DNS를 설정했다면 서버 도메인을 처음 조회하는 방법과 연결이 직접 연결인지 프록시를 통하는지도 살펴봐야 합니다.
Windows의 ipconfig /flushdns는 시스템 DNS 캐시만 지웁니다. 브라우저나 코어의 캐시까지 함께 삭제되는 것은 아닙니다. 필요하다면 브라우저를 종료하고 코어를 재시작한 뒤 요청을 새로 보내세요.

6. Mux: 먼저 끄고 기준 속도를 측정한 뒤 유지 여부 판단

Mux는 연결을 재사용하는 기능이지 노드 대역폭을 늘리는 기능이 아닙니다. 짧은 연결이 많이 발생할 때 연결 설정 비용을 줄일 수 있지만, 여러 논리 연결이 하위 전송의 지연 영향을 함께 받을 수도 있습니다. 대용량 파일을 계속 다운로드할 때는 이점이 없을 수도 있습니다. 실제 효과는 코어 구현, 노드 프로토콜, 전송 설정에 따라 다르므로 특정 동시 연결 수를 보편적인 최적값으로 볼 수 없습니다.

현재 값 기록: 클라이언트, 코어, 노드별 Mux 상태를 기록하세요. 클라이언트 버전과 코어 버전은 별개이므로 문제를 전달할 때 각각 적어야 합니다.
끄고 재측정: v2rayN의 ‘설정’ → ‘매개변수 설정’에서 Mux 관련 항목을 찾으세요. 해당 항목이 없다면 설정 필드를 추측하지 말고 현재 코어와 설정 형식이 지원하는지 확인하세요.
설정 적용 확인: 저장한 뒤 코어를 재시작하고 테스트 연결을 새로 만드세요. 구독 노드, 개별 노드 설정, 사용자 지정 설정은 적용 범위가 다를 수 있으므로 실제 생성된 설정과 로그를 기준으로 판단하세요.
각각 비교: 같은 조건에서 세 차례 반복하고 짧은 페이지 로딩과 지속 다운로드 결과를 따로 기록하세요. 끈 뒤 연결 끊김이 줄고 일상 사용이 개선됐다면 끈 상태를 유지하면 됩니다. 설정을 복잡하게 만들기 위해 다시 켤 필요는 없습니다.

7. 자주 묻는 질문과 점검 마무리

지연 시간이 가장 짧은 노드가 오히려 다운로드가 가장 느리다면 어떤 노드를 선택해야 하나요?

용도에 맞춰 선택하세요. 동영상 시청과 대용량 파일 다운로드는 지속 전송 속도와 연결 끊김 여부를 우선 확인하고, 실시간 상호작용에서는 응답 시간도 살펴봐야 합니다. 같은 파일로 세 차례씩 측정하고 한 번의 지연 시간 결과를 종합 순위로 보지 마세요.

속도 테스트는 정상인데 브라우저에서만 페이지가 느리게 열리면 어떻게 하나요?

먼저 브라우저 프록시 확장 프로그램, 보안 DNS, 연결 재사용 설정을 확인하세요. 브라우저를 완전히 종료한 뒤 다시 시도하고, 로컬 프록시를 명시한 curl 요청과 비교해 보세요. 특정 사이트 하나만 느리다면 해당 사이트와 노드 출구 사이의 경로를 추가로 확인하세요.

안드로이드 휴대전화도 느린데 PC 설정을 그대로 적용해도 되나요?

단계별 점검 순서는 참고할 수 있지만 로컬 포트와 트래픽 처리 방식은 그대로 적용하면 안 됩니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 같은 Wi-Fi에서 동등한 노드와 테스트 대상으로 먼저 비교한 다음 다른 터널이나 절전 제한이 함께 적용되고 있는지 확인하세요.

저녁에만 느린데 Mux나 DNS를 조정하면 해결되나요?

먼저 같은 노드를 사용해 낮과 저녁 결과를 비교한 뒤, 저녁 시간에 접속망을 바꾸거나 다른 공급처의 노드를 사용해 보세요. 느린 현상이 시간대와 경로에 따라 달라진다면 혼잡이나 공유 용량을 우선 의심하세요. 처음 페이지를 열 때 DNS 조회만 유난히 오래 걸리는 경우에만 DNS를 별도로 확인하세요.

점검을 마친 뒤 발생 시각, 클라이언트와 코어 버전, 접속망, 노드 메모, 대상 도메인, 세 차례 측정 결과, 실제 아웃바운드, 오류 일부를 간단히 기록해 두세요. 서비스 제공자에게 전달하기 전 구독 링크, 사용자 식별 정보, 민감한 서버 정보를 숨기세요. ‘같은 노드에서 핫스팟으로 바꾸니 회복됨’ 또는 ‘같은 네트워크에서 출구를 바꾸니 회복됨’처럼 설명하면 단순히 ‘속도가 느림’이라고 하는 것보다 원인을 찾는 데 도움이 됩니다.

노드별 차이가 있다면 사용 가능한 출구를 유지하고 느린 노드의 시간대와 테스트 대상을 전달하세요.
회선별 차이가 있다면 무선 네트워크나 접속 경로를 점검하고 프로토콜을 무작정 바꾸지 마세요.
로컬 설정별 차이가 있다면 관련 없는 변경은 원래대로 되돌리고 반복 테스트로 효과가 확인된 설정만 유지하세요.