Xray 코어와 V2Fly 코어 차이: 프로토콜 지원 및 설정 비교

클라이언트, 코어, Project V부터 구분하기

코어는 실제 연결을 수립하고 프로토콜을 처리하며 DNS 조회와 라우팅을 담당합니다. 클라이언트는 이러한 기능을 조작할 수 있는 화면으로 제공합니다. v2rayN, v2rayNG, v2flyNG는 클라이언트 이름이고, Xray-core와 V2Fly가 관리하는 v2ray-core는 코어입니다. 클라이언트 버전과 코어 버전은 별개이므로, 화면 프로그램을 업데이트해도 코어가 다른 종류로 바뀌는 것은 아닙니다.

Project V는 V2Ray를 중심으로 형성된 도구 및 프로토콜 생태계입니다. V2Fly 커뮤니티는 v2ray-core 개발을 이어 왔으며, Xray-core는 2020년 관련 코드 기반에서 분기한 뒤 별도의 기능 발전 경로를 밟았습니다. 두 프로젝트는 공통된 역사를 바탕으로 비슷한 JSON 구조를 공유하지만, 모든 설정 필드를 서로 바꿔 쓸 수 있는 것은 아닙니다.

이 흐름을 보면 “구독은 가져왔는데 연결되지 않는” 이유도 알 수 있습니다. 가져오기에 성공했다는 것은 클라이언트가 일부 데이터를 읽었다는 뜻일 뿐, 코어가 모든 기능을 지원하거나 서버 주소, 인증 정보, 전송 설정이 서로 맞는다는 뜻은 아닙니다.

• v2rayN: 데스크톱 클라이언트입니다. 사용할 수 있는 코어와 전환 메뉴는 설치된 버전에 따라 다르므로, 문제를 확인할 때는 현재 노드가 실제로 어떤 코어를 사용하는지 확인하세요.
• v2rayNG: 안드로이드 클라이언트입니다. 이 글에서는 Xray 코어를 사용하는 경우를 다룹니다.
• v2flyNG: V2Fly 코어를 사용하는 안드로이드 클라이언트입니다. 화면이 비슷하다고 해서 Xray 전용 필드로 설정하면 안 됩니다.

프로토콜 지원 비교: VLESS와 REALITY는 다릅니다

하나의 연결에는 보통 프록시 프로토콜, 전송 방식, 보안 계층이 함께 사용됩니다. VLESS와 VMess는 프록시 프로토콜이고 TCP와 WebSocket은 전송 방식입니다. TLS와 REALITY는 연결 보안 방식에 해당합니다. XTLS Vision은 특정 흐름 제어 및 데이터 처리 방식을 가리키며, “TLS” 옵션의 이름만 바꾼 것이 아닙니다.

“V2Fly는 VLESS를 전혀 지원하지 않는다”거나 “VLESS만 지원하면 REALITY에도 연결할 수 있다”는 말은 모두 지나치게 단정적입니다. 전자는 버전 및 구현 차이를 간과하고, 후자는 프로토콜과 보안 계층을 혼동합니다. 오래된 자료의 XTLS 원본 흐름 제어를 Vision과 동일하게 취급해서도 안 되며, 특히 이전 값을 새 설정에 그대로 복사하지 마세요.

설정 비교: 자주 쓰는 두 조합에서 확인할 항목

아래 두 카드는 설정 필드를 확인하기 위한 표이며, 실제로 연결 가능한 노드나 서버 인증 정보를 제공하지 않습니다. 예시 경로 /proxy는 필드 위치를 설명하기 위한 것입니다. 실제 경로는 서버 설정에 맞춰 입력하세요. REALITY 카드는 일반적인 VLESS + TCP + Vision 조합을 예로 들며, 모든 VLESS에 Vision이 필요한 것은 아닙니다.

Host와 SNI는 같은 경우가 많지만 용도가 다릅니다. WebSocket의 Host는 HTTP 요청에 포함되는 대상 호스트 정보이고, SNI는 TLS 핸드셰이크에서 전달하는 서버 이름입니다. 연결 주소는 또 다른 필드로, 네트워크 연결을 시작할 대상을 지정합니다. 서버에서 이 세 값이 서로 다르게 요구된다면, 보기 좋게 정리한다는 이유로 모두 같은 값으로 바꾸면 안 됩니다.

JSON 설정: 비슷한 구조라고 전체 설정을 공유할 수 있는 것은 아닙니다

Xray와 V2Fly의 일반적인 설정에는 inbounds, outbounds, routing 같은 이름이 모두 등장합니다. V2Fly에는 서로 다른 설정 버전과 구조가 있으며, 클라이언트가 공유 링크를 먼저 읽은 뒤 자체 코어용 JSON을 생성하기도 합니다. 따라서 공유 링크가 같다는 것, 화면의 필드가 비슷하다는 것, 최종 코어 설정이 호환된다는 것은 각각 별개의 문제입니다.

아래는 기존 JSON 형식의 streamSettings 필드 일부로, WebSocket과 TLS의 계층 구조만 설명합니다. example.com은 문서용 예시 도메인이며 실제로 사용할 수 있는 서버 주소가 아닙니다. 이 조각에는 전체 인바운드, 아웃바운드, 인증 설정이 없으므로 단독으로 실행할 수 없습니다.

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com"
    },
    "wsSettings": {
      "path": "/proxy",
      "headers": {
        "Host": "example.com"
      }
    }
  }
}

