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

1. Xray와 V2Fly: 같은 뿌리지만 설정까지 호환되지는 않습니다

Project V는 네트워크 프록시 도구와 프로토콜, 설정 기능을 중심으로 발전한 프로젝트 생태계이며, V2Ray는 그중 주요 구현체입니다. V2Fly 커뮤니티는 V2Ray를 계속 유지 관리하고 있습니다. Xray는 2020년 V2Ray 코드 기반에서 분리된 뒤 독자적으로 발전했습니다. 따라서 인바운드, 아웃바운드, 라우팅, DNS 구조가 비슷하더라도 두 코어를 같은 프로그램의 다른 이름으로 볼 수는 없습니다.

코어는 실제 연결을 처리합니다. 로컬 요청을 받고, 아웃바운드를 선택하고, 전송을 설정한 뒤 프로토콜 통신을 수행합니다. 클라이언트는 인터페이스와 구독 관리, 매개변수 생성, 프로세스 제어를 담당합니다. 클라이언트에 옵션이 표시된다고 해서 현재 실행 중인 코어가 해당 기능을 지원하는 것은 아닙니다. 반대로 코어가 지원하는 필드가 클라이언트의 그래픽 인터페이스에 아직 제공되지 않을 수도 있습니다.

호환성을 판단하려면 이 흐름을 따라가며 확인해야 합니다. 공유 링크를 가져올 수 있다는 것은 클라이언트가 링크 형식을 인식했다는 뜻일 뿐입니다. 설정 파일을 불러올 수 있어도 문법과 일부 필드가 통과했다는 의미에 그칩니다. 실제 연결을 수립하고 인증을 완료한 뒤 대상 사이트의 응답을 받아야 해당 연결 경로가 정상적으로 작동한다고 볼 수 있습니다.

2. XTLS Vision과 REALITY의 역할

XTLS Vision은 Xray의 플로우 제어 기능이며, 흔히 xtls-rprx-vision 값을 사용합니다. 프록시 연결의 TLS 트래픽 처리 방식을 최적화해 프로토콜·전송·보안 계층의 조합이 지원되는 경우 불필요한 중복 처리를 줄입니다. 서버 주소만 입력해 사용하는 독립 프록시 프로토콜도 아니고, 어떤 노드든 빠르게 만들어 주는 기능도 아닙니다.

REALITY는 Xray가 제공하는 보안 계층 방식으로, TLS 핸드셰이크와 특정 인증 매개변수를 사용합니다. 일반 TLS와 설정 및 검증 방식이 다르며, 클라이언트에는 보통 서버 이름, 서버가 제공하는 공개 키 자료, 짧은 ID 등의 정보가 필요합니다. 일반적인 REALITY 구성에서는 프록시 진입점에 일반 TLS 방식의 도메인 인증서를 설정할 필요가 없지만, 올바른 대상 사이트와 핸드셰이크 및 인증 설정은 여전히 필요합니다.

Vision과 REALITY는 하나의 노드에 함께 설정될 수 있지만 같은 기능은 아닙니다. Vision은 지원되는 일반 TLS 조합에도 사용할 수 있습니다. 오래된 자료에 나오는 다른 XTLS flow 이름을 Vision으로 바꿔 쓸 수도 없습니다. 프로토콜, 플로우 제어, 전송 방식, 보안 계층을 하나의 조합으로 확인하고, 구체적인 지원 범위는 양쪽 코어 버전도 함께 고려해야 합니다.

3. 설정 비교: 인터페이스의 이름이 같아도 JSON 구조는 다를 수 있습니다

아래 두 카드는 일반적인 구성 두 가지의 확인 항목을 보여 주며, 그대로 연결할 수 있는 노드 설정은 아닙니다. 서버 주소와 사용자 ID, 인증 자료는 실제 서버 설정에서 확인해야 합니다. 카드에 표시된 /ws는 예시 경로이며 서버와 리버스 프록시에서도 같은 경로를 사용할 때만 유효합니다.

일반적인 Xray 설정에서 streamSettings.security는 전송 보안 계층을 선택하고, flow는 해당 사용자 설정에 속합니다. 둘은 서로 바꿔 쓸 수 없습니다. TLS 서버 이름과 WebSocket Host에 같은 도메인을 입력하는 경우가 많지만, 하나는 TLS 핸드셰이크와 인증서 검증에 사용되고 다른 하나는 HTTP 요청 정보에 해당합니다. 문제를 해결할 때는 각각 따로 확인하세요.

• 구조 호환성:inbounds, outbounds, routing 등의 이름이 비슷해도 내부 필드가 모두 같은 것은 아닙니다.
• 프로토콜 호환성: VMess, Trojan, Shadowsocks 등 흔히 지원되는 프로토콜도 구체적인 암호화 방식과 전송 조합, 버전을 확인해야 합니다. 프로토콜 이름만 비교해서는 안 됩니다.
• 버전 호환성: V2Fly의 설정 형식과 Xray의 필드는 버전에 따라 달라집니다. 오래된 튜토리얼의 필드 위치나 이름이 현재 버전에서도 동일하다고 가정하지 마세요.
• 데이터 파일 호환성:geosite:, geoip:를 사용하는 라우팅 규칙은 해당 데이터 파일과 로드 경로도 올바르게 설정해야 합니다.

4. v2rayN·v2rayNG·v2flyNG와 코어의 관계

