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

구독에 VMess, VLESS, Trojan, WebSocket, gRPC 및 REALITY 노드가 함께 포함되어 있을 때 노드 실행 여부를 결정하는 것은 클라이언트 이름만이 아닙니다. 클라이언트가 호출하는 코어 프로그램, 코어가 지원하는 전송 방식과 보안 계층, 구독 변환 후 생성된 설정 필드가 함께 영향을 줍니다. Xray와 V2Fly는 공통 기반을 많이 공유하지만, 두 코어를 임의로 서로 바꿔 쓸 수 있는 것은 아닙니다.

같은 뿌리에서 갈라진 두 코어의 관계

V2Ray는 처음에 인바운드, 아웃바운드, 라우팅, DNS, 정책 및 전송 계층으로 구성된 설정 모델을 구축했습니다. 이후 프로젝트가 커뮤니티 유지 단계로 넘어가면서 V2Fly는 이 모델을 이어받아 V2Ray Core를 계속 유지 관리했습니다. Xray는 같은 기술 기반에서 분기되어 다양한 설정 객체와 주요 프로토콜을 유지하는 한편, VLESS, XTLS, REALITY, 전송 구현 및 성능 경로를 지속적으로 확장했습니다.

따라서 두 코어는 한쪽이 다른 쪽을 단순히 대체하는 관계라기보다, 기본 문법을 공유하면서 각자 기능을 확장하는 관계에 가깝습니다. VMess over TCP, VMess over WebSocket, 일반적인 VLESS over TCP, SOCKS 인바운드, 도메인 기반 라우팅 등의 설정은 대체로 유사합니다. 하지만 Xray 전용 보안 계층이나 흐름 제어 필드가 포함되면 호환성의 경계가 뚜렷해집니다.

• 공통 기반: 두 코어 모두 JSON 설정 방식을 사용하며 inbounds, outbounds, routing, dns, policy 등의 주요 객체를 포함합니다.
• 분기 핵심: Xray는 XTLS 및 REALITY 관련 기능을 추가하고 유지 관리하며, 일부 필드는 Xray만 해석할 수 있습니다.
• 선택 원칙: 먼저 노드에 필요한 기능을 확인한 다음 클라이언트가 기본으로 호출하는 코어를 살펴보세요. 단순히 “신형/구형”만으로 판단하면 안 됩니다.

프로토콜 및 보안 계층 차이: XTLS·REALITY·VLESS

VMess는 두 코어 모두 처리할 수 있는 기본 프로토콜 중 하나입니다. 주소, 포트, 사용자 식별자, 전송 방식, TLS 매개변수와 서버 설정이 일치하면 VMess over TCP 또는 WebSocket은 대체로 양쪽에서 구조가 유사한 아웃바운드 설정으로 생성됩니다. 여기서 “유사하다”는 설정 전체를 그대로 복사할 수 있다는 뜻은 아닙니다. 로그, DNS, 전송 세부 설정 및 실험적 필드는 여전히 다를 수 있습니다.

VLESS 자체는 가벼운 프로토콜입니다. 일반 VLESS와 TLS의 조합은 XTLS Vision과 같지 않으며, 구독에 VLESS가 있다고 해서 반드시 Xray가 필요한 것도 아닙니다. 실제로 확인해야 할 항목은 flow 필드, 보안 계층 이름 및 해당 설정 객체입니다. 흐름 제어 값이 xtls-rprx-vision이라면 이를 지원하는 Xray 코어를 사용하고, 가져오기 과정에서 클라이언트가 flow를 삭제하지 않았는지 확인해야 합니다.

REALITY는 전송 보안 계층에 해당합니다. 클라이언트는 주소, 포트, 사용자 식별자 외에도 serverName, fingerprint, 공개 키, shortId 등의 매개변수를 받아야 합니다. 일반적인 서버 수신 포트는 443이지만 포트 번호만으로 프로토콜을 판단할 수는 없습니다. 운영자는 다른 포트를 사용할 수도 있으므로, 포트 번호만 보고 노드가 REALITY인지 판단해서는 안 됩니다.

설정 호환성: 재사용할 수 있는 필드

두 코어 모두 계층형 설정을 사용합니다. inbounds는 로컬 애플리케이션의 트래픽을 받고, outbounds는 원격 노드 또는 직접 연결 출구를 정의하며, routing은 도메인, IP, 포트 및 네트워크 유형에 따라 출구를 선택하고, dns는 조회 방식을 결정합니다. 이러한 기본 객체만 사용하는 경우 설정 이전이 성공할 가능성이 높습니다.

