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

공통 준비: 기기, 구독 및 설정 범위

클라이언트, 커널, 서버의 역할 구분하기

클라이언트는 서버 목록 표시, 구독 저장, 시스템 프록시 변경을 담당하고, 커널은 프로토콜 연결, 라우팅 및 로컬 리스닝을 처리합니다. v2rayN은 데스크톱 GUI 클라이언트이며 v2rayNG와 v2flyNG는 Android용입니다. 클라이언트를 설치해도 연결 가능한 서버가 생기는 것은 아닙니다. 유효한 구독 URL이나 완전한 단일 서버 설정이 필요합니다. Project V는 관련 기술 생태계의 기반이며 V2Fly와 Xray는 커널 계열입니다. 이 이름들을 구독 서비스명으로 사용하지 마세요.

설정 전에 서버 정보의 출처를 확인하고 사용 범위를 파악하세요. 구독 URL에는 보통 접속 정보가 포함되므로 계정 정보처럼 안전하게 보관해야 합니다. 공개 게시판, 스크린샷, 온라인 변환 사이트에 올리지 마세요. 도움을 요청할 때는 프로토콜 종류, 전송 방식, 오류 유형만 남기고 서버 주소, 사용자 식별 정보, 구독 URL의 쿼리 매개변수는 가리세요. 클라이언트 로그에 접속 대상 도메인이 기록될 수도 있으니 공유 전에 한 줄씩 확인하세요.

프로세서 아키텍처와 설치 파일 형식 확인하기

같은 운영체제라도 프로세서 아키텍처는 다를 수 있습니다. Windows에서는 “설정 → 시스템 → 시스템 정보”에서 시스템 종류를 확인하세요. macOS에서는 “이 Mac에 관하여”에서 칩 또는 프로세서를 확인하고, Android에서는 시스템 기기 정보에서 확인하세요. 확인하기 어려우면 범용 패키지를 선택하세요. Linux는 아래 명령으로 아키텍처를 확인할 수 있습니다. 기기의 외형이나 구매 연도만으로 판단하거나 배포판 이름과 프로세서 종류를 혼동하지 마세요.

uname -m

최소 시스템 요구 사항과 필요한 런타임은 다운로드 페이지 및 실제 설치 안내를 확인하세요. 데스크톱 클라이언트는 UI와 커널 등 여러 구성 요소로 이루어져 있어 실행 파일만 옮기면 리소스가 누락될 수 있습니다. 설치 위치는 현재 계정에서 쓸 수 있는 디렉터리를 우선 선택하세요. 포터블 환경으로 옮기려면 클라이언트의 설정 백업 기능을 함께 사용하고, 이전 디렉터리에서 파일 몇 개를 임의로 골라 새 설치본에 덮어쓰지 마세요.

재현 가능한 시작 상태 만들기

다른 프록시 클라이언트, 네트워크 가속 도구, 중복 실행 중인 프로그램을 종료하고 네트워크를 제어할 프로그램 하나만 남기세요. 기존 시스템 프록시, DNS 및 VPN 상태를 기록하세요. 특히 업무용 기기는 조직에서 설정한 구성이 있을 수 있습니다. 첫 테스트에서는 시스템 프록시, TUN, 사용자 지정 DNS, 다수의 라우팅 규칙을 한꺼번에 켜지 마세요. 기본 설정으로 단일 연결이 되는지 확인한 뒤 기능을 하나씩 추가하면 문제가 생겼을 때 되돌릴 지점을 파악하기 쉽습니다.

테스트 대상은 두 개 준비하세요. 하나는 프록시 없이 접속 가능한 일상적인 웹사이트, 다른 하나는 프록시 경로를 확인할 HTTPS 웹사이트입니다. 브라우저에서 웹페이지가 열려도 해당 브라우저의 접속 경로만 정상일 수 있으며 모든 앱의 트래픽이 전달된다는 뜻은 아닙니다. 클라이언트 로그에 해당 요청이 나타나는지 확인하고 프록시 전달을 끈 상태와 비교하세요. 테스트 중에는 같은 브라우저 창을 사용해 확장 프로그램, 캐시, 앱 차이의 영향을 줄이는 편이 좋습니다.

마지막으로 시스템 시간이 정확한지, 네트워크에서 웹 로그인 인증이 필요한지, 관리형 네트워크에 연결되어 있는지 확인하세요. 인증서 검증에는 올바른 시간이 필요하며, 포털 인증이 완료되지 않으면 구독 업데이트가 시간 초과될 수 있습니다. 먼저 프록시를 끈 일반 브라우저로 기본 네트워크를 확인한 다음 플랫폼별 항목을 살펴보세요. 첫 연결만 빠르게 완료하려면 사용 가이드로 돌아가세요. 고급 설정을 한 번에 모두 바꿀 필요는 없습니다.

Windows: v2rayN 설치 및 트래픽 전달

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

Windows 다운로드에서 v2rayN을 선택하세요. 데스크톱 버전은 크로스 플랫폼 UI를 사용하고 클래식 WPF 버전은 Windows UI 체계를 유지합니다. 이는 UI 구현 방식의 차이일 뿐, 특정 서버가 한 버전에서만 작동한다는 뜻은 아닙니다. 다운로드 페이지에서 제공하는 x64 패키지가 기기에 맞는지 확인한 뒤 설치 프로그램의 안내를 따르세요. 런타임이 없다는 메시지가 표시되면 안내된 구성 요소를 설치하세요. 출처가 불분명한 사이트에서 DLL 파일을 따로 내려받지 마세요.

처음 실행했을 때 창이 나타나지 않으면 작업 표시줄 알림 영역에 이미 실행 중인 인스턴스가 있는지 확인한 다음 시스템이 프로그램 실행을 차단했는지 살펴보세요. 시스템 프록시 테스트를 위해 프로그램을 계속 관리자 권한으로 실행할 필요는 없습니다. 보호된 디렉터리에 설치하면 일반 디렉터리와 설정 저장 권한이 다를 수 있습니다. 재부팅할 때마다 설정이 사라진다면 구독을 반복해서 가져오기보다 디렉터리 권한과 보안 프로그램의 차단 기록을 먼저 확인하세요.

