Xray 코어와 V2Fly 코어 비교: REALITY·XTLS Vision 지원 및 설정 호환성

클라이언트·코어·노드 프로토콜 구분하기

v2rayN은 구독 관리, 노드 편집, 시스템 프록시 설정, 코어 프로세스 관리를 담당하는 데스크톱 클라이언트입니다. Xray와 V2Fly는 실제 프록시 트래픽을 처리하는 코어입니다. 특정 클라이언트를 설치했다고 해서 현재 연결이 반드시 특정 코어를 사용하는 것은 아닙니다. 실행 로그에 표시된 코어 이름과 버전, 시작 결과를 확인하세요.

V2Fly 커뮤니티는 V2Ray 프로젝트를 유지 관리합니다. Xray는 V2Ray 프로젝트에서 분기되어 발전했으며, 이후 전송 방식과 보안 메커니즘, 설정 필드에서 독자적인 개발 방향을 이어 왔습니다. 두 코어는 공통된 기원을 갖지만 새 기능이 동시에 추가된다고 볼 수 없으며, 전체 JSON 설정을 서로 그대로 바꿔 쓸 수 있는 것도 아닙니다.

• 클라이언트 계층: v2rayN, v2rayNG, v2flyNG는 사용자 인터페이스를 제공하고 구독을 가져와 코어를 실행합니다.
• 코어 계층: Xray 또는 V2Fly가 설정을 해석하고 인바운드·아웃바운드 연결을 구성해 라우팅 규칙을 적용합니다.
• 프로토콜 계층: VMess, VLESS, Trojan 등은 프록시 통신 방식을 가리키며 클라이언트 이름과는 다릅니다.
• 전송·보안 계층: TCP, WebSocket, TLS, REALITY 등의 설정이 함께 연결 조건을 결정합니다. 노드 목록에 표시된 프로토콜 이름만 확인해서는 안 됩니다.

Android의 v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 데스크톱에서 v2rayN을 사용할 때는 현재 버전에서 선택할 수 있는 코어와 해당 노드가 실제로 사용하는 코어를 확인하세요. 인터페이스에서 노드를 저장할 수 있다는 것은 입력값 검사를 통과했다는 뜻일 뿐, 코어가 연결을 성공적으로 설정했다는 의미는 아닙니다.

REALITY·XTLS Vision 및 주요 프로토콜 비교

REALITY와 XTLS Vision은 서로 다른 문제를 해결합니다. REALITY는 Xray가 제공하는 전송 보안 메커니즘입니다. Vision은 xtls-rprx-vision으로 표시되는 흐름 제어 방식으로, 주로 VLESS 설정에서 사용됩니다. 두 기능은 함께 쓰이는 경우가 많지만 같은 설정 항목은 아니며, 요구 조건을 충족하는 TLS 설정에서도 Vision을 사용할 수 있습니다.

REALITY 노드에서 클라이언트는 보통 서버가 제공하는 공개 키 관련 매개변수, serverName, shortId와 클라이언트 지문 등의 설정이 필요합니다. 서버 개인 키를 클라이언트에 입력해서는 안 됩니다. 공유 링크, 클라이언트 입력 양식, 코어 JSON의 필드 이름은 서로 다를 수 있습니다. 필드명을 그대로 복사하기보다 사용 중인 버전의 안내에 따라 대응하는 항목을 입력하세요.

노드 요구 사항에 따라 Xray 또는 V2Fly 선택

구독에 REALITY 또는 Vision 노드가 포함되어 있다면 해당 기능을 지원하는 Xray 클라이언트를 우선 선택하세요. 기존 설정이 V2Fly 환경에서 안정적으로 작동하고 양쪽이 지원하는 프로토콜과 전송 방식을 사용한다면, 먼저 기존 환경을 유지한 채 검증한 후 이전할 수 있습니다. 코어 선택은 속도 순위가 아닙니다. 실제 사용 경험은 회선 혼잡도, 서버 부하, 로컬 네트워크에도 좌우됩니다.

‘새 코어’라고 해서 모든 기존 노드를 그대로 가져올 수 있는 것은 아닙니다. 클라이언트의 구독 파서도 설정 변환에 관여하므로 같은 공유 링크도 클라이언트에 따라 다른 필드로 해석될 수 있고, 일부 확장 매개변수가 누락될 수 있습니다. 클라이언트를 바꾼 뒤에는 구독을 반복해서 갱신하기보다 노드 편집 화면에서 항목별로 확인하는 편이 문제를 찾기 쉽습니다.

설정 이전 시 확인할 다섯 가지 필드

