Xray 코어와 V2Fly 코어의 차이: VLESS·XTLS·REALITY 지원 비교 및 선택 가이드

Project V, V2Fly, Xray의 관계

먼저 클라이언트와 코어를 구분해야 합니다. v2rayN, v2rayNG, v2flyNG는 구독 관리, 노드 목록, 시스템 프록시와 그래픽 설정을 담당하며, Xray-core와 v2ray-core는 실행 설정을 해석하고 연결을 수립하며 DNS와 라우팅 규칙을 처리합니다. 인터페이스에서 공유 링크를 인식한다고 해서 현재 코어가 링크의 모든 필드를 실행할 수 있다는 뜻은 아닙니다.

V2Fly는 Project V 체계의 v2ray-core를 이어갑니다. 설정은 여전히 inbounds, outbounds, routing, dns, transport를 중심으로 구성됩니다. VMess, SOCKS, HTTP, Shadowsocks와 WebSocket, gRPC, TLS처럼 오랫동안 안정적으로 사용된 조합에 적합합니다. 유지보수 방향은 범용 프록시 플랫폼과 설정 인터페이스의 지속적인 발전에 초점을 둡니다.

Xray-core는 같은 설정 체계에서 발전했으며, 많은 V2Ray JSON 구조를 유지하면서 VLESS, XTLS Vision, REALITY와 새로운 전송 방식에 필요한 필드를 확장했습니다. 따라서 두 프로젝트는 완전히 무관한 별개의 프로젝트가 아니지만, 설정 파일에서 프로그램 이름만 바꾸면 항상 작동한다고 이해해서도 안 됩니다.

VMess·VLESS·XTLS·REALITY 지원 차이

VMess는 두 코어가 공통으로 지원하는 기반입니다. 서버가 VMess를 사용하고 기존 TCP, WebSocket 또는 gRPC 전송을 조합한다면 Xray와 최신 V2Fly 모두 대체로 연결할 수 있습니다. 이전할 때는 alterId, 암호화 방식, Host, 경로와 TLS 서버 이름을 다시 확인해야 하며, 필드 하나라도 빠지면 핸드셰이크 실패로 나타날 수 있습니다.

VLESS는 프로토콜 이름만으로 판단할 수 없습니다. 최신 코어가 일부 기본 VLESS 설정을 모두 처리할 수 있더라도, VLESS를 XTLS Vision·REALITY와 조합하면 실제로는 Xray의 확장 필드와 핸드셰이크 절차에 의존합니다. 공유 링크에 flow=xtls-rprx-vision, security=reality, pbk, sid 또는 fp가 있으면 바로 Xray를 선택하세요.

전송 계층과 JSON 설정의 호환 범위

두 코어 모두 계층형 설정 방식을 사용합니다. 인바운드는 로컬 트래픽을 받고, 아웃바운드는 원격 서버에 연결하며, 라우팅은 트래픽을 프록시·직접 연결·차단 출구 중 어디로 보낼지 결정합니다. 일반적인 routing.rules, dns.servers, inbounds, outbounds 구조가 비슷하므로 단순한 설정은 재사용되는 경우가 많습니다.

호환성의 경계는 주로 streamSettings에서 나타납니다. Xray 노드는 security, realitySettings, tlsSettings, grpcSettings 또는 다른 전송 객체에 전용 필드를 추가할 수 있습니다. V2Fly는 알 수 없는 필드를 만나면 시작 단계에서 설정 오류를 바로 보고할 수도 있고, 버전 차이에 따라 일부 내용을 무시할 수도 있습니다. 필드를 무시한다고 해서 연결 매개변수가 올바른 것은 아닙니다.

구독 링크 역시 코어가 직접 저장하고 갱신하는 방식이 아닙니다. 클라이언트가 먼저 구독을 읽고 vmess:// 또는 vless:// 내용을 실행 설정으로 변환한 다음 선택한 코어를 호출합니다. 따라서 호환성 문제는 두 단계로 나뉩니다. 클라이언트가 공유 필드를 인식하는지, 그리고 코어가 해당 필드에 대응하는 프로토콜 동작을 구현했는지 확인해야 합니다.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.net",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.example.com",
          "fingerprint": "chrome",
          "publicKey": "examplePublicKey",
          "shortId": "6ba85179e30d4fc2"
        }
      }
    }
  ]
}

1. 먼저 원본 설정을 복사해 복구 가능한 버전을 남기고, 현재 사용 중인 파일을 직접 덮어쓰지 마세요.
2. 코어의 설정 테스트를 실행하거나 클라이언트에서 한 번 시작해 보고, unknown field, failed to parse config, invalid user 오류부터 처리하세요.
3. 아웃바운드의 프로토콜, network, security, flow 네 항목을 확인하세요. REALITY 설정을 일반 TLS로 바꿔 계속 사용해서는 안 됩니다.
4. 로컬 수신 포트가 충돌하지 않는지 확인하세요. 이 글의 테스트에서는 SOCKS 10808, HTTP 10809를 사용하며, 하나의 포트는 하나의 프로세스만 수신할 수 있습니다.
5. 연결 후 코어 로그를 확인하세요. TCP 연결은 수립됐지만 TLS 또는 REALITY 핸드셰이크가 실패한다면 serverName, 공개 키, shortId와 시스템 시간을 다시 확인해야 합니다.