구독을 가져와 서버 선택하기

“구독 그룹 → 구독 그룹 설정”에서 그룹을 추가하고 알아보기 쉬운 이름을 입력한 뒤 구독 URL 전체를 주소란에 붙여 넣으세요. 저장 후 “모든 구독 업데이트(프록시 사용 안 함)”를 실행합니다. 처음 설정할 때는 아직 사용 가능한 프록시가 없으므로 프록시를 사용하지 않는 업데이트 방식을 우선 사용하세요. 업데이트가 끝나면 해당 그룹을 선택하고 서버 목록이 표시되는지 확인한 뒤 서버 하나를 선택해 활성 서버로 지정하세요.

목록이 바뀌지 않으면 먼저 검색 조건을 지우고 “전체”로 전환한 다음 업데이트 로그를 확인하세요. 응답이 웹 로그인 페이지이거나 구독이 만료되었거나 주소가 일부 누락되면 설정을 파싱하지 못할 수 있습니다. 단일 공유 링크는 “클립보드에서 URL 일괄 가져오기” 등 알맞은 가져오기 메뉴를 사용하세요. 구독 주소로 바로 입력하면 안 됩니다. 설정 페이지에 저장되었다고 서버 정보가 완전한 것은 아니므로 프로토콜, 포트, 전송 매개변수도 확인해야 합니다.

먼저 시스템 프록시를 사용하고 TUN은 필요할 때 검토하기

서버를 선택한 다음 “시스템 프록시”에서 “시스템 프록시 자동 설정”을 선택하고 라우팅은 “중국 본토 우회”로 설정하세요. 시스템 프록시는 Windows 프록시 설정을 따르는 앱에만 적용됩니다. 일부 명령줄 도구와 앱은 자체 네트워크 설정을 사용하므로 브라우저에서 접속된다고 자동으로 프록시를 따르지는 않습니다. 클라이언트 하단에서 로컬 리스닝 정보를 확인하세요. 포트는 현재 설정을 기준으로 하며 일반적인 구성으로 SOCKS 10808, HTTP 10809가 사용되기도 하지만 확인 없이 다른 앱에 그대로 입력하지 마세요.

시스템 프록시를 따르지 않는 트래픽도 클라이언트로 전달해야 할 때 TUN을 검토하세요. TUN은 가상 네트워크 인터페이스, 라우팅 및 관련 권한이 필요하며 활성화 시 권한 요청이 표시될 수 있습니다. 다른 VPN이나 가상 네트워크 카드의 트래픽 전달을 먼저 끈 다음 클라이언트의 TUN을 켜세요. 초기화에 실패하면 로그에서 권한, 네트워크 카드 또는 라우팅 오류를 확인하세요. TUN과 시스템 프록시를 반드시 동시에 켜야 하는 것은 아닙니다. 문제를 해결할 때는 한 가지 전달 방식만 먼저 검증하세요.

포트 충돌, 종료 및 시작 프로그램

포트가 사용 중이라는 로그가 나타나면 먼저 중복 실행 중인 클라이언트를 종료하세요. 추가 확인이 필요하면 명령 프롬프트에서 아래 명령을 사용할 수 있습니다. 이 명령은 연결 및 프로세스 ID를 확인할 뿐 네트워크 설정을 변경하지 않습니다. 결과의 프로세스 ID를 작업 관리자의 “세부 정보”와 대조하고, 포트를 점유했다는 이유만으로 낯선 시스템 프로세스를 종료하지 마세요. 포트를 바꿔야 한다면 해당 포트를 수동으로 설정한 브라우저, 터미널 및 다른 앱도 함께 수정하세요.

netstat -ano | findstr ":10808"
netstat -ano | findstr ":10809"

창을 닫아도 알림 영역으로 최소화될 수 있으며 완전히 종료된 것은 아닙니다. 종료 동작을 테스트할 때는 먼저 시스템 프록시 메뉴에서 “시스템 프록시 지우기”를 선택한 뒤 트레이 메뉴에서 종료하세요. “설정 → 네트워크 및 인터넷 → 프록시”에 수동 프록시 주소가 남아 있는지도 확인하세요. 수동 실행과 정상 종료가 모두 안정적으로 작동한 뒤에 시작 프로그램을 활성화하세요. 그렇지 않으면 시스템 시작 시 클라이언트는 실행되지 않았는데 다른 앱은 로컬 프록시 주소를 계속 사용해 브라우저가 갑자기 인터넷에 연결되지 않을 수 있습니다.

macOS: 아키텍처, 시스템 권한 및 프록시 서비스

칩에 맞는 DMG 선택

Apple 메뉴에서 “이 Mac에 관하여”를 열어 Apple 계열 칩이면 Apple Silicon 패키지를, Intel 프로세서이면 Intel 패키지를 선택하세요. 다음으로 macOS 다운로드에서 해당 v2rayN DMG를 받으세요. 디스크 이미지를 열고 앱을 “응용 프로그램”으로 복사한 뒤 그 위치에서 실행합니다. 디스크 이미지에서 계속 실행하면 업데이트, 권한 기록 및 앱 위치가 일치하지 않을 수 있으며 이미지를 꺼낸 뒤 실행 경로가 사라질 수도 있습니다.

처음 열 때 보안 경고가 표시되면 다운로드 출처와 앱 이름을 먼저 확인한 다음 “시스템 설정 → 개인정보 보호 및 보안”에서 시스템이 제공하는 처리 방법을 살펴보세요. 앱 하나를 실행하려고 시스템 보안 기능 전체를 끄지 마세요. 아키텍처가 호환되지 않는다는 메시지가 나타나면 다운로드 페이지에서 올바른 패키지를 다시 선택하세요. 시스템 버전이 요구 사항에 맞지 않으면 지원되는 런타임이나 시스템을 업데이트하고, 실행 검사를 우회하려고 패키지 내부 파일을 수정하지 마세요.

구독 및 현재 서버 설정

