V2Ray 전체 플랫폼
설치 및 설정 가이드

01 / BEFORE INSTALLATION

공통 준비: 시스템, 구독, 네트워크 연결

클라이언트, 코어, 서버 설정의 역할 구분

GUI 클라이언트는 서버 매개변수 저장, 구독 관리, 설정 생성, 코어 실행을 담당합니다. 코어는 프로토콜 연결, 트래픽 전달, 라우팅 판단을 처리합니다. 데스크톱에서는 v2rayN을, Android에서는 Xray 코어를 탑재한 v2rayNG를 우선 사용하세요. V2Fly 설정이 필요한 경우에는 v2flyNG를 고려할 수 있습니다. 클라이언트를 설치해도 사용할 수 있는 서버가 자동으로 제공되지는 않으며, 구독 제공업체의 계정이나 서비스를 대신하지도 않습니다. 시작하기 전에 사용 권한이 있는 구독 링크나 단일 서버 공유 링크를 준비하고 유효 기간이 남아 있는지 확인하세요.

Project V는 관련 구성 요소를 이해하기 위한 배경 지식이지, 별도로 설치해야 하는 데스크톱 앱이 아닙니다. V2Fly와 Xray는 관련 코어 생태계에 속하며 지원 범위는 코어 구현에 따라 달라집니다. 특정 설정의 사용 가능 여부는 프로토콜, 전송 방식, 보안 매개변수와 실제 코어 기능의 조합에 달려 있습니다. 클라이언트 이름만으로 판단할 수 없습니다. 구성 요소 간 관계를 살펴보려면 Project V, V2Fly, Xray 생태계 이해하기를 읽고 코어 변경 여부를 결정하세요.

시스템 아키텍처와 설치 위치 확인

프로세서 아키텍처는 기기 출시 연도가 아니라 운영체제에 표시된 정보를 기준으로 확인하세요. Windows에서는 시스템 정보의 시스템 종류를, macOS에서는 ‘이 Mac에 관하여’의 칩 정보를 확인합니다. Linux에서는 아래 명령을 실행할 수 있습니다. 다운로드 페이지에는 실제 제공되는 설치 파일만 표시됩니다. 아키텍처가 맞지 않는다면 반복해서 실행하는 방식으로 해결하려 하지 마세요. 설치 위치도 미리 정해야 합니다. 포터블 디렉터리는 사용자에게 쓰기 권한이 있어야 하며, 설치 프로그램이 관리하는 디렉터리에 설정 파일을 수동으로 섞어 넣는 것은 피하는 편이 좋습니다.

uname -m
cat /etc/os-release

Linux에서 x86_64는 일반적인 x64 패키지에, aarch64는 arm64 패키지에 해당합니다. 배포판 정보는 deb와 rpm 중 어떤 형식을 선택할지 판단하는 데 사용하며, 데스크톱 프록시가 반드시 어떤 방식으로 적용되는지를 판단하는 기준은 아닙니다. 시스템, 데스크톱 환경, 애플리케이션은 각각 자체 네트워크 설정을 사용하므로 따로 확인해야 합니다. 새로 설치할 때는 기본 디렉터리 구조를 유지하세요. 실행 파일만 따로 옮기면 함께 제공된 리소스나 실행 구성 요소가 누락될 수 있습니다.

복구 가능한 네트워크 기준 상태 만들기

설치 전에 트래픽을 처리 중인 다른 프록시나 터널 프로그램을 종료하고, 기존 시스템 프록시 상태를 기록해 두세요. 일반 네트워크 접속이 정상인지, 시스템 시간과 시간대가 정확한지 확인합니다. 시간 오차는 인증서 검증 실패를 일으킬 수 있고, 이전 프록시 설정이 남아 있으면 구독 업데이트 요청이 종료된 로컬 포트로 전달될 수 있습니다. 이 경우 클라이언트가 실행되기도 전에 발생한 문제를 클라이언트 오류로 오해하기 쉽습니다. 기준 상태를 확인하지 않은 채 네트워크 어댑터, 리졸버, 라우팅 프리셋을 한꺼번에 변경하지 마세요.

처음 연결을 확인할 때는 TUN보다 시스템 프록시를 먼저 사용하세요. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에서 작동하므로 브라우저 연결을 먼저 확인하기에 적합합니다. TUN은 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 처리하며, 추가 권한이 필요하고 DNS, 로컬 네트워크, 다른 가상 네트워크에 영향을 줄 수 있습니다. 둘은 서버 프로토콜의 차이가 아니며, 더 많은 기능을 켠다고 연결이 안정되는 것도 아닙니다. 기본 연결을 확인한 뒤 대상 앱이 프록시를 따르는지에 따라 TUN 사용 여부를 결정하세요.

백업 및 개인정보 보호

기기에 기존 설정이 있다면 먼저 클라이언트에서 지원하는 내보내기 또는 백업 기능을 사용하세요. 데이터 디렉터리를 수동 복사하려면 쓰기 도중 파일이 손상되지 않도록 프로그램을 먼저 종료합니다. 백업에는 구독 그룹, 라우팅, 사용자 지정 DNS, 필요한 로컬 설정이 포함되어야 합니다. 구독 주소에는 계정 식별 정보가 들어 있는 경우가 많고, 공유 링크에도 인증 정보가 포함될 수 있습니다. 공개 스크린샷, 게시물, 공개 클라우드 저장소에 올리지 마세요. 문제를 확인할 때는 가려진 오류 유형과 발생 시각만 우선 공유하세요.

