Xray와 V2Fly 코어 차이 완벽 정리: 버전 관계와 클라이언트 선택 가이드

먼저 Xray, V2Fly, V2Ray의 버전 관계부터 정리하기

V2Ray는 처음에 Project V 생태계의 핵심 프로그램으로, JSON 설정을 읽고 인바운드·아웃바운드 연결을 구성하며 DNS, 라우팅과 전송 계층 설정을 처리했습니다. 이후 프로젝트는 V2Fly 커뮤니티가 계속 유지보수했기 때문에, 일상적인 논의에서 말하는 “V2Fly 코어”는 대개 V2Fly가 관리하는 V2Ray Core를 뜻합니다. V2Ray와 완전히 무관한 새로운 프로토콜을 의미하는 것은 아닙니다. VMess, SOCKS, HTTP, Shadowsocks, 라우팅 규칙과 다양한 전송 방식이 여전히 주요 기능을 이룹니다.

Xray-core는 2020년 말 같은 코드 계보에서 발전했으며, 초기에는 V2Ray 설정 구조를 상당 부분 계승한 뒤 독립적인 버전 체계를 갖추었습니다. Xray는 v2rayN의 대체 제품이 아닙니다. Xray는 네트워크 연결을 처리하는 코어이고, v2rayN은 구독·노드·시스템 프록시·코어 프로세스를 관리하는 그래픽 클라이언트입니다. 데스크톱 사용자가 연결을 클릭하면 클라이언트가 노드 정보를 설정으로 변환한 다음 선택한 코어를 실행합니다.

두 프로젝트가 분리되어 유지보수되면서 버전 번호를 단순 비교할 수 없게 되었습니다. Xray의 1.x와 V2Fly의 v5는 각각의 릴리스 순서를 나타낼 뿐, 어느 쪽이 더 최신이거나 성숙한지를 판단하는 기준이 아닙니다. 연결 가능 여부는 버전 숫자보다 대상 프로토콜, 전송 방식, 보안 계층과 서버 매개변수를 확인해 판단해야 합니다.

1. Project V 단계: V2Ray Core는 인바운드, 아웃바운드, 라우팅, DNS와 전송 계층을 분리하는 설정 구조를 확립했습니다.
2. 커뮤니티 유지보수 단계: V2Fly는 V2Ray Core를 이어받아 v5 계열에서 새로운 설정 인터페이스와 내부 모듈을 발전시켰습니다.
3. 독립 발전 단계: Xray-core는 기존 설정 방식을 상당 부분 유지하면서 VLESS, Reality 등의 기능을 중점적으로 발전시켰습니다.
4. 클라이언트 통합 단계: v2rayN은 데스크톱 코어를 관리하고, v2rayNG와 v2flyNG는 서로 다른 Android 코어 계열을 사용합니다.

프로토콜과 기능 차이가 실제 호환성을 결정합니다

일반 사용자에게 코어 차이는 우선 노드를 얼마나 완전하게 인식하는지에서 드러납니다. VMess와 TCP 또는 WebSocket 조합은 두 버전 계열에서 오랫동안 지원된 기본 구성이라 일반적인 구독은 양쪽에서 대체로 변환할 수 있습니다. 반면 VLESS, Reality, XTLS Vision 등의 조합은 Xray 기능 계열에 더 가깝습니다. 구독에 이런 필드가 포함되어 있다면 클라이언트 변환 과정에서 매개변수가 누락될 위험을 줄이기 위해 Xray를 우선 사용하는 편이 좋습니다.

“모두 가져오기 가능”하다고 해서 “모두 연결 가능”한 것은 아닙니다. 구독 링크는 클라이언트에 노드 데이터를 제공할 뿐이며, 클라이언트는 이를 코어가 인식하는 설정으로 다시 매핑해야 합니다. 어떤 클라이언트에서는 노드 이름이 표시되더라도 현재 코어가 보안 유형이나 전송 필드를 인식하지 못해 실행에 실패할 수 있습니다. 문제를 점검할 때는 구독 원본 매개변수, 클라이언트가 생성한 설정과 실행 로그를 함께 확인해야 합니다.

설정이 비슷해도 전체 파일을 그대로 복사할 수 있는 것은 아닙니다

Xray와 V2Fly는 모두 인바운드, 아웃바운드와 라우팅이라는 기본 개념을 사용하며, 일반적인 JSON 설정에서도 inbounds, outbounds, routing, dns를 확인할 수 있습니다. 이러한 유사성은 설정을 이해하는 데 도움이 되지만, 전체 파일이 코어 간에 호환된다는 보장은 아닙니다. 버전에 따라 필드 위치, 기본값, 전송 이름과 실험 기능의 요구사항이 다를 수 있습니다.

