Windows
v2rayN으로 구독, 시스템 프록시, 라우팅 규칙과 TUN을 관리하세요. 다운로드 페이지에서 최신 데스크톱 인터페이스와 클래식 WPF 버전을 제공하므로 시스템 환경과 사용 방식에 맞춰 선택할 수 있습니다.
다운로드하기데스크톱 및 Android 클라이언트, 구독 가져오기 단계와 VMess, VLESS, REALITY 설정 안내를 한곳에 정리했습니다. 플랫폼별 메뉴에서 해당 항목을 찾은 뒤 시스템 프록시와 라우팅을 설정하세요.
핵심 기능
클라이언트는 구독, 프록시 프로토콜, 시스템 연결 지점과 분기 규칙을 하나로 관리합니다. 먼저 각 계층의 역할을 이해한 뒤 설정을 조정하면 노드를 계속 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다.
VMess와 VLESS는 주로 클라이언트와 서버 사이의 인증 및 연결 구조를 정의하며, TCP, WebSocket, gRPC 등은 전송 계층에 해당합니다. TLS와 REALITY는 보안 계층에 위치합니다. 클라이언트 화면에서는 이러한 설정이 하나의 편집 양식에 함께 표시되지만 서로 임의로 바꿔 사용할 수는 없습니다. 구독을 가져온 뒤에는 제공자가 지정한 프로토콜, 주소, 포트, 전송 방식과 보안 계층 설정을 우선 유지하고, 로컬에서 조정할 수 있는 시스템 프록시와 라우팅 모드만 선택하는 것이 일반적입니다.
직접 확인해야 할 때는 “프로토콜 유형—전송 방식—보안 계층—추가 식별자” 순서로 점검하세요. 그러면 구독 내용이 불완전한지 로컬 연결 지점이 활성화되지 않았는지 빠르게 구분할 수 있습니다. VLESS 자체가 특정 전송 방식을 의미하는 것은 아니며, REALITY도 독립 클라이언트가 아닙니다. 이러한 계층 관계를 이해하면 이름 하나만 바꾸고 관련 매개변수를 놓치는 일을 피할 수 있습니다.
라우팅 규칙은 각 연결을 프록시로 보낼지, 직접 연결할지, 차단할지를 결정합니다. 규칙은 도메인, 대상 주소, 포트와 네트워크 유형을 기준으로 매칭되며 클라이언트에 표시된 순서대로 적용됩니다. 일상적인 사용에서는 처음부터 긴 규칙 목록을 만들 필요가 없습니다. 먼저 클라이언트가 제공하는 기본 모드로 웹사이트와 앱 연결이 정상인지 확인한 뒤, 필요한 도메인만 사용자 지정 규칙에 추가하면 변경 범위를 명확하게 관리할 수 있습니다.
트래픽 분기 문제는 일부 웹사이트만 열리고 특정 앱은 연결되지 않거나, 시스템 프록시를 켠 뒤 로컬 서비스에 영향이 생기는 형태로 나타나는 경우가 많습니다. 문제를 찾을 때는 먼저 단순 모드로 전환해 비교하고, 도메인 확인 방식과 규칙 우선순위를 점검하세요. 라우팅은 “연결이 어디로 나가는가”를 정하는 기능이지 프로토콜 매개변수를 대신하거나 노드 회선 품질을 개선하는 기능은 아닙니다. 두 문제를 나누어 보면 불필요한 설정 변경을 줄일 수 있습니다.
시스템 프록시는 운영체제의 프록시 설정을 따르는 브라우저와 데스크톱 앱에 적합합니다. 클라이언트가 로컬에서 프록시 포트를 열고 시스템 설정이 해당 포트를 가리키도록 합니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 다양한 연결을 처리하므로 시스템 프록시 설정을 읽지 않는 프로그램에 유용합니다. 두 방식은 적용 범위가 다르며 동시에 켜야 작동하는 것이 아닙니다. 실제 사용하는 앱에 맞춰 하나를 주요 연결 지점으로 선택하세요.
처음 설정할 때는 시스템 프록시로 구독과 노드가 유효한지 먼저 확인한 다음 TUN이 필요한지 판단하는 것이 좋습니다. TUN을 켜기 전에는 같은 종류의 네트워크 도구를 종료하고, 권한 요청, DNS 처리 방식과 로컬 네트워크 접근 필요 여부를 확인하세요. 클라이언트를 종료할 때는 시스템 프록시가 복원되었는지도 점검해야 합니다. 연결이 순환하거나 모든 앱의 인터넷이 끊기면 원격 프로토콜을 바로 바꾸기보다 여러 프로그램이 동시에 트래픽을 가로채고 있는지 먼저 확인하세요.
구독 주소는 노드 목록과 연결 매개변수를 가져오는 데 사용됩니다. 가져온 후 클라이언트는 노드 목록을 로컬에 저장하고, 수동 또는 예약 업데이트 시 구독 내용을 다시 읽습니다. 노드 이름, 서버 주소와 프로토콜 매개변수는 대개 구독에서 관리되며, 라우팅 모드, 로컬 수신 포트, 시작 동작과 화면 설정은 클라이언트 설정에 속합니다. 둘을 구분해 두면 구독을 업데이트할 때 모든 로컬 옵션까지 덮어써진다고 오해하지 않게 됩니다.
구독 업데이트에 실패하면 먼저 주소가 처음부터 끝까지 정확히 복사되었는지, 시스템 시간이 올바른지 확인하고 현재 네트워크에서 구독 출처에 접근할 수 있는지 점검하세요. 업데이트는 성공했지만 목록이 비어 있다면 반환 형식이 사용 중인 클라이언트와 맞지 않을 수 있습니다. 수동으로 추가한 노드를 보존해야 한다면 별도 그룹을 만들어 구독 내용과 분리하세요. 클라이언트를 바꾸기 전에는 로컬 라우팅과 포트 설정을 기록한 뒤 새 클라이언트가 지원하는 방식으로 다시 가져오는 것이 좋습니다.
플랫폼 입구
데스크톱 플랫폼에서는 v2rayN을 사용하고, Android에서는 Xray 및 V2Fly 커널 클라이언트 중에서 선택할 수 있습니다. 다운로드 페이지에서는 프로세서 아키텍처와 설치 패키지 유형도 구분해 제공합니다.
v2rayN으로 구독, 시스템 프록시, 라우팅 규칙과 TUN을 관리하세요. 다운로드 페이지에서 최신 데스크톱 인터페이스와 클래식 WPF 버전을 제공하므로 시스템 환경과 사용 방식에 맞춰 선택할 수 있습니다.
다운로드하기v2rayN 데스크톱 버전은 크로스플랫폼 인터페이스를 사용하며, 하나의 앱에서 노드, 구독과 로컬 프록시를 관리합니다. 다운로드하기 전에 기기가 Apple Silicon인지 Intel 프로세서인지 확인해야 합니다.
다운로드하기v2rayNG는 Xray 커널을 사용하며 VLESS, REALITY 등의 기능이 필요한 설정에 적합합니다. v2flyNG는 V2Fly 커널을 사용하므로 해당 생태계의 클라이언트로 선택할 수 있습니다. 다운로드 페이지에서는 arm64 및 범용 패키지를 제공합니다.
다운로드하기v2rayN 데스크톱 버전은 주요 Linux 데스크톱 환경을 지원합니다. 다운로드 페이지에서 deb, rpm 및 프로세서 아키텍처별 항목을 제공하므로 그래픽 인터페이스로 구독과 라우팅을 관리하려는 사용자에게 적합합니다.
다운로드하기빠른 시작
처음에는 설정을 단순하게 유지하세요. 재현 가능한 연결 과정을 하나 완성한 뒤 자동 시작, TUN과 사용자 지정 라우팅을 조정하는 것이 좋습니다.
Windows, macOS 및 Linux에서는 v2rayN을 선택하고, Android에서는 먼저 v2rayNG를 확인하거나 커널 요구 사항에 따라 v2flyNG를 선택할 수 있습니다. 데스크톱 설치 패키지는 운영체제와 프로세서 아키텍처에 맞아야 하며, Android 기기에서는 arm64와 범용 패키지 중에서 선택합니다. 설치가 끝나면 클라이언트를 정상적으로 실행하고 기본 화면, 트레이 메뉴 또는 시스템 상태 영역을 사용할 수 있는지 확인한 뒤 설정을 가져오세요.
구독 관리에서 주소를 추가하고 저장한 다음 수동 업데이트를 한 번 실행하세요. 노드가 표시되면 프로토콜, 전송 방식과 보안 계층 매개변수는 먼저 변경하지 마세요. 일반적으로 구독에서 이미 제공되는 값이기 때문입니다. 노드 하나를 선택해 연결을 테스트하고 클라이언트 로그에 주소 확인, 인증 또는 시간 초과 메시지가 나타나는지 살펴보세요. 목록이 비어 있다면 프록시 모드를 계속 바꾸기보다 구독 주소와 시스템 시간을 먼저 확인해야 합니다.
데스크톱에서는 먼저 시스템 프록시를 활성화하고, 모바일에서는 시스템 안내에 따라 연결을 설정할 수 있습니다. 브라우저와 자주 사용하는 앱을 열어 확인하면서 로컬 웹사이트, 네트워크 기기와 업무용 프로그램이 예상대로 작동하는지도 점검하세요. 기본 연결이 안정된 후 TUN, 부팅 시 시작, 예약 구독 업데이트 또는 사용자 지정 라우팅을 사용할지 결정하세요. 한 번에 한 종류의 설정만 바꾸면 변화가 어느 계층에서 발생했는지 쉽게 파악할 수 있습니다.
오픈 소스 생태계
클라이언트, 커널과 프로토콜은 서로 다른 계층에 속합니다. 이들 사이의 관계를 이해하면 앱을 선택하기 쉽고 문제를 구체적인 구성 요소까지 좁혀서 해결할 수 있습니다.
프록시 프로토콜, 전송 방식, 라우팅 기능과 클라이언트 도구를 중심으로 형성된 오픈 소스 기술 생태계입니다.
VMess, VLESS, 라우팅과 다양한 전송 기능을 유지하며, 관련 설정 개념은 여러 클라이언트에서 계속 활용되고 있습니다.
유사한 설정 체계를 바탕으로 새로운 프로토콜 조합과 전송 특성을 계속 추가하며, v2rayN 및 v2rayNG와 함께 사용되는 경우가 많습니다.
V2Ray는 처음에 Project V 체계의 핵심 구성 요소로 널리 알려졌고, 이후 커뮤니티의 유지보수 방향이 V2Fly와 Xray라는 두 주요 커널 계열로 발전했습니다. 오늘날 “V2Ray 클라이언트”는 보통 하나의 특정 프로그램이 아니라 이러한 커널, 구독과 프로토콜 설정을 관리할 수 있는 그래픽 앱을 뜻합니다. v2rayN, v2rayNG와 v2flyNG는 모두 클라이언트 계층에 있으며 화면, 설정 관리와 시스템 연동을 담당하고, 실제 연결과 라우팅은 내부에서 사용하는 커널이 처리합니다.
이러한 계층 구조는 서로 다른 클라이언트에서 비슷한 프로토콜 필드가 보이는 이유도 설명해 줍니다. VMess, VLESS, 전송 방식, TLS, REALITY와 라우팅 규칙은 커널 설정 체계에서 비롯되며, 클라이언트는 이를 데스크톱이나 모바일 환경에 맞게 표시할 뿐입니다. 연결 문제가 발생하면 앱 화면, 시스템 권한, 커널 시작, 구독 내용과 원격 연결 중 어느 계층의 문제인지 먼저 판단해야 하며, 앱 이름만으로 원인을 추측해서는 안 됩니다.
V2Fly와 Xray는 서로 유사한 설정 개념을 많이 유지하므로 기본적인 VMess, VLESS, 아웃바운드, 인바운드와 라우팅 규칙은 이해 방식이 상당 부분 통합니다. 그러나 두 커널의 기능 범위와 세부 필드가 항상 같은 것은 아닙니다. Xray에서 사용할 수 있는 전송 기능이라고 해서 동일한 설정을 V2Fly에 바로 적용할 수 있는 것은 아니며, 구독 변환 과정에서 클라이언트가 인식하지 못하는 매개변수가 생략될 수도 있습니다.
커널을 선택할 때는 구독에 실제로 포함된 프로토콜과 보안 계층을 기준으로 결정하는 것이 가장 안전합니다. REALITY 또는 특정 XTLS 조합이 필요하다면 일반적으로 Xray 커널을 사용하는 클라이언트를 선택하고, 설정이 V2Fly를 명확히 대상으로 한다면 해당 커널을 사용하는 편이 직접적입니다. 더 많은 설정 항목을 사용하려고 설정을 무리하게 변환하지 마세요. 화면에 옵션이 얼마나 많이 표시되는지보다 기능 호환성, 읽기 쉬운 로그와 안정적인 업데이트가 더 중요합니다.
이 프로젝트들은 오픈 소스 방식으로 커뮤니티가 유지보수하며, 소프트웨어 동작, 설정 구조와 변경 기록을 개발자가 검토할 수 있습니다. 오픈 소스의 가치는 기술적 과정을 논의하고 구현을 재검토할 수 있으며, 여러 클라이언트가 유사한 설정 형식을 바탕으로 협력할 수 있다는 데 있습니다. 그렇다고 사용자의 설정 판단을 대신하지는 않습니다. 구독 출처, 서버 구성, 시스템 환경과 로컬 라우팅은 여전히 연결 결과에 직접 영향을 줍니다.
클라이언트는 무료로 사용할 수 있으며 프로토콜과 커널 문서도 커뮤니티에 의해 장기간 축적되어 왔습니다. 일반 사용자는 안정적인 클라이언트 경로에서 시작하고 앱과 커널을 동일한 유지보수 체계 안에서 관리하며, 문제가 생기면 로그를 읽고 해당 프로토콜 문서를 확인하는 것이 현실적입니다. 개발자에게는 명확한 설정 모델과 검토 가능한 구현이 호환성 차이를 찾고 문제를 관련 구성 요소에 정확히 전달하는 데 도움이 됩니다.
v2rayN은 Windows, macOS 및 Linux 데스크톱 환경을 대상으로 구독, 노드, 커널, 시스템 프록시와 라우팅을 통합 관리합니다. v2rayNG는 Android용이며 Xray 커널 기능을 주요 방향으로 합니다. v2flyNG 역시 Android용이지만 V2Fly 커널 생태계에 대응합니다. 세 클라이언트는 서로 다른 플랫폼과 커널 선택 문제를 해결하므로 같은 기기에서 유사한 클라이언트를 여러 개 동시에 실행할 필요는 없습니다.
클라이언트 업데이트와 커널 업데이트는 서로 다른 주기로 진행될 수 있습니다. 화면 기능, 시스템 호환성과 설치 방식은 클라이언트 유지보수 범위에 속하고, 프로토콜 지원, 전송 구현과 라우팅 동작은 커널에 더 크게 좌우됩니다. 업데이트 후 차이가 생기면 먼저 어느 계층에서 변화가 발생했는지 확인한 뒤 설정 마이그레이션 상태를 살펴보세요. 구독 주소, 자주 사용하는 라우팅 방식과 로컬 포트 기록을 보관하면 클라이언트를 더 체계적으로 옮길 수 있습니다.
기술 노트
연결 구조와 작업 순서를 바탕으로 자주 발생하는 문제를 설명합니다. 프로토콜 원리, 클라이언트 설정과 문제 원인 파악을 중심으로 내용을 구성했습니다.
TLS 핸드셰이크 계층에서 REALITY의 연결 방식을 이해한 뒤, XTLS Vision이 전달 경로에서 반복 처리를 줄이는 원리와 이 설정 조합에 적합한 연결 조건을 설명합니다.
전체 글 읽기실행 환경 준비, 최초 실행 점검, 시스템 프록시와 포트 설정을 다루고 커널 알림, 자동 시작과 브라우저 연결 문제를 처리하는 순서도 설명합니다.
전체 글 읽기속도 문제를 노드 응답, 회선 사용 시간대와 로컬 설정의 세 계층으로 나누고, 지연 시간 결과, 프로토콜 변경, Mux와 트래픽 분기 규칙이 각각 무엇을 보여 주는지 설명합니다.
전체 글 읽기자주 묻는 질문
대부분의 최초 연결 문제는 구독 내용, 시스템 시간, 로컬 연결 지점, 노드 상태와 라우팅 규칙을 정해진 순서대로 확인하면 원인을 찾을 수 있습니다.
Windows, macOS 및 Linux 데스크톱 환경에서는 v2rayN을, Android에서는 v2rayNG를 선택하세요. 두 클라이언트는 화면과 시스템 연동 방식은 다르지만 구독, 노드, 프록시 프로토콜과 라우팅 규칙을 중심으로 작동합니다. 데스크톱 클라이언트 설치 패키지를 모바일 기기에 사용하거나 한 플랫폼의 화면 안내를 다른 플랫폼에 그대로 적용하지 마세요.
먼저 수동 업데이트를 한 번 실행하고 구독 주소가 처음부터 끝까지 정확히 복사되었는지 확인한 다음 시스템 날짜, 시간과 시간대를 점검하세요. 업데이트 과정에서 오류가 없었는데도 목록이 비어 있다면 반환된 내용이 현재 클라이언트가 지원하는 구독 형식인지 확인해야 합니다. 구독을 다시 추가하기 전 주소 양끝에 실수로 들어간 공백을 삭제해 보세요.
시스템 프록시는 시스템 프록시 설정을 읽는 앱에 주로 영향을 주며 설정이 간단해 최초 확인에 적합합니다. TUN은 가상 네트워크 인터페이스를 통해 더 폭넓은 연결을 인계하므로 적용 범위가 넓지만 시스템 권한, DNS 설정과 다른 네트워크 도구의 상태에 더 크게 의존합니다. 먼저 시스템 프록시로 노드가 유효한지 확인한 뒤 앱 사용 목적에 따라 TUN을 활성화하세요.
지연 시간 결과는 특정 탐지 방식이 응답을 받았다는 뜻일 뿐 전체 웹 연결이 성공했다는 의미는 아닙니다. 현재 노드가 선택되어 있는지, 시스템 프록시가 적용되었는지, 브라우저가 별도 프록시를 사용하는지, DNS가 올바르게 확인되는지, 라우팅 규칙이 대상 연결을 예상한 출구로 보내는지 계속 점검하세요. 자세한 절차는 빠른 시작 가이드에서 확인할 수 있습니다.