Xray 코어와 V2Fly 코어 비교: VLESS·XTLS·REALITY 지원 차이

핵심 내용

코어를 고를 때는 클라이언트 이름보다 노드 설정을 먼저 확인하세요. REALITY 또는 xtls-rprx-vision이 포함된 노드에는 해당 기능을 지원하는 Xray가 필요합니다. VMess, WebSocket, 일반 TLS 노드는 전송 항목과 설정 형식도 확인해야 합니다. v2rayN, v2rayNG, v2flyNG 간 설정을 옮기려는 사용자를 위해 프로토콜, 전송, 보안 계층, 클라이언트의 가져오기 기능을 구분하고, 시작 로그부터 로컬 포트까지 확인하는 순서를 안내합니다.

1. Xray와 V2Fly: 코어와 클라이언트는 서로 다른 계층

V2Ray는 프록시 도구와 그 설정 생태계를 가리키는 이름입니다. V2Fly 커뮤니티는 V2Ray 코어를 이어서 관리하고, Xray는 V2Ray 코드에서 파생된 뒤 자체 프로토콜 확장, 전송 구현, 설정 발전 경로를 갖추었습니다. 공통된 기반이 있다고 해서 새 설정 항목까지 항상 호환되는 것은 아닙니다. 전체 JSON 파일을 범용 형식으로 간주해서도 안 됩니다.

클라이언트는 구독 관리, 노드 편집, 시스템 프록시 설정과 코어 실행을 담당합니다. 코어는 실행 설정을 해석하고 인바운드와 아웃바운드를 구성하며 라우팅을 처리합니다. 클라이언트에 노드가 표시된다고 해서 포함된 코어로 해당 노드를 실행할 수 있는 것은 아닙니다. 구독 가져오기 성공과 프로토콜 핸드셰이크 성공은 별개의 확인 단계입니다.

v2rayN: 데스크톱 클라이언트입니다. 프로그램 아이콘이나 구독 그룹 이름으로 실행 코어를 판단하지 말고, 실제 시작 로그에서 코어 이름과 버전을 확인하세요.
v2rayNG: Xray 코어를 사용하는 Android 클라이언트입니다. REALITY 등의 설정은 클라이언트 편집 화면, 구독 파서, 코어가 모두 지원해야 합니다.
v2flyNG: V2Fly 코어를 사용하는 Android 클라이언트입니다. 실제 코어와 가져오기 형식에 맞춰 노드를 선택하세요. v2rayNG와 이름만 비슷한 대체 앱으로 간주해서는 안 됩니다.

2. VLESS·XTLS·REALITY 지원 범위 비교

VMess와 VLESS는 프록시 프로토콜이고, TCP와 WebSocket은 전송 방식입니다. TLS와 REALITY는 연결 보안 계층과 관련된 설정이며, XTLS Vision은 특정 흐름 제어 방식으로 연결 처리에 관여합니다. 각 항목은 서로 다른 계층에 속하므로 마음대로 바꿔 쓸 수 있는 ‘프로토콜 옵션’처럼 나열할 수 없습니다.

항목	Xray 코어	V2Fly 코어	전환 시 확인 사항
VMess	지원	지원	UUID, 암호화 설정, 전송 방식, TLS 매개변수 확인
VLESS	지원하며 Vision·REALITY와 함께 사용하는 경우가 많음	이전 버전에 구현된 적 있음. 실제 사용 버전과 설정 형식 확인 필요	VLESS 지원만으로 Xray 확장 기능까지 지원한다고 볼 수 없음
WebSocket + TLS	지원	지원	path, Host, serverName, 인증서 검증 확인
XTLS Vision	해당 VLESS 흐름 제어 설정 지원	Xray의 Vision 방식은 지원하지 않음	flow가 xtls-rprx-vision인지 확인
REALITY	지원	Xray의 REALITY 방식은 지원하지 않음	보안 계층, 공개 키, serverName, shortId 등의 매개변수 확인
실행용 전체 JSON	Xray 설정 사양에 따라 해석	해당 V2Fly 설정 버전에 따라 해석	설정 구조가 비슷해도 그대로 호환되는 것은 아님

