Xray와 V2Fly 코어 비교: 차이점·호환성·선택 가이드

핵심 내용 미리보기

코어를 선택할 때는 먼저 서버 프로토콜, 전송 방식, 보안 매개변수를 확인한 다음 클라이언트가 해당 항목을 모두 설정할 수 있는지 살펴보세요. VLESS, Vision, REALITY 조합이 필요하다면 이를 지원하는 Xray 환경을 우선 선택하세요. 기존 VMess 설정이 정상 작동한다면 이름이 다르다는 이유만으로 옮길 필요는 없습니다. 안드로이드 클라이언트를 바꾸거나 데스크톱 코어를 전환하거나 사용자 지정 설정을 가져오려는 경우에 적합한 글입니다. 재사용할 수 있는 항목과 다시 확인해야 할 항목을 짚어봅니다.

분기 배경: 프로젝트·코어·클라이언트는 서로 다른 계층

Project V는 이 생태계를 이해하는 출발점이며, V2Ray는 그 안에서 개발된 프록시 소프트웨어입니다. V2Fly 커뮤니티는 v2ray-core를 계속 유지 관리하고 있습니다. Xray-core는 2020년 당시 V2Ray 코드베이스에서 분기한 뒤 독자적으로 발전했습니다. 분기 전 코드와 설정 관행을 공유했더라도 이후 기능, 설정 형식, 출시 시점까지 계속 같다는 뜻은 아닙니다.

일상적으로 말하는 ‘V2Fly 코어’는 보통 V2Fly가 관리하는 v2ray-core를, ‘Xray 코어’는 Xray-core를 가리킵니다. v2rayN, v2rayNG, v2flyNG는 노드 관리와 UI 설정을 담당하고 코어를 실행하는 클라이언트입니다. 클라이언트 버전과 코어 버전은 별개의 정보이므로 문제를 진단할 때 각각 기록해야 합니다.

프로토콜 계층: VMess, VLESS 등은 클라이언트와 서버가 프록시 요청을 주고받는 방식을 정합니다.
전송 및 보안 계층: TCP, WebSocket, TLS, REALITY 등은 연결을 전달하는 방식과 보안 세션을 설정하는 방식을 정합니다.
코어 계층: 설정을 해석하고 DNS, 라우팅, 인바운드 및 아웃바운드 로직을 처리합니다.
클라이언트 계층: 구독 정보를 읽고 코어 설정을 생성하며 시스템 프록시나 안드로이드 VPN 인터페이스를 처리합니다.

따라서 ‘클라이언트에서 링크를 가져올 수 있다’는 것과 ‘코어가 연결을 설정할 수 있다’는 것은 별개입니다. 링크 파서가 VLESS를 인식하더라도 서버에서 요구하는 flow나 보안 항목을 보존하지 못할 수 있습니다. 노드가 목록에 표시된다는 사실만으로 설정이 완전하다고 볼 수는 없습니다.

기능 차이: Vision과 REALITY 조합을 중점적으로 확인

VMess는 두 코어에서 공통으로 사용하는 사례 중 하나일 뿐, 모든 기능이 호환된다는 뜻은 아닙니다. VLESS는 프록시 프로토콜, XTLS는 관련 기술 계열, Vision은 흔히 쓰이는 flow 모드, REALITY는 전송 보안 방식입니다. 이 용어들은 서로 다른 계층을 가리키므로 서로 대체할 수 있는 네 가지 노드 유형으로 보면 안 됩니다.

확인 항목	Xray-core	V2Fly v2ray-core
VMess	호환 가능한 VMess 설정에 사용 가능	호환 가능한 VMess 설정에 사용 가능
WebSocket + TLS	경로, Host, 서버 이름 확인 필요	전송 및 TLS 매개변수도 확인 필요
VLESS	일반적인 사용 사례지만 전송 방식과 flow를 맞춰야 함	프로토콜 이름만으로 판단할 수 없음. 기존 구현이 Xray 확장 기능과 호환된다는 뜻은 아님
Vision	해당 XTLS Vision 사용 방식 지원	Xray Vision 설정을 그대로 대체할 수 없음
REALITY	해당 REALITY 설정 지원	Xray REALITY 아웃바운드의 대체 코어로 사용하면 안 됨
전체 JSON 설정	Xray 설정 규격에 따라 해석	해당 버전의 V2Fly 설정 규격에 따라 해석

