Xray 코어와 V2Fly 코어 비교: 기능 차이와 클라이언트 선택 가이드

두 코어 브랜치는 어디서 갈라졌을까

V2Fly와 Xray는 모두 V2Ray 기술 체계에서 파생되어 기본 구조가 비슷합니다. 설정에는 일반적으로 인바운드, 아웃바운드, 라우팅, DNS, 로그, 정책 모듈이 포함됩니다. 두 코어 모두 주요 프록시 프로토콜을 처리하고 도메인, IP, 포트 또는 규칙 집합에 따라 아웃바운드를 선택할 수 있습니다. 차이는 프록시를 실행할 수 있는지보다 이후 추가된 프로토콜 확장, 전송 구현, 설정 필드와 유지보수 방향에 있습니다.

V2Fly는 커뮤니티가 V2Ray Core를 계속 유지보수하며 v5 설정과 API를 단계적으로 발전시키고 있습니다. VMess, VLESS, Trojan, Shadowsocks, WebSocket, gRPC 등의 일반적인 조합에 의존하는 환경에 적합합니다. Xray는 기존 설정과의 호환성을 바탕으로 VLESS, XTLS Vision, REALITY 및 관련 흐름 제어 기능을 지속적으로 발전시키고 있습니다. 노드 설정에 이러한 전용 필드가 등장하면 코어 선택은 취향의 문제가 아니라 해당 설정을 해석하고 연결을 수립할 수 있는지의 문제가 됩니다.

유지보수 현황은 문제 원인 파악에도 영향을 줍니다. 오류가 발생하면 단순히 “V2Ray 연결 실패”라고 적기보다 클라이언트 버전, 코어 버전, 프로토콜, 전송 방식과 보안 계층을 먼저 기록해야 합니다. 예를 들어 테스트 환경에서 Xray-core 25.6.8과 V2Ray 5.30.0을 고정해 얻은 결과는 해당 조합에만 유효합니다. 업그레이드 후 설정 해석 규칙이 바뀌었다면 다시 테스트해야 하며, 이전 결론을 새 버전에 그대로 적용해서는 안 됩니다.

• 공통 기반: 인바운드·아웃바운드 모델, 라우팅 매칭, DNS 처리, 로그 레벨 등의 개념이 유사합니다.
• Xray의 방향: REALITY, XTLS Vision 등 Xray 생태계의 기능을 우선적으로 지원합니다.
• V2Fly의 방향: V2Ray Core의 커뮤니티 유지보수를 이어가며 자체 v5 설정 체계를 발전시킵니다.
• 이전 원칙: 먼저 전용 필드를 식별한 뒤 프로토콜과 전송을 확인하고 마지막으로 성능을 비교합니다.

VLESS, REALITY와 XTLS의 지원 범위

VLESS만으로 코어를 판단할 수는 없습니다. 두 코어 모두 VLESS 사용 사례가 있지만, 실제 설정에는 서로 다른 흐름 제어, 보안 계층과 전송 매개변수가 포함될 수 있습니다. 주소, 포트, 사용자 식별자, TCP와 TLS만 포함한 VLESS 노드와 REALITY 공개 키, 짧은 식별자, 서버 이름, 지문 및 Vision 흐름 제어가 함께 포함된 노드는 실제 의존성이 완전히 다릅니다.

REALITY는 Xray 생태계에 속합니다. 공유 링크에서 흔히 볼 수 있는 관련 매개변수는 security, pbk, sid, sni, fp, flow입니다. 노드가 security=reality를 요구한다면 해당 기능을 지원하는 Xray 코어가 필요합니다. 이러한 필드를 인식하지 못하는 코어에 링크를 전달하면 가져오기 과정에서 필드가 사라지거나, 시작 시 알 수 없는 설정 오류가 발생하거나, 연결 직후 끊길 수 있습니다.

XTLS는 과거 명칭과 현재의 흐름 제어를 구분해야 합니다. 현재 설정에서는 VLESS와 flow=xtls-rprx-vision을 함께 사용하는 형태가 일반적입니다. 이는 TLS 스위치의 이름만 바꾸는 기능이 아니라 Xray의 데이터 경로와 흐름 제어 구현에 관련된 설정입니다. 서버가 Vision을 요구한다면 클라이언트도 같은 flow를 유지해야 합니다. 이 필드를 삭제한다고 일반 TLS로 자동 전환되지는 않으며, 오히려 양쪽 매개변수가 일치하지 않게 됩니다.

