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

1. Xray, V2Fly와 클라이언트의 역할

V2Ray는 처음에 프록시 도구 프로젝트와 핵심 프로그램을 가리키는 이름이었습니다. V2Fly 커뮤니티는 v2ray-core를 계속 유지 관리하고 있습니다. Xray-core는 2020년에 관련 코드 기반에서 분기한 뒤, 자체적인 기능과 설정 발전 경로를 만들어 왔습니다. 두 코어는 공통된 역사를 지녔지만 동일 프로그램의 표시 이름만 다른 것은 아니며, 이름만으로 어느 쪽이 최신인지 판단할 수도 없습니다.

코어는 프로토콜 핸드셰이크, 전송, DNS, 라우팅 등 실제 작업을 처리합니다. 클라이언트는 구독 관리, 노드 편집, 연결 시작·중지, 로그 화면을 제공하고, 화면의 항목을 코어 설정으로 변환합니다. 노드 사용 가능 여부는 클라이언트가 해당 설정을 표현할 수 있는지, 코어가 필요한 기능을 구현했는지에 따라 달라집니다.

• v2rayN: 데스크톱 클라이언트입니다. 문제를 해결할 때 현재 선택된 코어를 확인해야 합니다. 클라이언트 버전 번호를 Xray 또는 V2Fly 버전으로 착각하지 마세요.
• v2rayNG: 안드로이드 클라이언트입니다. 이 글에서는 Xray 코어 설정 경로를 다루며, REALITY나 Vision 같은 기능이 필요한 노드에 적합합니다.
• v2flyNG: V2Fly 코어를 사용하는 안드로이드 클라이언트입니다. 선택하기 전에 노드의 프로토콜, 전송 방식, 설정 형식이 사용 중인 버전에서 지원되는지 확인하세요.

예를 들어 노드가 목록에 표시된다는 것은 구독을 파싱해 항목으로 만들었다는 뜻일 뿐입니다. 코어가 설정을 정상적으로 불러오고 원격 핸드셰이크까지 완료해야 연결이 가능한지 확인할 수 있습니다. 가져오기에 성공했다고 호환성 확인이 끝난 것은 아닙니다.

2. 기능 차이: Vision과 REALITY 확인하기

VMess와 VLESS는 프록시 프로토콜이고, WebSocket과 TCP는 전송 방식이며, TLS와 REALITY는 연결 보안 계층의 선택지입니다. XTLS Vision은 특정 연결 조합에서 사용하는 흐름 제어 기능입니다. 각각 담당하는 계층이 다르므로, 전체 설정 변경을 'VMess를 REALITY로 바꾼다'고 표현하는 것은 정확하지 않습니다.

Vision에서 흔히 사용하는 설정 값은 xtls-rprx-vision입니다. 예전 XTLS 설정의 다른 이름도 아니고, 아무 전송 방식에나 추가할 수 있는 속도 향상 옵션도 아닙니다. 일반적으로 VLESS, TCP, TLS 또는 REALITY를 조합해 사용하며, 클라이언트의 흐름 제어 설정도 서버와 일치해야 합니다.

REALITY는 인증서 검증을 끄는 기능도 아닙니다. 핸드셰이크와 신원 확인 방식이 다르며, 클라이언트에는 보통 서버 공개 키, 허용된 서버 이름, short ID, 지문 등의 정보가 필요합니다. 일반 TLS 노드의 보안 계층을 REALITY로 바꾼다고 바로 연결되는 것은 아닙니다.

3. 두 유형의 노드에서 확인할 주요 설정 항목

아래 두 카드는 설정 항목 간 관계를 확인하기 위한 것으로, 그대로 가져올 수 있는 노드 설정이 아닙니다. 예시 포트와 경로는 각각의 용도를 설명할 뿐입니다. 실제 값은 노드 제공처에서 확인해야 합니다. 서버가 443 포트에서 연결을 받는다는 사실만으로 TLS를 사용한다고 단정할 수 없으며, REALITY 사용 여부도 알 수 없습니다.

