Xray 코어와 V2Fly 코어 차이: XTLS Vision, REALITY 및 설정 호환성

이 글 한눈에 보기

코어를 선택할 때는 클라이언트 이름보다 서버 요구사항을 먼저 확인하세요. 노드를 가져오거나 코어를 바꾸거나 JSON 설정을 이전하려는 사용자라면, 먼저 클라이언트와 코어의 역할을 구분한 뒤 프로토콜·전송 방식·보안 계층을 확인하세요. 마지막으로 설정 검사와 연결 로그를 통해 문제를 찾아낼 수 있습니다. 노드에 REALITY 또는 xtls-rprx-vision이 표시되어 있다면 해당 기능을 지원하는 Xray 실행 환경을 선택해야 합니다. 일반 노드도 세부 필드와 버전을 확인해야 합니다.

클라이언트와 코어: 각 역할부터 구분하기

v2rayN, v2rayNG, v2flyNG는 사용자가 조작하는 클라이언트입니다. 서버 목록, 구독 가져오기, 시스템 프록시 설정, 화면 설정은 클라이언트에서 처리합니다. 설정 파싱, 연결 수립, 라우팅 규칙 적용, 트래픽 전달은 주로 코어가 담당합니다. 클라이언트 화면에 어떤 옵션이 표시된다고 해서 현재 실행 중인 코어도 반드시 해당 옵션을 지원하는 것은 아닙니다.

구독 또는 노드 클라이언트에서 파싱 실행 설정 생성 코어에서 로드 서버에 연결

안드로이드에서는 v2rayNG가 Xray 코어를, v2flyNG가 V2Fly 코어를 사용합니다. 데스크톱의 v2rayN은 버전과 노드 유형, 실제 실행 로그를 확인해야 사용 중인 코어를 알 수 있습니다. 바탕 화면 바로 가기만으로 판단할 수는 없습니다. 문제를 진단할 때는 클라이언트 버전과 코어 버전을 각각 기록하세요. 두 버전 번호는 서로 다른 것입니다.

구독을 가져오지 못하는 경우: 먼저 구독 내용과 클라이언트의 파싱 기능을 확인하세요. 이 단계에서는 코어가 아직 실행되지 않았을 수 있습니다.
코어가 시작되지 않는 경우: 생성된 설정, 필드 유형, 포트 사용 여부와 코어의 기능 지원 범위를 먼저 확인하세요.
코어는 시작됐지만 연결되지 않는 경우: 서버 설정값, 핸드셰이크 로그, 실제 네트워크 경로를 확인하세요.

Xray와 V2Fly: 같은 뿌리에서 나왔어도 설정이 항상 호환되는 것은 아닙니다

V2Fly는 V2Ray의 개발을 이어가는 커뮤니티 프로젝트이며, 핵심 프로그램은 보통 V2Ray Core라고 부릅니다. Xray는 2020년에 V2Ray 코드 기반에서 분기한 뒤 독자적인 방향으로 발전했습니다. 인바운드, 아웃바운드, 라우팅, DNS처럼 공통된 개념은 많지만, 기능과 설정 구조에는 이미 차이가 있습니다.

따라서 “둘 다 프록시 트래픽을 처리한다”는 것과 “실행 파일만 바꿔 끼우면 된다”는 것은 전혀 다른 이야기입니다. 이전할 때 프로토콜 이름이 같다는 사실은 첫 단계에서 대응될 가능성을 보여줄 뿐입니다. 전송 매개변수, 보안 계층, 라우팅 표현식, DNS 설정까지 모두 호환된다는 뜻은 아닙니다.

비교 항목	Xray	V2Fly	실제 영향
프로젝트 관계	V2Ray에서 분기해 발전	V2Ray의 개발을 이어가는 커뮤니티 프로젝트	기본 개념은 비슷하지만 모든 필드가 공통이라고 단정할 수 없음
VMess 등 기본 프로토콜	대응 구현 지원	대응 구현 지원	전송 방식, 보안 계층, 사용 버전도 확인해야 함
XTLS Vision	해당 흐름 제어 방식 지원	동등한 대체재로 실행할 수 없음	Vision 노드에는 호환되는 Xray를 사용해야 함
REALITY	해당 보안 계층 지원	Xray의 REALITY 설정을 그대로 실행할 수 없음	이름만 바꿔서 이전할 수 없음
설정의 발전	Xray의 필드 및 버전 요구사항에 맞춰 확인	V4, V5 등 설정 체계를 구분해야 함	이전 전에 설정 형식과 로드 방식을 확인