제공된 설정 조합이 VLESS + TCP + REALITY이고 flow가 xtls-rprx-vision이라면 이 요구사항 전체를 기준으로 코어를 선택해야 합니다. REALITY를 TLS로 바꾸거나 Vision 항목을 삭제한다고 해서 호환되는 노드가 자동으로 만들어지는 것은 아닙니다. 서버도 해당 접속 방식을 제공해야 합니다.

결론: 서버 매개변수를 빠짐없이 확인한 뒤 코어 선택

프로토콜, 전송 방식, 보안 방식, flow를 하나의 점검표에 기록하세요. 어느 한 항목이라도 Xray 전용 기능에 의존한다면 호환되는 Xray 환경에서 먼저 테스트하세요. 필드를 삭제해 해결하려고 해서는 안 됩니다.

설정 호환성: 공유 링크는 옮길 수 있어도 전체 설정을 무작정 복사하면 안 됩니다

‘같은 노드를 사용할 수 있는가’와 ‘같은 JSON을 사용할 수 있는가’는 따로 살펴봐야 합니다. 전자는 주로 원격 연결 매개변수에 관한 문제지만, 후자에는 로컬 리스너, DNS, 라우팅 규칙, 아웃바운드 태그, 코어 전용 옵션도 포함됩니다. 두 파일에 모두 inbounds와 outbounds가 있다고 해서 내용을 그대로 바꿔 쓸 수 있는 것은 아닙니다.

먼저 노드 매개변수 옮기기: 주소, 포트, 사용자 ID, 전송 방식, 보안 매개변수를 하나씩 대응시키세요. 공유 링크에는 클라이언트의 로컬 설정이 모두 포함되지 않는 경우가 많습니다.
다음으로 라우팅 정책 옮기기: 어떤 도메인은 직접 연결하고, 어떤 도메인은 프록시를 사용하며, 어떤 도메인은 차단할지 기록하세요. 대상 클라이언트에서 규칙을 다시 설정하고 적용 순서를 확인하세요.
DNS는 별도로 설정하기: 리졸버 주소, 쿼리 경로, 도메인 매칭 방식을 확인하세요. 원격 DNS 주소가 같다는 이유로 정책까지 같다고 판단하지 마세요.
마지막으로 전용 항목 확인하기: 이전 가이드의 XTLS 항목, 설정 형식별 전송 이름, REALITY 매개변수는 실제 코어 버전에 맞춰 다시 확인해야 합니다.

WebSocket + TLS를 예로 들면 원격 포트가 모두 443이라고 해서 연결 매개변수까지 같다는 뜻은 아닙니다. WebSocket 경로는 HTTP 업그레이드 요청에 사용되고, Host는 요청 헤더에 포함되며, TLS 서버 이름은 핸드셰이크와 인증서 검증에 사용됩니다. 세 값은 서로 다를 수 있으므로 이전할 때 모두 서버 IP로 바꾸면 안 됩니다. 인증서 검증 비활성화를 일반적인 해결 방법으로 삼지 마세요.

REALITY의 서버 이름, 공개 키 관련 매개변수, short ID, 지문 옵션은 제공된 정보와 현재 클라이언트의 항목에 맞춰 입력해야 합니다. 버전에 따라 UI 이름, JSON 필드, 공유 링크 매개변수 이름이 다를 수 있으므로 글자가 비슷하다는 이유만으로 직접 이름을 바꾸지 마세요. 설정 문제를 공유할 때는 먼저 구독 주소, 사용자 ID, 기타 접속 정보를 삭제하세요.

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

데스크톱에서는 창 제목만 보지 말고 v2rayN에서 현재 노드가 실제로 어떤 코어를 호출하는지 확인하세요. 일반 노드는 대개 클라이언트가 설정을 생성하지만, 사용자 지정 설정은 파일을 그대로 지정된 코어에 전달해 실행할 수 있습니다. 노드 편집 양식에 특정 옵션이 없다고 해서 코어가 지원하지 않는다는 뜻은 아니며, 그 반대도 마찬가지입니다.

