Xray와 V2Fly 코어 차이: 기능 분기, 설정 호환성 및 선택 기준

핵심 내용

코어를 선택할 때는 먼저 서버 요구 사항을 확인하고, 클라이언트가 설정을 빠짐없이 반영할 수 있는지 살펴보세요. 기존 VMess 노드는 이름이 다르다는 이유만으로 옮길 필요가 없습니다. REALITY 또는 XTLS Vision이 명시된 노드라면 해당 기능을 지원하는 Xray 버전을 사용해야 합니다. 이 글은 코어 전환, JSON 설정 마이그레이션, 가져오기 오류 해결이 필요한 사용자를 위해 프로토콜 기능, 필드 호환성, 클라이언트 설정 생성이라는 세 가지 문제를 구분해 설명합니다.

1. 분기 배경: 공통 기반, 서로 다른 개발 방향

V2Ray는 원래 Project V 생태계의 프록시 도구였습니다. 이후 V2Fly 커뮤니티가 관련 코드와 문서의 유지 관리를 이어 왔으며, 널리 쓰이는 코어 프로그램 이름은 여전히 v2ray입니다. Xray는 2020년 V2Ray 코드를 바탕으로 분기했으며, 초기에는 XTLS 관련 개발 방향을 두고 갈라진 뒤 독자적으로 발전했습니다. 두 프로젝트는 공통된 역사적 기반을 갖지만, 각자 버전을 출시하고 구현과 설정 인터페이스를 변경해 왔습니다. 출발점이 같다고 해서 이후 기능까지 모두 함께 제공되는 것은 아닙니다.

클라이언트와 코어도 구분해서 봐야 합니다. v2rayN은 데스크톱 인터페이스와 구독 관리, 설정 생성을 제공하고 실제 연결은 선택한 코어가 처리합니다. v2rayNG는 Xray 코어를 사용하는 안드로이드 클라이언트이고, v2flyNG는 V2Fly 코어를 사용합니다. 클라이언트에 노드 이름이 표시된다는 것은 해당 항목이 저장됐다는 뜻일 뿐, 실행 중인 코어가 그 노드의 모든 매개변수를 지원한다는 뜻은 아닙니다.

클라이언트 계층: 공유 링크를 가져오고 구독을 저장하며 노드를 선택하고, 인터페이스 설정을 코어 설정으로 변환합니다.
코어 계층: 연결을 수립하고 프로토콜을 처리하며 DNS와 라우팅 규칙을 적용하고 실행 로그를 출력합니다.
서버 계층: 허용할 프로토콜과 전송 방식, 보안 설정을 결정합니다. 로컬 코어만 바꿔서는 서버가 지원하는 기능이 달라지지 않습니다.

2. 프로토콜 기능: VLESS와 REALITY는 서로 다른 계층

VMess와 VLESS는 프록시 프로토콜이고, TCP와 WebSocket 등은 연결을 전달하는 방식을 나타냅니다. TLS와 REALITY는 연결의 보안 메커니즘과 관련됩니다. 이는 기능을 분류한 것이지, 조합을 마음대로 선택할 수 있는 호환성 표가 아닙니다. 서버에서 사용하는 조합을 클라이언트도 지원해야 하며 관련 매개변수도 정확히 입력해야 합니다.

확인 항목	Xray	V2Fly
VMess	지원하지만 전송 및 보안 매개변수 확인 필요	지원하지만 전송 및 보안 매개변수 확인 필요
VLESS 기본 프로토콜	지원하며 관련 기능을 지속적으로 확장	기본 구현은 있으나 Xray의 모든 확장 기능과 호환된다고 볼 수 없음
REALITY	지원하며 버전과 서버 매개변수를 맞춰야 함	Xray REALITY 설정을 그대로 대체해 구현할 수 없음
XTLS Vision	해당 VLESS flow를 지원하며 조합별 요구 사항을 충족해야 함	Xray Vision 설정을 직접 실행할 수 없음
라우팅 및 DNS	관련 기능을 제공하며 필드와 동작은 해당 버전에 따라 다름	관련 기능을 제공하며 필드와 동작은 해당 버전에 따라 다름

