v2rayN 완벽 가이드
핵심 개념부터 일상적인 유지 관리까지

1단계 · 기본 개념 익히기

핵심 개념과 연결 흐름

클라이언트, 코어, 원격 서버 구분하기

먼저 연결 과정을 나누어 살펴보세요. 앱이 요청을 보내면 로컬 프록시로 들어오고, 코어가 라우팅 규칙에 따라 직접 연결하거나 원격 서버로 전달합니다. v2rayN은 서버 정보를 저장하고 구독을 업데이트하며 사용할 설정을 선택하고 코어를 실행하는 그래픽 클라이언트입니다. 실제 프로토콜 처리와 연결은 코어가 담당합니다. 클라이언트를 내려받았다고 원격 서비스를 이용할 수 있는 것은 아닙니다. 서버 주소, 인증 정보, 유효 기간은 이용 가능한 정식 서비스 제공처에서 확인해야 합니다.

Project V는 이 생태계를 이해하는 출발점이며, V2Fly와 Xray는 관련 코어 계열입니다. 클라이언트 인터페이스와 코어의 기능은 별개입니다. 인터페이스에 특정 필드가 표시되더라도 현재 사용하는 코어가 그 조합을 지원한다는 뜻은 아닙니다. 가져온 설정에서 프로토콜, 전송 방식 또는 보안 설정을 지원하지 않는다는 메시지가 나오면 실제로 어떤 코어가 실행되는지 확인한 뒤 설정을 점검하세요. 지원되지 않는 기능을 구독 오류로 오해하지 말고, 클라이언트가 실행됐다는 이유만으로 원격 연결까지 성공했다고 판단하지 마세요.

프로토콜과 전송 설정을 필드별로 이해하기

VMess, VLESS, Trojan은 연결 설정의 프로토콜 정보입니다. TCP, WebSocket, gRPC 등은 전송 방식을 나타내고, TLS와 REALITY 등은 보안 핸드셰이크 또는 관련 메커니즘을 다룹니다. 이 값들은 임의로 바꿔도 되는 성능 옵션이 아닙니다. 원격 서버에서 요구하는 주소, 포트, 사용자 ID, 서비스 이름, 경로, 서버 이름 등을 로컬 설정에도 그대로 적용해야 합니다. VLESS 자체가 암호화된 연결을 뜻하는 것은 아니므로 필요한 보호 기능이 갖춰졌는지는 전송 및 보안 설정 전체를 확인해야 합니다.

도메인 관련 필드도 각각 다른 역할을 할 수 있습니다. 서버 주소는 처음 연결할 대상을 지정하고, TLS 서버 이름은 인증서 및 핸드셰이크 처리에 사용되며, WebSocket Host는 요청 헤더에 포함됩니다. 세 값이 같을 수도, 다를 수도 있습니다. 주소가 해석됐다는 사실은 DNS 단계가 성공했음을 뜻할 뿐입니다. 포트에 연결되더라도 인증이 성공했다는 의미는 아닙니다. 문제를 해결할 때는 DNS 조회, 네트워크 연결, 보안 핸드셰이크, 프로토콜 인증, 대상 서비스 접속 순서로 확인하세요. 모든 오류를 네트워크 속도 문제로 취급하지 마세요.

반복 가능한 테스트 기준 만들기

직접 연결되는 일반 웹사이트 하나와 프록시가 필요한 테스트 대상 하나를 준비하세요. 다른 트래픽 가로채기 도구는 종료하고 현재 활성 서버, 시스템 프록시 상태, 라우팅 프리셋을 기록하세요. 같은 브라우저와 네트워크를 사용해 설정을 한 번에 하나씩만 바꾸고 로그와 접속 결과를 확인합니다. 특정 페이지가 가끔 열리는지만 보면 캐시, 연결 재사용, 앱 자체 DNS 조회가 결과에 영향을 줄 수 있습니다. 설정을 바꾼 뒤에는 같은 페이지를 계속 새로고침하기보다 새 연결을 만들어 비교하는 편이 좋습니다.

테스트 결과가 의미하는 범위를 이해하세요. 목록에 표시되는 지연 시간은 해당 테스트 방식만 반영하며 다운로드 대역폭을 직접 나타내지 않습니다. 웹 요청이 성공했다고 실시간 통신, 게임 또는 모든 UDP 트래픽이 정상이라고 볼 수도 없습니다. 단순히 “연결할 수 없음”이라고 기록하기보다 어느 단계에서, 어떤 앱과 대상에서 실패했는지 남기세요. 이후 각 장에서도 같은 기준을 따르세요. 앞 단계가 정상임을 확인한 뒤 다음 기능을 추가하고, 문제가 생기면 가장 최근에 정상 작동했던 상태로 돌아가세요.

2단계 · 도구 선택하기

플랫폼과 클라이언트 선택

데스크톱에서는 v2rayN 우선 고려

Windows, macOS, Linux에서는 구독, 서버 목록, 라우팅을 한곳에서 관리할 수 있는 v2rayN을 우선 고려하세요. 다운로드 페이지로 이동하기 전에 운영체제와 프로세서 아키텍처를 확인하세요. 운영체제 이름이 같아도 설치 파일을 서로 바꿔 쓸 수는 없습니다. 특히 ARM과 x64는 파일 아이콘만 보고 판단하지 마세요. 항목별 비교가 필요하다면 먼저 선택 가이드를 읽고, 다운로드 페이지에서 알맞은 버전을 선택하세요.

Windows에서는 데스크톱 버전 Desktop과 클래식 WPF 버전을 사용할 수 있습니다. Desktop은 차세대 크로스 플랫폼 인터페이스를 사용하고, WPF는 기존 Windows 인터페이스의 사용 방식을 유지합니다. 처음 사용한다면 Desktop부터 시작해도 좋습니다. 기존 작업 흐름이 안정적이라면 두 버전의 인터페이스와 설정 차이를 먼저 살펴본 뒤 이전 여부를 결정하세요. 두 인터페이스를 서로 다른 서비스 제공처로 혼동하지 마세요. 문제를 해결하려고 클라이언트를 두 개 동시에 실행하면 로컬 포트, 시스템 프록시, 설정 디렉터리가 서로 간섭할 수 있습니다.

