V2Ray 처음부터 제대로
클라이언트 설정 완벽 가이드

1단계 · 기본 개념 익히기

핵심 개념: 연결은 어떤 과정을 거칠까?

V2Ray는 여러 프록시 기술을 통칭하는 이름으로 자주 쓰이지만, 실제 사용 시에는 그래픽 클라이언트, 프록시 코어, 연결 설정, 원격 서버를 구분해야 합니다. 그래픽 클라이언트는 구독을 가져오고 설정을 저장한 뒤 코어를 실행합니다. 코어는 연결을 받아 라우팅을 판단하고 외부 연결을 처리합니다. 화면에 실행 중이라고 표시되어도 로컬 프로세스가 작동한다는 뜻일 뿐, 원격 서버에 연결할 수 있거나 브라우저 요청이 클라이언트로 전달된다는 보장은 없습니다.

클라이언트, 코어, 서버의 차이

Project V는 이 생태계를 이해하는 출발점입니다. V2Fly는 V2Ray 관련 개발을 이어 가고 있으며, Xray는 별도의 코어 구현으로 발전했습니다. 일부 개념은 공유하지만 지원 기능과 설정 항목이 완전히 같지는 않습니다. v2rayN은 데스크톱용 그래픽 클라이언트이고 v2rayNG와 v2flyNG는 안드로이드용입니다. 어떤 화면을 선택하든 모든 프로토콜을 사용할 수 있는 것은 아닙니다. 실제 지원 여부는 클라이언트와 함께 실행되는 코어를 기준으로 확인해야 합니다.

한 번의 접속을 앱, 진입점, 라우팅, 출구의 네 단계로 나눠 볼 수 있습니다. 앱에서 프록시 사용 여부를 결정하고, 진입점은 로컬 HTTP·SOCKS 포트 또는 가상 네트워크 인터페이스일 수 있습니다. 라우팅은 도메인이나 주소 등의 조건에 따라 출구를 고르고, 출구는 연결 설정을 사용해 서버와 통신합니다. 어느 한 단계라도 설정이 맞지 않으면 접속 문제가 생길 수 있으므로 노드만 계속 바꾸기보다 이 연결 흐름을 따라 하나씩 확인하세요.

프로토콜, 전송 방식, 보안 설정

VMess와 VLESS는 프록시 프로토콜이고 TCP, WebSocket, gRPC는 연결을 전달하는 전송 방식입니다. TLS와 REALITY는 연결 보안과 관련된 기술입니다. 서로 바꿔 쓸 수 있는 같은 종류의 옵션이 아닙니다. 가져온 설정은 제공된 조합 그대로 유지하세요. 전송 방식을 임의로 바꾸거나 이름만 보고 보안 옵션을 추가하면 연결이 나아지기보다 클라이언트와 서버의 핸드셰이크 조건이 맞지 않을 수 있습니다.

하나의 설정에서도 서버 주소, 연결 포트, 사용자 식별자, 서버 이름, 전송 경로는 각각 역할이 다릅니다. 서버 이름은 보안 핸드셰이크에 사용될 수 있어 주소의 호스트 이름과 다를 수도 있습니다. 경로는 대개 특정 전송 방식에 속하므로 주소 항목에 입력하면 안 됩니다. 매개변수를 확인할 때는 먼저 어느 계층에 속하는지 파악한 뒤 해당 설정 화면을 살펴보세요. 의미가 불분명한 항목은 검색 결과의 예시로 덮어쓰기보다 설정 제공자에게 확인하는 편이 안전합니다.

구독과 로컬 설정의 차이

구독은 연결 정보를 여러 개 가져오는 수단이지, 그 자체로 작동하는 연결은 아닙니다. 구독을 업데이트한 뒤에도 클라이언트에서 설정을 선택하고 서비스나 시스템 프록시를 실행해야 하는 경우가 많습니다. 구독 주소가 열리는 것은 해당 주소에 접속할 수 있다는 뜻일 뿐, 목록의 모든 서버에 연결할 수 있다는 의미는 아닙니다. 반대로 기존 설정으로 연결되더라도 구독 업데이트가 실패할 수 있습니다. 두 요청이 서로 다른 네트워크 경로를 사용할 수 있기 때문입니다.

로컬 포트는 앱이 클라이언트에 접속하는 입구이고, 원격 포트는 클라이언트가 서버에 연결할 때 사용하는 대상 포트입니다. 두 포트가 같을 필요는 없습니다. 예를 들어 로컬 포트가 10808이라고 해서 구독에 포함된 원격 포트를 바꾸면 안 됩니다. 해당 로컬 포트가 어떤 프로토콜을 지원하는지도 확인하세요. 버전에 따라 HTTP와 SOCKS 포트가 따로 있거나 하나의 혼합 포트를 제공할 수 있으므로 현재 클라이언트의 설정 화면을 기준으로 판단해야 합니다.

2단계 · 도구 선택하기

클라이언트 선택: 플랫폼을 먼저, 코어는 다음에

클라이언트를 고를 때는 먼저 실행할 플랫폼을 정한 뒤 인터페이스와 코어를 살펴보세요. 데스크톱에서는 Windows, macOS, Linux에서 비슷한 방식으로 사용할 수 있는 v2rayN을 우선 고려하고, 안드로이드에서는 v2rayNG를 선택하면 됩니다. V2Fly 코어의 동작이 필요하거나 특정 설정과의 호환성이 확인된 경우에만 v2flyNG를 고려하세요. 여러 클라이언트를 설치해도 사용할 수 있는 연결이 늘어나는 것은 아닙니다. 처음에는 주로 사용할 클라이언트 하나만 두는 편이 설정을 파악하기 쉽습니다.

데스크톱 버전과 아키텍처

Windows용 v2rayN 다운로드에는 데스크톱 버전과 클래식 WPF 버전이 있습니다. 데스크톱 버전은 크로스 플랫폼 인터페이스를 지향하고, 클래식 WPF 버전은 다른 화면 구성을 사용합니다. 시스템 요구 사항과 기존 사용 방식, 필요한 기능을 기준으로 선택하세요. 두 다운로드 항목이 서로 다른 프록시 프로토콜을 뜻하는 것은 아닙니다. 두 버전 모두 연결 정보를 읽고 코어, 로컬 포트, 프록시 모드를 확인해야 하므로 익숙한 인터페이스만으로 설정이 올바르다고 판단해서는 안 됩니다.