위험 요소는 주로 확장 필드에서 발생합니다. Xray의 REALITY 설정은 streamSettings에서 security를 reality로 선언하고 realitySettings에 서버 이름, 클라이언트 지문, 공개 키 및 짧은 식별자를 저장합니다. XTLS Vision은 대개 VLESS 사용자 객체 안에 flow로 나타납니다. V2Fly가 인식할 수 없는 핵심 설정을 만나면 시작 단계에서 필드 또는 보안 계층 오류를 직접 표시할 수 있으며, 클라이언트가 설정을 생성하는 과정에서 노드 생성을 거부할 수도 있습니다.

일반적인 확인 경로
outbounds → protocol → settings → 사용자 및 서버 매개변수
outbounds → streamSettings → network → 전송 방식
outbounds → streamSettings → security → 보안 계층
outbounds → streamSettings → tlsSettings / realitySettings
VLESS 사용자 매개변수 → encryption / flow

구독 링크 자체는 코어 설정 파일이 아닙니다. 서버는 보통 공유 링크 목록이나 구독 데이터를 반환하고, 클라이언트가 이를 해석한 뒤 실행용 JSON을 생성합니다. 같은 구독이 v2rayN과 v2flyNG에서 다르게 표시되는 이유는 파서가 해당 필드를 지원하지 않거나 하위 코어가 노드 요구 사항을 지원하지 않기 때문일 수 있습니다. 문제를 해결할 때는 구독 전체를 반복해서 삭제하고 다시 추가하기보다 먼저 개별 노드의 상세 정보를 비교해야 합니다.

우선 재사용할 수 있는 항목

• 라우팅 규칙의 domain, ip, port, network 및 outboundTag 등의 기본 조건
• VMess 노드의 주소, 포트, 사용자 식별자, alterId, 전송 방식 및 일반 TLS 매개변수
• SOCKS 및 HTTP 로컬 인바운드 포트. 단, 이전 후 다른 프로세스가 사용 중인지 확인해야 합니다.
• 일반 DNS 서버 주소와 조회 정책. 단, 해당 버전에서 허용하는 필드 이름을 다시 확인해야 합니다.

반드시 다시 확인할 항목

1. security가 reality인지, 그리고 realitySettings가 존재하는지 확인하세요.
2. VLESS 사용자 객체에 xtls-rprx-vision 흐름 제어가 포함되어 있는지 확인하세요.
3. 전송 계층이 대상 코어에서 현재 지원하는 네트워크 유형과 매개변수를 사용하는지 확인하세요.
4. 라우팅 규칙이 참조하는 outboundTag가 대상 설정에 실제로 존재하는지 확인하세요.
5. DNS 아웃바운드, 직접 연결 아웃바운드 및 차단 아웃바운드의 태그가 규칙과 일치하는지 확인하세요.

클라이언트 선택: v2rayN·v2rayNG·v2flyNG

v2rayN은 데스크톱용 설정 관리자로 구독, 노드, 라우팅 및 여러 코어를 관리할 수 있습니다. VMess, VLESS Vision, REALITY가 함께 포함된 구독에서는 해당 노드의 실행 코어로 Xray를 우선 유지하세요. 일반적인 확인 경로는 「설정」→「매개변수 설정」→「Core 유형 설정」이며, VLESS 및 관련 노드 유형이 호환되지 않는 코어로 지정되지 않았는지 확인해야 합니다.

노드를 실행한 후 로그 영역에서 실제로 시작된 코어 이름을 확인할 수 있습니다. 로컬 SOCKS 포트가 10808이고 HTTP 포트가 10809라면 시스템 프록시가 현재 포트를 가리키는지도 확인하세요. 브라우저 확장 프로그램, 기존 코어 프로세스 또는 다른 네트워크 도구가 포트를 사용 중이면 노드 설정이 올바르더라도 트래픽을 정상적으로 넘겨받을 수 없습니다.

v2rayNG는 Android 기기용 클라이언트로 Xray 코어를 사용하며 REALITY, VLESS Vision, VMess 및 일반적인 구독을 가져오는 데 적합합니다. 가져온 후 노드 편집 화면에서 전송 프로토콜, 위장 도메인, 지문, 공개 키, shortId 및 흐름 제어를 중점적으로 확인하세요. 노드를 길게 눌러 실제 연결 테스트를 실행하기 전에 서비스를 시작하고 상태 표시줄의 실시간 트래픽이 변하는지 확인해야 합니다.

