데스크톱에서는 v2rayN, Android 기기에서는 v2rayNG를 우선 확인하세요. 먼저 운영체제와 CPU 아키텍처를 확인한 뒤 설치 패키지를 선택해야 합니다. 패키지 형식은 설치 방법을, 코어는 지원하는 프로토콜과 전송 방식을 결정하므로 각각 따로 확인하세요.
처음 설정할 때는 일반 시스템 프록시부터 시작하는 것이 좋습니다. 기존 구독을 가져오고 서버 항목을 하나 선택한 다음 코어가 실행되는지 확인하고, 앱 요청이 클라이언트를 통과하는지 테스트하세요. 기본 연결이 정상인 것을 확인한 뒤 규칙과 DNS를 하나씩 조정하면 여러 설정을 동시에 바꿔 원인을 찾기 어려워지는 일을 막을 수 있습니다.
클라이언트 다운로드와 연결 설정은 별개의 단계입니다. 클라이언트를 설치해도 사용할 수 있는 서버 항목이 자동으로 만들어지지는 않습니다. 구독 주소, 노드 매개변수, 인증 정보는 사용자가 이미 보유한 서비스 설정에서 제공해야 합니다. 여기에 표시된 예시 주소는 입력란의 위치를 설명하기 위한 것으로 실제 연결에는 사용할 수 없습니다.
데스크톱 버전은 크로스 플랫폼 인터페이스를 제공하고, 클래식 WPF 버전은 익숙한 Windows 조작 방식을 유지합니다. 두 버전 모두 서버 목록, 구독 그룹, 연결 설정을 관리합니다. 선택할 때는 시스템 요구 사항과 사용 습관을 먼저 고려하세요. 인터페이스 차이 때문에 구독을 새로 만들 필요는 없습니다.
설치 후에는 먼저 로컬 수신 포트를 확인한 다음 시스템 프록시를 설정하세요. 브라우저는 접속되는데 특정 앱만 연결되지 않는다면 해당 앱이 시스템 프록시를 사용하는지, 자체 프록시 설정이 있는지 확인하세요. 노드를 계속 바꾸기보다 트래픽이 어디로 들어가는지 먼저 찾는 편이 효과적입니다.
TUN을 사용하기 전에 관리자 권한과 다른 네트워크 도구를 확인하세요. 클라이언트를 종료한 뒤에도 시스템 네트워크 동작이 복구되지 않으면 시스템 프록시가 중지된 로컬 포트를 계속 가리키는지 확인하세요.
기기 칩에 따라 Apple Silicon 또는 Intel 설치 항목을 선택하세요. 시스템의 기기 정보에서 칩 이름을 확인할 수 있습니다. Apple Silicon은 arm64, Intel은 x64에 해당합니다. 아키텍처를 올바르게 선택하면 호환성 계층에 따른 변수를 줄이고 다운로드 페이지 안내에 따라 실행 문제를 해결하기도 쉬워집니다.
클라이언트를 실행한 뒤에는 현재 네트워크 서비스의 프록시 설정을 별도로 확인해야 합니다. 무선 네트워크를 바꾸거나 외장 네트워크 어댑터를 사용하거나 다른 네트워크 도구에 연결하면 활성 네트워크 서비스가 달라질 수 있습니다. 클라이언트 버튼 상태만 보고 모든 앱이 프록시를 사용한다고 판단하지 마세요.
시스템 보안 경고가 표시되면 먼저 설치 패키지의 출처와 경고 내용을 확인하고 다운로드 페이지의 안내에 따라 처리하세요. 프로그램 하나를 실행하기 위해 시스템 보안 기능 전체를 끄지 마세요.
v2rayNG는 Xray 코어를 사용하며 일반적인 Android 구독 가져오기와 연결 관리에 적합합니다. v2flyNG는 V2Fly 코어를 사용하는 대안으로, 적합성은 클라이언트 이름이 비슷한지가 아니라 기존 노드 설정에 따라 달라집니다. 다운로드 페이지에서 이 순서대로 다운로드 경로를 제공합니다.
대부분의 최신 기기는 arm64를 사용합니다. 아키텍처를 모르겠다면 시스템 정보를 확인하거나 범용 패키지를 선택하세요. 구독을 가져온 뒤 처음 실행할 때 시스템의 VPN 연결 요청을 허용해야 합니다. 이는 클라이언트가 앱 트래픽을 처리하기 위한 시스템 진입점으로, 데스크톱 시스템 프록시와는 작동 방식이 다릅니다.
화면을 잠근 뒤 연결이 끊기면 배터리 최적화와 백그라운드 실행 제한을 먼저 확인하세요. 같은 VPN 연결 진입점을 사용하는 다른 앱이 있는지도 확인한 뒤 백그라운드에서 앱이 종료된 것인지 서버 연결에 실패한 것인지 구분하세요.
배포판의 패키지 관리 방식에 따라 deb 또는 rpm을 선택한 뒤 x64와 arm64도 구분하세요. 그래픽 데스크톱 환경, 시스템 의존성, 네트워크 권한에 따라 사용 방법이 달라질 수 있습니다. 설치 후에는 먼저 인터페이스가 정상적으로 실행되고 코어가 로드되는지 확인한 다음 트래픽 처리 방식을 조정하세요.
데스크톱 환경의 시스템 프록시 설정을 모든 프로그램이 읽는 것은 아닙니다. 일부 앱은 로컬 HTTP 또는 SOCKS 주소를 직접 지정해야 합니다. 브라우저는 정상인데 다른 프로그램이 작동하지 않는다면 앱 자체의 프록시 설정부터 확인하세요.
TUN은 가상 네트워크 어댑터, 라우팅 테이블, 권한을 사용합니다. 컨테이너 네트워크, 가상 머신 네트워크 또는 다른 터널 도구를 사용하는 기기라면 기존 설정을 기록해 두고, 변경할 때마다 로컬 네트워크와 기본 경로가 예상대로 유지되는지 확인하세요.
먼저 주요 필드를 확인한 다음 설정이 미치는 영향을 살펴보세요. 아래는 일부 예시이며 클라이언트 설정 파일 전체를 그대로 대체할 수는 없습니다. 그래픽 인터페이스의 필드 이름은 플랫폼과 코어에 따라 달라질 수 있으니 실제 로그와 생성된 결과를 함께 확인하세요.
메모: 일상 구독
주소: https://example.com/sub?token=xxxx
업데이트 사용: 예
필터 키워드:홍콩|일본
구독 그룹은 주소, 메모, 업데이트 동작을 한곳에서 관리하므로 여러 구독 출처를 정리하기에 편리합니다. 먼저 그룹 이름을 지정하고 주소를 가져와 업데이트한 뒤 서버 항목이 원하는 그룹에 추가되었는지 확인하세요. 필터 키워드는 정규식을 지원하지만 결과는 노드 이름에 따라 달라집니다. 범위를 너무 좁게 설정하면 업데이트 후 목록이 비어 보일 수 있습니다. 노드를 하나씩 직접 추가하는 것보다 그룹 업데이트는 구독 출처의 변경 사항을 반영하기 쉽지만 수동 수정 내용을 덮어쓸 수도 있습니다. 오래 유지해야 하는 사용자 지정 항목은 따로 관리하고 업데이트 전에 영향 범위를 확인하세요.
라우팅 규칙은 트래픽을 직접 연결, 프록시, 차단 아웃바운드로 분배하며 서버 대역폭을 높이지는 않습니다. 규칙은 보통 위에서 아래로 검사하므로 구체적인 조건을 포괄적인 조건보다 앞에 배치해야 합니다. 예시에서는 리소스 파일에 광고 도메인 목록이 포함되어 있고 설정에 해당 아웃바운드 태그가 있다는 전제하에 광고 도메인을 차단 아웃바운드로 보냅니다. 모든 트래픽을 같은 경로로 보내는 대신 도메인과 주소에 따라 분기하면 로컬 접속을 유지하기 쉽습니다. 설정을 바꾼 뒤에는 웹페이지가 열리는지만으로 규칙을 판단하지 말고 로그에서 실제로 어떤 규칙이 적용되었는지 확인하세요.
DNS를 설정할 때는 DNS 서버와 DNS 요청이 나가는 경로를 함께 고려해야 합니다. 원격 DNS는 일반적으로 프록시 아웃바운드와 함께 사용하고, 직접 연결 트래픽에는 적절한 결과를 반환하는 DNS 방식을 사용해야 합니다. 예시의 도메인 정책은 라우팅 판단에 쓰이며 모든 요청이 즉시 IP 주소로 해석된다는 뜻은 아닙니다. 시스템 DNS만 바꾸는 것보다 코어 DNS가 트래픽 분기 로직에 가깝지만, 앱이 직접 DNS 조회를 하는지도 확인해야 합니다. 문제를 해결할 때는 도메인 조회 실패, DNS 서버에 연결할 수 없는 경우, 반환된 주소에 연결할 수 없는 경우를 먼저 구분한 뒤 설정을 변경하세요.
TUN 사용:예
시스템 프록시: 시스템 프록시 해제
스택: gvisor
권한: 관리자 권한
TUN은 가상 네트워크 인터페이스로 트래픽을 받아 시스템 프록시를 사용하지 않는 앱을 처리할 수 있습니다. 바뀌는 것은 트래픽 진입 경로이며 노드 매개변수나 DNS 문제를 자동으로 해결하지는 않습니다. 사용하기 전에 일반 프록시 연결이 정상인지 확인하고 관리자 권한, 네트워크 스택, 기존 가상 네트워크 어댑터를 점검하세요. 시스템 프록시보다 더 많은 트래픽을 처리하는 만큼 라우팅 충돌과 로컬 네트워크 접속에 유의해야 합니다. 사용 후 문제가 생기면 TUN을 꺼서 기본 상태로 되돌리고 로그를 보관한 뒤 설정을 하나씩 테스트하세요. 노드와 규칙을 동시에 바꾸지 마세요.
멀티 코어 선택은 프로토콜, 전송 방식, 설정 필드에 맞추기 위한 것으로 같은 노드에 적용하는 범용 속도 향상 옵션이 아닙니다. 호환성을 판단할 때는 프로토콜 이름뿐 아니라 전송 방식과 보안 계층도 함께 확인해야 합니다. VLESS라는 이유만으로 모든 코어에서 처리할 수 있다고 단정하지 마세요. 예시에는 아웃바운드 프로토콜만 표시되어 있으며 실제 연결에는 완전한 서버 매개변수가 필요합니다. 그래픽 클라이언트를 바꾸는 것보다 코어의 지원 범위를 확인하는 편이 실행 오류를 직접적으로 찾는 데 도움이 됩니다. 전환 전에 작동하는 설정을 저장하고, 전환 후 로그를 다시 확인해 대상 코어가 설정을 올바르게 불러왔는지 확인하세요.
각 설정은 서로 연결되어 있습니다. 구독에서 서버 항목을 가져오고, 코어가 연결 매개변수를 불러오며, 라우팅이 아웃바운드를 결정하고, DNS가 도메인 주소를 조회합니다. 시스템 프록시나 TUN은 앱 트래픽이 클라이언트로 들어오는 방식을 정합니다. 문제를 해결할 때 이 흐름을 따라 점검하면 모든 설정을 한꺼번에 초기화하는 것보다 유효한 정보를 보존하기 쉽습니다.
설정 예시를 읽을 때는 클라이언트 옵션과 코어 필드도 구분해야 합니다. 구독 메모와 필터 키워드는 설정 관리 항목이며, 라우팅 규칙과 DNS 예시는 클라이언트가 생성하거나 코어에 전달합니다. 화면에 표시된 문구를 JSON 필드로 그대로 사용하면 설정을 파싱하지 못할 수 있습니다. 전체 설정 과정을 확인하려면 심화 설정 가이드를 읽어보세요.
클라이언트와 코어
Project V 오픈소스 생태계
V2Ray는 Project V 생태계의 네트워크 프록시 도구로, 프로토콜 처리와 전송, 라우팅을 담당합니다. 일상적으로 사용하는 v2rayN·v2rayNG·v2flyNG는 코어를 조작할 수 있는 인터페이스를 제공하는 클라이언트입니다. 서버 매개변수, 구독 업데이트, 실행 제어를 한곳에서 관리해 설정을 모두 직접 편집하지 않아도 됩니다.
이러한 역할 분리는 자주 발생하는 현상을 설명해 줍니다. 클라이언트가 정상적으로 열려도 코어 실행에는 실패할 수 있습니다. 그래픽 인터페이스는 설정을 관리하고 코어는 설정을 읽어 연결을 수립하므로 두 구성 요소의 실행 상태는 서로 대신할 수 없습니다. 오류가 발생하면 인터페이스, 설정 생성, 코어 출력 중 어디에서 문제가 생겼는지 먼저 확인한 뒤 노드 매개변수를 조정하세요.
V2Fly와 Xray: 공통 기반, 세부 사항은 각각 확인
V2Fly는 V2Ray 커뮤니티의 유지보수를 이어가고, Xray는 관련 코드 기반에서 별도의 코어 분기로 발전했습니다. 두 코어는 일부 개념과 사용 방식이 같지만 프로토콜 기능, 전송 지원, 설정 세부 사항은 항상 일치하지 않습니다. V2Ray 코어의 차이를 살펴볼 때는 전체 생태계를 서로 바꿔 쓸 수 있는 하나의 프로그램처럼 보기보다 구체적인 필드와 기능을 확인해야 합니다.
노드 이름은 메모일 뿐 연결에 필요한 조건을 모두 나타내지 않습니다. VLESS 설정을 예로 들면 전송 방식, TLS 또는 REALITY 같은 보안 계층 설정, 관련 매개변수가 서버 설정과 일치하는지도 확인해야 합니다. 클라이언트를 선택하기 전에 현재 설정에 필요한 코어 기능을 알아보세요. 기존 연결이 안정적으로 작동한다면 다른 분기의 이름이 더 새롭다는 이유만으로 바로 옮길 필요는 없습니다.
세 가지 클라이언트: 플랫폼과 설정 요구 사항을 따로 고려
v2rayN은 데스크톱용으로 서버 목록, 구독 그룹, 라우팅 관리, 멀티 코어 설정을 제공하며 그래픽 인터페이스에서 연결을 한곳에 정리하려는 사용자에게 적합합니다. 크로스 플랫폼 인터페이스를 통해 데스크톱 기기 간 사용 방식은 비슷하지만 시스템 프록시, 권한, 네트워크 어댑터 처리는 운영체제마다 다릅니다. 모든 플랫폼에서 동작이 같다고 가정하지 마세요.
v2rayNG는 Android용으로 Xray 코어를 사용해 연결을 처리하고 시스템 VPN 인터페이스를 통해 앱 트래픽을 받습니다. 주요 사용 항목은 구독 가져오기, 활성 노드 선택, 앱별 트래픽 분기, 백그라운드 실행 제한입니다. v2flyNG도 Android용이지만 V2Fly 코어를 사용합니다. 해당 코어가 지원하는 설정에 맞는 대안이며 모든 노드를 다른 프로토콜로 바꾸는 도구는 아닙니다.
세 클라이언트는 모두 오픈소스 프로젝트로 유지보수됩니다. 오픈소스는 코드를 검토하고 변경 사항을 논의할 수 있다는 뜻이며 무료 사용 여부와 서버 리소스는 별개의 문제입니다. 클라이언트 자체는 구독 서비스를 제공하지 않으며 서버 회선 품질도 결정하지 않습니다. 속도, 데이터 한도, 노드 지역 문제가 발생하면 클라이언트 설정과 기존 서비스 설정을 각각 확인해야 합니다.
오픈소스 라이선스: 코드 사용 조건
오픈소스 라이선스는 코드를 사용, 수정, 배포하는 조건을 정합니다. V2Fly의 V2Ray 코어와 Xray 코어는 MPL 2.0을 사용하고, v2rayN·v2rayNG·v2flyNG 클라이언트는 GPL 계열 라이선스를 사용합니다. 클라이언트와 코어는 별도 프로젝트이므로 소프트웨어를 배포하거나 코드를 수정할 때는 관련 프로젝트의 라이선스를 각각 확인해야 합니다. 외부 클라이언트 이름만 참고해서는 안 됩니다.
일반 사용자에게 이 내용을 아는 실질적인 이유는 출처와 역할의 경계를 구분할 수 있다는 점입니다. 클라이언트는 커뮤니티가 유지보수하고 코어도 별도의 개발 일정에 따라 발전합니다. 이 사이트는 한국어 다운로드 및 설정 정보를 정리합니다. 문서의 예시는 설정의 의미를 설명하기 위한 것이며 특정 노드, 회선, 설정이 모든 환경에서 같은 결과를 낸다는 뜻은 아닙니다.
업데이트 순서: 기준 상태를 보존하고 변경 사항 확인
클라이언트 업데이트에는 인터페이스 변경, 설정 생성 로직, 함께 제공되는 구성 요소가 포함될 수 있고 코어 업데이트에는 프로토콜 처리와 필드 지원 변경이 포함될 수 있습니다. 두 요소는 서로 관련되어 있지만 완전히 동기화된 하나의 버전 체계는 아닙니다. 홈페이지에서는 선택과 사용 방법을 다루고, 구체적인 설치 경로와 최신 릴리스 정보는 다운로드 페이지에서 확인할 수 있습니다. 플랫폼과 패키지 형식도 한곳에서 비교할 수 있습니다.
업데이트 전에 현재 사용하는 코어, 활성 노드, 라우팅 방식, 로컬 수신 포트를 기록하고 필요한 설정을 저장하세요. 업데이트 후에는 이전에 작동하던 노드로 기본 연결을 먼저 테스트한 다음 구독 업데이트, 트래픽 분기, DNS를 확인하세요. 차이가 생기면 로그에서 가장 먼저 나타난 오류 줄을 찾아 설정 필드 변경, 권한 변경, 앱이 새 프록시 진입점을 사용하지 않는 경우 중 무엇인지 판단하세요.
한 번의 테스트에서 클라이언트, 코어, 서버를 모두 바꾸고 TUN까지 켜지 마세요. 변경 사항이 추가될 때마다 원인을 판단하기가 더 어려워집니다. 작동이 확인된 설정을 기준으로 보존하고 한 번에 하나만 바꾸면 문제를 더 쉽게 재현하고 정상 상태로 되돌릴 수 있습니다.
설정을 읽을 때 자주 찾는 네 가지 항목
구독 업데이트 실패. 먼저 주소가 잘리지 않았는지 확인한 다음 요청 로그의 상태와 응답 내용을 살펴보세요. 로컬에 노드가 있다면 가져오기 문제와 기존 연결의 작동 여부를 따로 테스트할 수 있습니다. 자세한 단계는 구독 업데이트 문제 해결을 참고하세요.
브라우저는 정상인데 다른 앱은 작동하지 않음. 먼저 앱이 어떤 프록시 진입점을 사용하는지 확인하세요. 시스템 프록시는 모든 네트워크 트래픽을 처리하는 스위치가 아닙니다. 더 많은 트래픽을 처리하려면 TUN 모드 안내에서 권한과 네트워크 스택을 확인하세요.
도메인은 실패하지만 주소로는 연결됨. DNS 요청 경로, 반환 결과, 라우팅 도메인 정책을 먼저 확인하세요. IP 주소로 접속할 수 있다고 모든 DNS 설정이 정상인 것은 아닙니다. DNS 설정 항목에서 이름 조회 실패와 연결 실패를 구분해 보세요.
프로토콜 이름은 같은데 가져오기에 실패함. 전송 방식, 보안 계층, 매개변수 형식을 추가로 확인하세요. 일부 정보는 링크에 포함되고 일부는 구독에서 생성되므로 이름이 같다고 설정까지 같은 것은 아닙니다. 먼저 VLESS 용어 설명을 읽고 코어 비교를 확인하세요.
설정 원리와 문제 해결 문서
빠른 시작 가이드는 작업 순서를 안내하고 주제별 문서는 네트워크 동작 원리를 설명합니다. 복잡한 문제를 찾을 때는 먼저 트래픽이 어느 단계에서 끊기는지 확인한 뒤 관련 문서를 선택하세요. 라우터 배포, 코어 호환성, 노드 속도 측정을 하나의 문제로 섞지 마세요.