macOS에서는 시스템의 기기 정보에서 칩 종류를 확인한 뒤 Apple Silicon 또는 Intel용 파일을 선택하세요. Linux에서는 프로세서 아키텍처와 배포판의 패키지 형식을 함께 확인해야 합니다. 보통 deb와 rpm 중 하나를 고르며 arm64 기기라면 해당 아키텍처용 패키지도 선택해야 합니다. 패키지 형식과 프로세서 아키텍처는 별개의 조건이므로 하나만 맞으면 설치나 실행이 되지 않을 수 있습니다.

안드로이드용 두 가지 코어 경로

v2rayNG는 주로 Xray 코어를 사용하고, v2flyNG는 V2Fly 코어를 사용합니다. 화면이나 일부 조작 방식이 비슷하더라도 모든 가져오기 형식과 프로토콜 확장이 서로 호환된다고 볼 수는 없습니다. 특정 코어 전용 기능을 사용하는 설정이라면 먼저 지원 여부를 확인하세요. 가져온 설정에서 항목이 누락되거나 인식되지 않고 연결도 실패한다면 서버 문제로 단정하기 전에 코어와 설정 형식이 맞는지 살펴보세요.

안드로이드 설치 패키지의 arm64 버전은 비교적 최신인 대부분의 기기에 적합합니다. 기기 아키텍처를 모르는 경우 범용 패키지를 선택할 수 있지만, 실제 지원 여부는 앱 요구 사항을 확인해야 합니다. 휴대전화의 출시 연도만으로 아키텍처를 추측하지 말고 시스템 정보나 기기 사양을 확인하세요. 설치 패키지 용량이 기능의 많고 적음을 뜻하는 것은 아닙니다. 범용 패키지는 지원하는 실행 아키텍처의 범위가 더 넓을 수 있지만 네트워크 속도를 높여 주지는 않습니다.

클라이언트 동시 실행으로 인한 충돌 줄이기

클라이언트를 바꿀 때는 기존 프로그램을 완전히 종료한 다음 새 프로그램을 실행하세요. 데스크톱에서는 두 프로그램이 시스템 프록시, 같은 로컬 포트 또는 가상 네트워크 어댑터를 두고 충돌할 수 있습니다. 안드로이드에서는 VPN 권한이 기존 연결에 영향을 줄 수도 있습니다. 창을 닫아도 백그라운드 프로세스가 종료되지 않을 수 있으니 시스템 트레이, 알림 영역 또는 앱 상태를 확인하세요. 두 클라이언트를 비교할 때는 같은 네트워크와 같은 연결 정보를 사용해 회선 차이를 프로그램 차이로 오해하지 않도록 하세요.

다운로드 전에 클라이언트 3종 비교를 확인하고, 설치 파일은 클라이언트 다운로드 페이지에서 받으세요. 이 가이드의 목표는 특정 패키지 이름이나 버전 번호를 외우는 것이 아닙니다. 현재 플랫폼, 프로세서 아키텍처, 클라이언트, 코어가 각각 무엇인지 설명할 수 있어야 합니다. 문제가 생기면 이 네 가지 정보가 단순히 “최신 버전으로 업데이트했다”는 말보다 원인을 좁히는 데 도움이 됩니다.

3단계 · 로컬 환경 준비하기

설치 및 기본 설정: 로컬 서비스부터 확인

설치 단계에서는 고급 옵션을 바로 조정하기보다 프로그램 실행, 설정 저장, 로컬 포트 사용 여부를 먼저 확인합니다. 다운로드 페이지에서 해당 플랫폼의 시스템 요구 사항을 확인한 뒤 일반적인 설치 절차를 따르세요. 처음 클라이언트를 실행한 뒤에는 기본 라우팅과 DNS 설정을 그대로 두고 TUN은 아직 켜지 마세요. 연결이 실패하더라도 여러 네트워크 처리 기능을 한꺼번에 점검하지 않고 기본 경로부터 원인을 좁힐 수 있습니다.

데스크톱 클라이언트 실행 전 확인 사항

Windows 설치 프로그램을 사용한다면 화면 안내에 따라 설치 위치를 정하고 설치를 완료하세요. 압축을 풀어야 하는 배포 파일이라면 먼저 전체 압축을 해제한 다음 실행해야 합니다. 압축 미리보기 화면에서 바로 실행하지 마세요. 설정 폴더는 쓰기 가능한 위치에 두고 임시 폴더나 자동 정리되는 위치는 피하세요. 시스템에서 실행 구성 요소가 없다는 안내가 나오면 클라이언트의 시스템 요구 사항과 구체적인 오류 내용을 확인하고, 출처가 불분명한 같은 이름의 파일을 설치하지 마세요.

macOS에서는 설치 후 일반적인 앱 실행 경로로 시작하세요. 시스템 보안 경고가 표시되면 다운로드 출처와 경고 내용을 확인한 뒤 시스템이 안내하는 절차에 따라 처리하세요. 한 번 설치하려고 보안 기능을 전역으로 끄는 것은 권장하지 않습니다. Linux에서는 배포판에 맞는 패키지 관리 도구를 사용하고 의존성 안내와 그래픽 세션 환경을 확인하세요. 설치는 됐지만 창이 열리지 않는 문제와 코어 실행 실패는 서로 다릅니다. 먼저 메인 프로그램이 열리고 설정 화면에 접근할 수 있는지 확인하세요.

로컬 리스너와 기본 스위치

기본 설정에서 로컬 리스너의 주소, 포트, 유형을 기록해 두세요. 한 대의 기기에서만 사용하는 경우에는 보통 루프백 주소로 충분하며 “LAN 연결 허용”을 켤 필요가 없습니다. 다른 프로그램이 사용 중이 아니라면 기본 포트를 유지해도 됩니다. 포트 바인딩에 실패하면 포트를 바꾸기 전에 같은 프로그램이 중복 실행 중인지, 다른 프록시 도구가 실행 중인지 확인하세요. 로컬 포트를 변경한 경우 수동으로 프록시를 설정한 앱도 함께 수정해야 합니다. 시스템 프록시를 사용한다면 설정을 다시 적용하세요.