따라서 “VLESS 노드에는 반드시 Xray가 필요하다”는 말은 지나치게 단순하고, “VLESS를 지원하면 REALITY도 쓸 수 있다”는 말도 맞지 않습니다. 노드에 security=reality가 필요하거나 flow=xtls-rprx-vision이 지정된 경우, 다른 코어가 기본 VLESS를 지원한다는 이유만으로 바꿔 쓸 수는 없습니다. 프로토콜, 전송 방식, 보안 설정, flow를 하나의 조합으로 확인하세요.

REALITY 설정에는 보통 서버 이름, 서버에서 제공한 공개 키 관련 매개변수, short ID, 클라이언트 지문 등의 옵션도 포함됩니다. 필드 이름은 버전과 클라이언트 인터페이스에 따라 달라질 수 있으므로 security를 tls에서 reality로 바꾸는 것만으로 마이그레이션이 끝나지 않습니다. 반대로 일반적인 VMess + WebSocket + TLS 노드가 안정적으로 작동한다면 코어를 바꾸기 위해 서버까지 변경할 필요는 없습니다.

3. 설정 호환성: JSON 구조가 비슷해도 그대로 바꿔 쓸 수는 없습니다

두 코어의 일반적인 설정에는 inbounds, outbounds, routing 같은 구조가 나타납니다. 구조가 비슷하다는 것은 공통된 설계 기반이 있다는 뜻일 뿐입니다. 특정 필드를 허용하는지, 기본값이 무엇인지, 특정 전송 구현에 의존하는지는 설정을 실행하는 버전에 따라 달라집니다. V2Fly의 여러 설정 형식과 Xray에서 흔히 쓰는 JSON 설정도 구분 없이 서로 덮어써서는 안 됩니다.

먼저 설정 형식 확인: 파일의 형식과 불러오는 방법을 확인해 다른 형식의 객체를 잘못된 파서에 전달하지 않도록 합니다.
다음으로 아웃바운드 매개변수 확인: 노드 이름만 비교하지 말고 프로토콜, 주소, 포트, 사용자 ID, 전송 방식, SNI, 경로, 보안 옵션을 하나씩 대조합니다.
전용 필드 확인: REALITY, Vision 또는 특정 코어에 새로 추가된 전송 옵션이 있다면 대상 코어의 문서에 따라 확인하세요. 오류가 난 필드를 지운 뒤 계속 사용하는 방식은 피해야 합니다.
마지막으로 실행 환경 확인: 규칙 데이터 파일, 인증서 경로, 상대 경로의 기준이 되는 작업 디렉터리도 시작 결과에 영향을 줍니다.

공유 링크와 구독은 전체 코어 설정과 다릅니다. 클라이언트가 vmess:// 또는 vless://를 가져온 뒤에도 매개변수를 실제 설정에 반영해야 합니다. 구독을 갱신해도 보통 노드 항목만 업데이트되며 DNS, 라우팅, 사용자 지정 템플릿 전체를 자동으로 확인해 주지는 않습니다. 마이그레이션할 때는 생성된 설정이나 시작 로그를 살펴 인터페이스의 옵션이 실제로 코어에 전달되는지 확인하세요.

4. 코어 선택: 현재 노드와 관리 방식에 맞추기

아래의 ‘권장’은 REALITY 또는 Vision을 명확히 사용하는 경우에 한하며, 다른 코어가 전반적으로 뒤처졌다는 뜻은 아닙니다. 현재 노드와 설정 템플릿, 운영 절차가 모두 V2Fly 기반이라면 검증된 조합을 유지하는 편이 재설정과 문제 해결에 드는 비용을 줄일 수 있습니다. 서버가 Xray 기능을 명시적으로 요구한다면 호환 조건을 우선 충족해야 합니다.

Xray 코어

권장

서버에서 REALITY 또는 XTLS Vision을 요구한다면 해당 기능을 지원하는 Xray 버전을 선택하고, 클라이언트가 필요한 필드를 빠짐없이 생성하는지도 함께 확인하세요.

적합한 환경: Xray 전용 기능을 사용하는 것으로 확인된 노드, 동일한 Xray 설정을 유지해야 하는 환경.

V2Fly 코어

