Xray 코어와 V2Fly 코어 차이: 분기 배경, 프로토콜 지원, 클라이언트 선택

분기 배경: V2Fly와 Xray는 클라이언트의 서로 다른 스킨이 아닙니다

Project V는 관련 도구와 프로토콜이 발전해 온 프로젝트 배경이며, V2Ray는 그 안에서 널리 쓰이는 프록시 코어입니다. V2Fly 커뮤니티가 V2Ray 코어와 관련 프로젝트를 이어서 관리하면서 ‘V2Ray 코어’와 ‘V2Fly 코어’라는 표현을 모두 사용하게 됐습니다. 호환성을 구체적으로 논할 때는 프로젝트, 버전, 설정 형식을 명시하는 것이 좋습니다. 단순히 ‘V2Ray를 사용한다’고만 해서는 충분하지 않습니다.

Xray는 2020년 V2Ray 코드 기반에서 분기한 뒤 독자적인 방향으로 발전했습니다. 분기 배경에는 당시 XTLS 관련 기술과 프로젝트 유지 관리 방향을 둘러싼 이견이 있었습니다. 공통된 출발점 덕분에 일부 프로토콜과 라우팅 필드는 비슷하지만, 이후 기능과 설정 의미에는 차이가 생겼습니다. 한 프로젝트의 JSON 전체를 다른 프로젝트에서도 그대로 쓸 수 있는 범용 설정으로 간주해서는 안 됩니다.

• 코어: 프로토콜 핸드셰이크, 인바운드·아웃바운드 연결, 라우팅, DNS 등 하위 처리를 담당합니다.
• 클라이언트: 노드 목록, 구독 가져오기, 시스템 프록시 전환, 로그 화면을 제공하고 코어에 설정을 전달해 실행합니다.
• 구독: 노드 매개변수를 배포합니다. 가져오기에 성공해도 클라이언트가 내용을 읽었다는 뜻일 뿐, 코어의 모든 기능이 지원된다는 의미는 아닙니다.

따라서 ‘v2rayNG에서 가져올 수 있음’과 ‘V2Fly에서 실행 가능함’은 서로 다른 문제입니다. 클라이언트가 공유 링크를 인식하더라도 실행 설정 생성, 코어 구동, 원격 핸드셰이크 단계에서 오류가 날 수 있습니다.

프로토콜 비교: VLESS, XTLS Vision, REALITY의 역할

프로토콜 이름이 같아도 보안 계층, 전송 방식, 흐름 제어 매개변수까지 같은 것은 아닙니다.VLESS는 주로 프록시 프로토콜을 정의하며 자체적으로 트래픽을 암호화하지 않습니다. 일반적인 구성에서는 TLS나 REALITY 같은 방식이 추가로 필요합니다. XTLS Vision은 흐름 제어 방식이고 REALITY는 별도의 연결 보안 메커니즘입니다. 이 셋을 임의로 바꿔 끼울 수 있는 하나의 옵션처럼 취급해서는 안 됩니다.

표의 ‘지원’은 모든 과거 버전에서 작동한다는 보장이 아닙니다. 오래된 코어나 클라이언트의 공유 링크 파서는 나중에 추가된 매개변수를 인식하지 못할 수 있습니다. 문제를 해결할 때는 클라이언트 버전과 실제 실행 중인 코어 버전을 함께 기록하세요. 화면 프로그램만 업데이트해도 사용 중인 코어 파일이 바뀌지 않을 수 있습니다.

클라이언트 선택: v2rayNG와 v2flyNG 중 무엇을 쓸까?

안드로이드용 v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 앱 아이콘이나 익숙한 이름이 아니라 노드 구성에 따라 선택해야 합니다. 아래 추천은 구독에 REALITY나 Vision이 포함될 수 있다는 전제에 따른 것이며, 특정 코어가 모든 네트워크에서 더 빠르다는 뜻은 아닙니다.

비교를 위해 안드로이드 클라이언트 두 개를 설치하더라도 VPN 연결을 동시에 켜지 마세요. 일반적으로 같은 사용자 환경에서는 앱 하나만 VPN 채널을 사용할 수 있습니다. 나중에 시작한 연결이 앞선 연결을 대체해 ‘코어를 바꾼 뒤 갑자기 끊겼다’고 오해할 수 있습니다.

여러 기기에서 사용하기: 구독은 공유해도 실행 설정은 각각 확인

서비스 제공자가 사용 기기 수를 허용하고 구독 출력 형식을 양쪽에서 인식할 수 있다면 데스크톱과 안드로이드에서 같은 구독을 가져올 수 있습니다. 노드 목록이 같더라도 라우팅 그룹, 앱별 프록시, 로컬 수신 포트, DNS 동작까지 구독을 따라 자동으로 옮겨지는 것은 아닙니다.