“UDP 사용”과 “트래픽 스니핑 사용”은 무조건 속도를 높이는 버튼이 아닙니다. UDP 사용 가능 여부는 앱 진입점, 라우팅, 서버와 전체 연결 경로의 지원 여부에 달려 있습니다. 스니핑은 일부 연결 정보에서 대상 식별을 돕는 기능일 뿐 모든 트래픽을 파악하는 것은 아닙니다. 기본 단계에서는 기존 값을 기록해 두고 명확한 필요가 있을 때 조정하세요. 설정을 저장한 뒤 서비스 재시작 안내가 나오면 현재 연결을 먼저 중지한 다음 안내에 따라 다시 시작하세요.

안드로이드 설치 후 권한 설정

안드로이드에 설치한 뒤 먼저 앱을 열어 설정이 저장되는지 확인하고 연결 정보를 가져오세요. VPN 방식으로 처음 연결하면 시스템 권한 요청이 표시됩니다. 이는 클라이언트가 로컬 네트워크를 제어하는 통로를 만들도록 허용하는 것으로, 원격 서비스를 구매하는 과정이 아닙니다. 권한을 거부하면 설정이 목록에 있어도 해당 방식으로 앱 트래픽을 처리할 수 없습니다. 이미 다른 VPN이 실행 중이라면 먼저 연결을 끊으세요. 시스템이 다른 앱으로 전환된 뒤 현재 클라이언트가 계속 작동하는 것으로 착각할 수 있습니다.

배터리 관리와 백그라운드 제한으로 인해 화면을 잠근 뒤 안드로이드 클라이언트가 중지될 수 있지만, 설치 직후 모든 시스템 최적화 옵션을 바꿀 필요는 없습니다. 먼저 앱을 화면에 띄운 상태에서 연결을 테스트해 작동을 확인한 다음 “화면 잠금 후 연결 끊김”이 발생할 때 백그라운드 권한을 살펴보세요. 앱별 프록시 범위도 처음에는 단순하게 유지하세요. 시작부터 많은 앱을 목록에 추가하면 서비스가 실행되지 않은 것인지, 테스트 앱이 처리 대상에서 제외된 것인지 구분하기 어려워집니다.

초기 설정 상태 기록하기

기본 환경을 준비한 뒤 클라이언트 이름, 운영체제, 로컬 포트, 현재 스위치 상태를 기록해 두세요. 설정을 내보내거나 백업할 때 연결 자격 증명이 포함될 수 있으므로 전체 파일을 공개 게시판에 올리지 마세요. 프로그램을 종료했다 다시 실행해도 설정이 유지되는지 확인하세요. 재시작할 때마다 설정이 사라진다면 반복 설치하기보다 설정 폴더의 쓰기 권한이나 시스템의 자동 정리 문제부터 해결해야 합니다.

4단계 · 연결 정보 가져오기

구독 가져오기: 업데이트, 선택, 연결 구분하기

구독 주소에는 계정을 식별할 수 있는 매개변수가 포함되는 경우가 많으므로 자격 증명처럼 취급하세요. 화면을 공개하거나 전체 링크를 포럼에 올리지 마세요. 복사할 때 계정 관리 페이지나 도움말 페이지, 브라우저 로그인 후의 페이지 주소가 아니라 실제 구독 주소인지 확인하세요. 모든 클라이언트에서 통용되는 단일 구독 형식은 없습니다. 제공자가 클라이언트별 형식을 안내한다면 맞는 형식을 선택해야 프로토콜 관련 항목이 누락되는 일을 줄일 수 있습니다.

데스크톱에서 구독 그룹 만들기

v2rayN의 구독 그룹 관리에서 새 그룹을 만들고 알아보기 쉬운 이름과 구독 주소를 입력한 뒤 저장하고 구독을 업데이트하세요. 그룹 이름은 로컬에서 정리할 때만 사용되며 원격 설정에는 영향을 주지 않습니다. 업데이트가 끝나면 그룹에 선택 가능한 항목이 나타나는지 확인한 뒤 사용할 항목을 선택하세요. 그룹을 저장했다고 구독이 업데이트된 것은 아니며, 목록에 항목이 있다고 현재 연결된 것도 아닙니다.

첫 업데이트는 가능하면 현재 사용할 수 있는 직접 연결 경로로 진행하세요. 해당 구독 주소에 프록시 접속이 반드시 필요하다면 먼저 작동하는 연결을 확보한 다음 클라이언트의 프록시 경유 업데이트 기능을 사용하세요. 사용 가능한 연결이 하나도 없는데 아직 작동하지 않는 프록시에 구독 업데이트를 의존하면 순환 문제가 생길 수 있습니다. 네트워크 제한이 있는 경우 링크 매개변수를 임의로 고치지 말고 제공자에게 구독 주소에 접속할 수 있는지 확인하세요.

안드로이드에서 가져오고 확인하기

v2rayNG와 v2flyNG에서는 각 앱의 구독 관리 메뉴에서 연결 정보를 추가할 수 있습니다. 메뉴 이름은 현재 화면에 따라 다를 수 있습니다. 업데이트 후 설정 목록으로 돌아가 사용할 항목을 선택하고 연결을 시작하세요. 클립보드 가져오기, QR 코드 가져오기, 구독 업데이트는 서로 다른 작업입니다. 앞의 두 방법은 단일 연결만 추가하고 이후 업데이트 연결을 만들지 않을 수도 있습니다. 정보를 계속 동기화하려면 한 번만 가져온 항목이 아니라 구독 그룹에 저장됐는지 확인하세요.

가져온 뒤 프로토콜, 주소, 포트, 전송 방식, 보안 설정이 모두 있는지 확인하세요. 이름은 제공자가 임의로 정할 수 있으므로 이름만 보고 설정이 일치한다고 판단하면 안 됩니다. 중복 항목이 있으면 바로 전부 삭제하지 말고 먼저 그룹과 출처를 확인하세요. 전송 매개변수만 다른 항목일 수도 있습니다. 직접 수정해야 한다면 별도 설정으로 복사하는 편이 좋습니다. 구독을 다음에 업데이트할 때 수정 내용이 덮어써져 원인을 재현하기 어려워지는 일을 막을 수 있습니다.

