Project V는 이 생태계를 이해하는 출발점입니다. V2Fly와 Xray는 구분해야 할 핵심 프로젝트이며, v2rayN·v2rayNG·v2flyNG는 그래픽 인터페이스를 제공합니다. 클라이언트를 고르거나 노드 호환성을 확인하고 코어를 바꾸려는 사용자를 위해 프로젝트 구조부터 짚고, 프로토콜·전송 방식·보안 설정·오픈소스 라이선스까지 실제 설치 파일을 기준으로 살펴봅니다. 클라이언트 이름만으로 호환성을 단정하지 마세요.
Project V의 시작: 프로젝트·코어·프로토콜은 서로 다른 개념
Project V는 처음에 V2Ray를 중심으로 네트워크 프록시 도구와 관련 구성 요소를 구축했습니다. V2Ray 코어는 구독 목록을 보여주는 프로그램이 아니라, 설정에 따라 인바운드 연결을 받고 라우팅을 선택해 아웃바운드 연결을 처리합니다. 일상적으로 ‘V2Ray’는 프로젝트나 코어 프로그램을 가리키기도 하고, 프록시 설정 전반을 뜻하기도 합니다. 문제를 논의할 때는 먼저 무엇을 가리키는지 구분해야 합니다.
그래픽 클라이언트는 별도의 계층에 있습니다. 서버 목록 표시, 구독 저장, 설정 생성, 코어 실행, 로그 표시 등을 담당합니다. VMess·VLESS 같은 프로토콜 연결은 코어와 해당 구현이 실제로 처리합니다. 클라이언트 화면에 프로토콜 이름이 표시된다고 해서 현재 포함된 코어가 그 프로토콜의 모든 전송·보안 조합을 지원한다는 뜻은 아닙니다.
- 프로젝트 계층: Project V는 역사와 기술적 배경을 제공합니다. V2Fly와 Xray는 각각 별도의 유지보수 범위와 배포 주기를 따릅니다.
- 코어 계층: V2Fly-core와 Xray-core가 설정을 읽고 연결을 처리하며, 지원 기능은 해당 버전에 따라 달라집니다.
- 인터페이스 계층: v2rayN·v2rayNG·v2flyNG는 설정과 실행 상태를 관리하는 그래픽 클라이언트이며, 이름이 비슷한 프로토콜과는 다릅니다.
- 설정 계층: 서버 주소와 포트, 사용자 식별자, 전송 방식, 보안 매개변수, 라우팅 규칙이 함께 연결 방식을 결정합니다.
따라서 ‘V2Ray를 설치했다’는 정보만으로는 문제를 파악하기 어렵습니다. 클라이언트 이름과 버전, 실행 중인 코어의 이름과 버전, 노드 프로토콜, 오류 로그를 함께 확인하세요. 로그를 공유하기 전에는 구독 주소와 사용자 식별자 등 접속 정보를 삭제해야 합니다.
V2Fly와 Xray: 뿌리는 같지만 각자 발전하는 프로젝트
V2Fly는 V2Ray 코어의 유지보수를 이어가는 커뮤니티 프로젝트입니다. 코어는 보통 V2Fly-core라고 부르지만, 프로그램과 문서에는 V2Ray라는 이름도 계속 등장합니다. Xray-core는 2020년에 관련 코드 기반에서 분리된 뒤 독립 프로젝트로 발전했습니다. 두 프로젝트는 역사적으로 연결되어 있지만, 같은 배포 계열의 일반판과 고급판으로 볼 수는 없습니다.
| 비교 항목 | V2Fly-core | Xray-core |
|---|---|---|
| 프로젝트 성격 | V2Ray 코어를 이어서 관리하는 커뮤니티 프로젝트 | 관련 코드 기반에서 분리된 독립 코어 |
| 호환성 확인 | 해당 버전의 프로토콜 및 설정 문서 확인 | 해당 버전의 프로토콜 및 설정 문서 확인 |
| 주요 관심사 | 기존 V2Ray 설정의 유지보수 및 마이그레이션 | VLESS, XTLS Vision, REALITY 등 관련 설정 |
| 코어 라이선스 | MIT License | Mozilla Public License 2.0 |
VMess와 VLESS는 프로토콜 이름이고, TCP·WebSocket 등은 전송 방식이며, TLS는 연결 보안 관련 설정입니다. REALITY와 XTLS Vision은 각각 특정 구현 및 설정 요건과 관련되어 있으므로 VMess와 나란히 놓고 자유롭게 바꿔 쓸 수 있는 옵션으로 보면 안 됩니다. 특히 REALITY 또는 Vision 매개변수가 있는 노드는 클라이언트에서 링크를 가져올 수 있는지만 볼 것이 아니라, 코어가 해당 조합 전체를 지원하는지 확인해야 합니다.
판단 기준: 노드 매개변수를 먼저 확인한 뒤 코어 선택
서비스 제공자가 안내한 프로토콜, 전송 방식, 보안 방식과 추가 매개변수를 목록으로 정리한 다음 현재 코어의 지원 범위를 확인하세요. 두 코어의 출처가 같다는 이유만으로 실행 파일을 교체하거나 설정 전체를 그대로 재사용하지 마세요.
세 그래픽 클라이언트의 생태계 내 역할
v2rayN은 Windows·macOS·Linux 데스크톱 환경을 지원합니다. 플랫폼에 따라 설치 방법, 권한, 시스템 프록시 동작 방식이 다를 수 있습니다. 구독과 라우팅을 관리하고 지원 범위 내에서 여러 코어를 사용할 수 있습니다. 특정 코어로 전환할 수 있는지는 클라이언트 버전, 설치 파일 구성, 노드 유형에 따라 달라집니다. 이름에 N이 들어간다는 이유만으로 판단할 수는 없습니다.
| 클라이언트 | 플랫폼 | 코어 구성 | 사용 전 확인 사항 |
|---|---|---|---|
| v2rayN | Windows、macOS、Linux | 코어를 지원 여부에 따라 선택할 수 있는 데스크톱 관리 인터페이스 | 시스템 아키텍처, 코어 파일, 노드 지원 여부, 프록시 연결 방식 |
| v2rayNG | Android | Xray 코어 사용 | 노드 매개변수, 코어 버전, 시스템 VPN 권한 |
| v2flyNG | Android | V2Fly 코어 사용 | 기존 설정 호환성 및 시스템 VPN 권한 |
v2rayNG와 v2flyNG는 인터페이스와 사용 방식이 비슷하지만, 한 설치 파일 안에서 바꿔 쓰는 두 가지 테마는 아닙니다. Android 클라이언트를 바꿀 때는 구독 가져오기 결과, 앱별 설정, 라우팅, DNS를 다시 확인하세요. 다른 앱이 기존의 로컬 설정을 자동으로 이어받는다고 가정하면 안 됩니다.
Android 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 기기 트래픽을 받습니다. 이 로컬 연결 방식은 원격 노드가 사용하는 프로토콜과는 별개입니다. 데스크톱의 ‘시스템 프록시’는 주로 시스템 프록시 설정을 따르는 앱에 영향을 줍니다. 두 방식 모두 클라이언트 설정의 라우팅을 거치므로, 연결 버튼만 보고 최종 트래픽 경로를 판단할 수는 없습니다.
- 데스크톱에서 구독 및 라우팅 관리: 현재 시스템과 노드 조합을 v2rayN이 지원하는지 먼저 확인하세요.
- Android에서 Xray 설정 사용: v2rayNG에 포함된 코어와 노드 요구 사항을 먼저 확인하세요.
- Android에서 V2Fly 설정 유지: 기존 설정의 v2flyNG 지원 여부를 확인한 뒤 규칙을 옮기세요.
포트 예시로 클라이언트·코어·원격 서버 관계 이해하기
아래에서는 각 계층의 관계를 설명하기 위해 구체적인 포트 예시를 사용합니다. 모든 클라이언트의 기본값이 아니며, 설치할 때 반드시 그대로 사용해야 하는 값도 아닙니다. 로컬 수신 주소는 127.0.0.1로 설정할 수 있고, 포트는 실제 설정을 확인해야 합니다. 원격 포트는 서버 설정과 일치해야 합니다.
위 설정에서 브라우저는 먼저 요청을 로컬 HTTP 인바운드 127.0.0.1:10809로 보냅니다. 코어는 요청을 받은 뒤 라우팅을 확인합니다. 직접 연결 규칙에 해당하면 대상에 직접 연결하고, 프록시 규칙에 해당할 때만 원격 서비스의 443 포트에 연결할 수 있습니다. 로컬 HTTP 포트를 원격 포트로 바꿔도 서버 연결 문제는 해결되지 않습니다.
앱
→ 로컬 HTTP 인바운드: 127.0.0.1:10809
→ 코어 라우팅 판단
→ 직접 연결 아웃바운드 → 대상 사이트
→ 프록시 아웃바운드 → 원격 서버:443 → 대상 사이트
일부 버전은 혼합 인바운드를 사용해 하나의 수신 포트에서 여러 종류의 프록시 요청을 받습니다. 따라서 서로 다른 두 포트를 반드시 찾아야 하는 것은 아닙니다. ‘주소가 이미 사용 중’이라는 오류가 나타나면 먼저 로컬 수신 포트 충돌을 확인하세요. 원격 핸드셰이크나 인증 오류가 발생하면 서버 매개변수를 확인해야 합니다. 두 문제는 발생 지점이 다르므로 해결 방법도 다릅니다.
전환 및 문제 해결: 현재 상태를 기록하고 하나씩 검증
코어 전환은 모든 문제를 해결하는 만능 버튼이 아닙니다. 클라이언트에 노드가 저장되어 있다고 해서 코어가 정상 실행된 것은 아니며, 코어가 실행되어도 원격 인증이 성공했다는 뜻은 아닙니다. 아래 내용은 v2rayN에서 흔히 볼 수 있는 메뉴 경로를 예로 든 것이며, 버전과 플랫폼에 따라 메뉴 이름이 달라질 수 있습니다. 해당 옵션이 없다면 같은 이름의 설정 필드를 임의로 만들지 마세요.
-
현재 상태 기록
「도움말」→「정보」를 열어 클라이언트 버전을 기록하세요. 시작 로그에서 코어 이름과 버전도 확인합니다. 현재 설정을 백업하고 활성 노드와 라우팅 선택을 메모해 두세요.
-
코어 확인
「설정」→「매개변수 설정」으로 이동해 「Core 유형」 또는 이에 해당하는 코어 유형 설정을 찾아 대상 프로토콜에 맞는 코어가 선택되어 있는지 확인하세요. 메뉴가 없다면 현재 버전의 설명서에서 지원 범위를 확인하고, 코어 파일을 바로 덮어쓰지 마세요.
-
인바운드 확인
「설정」→「매개변수 설정」에서 로컬 수신 주소와 포트를 확인하세요. 앞의 예시를 사용한다면 HTTP 요청이 10809로 전달되는지 확인하고, 혼합 인바운드를 사용한다면 인터페이스에 표시된 값을 따르세요.
-
항목별 테스트
같은 노드와 라우팅을 유지하고 호환성이 확인된 코어 선택만 변경한 뒤 저장하고 서비스를 다시 시작하세요. 첫 번째 오류 로그를 확인한 다음 프록시 접속과 직접 접속을 각각 테스트합니다. DNS·전송 방식·라우팅을 동시에 바꾸지 마세요.
구독은 설정을 배포하는 수단일 뿐, 서로 다른 코어에서 완전히 동일한 유효 설정을 제공한다고 보장하지 않습니다. 가져오는 과정에서 클라이언트는 필드를 해석해 코어 설정을 생성합니다. 전송 경로, 서비스 이름, 보안 매개변수가 누락되어도 가져오기 단계에서는 오류가 발생하지 않고 연결 단계에서 실패할 수 있습니다. 문제를 확인할 때는 원본 노드 설명과 항목별로 대조하고, 구독 주소 전체를 공개하지 마세요.
오픈소스 라이선스: 코어와 그래픽 인터페이스를 각각 확인
오픈소스 프로젝트라고 해서 모두 같은 라이선스를 사용하는 것은 아닙니다. V2Fly-core는 MIT License, Xray-core는 MPL 2.0을 사용하며, v2rayN과 v2rayNG는 GPLv3 라이선스를 따릅니다. v2flyNG를 재배포할 때도 해당 버전의 라이선스와 상속된 코드 관련 고지를 확인해야 합니다. 앱에 포함된 서드파티 의존성에는 별도의 라이선스 의무가 있을 수 있으므로, 설치 파일 이름만으로 전체 조건을 판단할 수 없습니다.
- 개인적으로 실행: 호환성, 설정 출처, 업데이트 안내를 먼저 확인하세요. 일반적인 소프트웨어 사용은 수정본을 외부에 배포하는 것과 다릅니다.
- MIT 라이선스 코드: 복사하거나 배포할 때 저작권 및 라이선스 고지를 보존해야 합니다.
- MPL 2.0 라이선스 코드: 외부에 배포할 때 라이선스 적용 대상 파일과 수정 사항에 대한 소스 코드 공개 등 관련 요건을 확인해야 합니다.
- GPLv3 프로그램: 라이선스 적용 대상 프로그램이나 수정본을 배포할 때 해당 소스 코드와 라이선스 문서를 제공해야 합니다. 코어의 허용적인 라이선스로 그래픽 인터페이스의 의무를 대신할 수는 없습니다.
위 내용은 라이선스의 핵심을 파악하기 위한 참고 사항이며, 모든 조합과 패키징 방식에 대한 법률적 판단은 아닙니다. 2차 개발, 기업 배포, 재패키징을 계획한다면 해당 버전의 LICENSE, COPYING, 서드파티 고지와 빌드 안내를 확인하세요. 사이트에 표시된 브랜드명은 상류 프로젝트와의 라이선스 또는 운영상 관계를 의미하지 않습니다.
자주 묻는 질문: 이름이 비슷한 프로젝트 구분하기
v2rayN을 설치하면 V2Fly를 사용하는 건가요?
반드시 그렇지는 않습니다. 시작 로그에서 실제 코어 이름을 확인하고 코어 유형 설정도 살펴보세요. v2rayN은 그래픽 클라이언트 이름이며, 이것만으로 실행 중인 코어를 알 수 없습니다. 문제를 제보할 때는 클라이언트와 코어 버전을 모두 적어 주세요.
같은 구독인데 다른 Android 클라이언트에서는 작동하지 않나요?
먼저 가져온 노드 수와 프로토콜을 비교하고, 전송 및 보안 매개변수와 코어 지원 여부를 확인하세요. 이어서 시스템 VPN 권한과 앱별 적용 범위를 점검합니다. 구독 업데이트에 성공했다고 해서 노드 호환성 확인을 생략하면 안 됩니다.
Xray를 사용하면 노드를 VLESS로 바꿔야 하나요?
코어 이름 때문에 프로토콜을 바꿀 필요는 없습니다. 서버가 실제로 제공하는 프로토콜을 유지하고 현재 코어의 지원 여부를 확인하세요. 클라이언트에서 VMess를 VLESS로 바꾸더라도 서버 설정이 함께 변경되지 않으면 연결에 실패합니다.
코어를 바꾼 뒤 연결은 되는데 일부 앱은 왜 직접 연결되나요?
먼저 해당 앱이 시스템 프록시 또는 Android VPN 적용 범위에 포함되는지 확인한 다음, 라우팅에서 앱이나 대상이 직접 연결로 지정되어 있는지 살펴보세요. 추가로 원인을 확인하려면 코어를 계속 바꾸기보다 문제 해결 가이드의 계층별 점검 순서에 따라 확인하세요.