설정 파일을 그대로 서로 바꿔 쓸 수 있을까

기본 JSON 구조가 비슷하다고 해서 전체 설정을 수정 없이 서로 바꿔 쓸 수 있는 것은 아닙니다. 일반적인 inbound, outbound, routing, dns 모듈은 실행 파일만 바꾸면 작동할 것 같은 인상을 주지만, 코어는 프로토콜 필드, 전송 계층 필드와 객체 계층을 각각 검증합니다. 전용 필드를 인식하지 못하면 클라이언트 가져오기 도구가 무시할 수도 있고, 심하면 코어 시작에 실패할 수 있습니다.

다음은 Xray REALITY 노드를 식별하기 위한 간소화된 구조입니다. 직접 연결할 수 있는 완전한 설정은 아니지만, security가 reality이고 flow가 xtls-rprx-vision이며 realitySettings에 publicKey와 shortId가 포함된다는 핵심 판단 기준을 보여줍니다.

{
  "protocol": "vless",
  "settings": {
    "vnext": [{
      "address": "example.invalid",
      "port": 443,
      "users": [{
        "id": "00000000-0000-0000-0000-000000000000",
        "encryption": "none",
        "flow": "xtls-rprx-vision"
      }]
    }]
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "serverName": "server.example",
      "fingerprint": "chrome",
      "publicKey": "예시 공개 키 텍스트",
      "shortId": "0123456789abcdef"
    }
  }
}

구독을 이전할 때는 “구독 내용”과 “코어 설정”도 구분해야 합니다. 구독은 일반적으로 클라이언트가 공유 링크를 먼저 해석한 뒤 코어에 필요한 JSON으로 변환합니다. 두 클라이언트가 같은 링크를 받아도 기본 지문, Mux 설정, DNS 정책과 라우팅 규칙이 달라 생성 결과가 달라질 수 있습니다. 따라서 가져오기에 성공했다는 것은 클라이언트가 텍스트를 인식했다는 뜻일 뿐, 코어가 모든 필드를 지원한다는 의미는 아닙니다.

1. 먼저 원본 설정을 복사하고 현재 코어 버전을 기록하세요. 유일하게 사용할 수 있는 설정을 바로 덮어쓰지 마세요.
2. 노드 세부 정보에서 프로토콜, 전송, 보안 계층, flow, SNI, ALPN과 지문을 확인하세요.
3. 코어를 전환한 뒤에는 단일 노드만 먼저 시작하고, 코어 로그에 unknown field, failed to parse 또는 handshake 유형의 오류가 나타나는지 확인하세요.
4. SOCKS 포트 10808과 같은 로컬 수신 포트가 다른 프로세스에 점유되지 않았는지 확인하세요.
5. DNS 해석, TCP 페이지 접속, 지속 전송을 차례로 테스트하세요. 한 번의 지연 시간 수치만 확인해서는 안 됩니다.

성능 차이는 어떻게 테스트해야 할까

같은 노드의 두 코어 간 지연 시간이 몇 밀리초 차이 나는 것만으로는 어느 코어가 더 빠르다고 보기 어렵습니다. 네트워크 경로, 서버 부하, DNS 캐시, 연결 재사용과 테스트 시간에 따라 결과가 달라집니다. 더 신뢰할 수 있는 방법은 노드, 설정, 네트워크와 테스트 대상을 고정하고 여러 차례 번갈아 실행한 뒤 중앙값, 실패 횟수와 지속 전송 안정성을 비교하는 것입니다.

재현 가능한 데스크톱 테스트는 다음과 같이 설정할 수 있습니다. 로컬 SOCKS 포트를 10808로 고정하고 연결 시간 초과를 2초로 설정하며 경로에 영향을 줄 수 있는 추가 연쇄 프록시는 끕니다. 각 코어에서 짧은 연결을 50회 실행한 다음, 회당 5분씩 지속 전송을 3회 수행합니다. 테스트 중에는 구독을 업데이트하거나 속도 측정 작업을 동시에 실행하지 마세요. 코어 로그와 대역폭 경쟁이 결과를 오염시킬 수 있습니다.

