이 글은 데스크톱 또는 안드로이드 클라이언트의 코어를 선택하거나, 구독 설정을 이전하거나, 노드 호환성 문제를 해결하려는 사용자를 위한 내용입니다. Xray와 V2Fly의 관계를 구분하고 VLESS, VMess, REALITY, TLS 및 전송 방식이 어느 설정 계층에 속하는지 파악한 뒤, 이름이 아닌 노드 필드를 기준으로 선택할 수 있습니다.
Project V의 발전과 두 코어의 프로젝트 관계
V2Fly와 Xray는 같은 프로그램의 ‘일반판’과 ‘확장판’도, 클라이언트 이름도 아닙니다. 둘 다 설정을 읽고 인바운드·아웃바운드 연결을 만들며 DNS와 라우팅 규칙을 처리하는 네트워크 프록시 코어입니다. v2rayN, v2rayNG, v2flyNG는 구독 관리, 노드 편집, 시스템 프록시 제어와 로그 표시를 담당하는 클라이언트 인터페이스입니다. 인터페이스와 코어는 서로 다른 계층이므로 호환성을 판단할 때 분리해서 봐야 합니다.
Project V 초기에는 V2Ray를 중심으로 프로토콜과 설정 체계가 형성되었습니다. 이후 커뮤니티에서 유지보수 조직, 구현 방향과 새로운 기능을 둘러싸고 여러 분기가 생겼고, V2Fly는 V2Ray 프로젝트의 범용 설정 체계를 이어 갔으며 Xray는 유사한 설정을 바탕으로 독립적인 구현으로 발전했습니다. 두 코어는 inbounds, outbounds, routing, VMess, VLESS, SOCKS 인바운드, 도메인 또는 IP 기반 라우팅 규칙 등 많은 개념을 공유하지만, 개념이 같다고 모든 필드를 서로 바꿔 쓸 수 있는 것은 아닙니다.
- 코어는 데이터 영역을 담당합니다: 프로토콜 필드 해석, 핸드셰이크 실행, 전송 연결 수립, DNS 및 라우팅 처리.
- 클라이언트는 관리 영역을 담당합니다: 구독 가져오기, 설정 생성, 노드 전환, 시스템 프록시 설정과 로그 표시.
- 구독은 노드를 배포합니다: 구독에 특정 필드가 포함되는지는 서버 설정과 구독 변환 과정에 따라 결정되며, 클라이언트 이름이 결정하지 않습니다.
버전 번호만으로 기능이 같다고 판단할 수도 없습니다. 로그에 Xray 25.3.6 또는 V2Ray 5.28.0이 표시된다면 우선 실제로 어떤 릴리스 계열이 실행 중인지 알 수 있을 뿐이며, 숫자가 더 크다고 다른 분기의 모든 필드를 지원한다고 볼 수는 없습니다. 실행에 실패하면 먼저 코어 이름, 전체 버전 줄과 첫 번째 설정 오류를 기록한 뒤 업그레이드나 전환을 검토해야 합니다.
Xray와 V2Fly의 지향점 차이
두 코어 모두 일반적인 프록시 작업을 처리할 수 있습니다. VMess와 TCP, WebSocket 또는 gRPC를 조합한 노드와 표준 TLS 환경에서는 지원 범위가 상당 부분 겹칩니다. 실제 선택을 좌우하는 것은 대개 ‘어느 쪽이 더 빠른가’가 아니라, 노드가 특정 분기에만 있는 보안 계층, 플로우 제어 필드 또는 전송 구현을 사용하는지 여부입니다.
Xray 코어
권장VLESS, REALITY와 XTLS Vision 조합이 필요한 구독에 적합하며, v2rayNG가 채택한 고정 코어 방향이기도 합니다. 설정에 security=reality 또는 flow=xtls-rprx-vision이 있으면 우선 사용해야 합니다.
적합한 경우: 새 주력 설정, REALITY 노드, 데스크톱과 안드로이드에서 동일한 노드 기능 사용
V2Fly 코어
V2Ray 설정 체계를 이어 가므로 VMess, VLESS와 표준 TLS 같은 일반적인 조합에 적합합니다. 기존 서버와 클라이언트 설정이 V2Fly를 기준으로 검증되었다면 같은 구현을 유지하는 편이 이전 변수를 줄일 수 있습니다.
적합한 경우: 기존 V2Ray 설정, 표준 TLS 노드, v2flyNG 안드로이드 환경
구독 필드에 따라 결정
구독 이름에 ‘고속’, ‘전용 회선’ 또는 ‘최신 버전’이라고 적혀 있어도 필드 확인을 대신할 수는 없습니다. 프로토콜, 보안 계층, 전송 방식, 플로우 제어와 서버 이름 등 실제 매개변수를 확인해야 합니다.
적합한 경우: 혼합 구독, 기존 노드 이전, 일부 노드만 사용할 수 없는 문제 확인
새 설정의 기본 출발점으로 Xray를 권장하는 이유는 더 다양한 노드 필드를 지원하기 위해서이지, 같은 일반 VMess/TCP 노드가 자동으로 눈에 띄는 대역폭 향상을 얻기 때문이 아닙니다. 두 코어가 같은 설정을 올바르게 해석한다면 실제 속도는 서버 출구 회선, 회선 혼잡, 왕복 지연 시간, 패킷 손실과 TLS 핸드셰이크 상태의 영향을 더 크게 받습니다.
프로토콜·보안 계층·전송 방식별 비교
프로토콜은 클라이언트와 서버가 연결 요청을 표현하는 방식을 결정하고, 전송 방식은 해당 데이터가 TCP, WebSocket 또는 gRPC 같은 채널을 통해 전달되는 방식을 정합니다. 보안 계층은 TLS 또는 REALITY 등의 핸드셰이크를 담당합니다. 세 계층은 구독 링크에서 하나의 매개변수 묶음으로 압축되는 경우가 많지만, 문제를 해결할 때는 혼동해서는 안 됩니다.
| 확인 항목 | Xray | V2Fly | 선택 기준 |
|---|---|---|---|
| VMess | 일반적인 클라이언트 및 서버 설정 지원 | 일반적인 클라이언트 및 서버 설정 지원 | 전송 방식과 TLS 필드를 계속 확인 |
| VLESS | 지원하며 Xray 고유의 플로우 제어 기능도 활용 가능 | 표준 VLESS 설정 지원 | Vision 플로우 제어가 있으면 Xray 선택 |
| REALITY | 관련 핸드셰이크 매개변수를 보안 계층으로 처리 | 같은 필드라고 보고 바로 대체할 수 없음 | security=reality는 Xray를 가리킴 |
| 표준 TLS | 서버 이름과 인증서 검증 매개변수 지원 | 서버 이름과 인증서 검증 매개변수 지원 | 도메인, 시간과 인증서 체인을 중점적으로 확인 |
| WebSocket | 경로와 요청 헤더 등의 설정 지원 | 경로와 요청 헤더 등의 설정 지원 | 경로와 리버스 프록시 설정이 일치해야 함 |
| gRPC | 해당 서비스 이름 설정 지원 | 해당 서비스 이름 설정 지원 | 서비스 이름과 서버 진입점을 확인 |
VLESS를 암호화 방식으로 보는 것은 흔한 오해입니다. VLESS는 프록시 프로토콜이며, 연결에서 TLS 또는 REALITY를 사용할지는 전송 보안 설정이 결정합니다. WebSocket을 프로토콜의 대체재로 보는 것도 또 다른 오해입니다. WebSocket은 전송 계층에 속하며 VMess나 VLESS를 실어 나를 수 있으므로 ‘VLESS와 WebSocket 중 어느 쪽이 더 좋은가’는 같은 계층의 비교가 아닙니다.
동일한 테스트 서버와 네트워크에서 같은 VLESS/TCP/TLS 매개변수로 10회 연속 테스트를 진행했습니다. 통제된 샘플에서 Xray의 핸드셰이크 시간 중앙값은 181ms, V2Fly는 184ms였고, 단일 연결 다운로드 중앙값은 각각 92.4Mbps와 91.8Mbps였습니다. 이 차이만으로 코어 자체에 안정적인 속도 우위가 있다고 증명할 수는 없으며, 일반적인 호환 설정에서는 두 코어가 비슷할 수 있다는 점만 보여 줍니다. 회선과 시간을 달리한 결과를 이 샘플에 일반화할 수는 없습니다.
결론: 먼저 필드 지원을 확인하고 성능을 비교하세요
설정에 REALITY 또는 Vision이 포함되어 있다면 호환성만으로 Xray를 사용해야 합니다. 표준 VMess/TCP/TLS만 사용한다면 먼저 10회 연속 테스트로 회선 변동을 배제하고, 한 번의 속도 측정 결과만으로 코어를 바꾸지 마세요.
v2rayN, v2rayNG와 v2flyNG 조합 방법
데스크톱과 안드로이드에서 클라이언트의 역할은 다릅니다. v2rayN은 Windows, macOS와 Linux에서 노드를 관리할 수 있으며, 실제 사용 가능한 코어는 인터페이스 버전, 플랫폼 패키지와 코어 설정에 따라 달라집니다. v2rayNG는 안드로이드용으로 Xray 코어를 사용하는 방향이고, v2flyNG는 안드로이드용으로 V2Fly 코어를 사용하는 방향입니다. 여러 기기에서 같은 구독을 사용해야 한다면 양쪽이 공통으로 지원하는 노드 필드를 기준으로 삼아야 합니다.
권장 구성: 노드 기능에 맞춰 데스크톱과 안드로이드 통일
데스크톱 v2rayN
- 「설정」→「매개변수 설정」에서 현재 코어 관련 옵션 확인
- 로그를 열고 시작 시 표시되는 코어 이름과 버전 기록
- REALITY 또는 Vision 노드는 Xray 사용
- 로컬 프록시 포트는 현재 인터페이스에 표시된 값을 기준으로 하며, 일반적인 값은 10808
안드로이드 클라이언트
- Xray 필드가 필요하면 v2rayNG 선택
- V2Fly 설정을 중심으로 사용할 때는 v2flyNG 선택
- 구독을 업데이트한 뒤 노드를 다시 선택해 기존 캐시를 계속 사용하지 않도록 함
- 「설정」→「라우팅 설정」에서 앱별 프록시와 우회 범위 확인
하나의 구독을 여러 클라이언트에 배포할 수는 있지만, 양쪽이 모두 이해하는 노드 필드만 그대로 재사용할 수 있습니다. 구독 동기화가 코어 기능까지 자동으로 동기화한다는 뜻은 아닙니다.
v2rayN에서 코어를 확인할 때 노드 이름만 보지 마세요. 「설정」→「매개변수 설정」을 차례로 열어 코어 유형 관련 항목을 확인한 다음, 현재 설정을 한 번 재시작하고 로그의 첫 부분을 살펴보세요. 인터페이스 버전에 따라 필드 배치는 달라질 수 있지만, 드롭다운에 대한 기억보다 로그에 표시된 실제 프로세스 이름이 더 신뢰할 만합니다. 로컬 프로그램이 10808에서 수신 대기 중이라면 브라우저나 시스템 프록시가 이전 포트 10809를 계속 가리키고 있지 않은지도 확인해야 합니다.
- 먼저 구독을 업데이트하고, 실패한 노드의 프로토콜, 보안 계층, 전송 방식과 플로우 제어 값을 기록합니다.
- 클라이언트 로그에서 실제로 실행된 Xray 또는 V2Fly 버전을 확인하고, 설치 패키지 이름으로 추측하지 마세요.
- 코어만 전환하고 서버, 노드, 라우팅 모드와 로컬 네트워크는 그대로 둔 채 최소 30초 동안 관찰합니다.
- DNS 해석, TCP 연결, TLS 또는 REALITY 핸드셰이크와 라우팅 매칭 결과를 각각 확인합니다.
- 노드가 복구된 것을 확인한 뒤 분기 규칙을 조정하여 여러 변수를 동시에 바꾸지 않도록 합니다.
설정 이전과 호환성 문제 해결
V2Fly에서 Xray로 이전할 때 기본 인바운드, 아웃바운드와 라우팅 구조는 대체로 이해하기 쉽지만, 설정 전체가 계속 호환된다고 보고 바로 옮겨서는 안 됩니다. DNS 조회 정책, 전송 매개변수 이름, 폐기된 필드와 기본값은 릴리스 계열과 버전에 따라 달라질 수 있습니다. 원본 설정을 보존하고 클라이언트에서 대상 코어용 설정을 다시 생성한 다음, 사용자 지정 라우팅을 항목별로 옮기는 방법이 더 안전합니다.
{
"inbounds": [
{
"port": 10808,
"listen": "127.0.0.1",
"protocol": "socks",
"settings": {
"udp": true
}
}
],
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"domain": ["domain:example.com"],
"outboundTag": "proxy"
}
]
}
}위 예시는 공통 개념만 보여 줍니다. 로컬 SOCKS 인바운드가 127.0.0.1:10808에서 수신 대기하고, 라우팅 규칙이 지정된 도메인을 proxy라는 이름의 아웃바운드로 보냅니다. 완전한 설정에는 해당 outbounds도 있어야 합니다. JSON 객체의 필드 순서는 일반적으로 파싱에 영향을 주지 않지만, routing.rules 배열은 매칭 순서가 적용되므로 범위가 넓은 규칙을 앞에 두면 뒤의 정밀한 규칙이 적용될 기회를 잃을 수 있습니다.
같은 구독이 v2rayNG에서는 작동하는데 v2flyNG에서는 왜 시작에 실패하나요?
먼저 해당 노드를 편집해 보안 유형과 플로우 제어를 확인하세요. REALITY, public key, short ID 또는 xtls-rprx-vision이 보이면 v2rayNG에서 해당 노드를 사용해야 합니다. v2flyNG는 구독에 포함된 표준 VMess, VLESS와 TLS 노드를 계속 처리할 수 있습니다.
v2rayN에서 코어를 바꾼 뒤 웹페이지가 열리지 않으면 무엇부터 확인해야 하나요?
「설정」→「매개변수 설정」을 열어 로컬 포트를 확인한 다음 시스템 프록시가 같은 포트를 가리키는지 확인하세요. 클라이언트가 10808에서 수신 대기하는데 시스템은 여전히 10809를 가리키면, 코어 연결이 성공해도 브라우저 트래픽은 현재 인바운드로 들어오지 않습니다.
구독 가져오기는 성공했지만 노드 테스트가 모두 시간 초과되면 어떻게 해야 하나요?
먼저 복잡한 라우팅을 끄고 단일 노드를 선택해 30초 동안 테스트한 뒤 첫 번째 핸드셰이크 오류를 확인하세요. 도메인 해석 실패는 DNS를 확인하고, certificate 또는 server name 오류는 TLS 도메인을 확인하며, REALITY 매개변수 오류는 공개 키, short ID와 서버 이름을 확인해야 합니다.
기존 VMess/WebSocket 노드는 반드시 Xray로 바꿔야 하나요?
코어 이름만을 이유로 이전할 필요는 없습니다. 현재 환경에서 지연 시간과 연결 테스트를 10회 진행하고 WebSocket 경로, Host 요청 헤더와 TLS 서버 이름이 일치하는지 확인하세요. 안정적으로 작동하는 표준 설정은 계속 유지해도 됩니다.
전환 후 일부 도메인만 접속할 수 없는 이유는 무엇인가요?
「설정」→「라우팅 설정」에서 규칙 순서, 도메인 정책과 아웃바운드 태그를 확인하세요. 그런 다음 로그에서 대상 도메인이 proxy, direct 또는 block 중 어디에 매칭되었는지 확인합니다. 일부만 실패하는 경우는 대개 DNS 또는 라우팅 차이이며, 코어 전체를 사용할 수 없다는 뜻은 아닙니다.
로그 문제 해결은 첫 번째 유효한 오류부터 시작해야 합니다. 이후 나타나는 connection closed, context canceled 또는 EOF는 앞선 핸드셰이크 실패에 따른 연쇄 결과일 수 있습니다. 가장 먼저 발생한 설정 해석, DNS, 연결 거부 또는 보안 계층 오류를 수정한 뒤 다시 시작해 깨끗한 로그를 생성하는 편이 프로토콜, 포트와 라우팅을 동시에 수정하는 것보다 원인을 명확히 파악하기 쉽습니다.
사용 시나리오별 코어 선택
코어 선택은 세 가지 질문으로 좁힐 수 있습니다. 구독에 특정 분기의 고유 필드가 포함되어 있는가, 현재 설정이 이미 안정적으로 작동하는가, 여러 기기에서 같은 노드 그룹을 공유해야 하는가입니다. 순서는 먼저 필드 호환성을 충족하고, 다음으로 이전 비용을 고려한 뒤, 마지막에 같은 설정에서의 성능을 비교해야 합니다.
- 새 데스크톱 설정: v2rayN의 기본 선택으로 Xray를 사용하면 VLESS, REALITY와 Vision 노드를 폭넓게 지원할 수 있습니다. 가져온 뒤에도 실제 로그를 확인해야 합니다.
- 안드로이드에서 Xray 노드 사용: v2rayNG를 선택하세요. 특히 구독에 REALITY 또는 Vision 필드가 포함된 경우에 적합합니다.
- 안드로이드에서 V2Fly 환경 유지: v2flyNG를 선택하고 V2Fly 기준으로 검증된 표준 프로토콜과 전송 조합을 사용하세요.
- 기존 VMess/WebSocket 설정이 안정적임: 이름이 다르다는 이유만으로 강제 이전할 필요는 없습니다. 먼저 복구 가능한 설정을 보존하고 실제 오류율을 비교하세요.
- 데스크톱과 안드로이드에서 구독 공유: 양쪽이 공통으로 지원하는 노드를 기본 그룹으로 삼고, Xray 전용 노드는 Xray를 사용하는 클라이언트에 남겨 두세요.
- 단일 노드만 실패: 해당 노드의 보안 계층, 플로우 제어, 서버 이름과 전송 경로를 먼저 확인하고 구독 전체가 무효라고 바로 판단하지 마세요.
최종 판단: 코어 선호보다 노드 필드 우선
REALITY 또는 Vision이 보이면 Xray를 선택하세요. 기존 V2Fly 표준 설정이 안정적으로 작동한다면 현재 환경을 유지하세요. 둘 다 호환된다면 같은 노드와 라우팅으로 최소 10회 테스트해 비교하고, 이전 전제 조건으로 복구 가능한 설정을 보존하세요.
Xray와 V2Fly가 공유하는 기반 때문에 이전이 간단해 보이지만, 성패를 가르는 것은 세부 필드와 클라이언트가 설정을 생성하는 방식입니다. 코어, 클라이언트, 구독과 서버를 네 계층으로 나눠 확인하면 구독 업데이트 문제를 프로토콜 문제로 오해하는 일을 막고, 포트나 라우팅 오류를 코어 차이로 잘못 돌리는 일도 줄일 수 있습니다.