다음은 구조를 설명하기 위한 간소화된 VMess 아웃바운드 예시입니다. 주소, 포트, 사용자 식별자와 전송 매개변수는 서버와 일치해야 합니다. 실제로 v2rayN이 관리하는 환경에서는 전체 설정을 직접 작성할 필요가 없는 경우가 많으며, 클라이언트가 노드 정보를 바탕으로 실행 파일을 생성합니다.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "node.example.net",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/gateway"
        }
      }
    }
  ]
}

설정을 마이그레이션할 때는 먼저 최소 연결 구조를 유지하세요. 로컬 인바운드 하나, 프록시 아웃바운드 하나와 직접 연결 아웃바운드 하나로 시작하면 됩니다. 연결이 확인된 뒤 DNS, 광고 도메인 규칙, LAN 직접 연결과 애플리케이션별 분기를 단계적으로 추가하세요. 많은 규칙을 한 번에 복사하면 프로토콜, DNS와 라우팅 오류가 하나의 로그에 뒤섞입니다.

• 프로토콜 계층: VMess 또는 VLESS, 사용자 식별자, 암호화 옵션과 flow 필드를 확인합니다.
• 전송 계층: TCP, WebSocket 또는 gRPC와 함께 경로, 서비스 이름과 요청 호스트를 확인합니다.
• 보안 계층: TLS 또는 Reality, 서버 이름, 공개 키, 짧은 식별자와 지문 매개변수를 확인합니다.
• 라우팅 계층: 규칙 순서, 대상 포트, 도메인 일치 방식과 아웃바운드 태그를 확인합니다.
• 로컬 진입점: SOCKS, HTTP 또는 mixed 인바운드 주소를 확인하고 다른 프로세스와 동일한 포트를 사용하지 않도록 합니다.

v2rayN, v2rayNG, v2flyNG 선택 방법

데스크톱에서는 먼저 v2rayN을 확인하세요. v2rayN은 구독 업데이트, 노드 목록, 속도 측정, 시스템 프록시, 라우팅 그룹과 코어 수명주기를 관리하며 Windows에서 사용할 수 있고 macOS와 Linux용 데스크톱 빌드도 제공합니다. Xray 등의 코어와 함께 실행할 수 있지만 클라이언트 버전, 운영체제 아키텍처와 코어 파일이 서로 맞아야 합니다. 새로 설치한 환경에서는 Xray를 주력으로 사용하면 최신 VLESS 설정을 더 폭넓게 지원할 수 있습니다.

Android에서는 v2rayNG와 v2flyNG 중에서 선택해야 합니다. v2rayNG는 Xray 계열을 사용하므로 VLESS, Reality와 Xray 기능을 빠르게 지원해야 하는 구독에 적합합니다. v2flyNG는 V2Fly 계열에 해당하며 V2Fly Core를 명확히 사용하는 환경에 더 적합합니다. 두 앱 모두 그래픽 클라이언트지만 같은 구독을 가져와도 표시되는 사용 가능 노드 수가 다를 수 있습니다. 대개 프로토콜 필드 지원 범위가 다르기 때문입니다.

데스크톱 선택 순서

1. 구독 노드 상세 정보를 열고 프로토콜이 VMess인지 VLESS인지 확인합니다.
2. 전송 방식과 보안 유형을 확인하고 Reality 또는 Vision이 있으면 Xray를 선택합니다.
3. 「설정」→「매개변수 설정」으로 이동해 로컬 수신 주소와 포트가 충돌하지 않는지 확인합니다.
4. 구독을 업데이트한 뒤 노드 하나를 선택해 기본 네트워크 응답이 아닌 실제 연결 지연 테스트를 실행합니다.
5. 시스템 프록시를 활성화한 뒤 브라우저와 시스템 프록시를 읽지 않는 터미널 프로그램을 각각 테스트합니다.

Android 선택 순서

• 구독이 VLESS와 Reality 중심이라면 먼저 v2rayNG로 가져온 후 노드 상세 정보를 확인합니다.
• 서버에서 V2Fly를 명확히 사용하고 노드가 VMess 중심이라면 v2flyNG로 같은 구현 계열을 유지할 수 있습니다.
• QR 코드나 링크로 가져온 뒤 주소, 포트, 사용자 식별자, 전송 방식과 서버 이름을 확인해야 합니다.
• 애플리케이션별 프록시가 필요하다면 먼저 전체 범위에서 노드 연결을 확인한 다음 지정 앱으로 범위를 줄이세요. 노드 문제와 앱 선택 문제를 동시에 점검하는 상황을 피할 수 있습니다.

코어 전환은 5단계로 검증하기

