2026-08-26 · 입문 가이드 · 약 10분

v2rayN 첫 연결 가이드: 서버 선택, 실제 연결 속도 측정 및 프록시 적용 확인

구독을 가져온 뒤 서버를 지역과 프로토콜별로 고르고, TCPing과 실제 연결 속도 측정 결과를 구분하세요. 시스템 프록시와 외부 IP를 확인해 프록시가 적용됐는지도 점검할 수 있습니다.

이 글의 핵심 내용

구독을 가져왔지만 연결을 어떻게 시작해야 할지 막막한 데스크톱 사용자에게 적합합니다. 먼저 후보 서버를 몇 개로 추린 다음 실제 연결 지연 시간을 측정해 사용할 수 없는 경로를 제외하고, 마지막으로 로컬 프록시 포트와 시스템 프록시, 요청의 외부 IP를 각각 확인합니다. Windows용 v2rayN을 기준으로, 서버 목록의 숫자 하나만 보는 대신 반복 가능한 점검 절차를 안내합니다.

1. 구독을 가져온 뒤 확인할 항목: 서버, 코어, 로컬 포트

구독 업데이트가 성공했다는 것은 클라이언트가 서버 설정을 가져왔다는 뜻일 뿐, 계정이 유효하거나 서버에 연결할 수 있거나 브라우저가 프록시를 사용한다는 뜻은 아닙니다. 목록에 구독 그룹 이름만 있는 것이 아니라 실제 서버 항목이 있는지 확인한 뒤 서버를 선택해 설정을 불러오세요. 서버 주소, 인증 정보, 전송 방식, TLS 설정이 함께 연결 결과를 결정하므로 이름만 보고 판단하면 안 됩니다.

아래 안내는 Windows 데스크톱 앱에서 흔히 사용하는 메뉴 이름을 기준으로 합니다. 버전에 따라 메뉴 문구가 조금 다를 수 있습니다. 예를 들어 ‘서버 실제 연결 지연 시간 테스트’가 ‘실제 연결 지연 시간 테스트’로 표시될 수도 있습니다. 메뉴 이름을 억지로 맞추기보다 해당 기능을 찾아 기존 설정을 그대로 유지하세요.

  1. 구독 확인

    ‘구독 그룹’ → ‘구독 그룹 설정’에서 그룹이 활성화되어 있는지 확인한 다음, ‘구독 그룹’ 메뉴에서 ‘모든 구독 업데이트(프록시 미사용)’를 실행하세요. 업데이트 로그와 서버 목록을 확인합니다. 현재 네트워크에서 구독 주소에 접속할 수 없다면 먼저 구독을 가져오는 문제부터 해결하세요.

  2. 설정 값 확인

    서버를 선택하고 마우스 오른쪽 버튼을 눌러 ‘서버 편집’으로 이동한 뒤 주소, 포트, 프로토콜, 전송 설정이 같은 설정에서 가져온 값인지 확인하세요. VLESS와 REALITY를 함께 사용하는 경우 공개 키, 서버 이름, shortId 등의 값도 서버 설정과 일치해야 합니다. 값을 임의로 추측해 채우지 마세요.

  3. 포트 확인

    ‘설정’ → ‘매개변수 설정’을 열고 로컬 수신 포트와 관련 인바운드 설정을 찾아 HTTP 또는 혼합 프록시의 실제 포트를 확인하세요. 아래 명령은 HTTP 프록시를 지원하는 127.0.0.1:10808을 예로 듭니다. 실행 전에는 화면에 표시된 포트로 바꾸세요.

  4. 활성 서버로 지정

    서버 목록에서 마우스 오른쪽 버튼을 눌러 ‘활성 서버로 설정’을 선택하세요. 활성 표시가 대상 서버로 옮겨졌는지 확인하고, 로그에 설정 불러오기 실패, 코어 종료, 포트 사용 중 등의 메시지가 있는지도 살펴보세요. 목록에서 한 줄을 선택한 것만으로 활성 서버가 바뀌는 것은 아닙니다.

2. 서버 선택 기준: 지역, 프로토콜, 안정성