VLESS 자체는 TLS와 동등한 전송 암호화를 제공하지 않습니다. VLESS 노드를 확인할 때는 프로토콜 이름만으로 연결 보호 방식을 판단하지 말고 보안 계층도 살펴보세요. 과거에 VLESS가 구현된 적이 있더라도, V2Fly에서 REALITY 또는 Vision이 포함된 구독 노드를 사용할 수 있다는 뜻은 아닙니다.

이전 가이드에서 보이는 security: "xtls"와 현재 흔히 사용하는 flow: "xtls-rprx-vision"은 서로 다른 설정 방식입니다. 문자열을 TLS로 바꿔 구형 설정을 ‘수정’하지 마세요. 서버 수신 설정, 흐름 제어, 클라이언트 기능이 모두 맞아야 합니다.

3. 속도 표시가 아니라 노드 설정으로 코어 선택하기

코어 선택의 첫 번째 기준은 설정을 실행할 수 있는지 여부이며, 연결 품질은 그다음입니다. 지연 시간은 회선, 서버 부하, DNS, 라우팅, 네트워크 환경의 영향을 모두 받으므로 특정 코어가 항상 더 빠르다고 볼 수 없습니다. 아래 권장 사항은 REALITY 또는 Vision 설정이 명시된 노드에만 해당합니다.

Xray 코어

권장

노드에 REALITY, xtls-rprx-vision 또는 Xray가 필요하다고 명시된 설정이 있으면 해당 항목을 지원하는 Xray 버전을 선택하고, 클라이언트가 매개변수를 빠짐없이 보존하는지 확인하세요.

적합한 경우: VLESS + REALITY, Vision 노드, 서버에서 Xray를 명시적으로 요구하는 노드

V2Fly 코어

V2Fly 설정 사양으로 이미 구성한 VMess 등의 노드가 있다면 해당 코어와 설정 절차를 계속 사용할 수 있습니다. 이전하기 전에 전송 방식, DNS, 라우팅 구조를 각각 확인하세요.

적합한 경우: 기존 V2Fly 설정 유지 관리, VMess 노드, Xray 확장 기능에 의존하지 않는 환경

일반적인 VLESS + TCP + REALITY 노드를 예로 들면 주소, 포트, UUID, 흐름 제어, 보안 계층, 서버 이름, 공개 키, shortId를 항목별로 확인해야 합니다. 핑거프린트 매개변수도 제공업체의 안내에 따라 입력하세요. 사용할 수 있는 shortId 값은 서버 설정에 따라 다르므로 다른 노드의 값을 복사하거나 반드시 정해진 길이여야 한다고 가정하지 마세요.

노드 편집 화면에서 프로토콜이 VLESS인지, 전송 방식이 서버 설정과 일치하는지 확인하세요.
보안 계층이 REALITY인지 확인하세요. 서버에서 Vision을 요구하는 경우에만 xtls-rprx-vision을 입력합니다.
공개 키와 서버 이름을 확인하세요. 연결 주소, WebSocket Host, serverName을 모두 같은 값으로 입력하면 안 됩니다.
실행 후 로그에서 먼저 설정이 받아들여졌는지 확인한 다음, 핸드셰이크와 앱 접속이 성공했는지 확인하세요.

4. 설정 호환성: 공유 링크와 실행 JSON 구분하기

공유 링크에는 노드 정보가 담기며, 클라이언트가 이를 실행 설정으로 변환합니다. 전체 JSON에는 로컬 수신 설정, DNS, 라우팅, 여러 아웃바운드가 함께 포함될 수 있습니다. 링크를 가져올 수 있었다는 것은 파서가 해당 링크를 처리했다는 뜻일 뿐입니다. JSON을 복사할 수 있어도 다른 코어가 모든 항목을 인식한다는 보장은 없습니다.

아래는 Xray 보안 계층을 식별하기 위한 설정 일부이며, 단독으로 실행할 수 있는 설정이 아닙니다. 서버 주소, 사용자 정보, REALITY 연결 매개변수가 빠져 있으므로 전체 설정으로 저장해 바로 실행하지 마세요.