판단 기준: 노드가 필요한 기능을 먼저 파악한 뒤 코어 전환 여부 결정

현재 노드가 REALITY 또는 Vision에 의존한다면 먼저 Xray를 유지하세요. 목표 코어를 지원하는 연결 방식을 서버에서 별도로 제공하는 경우에만 이전을 테스트하고, 알 수 없는 필드를 바로 삭제하지 마세요.

XTLS Vision과 REALITY: 하나는 흐름 제어, 다른 하나는 보안 계층

일반적인 VLESS 설정에서 XTLS Vision은 flow: xtls-rprx-vision으로 지정합니다. 조건에 맞는 트래픽을 해당 방식으로 처리하며, 독립적인 구독 형식이나 아무 전송 조합에나 추가할 수 있는 속도 향상 옵션은 아닙니다. 서버에 해당 흐름 제어 설정이 없으면 클라이언트에서 Vision을 입력해도 호환되지 않습니다.

REALITY는 보안 계층에 해당하며 서버 인증과 관련 핸드셰이크 매개변수를 다룹니다. 클라이언트에서는 보통 서버 이름, 공개 키, Short ID 등을 확인해야 합니다. 화면에서 공개 키 자료를 Public key라고 표시하거나 버전에 따라 다른 이름을 사용할 수 있으므로, 표시 이름만 다르다고 매개변수를 서로 바꿔 쓰면 안 됩니다. 서버의 개인 키를 클라이언트 공개 키 입력란에 넣어서는 안 됩니다.

VLESS + Vision + REALITY

프로토콜: VLESS
전송 방식: TCP, 일부 버전에서는 RAW로 표기
Flow: xtls-rprx-vision
보안 계층: REALITY
주요 확인 항목: 서버 이름, 공개 키, Short ID

일반적인 조합에서 필드가 어떻게 대응되는지 보여주는 예시일 뿐, 그대로 연결할 수 있는 완성 설정은 아닙니다. 각 항목은 서버 설정과 일치해야 합니다.

VMess + WebSocket + TLS

프로토콜: VMess
전송 방식: WebSocket
경로 예시: /ws
보안 계층: TLS
주요 확인 항목: UUID, Host, 경로, 서버 이름

경로는 예시일 뿐이며 구독의 실제 값을 대체할 수 없습니다. 일반 TLS와 REALITY의 매개변수는 서로 바꿔 쓸 수 없습니다.

Vision은 REALITY와 다릅니다: Vision은 호환되는 TLS 조합에도 사용할 수 있으므로, Vision이 보인다고 보안 계층을 단정할 수 없습니다.
REALITY가 특정 포트를 뜻하는 것은 아닙니다: 서버가 443 포트를 사용하는 경우가 많지만, 포트 자체가 프로토콜이나 보안 계층을 결정하지는 않습니다.
VLESS가 Vision을 뜻하는 것은 아닙니다: “VLESS 지원”이라고만 안내되어 있다면 xtls-rprx-vision 지원 여부를 확인할 수 없습니다.
WebSocket을 그대로 적용하지 마세요: 위의 Vision 조합을 WebSocket으로 단순히 바꾼 뒤에도 같은 기능을 기대하며 연결할 수는 없습니다.

설정 호환성: 전체 치환 대신 네 계층으로 나눠 확인

공유 링크, 구독 텍스트, 클라이언트에 저장된 데이터, 코어가 읽는 JSON은 서로 다른 계층입니다. vless:// 링크를 가져오는 데 성공했다면 클라이언트가 링크를 파싱했다는 뜻일 뿐입니다. 생성된 실행 설정에 흐름 제어, 보안 계층, 전송 매개변수가 그대로 반영됐는지도 확인해야 합니다. 반대로 전체 JSON을 일반 노드 링크처럼 가져올 수 있는 것도 아닙니다.

