DESKTOP · V2RAYN
Windows
데스크톱 버전과 클래식 WPF 버전을 제공합니다. 새로 설치한다면 먼저 크로스 플랫폼 인터페이스의 데스크톱 버전을 선택할 수 있습니다. 기존 창 배치, 서버 목록과 트레이 메뉴에 익숙하다면 클래식 버전을 확인하세요. 설치 전에 시스템 아키텍처를 확인하고 클라이언트 설정 폴더의 읽기·쓰기 권한을 유지하세요.
다운로드로 이동V2RAY CLIENTS · CONFIGURATION GUIDE
Windows, macOS, Android, Linux용 클라이언트 다운로드와 설정 문서를 제공하며, 구독 가져오기, 시스템 프록시, TUN 모드 및 라우팅 규칙의 실제 설정 방법을 한곳에 정리했습니다.
PLATFORM ENTRY
다운로드 페이지에서 플랫폼별 클라이언트, 설치 패키지 형식과 선택 방법을 확인할 수 있습니다. 데스크톱에서는 v2rayN을 사용하고, Android에서는 필요한 커널에 따라 v2rayNG 또는 v2flyNG를 선택하세요.
DESKTOP · V2RAYN
데스크톱 버전과 클래식 WPF 버전을 제공합니다. 새로 설치한다면 먼저 크로스 플랫폼 인터페이스의 데스크톱 버전을 선택할 수 있습니다. 기존 창 배치, 서버 목록과 트레이 메뉴에 익숙하다면 클래식 버전을 확인하세요. 설치 전에 시스템 아키텍처를 확인하고 클라이언트 설정 폴더의 읽기·쓰기 권한을 유지하세요.
다운로드로 이동DESKTOP · V2RAYN
설치 패키지는 Apple Silicon과 Intel 프로세서용으로 나뉩니다. 시스템 정보에서 칩 이름을 확인한 뒤 알맞은 다운로드 항목으로 이동하세요. 처음 실행하면 시스템 안내에 따라 네트워크 구성 권한을 허용해야 합니다. 구독 가져오기와 활성 서버 선택 과정은 다른 데스크톱 플랫폼과 동일합니다.
다운로드로 이동MOBILE · V2RAYNG / V2FLYNG
v2rayNG는 Xray 커널을 사용해 일반적인 프로토콜과 라우팅 설정에 적합하며, v2flyNG는 V2Fly 커널을 사용하는 대안입니다. 최근 출시된 대부분의 기기는 arm64 패키지를 사용할 수 있고, 아키텍처를 확인하기 어려울 때는 범용 패키지를 선택하세요. 연결 시 시스템에 네트워크 연결 권한 요청이 표시됩니다.
다운로드로 이동DESKTOP · V2RAYN
v2rayN은 주요 배포판의 패키지 관리 체계에 맞는 설치 패키지를 제공합니다. Debian·Ubuntu 계열은 보통 deb, Fedora·RHEL 계열은 보통 rpm을 선택합니다. x64와 arm64도 프로세서 아키텍처에 따라 구분해야 합니다. 설치 후 데스크톱 메뉴에서 실행한 다음 구독과 프록시 모드를 설정하세요.
다운로드로 이동LINK INSPECTION
구성 출처부터 출구 연결 확인까지 각 구간을 순서대로 점검합니다. 왼쪽에서 현재 단계를 선택하면 오른쪽에 해당 단계에서 해결할 문제, 설정 위치와 확인할 매개변수가 표시됩니다.
SOURCE / UPDATE
구독 주소는 클라이언트가 생성하는 값이 아니라 설정 제공자가 전달하는 서버 정보 묶음입니다. 올바른 그룹에 주소를 추가한 뒤 업데이트하면 클라이언트가 프로토콜, 주소, 포트, 전송 및 보안 매개변수를 해석해 선택 가능한 서버 목록을 만듭니다. 업데이트 후에는 먼저 그룹 이름과 노드 수가 바뀌었는지 확인한 다음 활성 서버를 선택하세요. 목록이 비어 있다면 프록시 모드를 반복해서 바꾸기보다 주소가 완전한지, 그룹을 올바르게 선택했는지, 업데이트 로그에 문제가 없는지 확인해야 합니다.
여러 구독을 함께 사용할 때는 출처별로 그룹을 만들고 알아보기 쉬운 메모를 추가하는 것이 좋습니다. 그룹별 업데이트·필터링·정렬이 가능해 같은 이름의 서버가 한 목록에 섞이는 일을 줄일 수 있습니다. 구독 내용이 바뀌어도 사용자가 직접 만든 로컬 설정이 자동으로 대체되지는 않으므로 수동 항목과 원격 항목을 분리해 관리하세요.
source: subscription · action: update · result: server list
INBOUND / SYSTEM
시스템 프록시 모드는 운영체제의 프록시 주소를 클라이언트의 로컬 수신 포트로 지정합니다. 브라우저와 시스템 설정을 따르는 대부분의 데스크톱 앱은 이 경로로 트래픽을 보냅니다. 작동 범위가 명확하고 켜고 끄기 쉬워 처음 연결할 때 기본 선택으로 적합합니다. 클라이언트가 실행 중인데도 앱이 직접 연결된다면 시스템 프록시가 실제로 활성화되었는지, 앱에 별도 프록시 설정이 있는지, 로컬 수신 포트를 다른 프로그램이 사용 중인지 확인하세요.
클라이언트를 종료하기 전에 시스템 프록시를 원래대로 복원하면 운영체제에 이미 작동하지 않는 로컬 주소가 남는 일을 방지할 수 있습니다. 일부 명령줄 도구는 시스템 프록시를 읽지 않으므로 환경 변수를 별도로 설정하거나 TUN을 사용해야 합니다. 이는 서버 장애가 아니라 앱의 연결 방식이 다른 것입니다.
inbound: local socks/http · scope: system-aware applications
VIRTUAL INTERFACE / ROUTE
TUN은 가상 네트워크 인터페이스로 트래픽을 받아 게임 런처, 명령줄 프로그램과 시스템 프록시 설정을 따르지 않는 앱까지 처리할 수 있습니다. 시스템 프록시보다 적용 범위가 넓지만 가상 네트워크 어댑터, 라우팅 테이블, DNS와 권한 설정에 의존합니다. 활성화하기 전에 가상 네트워크 인터페이스를 만드는 다른 도구를 종료하고, 클라이언트에 네트워크 설정을 변경할 권한이 있는지 확인하세요. 활성화 후 로컬 네트워크 접속에 문제가 생기면 먼저 사설 주소 우회 규칙을 점검하세요.
TUN을 사용한다고 모든 연결이 하나의 출구로 전송되는 것은 아닙니다. 최종적으로 직접 연결할지, 프록시를 사용할지, 차단할지는 라우팅 규칙이 결정합니다. 문제를 분석할 때는 ‘트래픽이 클라이언트에 들어왔는가’와 ‘들어온 뒤 어떤 규칙이 적용되었는가’를 구분해야 합니다.
capture: virtual interface · decision: routing rules · dns: coordinated
RULESET / OUTBOUND
라우팅 규칙은 도메인, 주소, 포트, 프로토콜 또는 프로세스 등의 조건에 따라 출구를 선택합니다. 일반적으로 로컬 네트워크와 로컬 서비스를 직접 연결하고, 특정 네트워크 요청은 프록시로 보내며, 불필요한 연결은 차단합니다. 규칙은 보통 위에서 아래 순서로 적용되므로 더 구체적인 조건을 일반적인 조건보다 앞에 배치해야 합니다. 수정 후에는 클라이언트 연결 여부만 보지 말고 대상 요청에 실제로 어떤 규칙이 적용되었는지 확인하세요.
사전 설정 규칙은 기본 구조를 잡는 데 유용하지만, 장기간 사용하려면 direct, proxy, block 세 출구의 의미를 이해해야 합니다. 규칙이 많다고 결과가 더 정확해지는 것은 아닙니다. 중복 조건, 순서 충돌과 지나치게 넓은 매칭은 오히려 문제 분석을 어렵게 합니다.
match: domain / ip / port / process · outbound: direct / proxy / block
EVENT / DIAGNOSIS
로그는 문제가 발생한 지점을 판단하는 가장 중요한 근거입니다. 커널이 시작되지 않으면 먼저 설정 파싱 실패, 누락된 필드와 포트 사용 여부를 확인하세요. 시작은 되지만 연결이 성립하지 않을 때는 도메인 확인, TLS 핸드셰이크, 시간 초과와 라우팅 매칭 정보를 살펴보세요. 오류가 발생한 시간과 실행한 동작을 기록하면 시작 단계의 문제와 특정 대상에 접근할 때의 문제를 구분할 수 있어, 여러 설정을 한꺼번에 변경한 뒤 무엇이 적용되었는지 모르는 상황을 피할 수 있습니다.
문제 분석은 로컬 수신, 시스템 연결, 규칙 매칭, 원격 연결 순서로 진행해야 합니다. 한 번에 하나의 변수만 바꾸고 변경 후 같은 요청을 다시 실행하세요. 무작정 재설치하는 것보다 이 순서가 기존의 정상 설정을 보존하면서 실제 장애 지점을 찾는 데 효과적입니다.
order: startup → inbound → dns → routing → outbound
QUICK START
처음 설정할 때는 과정을 단순하게 유지하세요. 올바른 설치 패키지를 선택하고, 사용할 수 있는 설정을 가져온 뒤, 시스템 프록시로 기본 연결을 한 번 확인합니다. 기본 경로가 확인된 후 TUN과 복잡한 라우팅을 설정하세요.
Windows, macOS와 Linux에서는 v2rayN을 사용하고, Android에서는 v2rayNG 또는 v2flyNG를 선택할 수 있습니다. 다운로드 전에 프로세서 아키텍처와 설치 패키지 형식을 확인하세요. 데스크톱에서는 현재 계정에 설정 폴더 쓰기 권한이 있고 클라이언트가 로컬 수신 포트를 만들 수 있는지도 확인해야 합니다. 설치가 끝나면 방화벽, DNS와 라우팅을 동시에 변경하지 말고 먼저 정상적으로 한 번 실행해 기본 화면이 표시되는지 확인하세요.
구독 관리에서 전체 주소를 입력하고 출처를 쉽게 알아볼 수 있는 그룹 이름을 지정한 다음 업데이트를 실행하세요. 서버 목록이 나타나면 항목 하나를 선택해 활성 서버로 설정합니다. 이때 프로토콜, 주소, 포트와 전송 필드가 정상적으로 해석되었는지 확인해야 합니다. 구독 주소는 설정을 전달하고 클라이언트는 이를 읽어 실행합니다. 업데이트에 실패했다면 커널을 사용할 수 없다고 단정하지 말고 먼저 구독 작업 로그를 확인하세요.
먼저 커널을 시작하고 시스템 프록시를 활성화한 다음, 시스템 프록시 설정을 따르는 브라우저에서 테스트 요청을 보내세요. 접속할 수 없다면 로컬 포트, 시스템 프록시, DNS, 라우팅 규칙, 원격 연결 순서로 확인합니다. 기본 모드 검증에 성공한 뒤 앱 적용 범위에 따라 TUN을 활성화할지 결정하세요. 이렇게 하면 가상 네트워크 어댑터 문제와 서버 설정 문제를 분리해 서로의 영향을 줄일 수 있습니다.
OPEN ECOSYSTEM
클라이언트, 커널과 설정 출처는 서로 다른 세 계층의 구성 요소입니다. 각자의 경계를 이해해야 업데이트, 호환성 및 장애가 어느 계층에서 발생했는지 정확히 판단할 수 있습니다.
Project V는 프록시 프로토콜, 전송 방식, 라우팅 규칙과 로컬 인바운드를 중심으로 한 도구 생태계를 형성했습니다. 그래픽 클라이언트는 프로토콜 자체가 아닙니다. 구독, 서버 목록, 시스템 프록시, 라우팅과 로그를 조작 가능한 화면으로 정리한 뒤 생성된 설정을 커널에 전달해 실행합니다. 화면에서 서버를 선택하거나 모드를 전환할 때 실제로는 클라이언트가 설정을 다시 구성하고 커널 프로세스를 제어하는 것입니다.
이 구분은 문제 분석 방식에 직접 영향을 줍니다. 구독 업데이트 실패는 대개 설정 출처 또는 클라이언트의 네트워크 요청 문제입니다. 커널이 시작 직후 종료된다면 설정 필드, 포트 또는 실행 환경과 관련된 경우가 많습니다. 특정 대상만 접속되지 않는다면 DNS, 라우팅 매칭, 전송 매개변수 또는 원격 상태일 가능성이 큽니다. 모든 현상을 ‘클라이언트가 고장 났다’고 부르면 실제 문제가 끊긴 지점을 찾기 어렵습니다.
V2Fly는 Project V 생태계의 핵심 구현과 설정 체계를 이어가고, Xray는 기존 개념과의 호환성을 유지하면서 일부 프로토콜, 전송 방식과 하위 기능을 확장했습니다. 두 커널 모두 인바운드, 아웃바운드, 라우팅, DNS와 정책 등의 구조로 설정을 구성하지만, 지원하는 필드와 동작은 구현에 따라 달라질 수 있습니다. 설정을 가져올 때 클라이언트는 구독 내용을 현재 커널이 인식할 수 있는 형식으로 변환해야 합니다.
v2rayN은 데스크톱 플랫폼에서 관련 커널과 설정 과정을 관리할 수 있고, v2rayNG는 주로 Xray 커널을 사용하며, v2flyNG는 V2Fly 커널에 대응합니다. 클라이언트를 선택할 때 그래픽 인터페이스와 커널을 하나로 생각할 필요는 없습니다. 인터페이스는 조작 방식을 결정하고, 커널은 설정 실행과 프로토콜 처리를 담당하며, 구독은 서버 매개변수를 제공합니다. 세 계층이 호환되어야 연결이 정상적으로 성립합니다.
세 클라이언트 모두 오픈 소스 방식으로 유지보수되며, 기능 변경, 설정 형식 조정과 문제 수정은 유지관리자와 커뮤니티가 계속 진행합니다. 오픈 소스의 실제 의미는 추상적인 보안 문구가 아니라 구현과 변경 사항을 기술 커뮤니티가 검토하고 논의하며 재현할 수 있다는 데 있습니다. 새 빌드를 설치한 뒤에도 변경 사항을 읽고 설정 폴더, 커널 선택, 권한 요구 사항과 시스템 프록시 동작이 달라졌는지 확인하세요.
클라이언트 업데이트와 구독 업데이트는 같은 작업이 아닙니다. 클라이언트 업데이트는 프로그램 자체와 지원 기능을 바꾸고, 구독 업데이트는 서버 설정만 새로 고칩니다. 프로토콜 필드를 인식하지 못한다면 구독 내용이 잘못된 것인지, 클라이언트의 파싱 기능이 부족한 것인지, 현재 커널이 해당 매개변수를 지원하지 않는 것인지 판단해야 합니다. 계층별로 확인하는 편이 모든 설정을 자주 삭제하는 것보다 훨씬 안정적입니다.
COMMON QUESTIONS
아래 내용은 처음 사용할 때 가장 혼동하기 쉬운 설정의 경계를 다룹니다. 전체 분류와 문제 해결 과정은 문제 해결 페이지에서 확인할 수 있습니다.
아닙니다. v2rayN은 구독, 서버 목록, 프록시 모드, 라우팅과 로그를 관리하는 그래픽 클라이언트이고, 커널은 설정을 해석해 실제 연결을 처리합니다. 클라이언트는 설정과 플랫폼에 따라 적절한 커널을 호출할 수 있으므로, 인터페이스가 정상적으로 시작되었다고 해서 커널까지 반드시 정상 실행 중인 것은 아닙니다. 연결 문제가 발생하면 기본 화면의 상태와 커널 로그를 함께 확인해야 합니다.
구독 업데이트는 원격 설정을 서버 목록으로 변환할 뿐, 현재 어떤 항목을 사용해야 할지 대신 판단하지는 않습니다. 업데이트가 끝나면 올바른 그룹에서 활성 서버를 선택한 뒤 커널을 시작해야 합니다. 자동 선택 정책을 제공하는 클라이언트라도 먼저 수동 연결을 한 번 검증해 설정이 정상적으로 실행되는지 확인하는 것이 좋습니다.
처음 설정할 때는 시스템 프록시부터 사용하는 것이 좋습니다. 적용 범위와 장애 경계를 더 쉽게 확인할 수 있기 때문입니다. 브라우저 같은 일반 앱의 연결을 확인한 뒤 명령줄 도구, 게임 또는 다른 앱의 필요에 따라 TUN을 활성화하세요. TUN은 가상 네트워크 인터페이스, 라우팅과 DNS를 사용하므로 문제가 발생하면 권한과 네트워크 인터페이스 충돌을 점검해야 합니다.
먼저 활성 서버를 선택했는지 확인한 다음 시스템 프록시가 켜져 있는지, 로컬 수신 포트가 존재하는지, 브라우저에 별도 프록시가 설정되어 있지 않은지 확인하세요. 이어서 DNS, 라우팅 적용 규칙과 원격 연결 로그를 살펴봅니다. 연결 경로에 따라 하나씩 확인하면 요청이 클라이언트에 들어오지 않은 경우, 잘못된 출구가 선택된 경우와 원격 연결에 실패한 경우를 구분할 수 있습니다.
TECHNICAL NOTES
글은 실제 조작 문제를 중심으로 구성했으며, 재현 가능한 점검 순서, 로그 키워드와 설정 경계를 중점적으로 기록합니다.
구독 주소의 출처, 커널의 역할, 시스템 프록시와 TUN의 차이, 서버 선택 및 트레이 상태 등 처음 사용할 때의 궁금증을 한곳에 정리하고, 각 항목에 바로 따라 할 수 있는 방법을 제시합니다.
전체 글 읽기 →포트 사용 여부, 설정 형식, 누락된 필드와 실행 권한부터 확인하고, 커널이 시작 직후 종료되는 문제를 로그 발생 순서에 따라 찾는 방법을 설명합니다.
전체 글 읽기 →여러 구독을 함께 사용할 때의 그룹 구성, 키워드 필터, 별칭 메모와 정렬 방법을 소개해 출처와 용도가 다른 서버를 명확하게 분리해 관리하도록 돕습니다.
전체 글 읽기 →