먼저 같은 지역의 후보 서버를 2~3개 고르세요. 지역과 서비스 경로를 한꺼번에 바꾸면 결과를 비교하기 어렵습니다. 지리적 거리는 후보를 추리는 데 참고할 수 있지만 실제 테스트를 대신하지는 못합니다. 통신사 간 연결, 저녁 시간대 혼잡, 서버 부하, 중계 경로에 따라 결과가 달라질 수 있으며 서버 이름에 표시된 지역이 실제 외부 IP 위치와 다를 수도 있습니다.

같은 지역의 후보 서버

추천

목표 사이트에서 요구하는 지역에 해당하는 서버 중 2~3개를 골라 실제 연결 테스트를 반복하세요. 가끔 가장 낮은 지연 시간을 기록하는 서버보다 매번 연결에 성공하고 변동 폭이 작은 경로를 우선하세요.

적합한 용도: 첫 연결, 일상적인 웹 탐색, 기준값 확인

특정 지역 서버

이용하려는 서비스에서 특정 지역을 요구한다면 실제 외부 IP와 사이트의 지역 판별 결과를 기준으로 선택하세요. 지연 시간이 높더라도 설정 오류라고 단정할 수 없습니다. 지역 간 연결에서 흔히 발생하는 특성일 수 있습니다.

적합한 용도: 특정 지역 접속이 필요한 서비스

다른 프로토콜 서버

주 경로가 실패하면 설정이 완전하고 현재 코어에서 지원되는 다른 서버와 비교해 보세요. 프로토콜 이름만으로 지연 시간이 더 짧다고 보장할 수는 없습니다. 주소와 경로, 전송 방식의 조합에 따라 결과가 달라집니다.

적합한 용도: 특정 경로 문제와 로컬 환경 문제 구분

구독에 VLESS + REALITY 서버가 포함되어 있다면 현재 사용하는 코어가 해당 설정을 지원하는지 확인하세요. v2rayN의 ‘설정’ → ‘매개변수 설정’에서 Core 유형 관련 옵션을 찾아보고, 시작 로그에서 실제로 불러온 코어를 확인할 수 있습니다. 코어 이름을 서버 품질 순위처럼 여기지 말고, 서버에서 요구하는 보안 설정을 임의로 다른 조합으로 바꾸지 마세요.

3. TCPing과 실제 연결 속도 측정의 차이

TCPing은 보통 서버 주소와 포트에 TCP 연결을 맺는 데 걸리는 시간을 측정합니다. 프록시 인증, 전송 핸드셰이크, 대상 사이트 접속까지 확인하지는 않습니다. 포트에 연결할 수 있다고 해서 그 뒤의 프록시 서비스까지 정상이라고 볼 수 없습니다. 서버의 다른 서비스나 앞단 접속 계층이 연결을 받아들였을 수도 있습니다.

실제 연결 지연 시간 테스트는 서버를 통해 설정된 테스트 URL에 접속해 프록시 연결의 더 많은 단계를 확인합니다. ‘이 서버를 통해 요청을 보낼 수 있는지’를 TCPing보다 가까이서 점검하지만, 결과는 테스트 URL, DNS, 시간 제한, 네트워크 상태에 따라 달라집니다. 모든 사이트에 접속할 수 있다는 뜻도 아닙니다.

테스트 종류주요 확인 항목이 결과만으로 알 수 없는 항목
TCPing서버 TCP 포트 접속 가능 여부와 연결 시간인증의 정확성 및 프록시 요청 완료 여부
실제 연결 지연 시간서버를 통한 테스트 URL 요청 결과와 소요 시간모든 서비스 사이트의 접속 가능 여부와 지속적인 다운로드 속도
다운로드 속도 테스트지정된 리소스와 테스트 시간대의 전송 성능장기적인 안정성과 다른 대상에 대한 접속 품질

권장 테스트 순서

  1. 후보 서버를 몇 개 선택한 뒤 마우스 오른쪽 버튼 메뉴에서 ‘서버 실제 연결 지연 시간 테스트’를 실행하거나 ‘서버’ 메뉴의 같은 기능을 사용하세요.
  2. 테스트 URL을 그대로 유지하면서 3회 반복하고 성공 여부와 지연 시간 변동을 기록하세요. 많은 서버를 대상으로 다운로드 테스트를 동시에 실행하지 마세요.
  3. 모든 테스트가 실패하면 ‘설정’ → ‘매개변수 설정’에서 실제 연결 테스트 주소 관련 항목을 확인해 테스트 대상이 유효한지 점검한 뒤 로그를 살펴보세요.
  4. 연속으로 성공한 서버를 활성 서버로 지정한 다음 실제 앱에서 확인하세요. 테스트 기능을 사용하는 데 시스템 프록시를 켤 필요는 없을 수 있습니다.