Xray 사용: v2rayN / v2rayNG

권장

VLESS + Vision + REALITY가 필요하다면 Xray 코어 버전과 클라이언트의 관련 항목 지원 여부를 먼저 확인하세요. 안드로이드에서는 v2rayNG를 사용하고, 데스크톱에서는 v2rayN에서 선택한 설정이 실제로 Xray를 사용하는지 확인하세요.

적합한 경우: 서버에서 Xray 확장 기능을 요구하거나 해당 공유 링크를 이미 보유한 경우

V2Fly 사용: v2flyNG

안드로이드에서 기존 V2Fly 설정 체계를 계속 사용해야 한다면 v2flyNG를 선택할 수 있습니다. 기존 VMess 연결과 라우팅 정책이 정상 작동한다면 코어를 바꾸기 전에 이전으로 얻을 수 있는 이점을 먼저 확인하세요.

적합한 경우: 기존 V2Fly 설정을 유지 관리하며 노드가 Xray 전용 기능에 의존하지 않는 경우

여기서 제안하는 선택은 이 글에서 다룬 프로토콜 요구사항을 기준으로 한 것이며 속도 순위가 아닙니다. 같은 VMess 회선의 다운로드 속도도 서버 부하, 네트워크 경로, 혼잡 제어, 클라이언트 정책에 따라 달라집니다. 서로 다른 시간대의 속도 측정 결과 차이를 전부 코어 탓으로 돌릴 수 없으며, 코어를 바꾸면 지연 시간이 반드시 줄어든다고 보장할 수도 없습니다.

이전 절차: 최소 연결부터 확인한 뒤 로컬 정책 복원

데스크톱: v2rayN

현재 노드, 라우팅 모드, 로컬 리스너 포트를 기록합니다.
테스트 노드 하나로 코어와 전송 매개변수를 확인합니다.
먼저 프록시를 명시적으로 지정해 테스트한 뒤 시스템 프록시 설정을 확인합니다.

안드로이드: v2rayNG / v2flyNG

기존 클라이언트 설정을 저장한 뒤 테스트 노드 하나만 가져옵니다.
테스트 중에는 VPN 서비스를 하나만 실행합니다.
연결이 정상인지 확인한 다음 앱별 프록시와 DNS 정책을 복원합니다.

구독에서 같은 노드를 가져올 수는 있지만 양쪽 클라이언트의 DNS, 라우팅, 앱별 설정까지 자동으로 동기화되지는 않습니다.

확인 순서: 포트·문법·실제 트래픽을 나눠 점검

문제를 진단할 때는 먼저 반복 가능한 기준을 마련하세요. 아래 포트는 테스트 예시이며 모든 클라이언트의 기본값은 아닙니다. 서버 포트가 443이고 로컬 SOCKS 인바운드 포트를 10808로 직접 설정했다고 가정하면 테스트 프로그램은 실제로 설정한 주소와 포트에 연결해야 합니다. 혼합 인바운드를 사용하는 다른 클라이언트 버전은 UI나 생성된 설정에 표시된 리스너 값을 기준으로 확인하세요.

443

서버 포트 예시: 서버와 일치해야 함

10808

로컬 SOCKS 리스너 포트 예시

127.0.0.1

로컬 기기 테스트 전용 리스너 주소

JSON을 직접 관리한다면 코어에 포함된 테스트 하위 명령으로 문법을 확인할 수 있습니다. 아래 명령은 Xray에서 흔히 사용하는 형식과 V2Fly v5의 명령 형식에 각각 해당합니다. 실행 파일 이름은 운영체제와 설치 방식에 따라 달라질 수 있습니다. 정상 작동하는 원본 파일을 덮어쓰지 말고 복사본에서 먼저 확인하세요.

# Xray: 현재 디렉터리의 설정 파일 확인
xray run -test -config config.json

# V2Fly v5: 현재 디렉터리의 설정 파일 확인
v2ray test -c config.json

