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

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

Xray-core와 V2Fly가 관리하는 V2Ray-core는 서로 다른 코어 프로젝트입니다. 기술적 뿌리를 공유하지만 현재는 각자 발전하고 있습니다. 코어는 인바운드 연결을 처리하고 라우팅 규칙을 적용해 프록시 아웃바운드를 설정합니다. 클라이언트는 구독 관리와 화면 조작을 담당하고 설정을 생성합니다. 클라이언트에 노드가 표시된다고 해서 현재 코어가 해당 노드의 모든 필드를 처리할 수 있는 것은 아닙니다.

v2rayN은 데스크톱 클라이언트이며 실제 연결 기능은 선택한 코어와 버전에 따라 달라집니다. Android에서는 v2rayNG가 Xray 코어를, v2flyNG가 V2Fly 코어를 사용하는 경우를 기준으로 설명합니다. 설치 패키지 버전과 코어 버전은 별개이므로 문제를 점검할 때 각각 기록하세요. 클라이언트 버전만으로 프로토콜 지원 여부를 판단하면 안 됩니다.

• 파싱 단계: 클라이언트가 구독 필드를 인식해야 매개변수가 설정에 온전히 반영됩니다.
• 로드 단계: 코어가 필드 이름과 값, 조합을 허용해야 프로세스가 정상적으로 시작됩니다.
• 연결 단계: 서버 매개변수와 인증서, 시간, 네트워크 경로가 일치해야 핸드셰이크가 완료됩니다.

이 세 단계는 각각 실패할 수 있습니다. 예를 들어 클라이언트에서 가져오기는 성공했지만 생성된 설정에 REALITY 공개 키가 누락될 수 있습니다. 코어는 실행됐어도 서버와 클라이언트의 shortId가 다를 수도 있습니다. 따라서 ‘목록에 노드가 표시됨’과 ‘노드에 연결할 수 있음’은 따로 확인해야 합니다.

프로토콜 비교: VLESS와 REALITY는 다릅니다

VLESS는 프록시 프로토콜, XTLS Vision은 특정 흐름 제어 방식, REALITY는 Xray의 보안 계층 방식입니다. 서로 같은 계층의 개념이 아닙니다. 구독 링크가 vless://로 시작한다는 사실만으로 V2Fly에서 사용할 수 있는지 판단할 수 없습니다. 전송 방식과 보안 계층, flow도 확인해야 합니다.

여기서 ‘지원’은 어떤 설정이든 서로 바꿔 쓸 수 있다는 뜻이 아닙니다. 양쪽에서 같은 프로토콜을 사용할 수 있다는 것은 공통 기능이 있다는 의미일 뿐입니다. 새로운 전송 방식과 설정 형식, 확장 매개변수는 실제 버전에 맞춰 확인해야 합니다. 특히 Xray의 새 전송 필드를 V2Fly 설정에 그대로 복사하지 마세요.

XTLS·Vision·REALITY: 설정 이름의 차이

이전 튜토리얼의 XTLS를 현재 흔히 쓰는 Vision 설정과 그대로 대응해서는 안 됩니다. xtls-rprx-direct 같은 예전 flow 이름을 새 설정에 복사하지 마세요. 일반적인 Vision 조합은 flow: xtls-rprx-vision을 사용하며, 보안 계층은 TLS 또는 REALITY로 설정할 수 있습니다. Vision을 REALITY에서만 쓸 수 있는 것은 아닙니다.

REALITY는 TLS 인증서 검증을 끄는 기능이 아닙니다. 클라이언트는 서버에서 제공한 공개 키와 허용된 serverName, shortId, 지문 등의 매개변수를 확인해야 합니다. 서버 개인 키는 서버에만 보관해야 하며 구독 필드로 클라이언트에 전달하면 안 됩니다. 일반 TLS는 보통 인증서 체인과 이름을 검증하므로 인증서 오류가 발생하면 먼저 이름과 시스템 시간을 확인하세요.

WebSocket 노드에 Vision flow를 임의로 추가하거나 TLS 노드의 security를 REALITY로 바꾼 뒤 자동으로 호환되기를 기대하지 마세요. 이런 변경은 연결 프로토콜을 바꾸므로 서버에서 해당 설정을 제공해야 합니다. 구독 정보가 불완전하다면 다른 노드의 공개 키나 shortId를 복사하지 말고 누락된 매개변수를 확인하세요.

설정 이전: 포트가 같아도 설정은 다를 수 있습니다

코어를 바꾸기 전에 기존 설정을 보관하고 노드 하나부터 검증하세요. 구독 링크, 클라이언트에 저장된 노드 정보, 코어 JSON은 서로 다른 데이터 형식입니다. 모두 JSON이어도 설정 형식이 다를 수 있습니다. V2Fly의 여러 설정 형식과 Xray에서 흔히 쓰는 JSON 설정은 파일 확장자만으로 호환 여부를 판단할 수 없습니다.

다음 숫자는 문제 점검을 위한 설정 예시이며 모든 버전의 기본값은 아닙니다. 서버 포트 443과 로컬 포트 10808은 서로 다른 방향의 포트입니다. 로컬 포트가 사용 중이라면 서버 포트를 바꿔도 대개 해결되지 않습니다. 서버에서 443 포트로 해당 서비스를 제공하지 않는다면 로컬 인바운드가 정상이어도 프록시 연결은 완료되지 않습니다.