3회
권장 반복 횟수이며 실제 측정값은 아닙니다
10808
이 문서의 예시 프록시 포트입니다. 실제 설정을 확인하세요.
15초
아래 명령에서 요청 한 번에 적용되는 최대 시간 제한

목록에 음수, 시간 초과 또는 빈 값이 표시되면 해당 버전의 결과 안내와 로그를 먼저 확인하세요. 음수를 ‘지연 시간이 매우 짧다’는 의미로 해석하면 안 됩니다. TCPing은 성공하지만 실제 연결이 실패한다면 인증, TLS, 전송 설정, 테스트 대상을 먼저 점검하세요. 둘 다 실패하면 서버 주소와 포트, 로컬 네트워크, 방화벽을 확인하세요.

4. 시스템 프록시 확인: 요청을 로컬 포트로 보내기

활성 서버를 설정한 뒤에는 앱의 요청이 v2rayN으로 전달되도록 해야 합니다. Windows의 ‘시스템 프록시’는 해당 설정을 따르는 앱에 프록시 접속 경로를 제공하지만 모든 프로그램의 트래픽을 자동으로 처리하지는 않습니다. 터미널 도구, 일부 브라우저 확장 프로그램, 독립 실행형 앱은 자체 프록시 설정을 사용할 수 있습니다.

  1. 시스템 프록시 켜기

    v2rayN 하단 상태 표시줄 또는 트레이 메뉴에서 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 선택하세요. 현재 모드가 ‘시스템 프록시 해제’가 아닌지 확인합니다. 처음 문제를 점검할 때는 시스템 프록시를 변경하는 다른 프로그램을 함께 실행하지 마세요.

  2. 시스템 설정 확인

    Windows ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’를 열어 수동 프록시가 로컬 주소와 올바른 포트를 가리키는지 확인하세요. 스크립트 모드를 사용한다면 ‘설정 스크립트 사용’ 항목도 확인해야 합니다. 수동 프록시 스위치만 살펴봐서는 안 됩니다.

  3. 포트만 따로 테스트

    아래 명령을 PowerShell에서 실행하면 시스템 프록시를 터미널이 읽는지 여부와 관계없이 프록시를 명시적으로 지정할 수 있습니다. 로컬 포트 연결에 실패하면 수신 포트와 코어 상태부터 확인하세요.

  4. 브라우저 확인

    브라우저가 시스템 프록시를 사용하도록 설정하고 프록시 트래픽을 가로채는 확장 프로그램을 잠시 끈 뒤 새 페이지에서 대상 사이트를 여세요. 명령줄에서는 성공하지만 브라우저에서 실패한다면 구독을 바꾸기 전에 브라우저 자체의 프록시 규칙을 확인하세요.

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 15 --head https://example.com/

PowerShell에서 curl이 다른 명령으로 해석되는 문제를 피하려고 여기서는 curl.exe를 사용합니다. --noproxy ""는 이번 명령에서 프록시 우회 목록을 비웁니다. 이 예시는 해당 포트가 HTTP 프록시를 지원한다고 가정합니다. SOCKS 전용 인바운드를 설정했다면 --proxy socks5h://127.0.0.1:10808을 사용하세요. socks5h는 대상 도메인의 DNS 조회를 프록시에 맡깁니다.

5. 외부 IP 확인: 시스템 프록시와 라우팅 구분

시스템 프록시는 요청이 클라이언트로 들어오는지를 결정하고, 라우팅 규칙은 들어온 요청을 어떤 출구로 보낼지 결정합니다. 시스템 프록시가 켜져 있어도 중국 본토 사이트는 규칙에 따라 직접 연결될 수 있습니다. 따라서 직접 연결로 지정된 사이트 하나만 보고 프록시가 작동하지 않는다고 판단하거나, 웹페이지가 열린다는 이유만으로 외부 IP가 바뀌었다고 결론 내리면 안 됩니다.

