Xray-core와 V2Fly-core 차이: XTLS·REALITY 지원 및 설정 호환성

프로젝트 계보: 클라이언트·코어·노드 설정의 관계

V2Fly는 V2Ray를 이어 개발하는 커뮤니티 프로젝트이며, 핵심 프로그램은 보통 V2Fly-core라고 부릅니다. Xray-core는 2020년 V2Ray 코드 기반에서 분기한 뒤 독자적인 기능 개발과 배포 주기를 갖추었습니다. 두 프로젝트는 공통된 뿌리를 가져 설정 구조가 비슷한 경우가 많지만, 이것만으로 새 기능과 기본 동작, 필드 이름까지 항상 같다고 볼 수는 없습니다.

v2rayN은 구독 관리, 노드 편집, 설정 생성, 선택한 코어 실행을 담당하는 데스크톱 클라이언트입니다. 실제 프록시 연결은 코어 프로세스가 수행합니다. Android용 v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 클라이언트 이름이 비슷하다고 해서 지원하는 노드 기능까지 완전히 같지는 않습니다.

구독에 포함된 공유 링크도 아무 코어에서나 바로 실행할 수 있는 완전한 설정은 아닙니다. 클라이언트가 노드 매개변수를 해당 코어의 아웃바운드 객체로 변환하고 로컬 인바운드, DNS, 라우팅을 추가해야 합니다. 구독을 가져올 수 있다는 것은 클라이언트가 링크 형식을 인식했다는 뜻일 뿐입니다. 실행 및 핸드셰이크 성공 여부는 생성된 설정과 서버 요구 사항을 각각 확인해야 합니다.

기능 비교: VLESS·XTLS Vision·REALITY는 서로 다른 계층

VLESS는 프록시 프로토콜이고, Vision은 Xray에서 VLESS와 함께 사용하는 흐름 제어 방식이며, REALITY는 연결 보안 계층에 속합니다. 흔히 말하는 'VLESS + TCP + REALITY + Vision'은 실제로 네 가지 설정을 조합한 것입니다. REALITY를 VLESS의 다른 이름으로 취급하거나, VLESS라는 이유만으로 노드에 반드시 Xray가 필요하다고 단정해서는 안 됩니다.

Vision 설정은 보통 사용자 객체의 flow: "xtls-rprx-vision"으로 지정하며, security를 'Vision'으로 설정하는 방식이 아닙니다. REALITY는 일반적으로 streamSettings.security: "reality"와 해당 realitySettings로 설정합니다. Vision은 주로 TLS 또는 REALITY와 함께 사용합니다. WebSocket 노드에 Vision flow를 임의로 추가하지 마세요.

설정 호환성: 흐름 제어·보안 계층·전송 방식을 항목별로 확인

아래 두 카드는 매개변수 확인 예시이며 완전한 연결 설정이 아닙니다. 첫 번째는 Xray 전용 기능이 포함된 노드의 주요 설정을, 두 번째는 두 코어가 공통으로 지원하는 설정을 보여 줍니다. 주소, 사용자 인증 정보, 보안 매개변수는 실제 서버 설정이나 구독에서 확인해야 하며 노드 이름만으로 추측하면 안 됩니다.

• 사용자 객체: id, flow, 프로토콜 전용 필드를 확인하세요. VLESS의 encryption: "none"은 연결 전체에 보안 계층이 없다는 뜻이 아닙니다. TLS 또는 REALITY는 별도의 계층입니다.
• REALITY 매개변수: serverName, fingerprint, shortId와 서버에서 제공한 키 매개변수를 확인하세요. Xray 버전에 따라 필드 이름과 별칭의 허용 여부가 달라질 수 있습니다. 이전 설정의 publicKey 같은 표기는 실제 실행 버전에 맞춰 확인하고 V2Fly 설정에 그대로 적용하지 마세요.
• 전송 객체: network와 해당 설정 객체를 확인하세요. 최신 Xray 문서나 생성된 설정에는 raw 같은 이름이 사용될 수 있지만, V2Fly도 같은 표기를 허용한다고 가정하면 안 됩니다. WebSocket 경로와 요청 헤더도 빠뜨리지 마세요.
• 보안 확인: 일반 TLS 노드는 인증서 도메인과 SNI를 확인해야 합니다. 인증서 검증을 건너뛰는 설정을 일반적인 이전 절차로 사용하지 마세요. 프로토콜 불일치를 해결하지 못할 뿐 아니라 보안 경계도 바뀝니다.