02 / WINDOWS

Windows: v2rayN 설치 및 프록시 설정

데스크톱 버전과 클래식 WPF 버전 선택

Windows 다운로드 섹션에서 운영체제 아키텍처를 확인한 다음 v2rayN 데스크톱 버전 또는 클래식 WPF 버전을 선택하세요. 데스크톱 버전은 최신 크로스 플랫폼 인터페이스를 사용하고, WPF 버전은 기존 Windows 인터페이스를 유지합니다. 두 버전은 모두 설정을 관리하는 클라이언트이며 서버 연결 품질이 다른 것은 아닙니다. 기존 설정을 옮겨야 한다면 먼저 백업하고, 선택한 인터페이스에서 이전 데이터를 읽을 수 있는지 확인하세요. 두 프로그램이 같은 설정 디렉터리에 동시에 쓰도록 하지 마세요.

설치 프로그램은 안내에 따라 설치하고, 포터블 패키지는 전체 압축을 푼 뒤 실행하세요. 압축 파일 미리보기에서 직접 실행하거나 실행 파일만 복사하지 마세요. 설정이 사라지지 않도록 압축을 푼 디렉터리는 임시 폴더가 아닌 고정된 쓰기 가능 위치에 두는 것이 좋습니다. 실행에 필요한 구성 요소가 없다는 메시지가 표시되면 해당 패키지 안내와 시스템 알림을 확인해 필요한 구성 요소를 설치하세요. 출처를 알 수 없는 곳에서 개별 DLL 파일을 내려받아 교체하지 마세요. 실행 환경이 누락된 것인지 프로그램 리소스가 빠진 것인지 판단할 수 있도록 오류 메시지를 보관하세요.

실행 후 구독을 가져와 목록 확인

처음 실행하면 기본 화면이 정상적으로 표시되는지 확인한 뒤 구독 그룹 관리로 이동하세요. 그룹을 추가하고 알아보기 쉬운 이름을 입력한 다음 전체 구독 주소를 주소 필드에 붙여넣고 저장한 뒤 구독을 업데이트합니다. 주소를 추가하는 것과 내용을 업데이트하는 것은 별개의 작업입니다. 그룹만 추가했다고 서버 정보를 가져온 것은 아닙니다. 업데이트가 끝나면 서버 목록에서 프로토콜, 주소, 포트 등 기본 항목이 채워졌는지 확인하세요. 메뉴 이름은 버전에 따라 달라질 수 있으므로 현재 화면의 구독 관리 메뉴를 기준으로 진행하세요.

클립보드에 단일 서버 공유 링크가 있다면 원격 구독 주소로 입력하지 말고 클라이언트의 클립보드 가져오기 기능을 사용하세요. 웹페이지 주소라고 해서 모두 구독 링크인 것은 아닙니다. 계정 관리 페이지, 로그인 페이지, 서버 설정을 반환하는 API는 용도가 서로 다릅니다. 업데이트 후 목록이 비어 있다면 업데이트 로그에서 요청 결과를 확인한 뒤 구독 제공업체에 링크 형식과 계정 상태를 문의하세요. 목록을 표시하기 위해 인증서 검증을 끄거나 인증 매개변수를 임의로 삭제하지 마세요.

먼저 시스템 프록시를 확인한 뒤 적용 범위 확대

사용할 서버를 선택해 현재 항목으로 지정하고 코어가 정상적으로 시작되는지 확인한 다음 시스템 프록시 자동 설정을 선택하세요. 이 설정은 Windows 시스템 프록시를 따르는 앱을 로컬 리스닝 주소로 연결합니다. 로컬 포트는 클라이언트 설정에서 확인하고 다른 기기의 포트를 그대로 사용하지 마세요. HTTPS 접속이 정상인 것으로 알려진 페이지를 브라우저에서 열고 해당 연결이 로그에 표시되는지 확인합니다. 페이지가 열리지 않으면 먼저 코어가 실행 중인지 확인한 다음 서버 연결을 점검하세요. 곧바로 모든 라우팅 옵션을 바꾸지는 마세요.

Windows 시스템 프록시를 설정해도 모든 프로그램이 이를 따르는 것은 아닙니다. 일부 명령줄 도구, 서비스 프로세스, 자체 프록시 설정이 있는 앱은 별도로 설정해야 합니다. 시스템의 네트워크 구성 요소마다 다른 프록시를 사용할 수도 있으므로 브라우저가 정상이라고 해서 특정 프로그램의 실패가 서버 문제라는 뜻은 아닙니다. 먼저 해당 프로그램이 HTTP 또는 SOCKS 프록시를 지원하는지 확인하고 클라이언트에서 실제로 사용 중인 로컬 리스닝 주소를 입력하세요. 이 기기에서만 사용할 경우 루프백 주소로 리스닝해 같은 네트워크의 다른 기기에 실수로 노출되지 않도록 하세요.

TUN 권한과 종료 순서