시스템 정보를 기준으로 아키텍처 선택

Windows에서는 “설정 → 시스템 → 정보”에서 시스템 종류를 확인하세요. PC 브랜드만으로 판단하지 마세요. macOS에서는 “이 Mac에 관하여”를 열어 Apple 칩이 표시되면 Apple Silicon용 항목을, Intel이 표시되면 Intel용 항목을 선택하세요. Linux에서는 프로세서 종류뿐 아니라 배포판이 deb 또는 rpm 패키지를 사용하는지도 확인해야 합니다. 패키지 형식과 데스크톱 환경은 일대일로 대응하지 않으므로 같은 데스크톱 환경을 쓴다는 이유만으로 다른 컴퓨터의 설치 방법을 그대로 적용하지 마세요.

Android에서는 Xray 코어를 사용하는 v2rayNG를 우선 고려하세요. V2Fly 코어와 동일한 동작이 필요한 경우에는 v2flyNG를 검토할 수 있습니다. 최신 스마트폰은 대개 arm64에 적합하지만 아키텍처를 확인할 수 없다면 범용 버전을 고려하세요. 그래도 시스템 요구 사항은 확인해야 합니다. 범용 버전은 모든 프로토콜 조합을 자동으로 지원한다는 뜻이 아니라, 패키지의 아키텍처 호환 범위를 넓힌다는 의미입니다. 두 앱의 설정 방법은 비슷할 수 있지만 기능 지원까지 같다고 볼 수는 없습니다. 자세한 차이는 Xray와 V2Fly 코어 비교를 확인하세요.

성능을 추측하기 전에 요구 사항부터 확인하기

먼저 필요한 조건을 정리하세요. 원격 프로토콜을 지원하는지, 구독 형식을 가져올 수 있는지, 대상 앱에 TUN이 필요한지, 기기에서 필요한 권한을 허용하는지 확인합니다. 조건을 충족한 다음 인터페이스 사용 편의성과 유지 관리 비용을 비교하세요. 클라이언트를 바꿔도 원격 회선 품질이 저절로 좋아지지는 않으며, 인터페이스를 바꿔도 서비스 만료나 잘못된 설정은 해결되지 않습니다. 같은 설정을 비교할 때는 네트워크, 대상 사이트, 테스트 시간을 최대한 비슷하게 유지해 회선 변동을 클라이언트 차이로 오해하지 마세요.

이전할 때는 기존에 작동하던 방법을 남겨두되 네트워크를 동시에 제어하는 클라이언트는 실행하지 마세요. 구독 출처와 필요한 사용자 지정 규칙을 백업한 다음 새 클라이언트에서 가져오기, 서버 선택, 대상 접속을 각각 확인하고 복잡한 라우팅을 옮기세요. 휴대폰과 컴퓨터에서 같은 서비스 제공처를 이용하더라도 기기 수와 동시 접속 제한을 따라야 합니다. 선택 작업은 앱을 여러 개 설치하는 것으로 끝나지 않습니다. 주로 사용할 클라이언트 하나, 복구 방법 하나, 출처를 확인할 수 있는 설정 하나를 정해두세요.

3단계 · 초기 설정 마치기

설치, 권한 및 첫 실행

안정적인 실행 위치 마련하기

먼저 다운로드 페이지에서 플랫폼에 맞는 항목을 선택하고 시스템 안내에 따라 설치하세요. 설치 프로그램과 압축을 풀어 실행하는 프로그램은 관리 방법이 다릅니다. 압축 파일을 받았다면 안정적으로 보관할 디렉터리에 완전히 압축을 푸세요. 압축 프로그램 안에서 실행 파일만 바로 열지 마세요. 첫 실행 시 설정과 로그 등의 데이터가 생성되므로 해당 디렉터리에 쓰기 권한이 있어야 합니다. 임시 정리 대상 위치에 설치하지 말고, 동기화 소프트웨어가 동시에 파일을 수정하는 환경도 되도록 피하세요.

Windows에서 첫 실행 시 실행 환경이 없다는 메시지가 나오면 오류에 표시된 구성 요소와 아키텍처를 확인하세요. 출처가 불분명한 팝업에서 복구 도구를 내려받지 마세요. 조직 정책으로 관리되는 기기라면 프록시 소프트웨어 실행과 가상 네트워크 어댑터 생성을 허용하는지 먼저 확인하세요. 일반 시스템 프록시를 사용할 때는 계속 관리자 권한으로 실행할 필요가 없는 경우가 많지만, TUN에는 추가 권한이 필요할 수 있습니다. 일반 실행과 권한 상승 실행을 나누어 테스트하면 프로그램 오류, 디렉터리 권한, 네트워크 드라이버 문제를 더 쉽게 구분할 수 있습니다.

플랫폼별 실행 문제 해결

macOS에서는 설치 후 앱을 안정적으로 유지할 수 있는 응용 프로그램 디렉터리로 옮긴 다음 실행하세요. 보안 경고가 나타나면 다운로드 출처와 시스템 호환성을 먼저 확인하고 시스템의 보안 설정을 이용해 처리하세요. 시스템 보호를 끄는 명령을 그대로 복사해 실행하지 마세요. Linux에서는 배포판의 패키지 도구로 필요한 종속성을 설치하세요. 실행에 실패하면 누락된 라이브러리나 실행 환경에 대한 안내부터 확인합니다. 그래픽 인터페이스가 표시된다고 네트워크 권한까지 갖춰진 것은 아닙니다. 가상 네트워크 어댑터를 사용하는 경우에는 시스템에서 요구하는 권한을 별도로 확인하세요.