v2rayN의 “구독 그룹” 관련 설정에서 그룹을 추가하고 구독 URL 전체를 저장한 다음 프록시를 사용하지 않는 구독 업데이트를 실행하세요. 크로스 플랫폼 데스크톱 UI에서는 Windows 클래식 버전과 버튼 위치가 다를 수 있지만, 그룹 저장 → 구독 요청 → 활성 서버 선택 순서는 같습니다. 업데이트 후 목록이 비어 있다면 메뉴 위치 차이를 구독 호환성 문제로 오해하지 말고 현재 그룹, 필터 조건, 업데이트 결과부터 확인하세요.

첫 연결에서는 구독에 포함된 TLS, 서버 이름, 전송 매개변수를 그대로 유지하세요. 서버 주소는 네트워크 연결 대상을 지정하고 TLS 서버 이름은 인증서 및 핸드셰이크에서 식별에 사용되므로 둘이 다를 수 있습니다. 보기 좋게 맞추려고 두 값을 같게 변경하지 마세요. 가져온 뒤 서버 하나를 선택하고 시스템 프록시를 활성화한 다음 테스트 대상에 접속하세요. 실패하면 여러 전송 옵션을 한꺼번에 바꾸지 말고 커널 로그부터 확인하세요.

시스템 프록시와 네트워크 서비스의 관계

macOS 프록시 설정은 네트워크 서비스별로 적용됩니다. “시스템 설정 → 네트워크”에서 현재 Wi-Fi 또는 이더넷 서비스의 “세부사항 → 프록시”를 열어 실제 상태를 확인하세요. 클라이언트가 시스템 프록시를 설정할 때 권한 승인이 필요할 수 있습니다. 승인을 거부하면 앱에 표시된 설정과 시스템의 실제 상태가 다를 수 있으므로 다시 확인해야 합니다. 수동으로 변경하기 전에 기존 값을 기록하세요. 조직에서 관리하는 프록시나 자동 설정 주소를 바로 삭제하지 말고 기기의 관리 정책을 먼저 확인하세요.

Wi-Fi에서 유선 네트워크로 전환하거나 도킹 스테이션 연결 후 새 네트워크 서비스가 생기면 현재 어떤 서비스가 활성화되어 있는지 먼저 확인하세요. 브라우저는 새 서비스의 프록시 설정을 따르지만 클라이언트는 계속 실행 중일 수 있습니다. 이때 “프로그램은 정상인데 요청이 로그에 나타나지 않는” 현상이 생길 수 있습니다. 클라이언트를 종료한 뒤 웹페이지에 접속할 수 없다면 해당 네트워크 서비스에 로컬 포트를 가리키는 프록시가 남아 있는지 확인하세요. 이번에 변경한 설정만 복구하고 네트워크 구성을 전부 지우지 마세요.

TUN 권한, 절전 모드 및 네트워크 전환

TUN은 가상 네트워크 인터페이스를 만들고 라우팅을 조정하므로 구체적인 권한 부여 방식은 클라이언트 구현과 시스템 환경에 따라 달라집니다. 활성화 전에 다른 VPN의 트래픽 전달을 끄고 클라이언트 안내에 따라 필요한 권한을 부여하세요. 권한 요청을 취소했거나 백그라운드 보조 프로세스가 실행되지 않았거나 라우팅 생성에 실패했다면 먼저 초기화 오류를 해결해야 합니다. 모든 권한 요청을 일반 알림 권한으로 간주하지 말고 앱 설치 위치가 바뀌어도 한 번 허용한 권한이 계속 적용된다고 가정하지 마세요.

절전 모드에서 복귀하거나 네트워크를 전환하면 기존 연결이 끊기고 DNS 또는 기본 라우팅이 바뀔 수 있습니다. 현재 트래픽 전달 모드를 껐다가 다시 켜고 새 요청이 생성되는지 확인하세요. 앱이나 커널에 실제 이상이 있을 때만 앱을 재시작하세요. 설치 위치, 시스템 계정 또는 백업 복원 후 권한 문제가 생겼다면 앱 디렉터리와 시스템 권한 상태를 다시 확인하세요. 한 번에 한 가지 요소만 바꾸는 편이 연속해서 재설치하는 것보다 원인을 찾기 쉽습니다.

다른 Mac으로 옮길 때는 구독 출처와 필요한 라우팅 기록을 우선 옮긴 다음 새 기기의 칩, 리스닝 포트 및 권한을 다시 확인하세요. 이전 기기에서 내보낸 전체 설정에는 로컬 경로나 특정 네트워크 서비스 정보가 포함될 수 있으므로 확인 없이 바로 덮어쓰지 마세요. 이전 후 시스템 프록시를 먼저 테스트하고 TUN을 별도로 확인하세요. 정상 종료 시 네트워크 상태가 복구되는지도 검증하면 문제를 특정 트래픽 전달 방식으로 좁힐 수 있습니다.

Linux: 패키지, 데스크톱 프록시 및 권한

아키텍처와 패키지 형식을 모두 맞게 선택하기

Linux에서는 프로세서 아키텍처와 배포판의 패키지 체계를 모두 확인해야 합니다. Debian, Ubuntu 계열은 보통 deb를 사용하고 Fedora 등은 rpm을 사용합니다. x86_64는 일반적으로 x64, aarch64는 arm64에 해당합니다. 시스템 정보나 아래 명령으로 확인한 뒤 Linux 다운로드에서 v2rayN을 선택하세요. 파일 확장자만 보거나 컨테이너에서 확인한 아키텍처를 호스트 데스크톱의 전체 시스템 정보로 판단하지 마세요.

uname -m
cat /etc/os-release

다운로드가 완료되면 배포판의 소프트웨어 설치 프로그램으로 패키지 파일을 열어 패키지 관리자가 의존성과 앱 실행 경로를 처리하도록 하세요. 의존성 해결에 실패하면 어떤 구성 요소가 누락되었는지와 시스템 지원 범위를 먼저 확인하세요. 다른 배포판의 라이브러리 파일을 시스템 디렉터리에 복사하지 마세요. GUI 데스크톱 클라이언트는 사용할 수 있는 데스크톱 세션이 필요합니다. 원격 터미널 환경에서는 설치에 성공했다고 GUI, 트레이, 시스템 프록시 연동까지 작동한다고 볼 수 없습니다.

