V2Ray 첫 연결 방법: 노드 선택, 실제 연결 지연 테스트와 출구 IP 확인

이 글의 핵심

처음 연결할 때는 ‘구독 업데이트, 후보 노드 추리기, 실제 연결 지연 테스트, 활성 서버 지정, 시스템 프록시 켜기, 출구 확인’ 순서로 진행하세요. 이 글은 Windows용 v2rayN을 기준으로, 구독 주소는 있지만 노드가 실제로 작동하는지 확신이 없는 사용자를 위해 설명합니다. 테스트 결과와 브라우저 접속, 출구 IP를 함께 확인해야 합니다. 서버 목록에 지연 시간이 표시된다는 이유만으로 연결에 성공했다고 판단하지 마세요.

구독 그룹과 노드 출처 확인

먼저 클라이언트, 코어, 구독의 역할을 구분하세요. v2rayN은 구독 그룹과 노드, 프록시 설정을 관리하고 실제 연결은 코어가 담당합니다. 구독 주소에는 노드 설정이 들어 있으며 클라이언트 다운로드 주소가 아닙니다. 구독 업데이트에 성공했다는 것은 이번에 해석 가능한 설정을 가져왔다는 뜻일 뿐, 현재 네트워크에서 모든 서버에 연결할 수 있다는 의미는 아닙니다.

이 글은 v2rayN의 일반적인 한국어 UI를 기준으로 설명합니다. 버전에 따라 메뉴 위치나 단축키가 달라질 수 있으므로 실제 조작 시에는 화면에 표시된 메뉴 이름을 확인하세요. 처음 문제를 확인할 때는 TUN을 꺼 두세요. 시스템 프록시와 함께 요청을 처리하면 트래픽이 어느 경로로 전달되는지 판단하기 어려워집니다.

그룹 확인

상단 메뉴에서 ‘구독 그룹’ → ‘구독 그룹 설정’을 열고 대상 그룹의 구독 주소를 확인하세요. ‘추가’로 그룹을 만들었다면 출처를 구분할 수 있는 설명을 입력하세요. 로그인 페이지 주소를 구독 주소 입력란에 넣지 마세요.
구독 업데이트

‘구독 그룹’ 메뉴로 돌아가세요. 사용할 수 있는 프록시가 없다면 처음에는 ‘모든 구독 업데이트(프록시 사용 안 함)’를 선택하세요. 구독 서버에 접속할 때 프록시가 필요한 경우에는 먼저 정상 연결을 확보한 뒤, 프록시를 통해 업데이트하는 항목을 선택하세요.
후보 노드 추리기

방금 업데이트한 구독 그룹으로 전환하고, 현재 회선에 적합하고 용도가 명확하다고 서비스 제공자가 표시한 노드 두세 개를 먼저 선택하세요. 지역명은 설명일 뿐 실제 출구 위치를 뜻하지 않으며 속도를 보장하지도 않습니다.
테스트 실행

후보 노드를 선택하고 마우스 오른쪽 버튼을 눌러 ‘서버 실제 연결 지연 테스트’를 실행하세요. 이번 테스트가 끝난 뒤 결과를 비교하세요. 구독 업데이트, 일괄 속도 측정, 활성 서버 전환을 동시에 진행하지 마세요.
노드 활성화

테스트에 성공한 후보를 마우스 오른쪽 버튼으로 클릭하고 ‘활성 서버로 설정’을 선택하세요. 활성 표시가 바뀌었는지 확인한 다음 로그에 코어 시작 오류가 있는지 살펴보세요. 목록에서 행 하나를 마우스로 선택하는 것만으로는 현재 연결에 사용하는 서버가 바뀌지 않을 수 있습니다.

TCPing과 실제 연결 지연 테스트 구분

TCPing은 주로 서버의 대상 포트에 TCP 연결을 설정할 수 있는지 확인합니다. 구독에 포함된 사용자 식별 정보, TLS 설정, 프록시 프로토콜 핸드셰이크가 올바른지는 확인하지 않으며, 프록시를 통해 대상 웹페이지를 열 수 있는지도 검사하지 않습니다. 포트에 연결할 수 있지만 프로토콜 인증에 실패해도 TCPing에는 숫자가 표시될 수 있습니다.

실제 연결 지연 테스트는 노드를 통해 실제 테스트 요청을 보내므로 TCPing보다 앱 접속 상황에 가깝습니다. 다만 결과는 테스트 주소, DNS, 제한 시간, 노드 출구, 클라이언트 구현 방식에 영향을 받습니다. 테스트 성공은 이번 요청이 완료됐다는 뜻이지 모든 사이트에 접속할 수 있다는 뜻은 아니며, 다운로드 대역폭을 나타내지도 않습니다.