Android에 v2rayNG 또는 v2flyNG를 설치한 뒤 처음 연결하면 시스템 VPN 권한 요청이 표시될 수 있습니다. 이는 기기 트래픽을 앱으로 전달하는 시스템 연결 지점일 뿐, 원격 서비스를 이용할 수 있다는 의미는 아닙니다. 권한 내용을 읽고 출처를 확인한 클라이언트에만 허용하세요. 같은 연결 지점을 사용하는 다른 앱은 우선 종료하세요. 화면이 잠긴 뒤 백그라운드 제한으로 연결이 끊길 수 있습니다. 기본 연결이 정상인 것을 확인한 후 기기의 배터리 설정에서 클라이언트의 백그라운드 실행 권한을 조정하세요.

로컬 포트와 인터페이스 상태 확인

v2rayN 메인 창에서 서버 목록, 구독 그룹, 로그, 하단 상태 표시줄을 먼저 찾으세요. 아직 설정을 가져오지 않아 목록이 비어 있는 것은 정상입니다. 코어 매개변수를 바로 바꿀 필요는 없습니다. “설정 → 매개변수 설정”을 열어 실제 로컬 포트 설정을 확인하고 포트와 수신 주소를 기록하세요. 설정마다 연결 지점이 다를 수 있으므로 앱에 프록시를 수동으로 입력할 때는 여기에 표시된 실제 값을 사용하세요. 가이드에 자주 나오는 숫자를 보고 추측하지 마세요.

로그에 주소가 이미 사용 중이라는 메시지가 나오면 다른 클라이언트를 종료하고 이전 프로세스가 남아 있는지 확인하세요. 무작정 포트를 바꾸지 마세요. 브라우저나 다른 앱이 기존 포트를 계속 사용해 문제가 더 생길 수 있습니다. 수신 주소는 보통 로컬 범위로 유지해야 합니다. LAN 공유가 꼭 필요한 경우에만 수신 범위를 넓히고 접근 제어와 방화벽을 함께 설정하세요. 로컬 연결 오류를 해결하려고 기기의 포트를 네트워크에 공개하는 것은 일반적인 해결 방법이 아닙니다.

첫 실행은 세 가지만 확인하면 됩니다. 인터페이스가 안정적으로 열리는지, 설정을 저장할 수 있는지, 코어 실행 중 지속적인 오류가 없는지 확인하세요. 원격 정보 설정을 마치기 전이므로 모든 사이트에 접속할 필요는 없습니다. 먼저 메인 화면 상세 안내에서 로그 위치를 익힌 다음 구독 장으로 이동하세요. 설치 문제가 발생하면 원래 오류 문구와 시스템 아키텍처 정보를 보관하고, 운영체제를 다시 설치하는 대신 명확한 환경 오류부터 해결하세요.

4단계 · 설정 가져오기

구독 가져오기 및 서버 관리

구독 주소와 공유 링크 구분하기

먼저 보유한 정보의 종류를 확인하세요. 구독 주소는 보통 서버 목록을 가져오는 URL입니다. vmess://, vless:// 등으로 시작하는 문자열은 단일 서버 공유 링크인 경우가 많고, 전체 JSON은 코어 설정 파일일 수 있습니다. 모두 문자열이라는 이유만으로 서로 바꿔 사용할 수는 없습니다. 일반 구독 업데이트 메뉴에서 전체 설정 파일을 가져올 수 있는 것은 아니며, 공유 링크를 구독 URL 입력란에 웹 주소처럼 넣어서도 안 됩니다.

구독 주소에는 서비스를 바로 이용할 수 있는 인증 정보가 포함될 수 있으므로 계정 정보처럼 안전하게 보관하세요. 전체 링크를 공개 스크린샷, 게시판, 속도 측정 문의에 올리지 말고 출처가 불분명한 온라인 변환 사이트에 제출하지 마세요. 정보를 가려서 기록할 때는 프로토콜 종류, 오류 유형, 필요한 필드 이름만 남기면 됩니다. 서비스 제공처에서 새 구독 주소를 받으면 기존 주소가 만료됐는지 먼저 확인한 뒤 출처를 교체하세요. 같은 서비스로 연결되는 그룹이 중복되지 않게 관리하세요.

구독 그룹을 만들어 가져오고 업데이트하기

1. “구독 그룹 → 구독 그룹 설정”을 열고 출처를 알아볼 수 있는 별칭을 추가하세요.
2. 전체 구독 주소를 “선택 주소(URL)”에 입력하고 앞뒤 공백, 줄바꿈, 복사 누락이 없는지 확인하세요.
3. “업데이트 사용” 상태를 확인한 뒤 저장하고 “구독 그룹” 메뉴에서 현재 구독을 업데이트하세요.
4. 해당 그룹으로 돌아가 목록과 로그를 확인한 뒤 사용할 서버를 활성 서버로 지정하세요.

처음 업데이트할 때는 구독 주소에 직접 접속할 수 있다는 전제 아래 현재 프록시를 거치지 않는 방식을 사용하세요. 프록시를 통해서만 주소에 접근할 수 있다면 먼저 독립적으로 사용할 수 있는 연결을 마련한 다음 메뉴에서 프록시를 통한 업데이트를 선택하세요. 아직 가져오지 못한 구독을 이용해 자기 자신을 다운로드하려고 하지 마세요. 업데이트 오류가 나오면 DNS 조회 실패, 요청 시간 초과, 인증 거부, 형식 인식 실패 중 어떤 문제인지 먼저 확인하세요. 원인이 다른 오류를 모두 삭제 후 재생성으로 처리하지 마세요.

구독 그룹 → 구독 그룹 설정 → 선택 주소(URL) → 저장 → 현재 구독 업데이트

업데이트가 로컬 변경 사항에 미치는 영향 이해하기