기존에 VMess 등 지원되는 조합과 V2Fly 설정 템플릿을 사용하고 있다면 검증된 환경을 유지할 수 있습니다. 마이그레이션은 프로젝트 이름을 비교해서가 아니라 실제 필요에 따라 결정하세요.

적합한 환경: 기존 V2Fly 설정이 안정적이며, 현재 규칙과 유지 관리 절차를 이어가야 하는 환경.

두 환경에 맞는 클라이언트 구성

서버에서 REALITY / Vision 사용

데스크톱에서는 v2rayN에서 Xray가 선택됐는지 확인하세요.
안드로이드에서는 v2rayNG를 사용하고 내장 코어 버전을 확인하세요.
서버 이름, 키 관련 매개변수, flow를 하나씩 확인하세요.

기존 V2Fly 설정을 계속 사용

데스크톱에서는 현재 v2rayN 버전의 V2Fly 지원 범위를 확인하세요.
안드로이드에서는 v2flyNG를 선택하고 노드 조합에 따라 가져오기 결과를 확인하세요.
기존 DNS, 라우팅, 규칙 데이터에 관한 정보를 함께 보관하세요.

하나의 구독에 서로 다른 기능을 요구하는 노드가 포함될 수 있습니다. 두 클라이언트에서 가져온 노드 수가 같더라도 모든 노드가 두 코어에서 작동하는 것은 아닙니다.

성능도 코어 이름만으로 순위를 매겨서는 안 됩니다. 지연 시간과 처리량은 서버 부하, 네트워크 경로, 전송 방식, 기기 성능, 동시 연결 수에 따라 달라집니다. 비교할 때는 기기와 노드, 테스트 시간을 동일하게 맞추고 라우팅 정책도 유지하세요. VMess + WebSocket을 VLESS + REALITY로 함께 변경했다면 결과를 단순히 ‘코어 변경’ 때문이라고 볼 수 없습니다.

5. 전환 절차: 기준 환경을 보존하고 변수 하나씩 검증

먼저 클라이언트 설정과 사용자 지정 템플릿을 백업하고, 현재 작동하는 노드와 코어 버전을 기록하세요. v2rayN의 메뉴와 코어 선택 위치는 버전이나 인터페이스 분기에 따라 달라질 수 있으므로 현재 인터페이스와 시작 로그를 기준으로 확인해야 합니다. 아래 포트는 재현을 위한 점검 예시이며 세 클라이언트의 공통 기본값이 아닙니다. 실제 테스트에서는 이 기기에서 수신 대기 중인 포트로 바꾸세요.

10808

로컬 SOCKS 연결 예시

10809

로컬 HTTP 연결 예시

443

서버 TLS 포트 예시

기준 환경 기록: 기존 코어에서 노드 하나가 작동하는지 확인하고 로컬 수신 주소와 포트, 시스템 프록시 상태, 라우팅 모드를 기록합니다.
코어만 변경: 노드와 DNS, 규칙은 그대로 유지합니다. 한 번의 테스트에서 TUN을 켜고 규칙 파일을 교체하고 전송 매개변수까지 변경하지 마세요.
생성된 설정 확인: 대상 코어에 프로토콜과 보안 필드가 모두 전달됐는지 확인합니다. 클라이언트가 필요한 필드를 생성하지 못한다면 먼저 클라이언트 호환성 문제를 해결하세요.
시작 및 연결 확인: 먼저 설정 파싱 성공 여부를 확인하고, 다음으로 로컬 포트의 수신 대기 상태를 확인한 뒤 서버 연결과 대상 요청을 점검합니다.
전체 환경 복원: 기본 프록시가 정상 작동하면 분할 라우팅, 시스템 프록시, TUN 설정을 하나씩 복원하고 변경할 때마다 로그를 확인하세요.

직접 관리하는 독립 설정이라면 먼저 설정 테스트를 진행할 수 있습니다. 아래 두 명령은 각각 Xray와 해당 명령 인터페이스를 사용하는 V2Fly 버전용입니다. 실제 설치된 코어에 맞는 명령 하나를 선택하세요. Windows에서는 해당 실행 파일 이름을 사용할 수 있습니다. 구버전에서 매개변수가 다르면 먼저 도움말 명령으로 확인하세요.