{
  "streamSettings": {
    "network": "tcp",
    "security": "reality"
  }
}

프로토콜 계층: protocol과 해당 settings를 확인하세요. 프로토콜 이름만 바꾸고 기존 사용자 구조를 그대로 두면 안 됩니다.
흐름 제어 계층: Xray의 일반적인 VLESS 아웃바운드 설정에서 flow는 사용자 항목에 위치합니다. streamSettings에 임의로 추가하는 항목이 아닙니다.
전송 계층: streamSettings.network와 해당 전송 설정을 확인하세요. 새 전송 이름과 이전 이름의 호환 여부는 실제 코어 버전을 확인해야 합니다.
보안 계층: security와 관련 설정 객체를 확인하세요. realitySettings를 지원하지 않는 코어에 그대로 전달해서는 안 됩니다.
라우팅 계층: outboundTag가 존재하는지 확인하세요. 노드 핸드셰이크는 성공해도 규칙이 잘못된 아웃바운드를 가리키면 앱에서 접속하지 못할 수 있습니다.

5. 로컬 포트와 핸드셰이크 로그 확인 순서

테스트할 때는 로컬 진입점을 고정한 뒤 원격 연결을 확인하세요. 아래 숫자는 문제 해결을 위한 예시입니다. 10808과 10809는 실제 로컬 수신 설정과 일치해야 합니다. 443은 흔히 쓰이는 원격 TLS 포트일 뿐, 모든 노드에 고정된 값이 아니며 서비스 프로토콜을 판별하는 기준도 아닙니다.

10808

로컬 SOCKS 수신 포트 예시

10809

로컬 HTTP 수신 포트 예시

443

원격 보안 연결 포트 예시

시작 확인: 로그에 알 수 없는 프로토콜이나 전송 방식, 설정 파싱 오류가 표시되면 먼저 설정을 수정하거나 코어를 맞추세요. 회선 속도 측정은 그다음에 진행합니다.
수신 확인: 로컬 주소와 포트를 확인하세요. address already in use가 나타나면 해당 포트를 사용 중인 프로세스를 찾거나 로컬 포트를 변경한 뒤 테스트 명령도 함께 수정하세요.
핸드셰이크 확인: 코어는 시작됐지만 연결에 실패한다면 원격 포트, UUID, flow, serverName, 공개 키, shortId, 시스템 시간을 확인하세요.
라우팅 확인: 명령줄에서는 프록시를 통해 접속되지만 브라우저에서 안 된다면 시스템 프록시, 브라우저 프록시 설정, 분할 라우팅 결과를 확인하세요. 코어부터 바꾸지 마세요.

데스크톱 환경에 curl이 설치되어 있고 SOCKS 진입점이 127.0.0.1:10808로 설정된 경우, 아래 명령으로 명시적 프록시 요청을 테스트할 수 있습니다. --socks5-hostname은 대상 도메인 처리를 SOCKS 프록시 측에 맡깁니다. 시스템 전체 DNS나 모든 앱의 프록시 상태를 확인하는 방법은 아닙니다.

curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2ray88.com/

HTTP 응답을 받았다는 것은 해당 요청의 연결 절차가 완료됐다는 뜻이지, 모든 사이트와 규칙이 정상이라는 뜻은 아닙니다. 사이트 자체의 접속 제한 응답이 반환됐다면 프록시 핸드셰이크 실패와 구분해야 합니다. 오류를 기록할 때는 시간과 오류 유형을 남기고, 로그를 공유하기 전에 구독 링크, UUID, 기타 민감한 연결 정보를 삭제하세요.

6. 데스크톱과 Android의 설정 분담

하나의 구독 주소에서 여러 프로토콜을 제공할 수 있습니다. 같은 링크를 두 기기에서 가져와도 파서, 필터 조건, 업데이트 시점에 따라 목록이 달라질 수 있습니다. 양쪽 클라이언트가 명확히 인식하는 노드 하나로 먼저 확인하세요. ‘목록 개수가 같다’는 이유만으로 호환성을 판단하지 마세요.