아래에서는 같은 HTTPS 주소에 직접 연결한 요청과 프록시 요청을 비교합니다. 이 API는 요청이 사용한 공인 IP를 반환하는 테스트 대상입니다. 실제 접속 여부는 네트워크 연결 상태와 서비스 운영 상황에 따라 달라질 수 있습니다. API를 사용할 수 없다면 신뢰할 수 있는 다른 외부 IP 확인 서비스를 이용하되, 두 요청 모두 같은 대상을 사용하세요.

# 프록시를 사용하지 않고 직접 요청
curl.exe --noproxy "*" --connect-timeout 10 --max-time 15 https://api.ipify.org
Write-Output ""

# 로컬 HTTP 또는 혼합 프록시 포트를 지정해 요청
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 15 https://api.ipify.org
Write-Output ""

라우팅 영향을 분리해서 확인하려면 먼저 현재 라우팅 모드를 기록한 뒤, v2rayN의 ‘라우팅’에서 일반 요청을 프록시 출구로 보내는 전역 규칙을 임시로 선택해 다시 조회하세요. 버전이나 사용자 지정 규칙에 따라 이름이 다를 수 있으므로 규칙 내용과 로그의 출구 태그를 기준으로 판단합니다. 확인이 끝나면 기존 라우팅 규칙으로 되돌리세요.

6. 첫 연결 문제와 점검 순서

TCPing에는 숫자가 나오는데 실제 연결은 계속 시간 초과되는 이유는 무엇인가요?

먼저 같은 서버의 인증 정보, 전송 방식, TLS 서버 이름, 코어 지원 여부를 확인한 뒤 테스트 URL에 접속할 수 있는지 살펴보세요. TCP 포트 연결 성공은 검증의 앞부분만 통과한 것입니다. 프록시 핸드셰이크에 실패하면 실제 연결은 시간 초과될 수 있습니다.

실제 연결은 성공했는데 웹페이지가 열리지 않는 이유는 무엇인가요?

먼저 프록시를 명시한 명령을 실행한 다음 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’과 브라우저 설정을 확인하세요. 특정 사이트만 실패한다면 모든 서버를 사용할 수 없다고 단정하지 말고 해당 도메인의 라우팅, DNS, 사이트 응답을 살펴보세요.

로그에 로컬 포트가 사용 중이라고 표시되면 어떻게 해야 하나요?

netstat -ano | findstr :10808을 실행해 포트를 사용하는 항목을 확인하고 작업 관리자에서 해당 PID의 프로그램을 찾으세요. 클라이언트가 중복 실행되었는지도 확인합니다. 포트를 바꿔야 한다면 ‘설정’ → ‘매개변수 설정’에서 변경한 뒤 시스템 프록시와 테스트 명령에도 새 포트를 반영하세요.

지연 시간은 짧은데 다운로드가 느립니다. 속도 측정이 부정확한가요?

지연 시간은 요청 한 번에 걸리는 시간이고, 처리량은 경로의 대역폭과 혼잡도, 서버, 다운로드 대상의 영향을 받습니다. 같은 시간대에 같은 대상을 이용해 두 서버를 비교하세요. 속도 테스트를 여러 개 동시에 실행하지 말고 구독 트래픽 사용량도 확인하세요.

서버를 바꿨는데 외부 IP가 그대로입니다. 전환에 실패한 건가요?

서로 다른 접속 서버가 같은 외부 출구를 공유할 수 있습니다. 활성 서버 표시와 새 요청의 로그를 확인한 뒤 새 요청으로 다시 테스트하세요. 브라우저에서 이미 열려 있는 장시간 연결은 바로 바뀌지 않을 수 있습니다. 요청이 직접 연결 규칙에 해당한다면 서버를 바꿔도 외부 IP는 달라지지 않습니다.

다시 사용할 수 있도록 연결 정보 기록하기

첫 연결이 완료되면 서버 이름, 프로토콜과 전송 방식의 조합, 로컬 수신 포트, 테스트 대상, 라우팅 모드, 테스트 시간을 기록하세요. 나중에 문제가 생겼을 때 같은 절차로 다시 확인하면 서버 변경, 로컬 설정 변경, 대상 사이트 문제를 구분하기 쉽습니다.

클라이언트 다운로드