설정을 옮길 때는 먼저 노드 하나만 가져와 작동 여부를 확인한 뒤 전체 구독을 가져오세요. 전체 설정에는 원격 연결뿐 아니라 로컬 리스너, DNS, 라우팅, 아웃바운드 태그도 포함됩니다. 노드 정보만 옮기면 변수를 통제하기 쉽습니다. 전체 JSON을 덮어쓰면 앱의 연결 방식과 분기 결과까지 함께 바뀔 수 있습니다.

1. 현재 환경을 기록합니다. 클라이언트 로그에서 코어 이름과 버전을 확인하고 기존 설정의 사본을 저장하세요. v2rayN에서는 먼저 「설정」→「매개변수 설정」을 열어 로컬 리스너 관련 항목을 확인할 수 있습니다. 버전에 따라 탭 이름이 다를 수 있으니 현재 화면을 기준으로 확인하세요.
2. 원격 서버 정보를 확인합니다. 서버 주소, 포트, UUID 또는 비밀번호를 확인하세요. 포트는 서버 측에서 지정한 값입니다. 다른 노드가 443을 사용한다고 해서 현재 노드의 포트도 443으로 바꾸면 안 됩니다.
3. 전송 설정을 확인합니다. WebSocket의 path와 Host, TLS의 serverName, REALITY 매개변수는 모두 서버 설정과 일치해야 합니다. Host와 serverName은 용도가 다릅니다. 값이 같더라도 하나의 필드로 합칠 수 없습니다.
4. 보안 및 흐름 제어 설정을 확인합니다. TLS와 REALITY 중 어떤 방식을 사용하는지, xtls-rprx-vision이 필요한지 확인하세요. 가져온 뒤 VLESS라고 표시되어도 이러한 추가 조건이 모두 유지되었다는 뜻은 아닙니다.
5. 로컬 정책을 다시 설정합니다. DNS, 라우팅 순서, 아웃바운드 태그, 시스템 프록시를 다시 확인하세요. 존재하지 않는 outboundTag를 참조하면 설정 시작에 실패하거나 예상과 다른 트래픽 분기가 발생할 수 있습니다.

V2Fly에는 서로 다른 설정 형식과 개발 방향이 있으며, Xray도 필드와 유효성 검사 규칙을 변경할 수 있습니다. 따라서 둘 다 JSON이라고 해서 구조까지 같은 것은 아닙니다. 알 수 없는 필드, 잘못된 전송 설정, 지원되지 않는 flow 오류가 발생하면 먼저 설정을 읽는 코어와 형식을 확인한 뒤 오류가 발생한 필드를 살펴보세요. 오류 항목을 한꺼번에 삭제하지 마세요.

세 숫자는 서로 다른 용도의 예시이며 그대로 입력하라는 권장 설정이 아닙니다. 원격 포트는 서버에 연결할 때 사용하고, 로컬 포트는 앱이 프록시에 접속할 때 사용합니다. 예를 들어 브라우저가 로컬 HTTP 포트를 사용하려면 코어에서 해당 리스너를 실제로 제공해야 합니다. 현재 혼합 포트를 사용 중이라면 실제 리스너 유형에 맞게 설정하고 이전 클라이언트의 포트 값을 그대로 따라 하지 마세요.

데스크톱과 Android에서 구독을 사용하는 방법

하나의 구독에 여러 프로토콜이 포함될 수 있습니다. 데스크톱에서 가져오기에 성공했다고 해서 Android에서도 모든 항목을 지원한다는 뜻은 아닙니다. 서비스 제공업체가 클라이언트 유형에 따라 다른 내용을 제공할 수도 있으므로, 양쪽에서 노드 이름이 같더라도 프로토콜, 전송 방식, 보안 필드가 일치하는지 확인해야 합니다.

Mac의 시스템 프록시는 주로 시스템 프록시 설정을 따르는 앱에 영향을 줍니다. Android 클라이언트는 대개 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 두 방식은 연결 경로가 다르므로 Android에서 웹페이지가 열린다는 사실만으로 Mac 시스템 프록시가 올바르게 설정되었다고 볼 수 없습니다. 문제를 확인할 때는 먼저 코어가 실행되는지, 다음으로 앱 트래픽이 코어로 전달되는지 확인하세요.

가져오기는 성공했지만 연결되지 않을 때

‘설정이 시작되는지 → 원격 핸드셰이크가 성공하는지 → 앱 트래픽이 프록시로 전달되는지’ 순서로 확인하세요. 한 번에 한 종류의 매개변수만 수정하고 처음 발생한 구체적인 오류를 기록하세요. 노드 목록의 테스트 결과는 특정 테스트 대상만 확인하므로 브라우저, DNS, 라우팅을 모두 검증하는 절차를 대신할 수 없습니다.