기본 연결을 확인한 뒤 시스템 프록시를 따르지 않는 앱이 있다면 TUN 모드를 고려하세요. 처음 활성화할 때는 현재 클라이언트 구현에 따라 관리자 권한, 서비스 구성 요소, 가상 인터페이스가 필요할 수 있습니다. 프로그램 안내에 따라 권한을 허용한 뒤 인터페이스와 라우팅이 정상적으로 설정되었는지 시작 로그를 확인하세요. 스위치가 켜져 있다는 사실만으로 트래픽 처리가 완료됐다고 판단하지 마세요. 권한 거부, 인터페이스 생성 실패, 다른 터널과의 충돌로 인해 표시 상태와 실제 네트워크 경로가 다를 수 있습니다.

가상 머신, 사내 네트워크, 다른 터널 도구를 함께 사용하는 환경에서는 로컬 네트워크 접근을 유지하면서 항목별로 테스트하세요. TUN을 켠 뒤 일부 리소스에만 접근할 수 없다면 라우팅과 DNS를 우선 확인하고 가상 어댑터를 반복해서 재설치하지 마세요. 사용을 마칠 때는 먼저 TUN을 끄고 시스템 프록시를 해제한 다음 클라이언트를 종료합니다. 비정상 종료 후 브라우저에서 네트워크에 전혀 접속할 수 없다면 Windows 프록시 설정이 종료된 로컬 포트를 가리키는지 확인하고, 필요하면 원래 설정으로 복구하세요.

시작 시 자동 실행과 연결 성공은 별개의 문제입니다. 먼저 수동 실행이 안정적인지 확인한 뒤 클라이언트의 자동 시작 옵션을 활성화하세요. 관리자 권한이 필요한 TUN은 일반 로그인 자동 실행과 다른 방식으로 동작할 수 있으므로 설정 후 로그아웃하거나 재부팅해 실제로 확인해야 합니다. 기본 창, 트레이, 로그, 매개변수 설정의 관계는 v2rayN 기본 화면 기능 안내를 참고하세요. 창을 닫는 것과 프로세스를 완전히 종료하는 것을 혼동하지 않도록 주의하세요.

03 / MACOS

macOS: 칩 확인, 설치 및 네트워크 권한

칩에 맞는 패키지를 내려받아 앱 설치

시스템의 ‘이 Mac에 관하여’를 열어 Apple Silicon 칩인지 Intel 프로세서인지 확인한 뒤 macOS 다운로드 섹션에서 해당 v2rayN 패키지를 선택하세요. arm64와 x64는 인터페이스 언어나 기능 등급이 아니라 프로세서 아키텍처를 뜻합니다. 호환 계층을 통해 앱이 실행된다고 해서 패키지가 맞는 것은 아닙니다. 네이티브 아키텍처에 맞는 패키지를 사용하면 실행 구성 요소와 권한 문제를 확인할 때 변수가 줄어듭니다. 특히 나중에 TUN을 사용할 계획이라면 더욱 중요합니다.

다운로드가 끝나면 디스크 이미지를 열고 패키지 안내에 따라 앱을 고정된 응용 프로그램 폴더로 옮긴 뒤 해당 위치에서 실행하세요. 마운트된 이미지에서 계속 실행하거나 앱 실행 중에 전체 프로그램 디렉터리를 옮기지 마세요. 처음 실행할 때 시스템에서 출처와 실행 권한을 확인할 수 있습니다. 선택한 다운로드 경로에서 받은 설치 파일인지 확인하고 시스템 안내를 읽은 뒤 허용 범위 안에서 진행하세요. 시스템의 보안 검사를 전역으로 끄는 것을 설치 절차로 삼지 마세요.

앱이 실행되지 않는다면 아키텍처 오류, 시스템 요구 사항 미충족, 실행 구성 요소 누락, 시스템의 실행 차단을 구분해야 합니다. 앞의 두 문제는 권한을 반복해서 허용해도 해결되지 않으며, 뒤의 두 문제도 앱 이름을 임의로 바꾼다고 해결되지 않습니다. 먼저 오류 창의 문구와 시스템 정보를 기록한 뒤 패키지 안내와 대조하세요. 터미널에서 확장 속성을 삭제하는 명령은 문제 원인을 확인하지 않고 우회할 수 있으므로 일반적인 해결 방법으로 사용하지 마세요. 잘못된 디렉터리에 적용될 위험도 있습니다.

구독을 가져오고 현재 서버 확인

v2rayN을 실행한 뒤 구독 그룹 관리로 이동해 그룹을 만들고 전체 주소를 저장한 다음 업데이트하세요. 처음 업데이트할 때는 현재 정상적으로 작동하는 일반 네트워크를 사용하는 것이 좋습니다. 구독 API가 기존 프록시를 통해서만 연결된다면 이전 연결이 정상인지 확인한 뒤 해당 업데이트 방식을 선택하세요. 구독을 받으려면 연결이 필요하고 연결하려면 구독이 필요한 순환 상태를 만들지 마세요. 업데이트 후 서버를 선택해 현재 항목으로 지정하고, 시스템 프록시를 조정하기 전에 코어가 정상적으로 시작되는지 확인하세요.

macOS 네트워크 설정은 네트워크 서비스별로 관리됩니다. Wi-Fi, 유선 네트워크, 기타 네트워크 인터페이스마다 프록시 매개변수가 따로 저장될 수 있으므로 네트워크를 바꾼 뒤 현재 서비스의 프록시 상태를 다시 확인하세요. 클라이언트의 자동 설정은 현재 사용 중인 서비스에 적용되어야 합니다. 브라우저가 여전히 직접 연결된다면 시스템 네트워크 세부 정보의 프록시 설정을 확인하고 서버 매개변수를 곧바로 바꾸지 마세요. 수동 설정 시에는 원격 서버 포트가 아니라 로컬 루프백 주소와 클라이언트에 표시된 포트를 입력해야 합니다.

