Project V는 초기 프로젝트 체계이고, V2Fly는 V2Ray Core를 이어서 유지보수하는 커뮤니티 기반 분기입니다. Xray는 기존 설정과의 호환성을 바탕으로 프로토콜과 전송 기능을 확장한 또 다른 Core 계열입니다. 글을 읽고 나면 프로젝트명·Core 이름·클라이언트 이름을 구분하고, 구독의 VMess, VLESS, XTLS Vision, REALITY 등의 필드에 맞는 클라이언트를 선택할 수 있습니다.
Project V는 특정 클라이언트 하나를 뜻하지 않는 프로젝트 체계입니다
Project V는 네트워크 프록시 기능을 중심으로 만들어진 오픈소스 도구와 사양 집합을 가리키는 이름으로 시작했습니다. V2Ray Core는 그 안에서 연결·프로토콜·라우팅·아웃바운드를 처리하는 핵심 프로그램입니다. 일상적인 대화에서는 Project V, V2Ray, GUI 클라이언트를 한데 묶어 말하기 쉽지만, 세 용어는 서로 다른 계층에 속합니다.
Core는 설정을 받은 뒤 인바운드와 아웃바운드 연결을 구성합니다. 리슨 주소, 포트, 사용자 식별자, 전송 방식, TLS 매개변수와 라우팅 규칙을 읽고 트래픽을 어느 출구로 보낼지 결정합니다. 클라이언트는 Core를 감싸 구독 업데이트, 노드 목록, 지연 시간 측정, 시스템 프록시 전환, 로그 확인 기능을 제공합니다. 특정 작업을 버튼으로 수행할 수 있는지는 GUI 구현에 달려 있고, 특정 프로토콜로 연결할 수 있는지는 주로 호출되는 Core가 결정합니다.
- 프로젝트 계층: Project V는 초기 전체 생태계와 발전 과정을 설명하는 이름이며, 설치 후 바로 클릭해 사용하는 애플리케이션 이름이 아닙니다.
- Core 계층: V2Ray Core, V2Fly Core, Xray Core가 설정을 해석하고 프로토콜을 처리하며 라우팅과 연결 구성을 담당합니다.
- 클라이언트 계층: v2rayN, v2rayNG, v2flyNG가 구독·노드·로그·시스템 프록시 등의 작업을 GUI로 제공합니다.
- 서비스 계층: 구독이 노드 매개변수를 제공하면 클라이언트가 이를 가져와 해당 Core에 전달합니다. 구독 자체는 Core가 아닙니다.
V2Fly와 Xray는 왜 서로 다른 두 경로가 되었을까요
프로젝트가 커뮤니티 중심 유지보수 단계로 넘어간 뒤 V2Fly는 기존 V2Ray 코드 체계와 설정 구조, 범용 프록시 기능을 이어갔습니다. VMess, VLESS, Shadowsocks, SOCKS, HTTP 같은 일반적인 인바운드·아웃바운드 방식을 사용하는 사용자에게 V2Fly는 지금도 유지보수되는 Core 경로입니다. 단순히 옛 이름을 바꾼 것이 아니라 독립적인 릴리스 주기와 문서 체계를 갖춘 커뮤니티 프로젝트입니다.
Xray는 V2Ray 코드 기반에서 발전했으며, 서로 유사한 JSON 설정 구조를 상당 부분 유지하면서 VLESS, XTLS, Vision, REALITY 등의 기능을 계속 확장했습니다. 역사적으로 코드 기반이 가까워 기본 필드는 서로 해석되는 경우가 많지만, 모든 프로토콜 매개변수·전송 옵션·라우팅 동작이 완전히 같다고 볼 수는 없습니다.
| 비교 항목 | V2Fly Core | Xray Core |
|---|---|---|
| 발전 관계 | V2Ray 체계를 이어가는 커뮤니티 유지보수 경로 | V2Ray를 기반으로 발전한 독립 분기 |
| 기본 설정 | JSON으로 인바운드·아웃바운드·DNS·라우팅을 정의 | 유사한 구조를 유지하면서 자체 확장 필드를 추가 |
| 주요 프로토콜 | VMess·VLESS·SOCKS·HTTP 등 | VMess·VLESS 및 XTLS Vision·REALITY 조합을 중점 지원 |
| 판단 기준 | 구독에서 V2Fly를 명시적으로 요구하거나 기존 설정이 해당 Core에서 안정적으로 작동하는 경우 | 노드에 Xray 확장 필드가 포함되어 있거나 Xray Core를 명시적으로 요구하는 경우 |
| 호환성의 한계 | Xray에서만 구현된 전용 매개변수를 그대로 실행할 수 없음 | 기존 구조를 많이 읽을 수 있지만 V2Fly와 모든 동작이 항목별로 일치한다고 보장할 수 없음 |
결론: 노드 필드로 Core를 추정하기
구독에 security=reality, flow=xtls-rprx-vision, 서버 공개 키 또는 짧은 식별자가 있으면 Xray Core를 우선 사용하세요. VMess·WebSocket·TLS 같은 범용 필드만 있다면 현재 클라이언트와 서버 안내를 기준으로 선택하면 됩니다.
버전은 구체적인 오류 상황과 함께 판단해야 합니다. 새 버전에서는 작동하지만 오래된 버전에서 “unsupported security” 또는 “unknown field”가 발생한다면, 이전 Core가 구현하지 않은 필드가 설정에 포함되었을 가능성이 큽니다. GUI만 바꾸지 말고 실제 실행 로그에 기록된 Core 이름과 버전도 함께 확인하세요.
v2rayN·v2rayNG·v2flyNG는 각각 어떤 Core를 호출할까요
세 소프트웨어 모두 클라이언트 외피이며 프로토콜 자체는 아닙니다. v2rayN은 Windows 데스크톱 환경에서 구독 그룹·서버 목록·라우팅 규칙·시스템 프록시·Core 프로세스를 관리합니다. v2rayNG와 v2flyNG는 Android 기기용이며, 가장 뚜렷한 차이는 기본 Core 경로가 다르다는 점입니다.
아래 버전은 GUI와 로그 확인 방법을 설명하기 위한 예시일 뿐 버전 상한을 의미하지 않습니다. 테스트 기록에는 v2rayN 7.12.5, v2rayNG 1.10.16, v2flyNG 1.10.13을 사용했습니다. 이후 버전에서는 메뉴 문구가 바뀔 수 있지만 “클라이언트는 설정을 관리하고 Core는 연결을 실행한다”는 계층 관계는 변하지 않습니다.
| 클라이언트 | 플랫폼 | Core 관계 | 우선 사용하면 좋은 상황 |
|---|---|---|---|
| v2rayN | Windows 데스크톱 클라이언트 | 일반적으로 Xray Core를 사용하며 지원되는 패키지에서는 Core 유형을 관리할 수 있음 | 구독 그룹·일괄 테스트·시스템 프록시·세밀한 라우팅이 필요한 경우 |
| v2rayNG | Android 클라이언트 | Xray Core 경로 사용 | 노드에 VLESS·XTLS Vision 또는 REALITY 매개변수가 포함된 경우 |
| v2flyNG | Android 클라이언트 | V2Fly Core 경로 사용 | 구독에서 V2Fly 호환을 명시했거나 검증된 V2Fly 설정을 재사용해야 하는 경우 |
- 이름이 비슷해도 Core가 같은 것은 아닙니다: v2rayNG와 v2flyNG는 GUI 조작 방식이 비슷할 수 있지만 확장 프로토콜 필드 처리 능력은 각 Core가 결정합니다.
- 가져오기에 성공했다고 연결되는 것은 아닙니다: 클라이언트가 링크를 노드 카드로 해석할 수 있어도 Core가 지원하지 않는 프로토콜·전송·인증 매개변수 때문에 실행에 실패할 수 있습니다.
- 속도 측정에 성공했다고 라우팅이 올바른 것은 아닙니다: 지연 시간 측정은 특정 탐색 경로가 응답했다는 사실만 보여 줍니다. 시스템 프록시·DNS·분할 라우팅 규칙은 별도로 확인해야 합니다.
- 포트가 같다고 같은 노드는 아닙니다:
10808,10809는 보통 로컬 리슨 포트이고, 원격 노드에서 흔히 보이는443은 서버 연결 매개변수입니다.
클라이언트에서 현재 Core 확인하기
문제 해결 전에 재현 가능한 기록을 남기세요. 클라이언트 버전, Core 이름, Core 버전, 노드 프로토콜, 로컬 포트, 첫 번째 오류 로그를 적어 두면 됩니다. “연결되지 않음”만 기록해서는 구독 만료·Core 비호환·포트 충돌·DNS 이상·서버 연결 거부를 구분할 수 없습니다.
v2rayN에서는 메뉴에서 Core 유형을 바로 확인할 수 있고, Android에서는 앱 정보와 실행 로그를 확인해야 합니다. Core를 바꾸기 전에는 현재 연결을 먼저 중지해 기존 프로세스가 127.0.0.1:10808을 계속 점유하지 않도록 하세요. 그렇지 않으면 새 Core가 시작될 때 리슨 실패가 발생할 수 있습니다.
버전 기록
클라이언트의 “정보” 또는 버전 정보 화면을 열어 클라이언트 버전을 기록하세요. 그런 다음 실행 로그 첫 부분에서 Xray Core 또는 V2Fly Core의 버전 행을 찾습니다.
유형 확인
v2rayN에서 「설정」→「매개변수 설정」→「Core 유형」으로 이동해 대상 노드에 맞는 Core가 선택되었는지 확인하세요.
프로토콜 대조
노드를 편집해 주소·원격 포트·사용자 식별자·전송 방식·TLS·SNI·Flow를 확인하세요. REALITY 노드는 공개 키·짧은 식별자·지문 필드도 대조해야 합니다.
Core 재시작
설정을 저장한 뒤 서비스를 중지하고 Core를 다시 시작하세요. 로그에
address already in use,unknown field또는 인증 실패 메시지가 없는지 확인합니다.출구 검증
시스템 프록시를 켠 뒤 대상 사이트에 접속하고, 연결 로그에서 예상한 아웃바운드 태그가 적용되었는지 확인하세요. 분할 라우팅을 사용하는 경우 직결 규칙과 프록시 규칙이 서로 덮어쓰지 않는지도 함께 확인해야 합니다.
메뉴에 전환 가능한 Core 유형이 없다면 다른 플랫폼의 Core 파일을 복사해 클라이언트 디렉터리를 덮어쓰지 마세요. v2rayNG와 v2flyNG는 각자의 Core 경로에 맞게 사용해야 합니다. 경로를 바꿔야 한다면 먼저 구독 주소를 내보내거나 보관한 뒤 해당 클라이언트를 설치하고 다시 가져오세요.
설정 호환성이 프로토콜 기능의 동일함을 뜻하지는 않습니다
V2Fly Core와 Xray Core는 모두 구조화된 설정으로 연결을 정의하므로 inbounds, outbounds, routing, dns 같은 필드가 비슷하게 보입니다. 유사한 구조는 기본 설정을 옮기기 쉽게 해 주지만, 실제 호환성을 결정하는 것은 각 프로토콜 객체 내부 필드의 의미와 서버에서 실제로 활성화한 전송 조합입니다.
VLESS를 예로 들면 프로토콜 이름만 확인해서는 부족합니다. 전송 계층이 TCP·WebSocket·gRPC 중 무엇인지, 보안 계층이 TLS·REALITY 중 무엇인지, Flow가 xtls-rprx-vision인지까지 확인해야 합니다. 두 노드가 모두 VLESS라고 표시되어도 필요한 Core 기능은 완전히 다를 수 있습니다.
| 구독 또는 로그 단서 | 확인해야 할 계층 | 수행할 작업 |
|---|---|---|
vmess:// |
VMess 사용자 정보와 전송 방식 | 사용자 식별자·원격 포트·Host·Path·TLS 설정 대조 |
vless:// |
VLESS 암호화·보안 계층·Flow | Vision 또는 REALITY 매개변수가 포함되어 있는지 추가 확인 |
security=reality |
Xray 확장 기능 | Xray Core를 사용하고 공개 키·SNI·짧은 식별자·지문 대조 |
unknown field |
설정 구조 또는 Core 버전 | 가져오기 대상과 Core 유형을 확인하고 알 수 없는 필드를 직접 삭제하지 않기 |
address already in use |
로컬 리슨 포트 | 중복 프로세스를 종료하고 10808과 10809의 점유 여부 확인 |
결론: 핸드셰이크 매개변수부터 확인한 뒤 속도 측정하기
Core가 노드의 보안 계층을 지원하지 않는다면 지연 시간 숫자는 선택 기준으로 의미가 없습니다. 먼저 로그에서 프로토콜 초기화와 핸드셰이크가 완료되도록 한 다음 실제 연결 지연 시간·패킷 손실·라우팅 결과를 비교하세요.
라우팅 규칙도 구현 세부 사항에 차이가 있습니다. 기본적인 도메인·IP·포트·인바운드 태그 매칭은 대체로 옮기기 쉽지만, 복잡한 DNS 분할, 규칙 세트 로딩 방식, 특정 아웃바운드 매개변수는 대상 Core 문서에 따라 다시 확인해야 합니다. 이전 후에는 프록시 도메인 하나, 직결 도메인 하나, DNS 조회 한 번 이상을 테스트하세요. 클라이언트 상태 표시줄이 “연결됨”으로 바뀌었는지만 확인해서는 안 됩니다.
자주 혼동하는 내용과 구체적인 해결 방법
가장 흔한 오류는 프로젝트 이름을 잘못 기억하는 것이 아니라 “클라이언트 가져오기 성공”을 “Core가 완전히 지원함”으로 착각하는 것입니다. 구독 링크는 매개변수를 전달하고, 클라이언트는 이를 해석·표시하며, Core는 실제로 실행합니다. 어느 한 계층에서든 필드가 누락되면 최종 연결이 실패할 수 있습니다.
구독에 V2Ray라고 적혀 있으면 어떤 클라이언트를 선택해야 하나요?
구독 이름만 보지 마세요. 노드 상세 정보를 열고 프로토콜과 보안 계층부터 확인하세요. REALITY 또는 xtls-rprx-vision이 포함되어 있다면 Windows에서는 v2rayN의 Xray Core를, Android에서는 v2rayNG를 사용하세요.
VMess 노드는 반드시 V2Fly를 사용해야 하나요?
그렇지 않습니다. V2Fly Core와 Xray Core 모두 일반적인 VMess 설정을 처리할 수 있습니다. 전송 방식·TLS·Host·Path·사용자 식별자·서버 요구 사항을 추가로 확인한 뒤 현재 플랫폼에서 정상적으로 유지보수되는 클라이언트를 선택하세요.
v2rayNG를 V2Fly Core로 바로 바꿀 수 있나요?
앱 디렉터리에서 Core를 수동으로 교체하지 마세요. V2Fly 경로가 필요하다면 v2flyNG를 사용하고, 구독을 다시 가져온 뒤 노드 필드를 확인하세요. 실행 로그에서 실제로 V2Fly Core가 시작되었는지도 확인해야 합니다.
Core를 바꾼 뒤 포트 오류가 발생하는 이유는 무엇인가요?
먼저 기존 Core와 중복 실행 중인 클라이언트를 중지한 뒤 로컬 컴퓨터의 10808, 10809가 여전히 사용 중인지 확인하세요. 리슨 포트를 변경했다면 브라우저나 시스템 프록시 설정도 함께 업데이트해야 합니다.
가져오기는 성공했지만 REALITY 노드에 연결되지 않나요?
Xray Core를 사용하고 있는지 확인한 다음 서버 주소·포트·사용자 식별자·SNI·공개 키·짧은 식별자·지문·xtls-rprx-vision을 하나씩 대조하세요. 어느 한 필드라도 빠지면 핸드셰이크가 실패할 수 있습니다.
플랫폼과 노드 프로토콜에 맞춰 선택하기
선택할 때 프로젝트의 전체 역사를 먼저 공부할 필요는 없습니다. 정해진 순서대로 기기 플랫폼을 확인하고, 구독 프로토콜과 확장 필드를 살핀 다음, 데스크톱 라우팅·일괄 속도 측정·Android 상시 연결이 필요한지 판단하면 됩니다. 프로젝트 역사는 차이를 설명하지만 실제 선택의 기준은 노드 매개변수입니다.
- Windows 데스크톱: v2rayN을 선택하세요. 구독을 가져온 뒤 「설정」→「매개변수 설정」→「Core 유형」을 확인하고, REALITY 및 XTLS Vision 노드에는 Xray Core를 사용합니다.
- Android에서 구독이 Xray 기능 중심인 경우: v2rayNG를 선택하고 VLESS·REALITY·SNI·공개 키·짧은 식별자·Flow를 중점적으로 확인하세요.
- Android에서 서비스 제공자가 V2Fly 호환을 명시한 경우: v2flyNG를 선택하고 노드 필드를 서버 안내와 일치시키세요. Xray 전용 매개변수는 적용하지 마세요.
- VMess 또는 범용 VLESS만 있는 경우: 두 Core 경로 모두 사용할 수 있습니다. 우선 연결이 검증된 조합을 유지하고, 로그를 확인한 뒤 교체 여부를 결정하세요.
- 직접 작성한 JSON 설정인 경우: 이전하기 전에 원본 설정을 백업하고 인바운드·아웃바운드·DNS·라우팅 필드를 하나씩 확인하세요. “파일을 불러올 수 있음”을 호환이 끝났다는 의미로 받아들이지 마세요.