이 도구 생태계를 이해하려면 Project V부터 살펴보면 됩니다. V2Fly와 Xray는 서로 다른 코어 개발 경로를 따르고, v2rayN·v2rayNG·v2flyNG는 사용자 설정과 연결 관리를 담당합니다. 이 글에서는 프로젝트, 코어, 클라이언트, 프로토콜을 구분해 설명하고 데스크톱과 Android에서 선택하는 방법을 소개합니다. 구독 정보를 받았지만 어떤 클라이언트와 코어를 사용해야 할지 고민인 분에게 적합합니다.
Project V, V2Fly, Xray: 프로젝트 관계부터 구분하기
Project V는 네트워크 통신 도구와 모듈형 프록시 기능을 중심으로 하며, V2Ray는 그 안의 핵심 프로젝트입니다. 일상적인 대화에서 ‘V2Ray’는 코어 프로그램을 뜻하기도 하고 전체 도구 생태계를 통칭하기도 합니다. 문제를 진단할 때는 사용 중인 클라이언트, 클라이언트가 호출하는 코어, 코어가 실제로 사용하는 설정을 각각 확인해야 합니다.
V2Fly는 V2Ray를 이어서 유지·개발하는 커뮤니티이며, 흔히 V2Fly 코어라고 부르는 것은 이들이 관리하는 v2ray-core입니다. Xray-core는 v2ray-core에서 분기해 개발되기 시작한 뒤 독자적인 기능 개발 경로를 형성했습니다. 두 코어는 일부 역사와 설정 개념을 공유하지만, 새 기능이나 필드, 기본 동작까지 항상 같다고 볼 수는 없습니다.
- Project V: 프로젝트의 배경과 기술 체계입니다. 별도로 설치하는 데스크톱 클라이언트는 아닙니다.
- V2Fly: 커뮤니티와 그 개발 방향을 가리킵니다. 연결 기능을 논할 때는 v2ray-core를 구체적으로 지칭해야 합니다.
- Xray: 독자적으로 개발되는 코어 프로젝트입니다. REALITY와 XTLS Vision 등의 기능은 실제 지원 여부를 확인해 설정해야 합니다.
- v2rayN 등의 클라이언트: 서버 정보, 구독 그룹, 라우팅 설정을 코어가 실행할 수 있는 설정으로 변환합니다.
클라이언트와 코어: 화면 설정이 실제 연결로 이어지는 과정
클라이언트는 주로 사용자 인터페이스와 관리를 담당합니다. 구독 주소를 저장하고 서버 목록을 표시하며, 시스템 프록시를 설정하고 설정 파일을 생성한 뒤 코어를 시작하거나 중지합니다. 코어는 로컬 연결을 수신하고 라우팅 규칙을 적용하며 프로토콜 핸드셰이크를 수행해 데이터를 전달합니다. 화면이 정상적으로 열려도 포트 충돌이나 설정 오류로 코어가 시작되지 않을 수 있습니다.
| 클라이언트 | 주요 플랫폼 | 코어 구성 | 선택 시 확인할 점 |
|---|---|---|---|
| v2rayN | Windows、macOS、Linux | Xray 등을 지원하는 여러 코어를 관리하는 데스크톱 클라이언트. 선택지는 배포판에 따라 다를 수 있음 | 설치 패키지의 플랫폼과 아키텍처, 현재 설정에서 호출하는 코어 확인 |
| v2rayNG | Android | Xray 코어 사용. Android에서 화면과 트래픽 처리를 담당 | 노드 매개변수, 앱 프록시 적용 범위, VPN 권한 확인 |
| v2flyNG | Android | V2Fly의 v2ray-core 경로 사용 | 노드에 필요한 기능이 해당 코어에서 구현되어 있는지 확인 |
v2rayN의 크로스 플랫폼 데스크톱 인터페이스와 Windows WPF 인터페이스는 별개의 구분입니다. 인터페이스 기술은 창, 트레이, 플랫폼 연동 방식을 결정하지만, 원격 핸드셰이크에 VMess를 사용할지 VLESS를 사용할지까지 결정하지는 않습니다. 인터페이스 버전을 바꾸더라도 코어와 노드 매개변수 확인을 대신할 수는 없습니다.
Android에서 트래픽을 처리하는 일도 프로토콜 코어만으로 이루어지지 않습니다. v2rayNG와 v2flyNG는 일반적으로 시스템 VPN 인터페이스로 앱 트래픽을 받아 코어에 전달합니다. 시스템에 VPN 연결됨으로 표시되어도 트래픽을 가로채는 경로가 만들어졌다는 뜻일 뿐, 원격 노드와의 핸드셰이크 성공까지 보장하지는 않습니다.
확인 방법: 클라이언트와 코어를 각각 기록하기
문제를 문의하기 전에 클라이언트 이름과 버전, 실행 로그에 표시된 코어 버전, 노드 프로토콜을 함께 기록하세요. ‘V2Ray가 연결되지 않아요’만으로는 인터페이스, 트래픽 처리, 설정, 원격 서버 중 어디에서 문제가 생겼는지 구분할 수 없습니다.
VMess, VLESS, TLS, REALITY: 서로 다른 개념 구분하기
연결 설정에는 최소한 프록시 프로토콜, 전송 방식, 보안 설정이 포함됩니다. VMess와 VLESS는 프록시 프로토콜이고, WebSocket은 전송 방식이며, TLS와 REALITY는 연결 보안 설정에 해당합니다. 이들은 서로 바꿔 쓸 수 있는 같은 종류의 옵션이 아니며, 이름이 길다고 성능이 더 좋은 것도 아닙니다.
- VMess: V2Fly와 Xray 모두 관련 구현을 제공합니다. 연결 여부는 사용자 ID, 전송 방식, 보안 설정, 서버 설정이 서로 일치하는지에 달려 있습니다.
- VLESS: 프로토콜 자체는 페이로드를 암호화하지 않으므로 적절한 보안 계층과 함께 사용해야 합니다. VLESS를 ‘자동으로 암호화되는 VMess’라고 간단히 설명할 수는 없습니다.
- REALITY: 모든 코어에서 일반 TLS 옵션처럼 그대로 사용할 수 있는 기능은 아닙니다. VLESS + REALITY 매개변수를 받았다면 해당 조합을 명시적으로 지원하는 구현을 선택해야 합니다.
- Vision: XTLS 관련 흐름 제어 기능으로, 독립된 구독 형식이 아닙니다. 서버와 클라이언트의 흐름 제어 설정이 일치해야 합니다.
예를 들어 구독에서 VLESS + REALITY를 제공한다면 서버 주소, 포트, 사용자 ID, 서버 이름, 공개 키, Short ID, 흐름 제어 등의 필드를 확인해야 합니다. 필수 입력 항목과 구체적인 이름은 해당 설정 및 코어 문서를 기준으로 확인하세요. 프로토콜 드롭다운에서 VLESS만 선택한다고 나머지 매개변수가 자동으로 채워지지는 않습니다.
노드 요구 사항에 따라 v2rayN·v2rayNG·v2flyNG 선택하기
먼저 운영체제를 확인하고, 다음으로 노드 요구 사항을 살펴보세요. 데스크톱에서는 v2rayN으로 구독 그룹과 라우팅을 통합 관리할 수 있습니다. Android에서는 v2rayNG와 v2flyNG의 코어 기능을 비교해야 합니다. 아래 추천은 Xray 기능이 필요한 Android 설정을 대상으로 하며, 모든 사용 환경을 아우르는 성능 순위가 아닙니다.
v2rayNG
추천Android에서 Xray 코어를 사용합니다. 노드에서 REALITY 또는 Vision을 명시적으로 요구한다면 이 경로의 지원 여부와 실제 코어 버전을 먼저 확인하세요.
추천 대상: Android에서 Xray 기능을 명확히 요구하는 노드를 사용하는 경우
v2flyNG
Android에서 V2Fly 코어를 사용합니다. 기존 설정이 V2Fly의 기능과 동작을 기준으로 관리되고 있다면 이 경로를 유지할 수 있지만, 구체적인 전송 방식과 보안 옵션은 확인해야 합니다.
추천 대상: 검증된 V2Fly 설정을 이미 사용하는 Android 환경
v2rayN
데스크톱에서 구독, 시스템 프록시, 라우팅을 관리합니다. Windows, macOS, Linux 및 프로세서 아키텍처에 맞는 설치 패키지를 선택한 뒤 실행 중 호출되는 코어를 확인하세요.
추천 대상: 구독과 라우팅을 한곳에서 관리하려는 데스크톱 환경
클라이언트 이름만으로 속도를 판단할 수는 없습니다. 네트워크 경로, 서버 부하, 전송 설정, 로컬 트래픽 처리 방식이 모두 결과에 영향을 줍니다. 비교할 때는 같은 서버와 네트워크, 테스트 대상을 사용하고 한 번에 변수 하나만 바꾸세요. 그렇지 않으면 결과가 달라져도 코어의 영향인지 판단하기 어렵습니다.
v2rayN 확인 절차: 설정 메뉴부터 실행 로그까지
아래 절차는 ‘현재 설정을 실제로 어떤 코어가 실행하는지’를 확인하기 위한 것입니다. 배포판에 따라 옵션 위치가 달라질 수 있습니다. 화면에 해당 항목이 보이지 않으면 다른 버전의 스크린샷을 참고하지 말고 클라이언트 버전과 인터페이스 유형부터 확인하세요. 사용자 지정 설정은 일반 서버 설정의 기본 선택을 따르지 않을 수도 있습니다.
-
버전 기록하기
‘도움말’ → ‘정보’에서 클라이언트 버전을 확인하고 플랫폼과 인터페이스 유형도 기록하세요. 코어 버전은 시작 로그에서 별도로 확인해야 합니다. 클라이언트 버전을 코어 버전으로 간주하지 마세요.
-
코어 확인하기
‘설정’ → ‘매개변수 설정’으로 이동해 ‘Core 유형’ 관련 옵션을 확인하세요. 프로토콜별로 코어를 지정한다면 현재 노드 프로토콜에 해당하는 항목도 확인합니다. 항목 이름이나 위치가 다르면 실제 설정 화면을 기준으로 살펴보세요.
-
노드 설정 확인하기
현재 서버의 편집 창을 열어 프로토콜, 주소, 원격 포트, 전송 방식, TLS 또는 REALITY 매개변수를 확인하세요. 구독에서 받은 원래 설정을 유지하고, 오류를 없애려고 사용자 ID나 보안 매개변수를 임의로 바꾸지 마세요.
-
로그 확인하기
현재 설정으로 다시 시작한 뒤 메인 화면 로그에서 코어 시작 정보와 오류를 확인하세요. 먼저 설정이 받아들여지고 리스너가 생성되었는지 살펴본 다음 원격 연결 성공 여부를 판단하세요.
코어를 바꿔 한 노드에서 연결에 성공해도 구독의 모든 노드에 적용되는 것은 아닙니다. 노드마다 프로토콜이나 전송 방식이 다를 수 있습니다. 구독 그룹 전체가 ‘같은 업체에서 제공하므로 모두 동일하다’고 가정하지 말고 각 노드의 실제 요구 사항을 확인하세요.
로컬 포트, 시스템 프록시, 라우팅의 차이
들어오는 연결과 나가는 연결을 구분하기 위해 로컬 포트 두 개를 예로 들어 보겠습니다. 아래 숫자는 설명을 위해 수동으로 설정한 값이며, 어떤 배포판의 기본 포트라고 단정하는 것은 아닙니다. 해당 리스너가 실제로 설정되어 있어야 앱에서 이 주소를 사용할 수 있습니다.
예를 들어 SOCKS 입력을 127.0.0.1:10808, HTTP 입력을 127.0.0.1:10809로 설정한 경우 앱에서도 올바른 프록시 유형을 지정해야 합니다. HTTP 프록시 요청을 SOCKS만 지원하는 입력 포트로 보내면 원격 서버에 도달하기 전에 로컬 프로토콜 단계에서 오류가 발생합니다. 일부 버전은 혼합 입력을 지원하므로 실제 리스너 유형을 확인해 입력하세요.
- 시스템 프록시: 시스템 설정을 읽는 앱에 프록시 주소를 알립니다. 모든 프로그램이 이를 사용하는 것은 아닙니다.
- TUN: 가상 네트워크 인터페이스로 트래픽을 받아들입니다. 라우팅, DNS, 제외 규칙의 영향을 받으며 모든 연결이 프록시 서버로 전달되는 것은 아닙니다.
- 코어 라우팅: 코어에 들어온 트래픽을 대상으로 직접 연결, 프록시, 차단 여부를 결정합니다. 코어에 들어오지 않은 트래픽에는 이 규칙이 적용되지 않습니다.
- 원격 포트: 서버에서 연결을 수신하는 포트입니다. 로컬 포트 예시인 10808, 10809와 같을 필요는 없습니다.
문제 해결 순서: 트래픽 유입을 먼저 확인한 뒤 출구 점검하기
앱에서 접속이 안 되면 먼저 로그에 해당 연결이 나타나는지 확인하세요. 기록이 없다면 앱의 프록시 설정과 트래픽 처리 방식을 점검합니다. 기록이 있다면 라우팅 대상, DNS, 핸드셰이크 오류를 확인해 관련 없는 구독 주소를 반복해서 바꾸지 않도록 하세요.
오픈소스 라이선스: 클라이언트와 코어를 따로 확인하기
네트워크 프로토콜과 오픈소스 라이선스는 별개의 개념입니다. VMess와 VLESS는 통신 방식을 설명하고, MIT·MPL-2.0·GPL-3.0은 코드의 사용과 배포 조건을 규정합니다. 서로 통신할 수 있다고 해서 두 프로젝트가 같은 라이선스를 사용하는 것은 아닙니다. 클라이언트가 특정 코어를 호출하더라도 함께 제공되는 모든 구성 요소에 하나의 라이선스만 적용되는 것은 아닙니다.
| 프로젝트 | 주요 라이선스 | 확인할 범위 |
|---|---|---|
| V2Fly v2ray-core | MIT | 코어 자체와 종속성에 포함된 라이선스 고지 |
| Xray-core | MPL-2.0 | 라이선스가 적용되는 파일과 수정·배포 조건 |
| v2rayN | GPL-3.0 | 클라이언트 코드, 배포 패키지, 포함된 구성 요소 |
| v2rayNG | GPL-3.0 | Android 클라이언트와 통합 코어의 개별 라이선스 고지 |
| v2flyNG | GPL-3.0 | Android 클라이언트와 종속성의 라이선스 |
위 표는 프로젝트의 주요 라이선스를 파악하기 위한 것이며, 개별 배포 패키지의 LICENSE, NOTICE, 종속성 목록을 대신하지 않습니다. 일반 사용자는 플랫폼, 아키텍처, 노드 요구 사항에 맞는 클라이언트를 내려받으면 됩니다. 코드를 수정하거나 재배포할 계획이라면 인터페이스에 표시된 프로젝트 이름만 보지 말고 실제 코드 버전에 적용되는 라이선스 조건을 각각 확인하세요.
선택 과정을 세 단계로 정리할 수 있습니다. 먼저 플랫폼을 정하고, 다음으로 노드가 요구하는 프로토콜과 보안 조합을 확인한 뒤, 클라이언트에서 실제로 실행 중인 코어를 확인하세요. 구독은 정보를 제공하고, 클라이언트는 이를 관리하며, 코어는 연결을 실행하고, 라우팅은 출구를 선택합니다. 각 역할을 구분하면 버전 업데이트와 연결 문제를 더 정확하게 판단할 수 있습니다.