일반 사용자 계정으로 설정 구성하기

앱 메뉴에서 v2rayN을 실행하고 현재 일반 사용자 계정으로 구독을 저장하세요. “구독 그룹”에서 주소를 추가하고 프록시를 사용하지 않는 방식으로 업데이트한 뒤 서버 목록이 생성되면 활성 서버를 선택합니다. 권한 요청을 피하려고 GUI 프로그램 전체를 슈퍼유저로 실행하지 마세요. 설정 디렉터리의 파일 소유자가 바뀌어 이후 일반 사용자로 실행할 때 설정을 저장하지 못할 수 있습니다. 저장에 실패하면 먼저 사용자 디렉터리에 쓰기 권한이 있는지 확인하세요.

업데이트 전에 구독 주소의 사이트에 기본 네트워크로 접속할 수 있는지 확인하세요. 데스크톱 브라우저는 이미 프록시를 사용하고 있어도 클라이언트의 구독 요청은 다른 경로로 나갈 수 있습니다. 따라서 브라우저에서 구독 페이지가 열린다고 프록시 없이 업데이트할 수 있는 것은 아닙니다. 첫 가져오기는 직접 접속 가능한 구독 출처를 우선 사용하세요. 활성 서버가 있는 경우에만 출처의 요구 사항에 맞춰 프록시 경유 업데이트를 테스트하고 두 방식의 오류를 각각 기록하세요.

데스크톱 시스템 프록시는 모든 프로세스를 한꺼번에 제어하지 않습니다

Linux 데스크톱 환경마다 프록시 지원 방식이 다릅니다. GNOME, KDE의 시스템 네트워크 설정과 터미널 프로세스의 환경 변수는 서로 다른 경로입니다. 일부 앱은 데스크톱 설정을 읽고, 일부 앱은 자체 설정이나 환경 변수를 사용합니다. 클라이언트가 시스템 프록시를 설정했다고 표시하면 데스크톱 네트워크 설정에서도 확인하고 실제 앱으로 테스트하세요. 터미널이 계속 직접 연결된다고 바로 클라이언트 오류로 판단하지 말고 해당 도구가 어떤 프록시 설정을 지원하는지 먼저 확인하세요.

아래 명령은 로컬 HTTP 리스너가 10809임을 확인한 뒤 해당 포트에서 HTTPS 요청을 처리할 수 있는지 테스트할 때 사용할 수 있습니다. 이 명령은 한 번 실행하는 curl 요청에만 프록시를 지정하며 터미널이나 시스템 전체를 설정하지 않습니다. 예시에는 문서용으로 예약된 도메인이 사용되었습니다. 실제 업무를 테스트할 때는 접근이 허용된 대상으로 바꾸세요. 클라이언트 포트가 다르면 명령도 수정해야 합니다. curl이 설치되어 있지 않다면 브라우저의 별도 프록시 설정으로 같은 테스트를 할 수 있습니다.

curl --proxy http://127.0.0.1:10809 -I https://example.com

일반 HTTP 프록시는 CONNECT를 통해 HTTPS 요청을 전달할 수 있습니다. 따라서 프록시 주소가 HTTP라고 해서 대상 웹사이트의 TLS가 사라지는 것은 아닙니다. 프로그램에서 SOCKS를 요구하면 HTTP 포트를 그대로 둔 채 프로토콜 접두사만 바꾸지 말고 클라이언트가 실제로 제공하는 SOCKS 포트를 입력하세요. 원격 도메인 이름을 해석하는 방식은 도구마다 다르므로 비교 테스트에서는 프록시 종류와 DNS 조회 위치를 함께 기록해야 합니다.

TUN, 라우팅 및 데스크톱 세션

TUN은 장치 접근, 네트워크 관리 권한, 시스템 라우팅이 필요하므로 일반 사용자로 실행한 클라이언트에 추가 권한이 필요할 수 있습니다. 클라이언트와 배포판이 제공하는 방식에 따라 권한을 부여하세요. 출처가 불분명한 권한 상승 명령을 그대로 사용하거나 지나치게 넓은 권한을 계속 부여하지 마세요. 실행에 실패하면 권한 거부, 가상 인터페이스 생성 실패, 기존 VPN 경로 충돌 여부를 먼저 살펴본 다음 조치하세요. 모든 실패를 서버 탓으로 돌리면 안 됩니다.

트레이 아이콘이 보이지 않는 것은 데스크톱 환경에서 해당 기능을 지원하지 않기 때문일 수 있으며, 커널이 실행되지 않는다는 뜻은 아닙니다. 시작 프로그램도 데스크톱 세션 자동 시작과 시스템 서비스는 사용자, 환경 변수, 권한이 서로 다릅니다. 수동 실행, 네트워크 전환, 트래픽 전달 해제, 종료 후 복원이 모두 정상인지 확인한 다음 자동 시작을 설정하세요. 앱 업데이트 후에는 권한과 시작 항목을 다시 확인해 제거된 경로를 가리키는 이전 실행 항목이 남지 않도록 하세요.

Android: v2rayNG 및 v2flyNG

설치 패키지 및 클라이언트 선택

Android 다운로드에서는 Xray 커널을 사용하는 v2rayNG를 우선 권장합니다. V2Fly 커널 환경이 필요한 경우 v2flyNG를 고려하세요. 두 클라이언트에서 VPN 연결을 동시에 설정하면 안 됩니다. 최신 주류 기기는 보통 arm64를 사용하며 아키텍처를 모르면 범용 패키지를 선택할 수 있습니다. 범용 패키지는 더 많은 아키텍처를 지원한다는 뜻이지 연결 품질이 더 높다는 뜻은 아닙니다. 휴대전화 브랜드만 보고 설치할 클라이언트를 결정하지 마세요.