구성 방법: 노드 특성에 따라 클라이언트 선택

데스크톱: v2rayN

REALITY 또는 Vision 노드는 해당 기능을 지원하는 Xray 코어로 사용하세요.
시작 로그에서 실제 실행 중인 코어와 버전을 확인하세요.
먼저 로컬 프록시 진입점을 테스트한 뒤 전체 분할 라우팅 규칙을 적용하세요.

Android: 프로토콜에 따라 선택

v2rayNG는 Xray 기능을 지원하는 노드에 사용하세요.
v2flyNG는 V2Fly 기능에 맞는 노드에 사용하세요.
클라이언트를 전환할 때는 다른 클라이언트의 VPN 연결을 먼저 중지하세요.

결론: 구독 주소가 같아도 실제 실행 가능 여부는 각 클라이언트, 코어, 노드 설정에 따라 달라집니다.

Android에서 VPN 권한을 요청하면 시스템 안내에 따라 확인해야 합니다. 클라이언트를 바꾼 뒤에는 앱별 프록시 적용 범위도 확인하세요. 특정 앱이 제외되어 있으면 그 앱만 접속되지 않고 다른 앱은 정상 작동할 수 있습니다. 이 현상만으로 REALITY 매개변수나 코어 구현에 문제가 있다고 판단할 수는 없습니다.

7. 코어 전환 관련 자주 묻는 질문

구독은 가져와지는데 실행 후 알 수 없는 보안 유형이 표시되는 이유는 무엇인가요?

실행에 실패한 노드의 편집 화면에서 REALITY가 선택되어 있는지 확인한 다음, 시작 로그에서 코어 이름을 확인하세요. 현재 V2Fly를 실행 중이라면 해당 항목을 지원하는 Xray 환경을 사용하세요. 이미 Xray라면 구독만 업데이트하지 말고 코어 버전과 클라이언트가 생성한 설정을 확인하세요.

REALITY를 TLS로 바꾸면 v2flyNG에서 사용할 수 있나요?

클라이언트 설정만 바꿔서는 안 됩니다. 두 방식은 핸드셰이크와 서버 설정이 다릅니다. 서버에서 실제 설정에 맞는 TLS 노드를 제공해야 하며, 새 매개변수로 다시 가져와야 합니다. 공개 키를 지우거나 보안 계층 이름을 바꿔도 기존 REALITY 진입점이 일반 TLS 진입점으로 바뀌지는 않습니다.

VMess 노드가 두 코어에서 모두 작동한다면 코어를 바꿔야 하나요?

현재 노드, DNS, 분할 라우팅이 정상이라면 이름이 다르다는 이유만으로 바꿀 필요는 없습니다. 전환이 꼭 필요하다면 기존 설정을 보관하고 전송 경로, TLS 서버 이름, 인증서 검증을 각각 확인한 뒤 라우팅 규칙을 단계적으로 추가하세요.

로그에 오류가 없는데 브라우저가 열리지 않으면 어디부터 확인해야 하나요?

먼저 실제 로컬 포트를 사용해 명시적 프록시 요청을 실행하세요. 명령이 성공하면 v2rayN의 시스템 프록시 메뉴에서 현재 상태를 확인하고 브라우저에 별도 프록시가 설정되어 있는지도 살펴보세요. 명령이 실패하면 코어 로그를 확인해 로컬 연결 거부, 원격 타임아웃, 핸드셰이크 실패를 구분하세요.

최종 확인 순서는 다음과 같습니다. 노드가 요구하는 기능, 클라이언트의 설정 해석 여부, 실제 코어의 지원 여부, 생성된 설정의 정확성, 앱 트래픽의 프록시 유입 여부입니다. 항목을 더 확인하려면 전체 설정 가이드를 참고하세요. 처음 연결을 설정할 때는 여러 매개변수를 동시에 조정하기보다 빠른 시작 가이드에 따라 단계별로 진행하는 편이 문제를 찾기 쉽습니다.