REALITY 공유 링크에서 pbk는 보통 서버 공개 키, sid는 short ID, sni는 서버 이름, fp는 클라이언트 지문 식별자를 나타냅니다. 공유 링크의 항목명, 클라이언트 편집 화면의 이름, 네이티브 JSON 키가 서로 다를 수 있으므로 해당 형식을 지원하는 클라이언트가 올바르게 매핑해야 합니다.

4. 설정 호환성: 공유 링크와 네이티브 JSON은 다릅니다

같은 노드라도 공유 링크, 구독 항목, 네이티브 JSON으로 표현할 수 있지만 서로 같은 파일은 아닙니다. 공유 링크에는 주로 노드 설정이 담깁니다. 네이티브 설정에는 로컬 인바운드, DNS, 라우팅, 로그, 여러 아웃바운드가 추가될 수 있습니다. 전체 설정을 노드 링크 하나로 줄이면 기존 동작을 모두 보존하기 어렵습니다.

1. 먼저 설정의 출처를 구분하세요.vmess://와 vless://는 공유 링크 접두사입니다. 객체 구조로 된 JSON은 전체 코어 설정일 수도 있고, 서비스 제공처 API의 응답일 수도 있습니다.
2. 그다음 JSON 형식을 확인하세요. V2Fly의 여러 설정 형식과 Xray의 설정 항목 변화는 구분해야 합니다. 최상위 항목에 inbounds와 outbounds가 모두 있어도 내부 항목은 다를 수 있습니다.
3. 아웃바운드 설정을 계층별로 비교하세요. 먼저 프로토콜과 사용자 인증을 확인한 뒤 전송 방식, 보안 계층, 흐름 제어를 살펴보세요. REALITY 전용 설정이 빠졌다면 일반 TLS 설정으로 대신 채우지 마세요.
4. 마지막으로 실행 환경 설정을 옮기세요. 로컬 수신 주소와 포트, DNS, 라우팅 태그, 규칙 순서를 확인하세요. 노드 핸드셰이크가 성공했는데 라우팅이 잘못됐다면 UUID나 공개 키를 계속 바꿀 이유가 없습니다.

Xray의 네이티브 JSON 설정을 V2Fly로 옮길 때 실행 파일만 바꿔서는 안 됩니다. 코어에 따라 알 수 없는 값을 거부하거나, 특정 파싱 경로에서 일부 설정을 무시할 수 있습니다. 어느 쪽도 마이그레이션 성공으로 볼 수 없습니다. 먼저 대상 코어의 설정 검사에 통과한 뒤 실제 프록시 요청을 보내세요.

xray version
xray run -test -config client.json
v2ray version

아래 명령은 데스크톱 명령줄 환경에서 사용합니다. 처음 두 줄은 각각 Xray 버전을 확인하고 기존 client.json 설정을 검사하며, 세 번째 줄은 V2Fly 버전을 확인합니다. 먼저 파일을 준비해야 합니다. 배포 패키지마다 명령 옵션이 다를 수 있으므로 help부터 확인하세요. 설정 검사는 파싱 및 일부 초기화 문제만 찾아낼 수 있으며, 실제 네트워크 연결 검사를 대신하지 않습니다.

5. v2rayNG와 v2flyNG 선택 기준

안드로이드에서는 이름을 보고 추측하기보다 노드 기능에 맞춰 클라이언트를 선택하는 편이 정확합니다. 제공처에서 VLESS + REALITY + Vision을 명시했다면 v2rayNG의 Xray 경로를 선택하고, 클라이언트와 내장 코어가 구독 설정 항목을 처리할 수 있는지 확인하세요. 기존에 V2Fly 네이티브 설정을 사용한다면 v2flyNG의 설정 입력 방식과 코어 버전이 해당 형식에 맞는지 먼저 확인하세요.

• 노드에 REALITY 또는 Vision이 필요함: v2rayNG를 사용하고 보안 계층, 공개 키, short ID, 지문, 흐름 제어 설정이 모두 갖춰졌는지 확인하세요.
• 기존 노드가 VMess + WebSocket + TLS임: 두 클라이언트 모두 사용할 수 있습니다. 가져오기, 핸드셰이크, 라우팅이 제대로 작동하는 조합을 유지하고 전환 전에 구독 정보와 로컬 설정을 백업하세요.
• 사용자 지정 DNS 또는 라우팅을 사용함: 클라이언트가 실제로 생성한 설정을 우선 확인하세요. 노드를 가져올 수 있다는 사실만으로 전체 호환성을 판단하면 안 됩니다.
• 데스크톱에서 v2rayN 사용: 클라이언트 버전과 선택된 코어 버전을 따로 기록하세요. 코어를 바꾼 뒤에는 연결을 다시 시작하고 이전 로그를 근거로 판단하지 마세요.