시스템 프록시와 앱별 설정 구분

시스템 프록시를 따르는 앱은 자동 설정된 프록시를 사용할 수 있지만, 자체 네트워크 설정이 있는 도구는 이를 무시할 수 있습니다. 터미널 도구도 데스크톱 네트워크 서비스의 프록시 항목을 읽지 않을 수 있습니다. 특정 도구를 설정할 때는 먼저 지원하는 프록시 방식과 설정 적용 범위를 확인하세요. 임시 테스트 매개변수를 모든 로그인 세션에 기록하지 않도록 주의합니다. 도구가 SOCKS를 지원한다면 도메인 조회가 로컬과 프록시 중 어디에서 이루어지는지도 확인하세요. 같은 서버인데 결과가 다른 경우 전송 문제가 아니라 DNS 조회 경로의 차이일 수 있습니다.

브라우저는 정상이지만 개발 도구에서 문제가 발생하면 해당 도구에 저장된 이전 프록시 주소를 지우고 클라이언트의 현재 리스닝 설정과 대조하세요. 프록시 포트가 바뀌어도 앱별 설정은 자동으로 따라 바뀌지 않습니다. 로컬 서비스에 접속할 때는 루프백과 로컬 네트워크 직접 연결 정책을 유지해 디버깅 트래픽이 원격 출구로 전달되지 않도록 하세요. 편의를 위해 필요하지 않은 로컬 네트워크 공유를 켜지 마세요. 기기 내부에서 프록시를 사용하는 것과 다른 기기에 프록시를 제공하는 것은 별도의 배포 작업입니다.

TUN과 다른 네트워크 확장 기능 함께 사용하기

더 많은 앱의 트래픽을 처리해야 할 때 클라이언트에서 실제로 제공하는 TUN 기능을 활성화하세요. 시스템에서 관리자 권한이나 관련 보조 구성 요소를 요구할 수 있으며, 권한 요청은 클라이언트 구현에 따라 다릅니다. 권한을 허용한 뒤 로그와 시스템 네트워크 상태를 확인해 가상 인터페이스가 실제로 만들어졌는지 확인하세요. 사내 터널, 네트워크 필터, 가상 머신 네트워크를 사용 중이라면 한 번에 하나의 트래픽 처리 방식을 켜서 확인한 뒤 함께 사용해 보세요. 여러 구성 요소가 동시에 기본 경로를 바꾸면 연결이 자기 자신을 경유하거나 로컬 네트워크에 접근하지 못할 수 있습니다.

잠자기에서 깨어난 뒤, Wi-Fi를 바꾸거나 유선 네트워크에 연결한 뒤 TUN 모드만 작동하지 않는다면 먼저 TUN을 껐다가 다시 켜고 DNS가 현재 네트워크에 맞게 복구되는지 확인하세요. 터널을 중지하지 않은 상태에서 여러 DNS 서버를 연달아 변경하지 마세요. 시스템 프록시 모드가 작동한다면 우선 해당 모드로 돌아가 연결을 유지한 뒤 TUN 문제를 살펴보세요. 앱을 종료하기 전에 앱이 설정한 프록시를 해제하고, 특히 비정상 종료 후 시스템에 로컬 루프백 주소가 남아 있는지 확인하세요.

04 / LINUX

Linux: deb·rpm 및 데스크톱 프록시 환경

패키지 형식을 선택한 뒤 설치 의존성 확인

Linux 데스크톱에서는 v2rayN을 사용합니다. 배포판과 아키텍처를 확인한 뒤 Linux 다운로드 섹션에서 deb 또는 rpm 패키지를 선택하세요. Debian, Ubuntu 계열은 보통 deb를 사용하고 Fedora, openSUSE 등은 rpm 패키지 체계를 사용하지만, 의존성 처리 방식은 배포판에 따라 달라집니다. x64와 arm64에 맞는 패키지를 각각 선택하세요. 패키지 형식이 맞는다고 아키텍처까지 맞는 것은 아닙니다. 다운로드 후 배포판의 그래픽 소프트웨어 설치 도구를 사용하거나 로컬 패키지 설치 명령을 실행할 수 있습니다.

아래 두 명령은 각각 해당 패키지 관리 환경에서 사용합니다. 시스템에 맞는 명령 하나만 실행하세요. 설치 파일을 저장한 디렉터리에서 터미널을 열고 파일 경로를 실제로 다운로드한 전체 파일명으로 바꾸면 됩니다. 패키지 관리자를 사용해 로컬 파일을 설치하면 의존성도 함께 처리할 수 있습니다. 설치에 실패하면 의존성 이름, 아키텍처, 저장소 오류를 확인하세요. 의존성을 강제로 무시해 프로그램을 불안정한 상태로 만들지 마세요. openSUSE에서는 해당 시스템의 소프트웨어 관리 도구를 사용하고 Fedora 명령을 그대로 적용하지 마세요.

sudo apt install ./실제로_다운로드한_파일명.deb

sudo dnf install ./실제로_다운로드한_파일명.rpm