• 전송 필드: network에서 전송 구현을 선택합니다. 문서에 나오는 TCP, RAW 등의 명칭은 버전에 따라 바뀔 수 있으므로, 화면에 표시된 단어만 보고 내부 JSON 값을 추측하면 안 됩니다.
• 보안 필드: 일반 TLS에는 해당 TLS 설정을 사용합니다. Xray REALITY는 전용 설정 구조를 사용하므로, tls 문자열을 reality로 바꾸는 것만으로 설정 이전이 끝나지 않습니다.
• 흐름 제어 필드: 일반적인 Xray VLESS 아웃바운드 설정에서 flow는 사용자 설정 항목입니다. 임의로 streamSettings 안에 넣지 마세요.
• 버전별 필드: REALITY 클라이언트의 공개 키 관련 매개변수는 Xray 버전별 문서와 화면에서 이름이 다를 수 있습니다. 이전 예제의 publicKey와 최신 문서의 password는 실제 코어 버전을 확인해 판단해야 합니다. 버전을 모르는 상태에서 기계적으로 바꾸지 마세요.

가장 안전한 이전 방법은 서비스 제공자가 제공한 전체 구독을 다시 가져온 뒤 생성된 설정을 확인하는 것입니다. JSON 전체를 직접 옮기는 방법은 출처 버전, 대상 버전, 설정 형식을 정확히 알고 있을 때만 사용하세요. 문법 검사에 통과하더라도 필드가 실제로 적용되었는지는 따로 확인해야 합니다.

포트와 라우팅: 로컬 진입점을 원격 기능과 혼동하지 마세요

코어가 라우팅을 처리하더라도 트래픽이 먼저 코어로 들어와야 합니다. 시스템 프록시는 해당 설정을 따르는 앱에만 영향을 줍니다. TUN은 가상 네트워크 인터페이스로 지정된 트래픽을 처리하며, 추가 권한이 필요한 경우가 많습니다. 둘 다 “프록시 아웃바운드를 선택했다”는 뜻은 아니며, 코어에 들어온 요청은 라우팅 규칙에 따라 분배되어야 합니다.

이 숫자는 주소와 포트 예시일 뿐, 성능 측정 결과나 모든 클라이언트의 공통 기본값이 아닙니다. 앱에 127.0.0.1:10808을 입력했다면 클라이언트가 실제로 로컬의 해당 포트에서 연결을 수신하는지, 진입점의 프로토콜이 앱 요구사항과 맞는지 확인하세요. 포트 번호만으로 HTTP 프록시와 SOCKS 진입점을 구분할 수는 없습니다.

1. v2rayN의 「설정」→「매개변수 설정」에서 로컬 수신 주소와 관련 옵션을 확인하세요. 버전에 따라 메뉴 이름이나 구성이 다를 수 있으므로 현재 화면을 기준으로 확인해야 합니다.
2. 시스템 프록시나 앱 프록시가 실제 수신 주소를 가리키는지 확인하세요. 이전 클라이언트의 포트를 계속 가리키지 않도록 주의하세요.
3. 현재 라우팅 모드와 적용된 규칙을 확인하세요. geosite:cn은 도메인 분류 참조이고 geoip:cn은 IP 분류 참조입니다. 둘 다 해당 데이터 파일이 있어야 작동합니다.
4. 다른 코어로 이전한 뒤에는 규칙 파일 위치, 태그 이름, 아웃바운드 태그가 계속 일치하는지 확인하세요. 라우팅 항목만 복사해서는 충분하지 않습니다.

“직접 연결되는 사이트는 정상인데 프록시 사이트는 실패한다”면 요청이 특정 규칙에 들어갔지만 프록시 아웃바운드에 문제가 있을 가능성이 큽니다. “모든 앱에서 전환이 아무런 영향을 주지 않는다”면 진입점과 트래픽 처리 방식을 먼저 확인하세요. 연결 흐름을 따라 원인을 찾고, 곧바로 코어 속도 탓으로 돌리지 마세요.

안드로이드 클라이언트 선택: 구독 요구사항을 소규모로 검증하세요

사용 중인 노드에서 Xray REALITY나 Vision을 명시적으로 요구한다면, 해당 기능을 지원하는 v2rayNG를 선택하는 편이 간편합니다. 현재 서비스가 V2Fly와 함께 검증된 설정을 제공한다면 v2flyNG를 계속 사용해도 됩니다. 전용 기능이 필요하지 않다면 설정을 온전히 가져올 수 있는지, 로그를 확인하기 쉬운지, 기존 라우팅을 유지할 수 있는지를 우선 고려하세요.

1. 환경 기록: 클라이언트 버전, 코어 버전, 프로토콜, 전송 방식, 보안 계층, TUN 사용 여부를 기록하세요. “최신 버전”이라고만 적어 두지 마세요.
2. 기존 설정 보관: 이전 전에 구독 그룹과 사용자 지정 라우팅을 백업하세요. 민감한 구독 주소를 공개된 게시판에 올리지 마세요.
3. 테스트 항목 하나만 가져오기: 원본 설정과 포트, SNI, 경로, Flow, REALITY 관련 필드를 대조하세요. 필수 필드가 빠졌다면 테스트를 중단하고 먼저 확인하세요.
4. 동시에 트래픽을 처리하지 않기: 다른 클라이언트를 테스트하기 전에 기존 클라이언트의 프록시나 가상 네트워크 연결을 중지해 진입점 충돌을 줄이세요.
5. 한 번에 하나만 변경하기: 같은 네트워크, 같은 서버, 같은 대상 요청을 유지한 채 연결 결과를 비교하세요. DNS, 노드, 라우팅 모드를 동시에 바꾸지 마세요.

자주 묻는 질문: 가져오기 성공, 핸드셰이크 실패, 업데이트 순서