다운로드한 패키지를 설치할 때 Android에서 현재 브라우저나 파일 관리자에 “알 수 없는 앱 설치”를 허용하라는 메시지가 나타날 수 있습니다. 실제 설치에 사용할 앱에만 권한을 부여하고 설치가 끝나면 끌 수 있습니다. 설치에 실패하면 같은 이름의 이전 앱이 있는지, 기기 저장 공간이 충분한지, 시스템 호환 요구 사항을 충족하는지 확인하세요. 기존 설정이 있다면 업그레이드 문제를 해결하려고 바로 앱을 삭제하기 전에 내보내기 기능으로 백업하세요. 구독과 사용자 지정 규칙까지 함께 사라질 수 있습니다.

구독 가져오기 및 단일 서버 설정

v2rayNG 메뉴에서 “구독 그룹 설정”을 열고 그룹 이름과 구독 URL을 추가한 뒤 저장하고 구독을 업데이트하세요. 빌드에 따라 업데이트 메뉴가 메인 화면이나 그룹 메뉴에 있을 수 있으므로 기능 이름을 기준으로 찾으세요. 업데이트가 끝나면 목록으로 돌아가 사용할 서버를 선택하고 현재 활성 항목인지 확인한 뒤 연결을 시작하세요. 그룹만 저장하고 업데이트하지 않으면 서버 목록이 자동으로 만들어지지 않습니다.

단일 공유 링크는 메인 화면의 추가 메뉴에서 클립보드로 가져올 수 있으며 QR 코드를 스캔하려면 카메라 권한이 필요합니다. 클립보드 내용은 다른 앱에 의해 바뀔 수 있으므로 가져온 뒤 유형, 주소, 포트가 예상과 일치하는지 확인하세요. 시스템에서 백그라운드 클립보드 읽기를 제한하면 클라이언트를 화면에 띄운 상태에서 다시 가져오세요. 관계없는 권한을 계속 요청하지 마세요. v2flyNG의 사용 흐름은 비슷하지만 커널에서 지원하는 구체적인 프로토콜 옵션은 별도로 확인해야 합니다.

시스템 VPN 권한 및 앱 범위

처음 연결 버튼을 누르면 시스템에 VPN 연결 요청이 표시됩니다. 방금 설치한 클라이언트에서 온 요청인지 확인한 뒤 승인하세요. 이 권한은 로컬 VPN 트래픽을 전달하기 위한 것으로 시스템이 원격 서버를 자동으로 제공한다는 뜻은 아닙니다. 연결 후 시스템 VPN 상태와 클라이언트 실행 로그를 확인하세요. Android에서는 보통 VPN 서비스 하나만 활성화할 수 있으므로 업무용 설정, 다른 VPN 도구, 로컬 트래픽 필터 앱이 서로 대체할 수 있습니다.

Android 클라이언트는 보통 VPN 서비스를 통해 앱 트래픽을 전달하므로 데스크톱의 “시스템 프록시 자동 설정”을 그대로 적용하지 않습니다. 앱 범위를 지정해야 한다면 클라이언트의 앱별 프록시 또는 앱별 라우팅 설정을 확인하고, “선택한 앱만 프록시 사용”과 “선택한 앱 우회” 중 어느 쪽인지 먼저 파악하세요. 두 설정은 적용 범위가 반대입니다. 설정 후 다시 연결하고 목록에 포함된 앱과 제외된 앱을 각각 테스트하세요. 체크 표시만 보고 범위가 올바르다고 판단하지 마세요.

백그라운드 실행, 비공개 DNS 및 네트워크 전환

화면을 잠그면 연결이 끊기고 화면을 켜면 복구되는 경우 클라이언트의 배터리 최적화, 백그라운드 실행, 자동 시작 제한을 확인하세요. 제조사마다 설정 이름이 다르므로 해당 클라이언트에 적용되는 항목만 확인하고 기기 전체의 절전 기능을 끌 필요는 없습니다. 백그라운드 제한 문제는 대개 프로세스가 종료되거나 VPN 상태가 사라지는 형태로 나타납니다. 프로세스가 계속 실행 중인데 로그에 연결 시간 초과가 표시되면 배터리 설정 대신 네트워크 전환, 서버 접속 가능성, DNS를 살펴보세요.

Wi-Fi에서 모바일 네트워크로 전환하면 로컬 주소와 기본 라우팅이 바뀌어 기존 연결이 끊길 수 있습니다. 연결을 중지한 뒤 다시 시작하고 새 핸드셰이크가 성공하는지 확인하세요. 특정 네트워크에서만 실패하면 네트워크 종류와 시간을 기록하고 같은 서버의 결과를 비교하세요. 시스템의 “비공개 DNS”와 클라이언트 DNS는 서로 다른 설정입니다. 둘을 동시에 바꾸면 원인을 찾기 어려워지므로 DNS 오류가 발생하면 먼저 현재 비공개 DNS 상태를 기록한 뒤 한 번에 한 가지씩 테스트하세요.

클라이언트의 지연 시간 테스트는 앱의 전체 접속 과정을 검증하지 않으며, 일부 방식은 제한된 연결 단계만 확인합니다. 서버 테스트는 성공하지만 앱이 작동하지 않는다면 앱별 범위, 라우팅, 도메인 조회를 확인하세요. 테스트는 실패했는데 웹페이지가 열리면 테스트 대상이나 테스트 방식 자체의 문제도 고려해야 합니다. 다른 기기로 옮길 때는 구독 출처를 우선 옮기세요. Android VPN 권한과 배터리 정책은 새 기기에서 다시 설정해야 하며 설정 백업만으로 그대로 복원되지 않습니다.

구독 관리: 업데이트, 매개변수 및 설정 이전

구독 URL과 서버 링크의 차이