설치가 끝나면 데스크톱 앱 메뉴에서 실행하세요. 그래픽 프로그램은 일반 사용자 권한으로 실행하고 설정도 해당 사용자 환경에 저장해야 합니다. 설치된 프로그램을 실행하려고 인터페이스 전체를 계속 최고 관리자 권한으로 실행하지 마세요. 최고 관리자 계정 소유의 설정 파일이 생겨 일반 사용자로 실행할 때 쓰지 못할 수 있습니다. 가상 네트워크 인터페이스나 보조 서비스에 실제로 필요한 경우에만 클라이언트 안내에 따라 권한을 부여하세요. 시스템 프록시 문제를 모두 권한 부족으로 돌려서는 안 됩니다.

구독 가져오기와 데스크톱 환경별 차이

구독 그룹에 주소를 추가하고 저장한 뒤 업데이트한 다음 현재 서버를 선택하세요. 프록시를 설정하기 전에 코어가 시작되고 로그에 파일 누락이나 리스닝 실패가 없는지 확인합니다. GNOME, KDE 등 데스크톱 환경마다 프록시 설정 인터페이스가 다르고, 앱이 데스크톱 프록시를 읽는 방식도 제각각입니다. 클라이언트에 시스템 프록시가 설정되었다고 표시되어도 해당 작업이 적용되었다는 뜻일 뿐, 모든 프로세스가 프록시를 통과한다는 의미는 아닙니다. 브라우저와 실제로 사용할 도구를 각각 테스트하세요.

브라우저는 되지만 터미널에서 접속할 수 없다면 터미널 프로세스의 환경을 먼저 확인하세요. 아래 명령은 일반적인 프록시 환경 변수만 조회하며 네트워크 설정을 변경하지 않습니다. 변수 이름의 대소문자 처리 방식은 도구마다 다를 수 있고, 이전 세션에는 이미 중지된 포트가 남아 있을 수 있습니다. 특정 명령에만 임시 프록시를 지정하려면 해당 도구가 지원하는 일회성 옵션을 우선 사용하세요. 효과를 확인한 뒤 영구 설정 여부를 결정하고, 모든 사용자가 공유하는 환경 파일에 바로 기록하지 마세요.

env | grep -iE '^(http|https|all|no)_proxy='

데스크톱 프록시, 환경 변수, 앱 내부 프록시는 서로 독립된 세 가지 경로입니다. 모두 같은 로컬 리스닝 주소를 가리킬 수 있지만 자동으로 동기화되지는 않습니다. NO_PROXY를 사용하는 도구는 일부 목적지에 대한 프록시를 우회할 수 있으며, 매칭 문법도 도구마다 완전히 같지 않습니다. 특정 도메인이 계속 직접 연결된다면 클라이언트 라우팅뿐 아니라 도구 자체의 우회 목록도 확인하세요. 잘못된 단계에서 GeoSite 규칙을 반복해서 바꾸지 않도록 주의합니다.

TUN, DNS 리졸버, 컨테이너 네트워크

TUN을 사용하려면 가상 네트워크 인터페이스에 접근하고 라우팅을 설정하는 데 필요한 권한이 있어야 합니다. 활성화에 실패하면 먼저 클라이언트 로그에서 권한 및 장치 관련 오류를 확인한 뒤 현재 패키지에서 안내하는 방식으로 보조 구성 요소를 설정하세요. 설치 디렉터리 전체에 재귀적으로 쓰기 권한을 열거나 출처를 알 수 없는 바이너리에 임의로 시스템 권한을 부여하지 마세요. 배포판의 보안 정책, 서비스 실행 방식, 설치 패키지 구조에 따라 결과가 달라지므로 다른 시스템의 권한 상승 명령을 그대로 복사하지 말고 오류에 맞게 조치하세요.

Linux DNS는 네트워크 관리자, 로컬 리졸버 또는 다른 구성 요소가 관리할 수 있습니다. TUN을 켠 뒤 도메인으로만 접속할 수 없고 이미 알고 있는 주소로는 연결된다면 DNS 조회 경로와 클라이언트 DNS 설정을 확인하세요. 임시로 생성된 리졸버 파일을 유일한 설정 원본으로 보고 반복해서 덮어쓰지 마세요. 네트워크가 다시 연결되면 파일이 새로 생성될 수 있습니다. 컨테이너, 가상 머신, 브리지는 별도의 라우팅과 DNS를 사용할 수 있으므로 해당 네트워크 대역의 접근을 유지한 뒤 TUN에 포함할지 판단하세요.

로그인 시 자동 실행과 업그레이드 복구

데스크톱 클라이언트는 보통 사용자가 로그인해 그래픽 세션이 시작된 뒤 실행해야 합니다. 먼저 프로그램의 자동 시작 옵션을 사용하고 데스크톱 시작 프로그램 목록에 같은 항목이 중복 등록되어 있지 않은지 확인하세요. 데스크톱 자동 시작, 사용자 서비스, 시스템 서비스를 동시에 사용해 같은 설정을 실행하면 포트가 충돌하기 쉽습니다. 자동 시작 후에는 프로세스가 있다는 것만으로 트래픽 처리가 완료되었다고 판단하지 말고 현재 세션에 시스템 프록시가 설정되었는지 확인하세요.