구독은 출처와 동기화한 결과이지, 장기간 직접 수정하며 사용할 유일한 사본이 아닙니다. 서비스 제공처가 업데이트하면 서버 별칭, 주소, 항목 순서까지 바뀔 수 있으며 구독 항목의 로컬 수정 내용이 덮어써질 수도 있습니다. 매개변수를 시험해야 한다면 항목을 별도로 복사하고 용도를 기록하세요. 주로 사용하는 출처를 직접 수정하지 마세요. 자동 업데이트 간격은 실제 필요에 맞추세요. 자주 요청해도 원격 서버가 저절로 늘어나지는 않으며 출처 측의 접근 제한이 발생할 수 있습니다.

목록이 비어 있다면 현재 선택된 그룹과 화면 필터부터 확인한 다음 업데이트 로그를 살펴보세요. 로그인 화면이나 안내 페이지가 반환됐다고 해서 파싱 가능한 구독을 받은 것은 아닙니다. 서비스 만료, 접근 제한, 형식 비호환으로도 가져오기에 실패할 수 있습니다. 특정 프로토콜의 항목만 보이지 않는다면 전체 설정을 바꾸기 전에 클라이언트와 코어의 지원 여부를 확인하세요. 구독 형식의 차이와 변환 범위는 구독 형식 안내에서 확인할 수 있습니다.

업데이트에 성공했더라도 기존 항목을 바로 일괄 삭제하지 마세요. 새 항목 하나를 선택해 실제 접속을 확인하고 기존 활성 서버가 여전히 목록에 있는지도 살펴보세요. 자주 사용하는 그룹에는 알아보기 쉬운 이름을 붙이고 서비스 기간과 업데이트 방법을 기록하되 인증 정보를 별칭에 넣지 마세요. 출처를 구분하고 활성 항목을 명확히 하며 업데이트 결과를 확인할 수 있어야 이후 프록시 모드를 바꿀 때도 안정적입니다. 간단한 절차만 확인하려면 구독 가져오기 빠른 안내를 참고하세요.

5단계 · 앱 연결하기

시스템 프록시와 전체 프록시

먼저 일반 앱의 프록시 연결 설정하기

활성 서버를 선택한 뒤 v2rayN 하단의 시스템 프록시 항목에서 “시스템 프록시 자동 설정”을 선택하세요. 이 설정은 운영체제에서 앱이 읽을 수 있는 프록시 연결 지점을 지정하지만 모든 프로세스가 이를 따르도록 강제하지는 않습니다. 일부 브라우저는 시스템 설정을 따르고, 일부 앱은 자체 설정을 사용하며, 시스템 프록시를 읽지 않는 연결 방식도 있습니다. 시스템 설정을 따르는 브라우저로 먼저 확인한 다음 특수한 앱을 살펴보세요. 처음부터 컴퓨터의 모든 트래픽이 전부 처리된다고 판단하는 것보다 신뢰할 수 있습니다.

“시스템 프록시 지우기”는 관련 시스템 프록시 설정을 제거하는 기능으로, 종료 전 직접 연결 상태로 복구하거나 연결 지점 문제를 확인할 때 사용합니다. “시스템 프록시 변경 안 함”은 클라이언트가 해당 설정을 바꾸지 않는다는 뜻이지 시스템에 프록시가 없다는 의미는 아닙니다. 이전에 수동 설정이 남아 있다면 변경하지 않도록 해도 예전 포트를 계속 가리킬 수 있습니다. 종료 후 네트워크에 문제가 생기면 시스템 프록시 설정에서 주소와 포트를 확인한 뒤 지울지 결정하세요. 클라이언트를 종료한 상태에서 앱이 작동하지 않는 연결 지점을 계속 사용하게 두지 마세요.

전체 라우팅을 모든 앱의 트래픽 처리와 혼동하지 않기

흔히 말하는 V2Ray 전체 프록시는 어떤 단계에서 ‘전체’를 의미하는지 구분해야 합니다. 클라이언트의 전체 라우팅은 코어에 들어온 요청을 프록시 외부 연결로 보내는 방식입니다. 클라이언트로 들어오지 않은 앱의 연결 경로까지 바뀌지는 않습니다. 시스템 프록시는 연결 입구를 설정하고 라우팅 프리셋은 외부 연결 방식을 정하므로 각각 설정해야 합니다. 전체 라우팅은 분할 라우팅 규칙의 영향을 받는지 잠깐 확인할 때 유용합니다. 장기간 사용하려면 로컬 서비스, LAN 기기, 일상적인 직접 연결 업무의 접속 요구도 고려하세요.

브라우저와 다른 앱을 따로 확인하기

브라우저 접속에 실패하면 프록시를 제어하는 확장 프로그램을 잠시 끄고 현재 브라우저에 별도의 연결 지점이 설정돼 있지 않은지 확인하세요. 클라이언트 로그에 새 연결이 전혀 없다면 연결 입구부터 살펴보세요. 요청이 기록됐지만 원격 오류가 발생했다면 활성 서버와 핸드셰이크 매개변수를 확인합니다. 테스트 전에 기존 탭을 닫거나 새 세션을 만들어 이전 연결을 재사용하지 않도록 하세요. 시크릿 창도 모든 네트워크 설정을 우회하는 것은 아니므로 별도의 프록시 환경으로 간주하지 마세요.

명령줄 터미널과 일부 개발 도구는 시스템 프록시를 따르지 않을 수 있습니다. 브라우저는 정상인데 터미널이 작동하지 않는다면 먼저 서버를 바꾸지 마세요. 해당 도구에서 지원하는 프록시 설정을 확인하고 실제 수신 주소와 포트를 입력하세요. HTTP 프록시 연결 지점을 모든 상황에서 SOCKS 연결로 사용할 수 있는 것은 아니며 인증 방식도 일치해야 합니다. 자세한 문제 해결은 브라우저와 터미널을 나누어 문제 해결하기를 참고하세요. 이 단계에서는 원인을 찾기 쉽도록 연결 지점을 하나만 사용하세요.