구독 URL은 업데이트 가능한 설정 모음을 가리키고 단일 공유 링크는 서버 하나의 정보를 담습니다. 둘은 서로 다른 가져오기 메뉴를 사용해야 합니다. 문자열 길이만 보고 판단하지 말고 자료 출처에서 용도를 확인하세요. 웹 공유 주소를 구독 URL로 입력하면 HTML 페이지를 받아 파싱하지 못할 수 있습니다. 단일 링크를 구독 URL로 등록해도 업데이트에 실패할 수 있습니다. 먼저 자료 유형을 확인한 뒤 구독 그룹 설정 또는 클립보드 가져오기를 선택하세요.

출처나 용도별로 그룹을 만들고 알아보기 쉬운 이름을 사용하세요. 그룹은 많을수록 좋은 것이 아닙니다. 구독이 중복되면 비슷한 항목이 늘어나 활성 서버와 테스트 결과를 연결하기 어려워집니다. 업데이트 후 항목이 줄어들어도 클라이언트가 설정을 삭제했다고 바로 단정하지 마세요. 구독 출처의 내용이 바뀌었는지, 계정이 만료되었는지, 일부 그룹이 현재 숨겨져 있는지 먼저 확인하세요. 목록 필터와 구독의 실제 내용은 따로 점검해야 합니다.

프록시를 통한 업데이트와 직접 연결 업데이트

“모든 구독 업데이트(프록시 사용 안 함)”은 현재 활성 프록시 경로에 의존하지 않고 구독을 요청하는 방식이므로 처음 설정할 때 적합합니다. 다만 구독 출처에 직접 접속할 수 있다는 보장은 없습니다. “프록시 사용” 방식은 선택한 서버가 정상 작동해야 합니다. 활성 서버가 만료된 구독에서 가져온 것이라면 그 서버로 같은 구독을 업데이트하는 방식은 순환 문제가 생길 수 있습니다. 복구할 수 있도록 원래 구독 출처 정보를 보관하고 기본 네트워크에서 접속할 수 있다면 직접 연결로 업데이트하세요.

업데이트에 실패하면 세 단계로 나누어 확인하세요. 연결을 설정할 수 있는지, 응답 내용이 예상한 형식인지, 파싱된 항목을 사용할 수 있는지 살펴봅니다. 연결 시간 초과와 로그인 페이지 반환은 서로 다른 문제입니다. 파싱에 성공해도 필드를 읽을 수 있다는 뜻일 뿐 서버 핸드셰이크가 성공한다는 보장은 없습니다. 구독 URL의 특수 문자, 끝부분 매개변수, 대소문자는 중요할 수 있으므로 주소를 짧게 만들려고 임의로 삭제하거나 수정하지 마세요. 복사할 때 줄바꿈, 전각 문장 부호, 메신저가 덧붙인 텍스트도 확인하세요.

프로토콜 필드를 임의로 수정하지 마세요

일반적인 필드는 연결 대상, 인증 정보, 전송 계층, TLS의 네 가지로 나눌 수 있습니다. 주소와 포트는 연결할 대상을 지정하고 사용자 ID나 비밀번호는 인증에 사용됩니다. 전송 유형과 경로는 데이터를 전달하는 방식을 정하며 TLS 서버 이름, ALPN 및 관련 보안 매개변수는 핸드셰이크에 관여합니다. 필드를 생략할 수 있는지는 프로토콜과 서버 설정에 따라 다릅니다. 다른 서버에서 작동한 값을 그대로 적용하거나 필드 이름만 보고 기본값을 추측하지 마세요.

서버 주소와 Host, TLS 서버 이름은 서로 다른 계층에서 사용되므로 값이 다를 수 있습니다. 인증서 이름이 일치하지 않으면 출처의 설정과 시스템 시간을 확인하세요. 오류를 숨기려고 인증서 검증을 건너뛰도록 설정하지 마세요. 프로토콜을 인식하더라도 커널이 모든 확장 기능을 지원한다는 뜻은 아닙니다. v2rayNG와 v2flyNG를 바꿔 사용했다면 특히 특정 프로토콜과 전송 옵션을 확인하세요. 화면에 표시된 서버 이름만 비교해서는 안 됩니다.

백업 및 플랫폼 간 이전

이전할 때는 먼저 구독 출처, 그룹 이름, 필요한 사용자 지정 규칙을 보관하고 그다음 클라이언트의 전체 백업 기능 사용을 검토하세요. 운영체제별 로컬 경로, 리스닝 포트, TUN 권한 및 UI 설정은 그대로 재사용하지 못할 수 있습니다. 새 기기에 아키텍처에 맞는 클라이언트를 설치하고 구독을 가져와 기본 연결을 확인한 뒤 라우팅과 DNS를 하나씩 복원하세요. 그러면 이전 과정에서 생긴 문제와 기존 설정 문제를 구분할 수 있습니다.

구독을 업데이트하면 구독에서 관리하는 서버 항목이 다시 만들어질 수 있으므로 해당 항목을 직접 수정해도 변경 사항이 계속 유지되지 않을 수 있습니다. 매개변수를 시험해야 한다면 클라이언트에서 지원하는 경우 별도 테스트 설정으로 복사하고 용도를 명확히 표시해 나중에 잘못 사용하지 않도록 하세요. 이전을 마친 뒤 이전 기기의 권한이 계속 필요한지 확인하세요. 구독 정보가 유출되었다면 출처에서 접속 정보를 변경해야 합니다. 클라이언트에서 그룹을 삭제하는 것만으로 이미 유출된 주소를 무효화할 수는 없습니다.

프록시, 라우팅 및 DNS: 단계별 검증

트래픽 전달 방식과 최종 경로는 별개입니다

시스템 프록시, 앱별 프록시, TUN은 요청을 클라이언트로 전달하고 라우팅 규칙은 직접 연결, 프록시 또는 차단 여부를 결정합니다. TUN을 켠다고 모든 대상이 원격 서버를 통과하는 것은 아니며 “전역” 라우팅을 선택해도 모든 앱이 트래픽 전달 대상이 되는 것은 아닙니다. 이 두 가지를 따로 검증해야 합니다. 먼저 요청이 커널 로그에 들어오는지 확인한 다음 어떤 아웃바운드에 연결되었는지 살펴보세요. 스위치 색상만 보고 실제 네트워크 경로를 판단하지 마세요.