TCPing

테스트 대상: 서버 주소와 TCP 포트
확인 범위: 기본 TCP 연결 가능 여부
확인할 수 없는 항목: 프로토콜 인증, TLS, 웹페이지 접속 성공 여부
사용 시점: 주소나 포트에 연결할 수 있는지 확인할 때

네트워크 연결 가능 여부를 1차 확인할 때 유용하지만 프록시 경로 테스트를 대신할 수는 없습니다.

실제 연결 지연 테스트

테스트 대상: 노드를 통해 전송하는 테스트 요청
확인 범위: 현재 설정과 테스트 대상 사이의 연결 경로
확인할 수 없는 항목: 지속적인 대역폭, 모든 사이트와 앱의 사용 가능 여부
사용 시점: 처음 노드를 고르거나 연결 문제를 재확인할 때

같은 테스트 주소와 제한 시간 설정을 유지한 채 후보 노드를 비교하세요.

‘설정’ → ‘매개변수 설정’에서 현재 버전의 실제 연결 테스트 주소와 제한 시간 설정을 확인하세요. 지연 시간을 보기 좋게 만들려고 테스트 대상을 계속 바꾸지 마세요. 모든 노드가 실패한다면 먼저 이 기기에서 관련 도메인을 확인할 수 있는지, 시스템 시간이 올바른지, 테스트 주소에 일시적으로 접속할 수 없는 상태인지 점검하세요. 구독 전체가 잘못됐다고 바로 단정하지 마세요.

숫자가 표시됨: 이번 테스트에서 결과를 받았다는 뜻입니다. 브라우저로 이어서 확인하고, 같은 네트워크와 같은 테스트 대상에서 여러 번 측정한 결과를 비교하세요.
시간 초과 또는 실패 표시: 로그에서 연결 시간 초과, 인증서 오류, 인증 실패를 구분하세요. 음수 값 하나만 보고 원인을 추측하지 마세요.
측정값의 편차가 큼: 잠시 뒤 다시 테스트하고 대역폭을 사용하는 작업을 중단하세요. 한 번 측정한 최저값만으로 순위를 매겨 결론 내리지 마세요.

시스템 프록시를 켜고 로컬 포트 확인

활성 서버를 지정한 뒤에는 앱의 요청을 클라이언트로 보내야 합니다. Windows에서는 v2rayN 트레이 아이콘을 마우스 오른쪽 버튼으로 클릭한 다음 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 선택할 수 있습니다. 처음 확인할 때는 시스템 프록시를 따르는 브라우저를 사용하세요. 일부 명령줄 도구, 게임, 자체 프록시를 설정한 앱은 이 설정을 자동으로 사용하지 않습니다.

시스템 프록시

권장

먼저 브라우저로 기본 연결 경로를 확인하세요. 시스템 프록시를 켠 뒤 프록시 주소가 이 기기를 가리키는지, 포트가 v2rayN의 현재 인바운드 리스닝 포트와 일치하는지 확인하세요. 테스트를 마치면 ‘시스템 프록시 지우기’를 선택하세요.

적합한 경우: 첫 연결 확인, 브라우저 접속, 문제 단계별 진단

TUN 모드

가상 네트워크 인터페이스와 라우팅, 관련 권한이 필요하며 시스템 프록시를 따르지 않는 트래픽을 처리할 때 적합합니다. 문제를 확인할 변수가 늘어나므로 노드가 작동하는지 확인하기 전에는 함께 켜지 않는 것이 좋습니다.

적합한 경우: 기본 연결을 확인한 뒤 더 많은 앱의 트래픽을 처리해야 할 때

‘설정’ → ‘매개변수 설정’에서 로컬 리스닝 설정을 확인하고, Windows의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에 있는 수동 프록시 주소와 비교하세요. 아래 숫자는 설명을 위한 설정 예시이며 모든 버전의 기본값을 의미하지 않습니다. 현재 클라이언트에 표시되는 값을 기준으로 하세요.

10808

로컬 HTTP 또는 혼합 인바운드 포트 예시

127.0.0.1

원격 서버가 아닌 로컬 루프백 주소

443

HTTPS에서 흔히 사용하는 대상 포트이며 로컬 프록시 포트가 아닙니다

