코어를 선택할 때는 노드 설정을 먼저 확인한 뒤 클라이언트를 살펴보세요. VLESS와 REALITY는 같은 개념이 아니며, VLESS가 Xray 전용 프로토콜인 것도 아닙니다. REALITY 또는 xtls-rprx-vision이 포함된 설정은 Xray 지원 여부를 기준으로 선택해야 합니다. VMess 설정이 문제없이 작동한다면 이름만 바꾸려고 이전할 필요는 없습니다. 아래에서 프로젝트 관계, 프로토콜 조합, Android 클라이언트, 이전 전 확인 순서대로 살펴봅니다.
개발 분기: Xray와 V2Fly는 같은 코어의 설정 옵션이 아닙니다
Project V는 관련 도구와 프로토콜이 속한 프로젝트 생태계이며, V2Ray는 그 안에서 널리 쓰이는 코어 소프트웨어의 이름입니다. V2Fly 커뮤니티는 v2ray-core를 이어서 관리하고, Xray-core는 2020년 V2Ray 코드를 바탕으로 분기해 발전했습니다. 두 코어는 일부 역사와 설정 개념을 공유하지만, 이후 기능 개발과 릴리스 주기, 설정 항목은 완전히 같지 않습니다.
따라서 ‘V2Ray 클라이언트’라는 말만으로 어떤 코어가 실행 중인지 알 수는 없습니다. 클라이언트는 구독 관리, 노드 선택, 화면 조작을 담당하고, 코어는 연결을 구성하고 인바운드·아웃바운드를 처리하며 라우팅을 실행합니다. 클라이언트에 노드 이름이 표시되더라도 실제로 생성된 설정이 현재 코어에서 받아들여진다는 뜻은 아닙니다.
- 프로젝트: V2Fly와 Xray는 서로 다른 유지보수 분기입니다. 양쪽 버전 번호는 숫자 크기만으로 비교할 수 없습니다.
- 코어: 창 제목이나 설치 폴더명이 아니라 시작 로그에 표시된 코어 이름과 버전을 확인하세요.
- 클라이언트: v2rayN은 데스크톱 클라이언트이며, 이 글에서 다루는 Android 클라이언트는 v2rayNG와 v2flyNG입니다.
- 노드: 같은 프로토콜 이름이라도 전송 방식, 보안 계층, 추가 설정을 함께 확인해야 호환성을 판단할 수 있습니다.
프로토콜 지원: VLESS, REALITY, Vision을 구분하세요
노드 호환성을 확인할 때는 최소한 네 가지 계층을 살펴봐야 합니다. 프록시 프로토콜, 하위 전송 방식, 전송 보안, 프로토콜별 추가 동작입니다. VMess와 VLESS는 프록시 프로토콜이고, WebSocket은 전송 방식입니다. TLS와 REALITY는 전송 보안 관련 설정이며, xtls-rprx-vision은 특정 조합에서 사용하는 flow 값이지 독립된 노드 프로토콜이 아닙니다.
| 설정 항목 | Xray | V2Fly | 확인 사항 |
|---|---|---|---|
| VMess + WebSocket + TLS | 일반적인 지원 조합 | 일반적인 지원 조합 | 주소, 포트, 경로, Host, TLS 서버 이름 |
| VLESS | 지원함. 전체 설정 조합을 확인해야 합니다. | VLESS 구현은 있지만, Xray 확장 기능 지원 여부를 단정할 수 없습니다. | 전송 방식, 보안 계층, flow 및 버전 요구 사항 |
| REALITY | 지원되는 버전과 조합에서 사용 | Xray REALITY 설정과 호환되는 것으로 간주하지 마세요. | 서버 이름, 공개 키 관련 매개변수, shortId |
| xtls-rprx-vision | 해당 Xray 조합과 버전에 맞춰 사용 | 해당 flow를 그대로 적용할 수 없습니다. | 서버의 flow 및 클라이언트 전송 조합 |
예를 들어 VLESS 노드에 security=reality와 flow=xtls-rprx-vision이 함께 설정되어 있다면 해당 조합을 지원하는 Xray 코어를 선택해야 합니다. 반대로 노드 주소가 vless://로 시작한다는 사실만으로 REALITY가 필수라고 단정할 수 없으며, 모든 VLESS 클라이언트에서 사용할 수 있다는 뜻도 아닙니다.
- 호환성 문제를 해결하겠다며 REALITY를 일반 TLS로 바꾸지 마세요. 서버 설정을 함께 변경하지 않는다면 두 설정은 서로 대체할 수 없습니다.
- flow를 삭제했다고 호환된다고 단정하지 마세요. 설정이 로드되더라도 핸드셰이크 단계에서 실패할 수 있습니다.
- VMess도 시간 동기화, 사용자 ID, 전송 매개변수를 확인해야 합니다. 프로토콜을 지원한다고 해서 설정까지 올바른 것은 아닙니다.
클라이언트 선택: Android는 노드 요구 사항에 맞추고, 데스크톱은 코어부터 확인
Android에서 v2rayNG와 v2flyNG의 가장 큰 차이는 사용하는 코어 계열입니다. Xray 기능이 필요한 노드에는 v2rayNG를 우선 고려하세요. V2Fly 설정을 기반으로 사용 중이며 Xray 전용 항목에 의존하지 않는 환경이라면 v2flyNG를 계속 사용할 수 있습니다. 이 추천은 설정 호환 범위를 기준으로 한 것이며, 모든 네트워크 환경의 성능 순위를 뜻하지는 않습니다.
v2rayNG · Xray 코어
추천Android 노드에 REALITY, Vision 등 Xray 기능이 포함되어 있다면 해당 항목을 가져올 수 있는 v2rayNG 버전을 우선 선택하세요. 가져온 뒤에도 노드 세부 정보와 시작 로그를 확인해야 합니다.
추천 대상: Android에서 Xray 설정을 사용하거나 구독에 REALITY 노드가 포함된 경우
v2flyNG · V2Fly 코어
이미 사용 가능 여부를 확인한 V2Fly 설정에 적합합니다. VMess처럼 양쪽에서 공통으로 지원하는 프로토콜 조합은 실제 전송 설정을 확인하면 되므로, 개발 분기만을 이유로 클라이언트를 바꿀 필요는 없습니다.
추천 대상: Android에서 V2Fly 설정과 기존 라우팅 및 사용 방식을 유지하려는 경우
데스크톱에서 v2rayN을 사용할 때는 현재 설치 패키지와 설정 유형, 클라이언트 버전에서 어떤 코어를 선택할 수 있는지 먼저 확인하세요. 모든 버전에서 같은 위치에 동일한 전환 버튼이 있다고 가정하지 마세요. 설정을 적용한 뒤 선택한 구성을 다시 시작하고 로그에서 실제로 로드된 코어를 확인하세요. 다운로드 폴더에 코어 파일이 있다고 해서 현재 연결에 그 파일이 사용되는 것은 아닙니다.
두 가지 설정 환경별 선택 방법
노드가 Xray 기능에 의존하는 경우
- 데스크톱: v2rayN에서 지원되는 Xray 설정을 사용합니다.
- Android: 같은 제공처의 호환 구독을 v2rayNG에 가져옵니다.
- REALITY 매개변수와 flow를 확인하고 제공처의 원래 값을 유지합니다.
기존 V2Fly 설정이 작동하는 경우
- Android: v2flyNG에서 검증된 노드를 유지합니다.
- 데스크톱: 현재 v2rayN 버전의 설정 지원 여부에 맞춰 처리합니다.
- 이전하기 전에 구독, 라우팅, DNS 설정을 각각 저장합니다.
같은 구독을 사용한다는 것은 설정 출처가 같다는 뜻일 뿐입니다. 양쪽 클라이언트의 항목 해석, 라우팅, DNS 설정은 각각 확인해야 합니다.
전환 점검: 로컬 포트, 구독 변환, 라우팅을 함께 확인
코어를 바꾼 뒤 웹페이지가 열리지 않더라도 프로토콜 호환성 문제라고 단정할 수는 없습니다. 이전 클라이언트가 로컬 수신 포트를 계속 사용 중이거나 브라우저가 이전 포트를 가리킬 수 있습니다. 아래 숫자는 SOCKS 및 HTTP 진입점의 예시일 뿐이며 모든 클라이언트나 버전의 기본값은 아닙니다. 실제 설정과 시작 로그를 기준으로 확인하세요.
- 기존 설정을 저장합니다. 구독 출처, 선택한 노드, DNS, 라우팅, 로컬 포트를 기록하세요. 구독 링크에는 접속 정보가 포함될 수 있으므로 백업을 공개적으로 공유하지 마세요.
- 기존 연결을 중지합니다. 다른 클라이언트의 프록시 연결을 종료하세요. Android에서는 기존 VPN 연결을 먼저 중지한 뒤 대상 클라이언트를 실행해야 연결 인계 문제를 프로토콜 문제로 오해하지 않습니다.
- 구독을 다시 가져옵니다. 제공처가 출력한 형식이 대상 클라이언트에 맞는지 확인하세요. 한 코어용 전체 JSON을 다른 코어에서도 사용할 수 있는 범용 설정으로 간주하지 마세요.
- 실제 수신 포트를 확인합니다. 앱이
127.0.0.1:10809을 가리키는데 로그에는 다른 HTTP 포트만 표시된다면 노드를 계속 바꾸지 말고 앱의 프록시 설정을 수정하세요. - 라우팅을 따로 검증합니다. 먼저 대상 연결이 수립되는지 확인한 뒤, 직접 연결할 요청과 프록시를 거칠 요청이 예상한 경로로 나가는지 점검하고 마지막에 사용자 지정 규칙을 복원하세요.
구독 업데이트 성공은 콘텐츠를 가져와 클라이언트가 파싱했다는 뜻일 뿐, 모든 항목이 온전히 보존되었다는 보장은 아닙니다. 이전 후 노드 세부 정보에서 서버 이름, WebSocket 경로, REALITY 매개변수가 누락되었다면 이름만 보고 값을 임의로 채우지 말고 설정 제공처에 호환 형식을 요청하세요. 사용자 지정 DNS, 도메인 일치 정책, 규칙 세트도 노드 목록이 같다고 자동으로 동일하게 적용되지는 않습니다.
로그 확인: 시작 실패와 연결 실패를 구분하세요
코어가 시작된다는 것은 현재 버전의 설정 로드 검사를 통과했다는 뜻일 뿐입니다. 연결 실패는 도메인 조회, TCP 연결, TLS 또는 REALITY 핸드셰이크 단계에서 발생할 수 있습니다. ‘코어를 바꿔서 속도가 느려졌다’고 단정하기보다 먼저 어느 단계에서 문제가 생기는지 확인하세요.
| 로그 단서 | 우선 확인할 사항 | 다음 조치 |
|---|---|---|
unknown field 또는 설정 파싱 오류 |
항목, 형식 또는 코어 버전이 일치하지 않음 | 가져온 형식과 실제 코어, 오류가 난 항목을 확인하고 보안 매개변수부터 삭제하지 마세요. |
address already in use |
로컬 수신 포트 사용 중 | 중복 실행 중인 클라이언트를 중지하거나 수신 포트를 변경한 뒤 앱의 프록시 설정도 함께 수정하세요. |
timeout |
로그 맥락에 따라 타임아웃이 발생한 단계를 확인해야 합니다. | 서버 주소와 포트, 네트워크를 확인한 다음 핸드셰이크 매개변수를 점검하세요. |
| 핸드셰이크 관련 오류 | 보안 계층 매개변수와 서버 설정이 일치하지 않음 | 서버 이름, 시간, 해당 인증 매개변수를 확인하고 설정 제공처에 문의하세요. |
클라이언트 선택 FAQ: 코어 이름만으로 속도와 호환성을 판단하지 마세요
구독에 VMess만 있는데 Xray로 바꿔야 하나요?
이름만을 이유로 바꿀 필요는 없습니다. 현재 전송 방식과 TLS, 라우팅이 제대로 작동하는지 먼저 확인하세요. 기존 V2Fly 설정이 문제없이 작동한다면 그대로 사용해도 됩니다. 이전이 꼭 필요하다면 같은 노드를 사용해 기능을 하나씩 비교하고, DNS와 분할 라우팅 규칙을 동시에 바꾸지 마세요.
v2flyNG에서 VLESS를 가져왔는데 연결되지 않습니다. 어떻게 확인하나요?
노드 세부 정보에서 REALITY 또는 xtls-rprx-vision이 설정되어 있는지 확인하세요. 이러한 Xray 기능에 의존한다면 해당 조합을 지원하는 v2rayNG를 사용하고 제공처에서 설정을 다시 가져오세요. 인식되지 않는 항목만 삭제하는 방식으로 해결하려 하지 마세요.
같은 노드라면 Xray가 항상 V2Fly보다 빠른가요?
그렇게 판단할 수 없습니다. 서버, 전송 조합, 접속 네트워크, 테스트 대상을 동일하게 두고 연결 성공률과 실제 전송 성능을 각각 확인해야 합니다. 노드 경로, 서버 부하, DNS 차이가 코어 이름보다 결과에 더 큰 영향을 줄 수 있습니다.
코어를 바꾼 뒤 TUN을 다시 켜야 하나요?
먼저 기존 트래픽 연결 방식을 확인하세요. 시스템 프록시를 사용하는 일반 브라우저라면 TUN을 끈 상태로 연결을 먼저 테스트할 수 있습니다. 시스템 프록시를 따르지 않는 앱까지 연결해야 하는 경우에만 클라이언트 안내에 따라 TUN을 켜고 권한과 라우팅을 확인하세요.
선택 과정은 세 단계로 요약할 수 있습니다. 노드가 Xray 기능에 의존하는지 확인하고, 설정을 빠짐없이 표현할 수 있는 클라이언트를 선택한 다음, 로그와 로컬 트래픽 진입점을 점검하세요. V2Fly와 Xray가 공유하는 역사는 호환성 확인을 대신할 수 없으며, 클라이언트 화면이 비슷하다고 가져온 설정까지 완전히 같다는 뜻은 아닙니다.