오래된 안내서에서 단독으로 'XTLS'라고 부르는 설정은 초기 방식일 수 있으며 현재의 Vision과는 다릅니다. 이전할 때 실제 flow 값과 보안 계층을 확인해 과거 설정을 새 버전에 그대로 복사하지 않도록 하세요. 클라이언트를 업그레이드한 뒤에는 클라이언트 버전 번호만 기록하지 말고 실제 실행 중인 코어 버전도 확인해야 합니다.

v2rayN 코어 전환: 먼저 백업하고 최소한으로 검증

v2rayN은 버전에 따라 메뉴 이름과 코어 선택 위치가 달라질 수 있습니다. 먼저 '설정' → '매개변수 설정'에서 코어 관련 옵션을 찾아보세요. 현재 버전에서 노드 유형별로 코어를 선택할 수 있다면 해당 화면의 'Core 유형' 또는 이에 해당하는 항목을 기준으로 삼으세요. 모든 프로토콜의 코어를 한꺼번에 바꾼 뒤 DNS, 라우팅, 시스템 프록시까지 동시에 수정하지 마세요.

1. 기준 상태 기록. 현재 클라이언트 설정을 백업하고 클라이언트 버전, 로그에 표시된 코어 버전, 선택한 노드, 로컬 리스닝 주소와 포트를 기록하세요. 민감한 구독 주소는 로컬에만 보관하세요.
2. 공통 지원 노드 선택. 우선 두 코어에서 모두 지원하는 기존 VMess + WebSocket + TLS 노드 등으로 검증하세요. REALITY 노드만 있다면 V2Fly로 전환할 때 동등한 조건으로 테스트할 수 없습니다.
3. 한 번에 하나만 변경. 해당 프로토콜의 코어 선택을 변경하고 연결을 중지한 뒤 다시 시작하세요. 새 프로세스가 실행되었는지 확인한 다음 로그에서 실제 코어를 확인해 이전 프로세스가 포트를 계속 점유하고 있지 않은지 살펴보세요.
4. 로컬 연결 지점 확인. 앱의 프록시 유형과 포트를 그대로 둔 채 실제 웹 요청을 한 번 보내세요. 지연 시간 테스트에 숫자가 표시되어도 브라우저의 시스템 프록시 연결이 올바르다는 뜻은 아닙니다.
5. 기능을 단계별로 복구. 기본 연결을 확인한 다음 사용자 지정 라우팅, DNS, 기타 고급 설정을 복구하세요. 항목을 하나씩 복원할 때마다 다시 테스트하면 호환성 문제를 찾기 쉽습니다.

위 숫자는 로컬 연결 지점과 원격 출구를 구분하기 위한 예시이며 클라이언트의 고정 기본값이 아닙니다. 실제 포트는 현재 설정을 기준으로 확인하세요. 로컬 리스너가 HTTP, SOCKS, 혼합 방식 중 무엇인지도 함께 확인해야 합니다. 원격 서버가 443을 사용하더라도 브라우저의 시스템 프록시를 로컬 443으로 설정하는 것은 아닙니다.

실행 및 연결 문제 해결: 설정 검사를 통과해도 핸드셰이크가 성공하는 것은 아닙니다

전체 설정을 직접 관리하는 경우 코어에 포함된 설정 검사 명령부터 실행할 수 있습니다. 아래는 Xray와 V2Fly v5에서 흔히 사용하는 명령줄 형식입니다. client.json은 로컬에 저장된 완전한 설정 파일을 뜻합니다. 다른 버전은 먼저 도움말 명령으로 매개변수를 확인하세요. 클라이언트가 자동 생성한 임시 파일을 오프라인 검사에 사용하려면 먼저 복사해 백업해야 합니다.

xray version
xray run -test -config client.json

v2ray version
v2ray test -c client.json

설정 검사는 구문 오류, 일부 잘못된 필드, 지원되지 않는 조합을 찾아낼 수 있지만 원격 서버에 연결할 수 있는지 또는 인증 정보가 올바른지까지 증명하지는 않습니다. 코어가 정상적으로 시작된 뒤에는 실제 연결을 시도해 아웃바운드 핸드셰이크와 요청이 완료되는지 확인해야 합니다. 아래 표는 실패 단계를 나눠 모든 오류를 '노드 불량'으로 뭉뚱그리지 않도록 정리했습니다.

라우팅의 geosite:와 geoip:는 데이터 파일의 내용과 로드 경로에도 영향을 받습니다. 두 코어가 같은 규칙 문법을 인식하더라도 로컬 데이터에 해당 분류가 있다는 뜻은 아닙니다. 이전할 때 domainStrategy, DNS 서버, 아웃바운드 태그, 최종 기본 규칙까지 함께 확인해야 합니다. 그렇지 않으면 '실행은 되지만 라우팅 결과가 달라지는' 문제가 생길 수 있습니다.

자주 묻는 질문: 코어 선택과 성능 판단