'Xray가 무조건 빠르다'거나 'V2Fly가 항상 안정적이다'라고 단정할 수는 없습니다. 노드 위치, 네트워크 패킷 손실, 서버 부하, 전송 방식, 라우팅이 모두 사용 경험에 영향을 줍니다. 코어를 비교할 때는 같은 서버와 프로토콜 조합, 같은 테스트 대상, 비슷한 시간대를 유지하세요. 그렇지 않으면 측정된 차이가 코어가 아닌 네트워크 경로에서 비롯될 수 있습니다.

6. 가져오기는 됐지만 연결되지 않을 때의 점검 순서

먼저 '로컬 프록시 진입점'과 '원격 서버 포트'를 구분하세요. 아래는 문제 해결을 위한 숫자 예시일 뿐, 모든 클라이언트의 기본값이나 속도 측정 결과가 아닙니다. 로컬 포트는 실제 설정을, 원격 포트는 노드 정보를 기준으로 확인하세요.

1. 실행 중인 코어를 확인하세요. 현재 노드를 시작한 뒤 최신 로그를 확인해 코어 계열, 버전, 첫 번째 오류를 기록하세요. 설치 패키지 이름만 확인해서는 안 됩니다.
2. 설정 로드 실패를 해결하세요. 지원되지 않는 프로토콜, 보안 계층, 흐름 제어 값이 표시되면 먼저 해당 기능을 지원하는지 확인하세요. 코어가 정상적으로 시작되지 않았다면 DNS를 반복해서 바꿔도 소용없습니다.
3. 네트워크 연결 실패를 해결하세요. 서버 주소가 올바르게 확인되는지, 원격 포트가 맞는지, 네트워크에서 연결을 허용하는지 확인하세요. TCP 포트에 연결할 수 있어도 전송 진입점에 접근할 수 있다는 뜻일 뿐, 인증 성공을 의미하지는 않습니다.
4. 핸드셰이크 오류를 해결하세요. 일반 TLS에서는 기기 시간, serverName, 인증서 체인을 확인하세요. REALITY에서는 서버 공개 키, short ID, 허용된 서버 이름, 지문 설정을 확인하세요. Vision을 사용한다면 흐름 제어 설정도 확인해야 합니다.
5. 요청이 프록시를 거치지 않는 문제를 해결하세요. 데스크톱에서는 시스템 프록시나 앱별 프록시 설정을 확인하고, 안드로이드에서는 VPN 권한과 앱별 규칙을 확인하세요. 연결은 됐지만 목적지 요청이 프록시를 통과하지 않는다면 프로토콜 설정을 계속 바꾸면 문제가 더 커질 수 있습니다.

데스크톱에서 로컬 SOCKS 진입점이 실제로 127.0.0.1:10808인 것을 확인했다면 아래 명령으로 프록시를 명시해 이 사이트에 접속할 수 있습니다. socks5h는 대상 도메인의 DNS 조회를 SOCKS 프록시 쪽에서 처리하므로 로컬 DNS 경로와 구분하기 쉽습니다.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2rayid.com/

명령에 응답이 왔다는 것은 현재 규칙에 따라 해당 대상에 로컬 진입점을 통해 요청을 보낼 수 있다는 뜻일 뿐입니다. 코어 규칙에서 직접 연결되도록 설정했다면 원격 프록시의 출구가 정상이라는 증거가 되지 않습니다. 접속 로그에서 아웃바운드를 확인한 뒤 신뢰할 수 있는 외부 IP 확인 서비스로 결과를 점검하세요. 한 번 시간 초과가 발생했다고 코어 비호환으로 단정하지 말고, 로컬 연결, 원격 핸드셰이크, 대상 접속 중 어느 단계에서 실패했는지 로그를 확인하세요.

7. 자주 묻는 호환성 질문