• 연결 수립: 50회 중 성공 횟수와 중앙값 소요 시간을 기록하고, 단 한 번의 최저값은 사용하지 않습니다.
• 지속 전송: 5분 동안 재연결, 멈춤 또는 핸드셰이크 오류가 발생하는지 확인합니다.
• 리소스 사용량: 동일한 연결 수에서 메모리와 프로세서 사용량을 기록하고, 최소 60초 동안 기다린 후 값을 측정합니다.
• 로그 결과: 프로토콜 오류, DNS 오류, 시간 초과와 포트 점유를 구분해 집계합니다.

일반적인 VMess + WebSocket + TLS 노드에서는 두 코어 모두 실제 처리량이 비슷한 경우가 많습니다. 이때는 작은 수치 차이보다 클라이언트 사용 습관과 설정 안정성이 더 중요합니다. REALITY 또는 Vision 노드는 테스트 전제부터 Xray로 제한됩니다. 해당 필드를 지원하지 않는 코어를 속도 비교에 포함하는 것은 연결 능력 자체가 같지 않으므로 의미가 없습니다.

v2rayN, v2rayNG와 v2flyNG 선택 방법

클라이언트 이름과 코어 이름은 같은 개념이 아닙니다. 클라이언트는 구독, 인터페이스, 라우팅 진입점, 시스템 프록시와 설정 생성을 담당하고, 코어는 실제로 설정을 해석하고 트래픽을 전달합니다. 선택할 때는 먼저 플랫폼을 확인하고, 다음으로 노드에 필요한 기능을 살핀 뒤, 마지막으로 클라이언트가 해당 설정 진입점을 제공하는지 확인해야 합니다.

v2rayN은 Windows 데스크톱 환경에 적합하며 그룹 관리, 코어 로그 확인과 라우팅 전환이 편리합니다. 현재 설정을 확인하려면 「설정」→「매개변수 설정」을 열어 코어 유형, 로컬 수신 포트와 DNS 관련 옵션을 확인하세요. 버전에 따라 메뉴 문구가 조금 다를 수 있지만, 실제 실행 중인 구성 요소를 판단하는 가장 직접적인 근거는 여전히 코어 로그입니다.

v2rayNG는 Xray 코어를 사용하며 Android에서 REALITY, XTLS Vision과 일반적인 VMess, VLESS, Trojan 노드에 적합합니다. 가져온 후 노드 세부 정보에서 전송 계층, 보안 유형, SNI, 지문과 flow를 확인할 수 있습니다. 구독 업데이트 후 갑자기 연결되지 않는다면 모든 설정을 먼저 삭제하기보다 업데이트 전후의 필드를 비교하세요.

v2flyNG는 V2Fly 코어를 사용하며 V2Fly 설정 경로를 유지하려는 Android 사용자에게 적합합니다. 기존 VMess, 표준 TLS, WebSocket, gRPC 등의 조합에 더 적합합니다. 서버가 REALITY 또는 Vision을 명확히 요구한다면 필드를 삭제해 억지로 가져오지 말고 해당 설정을 지원하는 Xray 클라이언트로 전환해야 합니다.

자주 묻는 선택 문제와 문제 해결 단계

코어가 맞지 않을 때는 비교적 명확한 신호가 나타납니다. 가져온 후 핵심 필드가 비어 있거나, 코어가 시작되지 않거나, 로그에 알 수 없는 필드가 표시되거나, 핸드셰이크 단계가 반복해서 실패하거나, 일반 노드는 작동하지만 REALITY 노드만 모두 실패하는 경우입니다. 문제를 해결할 때는 먼저 코어가 실제로 시작되었는지 확인하고, 그다음 노드 매개변수를 살핀 뒤 시스템 프록시와 라우팅을 점검해야 합니다.

최종 선택은 세 단계로 요약할 수 있습니다. 먼저 설정에 REALITY 또는 Vision이 포함되어 있는지 확인하고, 다음으로 클라이언트가 실제로 사용하는 코어를 확인한 뒤, 로그와 여러 차례의 연결 테스트로 검증하세요. 일반 노드는 두 코어 사이를 자주 이전할 필요가 없으며, 전용 프로토콜은 구현을 엄격히 일치시켜야 합니다. 이렇게 처리하는 편이 한 번의 지연 시간, 노드 이름 또는 클라이언트 이름만으로 판단하는 것보다 신뢰할 수 있습니다.