v2rayNG는 Xray 코어를 사용하는 안드로이드 클라이언트이고, v2flyNG는 V2Fly 코어를 사용하는 안드로이드 클라이언트입니다. 이름과 일부 인터페이스가 비슷해도 한쪽 클라이언트에서 가져오기에 성공한 노드가 다른 쪽에서도 작동한다고 볼 수는 없습니다. 특히 REALITY와 Vision 노드는 코어 지원 여부를 먼저 확인한 다음, 가져오기 과정에서 매개변수가 모두 유지됐는지 살펴보세요.

v2rayN은 데스크톱 클라이언트입니다. 인터페이스와 실제로 실행되는 코어 프로그램은 구분해서 확인해야 합니다. 문제를 해결할 때는 클라이언트 이름만으로 모든 노드가 같은 코어에서 실행된다고 추측하지 말고, 현재 설정과 시작 로그, 실제 호출된 코어를 기준으로 판단하세요. 메뉴 문구는 데스크톱 버전에 따라 바뀔 수 있으므로 설정을 기록할 때 클라이언트와 코어 정보도 함께 적어 두세요.

1. 먼저 클라이언트 확인:정보 또는 버전 화면에서 클라이언트 이름을 확인하고, 설치 파일 이름만 기록하지 마세요.
2. 다음으로 코어 확인:시작 로그에서 코어 이름과 버전을 확인하세요. 시작에 실패했다면 먼저 설정 파싱 오류를 살펴보세요.
3. 노드 설정 확인:메모만 보지 말고 프로토콜, 전송 방식, 보안 계층, 서버 이름, flow를 하나씩 확인하세요.
4. 마지막으로 앱 연결 설정 확인:안드로이드에서는 VPN 연결 권한과 앱별 설정을 확인하고, 데스크톱에서는 앱이 사용하는 로컬 프록시 주소와 포트를 확인하세요.

5. 구독 및 사용자 설정 이전: 계층별로 검증하기

구독은 설정을 배포하는 방식이지, 모든 코어에 통용되는 설정 표준은 아닙니다. 같은 구독이라도 클라이언트에 따라 파싱 방식과 필드 매핑, 기본값 보완 과정이 달라질 수 있습니다. 이름과 주소, 포트가 표시된다고 해서 REALITY 매개변수와 플로우 제어, 라우팅 규칙까지 모두 유지됐다는 뜻은 아닙니다. 이전하기 전에 기존 클라이언트에서 작동하는 설정을 보존하고, 새 클라이언트에서는 노드 하나만 따로 검증하세요.

두 포트는 서로 다른 연결 단계에 사용됩니다. 원격 진입점은 다른 포트를 사용할 수 있고 로컬 수신 포트도 변경할 수 있으므로 둘이 같을 필요는 없습니다. 브라우저 프록시를 원격 443 포트로 지정하거나 노드 서버 포트를 로컬 10808로 바꿔도 코어 비호환 문제는 해결되지 않습니다.

1. 기준 설정 저장:연결되는 노드 하나를 기록하고 기존 프로토콜, 전송 방식, 보안 계층, 라우팅 설정을 보존하세요. 민감한 인증 정보는 로컬에만 저장하세요.
2. 최소 연결부터 검증:복잡한 분할 라우팅은 일단 옮기지 말고 새 클라이언트에서 노드 하나로 연결되는지 확인하세요. DNS, 라우팅, 프로토콜을 한꺼번에 바꾸지 마세요.
3. 가져온 필드 확인:원본 노드에서 Vision을 사용한다면 flow가 xtls-rprx-vision으로 유지됐는지 확인하세요. REALITY를 사용한다면 서버 이름, 짧은 ID, 공개 키 자료를 확인하세요.
4. 분할 라우팅 복구:라우팅 규칙을 하나씩 옮기고 각 outboundTag가 정의된 아웃바운드와 일치하는지, 규칙 순서가 올바른지 확인하세요.
5. 업데이트 동작 확인:구독을 한 번 수동으로 새로고침해 사용자 설정이 덮어써지는지 확인하세요. 장기적으로 유지할 설정은 클라이언트에서 제공하는 지속 설정 기능에 입력하세요.

서버 이름을 임의의 인기 도메인으로 바꾸면 안 되며, REALITY 공개 키 자료를 클라이언트에서 임시로 생성해 대체할 수도 없습니다. 모두 서버 설정에 연결된 값입니다. 구독에 필수 항목이 빠져 있다면 코어를 바꿔 가며 해결하려 하지 말고 설정 제공자에게 전체 매개변수를 확인하세요.

6. 오류 진단: 설정 파싱부터 수신 포트와 원격 핸드셰이크까지

가장 효율적인 문제 해결 방법은 먼저 어느 단계에서 실패했는지 확인하는 것입니다. 설정이 파싱되지 않았다면 속도 측정이나 DNS 변경은 의미가 없습니다. 코어가 정상적으로 시작됐지만 연결 시간이 초과되더라도, 타임아웃만으로 특정 프로토콜이 지원되지 않는다고 단정할 수는 없습니다. 아래 로그 예시는 흔히 나타나는 상황을 설명하며, 실제 문구는 버전과 운영체제에 따라 달라질 수 있습니다.

문제를 찾는 동안 로그 상세 수준을 잠시 높이면 도움이 되지만, 확인이 끝나면 평소 설정으로 되돌리세요. 로그를 공유하기 전에는 서버 주소, 사용자 ID, 구독 주소, 인증 자료를 삭제하세요. 인증서 검증을 끄는 방법을 일반 TLS의 장기 해결책으로 사용하지 마세요. 인증서 체인이나 서버 이름, 시스템 시간에 문제가 있다면 원인을 바로잡아야 합니다.

7. 코어 선택 및 자주 묻는 질문