로컬 프록시 포트에 노드의 원격 포트를 그대로 입력하면 안 됩니다. 로그에 address already in use 또는 바인딩 실패가 표시되면 해당 리스닝 포트를 다른 프로세스가 사용 중일 수 있습니다. 중복 실행된 클라이언트를 종료한 뒤 포트를 확인하세요. 포트를 변경한 다음에는 시스템 프록시도 다시 적용해야 합니다. 그렇지 않으면 시스템이 이전 포트를 계속 가리킵니다.

출구 IP와 라우팅 분기 확인

요청을 보낸 IP를 표시하는 확인 페이지를 선택하고, 먼저 현재 적용 중인 라우팅 규칙을 확인하세요. 프록시 출구를 확인하려면 라우팅 설정에서 전역 프록시 규칙을 잠시 적용해 비교한 뒤, 확인을 마치면 평소 사용하는 분기로 되돌리세요. 전역 프록시는 라우팅 선택 방식이지, 기기의 모든 앱이 자동으로 프록시를 사용한다는 뜻은 아닙니다.

직접 연결 기준값 기록. TUN을 끄고 ‘시스템 프록시’ → ‘시스템 프록시 지우기’를 선택한 뒤 확인 페이지를 새로고침해 현재 공인 출구 IP를 기록하세요. 브라우저에 별도의 프록시 설정이 있다면 먼저 끄고 테스트 조건을 하나로 유지하세요.
프록시 비교 결과 확인. ‘시스템 프록시 자동 설정’을 다시 적용하고 활성 서버가 테스트에 성공한 노드와 같은지 확인한 뒤, 같은 확인 페이지를 새로고침해 출구 IP를 기록하세요.
요청 경로 확인. 현재 라우팅 규칙과 확인 가능한 로그를 함께 살펴 조회 도메인이 직접 연결되는지 프록시를 거치는지 판단하세요. 노드를 바꾼 뒤 다시 요청하세요. 페이지가 이전 결과를 캐시했다면 새 세션을 열거나 다른 확인 페이지로 교차 검증하세요.
평소 규칙으로 복구. 임시로 적용한 전역 프록시 테스트 설정을 되돌리고 실제로 사용할 사이트에 접속하세요. 확인 페이지에서 검증에 성공했더라도 모든 대상에 라우팅 규칙이 예상대로 적용된다는 뜻은 아닙니다.

IP 위치 정보 데이터베이스는 업데이트가 늦을 수 있으며, 같은 출구라도 서비스마다 다른 도시로 표시될 수 있습니다. 노드 설명, 서버 연결 주소, 출구 IP는 서로 다른 개념입니다. 중계 서버나 출구 게이트웨이를 거치는 경우 세 값이 서로 달라도 정상입니다. 노드 설명의 지역명이 아니라 실제 요청 경로를 기준으로 판단하세요.

브라우저의 시스템 프록시 동작 차이를 피하려면 로컬 HTTP 프록시를 명시해 요청을 보낼 수 있습니다. 아래 명령은 Windows에서 사용할 수 있는 curl.exe용입니다. 10808이 HTTP 또는 혼합 인바운드 포트이며 현재 라우팅에서 대상 요청이 프록시 출구로 전달되는지 확인한 뒤 사용하세요.

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

이 명령은 로컬 인바운드 포트를 통해 예시 사이트에 접속할 때 HTTP 응답 헤더를 받을 수 있는지만 확인하며, 출구 IP는 표시하지 않습니다. 프록시 주소가 http://로 시작해도 대상의 HTTPS 콘텐츠가 평문으로 바뀌는 것은 아닙니다. HTTPS 대상에 접속할 때는 일반적으로 HTTP CONNECT로 터널을 설정합니다. 응답을 받더라도 출구 IP는 별도로 확인해야 하며, 시간 초과가 발생하면 로그를 통해 실패한 단계를 찾아보세요.

실패한 단계별로 첫 연결 문제 해결

현재 노드와 테스트 시간, 오류 원문을 기록하고 한 번에 한 항목만 변경하세요. 노드 변경, DNS 수정, 로컬 포트 변경, TUN 활성화를 한꺼번에 하면 접속이 복구되더라도 어떤 설정이 효과가 있었는지 알기 어렵습니다. 스크린샷을 찍거나 로그를 공유하기 전에 구독 주소와 사용자 식별 정보, 기타 인증 정보를 삭제하세요.

TCPing에는 숫자가 표시되지만 실제 연결 지연 테스트는 시간 초과되나요?