프로토콜 계층 확인: VMess 또는 VLESS인지, 사용자 식별자와 인증 매개변수가 올바른지 확인하세요. 오래된 VMess 설정에는 과거 호환 매개변수가 포함될 수 있습니다. 이전할 때는 서버 정보와 현재 구현을 함께 확인하고, 오래된 안내서의 고정값을 그대로 복사하지 마세요.
전송 계층 확인: TCP/RAW, WebSocket 등의 유형과 경로, Host 필드를 확인하세요. 버전에 따라 이름이나 설정 표기 방식이 바뀔 수 있으므로 화면에 표시된 문구만 비교해서는 안 됩니다.
보안 계층 확인: TLS, REALITY 중 무엇을 사용하는지 또는 해당 계층을 사용하지 않는지 확인하세요. 서버 이름, 인증서 검증, 키 자료, 지문 요구사항도 점검해야 합니다. 인증서 검증을 건너뛰는 것은 만능 해결책이 아닙니다.
실행 환경 확인: 인바운드 수신 주소와 포트, 라우팅 태그, DNS, 파일 경로를 비교하세요. 프로토콜 핸드셰이크 매개변수가 맞더라도 아웃바운드 태그 참조가 잘못되면 예상한 대로 트래픽을 분기하지 못할 수 있습니다.

V2Fly의 V4와 V5 설정 체계도 구분해야 합니다. 파일 확장자가 모두 .json이라고 해서 필드 구조까지 같다는 뜻은 아닙니다. 전체 설정을 이전한다면 대상 코어의 문서를 기준으로 구조를 다시 확인하세요. 일반 사용자는 서비스 제공자가 호환성을 확인한 링크를 가져와 클라이언트가 실행 설정을 생성하도록 하는 편이 좋습니다.

이전 검증: 로컬 수신과 원격 핸드셰이크를 따로 테스트

두 코어를 비교할 때는 서버, 네트워크, 테스트 대상을 동일하게 유지하고 매 테스트의 매개변수를 기록하세요. 아래 숫자는 로컬 비교 실험을 위한 예시일 뿐, 클라이언트 기본값이나 속도 측정 결과가 아닙니다. 예시에서는 로컬 HTTP 프록시 포트로 10809를 사용하고 루프백 주소에서만 수신하도록 설정해 테스트 포트가 LAN에 노출되지 않게 합니다.

10809

로컬 HTTP 프록시 포트 예시

443

원격 포트 예시: 노드 설정 기준

3회

같은 조건으로 요청을 반복해 일시적인 실패를 걸러냅니다

먼저 코어가 설정을 읽을 수 있는지 확인

다음은 명령줄 검사 예시입니다. 먼저 대상 코어가 읽을 수 있는 client.json을 준비하세요. Xray는 해당 명령줄 형식을 사용하고, V2Fly는 V5 명령줄 형식을 사용합니다. 배포판에 따라 차이가 있으면 해당 프로그램의 도움말 명령으로 먼저 확인하세요. 설정 검사는 로드 단계만 확인하며 원격 서버에 연결할 수 있는지는 검증하지 않습니다.

# Xray 설정 검사
xray run -test -config client.json

# V2Fly V5 명령줄 설정 검사
v2ray test -c client.json

요청이 로컬 프록시를 통과하는지 확인

테스트 설정을 실행한 다음 명확한 로컬 프록시 주소로 요청을 보내세요. 아래 예시는 10809에서 HTTP 프록시를 제공한다고 가정합니다. 실제로 SOCKS 인바운드만 사용한다면 http://를 그대로 쓰면 안 됩니다. 예시 대상인 https://example.com/은 접속할 수 있음을 확인한 HTTPS 주소로 바꿔도 됩니다.

curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 30 -I https://example.com/

로컬 연결 거부: 원격 프로토콜을 바로 바꾸기보다 코어 실행 여부와 수신 포트가 올바른지 먼저 확인하세요.
원격 연결 시간 초과: 서버 주소와 포트, 방화벽, 네트워크 경로를 확인하세요. 시간 초과만으로 코어 비호환을 단정할 수는 없습니다.
핸드셰이크 또는 인증 오류: UUID, Flow, 서버 이름, 공개 키, Short ID를 하나씩 확인하고 한 번에 여러 항목을 바꾸지 마세요.
요청은 성공하지만 일부 사이트에서 실패: DNS, 라우팅, 대상 사이트의 차이를 확인하세요. 특정 사이트의 장애를 전체 프로토콜의 문제로 간주하지 마세요.