업그레이드 전 클라이언트를 종료하고 데이터를 백업한 뒤 기존과 같은 설치 경로와 패키지 체계를 우선 사용하세요. 업그레이드 후 화면은 정상인데 연결되지 않는다면 사용자 디렉터리를 바로 삭제하지 말고 코어 경로, 설정 호환성, 규칙 리소스를 확인하세요. 복구할 때는 이번 로그를 보존하고 백업 상태와 차이를 비교하세요. 설치 프로그램, 데스크톱 시작 항목, 로그인 시 자동 실행에 대한 자세한 절차는 v2rayN Linux 설치 및 자동 시작 안내에서 확인할 수 있습니다.

05 / ANDROID

Android: 클라이언트 설치 및 VPN 권한

v2rayNG와 v2flyNG 중 선택

Android 다운로드 섹션에서 Xray 코어를 탑재한 v2rayNG를 우선 선택하세요. v2flyNG는 V2Fly 코어를 사용하는 대안으로, 설정이 해당 코어와 맞는지 확인한 경우에 적합합니다. 같은 설정을 확인하기 위해 여러 클라이언트를 기본적인 문제 해결 방법으로 반복 설치하지 마세요. 먼저 현재 코어가 프로토콜, 전송 방식, 보안 매개변수를 지원하는지 확인하세요. 두 앱의 데이터는 각각 독립적으로 관리되므로 다른 앱을 설치해도 기존 구독, 라우팅, 권한이 자동으로 옮겨지지 않습니다.

최신 기기는 대체로 arm64를 사용합니다. 기기 아키텍처를 확인하기 어렵다면 다운로드 페이지에서 제공하는 범용 패키지를 고려할 수 있습니다. 정확한 판단은 기기 시스템 정보와 패키지 안내를 기준으로 하세요. 시스템 설치 프로그램에서 호환되지 않는다고 표시되면 아키텍처, 시스템 요구 사항, 다운로드 완료 여부를 확인합니다. 기존 앱과 충돌한다는 메시지가 표시되면 패키지 출처와 서명이 일치하는지 확인하세요. 문제를 확인하기 전에 앱을 삭제하지 마세요. 삭제하면 앱 전용 데이터가 함께 제거되어 기존 구독과 사용자 설정을 복구하지 못할 수 있습니다.

외부에서 받은 앱을 설치할 때 Android는 설치를 시작한 출처에 따라 권한을 관리합니다. 현재 사용하는 파일 관리자나 브라우저에만 필요한 권한을 부여하고 설치가 끝나면 필요에 따라 권한을 취소하세요. 조직에서 관리하는 기기는 설치나 VPN 권한이 정책으로 제한될 수 있으므로 기기 관리 규정을 따르세요. 알 수 없는 도구로 시스템 제한을 우회하지 마세요. 설치 권한, 앱 호환성, 기기 정책 중 무엇이 문제인지 확인한 뒤 다음 조치를 결정하세요.

구독 추가, 업데이트, 설정 선택

앱에서 구독 설정 또는 구독 그룹 메뉴를 열고 이름과 전체 URL을 추가한 뒤 저장합니다. 기본 화면으로 돌아와 업데이트를 실행하세요. 원격 구독과 클립보드의 단일 설정은 각각 전용 메뉴를 사용해야 합니다. 업데이트가 끝나면 목록에 설정이 표시되는지 확인하고 연결할 항목을 선택하세요. 서비스 제공업체가 프로토콜별 항목을 여러 개 제공한다면 안내에 따라 선택하세요. 목록 순서만으로 성능을 추정하거나 관련 없는 다른 설정에 주소와 인증 정보를 조합하지 마세요.

QR 코드 가져오기는 단일 공유 설정을 추가할 때 편리하지만, QR 코드 내용에 인증 정보가 포함될 수 있습니다. 시스템 스크린샷이나 기기 간 이미지 전송을 사용할 때는 이미지 저장 위치와 공유 범위를 확인하세요. 구독 업데이트에 실패하면 앱 로그를 확인해 요청 실패, 빈 응답, 파싱 실패를 구분하세요. 계정 웹사이트가 브라우저에서 열린다고 구독 API까지 작동하는 것은 아닙니다. API는 전체 경로와 쿼리 매개변수가 필요할 수 있으므로 주소를 복사할 때 일부를 빠뜨리면 전혀 다른 응답이 반환됩니다.

시스템 VPN 권한과 앱 적용 범위 이해

처음 연결할 때 Android는 보통 시스템 VPN 인터페이스를 통해 로컬 트래픽을 처리하므로 시스템에 표시되는 연결 권한을 확인해야 합니다. 이 권한은 기기 트래픽이 클라이언트로 들어가는 통로일 뿐, 원격 서버 연결까지 성공했다는 뜻은 아닙니다. 권한을 허용한 뒤에도 로그와 실제 접속 결과를 확인하세요. 상태 표시줄에 VPN 아이콘이 나타나면 로컬 인터페이스가 작동 중이라는 의미일 뿐, 선택한 서버에 연결할 수 있거나 DNS가 예상대로 동작한다는 것을 단독으로 증명하지 않습니다.