업데이트 실패 원인 단계별 확인

업데이트 중 파싱 오류가 발생하면 응답 내용이 실제로 클라이언트가 지원하는 구독 형식인지 확인하세요. 주소 만료, 계정 로그인 필요, 웹사이트의 인증 페이지 응답 등이 있으면 “주소는 열리지만 파싱되지 않는” 상황이 생길 수 있습니다. 연결 시간 초과가 발생하면 먼저 네트워크와 도메인 확인을 살펴보세요. 웹페이지 응답을 설정 항목에 그대로 붙여 넣거나 일반 형식으로 변환해 원본을 덮어쓰지 마세요. 변환 과정에서 특정 코어에 필요한 확장 항목이 누락될 수 있습니다.

구독을 업데이트한 뒤 항목 수가 줄어도 로컬 데이터가 손상된 것은 아닐 수 있습니다. 제공자가 목록을 변경했을 가능성도 있습니다. 이전 설정이 여전히 작동하는지 기록하고 그룹과 업데이트 시각을 확인하세요. 목록을 계속 지우고 다시 가져오면 비교에 필요한 단서를 잃게 됩니다. 기존 항목은 작동하지만 새 항목이 모두 실패한다면 새 설정과 기존 설정의 프로토콜, 전송 방식, 보안 항목을 비교하고 클라이언트 코어가 변경 사항을 지원하는지 확인하세요.

구독 보안과 관리 시 유의점

구독 제공자는 내려받는 연결 정보를 바꿀 수 있으므로 출처가 명확하고 실제로 필요한 구독만 유지하세요. 그룹을 삭제하기 전에 개별 설정을 남겨야 하는지 확인하고, 기기를 옮길 때는 표시 이름만 복사하지 말고 클라이언트가 지원하는 내보내기나 다시 가져오기 기능을 사용하세요. 구독 링크가 공개됐다면 제공자 관리 페이지에서 관련 자격 증명을 변경해야 합니다. 로컬 그룹 이름만 바꿔서는 기존 링크가 무효화되지 않습니다.

5단계 · 앱 진입점 확인하기

프록시 모드: 시스템 설정과 앱 동작

프록시 모드는 “앱이 연결을 어떻게 클라이언트에 전달하는가”를, 라우팅 모드는 “연결을 받은 뒤 어디로 내보내는가”를 설명합니다. 이 두 단계는 나눠서 확인해야 합니다. 시스템 프록시를 켜고 중국 본토 트래픽 우회 모드를 선택했다고 모든 앱이 클라이언트를 사용하는 것은 아닙니다. 반대로 가상 네트워크 인터페이스로 트래픽을 처리해도 모든 대상이 원격 서버를 경유하는 것은 아닙니다. 먼저 앱의 진입 경로를 확인해야 이후 분기와 DNS 문제를 정확히 살펴볼 수 있습니다.

데스크톱 시스템 프록시의 적용 범위

v2rayN에서 시스템 프록시를 자동 설정하면 현재 운영체제나 데스크톱 환경의 프록시 설정이 바뀌며, 해당 설정을 따르는 앱에서 이를 사용합니다. 브라우저는 대체로 시스템 설정을 읽지만 일부 다운로드 프로그램, 게임, 명령줄 도구는 자체 네트워크 설정을 사용할 수 있습니다. 시스템 프록시가 켜져 있는데 특정 앱만 직접 연결한다면 노드를 바꾸거나 전역 라우팅을 켜기 전에 해당 앱이 시스템 프록시를 따르는지 확인하세요.

앱에 프록시를 직접 입력할 때는 클라이언트가 실제로 제공하는 진입점 유형, 주소, 포트를 사용하세요. 포트 번호만 보고 HTTP와 SOCKS 중 어느 쪽인지 추측하면 안 됩니다. 혼합 포트도 현재 버전에서 실제로 제공되는지 확인하세요. 한 대의 기기에서 테스트할 때는 보통 루프백 주소를 입력합니다. 앱의 “로컬 주소 우회”나 “별도 DNS 사용” 설정도 연결 경로를 바꿀 수 있으므로 기존 값을 기록한 뒤 프록시 설정을 명확히 지원하는 앱으로 먼저 확인하세요.

직접 제어할 수 있는 요청으로 진입점 확인

아래 명령은 curl이 설치된 환경에서만 사용할 수 있습니다. 실행 전에 포트가 클라이언트 설정과 일치하는지 확인하세요. 이 명령은 로컬 SOCKS 진입점을 명시적으로 사용하고 대상 도메인 처리를 프록시에 맡깁니다. 시스템 프록시나 구독 설정은 변경하지 않습니다. 예시 대상은 공개 테스트 사이트지만 결과는 현재 네트워크 환경에 따라 달라질 수 있습니다. 클라이언트가 해당 포트에서 SOCKS를 제공하지 않는다면 실제 진입점에 맞게 수정해야 합니다. 그대로 실행한 뒤 서비스 장애라고 단정하지 마세요.

curl --proxy socks5h://127.0.0.1:10808 --head --connect-timeout 10 https://example.com

프록시를 명시한 요청은 성공하지만 브라우저에서 접속되지 않는다면 브라우저 프록시, 확장 프로그램, 캐시 또는 개별 네트워크 설정이 원인일 가능성이 큽니다. 둘 다 실패하면 클라이언트 로그에 요청이 들어왔는지 확인하세요. 로그에 요청이 없다면 로컬 진입점을 먼저 살펴보세요. 요청이 기록됐지만 외부 연결에 실패했다면 그때 원격 서버, 라우팅, DNS를 확인하세요. 테스트 대상을 하나로 고정하고 시간을 기록하면 서로 다른 요청의 로그를 혼동하지 않습니다.

안드로이드 VPN과 앱별 프록시