v2flyNG는 V2Fly 코어가 필요한 Android 환경을 위한 클라이언트로, V2Fly 서버 및 기존 VMess 설정과의 일관성을 유지하는 데 적합합니다. 구독에 REALITY 노드가 함께 포함되어 있다면 해당 노드는 v2rayNG에서 처리하고, 필드를 삭제한 뒤 연결하려고 하지 마세요. security, flow 또는 공개 키를 삭제해도 서버의 핸드셰이크 방식은 바뀌지 않으므로 REALITY 노드가 일반 TLS 노드로 변환되지 않습니다.

v2rayN 실제 확인 순서

1. 구독 그룹을 열고 노드 목록을 한 번 업데이트한 뒤, 대상 노드가 빈 주소나 0 포트로 해석되지 않았는지 확인하세요.
2. 「설정」→「매개변수 설정」→「Core 유형 설정」으로 이동해 VLESS에 해당하는 코어 선택을 확인하세요.
3. 노드를 더블 클릭해 security, flow, serverName, fingerprint, 공개 키 및 shortId를 확인하세요.
4. 노드를 시작하고 로그를 열어 코어가 10808 또는 사용자 지정 로컬 포트를 정상적으로 수신 대기하는지 확인하세요.
5. 시스템 프록시를 활성화하고 실제 대상에 접속한 다음 업로드 및 다운로드 바이트가 증가하는지 확인하세요.

Android 실제 확인 순서

1. v2rayNG 또는 v2flyNG에서 구독을 업데이트하고 가져오기에 실패한 노드 유형을 기록하세요.
2. 개별 노드 상세 정보를 열고 서비스 제공자가 안내한 프로토콜 및 전송 매개변수와 대조하세요.
3. 서비스를 시작한 후 연결 테스트를 실행하고 구독 목록의 지연 시간 숫자만 믿지 마세요.
4. 연결에 실패하면 먼저 로그에 표시된 첫 번째 코어 오류를 확인한 다음 DNS 또는 라우팅 문제를 처리하세요.

성능과 안정성: 코어 이름만으로 결정되지 않음

같은 서버, 같은 네트워크 및 같은 전송 방식이라면 두 코어의 일상적인 처리량 차이보다 프로토콜이 일치하는지가 더 중요합니다. 서버 부하, 회선 패킷 손실, 왕복 지연 시간, 혼잡 제어, TLS 핸드셰이크, DNS 조회 경로 및 클라이언트 기기 성능이 모두 결과에 영향을 줍니다. 지연 시간 테스트 한 번만으로 코어의 우열을 정하면 결론이 왜곡되기 쉽습니다.

노드 하나를 고정하고 같은 네트워크에서 세 차례 연속 테스트하는 것이 좋습니다. 연결 설정 시간, 웹 첫 바이트 수신 시간, 지속 다운로드 속도 및 실패 횟수를 기록하세요. 예를 들어 왕복 지연 시간이 약 53밀리초이고 패킷 손실이 1% 미만이라면 VMess over WebSocket의 차이는 주로 회선 변동에서 발생할 수 있습니다. REALITY 노드를 사용하는 경우에는 V2Fly를 선택할 수 없으므로 프로토콜 기능이 맞지 않아 비교 테스트 자체가 성립하지 않습니다.

• 먼저 프로토콜 확인: 코어가 노드에서 사용하는 프로토콜, 보안 계층 및 흐름 제어를 완전히 지원해야 합니다.
• 그다음 조건 통일: 서버, 테스트 시간, 네트워크 접속 방식 및 DNS 설정을 고정하세요.
• 마지막으로 로그 확인: 핸드셰이크 실패, 시간 초과, DNS 오류, 잘못된 라우팅 분기 및 포트 점유를 구분하세요.

자주 발생하는 문제: 가져오기·오류·전환 해결

대부분의 호환성 문제는 “구독 해석, 코어 시작, 핸드셰이크 수립, 트래픽 전달”이라는 네 단계에서 위치를 찾을 수 있습니다. 먼저 어느 단계에서 실패했는지 확인한 후 해당 매개변수만 수정하는 편이 노드를 계속 바꾸거나 클라이언트를 재설치하는 것보다 효율적입니다.

최종 선택 체크리스트

• 구독에 REALITY 또는 XTLS Vision이 포함됨: Xray 코어를 선택하세요.
• v2rayNG 사용: Xray 노드 매개변수를 기준으로 구독 내용을 확인하세요.
• v2flyNG 사용: V2Fly 기능과 호환되는 기존 노드를 우선 실행하세요.
• v2rayN 사용: 프로토콜에 따라 코어를 설정하고 실행 파일만 교체하지 마세요.
• 라우팅 및 DNS 이전: 태그, 필드 및 대상 버전의 지원 범위를 하나씩 확인하세요.
• 성능 테스트: 최소 세 차례 연속 실행하고 로그, 패킷 손실 및 실제 트래픽을 함께 기록하세요.