Android에서는 보통 활성 VPN 연결을 한 번에 하나의 앱만 사용할 수 있습니다. 다른 터널 앱, 네트워크 필터 앱, 업무 프로필의 네트워크 구성 요소가 있다면 먼저 충돌 여부를 확인한 뒤 연결을 테스트하세요. 앱별 분할 목록도 트래픽 적용 범위를 바꿉니다. 허용 목록과 우회 목록은 의미가 다르며, 저장 후 다시 연결해야 적용될 수 있습니다. 특정 앱이 계속 직접 연결된다면 서버를 바꾸거나 구독을 다시 가져오기 전에 먼저 해당 앱이 적용 범위에 포함되어 있는지 확인하세요.

백그라운드 실행, 네트워크 전환, DNS

화면을 잠근 뒤에만 연결이 끊긴다면 백그라운드 실행과 배터리 정책을 확인하세요. 시스템 설정에서 필요한 백그라운드 활동을 허용한 뒤 화면을 끄고 다시 켜 테스트합니다. 기기마다 메뉴 이름이 다를 수 있으므로 다른 제조사의 화면을 그대로 따라 하지 마세요. 연결을 유지하기 위해 기기의 모든 절전 기능을 끌 필요는 없습니다. 클라이언트와 관련된 제한만 조정하세요. VPN을 항상 사용하도록 설정했다면 ‘연결되지 않았을 때 네트워크 차단’ 옵션과의 관계를 이해해야 일반 네트워크까지 고장 난 것으로 오해하지 않습니다.

Wi-Fi와 모바일 네트워크를 전환하면 IP 주소, DNS 리졸버, 접속 경로가 달라질 수 있습니다. 먼저 앱이 연결을 다시 설정할 때까지 기다린 뒤 로그에서 명확한 오류가 있는지 확인하세요. 특정 네트워크에서만 실패한다면 전체 설정을 삭제하지 말고 해당 네트워크의 로그인 상태, DNS, 서버 연결 가능성을 비교하세요. 시스템 비공개 DNS, 클라이언트 DNS, 앱 자체의 암호화 DNS가 동시에 영향을 줄 수도 있습니다. 한 번에 DNS 설정 하나만 바꾸고 어떤 변경이 결과에 영향을 주었는지 기록하세요.

새 기기로 옮긴 뒤에는 시스템 VPN 권한, 백그라운드 정책, 앱 적용 범위를 다시 확인하세요. 이런 시스템 설정은 설정 파일과 함께 이전되지 않을 수 있습니다. 마이그레이션이 끝나면 기본 라우팅으로 확인한 뒤 사용자 지정 분할 라우팅과 DNS를 복원하세요. 가져오기 메뉴와 업데이트 작업의 일반적인 차이는 빠른 시작 가이드를 따라 확인할 수 있습니다. 설치나 사용 관련 다른 질문은 도움말 센터를 참조하세요.

06 / CONFIGURATION LAYERS

구독 및 분할 라우팅: 저장, 매칭, DNS 조회

구독 업데이트가 모든 설정을 동기화하는 것은 아닙니다

구독은 보통 서버 설정을 배포하는 용도이며 로컬 기기의 모든 환경설정을 동기화하지는 않습니다. 시스템 프록시, 로컬 포트, TUN 권한, 앱별 분할 설정은 대개 기기에서 별도로 관리합니다. 업데이트 과정에서 구독 항목이 교체되거나 다시 만들어질 수 있으므로 덮어써질 항목에 장기적으로 필요한 수정을 저장하지 마세요. 고정 설정이 필요하다면 클라이언트에서 지원하는 별도 설정이나 그룹 기능을 사용하고 수정 이유를 기록하세요. 다음 업데이트 후 구독에서 가져온 값과 직접 변경한 값을 구분하기 쉬워집니다.

구독 업데이트와 서버 연결은 서로 다른 네트워크 경로를 사용할 수 있습니다. 현재 프록시를 사용할 수 없다면 프록시 경유 업데이트가 실패할 수 있고, 직접 연결로 구독 API에 접근할 수 없다면 직결 업데이트도 실패합니다. 우연히 성공할 때까지 방식을 반복해서 바꾸지 말고 실제로 사용 가능한 경로를 기준으로 선택하세요. 업데이트 전후에 그룹, 항목, 현재 선택 항목을 비교해 서버가 교체되었는지 확인한 뒤 다시 테스트할지 결정합니다. 구독에 이전 이름이 남아 있다고 해서 실제 주소까지 그대로라는 뜻은 아닙니다.

먼저 트래픽이 코어에 들어오는지 확인

라우팅 규칙은 이미 코어에 들어온 트래픽만 처리합니다. 앱이 시스템 프록시를 무시한다면 도메인 규칙을 아무리 추가해도 해당 앱의 트래픽이 자동으로 프록시로 들어오지 않습니다. 반대로 TUN으로 코어에 들어온 트래픽도 규칙에 따라 직접 연결할 수 있습니다. 따라서 트래픽을 받아들이는 범위와 원격 출구를 선택하는 것은 서로 다른 단계입니다. 문제를 확인할 때는 먼저 진입 경로, 다음으로 라우팅 규칙 적용 여부, 마지막으로 출구 연결을 확인하세요. 세 단계를 혼동하면 브라우저는 정상인데 다른 앱은 계속 실패하는 상황을 잘못 판단하기 쉽습니다.