안드로이드 VPN 모드는 시스템 인터페이스를 통해 트래픽을 처리하므로 일반 브라우저에 루프백 프록시를 직접 입력할 필요가 없습니다. 앱별 프록시는 어떤 앱을 VPN 경로에 포함하거나 제외할지 결정하며, 목록이 포함 방식인지 제외 방식인지는 현재 화면의 설명을 확인해야 합니다. 테스트 앱이 제외되어 있으면 알림 영역에 연결 중이라고 표시되어도 예상한 경로로 접속되지 않습니다. 목록을 변경한 뒤 다시 연결해야 한다면 클라이언트 안내를 따르세요.

앱이 VPN 처리 대상인지 판단할 때 페이지가 열리는지만 보면 안 됩니다. 직접 연결로도 성공할 수 있기 때문입니다. 클라이언트 로그와 직접 제어할 수 있는 요청을 함께 확인하세요. 안드로이드 앱은 백그라운드 프로세스, 내장 브라우저, 별도 서비스가 있을 수 있어 같은 앱 이름으로 실행되는 요청도 서로 다를 수 있습니다. 먼저 간단한 브라우저 상황에서 기본 경로를 확인한 뒤 특정 앱을 점검하면 로그인 상태와 백그라운드 캐시로 인한 혼란을 줄일 수 있습니다.

종료와 복구도 중요합니다

데스크톱에서 사용을 마칠 때는 시스템 프록시가 해제되거나 이전 설정으로 복원됐는지 확인하세요. 프로세스만 강제 종료하면 시스템이 더 이상 존재하지 않는 로컬 포트로 연결을 보내 전체 사이트에 접속할 수 없는 것처럼 보일 수 있습니다. 네트워크 자체가 끊긴 것은 아닐 수 있습니다. 안드로이드에서는 VPN 연결이 해제됐는지 확인하세요. 새 모드를 테스트하기 전에 기존 모드를 끄는 방법부터 알아 두고, 전환 후에는 영향을 받는 앱을 다시 시작해 이전 연결이 재사용되지 않도록 하세요.

6단계 · 연결 경로 제어하기

라우팅 분기와 DNS: 규칙과 이름 확인의 조합

라우팅 분기는 연결이 코어에 들어온 뒤 도메인, 대상 주소, 포트 등 사용할 수 있는 조건에 따라 출구를 선택합니다. 클라이언트의 “중국 본토 우회”, “전역” 같은 사전 설정은 규칙 모음에 접근하는 방식이지 프로토콜 자체가 아닙니다. 전역 모드는 보통 처리 대상으로 들어온 트래픽을 프록시 출구로 보내지만 앱 진입점과 사전 설정의 예외 규칙에는 여전히 영향을 받습니다. 특정 연결이 원격 서버를 경유한다고 모드 이름만 보고 판단하지 말고 실제 규칙 매칭 결과를 확인하세요.

규칙 순서와 매칭 조건

라우팅 규칙은 대부분 순서대로 검사합니다. 구체적인 규칙이 더 넓은 범위의 규칙에 가려지지 않도록 앞에 배치해야 합니다. 예를 들어 특정 도메인에 직접 연결 예외를 추가하기 전에 기존 규칙이 앞에서 이미 일치하는지 확인하세요. 도메인 규칙은 코어가 대상 도메인을 알아야 적용됩니다. 앱이 주소만 전달하고 진입점이 도메인 정보를 보존하지 않는다면 도메인 규칙을 추가해도 효과가 없을 수 있습니다. 스니핑은 일부 상황에서 식별에 도움을 주지만 모든 요청의 원본 정보를 대신하지는 않습니다.

아래는 정확한 도메인 규칙의 작성법을 설명하는 Xray 라우팅 객체의 일부 예시이며, 완성된 클라이언트 설정은 아닙니다. 전체 설정에 direct라는 이름의 출구가 있어야 이 규칙이 대상으로 작동합니다. 그래픽 클라이언트가 라우팅과 출구 레이블을 자동으로 생성할 수 있으므로 아무 입력란에나 이 코드를 붙여 넣지 마세요. 먼저 사용자 지정 규칙 화면에서 같은 의미를 설정하고 생성된 결과를 확인하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

V2Ray DNS 설정의 계층 구조

DNS는 클라이언트 설정 화면의 서버 목록만으로 결정되지 않습니다. 운영체제 리졸버, 브라우저의 암호화 DNS, 앱 내부 DNS, 코어 DNS가 요청에 관여할 수 있습니다. 앱이 먼저 주소를 조회한 뒤 연결하면 코어는 원래 도메인을 알지 못할 수 있습니다. 앱이 도메인을 프록시에 전달하는 경우에는 다른 쪽에서 이름을 확인할 수도 있습니다. DNS를 조정하기 전에 현재 진입점이 도메인과 주소 중 무엇을 전달하는지 확인하세요. 앱에서 이미 끝난 조회에 영향을 주려고 코어 DNS만 바꾸는 일을 피할 수 있습니다.

코어 DNS 요청에도 사용할 수 있는 네트워크 경로가 필요합니다. DNS 서버에 프록시를 통해서만 접속할 수 있는데 프록시 서버의 도메인을 조회하려면 같은 DNS 서버가 필요한 경우 시작 단계에서 의존성 순환이 생길 수 있습니다. 기본 문제 해결에서는 클라이언트의 기본 정책을 복원하고 서버 주소를 조회할 수 있는지 먼저 확인한 다음 직접 연결 대상과 프록시 대상의 설정을 따로 살펴보세요. 시스템 DNS, 브라우저 암호화 DNS, 코어 정책을 한 번에 바꾸면 실제로 어느 계층에서 개선됐는지 파악하기 어렵습니다.

도메인 처리 정책은 성능 등급이 아닙니다

AsIs, IPIfNonMatch 같은 정책은 라우팅 단계에서 주소 규칙과 비교하기 위해 도메인을 주소로 조회할지에 영향을 줍니다. 단순히 “빠름”과 “느림”을 뜻하는 옵션이 아닙니다. 코어와 설정 위치에 따라 의미가 다를 수도 있습니다. 주소 규칙을 사용할 때는 조회 결과가 의도한 출구에 적합한지 확인하고, 도메인 규칙을 사용할 때는 도메인 정보가 전달되는지 확인하세요. 더 적극적으로 보이는 정책을 무작정 고르기보다 규칙의 목적을 분명히 하는 것이 중요합니다.