마지막으로 종료 및 복구를 테스트하세요. 시스템 프록시를 지우고 일반 직접 연결이 복구되는지 확인합니다. 클라이언트를 다시 실행한 뒤 시스템 프록시를 켜고 대상에 접속되는지 확인하세요. 이를 통해 시스템 설정이 남아 있는 문제와 자동 시작 순서 문제를 찾을 수 있습니다. 프록시를 켰을 때 작동하고 끄면 복구되는 것까지 확인해야 연결 설정이 완료된 것입니다. 일반 연결 지점을 사용할 수 없는 앱이 있을 때만 TUN 장으로 이동하세요. 특정 앱 하나 때문에 컴퓨터 전체의 라우팅을 먼저 바꾸지 마세요.

6단계 · 외부 연결 조정하기

라우팅 및 DNS 설정

프리셋으로 기본 동작 확인하기

먼저 클라이언트에서 제공하는 라우팅 프리셋을 사용하세요. 출처를 알 수 없는 대형 규칙 목록을 처음부터 가져오지 마세요. “중국 본토 우회”는 해당 지역 규칙에 일치하는 요청을 직접 연결하고 나머지 요청은 프리셋에 따라 프록시로 보내는 데 주로 사용됩니다. “전체”는 클라이언트로 들어온 요청을 전체 정책에 따라 처리합니다. 프리셋의 구체적인 규칙은 변경될 수 있으므로 라우팅 설정에서 실제 항목을 확인하세요. 이름은 요약일 뿐 모든 LAN 대상, 특수 도메인, 앱에 적절한 규칙이 적용됐다는 뜻은 아닙니다.

코어는 설정된 규칙과 일치 조건에 따라 외부 연결을 선택하며 규칙 순서가 결과에 영향을 줍니다. 범위가 넓은 규칙을 앞에 두면 뒤에 있는 구체적인 규칙이 적용되지 않을 수 있습니다. 어떤 규칙에도 일치하지 않으면 기본 외부 연결이 사용됩니다. 문제를 해결할 때는 일치한 규칙과 기본 동작을 함께 확인하세요. 목록에 도메인이 있는지만 확인해서는 충분하지 않습니다. 규칙을 추가하기 전에 대상 도메인이나 네트워크, 직접 연결 또는 프록시 여부, 예외가 필요한 이유, 검증에 사용할 요청을 명확히 정하세요.

도메인 규칙과 IP 규칙 구분하기

도메인 규칙은 클라이언트가 해당 도메인 정보를 확인해야 적용할 수 있습니다. IP 규칙은 목적지 주소 또는 관련 조회 결과를 기준으로 판단합니다. 앱이 IP에 직접 연결하면 도메인 규칙만으로는 처리하지 못할 수 있습니다. 하나의 도메인이 여러 주소를 사용한다면 주소 하나만 기억해 두는 것도 신뢰할 수 없습니다. DNS는 우선 도메인을 IP 주소로 변환하는 역할을 하며 모든 연결의 외부 경로를 자동으로 정하지는 않습니다. 라우팅 정책, DNS 조회 정책, 연결에 실제 사용되는 주소를 함께 확인하세요. DNS를 바꾸면 외부 연결도 자동으로 바뀐다고 생각하지 마세요.

아래는 필드 간 관계를 설명하는 코어 수준의 규칙 예시입니다. 단독으로 실행 가능한 전체 설정이 아니며 구독 URL에 입력해서도 안 됩니다. 예시 도메인과 하위 도메인의 연결을 direct라는 이름의 외부 연결로 보내며, 사용하려면 해당 외부 연결이 미리 정의돼 있어야 합니다. 그래픽 클라이언트가 설정 파일을 다시 생성할 수 있으므로 일상적인 설정은 실행 파일을 반복해서 편집하지 말고 라우팅 인터페이스에서 관리하세요. 예시 도메인은 설명용이며 실제 규칙에 계속 추가하라는 뜻이 아닙니다.

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

특정 대상의 라우팅 문제 해결하기

특정 사이트가 열리지 않으면 먼저 전체 라우팅으로 전환해 같은 대상을 테스트하세요. 전체 라우팅은 정상인데 원래 프리셋에서 실패한다면 규칙 일치 여부, 직접 연결 경로, DNS를 중점적으로 확인하세요. 두 방식 모두 실패한다면 서버나 대상 서비스 자체를 살펴보세요. 설정을 바꿀 때마다 새 연결을 만들어 이전 외부 연결이 유지되지 않게 합니다. 테스트 중 DNS, 서버, 라우팅을 한꺼번에 바꾸지 마세요. 문제가 해결되더라도 어떤 항목이 원인이었는지 알 수 없게 됩니다.

라우터 관리 페이지, 프린터, 로컬 개발 서비스에 접속할 때는 사설 IP 주소와 로컬 도메인이 올바르게 직접 연결되는지 먼저 확인하세요. 프록시 외부 연결이 로컬 네트워크에만 있는 주소에 접속하려 해도 원격에서는 대개 도달할 수 없습니다. 반대로 LAN 대상을 하나 해결하려고 공인 IP 주소의 지나치게 넓은 범위를 모두 직접 연결하지 마세요. 스니핑은 일부 연결에서 도메인 정보를 복원하는 데 도움이 되지만 암호화된 모든 트래픽을 식별한다고 보장할 수는 없습니다. 앱 호환성도 고려해 필요한 경우에만 켜고 확인하세요.

