SECTION 01 / 구성 살펴보기
그래픽 클라이언트는 연결 설정을 관리하고, 코어는 트래픽을 처리합니다. 링크 가져오기는 설정의 시작일 뿐입니다. 프로토콜 항목은 서버 연결 방식을 정하고, 프록시 모드는 앱 트래픽이 클라이언트로 전달될지 결정하며, 라우팅 규칙은 트래픽이 어떤 아웃바운드로 나갈지 정합니다. 이 세 단계를 나눠 확인하면 여러 옵션을 한꺼번에 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다.
v2rayN은 그래픽 인터페이스에서 서버 설정을 관리한 뒤 선택한 코어에 전달합니다. VMess, VLESS, Trojan, Shadowsocks는 설정 항목을 서로 바꿔 쓸 수 없습니다. 전송 방식과 TLS 설정도 서버와 일치해야 합니다. 링크를 가져온 뒤 프로토콜 유형, 주소, 포트, 보안 설정을 확인하고 코어가 해당 조합을 지원하는지 점검하세요. 전체 설정을 직접 편집하지 않아도 여러 연결을 저장할 수 있다는 점은 그래픽 관리의 장점이지만, 각 설정 항목의 제약까지 없어지는 것은 아닙니다. REALITY는 보안 전송 관련 설정이며, 독립된 프록시 프로토콜처럼 임의로 바꾸면 안 됩니다.
구독 주소는 여러 연결 설정을 가져오는 데 사용하고, 공유 링크는 보통 하나의 연결을 설명합니다. 지속적으로 관리할 설정이라면 구독 그룹에 주소를 저장하고 업데이트하세요. 단일 링크는 클립보드에서 가져오면 됩니다. base64는 인코딩 방식일 뿐, 클라이언트가 내부 내용을 반드시 인식한다는 뜻은 아닙니다. 원본 JSON과 공유 링크도 같지 않아 변환 과정에서 라우팅이나 DNS 설정이 누락될 수 있습니다. 업데이트 전에 대상 그룹을 확인하고, 완료 후 항목을 선택할 수 있는지 점검하세요. 네트워크 요청 한 번이 실패했다고 모든 연결이 끊긴 것으로 판단하지 마세요.
라우팅은 목적지에 따라 트래픽을 서로 다른 아웃바운드로 보냅니다. 일반적인 동작은 프록시, 직접 연결 또는 차단입니다. 규칙은 보통 위에서 아래 순서로 적용되므로, 구체적인 도메인 규칙을 포괄적인 규칙보다 앞에 두세요. geosite는 도메인 목록, geoip는 IP 주소 목록을 기준으로 하며 각 데이터 파일이 필요합니다. domainStrategy는 도메인 매칭 시 IP를 확인할지 제어하는 옵션이지, 시스템 DNS 전체를 켜고 끄는 설정이 아닙니다. 동작을 명확히 설명할 수 있는 프리셋부터 사용하고 예외 규칙을 하나씩 추가하면, 출처를 알 수 없는 규칙을 대량으로 복사하는 것보다 유지 관리와 문제 해결이 쉽습니다.
시스템 프록시는 운영체제 설정에 로컬 프록시 주소를 등록합니다. 이 설정을 읽는 앱만 프록시를 사용합니다. TUN 모드는 가상 네트워크 인터페이스로 트래픽을 처리해 적용 범위가 넓지만 권한, 라우팅, DNS 설정도 필요합니다. 처음에는 시스템 프록시부터 확인하고, 필요한 경우 TUN을 켜세요. 그래야 연결 설정 오류와 인터페이스 문제를 구분하기 쉽습니다. 다른 프록시 도구, 기존 가상 네트워크 어댑터, 앱 자체 프록시 설정도 결과에 영향을 줄 수 있습니다. 모드를 바꾼 뒤에는 스위치가 켜져 있는지만 보지 말고 대상 앱에서 다시 테스트하세요.
데스크톱에서는 v2rayN을, Android에서는 v2rayNG를 우선 살펴보세요. V2Fly 코어가 필요하다면 v2flyNG도 고려할 수 있습니다. 같은 공유 링크를 여러 기기에서 사용할 수 있는지는 각 코어가 프로토콜, 전송 방식, 보안 항목을 지원하는지에 따라 달라집니다. 링크의 접두어만으로 판단할 수 없습니다. 설치 전에 프로세서 아키텍처와 패키지 형식을 확인하고, 기기를 옮길 때는 구독 주소와 사용자 지정 규칙을 각각 저장하세요. 그래픽 인터페이스의 이름은 달라도 연결을 가져온 뒤 트래픽 진입 방식을 선택하고 라우팅 및 DNS 동작을 확인하는 기본 흐름은 같습니다.
SECTION 02 / 운영체제별 다운로드
설치 파일은 현재 기기에 맞아야 합니다. 데스크톱에서는 인터페이스 종류, 프로세서 아키텍처, 패키지 형식을 각각 선택해야 하며 파일 크기만으로 판단할 필요는 없습니다. 다운로드 페이지에서 각 클라이언트와 선택 방법을 한눈에 확인할 수 있습니다. 이 페이지의 운영체제 링크를 누르면 해당 항목으로 바로 이동합니다.
데스크톱에서는 v2rayN을 우선 추천합니다. Desktop은 새로운 크로스 플랫폼 인터페이스를 사용하고, 클래식 WPF 버전은 기존 데스크톱 인터페이스를 유지합니다. 익숙한 사용 방식에 맞춰 선택하세요. 화면 구성은 다를 수 있지만 연결 가져오기, 서버 선택, 시스템 프록시 설정의 기본 흐름은 비슷합니다.
설치 전에 운영체제 종류와 다운로드 패키지의 아키텍처를 확인하세요. 처음 실행한 뒤에는 코어가 정상적으로 작동하는지 점검하세요. 창은 열리지만 연결에 실패한다면 로그를 확인해야 합니다. 이 증상만으로 서버 설정이 잘못됐다고 단정할 수는 없습니다.
다운로드 페이지로 이동 Windows 클라이언트 →v2rayN을 선택하고 ‘이 Mac에 관하여’에서 칩 정보를 확인하세요. Apple Silicon과 Intel은 설치 파일이 다릅니다. 모든 디스크 이미지를 공용 패키지로 간주하지 말고 기기의 기본 아키텍처에 맞는 항목을 선택하세요.
시스템 프록시는 주로 운영체제의 네트워크 설정을 따르는 앱에서 사용합니다. 더 넓은 범위의 트래픽을 처리해야 한다면 TUN 설정 요건을 확인하세요. 권한 확인과 연결 설정은 별개의 단계입니다. 먼저 앱을 실행하고 연결을 가져온 뒤 앱의 네트워크 접속을 테스트하세요.
다운로드 페이지로 이동 macOS 클라이언트 →Xray 코어를 사용하는 v2rayNG를 우선 선택하세요. V2Fly 코어 설정이 필요하다면 v2flyNG를 고려할 수 있습니다. 대부분의 최신 기기에는 arm64 패키지가 적합합니다. 아키텍처를 모른다면 기기 정보를 확인한 뒤 다운로드 페이지의 범용 패키지 안내를 참고하세요.
처음 연결할 때는 시스템의 VPN 권한을 확인해야 합니다. 백그라운드 실행은 기기의 배터리 관리 정책에 영향을 받을 수도 있습니다. 화면을 잠근 뒤에만 연결이 끊긴다면 프로토콜을 바로 바꾸기보다 백그라운드 제한을 확인하세요. 네트워크를 전환한 뒤에도 연결을 다시 테스트해야 합니다.
다운로드 페이지로 이동 Android 클라이언트 →데스크톱 환경에서는 v2rayN을 선택할 수 있습니다. 먼저 배포판에 맞춰 deb 또는 rpm을 고른 다음 x64 또는 arm64 아키텍처를 확인하세요. 패키지 형식은 시스템의 패키지 관리 방식에, 프로세서 아키텍처는 실행 환경에 맞아야 하므로 두 항목을 모두 확인해야 합니다.
시스템 프록시 설정을 앱이 읽는지는 데스크톱 환경과 앱의 구현 방식에 따라 달라집니다. 프록시를 별도로 설정해야 하는 프로그램에는 클라이언트가 실제로 사용하는 수신 주소와 포트를 입력하세요. TUN을 켜기 전에 권한 요건을 확인하고 기존 네트워크 관리 규칙과 충돌하지 않는지 살펴보세요.
다운로드 페이지로 이동 Linux 클라이언트 →SECTION 03 / 첫 연결
클라이언트에는 바로 사용할 수 있는 원격 연결이 포함되어 있지 않습니다. 시작하기 전에 사용할 권한이 있는 구독 주소나 공유 링크를 준비하고, 현재 네트워크에서 구독 내용을 가져올 수 있는지 확인하세요. 처음 설정할 때는 클라이언트 하나만 실행하고, 재현 가능한 기본 연결부터 만든 뒤 사용자 지정 라우팅이나 TUN 설정을 추가하세요.
STEP 01 / IMPORT
v2rayN의 ‘구독 그룹’에 구독 주소를 저장한 뒤 업데이트하세요. 단일 공유 링크는 클립보드에서 가져올 수 있습니다. 가져온 뒤 프로토콜, 주소, 포트, 전송 설정이 올바른지 확인하세요. 목록에 항목이 표시된다는 것은 클라이언트가 내용을 인식했다는 뜻일 뿐, 원격 서버에 연결됐다는 뜻은 아닙니다. 업데이트 결과가 비어 있다면 주소, 네트워크 요청, 구독 형식을 먼저 확인하세요. 모든 그룹을 반복해서 삭제하지 마세요.
구독 주소에는 접근 권한 정보가 포함될 수 있으므로 계정 정보처럼 안전하게 보관하세요. 문제 해결을 위해 화면을 공유할 때는 전체 주소, 사용자 식별 정보, 개인 메모를 가리세요. 기기를 옮기기 전에 구독 출처와 로컬 규칙을 각각 백업하세요. 서버 목록을 복사하면 모든 설정이 함께 복사된다고 생각하지 마세요.
STEP 02 / PROXY
사용할 서버를 활성 항목으로 지정한 다음 ‘시스템 프록시 자동 설정’을 선택하세요. 처음 테스트할 때는 동작을 파악하기 쉬운 라우팅 프리셋으로 시작해 어떤 목적지가 직접 연결되고 어떤 목적지가 프록시를 거치는지 확인하세요. 브라우저 확장 프로그램, 수동 프록시 설정, 다른 네트워크 도구가 시스템 설정을 덮어쓸 수 있으므로 테스트 전에 이런 추가 설정을 점검하세요.
시스템 프록시를 사용하지 않는 앱이라면 먼저 자체 프록시 설정을 제공하는지 확인하세요. 더 넓은 범위의 트래픽을 처리해야 할 때 TUN을 켜고 권한과 DNS를 설정하면 됩니다. 한 번에 한 항목만 바꾸고, 이전에 재현 가능했던 설정을 보관하면 문제가 시작된 지점을 찾기 쉽습니다.
STEP 03 / VERIFY
Tcping은 주로 대상 포트에 TCP 연결이 가능한지 확인합니다. 실제 연결 테스트는 프록시 핸드셰이크와 테스트 요청까지 확인하므로 두 검사는 서로 대체할 수 없습니다. 결과는 테스트 대상과 당시 네트워크 상태에도 영향을 받습니다. 서버를 선택한 뒤 프록시를 거쳐야 하는 웹페이지에 브라우저로 접속하고, 클라이언트 로그의 연결 및 라우팅 정보를 함께 확인하세요.
테스트는 통과했는데 앱이 계속 작동하지 않는다면 ‘앱의 프록시 설정 → 로컬 수신 → 라우팅 규칙 적용 → 원격 핸드셰이크’ 순서로 확인하세요. 작업 표시줄 아이콘이나 스위치 상태만으로 프록시가 적용됐다고 판단하지 마세요. 테스트가 끝나면 사용한 모드와 예외 규칙을 기록해 두세요. 다음에 네트워크를 바꿔도 같은 순서로 확인할 수 있습니다.
SECTION 04 / 오픈 소스 생태계
Project V는 V2Ray 생태계를 이해하는 출발점입니다. V2Ray는 인바운드, 라우팅, 아웃바운드, 전송 기능을 조합해 단일 프로토콜 연결 프로그램 이상의 역할을 합니다. 사용자가 자주 접하는 서버 목록과 스위치는 대개 별도의 그래픽 클라이언트에서 제공됩니다. ‘V2Ray 클라이언트’라는 표현이 인터페이스 프로그램, 실행 코어, 연결에 사용하는 프로토콜 중 무엇을 뜻하는지 먼저 확인하세요. 서로 관련은 있지만 같은 계층은 아닙니다.
V2Fly는 V2Ray의 커뮤니티 개발을 이어가고, Xray는 관련 코드 기반에서 출발해 자체 기능을 발전시켜 왔습니다. 두 코어는 공통된 설정 기반을 공유하면서도 각자의 구현과 발전 방향이 있습니다. 따라서 일부 기본 항목이 비슷해 보여도 모든 설정을 그대로 바꿔 쓸 수 있는 것은 아닙니다. VLESS, REALITY, 전송 확장 또는 특정 보안 옵션을 사용할 때는 클라이언트 이름만 보고 판단하지 말고 실제 코어가 지원하는지 확인하세요.
v2rayN은 서버 관리, 구독 업데이트, 프록시 모드, 라우팅 설정을 위한 그래픽 인터페이스를 제공하는 오픈 소스 데스크톱 클라이언트입니다. v2rayNG는 Xray 코어를 사용하는 오픈 소스 Android 클라이언트이며, v2flyNG는 V2Fly 코어를 선택할 수 있는 Android 클라이언트입니다. 먼저 운영체제를 확인하고, 기존 연결에 필요한 프로토콜 기능을 비교해 선택하세요. 링크를 가져올 수 있다는 이유만으로 모든 설정 항목을 지원한다고 볼 수는 없습니다.
그래픽 클라이언트는 화면에서 설정한 값을 코어가 실행할 설정으로 변환하므로, 화면의 이름과 원본 JSON 필드가 항상 일대일로 대응하지는 않습니다. 코어에서 지원하는 옵션이 모두 그래픽 컨트롤로 제공되는 것도 아닙니다. 고급 설정을 다룰 때는 현재 클라이언트의 설정 안내를 먼저 읽고 코어 필드의 의미를 확인하세요. 다른 클라이언트의 화면 안내를 그대로 적용하면 이름이 비슷한 설정을 같은 기능으로 오해할 수 있습니다.
오픈 소스 소프트웨어는 해당 라이선스에 따라 코드를 열람·사용·재배포할 수 있다는 뜻이지, 관련 프로젝트가 모두 같은 라이선스를 사용한다는 뜻은 아닙니다. Xray-core와 V2Fly의 V2Ray-core는 MPL-2.0을 사용합니다. 클라이언트 인터페이스, 코어, 포함된 구성 요소의 라이선스는 각각 확인해야 합니다. 소프트웨어를 수정·배포·통합할 때는 해당 프로젝트의 라이선스 원문을 기준으로 하세요. 생태계 전체를 뭉뚱그린 표현만으로 판단하면 안 됩니다.
오픈 소스 여부만으로 설정 출처의 신뢰성을 판단할 수는 없습니다. 구독 제공자는 연결 매개변수를 정하고, 원격 서버는 서비스 이용 가능성을 결정하며, 로컬 클라이언트는 트래픽 진입과 라우팅 동작을 담당합니다. 출처를 모르는 설정은 라우팅 대상, DNS 설정, 수신 범위를 먼저 확인하세요. 특히 문제 해결을 위해 로컬 프록시 수신 주소를 다른 기기에서도 접속할 수 있도록 함부로 열어 두지 마세요.
클라이언트 인터페이스, 코어, 규칙 데이터의 업데이트는 서로 다른 계층에 영향을 줍니다. 인터페이스 업데이트는 메뉴 위치를 바꿀 수 있고, 코어 업데이트는 설정 지원 범위나 실행 동작을 바꿀 수 있습니다. 규칙 데이터 업데이트는 도메인 및 IP 주소 목록의 매칭 결과에 영향을 줄 수 있습니다. 업데이트 후 달라진 점을 조사할 때는 먼저 변경된 계층을 기록한 뒤 연결 설정과 라우팅 결과를 비교하세요. 모든 이상을 서버 탓으로 돌리지 마세요.
업데이트 전에 필요한 로컬 설정을 보관하고, 업데이트 후에는 이전에 재현 가능했던 앱 요청으로 동작을 확인하세요. 사용자 지정 규칙이 많다면 구체적인 규칙이 일반 규칙보다 앞에 있는지도 점검해야 합니다. 다운로드 페이지에서는 클라이언트를 받고, 프로토콜 참고 페이지에서는 설계상의 차이를 확인할 수 있습니다. 특정 설정 항목의 동작은 현재 실행 중인 코어와 로그를 함께 살펴 판단하세요.
SECTION 05 / 사용 가이드
아래 세 글에서는 프로토콜 선택, 라우팅 우선순위, 첫 연결 확인 방법을 각각 다룹니다. 먼저 반복해서 확인할 수 있는 테스트 절차를 만든 다음 사용자 지정 규칙을 살펴보세요. 기존 연결을 옮길 때는 프로토콜과 전송 방식의 조합을 먼저 파악해 클라이언트를 바꾸는 과정에서 설정 항목이 누락되지 않도록 하세요.
프로토콜의 등장 배경, 암호화 방식, 핸드셰이크 오버헤드, 모바일 배터리 소모를 비교하고 사용 환경에 맞는 프로토콜 선택 기준을 안내합니다.
domain, full, regexp, geosite, geoip 등 규칙 접두사의 작성 방법을 설명하고, 규칙이 위에서 아래로 적용되는 순서와 domainStrategy가 결과에 미치는 영향을 알아봅니다.
구독을 가져온 뒤 서버를 선택하는 방법, Tcping과 실제 연결 지연 시간 테스트의 차이, 시스템 프록시 상태와 브라우저 접속으로 프록시가 적용됐는지 확인하는 방법을 안내합니다.