IPv6도 별도로 확인해야 합니다. 네트워크가 두 종류의 주소를 함께 반환하지만 그중 한 경로에 접속할 수 없으면 연결을 기다린 뒤에야 열리거나 특정 대상에서 실패할 수 있습니다. 주소 선택 정책을 조정하기 전에 로그에서 조회 오류와 연결 오류를 비교하세요. 특정 주소 유형을 전역으로 비활성화하는 것이 모든 문제의 해결책은 아닙니다. 설정을 바꾼 뒤에는 같은 대상에 새 연결을 만들어 확인하세요. 기존 장기 연결과 캐시에는 변경 사항이 바로 반영되지 않을 수 있습니다.

7단계 · 트래픽 처리 범위 넓히기

TUN 모드: 활성화 조건과 복구 방법

TUN은 가상 네트워크 인터페이스를 통해 조건에 맞는 트래픽을 처리 경로로 전달합니다. 시스템 프록시 설정을 읽지 않지만 트래픽을 한곳에서 처리해야 하는 앱에 유용합니다. TUN은 진입 범위를 넓힐 뿐 원격 연결 정보의 오류를 고치거나 모든 프로토콜과 네트워크 환경에서 작동을 보장하지 않습니다. 활성화하기 전에 같은 연결이 기본 모드에서 작동하는지 확인하세요. 시스템 프록시를 사용하는 상태에서 이미 외부 연결에 실패한다면 기존 문제를 TUN으로 감싸기보다 먼저 원인을 찾아야 합니다.

기능 지원과 권한부터 확인

데스크톱 v2rayN의 TUN 구현과 사용 가능한 옵션, 필요한 권한은 플랫폼, 클라이언트, 선택한 코어에 따라 달라집니다. 설정 화면에서 실제로 이 기능을 제공하는지, 어떤 권한 안내가 표시되는지 먼저 확인하세요. 관리자 권한이나 시스템 승인이 필요하다면 정상적인 승인 절차를 따르세요. 문제 해결을 위해 클라이언트를 항상 높은 권한으로 실행하는 것은 권장하지 않습니다. 해당 기능을 제공하지 않는 화면에 다른 플랫폼의 메뉴 위치나 설정 항목을 적용하지 마세요.

활성화 전에 다른 가상 네트워크 인터페이스, 네트워크 필터 프로그램의 충돌 모드, 기존 프록시 연결 등 네트워크를 처리하는 다른 도구를 종료하세요. 여러 처리 기능이 겹치면 기본 경로가 서로 덮어쓰이거나 DNS 요청이 중복 처리되고 트래픽이 진입점으로 되돌아올 수 있습니다. 두 기능이 모두 켜져 있다는 표시만으로 호환 여부를 알 수는 없습니다. 먼저 하나의 도구만으로 작동 상태를 만든 뒤 꼭 필요한 경우에만 함께 사용하는 방법을 단계별로 확인하세요.

순서대로 TUN 활성화하기

1. 기존 시스템 프록시, 라우팅 모드, DNS 설정을 기록하고 클라이언트를 정상적으로 종료할 수 있는지 확인합니다.
2. 작동이 확인된 연결을 선택하고 현재 플랫폼의 안내에 따라 권한을 허용한 뒤 TUN을 켭니다.
3. 일반 웹페이지부터 확인하고, 기존 시스템 프록시를 따르지 않던 앱을 테스트하면서 관련 로그를 살펴봅니다.
4. 로컬 네트워크 서비스와 필요한 업무용 연결이 정상인지, 의도치 않게 처리되지 않는지 확인합니다.
5. TUN을 끈 뒤 가상 인터페이스와 시스템 네트워크가 복구되는지 테스트하고 장기간 사용할지 결정합니다.

이 절차의 핵심은 기존 상태를 유지하는 것입니다. TUN을 켠 직후 라우팅, DNS, 노드를 한꺼번에 바꾸지 말고 트래픽 처리 범위가 실제로 달라졌는지 먼저 확인하세요. 클라이언트 문서에서 시스템 프록시와 TUN을 함께 사용하도록 안내한다면 해당 구현의 설명을 따르세요. 서로 독립된 기능이라면 경험만으로 두 설정을 억지로 함께 켜지 마세요. 플랫폼마다 구현이 다르므로 한 번 성공한 조합을 보편적인 규칙으로 여겨서는 안 됩니다.

로컬 네트워크와 DNS 예외

LAN 기기, 프린터, 회사 내부 도메인, 원격 업무 연결은 로컬 라우팅이나 전용 DNS에 의존할 수 있습니다. TUN을 켠 뒤 이런 리소스만 사용할 수 없다면 모든 대상을 프록시로 보내기보다 로컬 주소와 내부 도메인의 우회 규칙을 확인하세요. 내부 도메인의 조회 결과는 네트워크에 따라 달라질 수 있어 주소 하나를 고정 입력하는 방법이 오래 유효하지 않을 수도 있습니다. 업무 네트워크에 연결할 때는 네트워크 관리자가 안내한 조건을 따르세요.

DNS 처리도 연결 문제의 원인을 구분하는 기준입니다. TUN을 켠 뒤 도메인 이름을 사용하는 연결은 모두 실패하지만 IP 주소로는 연결된다면 DNS 경로를 우선 확인하세요. 로컬 게이트웨이나 기존에 가능했던 직접 연결까지 이상해졌다면 라우팅 처리와 인터페이스 상태를 먼저 살펴보세요. 현상을 이해하지 못한 채 가상 인터페이스를 계속 재설치하지 마세요. TUN을 끄고 기존 상태를 복원했을 때 문제가 사라진다면 새로 추가된 처리 계층에 원인이 있을 가능성이 높아져 다음 점검 범위를 좁힐 수 있습니다.

안드로이드 VPN과 데스크톱 TUN의 차이