규칙은 적고 명확하게 유지하세요. 사용자 지정 항목의 용도를 기록하고 사용할 수 없게 된 도메인이나 범위가 지나치게 넓은 일치 조건을 정기적으로 점검하세요. 규칙 리소스를 업데이트한 뒤에는 중요한 대상에 다시 접속해 확인합니다. 네트워크를 바꿀 때는 DNS 조회 결과와 LAN 환경을 비교한 다음 장기 정책을 바꿀지 결정하세요. 이 장의 목표는 규칙을 많이 보유하는 것이 아니라 요청이 왜 특정 외부 연결을 사용하는지 설명하고, 어떤 규칙에도 일치하지 않을 때 확인할 곳을 아는 것입니다. 다음 TUN 설정에서도 이 검증된 라우팅 기준을 유지하세요.

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

TUN 모드와 네트워크 복구

가상 네트워크 어댑터가 정말 필요한지 확인하기

앱이 시스템 프록시를 읽지 않거나 더 다양한 연결을 클라이언트로 보내야 할 때 v2rayN의 TUN 모드를 고려하세요. TUN은 가상 네트워크 어댑터와 시스템 라우팅을 통해 트래픽을 연결하는 기능이지, 더 빠른 서버가 아니며 잘못된 원격 설정을 고쳐 주지도 않습니다. 같은 활성 서버가 일반 프록시에서 작동하는지 먼저 확인한 다음 TUN을 켜세요. 일반 프록시 연결이 성공하지 않았다면 가상 네트워크 어댑터가 권한, 라우팅, DNS 변수를 추가해 원래 명확했던 문제를 더 찾기 어렵게 만들 수 있습니다.

활성화하기 전에 현재 작동하는 설정을 저장하고 기존 시스템 프록시 상태를 기록한 뒤 시스템 라우팅을 바꾸는 다른 도구를 일시 중지하세요. 사내 네트워크, 원격 접속 도구, 다른 가상 네트워크 어댑터가 기본 경로나 DNS를 놓고 충돌할 수 있습니다. 원격 데스크톱으로만 접속 가능한 연결에서 전체 트래픽을 섣불리 전환하지 마세요. 로컬에서 조작하거나 다른 연결을 사용할 방법을 먼저 마련하세요. 관리되는 기기에서는 가상 네트워크 드라이버나 권한 상승이 금지될 수 있습니다. 권한 안내를 우회하기 전에 조직 정책에서 허용하는지 확인하세요.

권한, 라우팅, DNS 순서로 확인하기

v2rayN 메인 화면에서 “TUN 사용”을 찾고 시스템 안내에 따라 필요한 권한을 허용하세요. 실행에 실패하면 로그에서 권한 부족, 장치 생성 실패, 주소 충돌을 확인한 뒤 해당 문제를 해결하세요. 가상 네트워크 어댑터를 만들지 못한 상태라면 서버를 바꿔도 보통 해결되지 않습니다. 어댑터는 생성됐는데 모든 접속이 실패한다면 시스템 라우팅이 적용됐는지, 기본 경로가 올바른지, DNS 요청에 사용할 경로가 있는지 점검하세요. 플랫폼에 따라 설정 이름이 다를 수 있으므로 실제 인터페이스를 기준으로 확인하세요.

첫 테스트에서는 시스템 프록시와 TUN을 동시에 사용해 성공 여부를 확인하지 마세요. 클라이언트의 동작 방식에 따라 불필요한 시스템 프록시 연결 지점을 잠시 지운 다음 원래 시스템 프록시를 읽지 않는 앱으로 테스트하세요. 브라우저만 성공했다면 일반 프록시를 계속 사용 중일 수 있습니다. 연결 로그, 대상 접속, 종료 후 복구를 모두 확인해 실제로 트래픽이 전환되는지 검증하세요. UDP 테스트는 해당 기능을 명확히 사용하는 앱으로 진행하세요. 웹페이지가 열린다는 사실만으로 UDP 지원을 판단할 수 없습니다.

LAN과 특수 네트워크의 경계 유지하기

프린터 검색, LAN 공유, 가상 머신, 컨테이너 네트워크는 라우팅 변경의 영향을 받을 수 있습니다. 로컬 서비스에 연결할 수 없다면 대상 주소와 네트워크 대역을 확인한 뒤 제외 규칙을 살펴보세요. 모든 트래픽을 직접 연결하도록 바꾸지 마세요. DNS 트래픽을 처리하는 방식이 바뀌면 내부 도메인의 조회 결과도 달라질 수 있으므로 사내 네트워크에서는 전용 DNS 서버에 올바른 경로를 유지해야 합니다. 공용 네트워크의 인증 페이지에 로그인해야 한다면 먼저 트래픽 처리를 끄고 로그인한 뒤 다시 켜서 확인하세요.

MTU를 기본적인 속도 향상 조절값으로 취급하지 마세요. 기본 연결이 정상이고 일부 연결에서 큰 패킷 전송 오류가 지속적으로 발생하며 이를 확인할 명확한 테스트 근거가 있을 때만 조정을 고려하세요. 무작위로 값을 바꾸면 회선이나 프로토콜의 실제 문제가 가려질 수 있습니다. 절전 모드에서 깨어난 뒤, Wi-Fi를 바꾼 뒤, 핫스팟에 연결한 뒤 문제가 생기면 연결을 다시 만들거나 TUN을 재시작한 다음 라우팅 변화를 비교하세요. 네트워크가 다르면 원인도 다를 수 있으므로 환경별로 기록하세요.

복구가 필요하면 먼저 TUN을 끄고 클라이언트를 종료한 뒤 시스템 프록시 설정이 남아 있지 않은지 확인하세요. 그래도 문제가 계속되면 다른 네트워크 도구와 시스템 DNS 설정을 확인하고 필요한 경우 현재 네트워크에 다시 연결하세요. 원인을 확인하지 않고 시스템 네트워크 어댑터를 전부 삭제하거나 네트워크 전체를 초기화하지 마세요. 자주 사용하는 앱, LAN 접속, 절전 후 복귀, 종료 후 복구가 모두 테스트를 통과해야 안정적인 상태입니다. 일반 프록시로 충분하다면 일반 모드를 유지하고, 명확한 용도가 있을 때만 TUN을 사용하세요.