# Xray: 로컬 config.json 테스트
xray run -test -config config.json

# V2Fly: 로컬 config.json 테스트
v2ray test -c config.json

설정 테스트에 통과했다는 것은 현재 코어가 파일을 받아들였다는 뜻이지, 서버에 연결할 수 있다는 뜻은 아닙니다. 로컬에 실제로 127.0.0.1:10808 SOCKS 연결 지점이 있다면 다음 명령으로 프록시 경로만 따로 테스트할 수 있습니다. socks5h는 대상 도메인 처리를 프록시 서버에 맡겨 로컬 DNS 해석 경로와 구분하는 옵션입니다.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://v2ray-home.com/

이 명령은 성공하지만 브라우저에서 실패한다면 브라우저가 실제로 사용하는 프록시 연결 지점, 시스템 프록시 상태, 앱 자체 설정을 확인하세요. 로그에 address already in use가 먼저 표시되면 포트 사용 여부부터 확인합니다. 설정이 아직 정상적으로 불러와지지 않았다면 원격 DNS를 조정하거나 서버 포트를 바꿀 필요는 없습니다.

6. 자주 묻는 질문: 가져오기, 핸드셰이크, 이전 설정 복원

구독은 가져왔는데 코어를 바꾼 뒤 노드가 작동하지 않는 이유는 무엇인가요?

먼저 노드 편집 화면에서 프로토콜, 전송 방식, 보안 설정, flow를 확인한 뒤 시작 로그에 표시된 실제 코어를 확인하세요. 가져오기 성공은 클라이언트가 노드 항목을 저장했다는 뜻일 뿐입니다. 노드가 REALITY를 사용하는데 실제 실행 코어가 V2Fly라면 해당 조합을 지원하는 Xray로 바꾸세요. 보안 필드를 삭제해 설정을 억지로 실행하지 마세요.

같은 VMess 노드인데 두 코어의 결과가 다르면 어디부터 확인해야 하나요?

먼저 생성된 설정의 주소, 포트, 사용자 ID, WebSocket 경로, Host, TLS 서버 이름을 대조한 뒤 기기 시간과 인증서 검증 설정을 확인하세요. 다음으로 라우팅과 DNS가 동일한지 살펴보세요. 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요. 오류 로그를 보면 인증서 문제와 전송 매개변수 문제를 구분하는 데 도움이 됩니다.

안드로이드에서 v2rayNG를 V2Fly로 바로 전환할 수 있나요?

데스크톱의 코어 선택 방식을 안드로이드에 그대로 적용하지 마세요. v2rayNG는 Xray를 사용합니다. V2Fly 환경을 확인하려면 v2flyNG에서 지원되는 노드를 별도로 가져온 뒤 규칙과 DNS 설정을 확인하세요. 테스트 중에는 다른 클라이언트의 프록시 서비스를 먼저 중지해 활성 연결과 시스템 VPN 상태가 서로 간섭하지 않게 하세요.

코어를 바꾼 뒤 원래대로 되돌리려면 클라이언트를 다시 설치하면 되나요?

먼저 저장해 둔 코어 선택, 설정 템플릿, 라우팅, DNS 설정을 복원한 뒤 기준 노드를 다시 선택하세요. 로컬 수신 포트를 바꿨다면 시스템 프록시의 연결 대상도 함께 복구해야 합니다. 로그의 코어 버전이 백업 기록과 일치하는지 확인한 다음 같은 프록시 테스트를 다시 진행하세요. 단순히 재설치하면 이전 설정이 그대로 남을 수 있어 오히려 변경 원인을 찾기 어려워집니다.

코어 선택의 기준은 재현 가능한 호환성입니다. 서버는 필요한 기능을 결정하고, 클라이언트는 매개변수를 올바르게 표현할 수 있는지 결정하며, 코어는 연결을 실행합니다. 기존 설정이 안정적이라면 되돌릴 수 있는 기준 환경을 우선 유지하세요. 새 기능이 필요하다면 클라이언트 지원과 서버 매개변수를 함께 검증해야 합니다. 필드 설명은 프로토콜 가이드에서, 기본 가져오기와 연결 절차는 입문 가이드에서 확인할 수 있습니다.