안드로이드 클라이언트의 VPN 모드도 가상 네트워크 인터페이스로 트래픽을 처리하지만, 권한과 앱별 제어, 시스템 제한은 안드로이드 방식으로 관리됩니다. 데스크톱 TUN 설정을 그대로 적용할 수는 없습니다. 화면 잠금 후 연결이 끊기거나 다른 VPN이 우선 적용되거나 앱 목록이 작동하지 않으면 안드로이드 설정을 다시 확인하세요. 두 기능은 진입 경로라는 개념으로 비교할 수 있지만 실제 설정은 각각 다르게 다뤄야 합니다. 안드로이드 화면에 데스크톱과 같은 스위치가 있어야 하는 것은 아닙니다.

8단계 · 재현 가능한 상태 유지하기

유지 관리: 속도 측정, 로그, 업데이트

일상 유지 관리의 목표는 목록에서 가장 작은 숫자를 찾는 것이 아니라 설정 상태를 명확하게 파악하는 것입니다. 테스트 결과는 로컬 네트워크, 원격 서버 상태, 대상 사이트, 테스트 방식에 따라 달라집니다. 클라이언트 업데이트, 구독 업데이트, 규칙 리소스 업데이트도 서로 다른 작업입니다. 클라이언트 업데이트는 프로그램과 관련 기능을 바꾸고, 구독 업데이트는 연결 정보를 바꾸며, 규칙 리소스 업데이트는 매칭 기준을 바꿉니다. 한 번에 한 종류만 변경해야 문제가 생겼을 때 되돌릴 지점을 찾기 쉽습니다.

V2Ray 서버 속도 측정에서 확인할 항목

TCP 연결 테스트는 대상 포트에 연결할 수 있는지를 주로 보여 줍니다. 완전한 프로토콜 핸드셰이크나 웹페이지 접속까지 성공한다는 뜻은 아닙니다. 프록시를 통한 요청 테스트는 실제 접속에 더 가깝지만 해당 대상과 테스트 시점의 결과만 보여 줍니다. 전송량 테스트는 테스트 파일, 동시 연결 수, 서버 속도 제한, 로컬 회선에도 영향을 받습니다. 항목을 비교할 때는 같은 네트워크에서 비슷한 시간대에 같은 방식으로 측정하세요. 서로 다른 종류의 테스트 숫자를 한데 놓고 비교하지 마세요.

일상적인 사용에서는 먼저 자주 이용하는 대상에 안정적으로 접속되는지 확인한 다음 연결 시간과 지속적인 전송 상태를 살펴보세요. 웹페이지는 느리지만 파일 전송은 정상이라면 DNS, 연결 수립, 페이지가 불러오는 리소스가 원인일 수 있습니다. 특정 사이트만 느리고 다른 대상은 정상이면 해당 사이트까지의 경로를 먼저 확인하세요. 한 번 시간 초과가 발생했다고 모든 설정을 삭제하거나 한 번 성공했다고 문제가 해결됐다고 단정하지 마세요. 테스트 도구를 자주 바꾸기보다 반복해서 확인할 수 있는 대상을 몇 개 정해 두는 편이 정확합니다.

연결 흐름에 따라 로그 읽기

로그에서는 먼저 요청이 코어에 들어왔는지 확인하고, 그다음 외부 연결을 살펴보세요. 테스트 시각, 대상, 진입점이 일치하는 기록을 찾습니다. 로컬 리스너 오류는 포트나 권한 문제, 조회 오류는 DNS 문제를 가리킬 수 있습니다. 연결 거부, 시간 초과, 보안 핸드셰이크 실패는 각각 주소, 네트워크, 프로토콜, 보안 매개변수를 확인해야 합니다. 같은 오류 문구에도 원인이 여러 가지일 수 있으므로 앞뒤 기록을 함께 살펴보고 한 줄만 보고 정해진 해결책을 적용하지 마세요.

로그 상세 수준을 임시로 높였다면 테스트가 끝난 뒤 일반 수준으로 되돌리세요. 민감한 접속 기록이 장기간 쌓이지 않도록 해야 합니다. 로그를 공유하기 전에 구독 주소, 사용자 식별자, 토큰, 개인 도메인, 계정을 식별할 수 있는 정보를 삭제하고 필요한 오류 유형과 발생 시각만 남기세요. 화면 캡처에는 클립보드 알림이나 다른 설정 이름이 포함될 수 있으므로 공개 전에 하나씩 확인하세요. 공개적으로 문제를 해결할 때 전체 자격 증명은 필요하지 않으며, 공개하면 이후 관리 부담만 커집니다.

업데이트 전 복구 가능한 기준 상태 확보

클라이언트를 업데이트하기 전에 사용 중인 코어, 프록시 모드, 사용자 지정 규칙을 기록하고 필요한 설정은 클라이언트가 지원하는 방법으로 백업하세요. 백업 파일은 관리되는 안전한 위치에 보관하고 공개 폴더에 동기화하지 않는 편이 좋습니다. 업데이트 후에는 기존 모드를 유지한 채 원래 작동하던 연결부터 확인한 뒤 새 기능을 사용하세요. 특정 설정만 업데이트 후 실패한다면 원격 정보를 전부 바꾸기보다 관련 기능과 생성된 설정의 변경점을 비교하세요.

재현 가능한 문제 설명 작성

“연결이 안 돼요”라는 문제는 구독 업데이트 실패, 서비스 시작 실패, 요청이 진입점에 도달하지 않음, 외부 핸드셰이크 실패, 특정 대상만 접속되지 않음으로 나눠 볼 수 있습니다. 운영체제, 클라이언트, 코어, 현재 모드, 발생 조건, 최근 변경 사항을 기록하고 프록시를 끄면 문제가 해결되는지도 적어 두세요. 이렇게 정리하면 같은 상황을 재현하고 다음에 확인할 항목을 판단하기 쉽습니다. 속도 문제는 노드·회선·로컬 설정별 문제 해결을 참고하세요.

9단계 · 필요에 따라 확장하기

고급 설정: 작동하는 설정에서 검증 가능한 규칙으로

고급 설정은 모든 스위치를 켜는 것이 아니라 필요한 기능을 파악한 뒤 확인 가능한 방식으로 하나씩 추가하는 과정입니다. 앞의 8개 장을 마쳤다면 안정적인 기준 설정을 마련하고 요청의 진입 경로, 라우팅 방식, DNS 조회 위치, 종료 후 복구 방법을 이해했어야 합니다. 이제 프로토콜 이해, 사용자 지정 라우팅, DNS 정책, 설정 관리의 네 가지 방향으로 단계적으로 확장할 수 있습니다. 실험할 때마다 목적, 예상 결과, 복구 방법을 기록해 매개변수 조합만 외우고 해결하려던 문제를 잊지 않도록 하세요.