코어를 전환할 때 클라이언트 상태 표시줄에 “시작됨”이라고 표시되는지만 확인해서는 안 됩니다. 코어 프로세스가 성공적으로 시작되었다는 것은 설정의 기본 구문 분석을 통과했다는 뜻일 뿐, 원격 핸드셰이크, DNS, 라우팅과 시스템 프록시가 모두 작동한다는 의미는 아닙니다. 같은 노드를 유지하면서 시작, 연결, 프록시 진입점, 도메인 해석과 실제 서비스 접속을 순서대로 검증하는 방법이 더 확실합니다.

1. 현재 노드 매개변수를 저장합니다. 프로토콜, 서버 주소, 포트, 사용자 식별자, 전송 방식, TLS 서버 이름과 Reality 매개변수를 기록하세요. 코어를 전환하면서 노드 내용까지 수정하지 마세요.
2. 기존 코어 프로세스를 종료합니다. 기존 프로세스가 로컬 포트를 해제했는지 확인하세요. 과거 설정에서 흔히 사용된 SOCKS 포트는 10808, HTTP 포트는 10809였지만 실제 값은 「설정」→「매개변수 설정」의 현재 구성을 기준으로 합니다.
3. 새 코어를 시작하고 첫 로그 구간을 확인합니다. 원격 연결을 테스트하기 전에 unknown field, failed to load config, address already in use 등의 시작 오류를 먼저 처리하세요.
4. 실제 연결 테스트를 실행합니다. 클라이언트가 프록시 진입점을 통해 대상에 한 번 연결하도록 하고 지연 시간과 실패 원인을 기록하세요. 기본 네트워크 응답은 주소에 도달할 가능성만 보여줄 뿐 프로토콜 핸드셰이크를 대신할 수 없습니다.
5. 트래픽 경로를 검증합니다. 먼저 일반 웹페이지에 접속하고, 이어서 프록시가 필요한 대상을 테스트한 다음, 직접 연결 규칙이 여전히 예상한 아웃바운드에 적용되는지 확인합니다.

다음 데이터는 판단 방법을 설명하기 위한 동일 환경 비교 기록입니다. 같은 VMess + WebSocket + TLS 노드를 고정된 네트워크에서 실제 연결 테스트 10회 연속 수행한 결과, Xray의 중앙값은 84ms, V2Fly의 중앙값은 87ms로 차이는 3ms에 불과했습니다. 이 정도 차이만으로 어느 한 코어가 일반적으로 더 빠르다고 볼 수 없습니다. 연속 시간 초과, 핸드셰이크 실패 또는 규칙 미적중 여부를 확인하는 편이 더 중요합니다.

두 코어가 같은 VMess 노드에 모두 연결되더라도 지연 차이는 회선 혼잡, DNS 캐시, 서버 부하와 테스트 시점의 영향을 받습니다. 최소 10회 연속 테스트하고 중앙값을 비교해야 단일 결과보다 참고 가치가 높습니다. Xray는 Reality 노드를 시작할 수 있지만 V2Fly는 시작하지 못한다면 이는 기능 호환성 차이이며 속도 테스트와 혼동해서는 안 됩니다.

자주 묻는 질문과 선택 결론

대부분의 사용자는 완전히 독립된 설정 두 세트를 장기간 관리할 필요가 없습니다. 새 프로토콜은 Xray로 지원하고 기존 VMess 환경은 V2Fly로 검증하는 방식이 역할을 명확히 나눕니다. 서버에서 코어 요구사항을 명시했다면 이를 우선 따르세요. 별도 안내가 없고 노드 매개변수가 양쪽의 일반적인 지원 범위에 해당할 때만 두 코어를 비교할 필요가 있습니다.

• 구독에 VLESS, Reality 또는 XTLS Vision이 포함된 경우: Xray, v2rayN 또는 v2rayNG 조합을 우선 선택하세요.
• 환경에서 V2Fly Core를 명확히 사용하고 노드가 VMess 중심인 경우: V2Fly 또는 v2flyNG를 선택해 클라이언트와 서버의 계열을 맞추세요.
• VMess + WebSocket + TLS가 양쪽에서 실행되는 경우: 네트워크 조건을 고정하고 로그와 여러 차례의 실제 연결 테스트로 안정성을 판단하세요.
• 설정 마이그레이션 후 시작되지 않는 경우: 확장 규칙을 먼저 제거하고 인바운드 하나와 프록시 아웃바운드 하나로 구성된 최소 구조로 되돌리세요.
• 클라이언트에는 연결됨으로 표시되지만 접속할 수 없는 경우: DNS, 라우팅, 시스템 프록시와 애플리케이션 자체의 프록시 설정을 계속 확인하세요.