처음 테스트할 때는 시스템 프록시와 기본 제공 라우팅 모드를 사용하세요. v2rayN의 “라우팅 → 중국 본토 우회”는 일반적인 직접 연결과 프록시의 역할을 나누는 시작점으로 적합합니다. “전역” 모드는 동일한 대상의 경로별 동작을 임시로 비교할 때 사용할 수 있습니다. 기본 규칙의 실제 내용은 설정에 따라 달라질 수 있으므로 이름만 보지 말고 현재 규칙을 확인하세요. 앱 요청이 로그에 전혀 나타나지 않으면 도메인 규칙을 바꾸기 전에 트래픽 전달 범위부터 살펴보세요.

규칙 순서와 일치 범위

커널 라우팅은 보통 규칙 순서대로 매칭하며 처음 일치한 규칙이 결과를 결정합니다. 특정 도메인 규칙은 일반적인 규칙보다 앞에 두는 것이 좋습니다. 사설 IP 직접 연결 규칙은 로컬 서비스가 원격으로 전달되는 것을 막습니다. 도메인 매칭과 IP 매칭은 서로 다른 경로입니다. 커널에 주소만 전달되면 일부 도메인 규칙이 적용되지 않을 수 있습니다. 도메인이 전달되더라도 DNS 조회 후 IP 규칙을 추가로 적용할지는 도메인 정책과 설정에 따라 다릅니다.