먼저 연결 매개변수 이해하기

프로토콜을 알아볼 때는 VMess와 VLESS를 비교하며 인증, 암호화, 전송 보안이 각각 어떤 역할을 하는지 살펴보세요. 이어서 TLS나 REALITY 사용 시 서버 쪽에 필요한 설정을 이해하면 됩니다. 프로토콜 이름만으로 성능을 보장할 수 없고 항목 하나를 줄인다고 무조건 빨라지는 것도 아닙니다. 실제 연결은 전송 방식, 네트워크 경로, 서버 구현에도 영향을 받습니다. 먼저 VMess와 VLESS 설정 차이를 읽고 현재 연결 정보의 각 항목이 무엇을 뜻하는지 확인하세요.

보안 관련 매개변수는 서버 설정과 일치해야 합니다. 서버 이름, 공개 키 관련 항목, 핑거프린트 옵션, 전송 경로에는 각각 구체적인 역할이 있으므로 다른 예시에서 임의로 가져와 조합하지 마세요. 인증서나 핸드셰이크 문제가 발생하면 시스템 시간, 이름 일치 여부, 설정 출처부터 확인하세요. 인증서 검증을 건너뛰는 방법을 장기적인 해결책으로 사용하지 마세요. 제공자가 보안 설정을 변경했다면 눈에 띄게 달라 보이는 항목 하나만 바꾸지 말고 전체 연결 정보를 다시 받으세요.

사용자 지정 라우팅을 작은 실험으로 검증하기

라우팅은 정확한 도메인 하나로 시작하는 것이 좋습니다. 직접 연결할지 프록시를 사용할지 정하고 규칙 하나를 추가한 뒤 매칭 결과와 다른 대상에 미친 영향을 확인하세요. 결과가 예상대로일 때만 도메인 접미사나 주소 범위로 확대합니다. 범위가 넓을수록 어떤 연결까지 포함해야 하는지 이유를 분명히 해야 합니다. 규칙 개수 자체가 설정의 품질을 의미하지는 않습니다. 계속 사용할 규칙에는 목적을 기록하고 오래된 예외는 정기적으로 검토해 기본 규칙보다 앞에 있는 이유를 잊지 않도록 하세요.

규칙이 충돌하면 필요한 규칙만 남도록 범위를 줄이고 하나씩 다시 추가하며 결과를 확인하세요. 이해하지 못한 규칙을 대량으로 가져오면 현재 코어와 DNS 경로에 맞는지 판단하기 어렵습니다. 그래픽 인터페이스의 사전 설정, 사용자 지정 규칙, 전체 설정 파일이 서로 덮어쓸 수 있으므로 클라이언트가 이를 어떻게 합치는지 먼저 확인하세요. 생성된 파일을 직접 수정한 뒤 클라이언트가 다시 덮어쓴다면 파일 권한 문제라고 단정하기보다 저장 설정을 바꿔야 할 올바른 위치를 찾으세요.

DNS 정책과 FakeDNS는 나중에 익히기

DNS는 일반 도메인 조회와 주소 매칭을 먼저 이해한 다음 FakeDNS를 살펴보세요. FakeDNS는 매핑 주소에 도메인 정보를 연결해 두는 방식으로, 나중에 원래 대상을 올바르게 복원하고 트래픽 진입점 및 라우팅과 함께 사용해야 합니다. 환경과 무관하게 켜기만 하면 되는 일반 옵션이 아닙니다. 앱 캐시, 클라이언트를 우회하는 연결, 불완전한 매핑 경로 때문에 접속 문제가 발생할 수 있습니다. 현재 연결에서 도메인 정보가 어디서 사라지는지 설명할 수 있을 때 이 기능을 검토하세요.

DNS 정책을 테스트할 때는 대상을 하나로 고정하고 조회 결과, 실제 외부 연결, 실패 단계가 각각 어떻게 나타나는지 살펴보세요. 캐시 적중 후 빨라진 결과를 모든 요청에 적용되는 이점으로 해석하지 마세요. 특정 사이트에서 한 번 개선됐다고 모든 기기에 같은 설정을 적용하는 것도 피해야 합니다. 데스크톱과 안드로이드는 진입점과 시스템 DNS 환경이 다를 수 있습니다. 개념은 같아도 설정 조합은 플랫폼별로 확인해야 합니다. 설정을 옮길 때는 스위치 위치를 그대로 따라 하기보다 목적과 검증 방법을 재현하는 편이 더 안전합니다.

개인 설정 기록 만들기

날짜별로 변경 목적, 관련 화면, 이전 값, 새 값, 테스트 대상과 결과를 기록하면 좋습니다. 실제 구독 주소나 계정 자격 증명은 기록하지 마세요. 클라이언트 설정, 연결 정보, 규칙을 구분해 정리하면 기기를 옮길 때 무엇을 다시 가져오고 무엇을 직접 복원해야 하는지 판단할 수 있습니다. 문제가 생기면 가장 최근에 작동하던 상태로 먼저 돌아간 뒤 한 번에 하나씩 다시 시험하세요. 오래된 전체 화면 캡처에 의존하는 것보다 관리하기 쉽습니다.

문제가 발생하면 증상에 맞는 장으로 돌아가세요. 가져오기 오류는 구독, 앱이 처리되지 않는 문제는 프록시 모드, 출구가 잘못된 문제는 라우팅 및 DNS, 가상 인터페이스를 켠 뒤 발생한 문제는 TUN 항목을 확인하세요. 기본 연결을 다시 설정해야 한다면 빠른 시작 가이드를 이용하세요. 플랫폼을 바꿔야 한다면 다운로드 페이지에서 클라이언트와 아키텍처를 확인하세요. 제대로 이해했다는 것은 복잡한 조합을 반드시 사용하는 것이 아니라 설정을 설명하고 검증할 수 있다는 뜻입니다.