v2rayN·v2rayNG·v2flyNG의 기본 코어 구성

데스크톱에서는 v2rayN을 우선 사용하세요. 현재 널리 사용되는 버전은 Xray를 주요 코어로 사용하므로 VMess, VLESS, XTLS Vision, REALITY 노드를 함께 저장하기에 적합합니다. 확인이 필요하면 「설정」→「매개변수 설정」→「Core 유형」을 열어 대상 프로토콜이 Xray에 할당됐는지 확인하세요. 시스템 프록시 스위치만 확인해서는 안 됩니다.

Android용 v2rayNG는 Xray 코어를 사용하며 REALITY 노드가 포함된 구독을 v2rayN과 함께 사용하기에 적합합니다. v2flyNG는 V2Fly 코어를 사용하므로 기존 서버가 v2ray-core를 명확히 사용하고 노드가 VMess와 일반적인 전송 위주인 환경에 더 적합합니다. 두 클라이언트의 인터페이스는 비슷하지만 코어 기능까지 완전히 같다고 볼 수는 없습니다.

v2flyNG를 선택할 조건

• 서버가 명확히 V2Fly를 실행하고 기존 노드가 VMess, TCP, WebSocket, gRPC 또는 일반 TLS 위주인 경우
• 구독에 xtls-rprx-vision, REALITY 공개 키, shortId 같은 Xray 전용 매개변수가 없는 경우
• 동일한 V2Fly JSON 로직을 검증해야 하고 라우팅 규칙이 현재 v2ray-core의 동작에 의존하는 경우
• 새 노드를 추가할 때 프로토콜 지원 여부를 다시 확인할 의향이 있으며, 모든 VLESS 링크가 기본적으로 바로 작동한다고 가정하지 않는 경우

성능 차이와 실제 선택 방법

코어 이름 자체는 일반적으로 속도 차이의 주요 원인이 아닙니다. 같은 서버, 같은 VMess WebSocket TLS 노드와 같은 라우팅 규칙을 사용하면 처리량은 네트워크 경로, TLS 핸드셰이크, 서버 부하와 WebSocket 추가 오버헤드의 영향을 더 크게 받습니다. 먼저 프로토콜 호환성을 확인한 뒤 속도를 비교하세요.

이 글에서는 다운로드 300 Mbps, 업로드 50 Mbps, 왕복 지연 시간 38ms인 고정 회선에서 500 MiB 파일을 테스트했습니다. VMess·WebSocket·TLS 조합에서 Xray의 평균 다운로드 속도는 286 Mbps, V2Fly는 281 Mbps였으며 5회 측정 차이는 약 1.8%였습니다. 이 결과는 동일한 기존 프로토콜에서 두 코어 사이에 큰 규모의 성능 차이가 없다는 점만 보여 주며, 다른 회선에 그대로 적용할 수는 없습니다.

VLESS·Vision·REALITY로 전환하면 핵심은 기능 사용 가능 여부가 됩니다. Xray는 5회 연결을 완료해 평균 다운로드 292 Mbps를 기록했지만, V2Fly는 이 매개변수 조합을 일반 VLESS TLS 설정과 동등하게 실행할 수 없었습니다. 이 경우에는 호환성 전제가 성립하지 않으므로 두 코어의 속도를 비교해서는 안 됩니다.

1. 구독 노드의 상세 정보를 확인하세요. VMess, WebSocket, TLS가 보이면 두 코어 간 호환성 테스트를 진행할 수 있습니다.
2. VLESS가 보이면 flow와 security를 계속 확인하세요. Vision 또는 REALITY가 있으면 Xray를 선택합니다.
3. TCP 연결 수립, TLS 핸드셰이크와 첫 바이트까지의 시간을 각각 측정하세요. 클라이언트에 표시되는 ICMP 또는 TCP 지연 시간만 확인해서는 안 됩니다.
4. 고정 크기 파일을 3~5회 연속 다운로드하고 평균 속도와 실패 횟수를 기록해 일시적인 회선 변동을 배제하세요.
5. 마지막으로 실제 라우팅 규칙을 활성화하고 DNS와 분할 라우팅이 결과를 바꾸는지 확인하세요. 전역 프록시 테스트만으로는 실제 분할 라우팅 환경을 대신할 수 없습니다.

일반적인 호환성 문제와 처리 절차

최종 선택 체크리스트

• 새 데스크톱 설정 또는 여러 프로토콜이 섞인 구독: v2rayN과 Xray를 사용하세요.
• Android에서 VLESS, Vision, REALITY가 필요함: v2rayNG를 사용하세요.
• 기존 V2Fly 서버와 VMess·일반 전송 중심 환경: v2flyNG를 사용할 수 있습니다.
• 하나의 구독을 여러 기기에서 사용: 가능한 한 양쪽 코어의 지원 범위를 일치시키세요.
• JSON 이전: 먼저 설정을 테스트하고, 그다음 노드에 연결한 뒤 마지막으로 DNS와 라우팅 규칙을 복원하세요.