아래는 사설 주소와 중국 본토 도메인 분류의 매칭 방식을 보여주는 라우팅 규칙 예시입니다. 클라이언트 전체 설정 파일을 그대로 대체하는 용도가 아닙니다. 사용 전에 선택한 코어가 해당 필드를 지원하는지, 규칙 리소스가 있는지, 아웃바운드 태그가 실제 설정에 정의되어 있는지 확인하세요. 클라이언트마다 태그 이름이 다를 수 있으므로 예시의 이름만으로는 작동하지 않습니다. 가능하면 클라이언트의 라우팅 편집 화면에서 관리하고, 직접 편집하기 전에는 백업하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

규칙 순서, 리소스 파일, 기본 출구

일반적인 라우팅 구현은 규칙을 순서대로 확인하므로 앞에서 일치한 규칙이 뒤의 규칙 적용에 영향을 줍니다. 특정 도메인 예외는 더 포괄적인 분류보다 앞에 두고, 클라이언트 프리셋이 다른 규칙을 추가로 생성하는지도 확인하세요. 위 예시에는 어떤 규칙에도 일치하지 않는 트래픽의 경로가 지정되어 있지 않으므로 기본 출구는 전체 설정을 살펴 판단해야 합니다. 직접 연결 규칙이 두 개 있다고 해서 나머지 트래픽이 반드시 프록시를 이용하는 것은 아닙니다. 인터페이스의 ‘전역’ 설정도 기기의 모든 앱 설정을 무시한다는 뜻은 아닙니다.

geosite:cn은 도메인 분류 데이터에 의존하고, geoip:private는 해당 주소 분류 기능을 사용합니다. 도메인 규칙은 매칭 가능한 도메인 정보를 사용하고 IP 규칙은 목적지 주소를 기준으로 판단하므로 서로 기계적으로 대체할 수 없습니다. 규칙 데이터베이스가 없거나 태그가 정의되지 않으면 코어가 시작되지 않을 수 있습니다. 데이터베이스 내용이 바뀌면 분할 라우팅 결과도 달라질 수 있습니다. 클라이언트를 업데이트한 뒤에는 리소스 로드 로그도 확인하세요. 자세한 내용은 GeoIP·GeoSite 규칙 데이터베이스 업데이트 방법을 참조하세요.

DNS와 코어 전환 시 확인할 사항

DNS 분할과 연결 분할은 함께 고려해야 하지만 같은 설정은 아닙니다. 도메인이 직접 연결 경로를 사용해도 DNS 조회가 로컬 리졸버를 사용한다는 뜻은 아닙니다. 원격 DNS 주소 자체도 접속 가능한 경로가 있어야 합니다. FakeDNS를 도입할 때는 가상 주소 매핑과 트래픽 적용 범위도 고려해야 하므로 다른 설정에서 옵션 하나만 복사해서는 안 됩니다. 먼저 일반 DNS 조회 방식으로 연결을 확인한 뒤 분할 설정을 단계적으로 적용하세요. 자세한 설정은 V2Ray DNS 분할 설정 안내를 읽고 현재 코어에서 사용하는 필드와 대조하세요.

Xray와 V2Fly를 전환할 때는 프로토콜, 전송 방식, 보안 매개변수, 클라이언트가 생성하는 설정을 다시 확인해야 합니다. 클라이언트에 선택 항목이 있다고 해서 모든 조합이 호환되는 것은 아닙니다. 전환 전에 기존 설정과 로그를 보존하고, 전환 후에는 코어가 정상적으로 시작되는지 먼저 확인한 다음 이전에 접속할 수 있던 대상에 연결해 보세요. 코어를 바꾸는 동시에 DNS, 라우팅, 서버까지 변경하지 마세요. 결과가 달라져도 어떤 변경이 원인이었는지 알 수 없습니다.

07 / DIAGNOSTICS

설정 관련 자주 묻는 질문: 시작부터 연결까지 단계별 점검

현상을 기록한 뒤 확인할 단계 선택

문제를 설명할 때는 플랫폼, 클라이언트, 트래픽 처리 모드, 발생한 동작, 오류 유형을 포함하세요. ‘연결이 안 됨’을 앱 실행 실패, 코어 시작 실패, 구독 업데이트 실패, 브라우저 접속 실패, 특정 앱만 실패하는 경우로 나누면 적절한 점검 방법을 선택할 수 있습니다. 현재 설정을 먼저 보관하고 데이터를 바로 지우지 마세요. 문제가 발생한 시각을 기준으로 로그를 확인하세요. 시작할 때의 오래된 오류는 나중에 발생한 접속 실패와 관련이 없을 수 있으므로 눈에 띄는 오류 문구 하나만 검색해 결론 내리지 마세요.

점검 순서는 로컬 네트워크, 클라이언트 프로세스, 코어 시작, 로컬 리스닝, 서버 연결, DNS 조회, 앱 트래픽 처리 순으로 유지하는 것이 좋습니다. 각 단계에서 한 가지 문제만 확인하고 결과를 기록하세요. 전후 상태를 비교할 때 정상적으로 접속되는 것으로 알려진 일반 웹페이지를 이용할 수 있지만, 웹사이트 하나가 열리는지 여부만으로 전체 연결 상태를 판단하지 마세요. 사이트 자체의 장애, 계정 제한, 앱 캐시도 결과를 바꿀 수 있습니다. 문제 해결의 목적은 원인을 좁히는 것이지, 일시적으로 성공할 때까지 설정을 계속 바꾸는 것이 아닙니다.