1. 기존 환경 기록: 클라이언트 버전과 시작 로그의 코어 버전, 노드의 전송 방식 및 보안 계층을 기록하고 복구 가능한 설정을 보관하세요.
2. 공통 프로토콜부터 테스트: 매개변수가 모두 갖춰진 VMess + WebSocket + TLS 같은 공통 조합으로 기준을 확인하세요. 확장 노드부터 한꺼번에 이전하지 마세요.
3. 생성된 설정 확인: protocol, 전송 설정, TLS 이름, 아웃바운드 태그를 점검하세요. 로그를 공유하기 전에 인증 정보는 삭제해야 합니다.
4. 규칙 의존성 확인: 실제 코어에서 geosite.dat와 geoip.dat을 찾을 수 있는지, 규칙에서 참조하는 분류가 존재하는지 확인하세요.
5. 기능을 하나씩 복원: DNS와 라우팅 분기, TUN을 차례로 복원해 여러 설정의 오류가 한꺼번에 겹치지 않도록 하세요.

라우팅과 DNS도 부가 기능이 아닙니다. 같은 도메인이라도 DNS를 처리하는 위치와 IPv6 사용 가능 여부, 규칙 순서에 따라 다른 아웃바운드로 연결될 수 있습니다. 코어를 비교할 때는 이러한 설정을 동일하게 유지하세요. 그래야 속도 변화가 프록시 연결에서 직접 연결로 바뀐 결과인지, 프로토콜 효율 차이인지 구분할 수 있습니다. 규칙에 관한 자세한 내용은 심화 설정의 DNS 설정을 참고하세요.

클라이언트 선택: v2rayNG와 v2flyNG 비교

Android 클라이언트를 고를 때는 현재 구독에서 필요한 기능과 사용 습관을 먼저 살펴보세요. REALITY나 Vision 노드를 사용한다면 해당 Xray 기능을 지원하는 v2rayNG 버전을 선택해야 합니다. 기존 V2Fly 설정을 보유하고 공통 프로토콜을 사용하며 기존 코어 경로를 유지하려면 v2flyNG를 검토할 수 있습니다. 노드 개수나 비슷한 화면만으로 프로토콜 호환 여부를 판단해서는 안 됩니다.

• v2rayNG: Xray 확장 기능이 필요한 노드에 적합합니다. 가져온 뒤에도 flow와 지문, 공개 키 등이 구버전 파서에서 누락되지 않았는지 확인하세요.
• v2flyNG: V2Fly가 지원하는 노드와 설정에 적합합니다. 가져오기에 성공했다고 REALITY를 지원한다는 뜻은 아닙니다.
• v2rayN: 데스크톱에서는 노드가 실제로 어떤 코어를 호출하는지 확인하세요. 클라이언트를 업데이트한 뒤 시작 로그를 살펴 실행 중인 코어도 업데이트됐는지 확인해야 합니다.

노드 필드를 직접 보완하면 연결되지만 같은 구독을 가져오지 못한다면 코어가 아니라 클라이언트 파싱 단계의 문제일 수 있습니다. 반대로 화면에서 모든 필드를 저장할 수 있어도 코어가 해당 flow를 지원하지 않는다고 보고할 수 있습니다. 두 문제를 구분하면 실제 오류 지점을 바꾸지 못한 채 재설치만 반복하는 일을 피할 수 있습니다.

문제 해결 순서: 필드에서 핸드셰이크, 네트워크까지

‘시작 실패’와 ‘시작 후 접속 불가’는 서로 다른 문제입니다. 전자는 설정 형식과 필드 지원 여부, 포트 사용 여부부터 확인하고, 후자는 주소 확인과 핸드셰이크 매개변수, 라우팅을 살펴보세요. 오류 메시지 원문이 중요합니다. 아래 내용은 흔한 오류의 의미를 설명하며, 모든 버전에서 같은 문구가 표시된다는 뜻은 아닙니다.

속도 측정도 조건을 동일하게 유지해야 합니다. TCP 핸드셰이크가 성공해도 해당 시점에 대상 포트에 접근할 수 있었다는 뜻일 뿐, VLESS 인증이나 TLS 또는 REALITY 핸드셰이크까지 완료된 것은 아닙니다. Xray와 V2Fly를 비교할 때는 양쪽에서 지원하는 동일한 프로토콜 조합과 출구, 테스트 주소를 사용하세요. 실제 요청 지연 시간과 다운로드 처리량을 각각 기록하고 하나의 ‘속도’ 점수로 합치지 마세요.

선택 기준은 간단합니다. REALITY나 Vision이 필요하면 Xray 경로를 선택하고, 공통 프로토콜을 사용한다면 설정 호환성과 기존 운영 방식을 고려하세요. 코어 이름이 안정성을 직접 결정하지는 않습니다. 재현 가능한 연결을 위해서는 완전한 매개변수와 호환되는 버전, 올바른 DNS 및 라우팅 설정이 필요합니다.