먼저 같은 구독 그룹의 다른 후보 노드에서 실제 연결 지연 테스트를 실행하세요. 특정 노드 하나만 실패한다면 해당 노드의 프로토콜과 TLS 매개변수가 완전한지 확인하고, 우선 구독을 다시 업데이트하세요. SNI 값을 추측해서 바꾸지 마세요. 모든 노드가 실패한다면 테스트 주소와 로컬 네트워크, 로그를 확인하세요.

실제 연결 지연 테스트는 성공했는데 브라우저에서 열리지 않나요?

먼저 ‘시스템 프록시’가 ‘시스템 프록시 자동 설정’으로 되어 있는지 확인한 다음, 시스템 프록시 포트와 로컬 리스닝 포트를 비교하세요. 브라우저의 별도 프록시 설정을 잠시 끄고 다른 브라우저로 다시 테스트하세요. 프록시를 명시한 명령은 성공하지만 브라우저에서는 실패한다면 브라우저와 시스템 프록시 계층을 먼저 점검하세요.

출구 IP가 바뀌지 않으면 노드가 적용되지 않은 건가요?

꼭 그렇지는 않습니다. 먼저 TUN이 꺼져 있고 브라우저가 시스템 프록시를 사용하는지 확인한 다음, 조회 도메인에 직접 연결 규칙이 적용되는지 살펴보세요. 라우팅 규칙을 잠시 전역 프록시로 바꾸고 다시 요청하세요. 두 후보가 원래 같은 출구를 공유하는 경우도 고려해야 합니다. 노드를 바꾼 뒤 IP가 바뀌는지만으로 결론 내리지 마세요.

웹페이지는 열리는데 다른 앱은 연결되지 않나요?

먼저 해당 앱이 시스템 프록시를 지원하는지, 또는 HTTP·SOCKS 프록시를 직접 설정할 수 있는지 확인하세요. 직접 설정할 수 있다면 클라이언트에 실제로 제공되는 프로토콜과 포트를 입력해야 합니다. TUN이 꼭 필요하다면 그때 문서에 따라 권한, DNS, 라우팅을 설정하세요. 첫 연결을 확인할 때 두 경로를 함께 사용하지 마세요.

클라이언트를 종료한 뒤 브라우저가 인터넷에 연결되지 않나요?

Windows의 수동 프록시가 더 이상 리스닝하지 않는 로컬 포트를 가리키는지 확인하세요. v2rayN을 다시 실행하고 ‘시스템 프록시’ → ‘시스템 프록시 지우기’를 선택하거나, 시스템 설정에서 테스트 중 추가한 프록시 설정을 삭제하세요. 조직에서 관리하는 기기라면 기존 프록시 정책을 먼저 확인하고 관리 설정을 덮어쓰지 마세요.

첫 연결 확인 결과 저장

첫 연결이 끝난 뒤에는 최저 지연 시간을 기억하는 것보다 재현 가능한 점검 기록을 남기는 편이 유용합니다. 네트워크와 구독 내용, 노드 출구는 바뀔 수 있습니다. 다음에 문제가 생겼을 때 같은 절차로 비교하면 원인이 구독 업데이트, 코어 연결, 앱 연결, 라우팅 분기 중 어디에 있는지 판단할 수 있습니다.

설정 확인: 클라이언트 버전, 구독 그룹 이름, 활성 노드 설명, 테스트 시간을 기록하세요. 공개 문서에는 구독 인증 정보를 저장하지 마세요.
연결 경로 확인: 실제 연결 지연 테스트를 한 번 이상 실행하고 HTTPS 사이트에 실제로 접속하세요. TCPing 결과만으로 연결을 완전히 확인했다고 판단하지 마세요.
출구 확인: 확인 대상과 당시의 라우팅 규칙, 출구 결과를 기록하세요. 서로 다른 규칙에서 얻은 결과를 나중에 그대로 비교하지 않도록 주의하세요.
설정 복구 확인: 평소 사용하는 라우팅 분기로 되돌리고, 클라이언트를 종료한 뒤 시스템 프록시 상태가 예상대로인지 확인하세요. 작동하지 않는 포트를 가리키는 설정이 남지 않도록 하세요.

구독 가져오기와 프록시 설정을 다시 확인하려면 구독 그룹 사용법, 실제 연결 지연 안내, 시스템 프록시 설정을 참고하세요. 시스템 프록시를 따르지 않는 앱의 트래픽을 처리해야 한다면 TUN 설정 방법을 확인하세요. 아직 원인을 찾지 못한 기본 연결 문제를 더 복잡한 트래픽 처리 방식으로 덮지 마세요.