설치 가이드 · 플랫폼별 안내
전체 플랫폼 설치 및 설정 가이드
이 페이지에서는 Windows, macOS, Linux, Android를 장별로 나누어 설치 파일 선택부터 연결 문제 해결까지 안내합니다. 데스크톱에서는 v2rayN을, Android에서는 먼저 v2rayNG를 살펴보세요. V2Fly 코어가 필요한 경우 v2flyNG를 선택하면 됩니다. 메뉴 이름은 버전에 따라 달라질 수 있으므로 설정의 기능과 현재 설치 파일에 포함된 안내를 기준으로 확인하세요.
처음 설정하거나 기본 연결 방법만 빠르게 확인하려면 빠른 시작 가이드를 먼저 읽어 보세요. 아키텍처, 권한, 라우팅 또는 구독 업데이트에 문제가 생기면 이 페이지의 해당 항목을 참고하면 됩니다. 설치 파일은 운영체제에 맞춰 클라이언트 다운로드 페이지에서 받으세요. 이 문서에서는 서버 매개변수나 구독 주소를 클라이언트에 기본 포함된 항목으로 다루지 않습니다.
준비 사항 및 설정 범위
클라이언트, 코어, 연결 정보를 구분하세요
GUI 클라이언트는 서버 정보를 저장하고 구독을 관리하며 설정을 생성하고 실행 상태를 제어합니다. 코어는 설정에 따라 연결을 처리합니다. v2rayN은 데스크톱 관리 도구이며, 지원되는 프로토콜은 실제로 사용하는 코어에 따라 달라집니다. v2rayNG는 Xray 코어를 사용하고 v2flyNG는 V2Fly 코어를 사용합니다. 화면에 같은 설정 항목이 보이더라도 두 코어가 모든 확장 매개변수를 동일하게 지원한다는 뜻은 아닙니다. 선택하기 전에 연결 정보가 요구하는 코어를 확인하세요.
클라이언트를 설치해도 사용할 수 있는 서버가 자동으로 생기지는 않습니다. 신뢰할 수 있는 출처에서 받은 구독 주소나 서버 주소, 포트, 사용자 식별자, 전송 방식, 보안 매개변수가 포함된 설정 파일을 준비하세요. 구독 주소에는 접근 권한이 포함될 수 있으므로 비밀번호처럼 안전하게 보관해야 합니다. 다른 사람에게 도움을 요청할 때는 전체 구독 링크, QR 코드, 사용자 식별자를 공개하지 마세요. 화면에 쿼리 매개변수 일부만 보여도 설정을 읽어낼 수 있습니다.
수동으로 설정할 때는 혼동하기 쉬운 도메인 세 가지를 구분해야 합니다. 서버 연결 주소는 연결 대상이고, TLS 서버 이름은 인증서 및 핸드셰이크에 사용되며, HTTP 또는 WebSocket의 Host는 해당 전송 계층에서 사용됩니다. 세 값이 같을 수도 있고 서버에서 각각 지정할 수도 있습니다. 주소가 흔한 웹사이트처럼 보이지 않는다고 해서 여러 항목을 같은 도메인으로 임의 변경하지 마세요.
시스템 아키텍처와 저장 위치 확인
설치 파일은 운영체제, CPU 아키텍처, 배포 형식이 모두 맞아야 합니다. x64는 일반적인 Intel 및 AMD 데스크톱 프로세서에 해당하고, arm64는 다른 명령어 집합을 사용하므로 기기의 출시 시기만 보고 판단하면 안 됩니다. Windows에서는 시스템의 ‘정보’에서 시스템 종류를 확인하고, macOS에서는 ‘이 Mac에 관하여’에서 칩 정보를 확인하세요. Linux에서는 시스템 아키텍처를 조회할 수 있습니다. Android 기기의 프로세서 아키텍처가 불확실하다면 기기 사양을 먼저 확인한 뒤 범용 패키지를 고려하세요.
클라이언트는 장기간 사용할 수 있고 쓰기 권한이 있는 위치에 저장하세요. 압축을 풀어야 하는 패키지는 완전히 압축 해제한 후 해당 폴더에서 실행하고, 압축 프로그램의 임시 보기에서 바로 실행하지 마세요. 설정과 로그는 프로그램 폴더나 사용자 데이터 폴더에 저장될 수 있으며 배포 방식에 따라 다릅니다. 업그레이드 전에 필요한 설정을 클라이언트에서 내보내고 기존 데이터 위치를 기록해 두세요. 프로그램 파일만 복사해 구독 및 라우팅 설정을 놓치는 일을 방지할 수 있습니다.
| 플랫폼 | 우선 확인 사항 | 최초 설정 시 주의 사항 |
|---|---|---|
| Windows | x64, 데스크톱 버전 또는 WPF 버전 | 설치하거나 압축을 푼 뒤 실행 환경 확인 |
| macOS | Apple Silicon 또는 Intel | 응용 프로그램 폴더에 복사한 뒤 첫 실행 안내 처리 |
| Linux | 아키텍처, deb 또는 rpm | 종속성, 데스크톱 환경, 권한 상승 방법 확인 |
| Android | arm64 또는 범용 패키지 | 이번 설치를 허용하고 VPN 권한 확인 |
재현 가능한 테스트 기준 마련
처음 설정하기 전에 다른 프록시, VPN, 네트워크를 제어하는 도구를 종료하고 현재 시스템 프록시 설정을 캡처해 두세요. 평소 네트워크로 접속 가능한 사이트를 열 수 있는지 확인하고 시스템 날짜, 시간, 시간대가 정확한지 점검한 다음 가져오기를 시작하세요. 문제가 발생했을 때 기존 네트워크 문제와 새 설정으로 인한 변화를 구분할 수 있어 여러 네트워크 구성 요소가 동시에 실행되는 상황에서 원인을 추측하지 않아도 됩니다.
첫 테스트에서는 서버 하나와 네트워크 연결 방식 하나만 사용하세요. 데스크톱에서는 보통 시스템 프록시부터 테스트하고, Android에서는 VPN 권한을 먼저 부여합니다. 사용자 지정 DNS, 복잡한 라우팅, LAN 공유는 한꺼번에 추가하지 마세요. 연결이 확인된 뒤 기능을 하나씩 추가하고, 수정할 때마다 같은 앱과 주소로 다시 테스트하세요. 변경 항목, 오류 원문, 발생 시간을 기록하면 ‘켜도 연결되지 않음’만 기록하는 것보다 원인을 찾기 쉽습니다.
Windows 설치 및 시스템 프록시
데스크톱 버전 또는 클래식 WPF 버전 선택
Windows 다운로드 페이지에서 v2rayN을 선택하세요. 데스크톱 버전은 크로스 플랫폼 인터페이스를 사용하고, 클래식 WPF 버전은 Windows 데스크톱 환경에 익숙한 사용 방식을 유지합니다. 두 버전 모두 현재 패키지 안내에서 실행 조건을 확인해야 합니다. 인터페이스 차이가 서버를 새로 구매해야 하거나 프로토콜이 반드시 달라진다는 뜻은 아닙니다. 연결 호환성을 결정하는 것은 실제 사용 코어와 서버 매개변수입니다.
패키지 형식에 맞게 설치하거나 압축을 푸세요. 압축 패키지는 고정된 폴더에 풀고, 경로는 가능한 한 짧고 현재 사용자에게 쓰기 권한이 있는 곳으로 지정하세요. 프로그램, 코어, 포함된 파일은 함께 보관해야 합니다. 처음 실행할 때 실행 환경이 없다는 안내가 나오면 필요한 구성 요소와 아키텍처를 확인한 뒤 운영체제의 일반적인 소프트웨어 설치 절차에 따라 설치하세요. 출처를 알 수 없는 사이트에서 이름이 같은 동적 링크 라이브러리를 하나씩 내려받아 프로그램 폴더에 넣지 마세요.
실행되지 않을 때는 ‘창이 열리지 않는 문제’와 ‘창은 열리지만 코어가 시작되지 않는 문제’를 구분하세요. 전자는 실행 환경, 압축 해제 완료 여부, 시스템 보안 기록을 확인합니다. 후자는 클라이언트 로그에서 코어 누락, 설정 생성 실패, 포트 충돌을 확인하세요. 보안 소프트웨어가 파일을 격리했다면 다운로드 출처와 구체적인 탐지 정보를 먼저 확인하고, 편의를 위해 보안 기능 전체를 끄지 마세요.
구독을 가져오고 로컬 수신 대기 확인
구독 그룹 설정을 열고 새 그룹을 만든 뒤 알아보기 쉬운 이름과 전체 구독 주소를 입력하세요. 저장은 주소를 등록하는 단계일 뿐이므로 구독 업데이트도 실행해야 합니다. 업데이트가 성공하면 서버 목록으로 돌아가 항목 하나를 선택해 활성 서버로 지정하세요. 목록이 비어 있다면 업데이트 로그, 그룹 필터, 주소가 복사 중 잘리지 않았는지 먼저 확인하세요. 서버 항목이 없는데 연결 버튼만 반복해서 누르지 마세요.
이어서 설정에서 로컬 수신 대기 포트와 유형을 확인하세요. HTTP, SOCKS, 혼합 수신 대기는 코어 설정에 따라 달라질 수 있으므로 앱에 프록시를 직접 입력할 때는 해당 프로토콜에 맞춰야 합니다. 포트 번호는 실제 화면에 표시된 값을 사용하고 다른 사람의 스크린샷을 그대로 따라 하지 마세요. 이 기기에서만 사용할 경우 수신 대기 범위는 루프백 주소로 유지하세요. 최초 연결에 LAN 공유는 필요하지 않습니다.
하단 상태 표시줄이나 트레이 메뉴에서 시스템 프록시를 찾아 ‘시스템 프록시 자동 설정’을 선택하세요. Windows 시스템 프록시를 따르는 앱은 로컬 프록시로 연결되지만 모든 프로그램이 강제로 프록시를 사용하는 것은 아닙니다. 먼저 브라우저로 접속 가능한 것으로 확인된 주소를 열고 클라이언트 로그에 해당 연결이 표시되는지 확인하세요. 브라우저는 연결되는데 특정 앱만 실패한다면 해당 앱이 시스템 프록시를 따르는지 확인해야 합니다.
TUN, 권한 및 종료 후 복구
시스템 프록시를 읽지 않는 앱까지 연결해야 할 때만 TUN 사용을 고려하세요. TUN은 가상 네트워크 인터페이스와 라우팅을 다루므로 패키지와 실행 방식에 따라 관리자 권한이 필요할 수 있습니다. 다른 VPN을 먼저 종료하고 일반 프록시 연결이 확인된 후 클라이언트 안내에 따라 권한을 부여하세요. 활성화 후 모든 네트워크가 이상해지면 TUN을 끄고 네트워크가 복구되는지 확인한 다음 DNS와 라우팅을 점검하세요.
Windows에서는 포트 충돌로 시작에 실패하는 경우가 흔합니다. 중복 실행된 클라이언트를 종료하고 로그에 표시된 포트를 확인하세요. 아래 명령으로 조회할 수 있으며, 포트에는 설정 화면에 표시된 값을 넣어야 합니다. 조회 결과는 포트를 사용 중인 항목을 확인하는 용도입니다. PID를 작업 관리자에서 확인하고 정체를 알 수 없는 시스템 프로세스를 바로 종료하지 마세요.
netstat -ano | findstr LISTENING
창을 닫아도 프로그램이 종료되지 않고 트레이에서 계속 실행될 수 있습니다. 완전히 종료하기 전에 ‘시스템 프록시 해제’를 선택하고 TUN을 끈 다음 클라이언트를 종료하세요. 프로그램이 비정상적으로 종료되면 Windows 설정에는 중지된 로컬 프록시가 남아 브라우저가 전부 열리지 않을 수 있습니다. 시스템 프록시를 복구한 뒤 정상적으로 접속된다면 구독 만료가 아니라 남은 설정이 원인일 가능성이 큽니다.
시작 시 자동 실행을 사용하려면 먼저 여러 차례 직접 실행, 연결, 종료를 테스트한 뒤 관련 옵션을 켜세요. 로그인 직후에는 네트워크가 아직 준비되지 않았을 수 있으므로 구독 업데이트 실패만으로 주소가 만료되었다고 판단하면 안 됩니다. 잠시 후 다시 수동으로 업데이트하고 로그를 확인하세요. 업그레이드하거나 데스크톱 버전과 WPF 버전을 바꾸기 전에는 기존 인스턴스를 종료해 포트와 시스템 프록시를 두 프로그램이 동시에 사용하지 않도록 하세요.
macOS 설치 및 네트워크 권한
칩에 맞는 패키지를 선택하고 첫 실행 완료
‘이 Mac에 관하여’에서 칩 정보를 확인하세요. Apple 칩이라면 Apple Silicon용 arm64 패키지를, Intel 프로세서라면 x64 패키지를 선택한 다음 macOS 다운로드 페이지에서 v2rayN을 받으세요. 기기 아키텍처에 맞는 패키지를 우선 사용하고 호환 변환 환경을 일상 설정의 전제로 삼지 마세요.
디스크 이미지를 연 뒤 응용 프로그램을 ‘응용 프로그램’ 폴더로 복사하고 그 위치에서 실행하세요. 이미지 안의 복사본을 계속 실행하면 이미지를 꺼내거나 파일을 옮기고 업그레이드할 때 실제 실행 위치를 혼동할 수 있습니다. 처음 실행을 시스템이 차단하면 파일 출처를 확인한 다음 시스템 설정의 ‘개인정보 보호 및 보안’에서 해당 안내를 찾아 시스템에서 제공하는 확인 절차를 따르세요.
안내를 한 번 피하려고 시스템의 보안 기능 전체를 끄지 마세요. 아키텍처, 파일 손상, 권한 문제는 각각 따로 해결해야 합니다. 아키텍처가 맞지 않으면 올바른 패키지를 받고, 복사가 완료되지 않았다면 다시 복사하세요. 권한 문제는 현재 사용자가 앱과 데이터 폴더에 접근할 수 있는지 확인해야 합니다. 조직에서 관리하는 기기라면 네트워크 설정이 관리 정책으로 제한될 수 있으므로 클라이언트를 반복해서 재설치해도 해결되지 않을 수 있습니다.
구독 가져오기 및 현재 네트워크 서비스
v2rayN을 실행한 뒤 구독 그룹 설정에서 주소를 추가하고 저장한 다음 업데이트를 실행하세요. 활성 서버를 선택하기 전에 보안 방식, 전송 유형, 구독에서 필요한 필드가 제대로 인식되었는지 확인하세요. 특정 클라이언트 전용 확장 항목은 다른 클라이언트에서 바로 사용할 수 없을 수 있습니다. 가져온 항목이 목록에 있는데 시작 시 매개변수 오류가 발생한다면 선택 항목을 모두 켜기보다 로그에 표시된 필드 이름부터 확인하세요.
처음 연결할 때는 시스템 프록시를 사용하세요. macOS 프록시 설정은 네트워크 서비스별로 관리되므로 Wi-Fi, 유선 네트워크 및 다른 인터페이스에 각각 설정이 있을 수 있습니다. 자동 설정 후 현재 사용 중인 네트워크 서비스의 세부 정보에서 프록시 상태를 확인하세요. 유선 연결에서 무선 연결로 바꾼 뒤 동작이 달라졌다면 서버나 구독 문제로 단정하기 전에 새 네트워크 서비스의 프록시 설정을 확인하세요.
브라우저에는 별도의 확장 프로그램이나 전용 프록시 설정이 있을 수 있고 터미널 도구는 시스템 프록시를 따르지 않을 수 있습니다. 따라서 검증할 때는 시스템 설정을 따르는 앱을 먼저 선택하고 대상 연결이 로그에 표시되는지 확인하세요. 터미널 요청이 한 번 실패했다고 시스템 프록시도 실패한 것은 아닙니다. 도구에서 수동 프록시를 지원한다면 해당 입력 형식에 맞춰 로컬 주소와 수신 대기 포트를 지정하세요.
TUN 권한 상승, 절전 모드 및 업그레이드
TUN은 가상 인터페이스와 시스템 라우팅을 다루므로 필요한 권한은 클라이언트 패키지에 따라 다릅니다. 기본 프록시가 작동하는지 확인한 다음 화면 안내에 따라 활성화하세요. 관리자 권한 요청이 나타나면 방금 실행한 클라이언트에서 보낸 요청인지 확인하세요. 출처가 불분명한 터미널 스크립트를 일반적인 해결책으로 사용하거나 일상 프로그램을 항상 높은 권한으로 실행하지 마세요.
절전 모드에서 깨어난 뒤, 핫스팟을 바꾼 뒤 또는 네트워크를 전환한 뒤에는 이전 연결이 대기 상태로 남을 수 있습니다. 먼저 새 네트워크가 정상인지 확인한 뒤 현재 연결을 다시 시작하세요. 필요하다면 TUN을 껐다가 다시 켜 인터페이스와 라우팅을 재설정하세요. 특정 네트워크에서만 실패한다면 다른 설정은 그대로 둔 채 두 네트워크의 로그를 비교하고, 전체 설정을 바로 다시 만들기보다 도메인 확인과 핸드셰이크 단계를 살펴보세요.
업그레이드 전에 보관할 설정을 내보내고 현재 사용자 데이터 위치를 기록하세요. 앱을 교체해도 사용자 설정이 항상 지워지는 것은 아니므로 업그레이드 후 이전 설정이 남아 있을 수 있습니다. 반대로 앱을 휴지통으로 옮겨도 네트워크 제어 설정이 반드시 정리되는 것은 아닙니다. 앱을 제거하거나 바꾸기 전 TUN을 끄고 시스템 프록시를 복구한 뒤 앱을 종료하세요. 마지막으로 현재 네트워크 서비스의 프록시 설정을 확인하세요.
클라이언트에는 연결 정상으로 표시되는데 관리 대상 브라우저에서 접속할 수 없다면 브라우저 정책, 확장 프로그램, 시스템 프로파일에 다른 프록시가 지정되어 있는지 확인하세요. 이러한 설정은 일반 사용자 설정보다 우선 적용될 수 있습니다. 정책의 출처를 기록하고 기기 관리자에게 문의하세요. 업무 네트워크나 다른 관리 대상 앱에 영향을 줄 수 있으므로 정체를 알 수 없는 프로파일을 삭제하며 시험하지 마세요.
Linux 설치 및 데스크톱 환경
패키지 형식, 아키텍처, 종속성 확인
Linux에서는 먼저 배포판의 패키지 시스템을 확인하고 다음으로 시스템 아키텍처를 살펴보세요. Debian, Ubuntu 등은 보통 deb를 사용하고 Fedora 등 rpm 기반 시스템은 해당 형식을 사용합니다. 다른 배포판에 서로 다른 형식의 패키지를 기본 패키지처럼 억지로 설치하지 마세요. Linux 다운로드 페이지에서 v2rayN을 선택하고 x64 또는 arm64가 실제 시스템 아키텍처와 맞는지 확인하세요.
다음 두 명령은 시스템 정보만 조회합니다. 첫 번째는 아키텍처, 두 번째는 배포판 식별 정보를 확인합니다. 일반적으로 x86_64는 x64에 해당하고 aarch64는 arm64에 해당합니다. 배포판 이름만으로 종속성이 충족되는 것은 아니므로 시스템 버전, 데스크톱 구성 요소, 패키지 관리자가 표시하는 종속성 정보도 함께 확인하세요. 파일 확장자가 같다는 이유만으로 설치할 수 있다고 판단하지 마세요.
uname -m
cat /etc/os-release
설치할 때는 배포판에서 제공하는 소프트웨어 설치 도구나 패키지 관리자를 우선 사용하세요. 종속성과 제거 기록을 시스템에서 관리할 수 있습니다. 종속성 누락 안내가 나오면 전체 오류를 보관하고 소프트웨어 저장소와 시스템 지원 범위를 확인하세요. 다른 배포판의 공유 라이브러리를 임의로 복사하지 마세요. GUI 클라이언트에는 사용 가능한 데스크톱 세션이 필요합니다. 터미널만 있는 서버 환경은 여기서 설명하는 GUI 설치 대상이 아닙니다.
일반 사용자 세션에서 가져오기 및 테스트
설치 후 앱 메뉴에서 실행하고 일반 데스크톱 사용자로 설정을 저장하세요. 관리자 계정으로 GUI를 바로 실행하면 다른 사용자 데이터 폴더에 설정이 저장되어 일반 계정으로 실행했을 때 자료가 사라진 것처럼 보일 수 있습니다. 이런 경우 같은 구독을 반복해서 가져오기보다 실행 사용자와 데이터 경로를 확인하세요. 권한 상승이 필요한 네트워크 작업은 클라이언트가 지원하는 방식으로 처리하고 일상 설정과 분리하세요.
구독은 새 그룹을 만들고 주소를 입력한 뒤 저장, 업데이트, 활성 서버 선택 순으로 가져옵니다. 업데이트 성공 후에는 데스크톱 프록시를 설정하기 전에 코어가 정상적으로 시작되는지 확인하세요. Linux는 데스크톱 환경마다 프록시 설정 위치가 다릅니다. 어떤 앱은 데스크톱 설정을 읽고, 어떤 앱은 환경 변수를 사용하며, 앱 자체 매개변수만 받는 경우도 있습니다. 따라서 ‘시스템 프록시가 켜짐’만으로 모든 프로그램이 프록시를 사용한다고 볼 수 없습니다.
데스크톱 프록시를 따르는 것으로 확인된 앱 하나로 먼저 테스트한 뒤 다른 도구를 따로 설정하세요. 수신 대기가 확인되지 않은 상태에서 모든 셸 시작 파일에 프록시 환경 변수를 넣지 마세요. 새 터미널도 실행되지 않는 포트를 계속 사용하게 될 수 있습니다. HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 설정한 적이 있다면 문제를 확인할 때 대문자와 소문자 형식, 앱 자체 설정도 함께 살펴보세요.
TUN, DNS 및 여러 네트워크 관리 도구
TUN을 켜기 전에 시스템이 필요한 가상 네트워크 인터페이스 기능을 제공하는지 확인하고 클라이언트 로그의 권한 안내를 살펴보세요. 일부 환경에서는 권한 상승 서비스나 네트워크 관리 도구와의 연동이 필요할 수 있습니다. 권한 오류를 해결하려고 설정 폴더 전체를 모든 사용자가 쓸 수 있게 변경하지 마세요. 오류가 프로그램 실행 권한, 데이터 폴더 권한, 인터페이스 및 라우팅 설정에 필요한 시스템 권한 중 무엇을 가리키는지 먼저 확인해야 합니다.
Linux에서는 데스크톱 네트워크 관리자, 시스템 DNS 확인 서비스, 컨테이너 네트워크, 다른 VPN이 동시에 작동할 수 있습니다. TUN을 켠 뒤 도메인 접속에 실패하고 일반 네트워크로 돌아가면 정상인 경우 실제 DNS가 어떤 경로로 처리되는지 확인하세요. 시스템이 자동 생성할 수 있는 DNS 설정 파일을 처음부터 덮어쓰지 마세요. 변경해도 곧 다시 기록되어 문제를 재현하기 어려워질 수 있습니다.
아래 명령으로 로컬 수신 대기 상태를 확인해 클라이언트 포트가 열렸는지 점검할 수 있습니다. 수신 대기가 확인되어도 로컬 연결 지점이 만들어졌다는 뜻일 뿐 원격 핸드셰이크가 성공했다는 의미는 아닙니다. 프로세스 이름을 볼 권한이 없더라도 주소와 포트는 확인할 수 있습니다. 자세한 조회가 필요하면 시스템 관리 규정에 맞춰 권한을 높이세요. 이 확인만을 위해 클라이언트 전체를 관리자 권한으로 실행할 필요는 없습니다.
ss -lntp
종료하기 전에 데스크톱 프록시를 복구하고 TUN을 끄세요. 종료 후에도 문제가 남으면 다른 클라이언트 인스턴스, 지속적으로 설정된 환경 변수, 다른 네트워크 서비스가 남긴 규칙이 있는지 확인한 뒤 관련 서비스를 다시 시작할지 결정하세요. 업그레이드 후에는 트레이, 백그라운드 실행, 자동 시작 동작도 다시 테스트해야 합니다. 데스크톱 세션에 따라 백그라운드 프로그램 처리 방식이 다를 수 있으므로 창이 닫혔는지만 보고 실행 여부를 판단하지 마세요.
Android 설치 및 VPN 권한
v2rayNG 또는 v2flyNG 선택
Android 다운로드 페이지에서 먼저 Xray 코어를 사용하는 v2rayNG를 고려하세요. 연결 정보에서 V2Fly 코어를 명시적으로 요구하는 경우 v2flyNG를 선택하면 됩니다. 이름이 비슷하다고 해서 두 클라이언트가 확장 매개변수를 모두 동일하게 지원하는 것은 아닙니다. 특히 REALITY 설정은 코어 지원 여부와 서버 요구 사항을 확인하세요. 지원되지 않는 필드를 토글을 반복해서 바꿔 해결하려 하지 마세요.
대부분의 최신 기기는 arm64를 선택할 수 있지만, 실제로는 기기 프로세서와 시스템이 지원하는 앱 아키텍처를 기준으로 판단해야 합니다. 설치 프로그램에서 아키텍처가 호환되지 않는다고 안내하면 범용 패키지를 사용해야 하는지 확인하세요. 다운로드 후 시스템 파일 앱에서 설치 파일을 여세요. 현재 출처의 앱 설치를 허용하라는 안내가 나오면 이번에 사용할 브라우저나 파일 관리자에만 권한을 부여하고, 설치 후 해당 출처의 권한을 해제할 수 있습니다.
업데이트 설치 중 서명이 일치하지 않는다는 안내가 나오더라도 기존 앱을 바로 삭제하지 마세요. 필요한 설정을 내보내고 기존 앱과 새 패키지의 출처, 앱 식별 정보, 서명이 같은 배포 채널에 속하는지 확인하세요. 앱을 제거하면 앱 데이터가 삭제되어 구독 그룹과 수동 설정도 함께 사라질 수 있습니다. 클라이언트 간에는 덮어쓰기로 이전할 수 없으므로 각 앱이 실제로 지원하는 가져오기 및 내보내기 기능을 사용하세요.
구독 가져오기 및 시스템 VPN 연결
구독 그룹 설정에서 이름과 주소를 추가하고 저장한 다음 메인 화면으로 돌아와 구독 업데이트를 실행하세요. 일부 화면에는 현재 프록시를 거쳐 업데이트하는 옵션과 직접 업데이트하는 옵션이 있습니다. 아직 연결하지 않은 첫 설정에서 구독 주소에 직접 접속할 수 있다면 직접 업데이트를 선택할 수 있습니다. 기존 연결이 있어야 구독 주소에 접근할 수 있다면 먼저 사용할 수 있는 설정을 준비해야 합니다. 빈 그룹만으로 연결을 만들 수는 없습니다.
목록에 항목이 표시되면 활성 서버를 선택하고 연결을 시작하세요. Android에서 처음 연결할 때 VPN 연결 요청이 표시됩니다. 확인하면 클라이언트가 시스템의 VPN 인터페이스를 통해 선택한 앱의 트래픽을 처리할 수 있습니다. VPN 표시가 나타나는 것은 인터페이스가 만들어졌다는 뜻이지 원격 서버에 연결되었다는 뜻은 아닙니다. 로그와 실제 앱 접속 결과를 함께 확인하세요. 권한 요청을 승인하지 않은 상태에서 서버를 반복해서 눌러도 트래픽을 처리할 수 없습니다.
Android 클라이언트의 트래픽 처리 방식은 데스크톱의 ‘시스템 프록시 자동 설정’과 다릅니다. 설정에 앱별 프록시가 있다면 VPN을 사용할 앱이나 우회할 앱을 선택할 수 있습니다. 모드에 따라 목록에서 앱을 선택하는 의미가 반대일 수 있으므로 활성화 전에 현재 안내를 읽으세요. 처음 테스트할 때는 기본 범위를 유지하고 연결이 확인된 뒤 앱을 하나씩 제외하세요. 테스트용 브라우저가 실수로 제외되지 않도록 주의해야 합니다.
백그라운드 제한, 네트워크 전환 및 공유
연결이 한동안 유지되다가 저절로 끊기면 시스템의 배터리 최적화, 백그라운드 활동 제한, 절전 모드를 먼저 확인하세요. 제조사마다 설정 위치가 다르므로 앱 정보 화면에서 배터리와 백그라운드 권한을 살펴보세요. 해당 클라이언트와 관련된 항목만 조정하고 화면을 잠그기 전후로 로그가 중단되는지 확인하세요. 모든 연결 끊김을 백그라운드 제한 탓으로 돌리면 안 됩니다. 프로세스가 계속 실행되는데 핸드셰이크가 실패한다면 원격 매개변수도 점검해야 합니다.
Wi-Fi와 모바일 네트워크를 전환할 때 로컬 인터페이스는 남아 있어도 기존 연결은 끊겼을 수 있습니다. 새 네트워크가 완전히 연결될 때까지 기다린 뒤 현재 서버에 다시 연결하세요. 모바일 네트워크에서만 실패한다면 서버와 라우팅은 그대로 두고 주소 확인, IPv4 및 IPv6 연결 여부, 핸드셰이크 오류를 비교하세요. 전송 방식과 보안 매개변수를 동시에 바꾸면 어떤 변경이 결과에 영향을 주었는지 알 수 없습니다.
‘LAN 연결 허용’은 다른 기기에 로컬 프록시 수신 대기를 개방하는 기능이며 휴대폰 자체의 인터넷 연결에 필요한 설정은 아닙니다. 켜기 전에 수신 대기 주소, 포트, 현재 네트워크의 신뢰도를 확인하세요. 휴대폰 핫스팟에 연결한 다른 기기의 트래픽이 VPN을 통과하는지는 시스템 구현에 따라 달라집니다. 휴대폰에서 연결된다고 핫스팟에 연결된 기기도 자동으로 VPN을 사용한다고 단정하지 마세요.
일상적으로 연결을 중지할 때는 클라이언트에서 먼저 연결을 끊고 시스템 VPN 상태가 종료되었는지 확인하세요. 항상 켜짐 VPN이나 VPN을 거치지 않는 연결 차단을 설정했다면 클라이언트를 종료한 뒤 시스템 정책에 따라 네트워크가 차단될 수 있습니다. 이는 시스템 설정이므로 VPN 상세 설정에서 확인하세요. 구독 관련 간단한 절차는 Android 구독 가져오기 가이드에서 확인할 수 있습니다.
구독 정리 및 매개변수 확인
구독 업데이트와 서버 연결은 별도로 확인
구독 주소는 설정을 배포하는 경로이며 클라이언트가 여기에 접속한 뒤 서버 정보를 받습니다. 업데이트 성공은 이번에 정보를 가져와 해석했다는 뜻이지 모든 서버를 지금 사용할 수 있다는 뜻은 아닙니다. 연결 성공도 구독 주소에 계속 접속할 수 있음을 보장하지 않습니다. 두 과정은 별개입니다. 문제를 확인할 때는 구독 다운로드, 내용 해석, 코어 시작, 원격 연결 중 어느 단계에서 실패했는지 먼저 살펴보세요. 모든 문제를 ‘가져오기 실패’라고 부르지 마세요.
출처별로 그룹을 하나씩 만들고 그룹 이름에는 용도나 출처를 알아볼 수 있는 짧은 이름을 사용하세요. 전체 주소를 그룹 이름에 넣지 마세요. 주소를 붙여넣을 때 앞뒤 공백, 줄 바꿈, 복사 도구가 추가한 문장 부호가 없는지 확인하세요. 쿼리 매개변수가 있는 주소는 전체를 보존해야 합니다. 주소가 만료되거나 접근 권한이 바뀌었거나 출처에서 웹페이지를 반환하면 클라이언트가 구독이 아닌 내용을 받을 수 있습니다. 이때는 서버 목록보다 업데이트 로그가 원인을 더 잘 보여 줍니다.
브라우저에서 페이지를 열 수 있다고 해서 해당 주소가 클라이언트가 인식할 수 있는 설정을 반환한다는 뜻은 아닙니다. 구독은 접속 방식에 따라 다른 내용을 반환할 수 있으며 계정이 유효해야 할 수도 있습니다. 로그인 페이지나 공유 페이지 주소를 구독 링크로 사용하지 마세요. 출처에서 여러 형식을 제공한다면 현재 클라이언트가 지원하는 형식을 선택하세요. 여러 곳에서 받은 구독 텍스트를 한 파일에 이어 붙이지 마세요.
연결 및 보안 매개변수를 하나씩 확인
수동으로 입력할 때는 먼저 프로토콜, 서버 주소, 포트, 사용자 식별자를 확인한 다음 전송 방식과 보안 계층을 살펴보세요. VLESS, VMess, Trojan은 인증 필드가 서로 다르므로 한 형식의 비밀번호를 다른 형식의 사용자 식별자 입력란에 임의로 넣으면 안 됩니다. 전송 방식도 서버 설정과 일치해야 합니다. 서버가 WebSocket을 사용한다면 경로와 Host의 대소문자 및 앞에 붙는 슬래시를 원본대로 유지하세요.
TLS 서버 이름은 인증서와 관련되며 보통 화면에서 SNI 또는 서버 이름으로 표시됩니다. REALITY 설정에는 공개 키, 짧은 ID, 지문 등의 항목이 포함될 수 있으므로 서버 정보를 기준으로 하나씩 입력해야 합니다. 공개 키를 비밀번호로 오해하거나 모든 도메인을 서버 IP로 바꾸지 마세요. 가져온 뒤 필수 항목이 비어 있다면 공유 형식이 호환되는지 먼저 확인하고 필요한 경우 수동으로 입력하세요.
| 매개변수 | 주요 기능 | 흔히 잘못 입력하는 값 |
|---|---|---|
| 서버 주소 | 원격 연결 대상 지정 | 전체 공유 링크를 주소 입력란에 붙여넣음 |
| 포트 | 원격 서비스 연결 지점 선택 | 로컬 수신 대기 포트를 잘못 사용 |
| SNI | TLS 핸드셰이크 및 인증에 사용 | 인증서와 무관한 도메인으로 임의 변경 |
| 전송 경로 | 해당 전송 서비스와 일치시킴 | 슬래시를 빠뜨리거나 불필요한 공백을 남김 |
공유 링크와 구독 내용에는 인코딩된 매개변수가 포함될 수 있습니다. 텍스트를 직접 수정하면 구분자나 이스케이프 문자가 손상되기 쉽습니다. 일반 사용자는 클라이언트가 지원하는 입력 화면에서 수정하고 변경 전 설정을 내보내 보관하는 것이 좋습니다. 프로토콜 원리를 더 알아보려면 VLESS 설정 안내와 REALITY 매개변수 안내를 참고하세요. 실제 값은 서버에서 받은 정보를 기준으로 해야 합니다.
업데이트, 필터링, 백업의 범위
구독 업데이트는 구독에서 관리하는 서버 항목을 덮어쓸 수 있으므로 임시 수동 변경을 영구 저장 방법으로 사용하지 마세요. 사용자 지정 항목을 보관하려면 클라이언트에서 지원하는 방식으로 별도 그룹에 옮기거나 백업을 내보내세요. 업데이트 후 현재 선택 항목이 사라졌다면 서버에서 항목이 삭제되거나 이름이 바뀌었을 수 있습니다. 먼저 활성 서버를 다시 선택하고 실제 연결 문제가 있는지 확인하세요.
필터 규칙은 목록 표시 방식에 영향을 주므로 목록이 비어 있다고 해서 구독에서 내용이 반환되지 않았다고 단정할 수 없습니다. 전체 그룹으로 돌아가 키워드 필터를 잠시 해제한 뒤 업데이트 로그를 확인하세요. 중복 항목도 표시 이름만으로 판단하면 안 됩니다. 이름이 같아도 포트, 전송 방식, 인증 정보가 다를 수 있습니다. 정리 방법은 구독 그룹 및 서버 필터링 메모를 참고하세요. 여러 항목을 일괄 처리하기 전에 복원할 수 있도록 내보낸 파일을 보관하세요.
설정 백업은 보호된 위치에 보관하고 공개 스크린샷이나 문의 내용과 함께 업로드하지 마세요. 내보낸 파일에는 서버 인증 정보와 구독 주소가 함께 들어 있을 수 있습니다. 표시 이름만 바꿔도 민감한 정보가 제거되는 것은 아닙니다. 다른 기기에서 복원한 뒤에는 로컬 포트, 시스템 프록시, 파일 경로, 권한을 다시 확인하세요. 기기별 설정은 기존 백업을 그대로 복사해도 완전히 같지 않을 수 있습니다.
시스템 프록시, TUN 및 라우팅
트래픽 처리 경로를 이해한 뒤 모드 선택
시스템 프록시, TUN, 라우팅 규칙은 서로 다른 계층에서 작동합니다. 시스템 프록시는 설정을 따르는 앱의 요청을 로컬 포트로 전달합니다. TUN은 가상 인터페이스를 통해 해당 네트워크 트래픽을 처리합니다. 라우팅 규칙은 코어에 들어온 연결이 어떤 출구를 사용할지 결정합니다. 라우팅 설정을 아무리 완벽하게 해도 클라이언트에 들어오지 않은 앱의 트래픽까지 자동으로 프록시할 수는 없습니다. 문제 해결에서는 이 차이를 먼저 파악해야 합니다.
데스크톱에서 웹을 이용할 때는 시스템 프록시로 시작하고 웹페이지 접속과 로그가 일치하는지 확인한 다음 추가적인 트래픽 처리 방식을 고려하세요. 일부 앱은 별도 프록시 설정을 제공하므로 로컬 수신 대기 주소를 직접 입력할 수도 있습니다. TUN은 더 넓은 범위의 트래픽을 처리하지만 인터페이스, 라우팅, DNS, 권한 문제가 추가됩니다. 모든 환경에서 첫 단계로 사용해야 하는 것은 아니며 잘못된 서버 매개변수를 고치는 스위치도 아닙니다.
‘전역’은 보통 클라이언트에 들어온 트래픽이 어떤 출구를 사용할지 나타내는 표현이지 기기의 모든 연결을 처리한다는 뜻은 아닙니다. 시스템 프록시를 사용할 때 전역 라우팅을 선택해도 해당 프록시를 읽지 않는 앱은 직접 연결될 수 있습니다. 반대로 TUN이 켜져 있어도 라우팅 규칙에 따라 일부 대상은 직접 연결할 수 있습니다. 트래픽 경로를 판단할 때는 연결 처리 방식, 규칙 일치 여부, 실제 출구 로그를 함께 확인하세요.
라우팅 순서 및 DNS 설정
규칙은 보통 순서대로 일치 여부를 확인하며 구체적인 동작은 사용하는 코어에 따라 다릅니다. 범위가 넓은 규칙보다 정확한 예외 규칙을 앞에 두고 각 규칙의 목적을 기록하세요. 규칙을 추가한 뒤에는 명확한 대상 하나로 테스트하고 서로 덮어쓸 수 있는 규칙을 한꺼번에 여러 세트 가져오지 마세요. 도메인 규칙과 IP 규칙은 같은 방식으로 작동하지 않습니다. 연결이 코어에 들어올 때 도메인 정보를 얻을 수 있는지에 따라 적용될 수 있는 규칙이 달라집니다.
아래는 사설 주소 범위를 direct라는 출구로 보내는 Xray 라우팅 객체의 구조 예시입니다. 전체 설정의 일부로만 사용할 수 있으며 해당 출구 태그가 이미 있어야 합니다. 단독으로 시작할 수 있는 클라이언트 설정은 아닙니다. GUI 클라이언트가 설정을 자동 생성할 수 있으므로 생성된 파일을 직접 수정하면 덮어써질 수 있습니다. 우선 화면의 라우팅 설정을 사용하세요.
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}
DNS 조회가 발생하는 위치도 결과에 영향을 줍니다. 앱이 먼저 도메인을 IP로 변환하는 경로와 도메인을 프록시에 전달해 조회하는 경로는 다릅니다. TUN을 사용하면 DNS 처리도 제어될 수 있으므로 브라우저 설정만 바꾸고 조회 경로가 바뀌었다고 판단하지 마세요. 도메인 접속은 실패하지만 IP 주소에는 연결할 수 있다면 실제 DNS 처리 경로와 로그를 확인하세요. DNS 주소를 전부 바꾸기보다 한 번에 한 요소만 변경해야 결과를 비교하기 쉽습니다.
LAN 공유 및 접근 범위
다른 기기와 공유할 때는 먼저 컴퓨터 자체의 연결이 정상인지 확인한 다음 ‘LAN 연결 허용’ 또는 해당 수신 대기 설정을 켜세요. 다른 기기에는 컴퓨터의 현재 LAN 주소와 로컬 프록시 포트를 입력해야 합니다. 원격 서버 주소나 127.0.0.1을 입력하는 것이 아닙니다. 루프백 주소는 해당 주소를 입력한 기기 자체를 가리키므로 휴대폰에 입력하면 휴대폰에서 실행 중인 서비스만 찾습니다.
같은 Wi-Fi를 사용해도 기기 간 통신이 보장되는 것은 아닙니다. 게스트 네트워크, 무선 기기 격리, 시스템 방화벽이 연결을 차단할 수 있습니다. 두 기기의 네트워크 대역과 네트워크 종류를 확인한 뒤 필요한 프로그램이나 포트만 허용하세요. 수신 대기를 열 때는 신뢰할 수 있는 네트워크로 범위를 제한하고 클라이언트에서 인증을 지원하면 필요에 따라 사용하세요. 테스트 편의를 위해 라우터를 통해 로컬 프록시를 공용 네트워크에 노출하지 마세요.
공유할 때는 접속 기기가 지원하는 프록시 유형도 확인해야 합니다. 기기 설정에서 HTTP 프록시만 지원한다면 SOCKS 전용 포트를 입력해도 사용할 수 없습니다. 일부 기기의 프록시 설정은 특정 앱에만 적용됩니다. 공유를 중지한 뒤 LAN 수신 대기를 끄고 다른 기기의 프록시 주소도 지우세요. 기기에서 설정하는 순서는 v2rayN LAN 공유 메모를 참고하세요. 공유 문제와 컴퓨터 자체의 원격 연결 문제를 함께 처리하지 마세요.
자주 발생하는 설정 문제 및 연결 해결
실패 단계별로 증거 수집
먼저 문제가 발생하는 범위를 설명하세요. 구독 업데이트 실패인지, 코어 시작 실패인지, 모든 앱에서 실패하는지, 특정 앱이나 대상에서만 실패하는지 구분해야 합니다. 다음으로 마지막으로 정상 사용한 뒤 변경한 항목과 현재 트래픽 처리 방식을 기록하세요. 문제를 확인하는 동안 테스트 대상과 앱을 하나로 고정하세요. 네트워크, 서버, DNS를 동시에 바꾸면 처음 오류를 재현할 수 없습니다.
클라이언트 창이 정상적으로 보여도 코어가 정상이라는 뜻은 아닙니다. 로그에서 설정 로드 완료와 로컬 수신 대기 생성 메시지를 확인한 뒤 가장 먼저 나타난 오류를 살펴보세요. 포트 충돌, 미지원 설정 필드, 데이터 파일 누락, 원격 시간 초과는 서로 다른 문제입니다. 시작 오류라면 우선 로컬 실행 조건부터 해결하고 구독을 먼저 바꿀 필요는 없습니다. 로컬 연결 지점이 정상인 것을 확인한 뒤 원격 연결과 앱의 프록시 사용 여부를 점검하세요.
로그는 짧은 시간 범위로 확인하세요. 테스트 시작 시각을 기록한 다음 요청을 한 번 실행하고 바로 이어지는 로그를 살펴보면 됩니다. 관계없는 과거 로그가 많으면 실제 첫 오류를 찾기 어렵습니다. 원인 파악을 위해 로그 상세 수준을 일시적으로 높였다면 확인 후 평소 수준으로 되돌리세요. 로그를 공유하기 전 구독 주소, 사용자 식별자, 인증 매개변수를 삭제하고 오류 유형, 발생 단계, 필요한 환경 정보만 남기세요.
시간 초과, 연결 거부 및 인증서 오류
‘연결 거부’는 해당 주소와 포트에서 연결을 받는 서비스가 없음을 뜻하는 경우가 많지만 중간 네트워크 장비가 거부했을 수도 있습니다. ‘시간 초과’는 대기 중 예상한 응답을 받지 못했다는 뜻이며 원인 범위가 더 넓습니다. 먼저 원격 주소와 포트를 확인한 다음 로컬 로그에서 실제로 접속하려는 대상을 살펴보세요. 특정 네트워크에서만 실패한다면 설정을 그대로 둔 채 다른 네트워크와 비교하고 프로토콜 유형부터 바꾸지 마세요.
TLS 인증서나 핸드셰이크 오류가 발생하면 먼저 시스템 날짜, 시간, 시간대를 맞춘 다음 SNI, 서버 주소, 보안 유형, 전송 매개변수가 서버 설정과 일치하는지 확인하세요. 도메인이 잘못된 대상으로 해석되어 인증서가 일치하지 않을 수도 있습니다. ‘인증서 검증 건너뛰기’는 매개변수 오류를 바로잡지 않으며 인증 기능을 약화하므로 일상적인 해결책이나 기본 설정으로 사용하지 마세요.
코어가 설정 필드를 인식하지 못하면 다른 코어 전용 형식을 가져왔는지, 클라이언트에서 적절하지 않은 코어를 선택했는지 확인하세요. 클라이언트 업데이트와 코어 변경은 서로 다른 작업이며 어느 쪽도 모든 호환성 문제를 해결한다고 보장할 수 없습니다. 오류가 난 필드에서 필요한 기능을 확인한 뒤 클라이언트를 선택하세요. 코어에 관한 배경은 Xray와 V2Fly의 차이를, 구체적인 핸드셰이크 문제는 TLS 및 인증서 문제 해결 메모를 참고하세요.
기본 테스트 상태로 되돌려 하나씩 재검증
브라우저는 되지만 다른 앱에서 연결되지 않는다면 해당 앱이 시스템 프록시를 사용하는지, 별도 설정이 있는지, 앱별 규칙에서 제외되었는지 확인하세요. 일부 대상에서만 실패하면 전체 클라이언트를 재설치하지 말고 라우팅 규칙 일치 여부, 도메인 조회, 대상 서비스 상태를 살펴보세요. 시스템 프록시는 정상인데 TUN에서만 실패한다면 가상 인터페이스, DNS 처리, 라우팅 충돌, 권한을 중점적으로 확인하세요. 서버 인증 정보를 먼저 다시 입력하지 마세요.
이전 상태로 되돌려야 한다면 현재 설정을 먼저 내보낸 다음 사용자 지정 라우팅과 추가 DNS 설정을 끄고 TUN을 비활성화하세요. 활성 서버 하나만 남겨 시스템 프록시를 테스트합니다. Android에서는 앱별 범위를 기본값으로 복구한 뒤 VPN 권한을 다시 부여하세요. 변수를 한 번에 하나씩 되돌리고 결과를 기록하세요. 기본 연결이 정상인지 확인한 다음 원래 순서대로 기능을 하나씩 켜면 어떤 설정부터 문제가 생겼는지 찾을 수 있습니다.
클라이언트를 종료한 뒤에도 일반 네트워크가 이상하다면 시스템 프록시를 복구하고 항상 켜짐 VPN 정책을 확인한 다음 다른 프로그램이 네트워크를 계속 처리하는지 살펴보세요. 네트워크가 복구되면 클라이언트를 다시 시작해 로컬 수신 대기와 원격 핸드셰이크를 확인하세요. 도움을 요청할 때는 운영체제와 아키텍처, 클라이언트 이름, 트래픽 처리 방식, 민감 정보를 제거한 오류 원문, 이미 테스트한 단계를 함께 제공하세요. ‘연결할 수 없음’만 표시된 스크린샷보다 유용하고 이미 확인한 항목을 반복하지 않아도 됩니다.
구독 업데이트는 성공했는데 서버에 연결할 수 없다면 어떻게 하나요?
업데이트 성공은 구독을 가져와 해석했다는 뜻입니다. 먼저 활성 서버를 선택하고 코어와 로컬 수신 대기가 정상인지 확인하세요. 다음으로 실제 요청이 클라이언트에 들어오는지 살펴본 뒤 로그에서 원격 주소, 전송 방식, 보안 매개변수를 확인하세요.
테스트가 끝난 뒤 어떤 설정을 복구해야 하나요?
클라이언트가 설정한 시스템 프록시를 해제하고 TUN 또는 VPN을 중지한 뒤 임시 LAN 수신 대기를 끄세요. 테스트 중 변경한 앱 프록시와 환경 변수도 복구한 다음 일반 네트워크가 정상인지 확인하고 일상적으로 유지할 설정을 결정하세요.