10809 포트를 사용하는 설정 두 개를 동시에 실행하지 마세요. 비교 테스트를 시작하기 전에 이전 설정을 중지하고 로컬 포트와 테스트 명령을 동일하게 유지하세요. 그렇지 않으면 포트 충돌이 발생하거나 요청이 이전 프로세스로 전달되어 로컬 상태를 코어 차이로 오인할 수 있습니다.

선택 기준: 노드 기능과 유지 관리 비용

현재 정상 작동하는 설정이라면 “다른 코어가 업데이트됐다”는 이유만으로 바로 이전할 필요는 없습니다. 새 버전이 유용한지는 수정 사항, 프로토콜 지원, 클라이언트 호환성을 함께 고려해 판단하세요. 업데이트 전에 기존 클라이언트 및 코어 버전과 사용 가능한 노드를 기록하고, 복구할 수 있는 설정 사본을 보관하면 롤백 시간을 크게 줄일 수 있습니다.

사용 상황	선택 방향	작업 시 확인할 점
노드에서 REALITY 또는 Vision을 명시적으로 요구	호환되는 Xray 사용	클라이언트 지원 여부와 실제 코어 버전을 확인하고 노드 매개변수를 빠짐없이 보관
안드로이드에서 Xray 기능을 사용하는 노드 이용	v2rayNG 호환성 확인	가져온 뒤 전송 방식, 보안 계층, Flow가 제대로 유지됐는지 확인
안드로이드에서 V2Fly 설정 체계 이용	v2flyNG 호환성 확인	노드 기능, 설정 형식, 내장 코어의 지원 범위 확인
데스크톱에서 여러 노드 관리	v2rayN 사용 후 실행 중인 코어 확인	시작 로그에서 실제로 로드된 코어를 확인하고 목록 이름만으로 판단하지 않기

작업 원칙: 한 번에 변수 하나만 변경

먼저 기존 노드를 기존 코어에서 기준 테스트한 뒤, 목표 코어가 지원하는 노드 조합을 테스트하세요. 구독, DNS, 라우팅, 전송 방식을 동시에 바꾸면 실패했을 때 어느 계층에서 문제가 생겼는지 파악하기 어렵습니다.

자주 하는 오해: 가져오기 성공, 시작 성공, 연결 성공은 따로 확인해야 합니다

v2rayNG의 노드를 v2flyNG에 가져왔는데도 왜 연결되지 않나요?

먼저 노드에 REALITY나 Vision이 포함되어 있는지 확인하세요. 화면에서 공유 링크를 인식하더라도 V2Fly 코어가 해당 기능을 구현했다는 뜻은 아닙니다. 일반 노드라면 전송 방식, 보안 계층, 인증 매개변수를 확인하세요. 바꿔야 할 것은 서버에서 제공하는 호환 연결 방식이지, 전용 필드를 지운 뒤 계속 시도하는 것이 아닙니다.

Xray를 쓰면 V2Fly보다 항상 빠른가요?

그렇게 단정할 수 없습니다. 처리량과 지연 시간은 서버 부하, 왕복 지연 시간, 패킷 손실, 기기 성능, 전송 방식에도 영향을 받습니다. Vision의 처리 방식에도 적용 조건이 있으므로 한 번의 속도 측정 결과를 모든 네트워크에 적용되는 결론으로 일반화할 수 없습니다. 환경을 동일하게 유지해 반복 측정하고 연결 오류도 함께 살펴보세요.

도메인과 443 포트가 같은데도 프로토콜을 바로 바꿔 쓸 수 없는 이유는 무엇인가요?

도메인과 포트는 연결 진입점일 뿐입니다. 진입점 뒤에는 특정 프로토콜이나 보안 계층, 전달 규칙이 설정되어 있을 수 있습니다. 클라이언트에서 VMess, VLESS, TLS, REALITY 중 무엇을 사용하든 서버에 그에 맞는 설정이 있어야 합니다. 포트가 같다고 핸드셰이크 방식까지 같은 것은 아닙니다.

문제 진단을 위해 로그를 다른 사람에게 보낼 때 무엇을 처리해야 하나요?

클라이언트와 코어 버전, 오류 유형, 발생 시각, 필요한 필드 이름은 남기고 구독 주소, UUID, 개인 키 및 기타 인증 정보는 숨기세요. 전체 구독 주소에 접근 토큰이 포함될 수 있으므로 공개된 공간에 그대로 올리면 안 됩니다. 문제와 관련된 로그 일부만 제공하면 원인을 더 쉽게 찾을 수 있습니다.