8단계 · 유지 관리하기

업데이트, 백업 및 일상적인 문제 해결

세 가지 업데이트를 따로 관리하기

클라이언트 업데이트, 코어 업데이트, 구독 업데이트를 각각 구분하세요. 클라이언트 업데이트는 인터페이스와 설정 관리를, 코어 업데이트는 프로토콜 처리와 실행 동작을, 구독 업데이트는 원격 서버 항목 동기화를 변경합니다. 세 가지는 서로 다른 작업이며 문제가 생겼을 때 모두 한꺼번에 실행할 필요는 없습니다. 현재 정상 상태를 먼저 기록하고 필요한 항목 하나만 업데이트하세요. 접속을 확인한 다음 다음 항목을 업데이트하면 호환성 문제가 발생했을 때 어느 단계가 원인인지 알기 쉽습니다.

“업데이트 확인” 관련 메뉴를 사용하기 전에 안내를 읽고 설정을 백업하세요. 설치 파일을 바꿔야 한다면 다운로드 페이지에서 플랫폼에 맞는 버전을 선택하세요. 특히 사용자 지정 라우팅이나 복잡한 DNS 설정이 있다면 유일한 작업용 사본을 바로 덮어쓰지 마세요. 백업에는 구독 출처, 별도로 추가한 서버 정보, 라우팅 규칙, 필요한 매개변수 설명이 포함돼야 합니다. 데이터 디렉터리는 운영체제와 설치 방식에 따라 다르므로 실제 클라이언트의 데이터 관리 메뉴에서 위치를 확인하세요.

복사에 그치지 않고 실제 복구 가능한 백업 만들기

설정 파일에는 사용자 ID, 구독 인증 정보, 연결 비밀번호가 들어 있을 수 있으므로 접근이 제한된 위치에 보관하세요. 기기 간 동기화를 설정하기 전에 동기화 서비스의 접근 권한을 확인하고 전체 설정을 공개 공유 폴더에 올리지 마세요. 백업 후에는 클라이언트 종류와 주요 설정을 기록하고 별도 디렉터리나 통제된 환경에서 복구를 검증하세요. 실행 파일만 복사해서는 사용자 설정을 보존할 수 없고, 스크린샷만으로는 숨겨진 필드를 정확히 복원할 수 없습니다. 어느 쪽도 완전한 백업을 대신하지 못합니다.

최근 정상 작동을 확인한 설정 하나와 업데이트 전 백업 하나를 유지하면 충분합니다. 인증 정보가 포함된 이전 파일을 계속 쌓아둘 필요는 없습니다. 다른 컴퓨터로 옮길 때는 기본 구독과 활성 서버를 먼저 복구한 뒤 라우팅과 TUN을 추가하세요. 시스템 프록시, 드라이버 권한, 로컬 포트는 기기 환경에 따라 달라지므로 설정 파일만으로 함께 이전된다고 가정하지 마세요. 새 기기에서 작동하는 것을 확인한 뒤 필요에 따라 기존 기기의 권한을 해제하거나 이전 자료를 정리하세요.

로그로 원인을 좁히고 반복적인 재설치는 피하기

V2Ray 연결에 실패하면 발생 시각, 대상 앱, 활성 서버, 프록시 연결 지점, 최근 변경 사항을 기록하고 같은 시각의 로그를 확인하세요. DNS 조회 실패는 DNS와 도메인부터 확인합니다. 연결 거부는 포트나 서버 상태 문제일 수 있습니다. 보안 핸드셰이크 오류는 시간, 서버 이름, 보안 매개변수를 확인하고 인증 실패는 사용자 정보를 점검하세요. 로그에 한 번 실패가 기록됐다고 전체 서비스가 사용할 수 없는 것은 아닙니다. 실제 접속 결과와 반복 테스트를 함께 확인하세요.

속도가 느리면 계층별로 확인하세요. 같은 그룹의 다른 정상 회선을 사용해 보고, 시간대와 대상에 따른 차이를 비교한 뒤 기기 자원, 네트워크 제어 도구의 충돌, 라우팅 설정을 점검합니다. 지연 시간이 가장 낮은 회선이 처리량도 가장 높다고 단정하지 마세요. 원격 대상의 속도 제한을 로컬 포트 탓으로 돌리지 마세요. 속도 저하 단계별 문제 해결 방법에 따라 테스트 내용을 기록하세요. 한 번에 변수 하나만 바꾸고 실패하면 되돌리세요. 검증되지 않은 최적화 설정을 계속 쌓는 것보다 효과적입니다.

로그를 공유하기 전에 구독 주소, 사용자 ID, 비밀번호, 전체 접속 기록을 가리고 필요한 오류 상황만 남기세요. 일시적으로 로그 상세 수준을 높이면 원인을 찾는 데 도움이 되지만, 지나치게 자세한 로그를 계속 남기면 디스크 사용량과 개인정보 노출 위험이 커집니다. 문제를 해결한 뒤에는 적절한 수준으로 되돌리세요. 서비스 만료일, 자동 업데이트 결과, 백업 복구 가능 여부를 정기적으로 확인해 주로 사용하는 항목이 만료된 뒤에야 원본 정보를 찾는 일이 없도록 하세요.

간단한 유지 관리 순서를 정해두세요. 먼저 출처가 유효한지 확인하고, 활성 서버, 연결 입구와 라우팅, 시스템 환경 순으로 점검합니다. 재설치는 프로그램이나 설정이 실제로 손상됐고 복구 자료를 갖춘 경우에만 고려하세요. 모든 네트워크 문제의 첫 번째 해결 방법은 아닙니다. 사용자 지정 설정을 적고 명확하게 유지해 각 항목의 이유를 알면 기기나 네트워크를 바꾼 뒤에도 빠르게 복구할 수 있습니다.

9단계 · 고급 설정 익히기

고급 설정과 구성 검증