문법 검사를 통과했다는 것은 설정을 해석할 수 있다는 뜻일 뿐, 원격 서버에 연결할 수 있거나 인증 정보가 유효하거나 트래픽이 예상대로 나간다는 뜻은 아닙니다. 명령 옵션을 인식하지 못한다면 해당 프로그램의 도움말을 실행해 설치된 버전에서 지원하는 사용법을 확인하세요. 검사를 통과하려고 이해하지 못한 설정 항목을 바로 삭제해서는 안 됩니다.

시작 로그 확인: 알 수 없는 필드, 설정 형식 오류, 로컬 포트 충돌부터 해결하세요. 이 단계에서는 아직 원격 핸드셰이크가 시작되지 않았습니다.
네트워크 연결 확인: 시간 초과가 계속되면 사용자 ID를 바꾸기 전에 서버 주소와 포트, 네트워크 연결 가능 여부부터 확인하세요.
핸드셰이크 확인: TLS 또는 REALITY 관련 오류가 발생하면 서버 이름, 보안 방식, 키 매개변수를 대조하고 기기 시간이 정확한지도 확인하세요.
실제 요청 확인: 프록시를 명시적으로 지정한 프로그램으로 대상에 접속한 다음 시스템 프록시나 안드로이드의 트래픽 처리 범위를 확인하세요. 프록시를 거치지 않은 요청을 코어 오류로 오인하지 않도록 합니다.
라우팅 및 DNS 복원: 최소 연결이 정상이라면 항목을 하나씩 복원하고 변경할 때마다 다시 테스트하세요. 그래야 어떤 정책이 결과를 바꿨는지 찾을 수 있습니다.

이전 전 마지막 점검: 되돌릴 방법을 남기고 중복 변경 피하기

두 코어 모두 현재 노드를 지원한다면 유지 관리 부담과 설정 검증 가능성을 기준으로 선택하세요. 안정적으로 작동하는 VMess + WebSocket + TLS 설정을 이름을 통일하려는 이유만으로 VLESS로 바꿀 필요는 없습니다. 서버에서 이미 REALITY를 요구한다면 이전 환경을 계속 사용하려고 연결 매개변수를 억지로 단순화해서도 안 됩니다.

같은 구독이 v2rayNG에서는 작동하지만 v2flyNG에서는 작동하지 않을 때는 무엇부터 확인해야 하나요?

구독 주소만 비교하지 말고 실제로 가져온 노드 유형과 매개변수를 먼저 비교하세요. 구독에는 VMess, VLESS와 여러 전송 방식이 섞여 있을 수 있으며 클라이언트마다 링크 매개변수를 다르게 해석할 수도 있습니다. 같은 노드를 선택해 flow, 보안 방식, 전송 방식을 확인한 뒤 시작 로그를 살펴보세요. Vision이나 REALITY에 의존하는 노드는 호환되는 Xray 환경에서 테스트해야 합니다.

코어를 바꾸면 DNS나 분할 라우팅 문제가 자동으로 해결되나요?

자동으로 해결되지는 않습니다. 코어를 바꾸면 설정 해석 방식이나 기본 동작이 달라질 수 있지만, 잘못된 도메인 규칙과 DNS 쿼리 경로, 클라이언트의 트래픽 처리 범위는 따로 확인해야 합니다. 이전 후에는 DNS 요청이 어디로 향하는지, 직접 연결할 대상이 여전히 직결되는지, 프록시 대상에 올바른 아웃바운드가 적용되는지 다시 점검하세요.

문제 해결을 위해 어떤 기록을 남겨야 하나요?

클라이언트 버전, 코어 버전, 운영체제, 노드의 프로토콜 조합, 인증 정보를 제거한 오류 로그를 보관하세요. 한 번에 코어나 연결 매개변수 하나만 바꾸고 같은 대상으로 반복 테스트하세요. 그래야 설정 비호환, 서버 거부, 로컬 트래픽 처리 실패를 구분할 수 있습니다.

원래 설정은 별도로 백업하고 테스트 설정은 구분되는 이름으로 저장해 구독 업데이트가 수동 변경 사항을 덮어쓰지 않도록 합니다.
앱이 완전히 중지된 것을 확인한 뒤 다른 서비스를 시작해 로컬 리스너 포트 충돌을 방지하세요.
이전에 성공한 뒤 기존 설정을 정리하고, 검증이 끝난 복구 경로 하나는 먼저 남겨두세요.