Project V는 이 도구 생태계의 배경을 이해하는 출발점이며, V2Fly와 Xray는 서로 다른 코어 유지보수 계열입니다. v2rayN, v2rayNG, v2flyNG는 사용자용 클라이언트입니다. 노드 요구사항을 확인해 코어를 고른 다음 플랫폼에 맞는 클라이언트를 선택하세요. 이 글에서는 프로젝트 관계, 프로토콜 기능, 설정 점검 순서로 살펴보고, 구독은 가져왔지만 연결되지 않는 상황을 피하는 방법을 안내합니다.
1. Project V, V2Ray, 코어의 차이
Project V는 별도로 설치하는 데스크톱 프로그램이 아니라 네트워크 프록시 도구를 둘러싼 프로젝트 생태계입니다. V2Ray는 그 핵심 프로젝트로, 연결을 받고 라우팅 규칙에 따라 트래픽을 분류하며 프로토콜을 처리하고 외부 서버로 연결합니다. 일상적인 대화에서 ‘V2Ray’는 클라이언트 사용 방식 전체를 가리키기도 하므로, 같은 표현이 코어를 뜻할 수도 있고 특정 노드 유형을 편의상 부르는 말일 수도 있습니다.
코어에는 보통 구독을 관리하는 완전한 사용자 인터페이스가 없습니다. 클라이언트에서 서버를 선택하거나 시스템 프록시를 전환하고 라우팅을 편집하면, 클라이언트가 선택 사항을 코어가 읽을 수 있는 설정으로 변환해 해당 프로세스를 실행합니다. 두 계층을 구분해야 문제가 화면 설정에 있는지 프로토콜 로그에 있는지 판단할 수 있습니다.
- 생태계와 프로젝트: Project V는 프로젝트의 배경과 출처를 이해하기 위한 개념이지, 노드 프로토콜 이름이 아닙니다.
- 코어: V2Fly가 유지보수하는 V2Ray Core와 Xray Core가 실제 연결 및 트래픽 처리를 담당합니다.
- 클라이언트: v2rayN, v2rayNG, v2flyNG는 사용자 인터페이스와 구독 관리, 플랫폼 연동 기능을 제공합니다.
- 노드 설정: 서버 주소, 포트, 인증 정보, 전송 방식과 보안 매개변수를 담으며 서버 설정과 일치해야 합니다.
2. V2Fly와 Xray: 공통된 출발점, 서로 다른 발전 경로
V2Fly는 V2Ray를 이어서 유지보수하는 커뮤니티 프로젝트입니다. 2020년 전후로 커뮤니티의 유지보수 활동이 오늘날 익숙한 V2Fly 계열로 자리 잡았습니다. 같은 해 Xray는 V2Ray 코드 기반에서 분기해 개발되기 시작했고, 이후 자체 프로토콜 구현과 전송 방식, 설정 기능을 중심으로 발전했습니다. 두 프로젝트는 공통된 역사를 공유하지만 같은 프로그램의 테마만 다른 것이 아니며, 하나를 설치하면 다른 하나로 자동 업그레이드되는 관계도 아닙니다.
차이를 파악할 때는 이름만 보지 말고 구체적인 기능을 확인해야 합니다. VMess와 VLESS는 프로토콜 계층의 이름이고, WebSocket은 전송 방식이며, TLS와 REALITY는 연결 보안 계층과 관련됩니다. XTLS Vision은 Xray의 흐름 제어 방식입니다. 각 항목은 서로 다른 계층에 있으므로 ‘VMess와 REALITY 중 무엇이 더 나은가’처럼 같은 기준으로 비교할 수 없습니다.
Xray Core
추천노드에서 VLESS, REALITY, Vision 조합을 명시적으로 요구한다면 해당 기능을 지원하는 Xray 버전을 선택하세요. 이 권장 사항은 설정 호환성을 기준으로 하며, 모든 네트워크 환경에서 속도를 보장하지는 않습니다.
추천 대상: 서버에서 Xray를 지정했거나 노드에 REALITY·Vision 매개변수가 포함된 사용자
V2Fly가 유지보수하는 V2Ray Core
기존 V2Ray 설정 체계를 이어서 사용하려는 환경에 적합합니다. 기존 VMess, WebSocket, TLS 노드를 사용할 수 있는지는 현재 코어 버전과 전송 기능, 서버 매개변수를 확인해야 합니다. 프로토콜 이름만으로 판단할 수 없습니다.
추천 대상: 이미 작동 중인 V2Fly 배포 환경을 사용하며 설정과 유지보수 방식을 이어가려는 사용자
VLESS라는 이름만으로 두 계열 중 하나를 선택할 수는 없습니다. 기본 프로토콜 지원과 특정 조합 지원은 별개의 문제입니다. VLESS를 인식한다고 해서 REALITY나 xtls-rprx-vision까지 처리할 수 있는 것은 아닙니다. 마찬가지로 V2Ray의 v4 방식 설정과 v5 설정 체계를 한데 섞어 쓰지 않는 편이 좋습니다. 온라인에서 JSON 조각을 찾았다면 먼저 어떤 코어와 설정 형식에 속하는지 확인하세요.
선택 기준: 노드 항목을 확인한 뒤 코어 선택
노드에 REALITY 공개 키와 short ID, Vision 흐름 제어 요구사항이 포함되어 있다면 클라이언트에서 사용하는 Xray 버전이 해당 항목을 처리하는지 먼저 확인하세요. 현재 V2Fly 설정이 정상 작동한다면 프로젝트 이름이 바뀌었다는 이유만으로 이전할 필요 없이 기존 구성을 유지하는 것이 좋습니다.
3. 클라이언트별 사용 코어
클라이언트 이름이 비슷하다고 구현까지 같은 것은 아닙니다. 데스크톱용 v2rayN은 여러 코어를 관리할 수 있지만, 선택 가능한 항목은 버전과 플랫폼, 설치된 구성 요소에 따라 달라집니다. Android용 v2rayNG는 Xray를 핵심으로 사용하고, v2flyNG는 V2Fly가 유지보수하는 V2Ray 코어를 사용합니다. 앱 버전과 코어 버전은 별도의 번호 체계를 쓰므로 기능을 비교할 때 각각 확인해야 합니다.
| 클라이언트 | 플랫폼 | 코어 구성 | 선택 기준 |
|---|---|---|---|
| v2rayN | Windows / macOS / Linux | 여러 코어 관리 지원. 실제 기능은 버전과 설치된 코어에 따라 다름 | 데스크톱에서 구독 관리, 시스템 프록시, 라우팅 설정이 필요한 경우 |
| v2rayNG | Android | Xray 코어 | 노드에서 Xray 기능을 요구하거나 Android에서 해당 설정을 관리해야 하는 경우 |
| v2flyNG | Android | V2Fly의 V2Ray 코어 | 노드와 설정을 V2Fly 계열에 맞춰 유지보수하는 경우 |
v2rayN에서는 노드 편집 창의 프로토콜 및 전송 항목과 실제 실행 로그에 표시되는 코어 이름을 함께 확인하세요. 화면에 옵션이 보인다고 해서 현재 선택된 코어가 해당 기능을 실행할 수 있는 것은 아닙니다. 반대로 코어가 특정 기능을 지원하더라도 클라이언트가 올바른 설정을 생성해야 사용할 수 있습니다.
- 먼저 클라이언트의 전체 버전을 기록하고, 시작 로그에서 코어 이름과 버전을 확인하세요. ‘최신 버전’이라고만 적어 두지 마세요.
- 노드 편집 창을 열어 주소, 포트, 사용자 ID, 전송 유형, 보안 계층을 확인하고 가져오는 과정에서 항목이 누락되지 않았는지 살펴보세요.
- 연결을 다시 시작한 뒤 로그에서 설정 파싱 실패, 핸드셰이크 실패, 연결 후 발생한 접속 문제 중 어느 단계에서 오류가 생기는지 확인하세요.
4. 구독을 공유해도 노드와 설정까지 모두 호환되는 것은 아닙니다
구독 링크는 노드 정보를 배포하는 경로이지 프록시 프로토콜이 아닙니다. 구독에는 공유 링크가 포함될 수도 있고 클라이언트가 지원하는 다른 형식이 쓰일 수도 있습니다. 두 클라이언트가 같은 주소를 읽는다는 것은 해당 배포 형식을 받아들였다는 뜻일 뿐입니다. 파싱 후 모든 항목이 보존되는지, 각 노드를 지원하는지는 따로 확인해야 합니다.
예를 들어 VLESS 노드가 원격 포트 443을 사용하면서 특정 server name, 공개 키, short ID, xtls-rprx-vision을 요구할 수 있습니다. 서버 주소와 사용자 ID가 맞더라도 필수 매개변수 하나가 빠지면 연결이 실패할 수 있습니다. 포트가 443이라고 해서 일반 TLS를 뜻하는 것도 아니므로 노드에 명시된 보안 유형을 확인하세요.
설정 방법: 데스크톱과 Android에서 같은 구독 각각 확인하기
데스크톱: v2rayN
- 먼저 구독을 업데이트한 다음 매개변수가 완전한 노드 하나를 기준으로 선택하세요.
- 노드 요구사항에 맞는 코어를 선택하고 시작 로그에 표시된 실제 코어 버전을 기록하세요.
- 시스템 프록시 연결 방식과 라우팅 규칙을 각각 확인하고, 여러 트래픽 처리 방식을 동시에 활성화하지 마세요.
Android: v2rayNG 또는 v2flyNG
- 노드가 요구하는 기능에 맞춰 클라이언트를 선택한 다음 구독을 가져오세요.
- 시스템 VPN 권한을 확인하고 대상 앱이 앱별 규칙에서 제외되어 있지 않은지 살펴보세요.
- 같은 노드로 다시 테스트하고 기기 자체의 DNS 및 라우팅 설정만 별도로 유지하세요.
구독을 공유하면 노드를 일일이 입력하는 수고를 줄일 수 있지만, 업데이트 시점과 로컬 라우팅, DNS, 앱별 설정은 기기마다 따로 관리해야 합니다.
데스크톱에서 내보낸 전체 실행 설정을 Android에서도 그대로 쓸 수 있다고 가정하지 마세요. 로컬 파일 경로, 수신 주소, 인바운드 포트, 트래픽 처리 방식이 다를 수 있습니다. 기기 간에 옮길 때는 노드 정보부터 가져온 뒤 각 플랫폼의 인터페이스에서 로컬 동작을 다시 설정하세요. 구독 주소에는 접근 정보가 포함될 수 있으므로 공개 스크린샷이나 문의 내용에 노출하지 마세요.
5. 코어를 바꾼 뒤 연결되지 않을 때 단계별로 점검하기
코어를 바꾼 뒤 접속에 실패했다고 곧바로 ‘새 코어가 불안정하다’고 단정할 수는 없습니다. 같은 노드라도 다른 매개변수로 설정이 만들어졌을 수 있고, 로컬 진입점이나 시스템 프록시, DNS 설정만 달라졌을 수도 있습니다. 먼저 같은 기기와 노드, 대상 URL로 반복 테스트할 수 있는 환경을 만든 뒤 한 번에 하나씩만 바꾸세요.
- 설정을 불러올 수 있는지 확인하세요. 알 수 없는 항목이나 설정 파싱 오류가 로그에 나타나면 먼저 코어 종류와 설정 형식을 확인하세요. 서버 포트를 계속 바꾸며 운에 맡기지 마세요.
- 로컬 수신 주소를 확인하세요. 예를 들어 로컬 SOCKS 진입점을
127.0.0.1:10808로 지정했다면 앱에서도 실제로 이 주소를 사용해야 합니다. 이는 문제 해결을 위한 예시일 뿐 모든 버전의 기본 포트를 뜻하지 않습니다. - 원격 핸드셰이크를 확인하세요. 서버 주소와 포트, 기기 시간, 보안 계층 매개변수를 확인하세요. Vision을 사용한다면 flow 항목을, REALITY를 사용한다면 서버에서 요구하는 공개 키와 server name을 확인하세요.
- 앱 트래픽의 진입 경로를 확인하세요. 데스크톱 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용됩니다. Android에서는 VPN 연결 상태와 앱별 적용 범위도 확인해야 합니다.
- 마지막으로 DNS와 분기 규칙을 확인하세요. 연결은 되었지만 일부 도메인에 접속할 수 없다면 규칙이 직접 연결과 프록시 중 무엇을 선택했는지 확인하고, 로컬 DNS 조회와 프록시 측 DNS 조회를 구분하세요.
지연 시간 테스트는 특정 탐지 조건에서 얻은 결과일 뿐, 웹페이지 열기나 다운로드, 장시간 연결을 대신하지 못합니다. 두 코어 계열을 비교하려면 같은 네트워크에서 각각 3회 반복하고 연결 성공 횟수, 첫 페이지가 열린 시간, 로그 오류를 기록하세요. 한 번 측정한 지연 시간만으로 특정 코어가 전반적으로 더 빠르다고 결론 내리면 안 됩니다.
6. 생태계 선택 관련 자주 묻는 질문
노드에 ‘V2Ray’라고 적혀 있는데 어떤 클라이언트를 설치해야 하나요?
먼저 노드 제공자에게 프로토콜, 전송 방식, 보안 계층을 확인하세요. 데스크톱에서 v2rayN을 선택해도 코어는 별도로 확인해야 합니다. Android에서 REALITY나 Vision이 명시적으로 요구된다면 해당 Xray 기능을 지원하는 v2rayNG 버전을 선택하세요. 구독 페이지의 포괄적인 명칭만으로 판단하지 마세요.
v2rayN을 업데이트했는데도 프로토콜 매개변수가 지원되지 않는다는 메시지가 표시되는 이유는 무엇인가요?
시작 로그를 확인해 클라이언트와 코어 버전을 각각 기록한 다음 선택한 노드에 어떤 코어가 사용되는지 살펴보세요. 인터페이스 프로그램을 업데이트해도 외부 코어 파일이 모두 교체되는 것은 아닙니다. 코어 업데이트 여부를 확인하고 연결을 다시 시작한 뒤 오류가 여전히 설정 로딩 단계에서 발생하는지 확인하세요.
같은 구독이 v2rayNG에서는 작동하지만 v2flyNG에서는 작동하지 않으면 어떻게 해야 하나요?
먼저 같은 노드를 선택해 보안 계층과 흐름 제어 항목을 비교하세요. 해당 항목에 Xray의 특정 기능이 필요하다면 호환되는 클라이언트에서 사용하세요. 양쪽 모두 지원하는 조합이라면 구독 전체를 먼저 삭제하지 말고 항목 파싱, 기기 시간, VPN 권한을 확인하세요.
코어를 바꾸면 DNS와 라우팅 분기 문제가 자동으로 해결되나요?
현재 네트워크에 맞는 규칙이 자동으로 설정되지는 않습니다. 기존 프리셋을 저장한 뒤 테스트 도메인 하나를 정해 어떤 규칙과 DNS 조회 경로가 적용되는지 확인하세요. 데스크톱에서는 앱 트래픽이 실제로 프록시를 통과하는지 프록시 모드 안내에 따라 확인한 다음 DNS를 조정하세요.
최종 선택 기준은 간단합니다. 노드가 요구하는 매개변수를 빠짐없이 표현하고 처리할 수 있는 코어를 사용하고, 기기에 필요한 연결 방식을 제공하는 플랫폼별 클라이언트를 선택하세요. 안정적으로 작동하는 환경은 재현 가능한 문제나 명확한 새 요구사항이 있을 때 조정해야 합니다. 프로젝트 분기 이름을 성능 순위처럼 여겨서는 안 됩니다.