복잡한 조합에 앞서 설정 구조 이해하기

앞의 8단계를 마친 뒤 코어 설정의 연결 입구, 외부 연결, 라우팅, DNS, 로그 구조를 학습하세요. 목표는 그래픽 인터페이스를 모두 손으로 작성한 파일로 바꾸는 것이 아니라 생성된 결과를 읽고 각 설정이 최종적으로 어디에 적용되는지 이해하는 것입니다. 그래픽 클라이언트는 실행 설정을 관리하고 생성하므로 임시 생성 파일을 직접 수정하면 재시작하거나 서버를 바꿀 때 변경 사항이 사라질 수 있습니다. 사용자 설정, 사용자 지정 설정, 실행 중인 파일을 먼저 구분한 다음 수정할 위치를 정하세요.

설정을 읽을 때는 요청 하나의 흐름부터 따라가세요. 어느 인바운드로 들어오는지, 어떤 대상 정보를 담는지, 어떤 규칙을 통과하는지, 마지막으로 어느 아웃바운드를 선택하는지 확인합니다. 이름 사이의 참조 관계도 살펴보세요. 특히 라우팅 규칙에서 지정한 아웃바운드 태그가 실제로 존재하는지 확인해야 합니다. 필드 문법이 맞아도 업무상 동작이 올바르다는 뜻은 아닙니다. JSON 파싱이 성공해도 원격 서버가 해당 매개변수를 받아들인다고 볼 수 없습니다. 문법 검증, 코어 실행, 대상 접속을 각각 확인해 “파일 저장 성공”을 전체 설정 성공으로 오해하지 마세요.

필요에 따라 프로토콜과 DNS 학습하기

프로토콜은 현재 사용하는 서비스에 필요한 기능부터 살펴보세요. VLESS를 사용할 때는 사용자 ID, 전송 방식, 보안 계층이 각각 어떤 역할을 하는지 확인합니다. REALITY 같은 기능을 사용한다면 다른 설정에서 매개변수를 가져와 섞지 말고 서비스 제공처의 요구 사항을 하나씩 확인하세요. 코어마다 지원 범위와 기본 동작이 다를 수 있으므로 이전하기 전에 실제 지원 여부를 점검하세요. 생소한 옵션은 해당 코어의 개념 안내를 먼저 읽고 별도의 설정 항목에서 테스트하세요. 주로 사용하는 설정을 바로 덮어쓰지 마세요.

DNS를 더 깊이 이해하려면 조회 경로부터 살펴보세요. 어느 구성 요소가 조회를 시작하는지, 요청이 직접 연결되는지 프록시를 거치는지, 반환된 주소가 라우팅에 어떤 영향을 주는지, 앱이 시스템 DNS를 우회하는지 확인합니다. 암호화 DNS가 모든 개인정보 보호와 연결 문제를 자동으로 해결하는 것은 아닙니다. 사용 가능한 네트워크 경로가 필요하며 사내 도메인과 충돌할 수도 있습니다. DNS 서버, 도메인 정책, 라우팅 리소스를 한꺼번에 바꾸지 마세요. 작동하는 기준 설정을 유지하면서 변경 결과를 계층별로 확인하세요.

사용 시나리오 목록으로 전체 설정 검증하기

웹페이지 하나만 테스트해서는 충분하지 않습니다. 일반 브라우저, 별도의 프록시 설정이 필요한 앱, LAN 대상, 실제로 필요한 UDP 시나리오를 각각 확인하세요. 클라이언트 종료, 시스템 절전, 네트워크 전환, 재시작도 테스트해야 합니다. 각 상황에서 어떤 트래픽은 프록시로 가고 어떤 트래픽은 직접 연결되는지, 연결이 끊긴 뒤 복구되는지 분명히 정하세요. 아직 필요하지 않은 항목은 검증되지 않았다고 기록하세요. 한 번 성공했다고 모든 시나리오가 안정적이라고 판단하지 마세요.

여러 기기에서 사용해야 한다면 각 기기에서 정식 출처를 별도로 가져와 플랫폼별로 검증하세요. 로컬 연결을 공유해야 하는 경우에만 LAN 수신 설정을 검토하세요. 수신 범위를 넓히면 다른 기기가 프록시 서비스에 접근할 수 있으므로 인증, 방화벽, 신뢰할 수 있는 네트워크 범위, 서비스 약관을 함께 고려해야 합니다. “LAN 연결 허용”을 일상적인 속도 향상 옵션으로 사용하지 말고 신뢰할 수 없는 네트워크에 로컬 관리 인터페이스를 공개하지 마세요.

계속 확인할 때는 문제에 맞는 문서를 선택하세요. 인터페이스 위치가 익숙하지 않다면 메인 창 안내를, 가져올 자료의 형식을 모르겠다면 구독 및 공유 형식 안내를 읽으세요. 연결 입구와 라우팅을 혼동한다면 이 페이지의 프록시 모드 및 라우팅 장을 다시 확인하세요. 이 사이트에는 별도의 FAQ 페이지가 없습니다. 일반적인 사용 문제는 사용 가이드의 확인 절차에서 계속 살펴보세요. 존재하지 않는 메뉴나 페이지를 찾느라 시간을 낭비하지 않아도 됩니다.

완성된 설정은 이유를 설명할 수 있고, 같은 결과를 재현할 수 있으며, 문제가 생겼을 때 복구할 수 있어야 합니다. 출처와 권한, 앱이 클라이언트에 연결되는 방식, 규칙이 특정 외부 연결을 선택하는 이유, 업데이트 실패 시 되돌리는 방법을 파악하세요. 단순한 주 사용 설정 하나를 유지하고 시험용 설정은 별도로 관리하세요. 새로운 프로토콜, 네트워크, 앱을 만났을 때도 개념, 연결 입구, 외부 연결, 검증 순서로 확인하면 모든 매개변수를 처음부터 추측할 필요가 없습니다.