아래는 Xray 라우팅 필드 예시로, “로컬 사설 주소는 직접 연결, 문서용 도메인도 직접 연결, 나머지 TCP와 UDP는 프록시 사용” 순서를 보여줍니다. 단독으로 실행할 수 있는 완전한 설정은 아니며 기존 설정에 direct와 proxy라는 아웃바운드 태그가 있어야 합니다. GUI 클라이언트는 보통 커널 설정을 생성하므로 실행 디렉터리의 임시 파일을 직접 수정하면 다음 시작 때 덮어써질 수 있습니다. 클라이언트의 라우팅 편집 메뉴를 우선 사용하세요.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["full:example.com", "domain:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

full:example.com은 도메인 전체를 정확히 일치시키고, domain:example.org는 해당 도메인과 하위 도메인에 적용됩니다. 규칙 태그는 실제 아웃바운드 이름과 일치해야 하므로 이름을 그대로 복사하지 마세요. geosite 또는 geoip 데이터를 사용한다면 해당 리소스를 읽을 수 있는지도 확인해야 합니다. 문법이 올바르다는 것은 설정 구조를 파싱할 수 있다는 뜻일 뿐, 규칙 순서가 목적에 맞다는 보장은 없습니다. 사용자 지정 라우팅 문법과 우선순위를 참고해 하나씩 점검하세요.

DNS 조회 위치가 결과에 미치는 영향

DNS는 도메인 이름을 IP 주소로 바꾸며 라우팅 판단에 사용할 수 있는 정보에도 영향을 줍니다. 시스템 DNS, 브라우저 보안 DNS, 앱 자체 조회, 클라이언트 DNS가 동시에 작동할 수 있습니다. 웹페이지에서 조회 오류가 나타나면 먼저 어느 구성 요소가 DNS 조회를 시작했는지 확인하세요. 브라우저에서 암호화 DNS를 사용하면 시스템 DNS를 바꿔도 영향을 주지 않을 수 있습니다. DNS 서버 변경을 인증서, 인증 정보, 포트 문제의 만능 해결책으로 여기지 마세요.

FakeDNS는 가상 주소와 도메인 매핑을 이용해 도메인 정보를 유지하는 방식으로, TUN이나 투명 프록시 환경에서 자주 사용되지만 첫 연결에 필수는 아닙니다. 활성화한 뒤 앱이 가상 주소를 캐시했다면 기능을 끈 후 연결을 다시 설정하거나 해당 앱의 캐시를 지워야 할 수 있습니다. 주소 매핑의 수명 주기를 잘 모른다면 일반 DNS 설정부터 사용하세요. 관련 원리는 FakeDNS 작동 원리에서 확인할 수 있습니다. 시스템과 클라이언트의 DNS 설정을 한꺼번에 모두 바꾸지 마세요.

매개변수를 계속 바꾸기보다 비교 테스트를 활용하세요

사용자 지정 규칙을 검증할 때는 대상 하나를 정하고 현재 트래픽 전달 방식, 라우팅 모드, 로그에 표시된 아웃바운드를 기록하세요. 먼저 기본 모드로 연결을 확인한 뒤 규칙 하나를 추가하고 요청을 다시 보내세요. 브라우저가 기존 연결을 재사용하면 이전 경로가 계속 쓰일 수 있으므로 필요하다면 해당 사이트의 연결을 닫고 다시 시도하세요. 규칙 하나가 문제를 해결하면 같은 유형의 대상에 적용 범위를 넓히세요. 규칙을 한꺼번에 많이 가져오면 어떤 규칙이 동작을 바꿨는지 판단하기 어렵습니다.

설정 문제 해결: 오류가 발생한 단계 찾기

먼저 실패가 발생한 계층을 찾으세요

문제 해결 순서는 기본 네트워크, 클라이언트 실행, 로컬 리스닝, 트래픽 전달, 원격 연결, 라우팅, 앱입니다. 먼저 트래픽 전달을 끄고 일반 네트워크가 되는지 확인하세요. 클라이언트를 실행해 커널이 정상 작동하는지 살펴본 뒤 로컬 포트를 점검합니다. 이 단계가 모두 정상일 때 서버 핸드셰이크와 대상 웹사이트를 확인하세요. 그러면 포트 충돌을 구독 문제로 오인하거나 시스템 프록시가 적용되지 않은 상태에서 서버만 반복해서 바꾸는 일을 줄일 수 있습니다.

기기 운영체제, 클라이언트 종류, 트래픽 전달 방식, 오류 발생 시간, 실행부터 첫 실패까지의 로그를 간단히 기록하세요. 테스트할 때는 클라이언트 하나와 활성 서버 하나만 남기고, 여러 항목을 연달아 바꾼 뒤 서로 연관 없는 로그를 캡처하지 마세요. 기록을 공유하기 전에 구독 URL, 사용자 정보, 민감한 대상은 가리세요. 오류가 발생한 계층을 파악하는 데 필요한 정보만 남기면 되며 설정 파일 전체를 공개할 필요는 없습니다.

서버 목록이 비어 있음, 실행 실패, 포트 점유

서버 목록이 비어 있으면 먼저 전체 그룹으로 전환하고 필터를 해제한 뒤 구독 업데이트가 실제로 성공했는지 확인하세요. 로그에 파싱 실패가 표시되면 응답 내용, 자료 형식, URL 전체가 입력되었는지 확인합니다. 네트워크 오류라면 기본 연결과 업데이트 요청이 프록시를 거쳤는지 살펴보세요. 서버는 있지만 커널이 시작되지 않는다면 구독을 반복해서 업데이트하지 말고 설정 생성 오류, 리소스 경로, 포트 점유를 확인하세요.

로그에 address already in use가 표시되면 보통 바인딩하려는 주소나 포트를 다른 프로세스가 사용 중이라는 뜻입니다. 다른 클라이언트와 중복 인스턴스를 먼저 종료한 뒤 서비스를 다시 시작하세요. 리스닝 포트를 바꾸면 일부 충돌을 해결할 수 있지만 해당 포트를 수동으로 참조하는 앱도 모두 수정해야 합니다. TUN 인터페이스나 라우팅 충돌이라면 SOCKS 포트를 바꿔도 해결되지 않을 수 있으므로 가상 네트워크 및 권한을 점검하세요. 두 종류의 리소스를 혼동하지 마세요.

핸드셰이크 실패, 시간 초과 및 인증서 오류

연결 시간 초과는 정해진 시간 안에 특정 단계가 완료되지 않았다는 뜻이지 서버가 반드시 만료되었다는 뜻은 아닙니다. 구독 가져오기, 원격 연결, 대상 접속 중 어느 단계에서 발생했는지 구분하고 같은 설정을 다른 네트워크에서 시험한 결과와 비교하세요. 특정 네트워크에서 모든 서버의 시간 초과가 발생하면 네트워크 환경을 먼저 확인하세요. 서버 하나에서만 실패한다면 해당 서버 정보와 서버 측 상태를 점검하세요. 테스트 수치를 확인하려고 프로토콜, 포트, 전송 유형을 동시에 바꾸지 마세요.

TLS 또는 인증서 오류가 나면 기기의 날짜, 시간, 시간대를 확인한 다음 서버 이름, 연결 주소, 출처 정보를 대조하세요. 인증 실패는 사용자 ID, 비밀번호 또는 구독 유효 기간을 확인해야 합니다. WebSocket 경로, Host, 서비스 이름 등 전송 필드가 맞지 않아도 연결 직후 끊길 수 있습니다. 로그의 warning이 항상 치명적인 오류인 것은 아닙니다. 그 뒤에 시작이 정상적으로 이어지는지 확인하고 실제로 실패한 요청과 함께 살펴보세요.

웹페이지는 열리지만 앱에서 실패하거나 종료 후 인터넷에 연결되지 않음

웹페이지는 열리는데 앱에서 실패한다면 해당 앱이 시스템 프록시를 따르는지, 앱별 규칙에서 제외되었는지, UDP가 필요한지 확인하세요. HTTP 프록시, SOCKS, TUN은 적용 범위가 서로 다르므로 브라우저 테스트 한 번으로 모든 프로토콜을 검증할 수 없습니다. 앱 요청이 로그에 들어왔다면 라우팅 아웃바운드와 원격 응답을 확인하고, 로그에 없다면 먼저 트래픽 진입 경로를 살펴보세요. 전역 라우팅으로 트래픽이 전달되지 않는 앱 문제를 해결할 수는 없습니다.

종료 후 인터넷에 연결되지 않으면 시스템에 로컬 프록시가 남아 있는지 또는 VPN이 아닌 연결을 차단하는 정책이 활성화되어 있는지 확인하세요. 이번에 변경한 프록시와 트래픽 전달 설정을 먼저 복구한 다음 클라이언트가 실제로 종료되었는지 확인합니다. 네트워크 전체를 즉시 초기화하지 마세요. 업무용 네트워크, 고정 주소, 기타 필요한 설정까지 삭제될 수 있습니다. 기기를 다시 시작해야 한다면 오류 기록을 먼저 저장하세요. 재시작으로 일부 임시 상태를 지울 수 있지만 원래 원인을 설명해 주지는 않습니다.

정상 작동하는 기본 설정으로 복원한 뒤 하나씩 다시 추가하기

원인을 찾기 어렵다면 필요한 설정을 내보내고 구독 출처를 보관한 뒤 서버 하나, 기본 라우팅, 단일 트래픽 전달 방식으로 되돌리세요. 사용자 지정 DNS와 추가 규칙을 잠시 제거하고 정상 작동을 확인한 다음 하나씩 다시 추가하면서 같은 테스트를 반복하세요. 재설치가 필요하다면 문제가 사용자 설정과 관련 있는지 먼저 확인하세요. 문제가 있는 설정을 그대로 다시 가져오면 프로그램만 재설치해도 같은 증상이 나타날 수 있습니다. 다른 기기에서 작동한다고 해서 이 기기의 네트워크 차이까지 배제되는 것은 아닙니다.

기타 문제는 자주 묻는 질문에서 확인하세요. 로그 필드의 의미를 알아보려면 v2rayN 실행 로그로 문제 찾기를 참고하세요. 문제를 해결한 뒤 실제 리스닝 포트, 프록시 방식, 라우팅 선택을 기록하고 테스트용 임시 규칙을 삭제한 다음 정상 종료와 재시작을 다시 확인하세요. 설명하기 어려운 매개변수를 쌓아 두기보다 간단한 기본 설정을 기록해 두는 편이 이후 관리에 도움이 됩니다.