데스크톱에서는 연결되지만 안드로이드에서는 연결되지 않는다면 먼저 같은 노드의 주소, 포트, 전송 방식, 보안 계층, 흐름 제어 매개변수를 비교하세요. 모든 차이를 코어 탓으로 돌리지 마세요. 두 기기에서 이름만 같은 서로 다른 매개변수의 노드를 선택했거나 한쪽에서만 구독을 업데이트했을 수도 있습니다.

포트와 필드: ‘연결 안 됨’을 확인 가능한 설정으로 나누기

아래 두 포트는 문제 해결을 위한 예시일 뿐, 모든 클라이언트의 고정 기본값이 아닙니다. 원격 포트는 서비스 제공자가 지정하고 로컬 수신 포트는 클라이언트 설정에서 정합니다. 두 포트의 용도는 다르므로 로컬 SOCKS 포트를 원격 노드 포트란에 입력하면 안 됩니다.

예를 들어 브라우저나 테스트 도구에서 로컬 프록시에 연결할 때는 사용 설정이 확인된 127.0.0.1:10808을 사용할 수 있습니다. 이후 코어가 노드의 원격 포트에 연결합니다. 이 과정은 ‘앱에서 로컬 진입점까지’와 ‘코어에서 원격 서버까지’ 두 구간으로 나뉩니다. 로컬 연결에 성공했다고 원격 핸드셰이크까지 완료된 것은 아닙니다.

1. 기본 연결: 원격 주소, 포트, 사용자 ID, 시스템 시간을 확인하세요. VMess는 시간 차이에 민감하며 TLS 인증서 유효기간 확인에도 정확한 시간이 필요합니다.
2. 전송 계층: WebSocket 노드는 경로와 Host를 확인하세요. WebSocket 설정을 일반 TCP 설정과 혼용하지 마세요.
3. 보안 계층: 일반 TLS는 서버 이름과 인증서 검증을 확인하세요. REALITY는 서비스 제공자가 지정한 서버 이름, 공개 키 관련 매개변수, shortId를 확인해야 합니다.
4. 흐름 제어: 서비스 제공자가 xtls-rprx-vision을 지정했다면 값을 일치시키세요. flow를 바꾼다고 서버 프로토콜이 자동으로 전환되지는 않습니다.
5. 실행 결과: ‘알 수 없는 필드’, ‘핸드셰이크 실패’, ‘연결 시간 초과’를 구분해 각각 호환성, 인증 매개변수, 네트워크 연결 가능성을 다시 확인하세요.

코어 전환 전후: 한 번에 변수 하나만 변경하세요

‘코어를 바꾼 뒤 더 빨라졌다’고 비교하려면 같은 노드, 비슷한 시간대, 같은 테스트 대상이 필요합니다. TCPing은 주로 TCP 연결 가능성을 확인할 뿐 프록시 핸드셰이크 성공을 뜻하지 않습니다. 실제 연결 테스트는 프록시 요청에 더 가깝지만 지속적인 다운로드 속도나 모든 웹사이트의 사용 경험을 보장하지는 않습니다.

1. 전환 전 백업: 구독 출처, 현재 노드 매개변수, 라우팅, DNS 설정을 보관하세요. 화면을 공유할 때는 사용자 ID와 구독 주소를 가리세요.
2. 실행 여부 확인: 먼저 코어를 실행하고 로그에 설정 파싱 오류가 있는지 확인하세요. 시작에 실패했다고 설정 문제를 덮기 위해 노드를 계속 바꾸지 마세요.
3. 프록시 요청 테스트: 같은 노드로 실제 연결 테스트를 실행한 뒤 같은 브라우저에서 같은 대상에 접속하세요. 시스템 프록시나 VPN 채널이 실제로 적용됐는지 확인해야 합니다.
4. 라우팅 별도 확인: 연결에 성공한 뒤 직결 및 프록시 규칙을 살펴보세요. 특정 웹사이트가 직결로 라우팅됐다고 새 코어가 트래픽을 처리하지 않는다는 뜻은 아닙니다.
5. 기록 후 되돌리기: 클라이언트와 코어 버전, 오류 유형, 변경 항목을 기록하세요. 결과가 나빠지면 기존 설정으로 되돌리고 DNS, 라우팅, 전송 매개변수를 한꺼번에 바꾸지 마세요.

자주 묻는 질문: 가져오기 성공, 구형 노드, 전환 실패