Xray 코어와 V2Fly 코어 비교: v2rayNG와 v2flyNG 선택 가이드

Project V, V2Fly, Xray: 프로젝트와 클라이언트 구분하기

V2Ray는 Project V 생태계의 네트워크 프록시 도구입니다. 코어는 인바운드 연결을 받아 라우팅 규칙을 적용하고 DNS를 처리한 뒤 아웃바운드 연결을 설정합니다. V2Fly는 V2Ray 개발을 이어가는 커뮤니티 프로젝트이며, Xray는 2020년에 V2Ray 관련 코드를 바탕으로 분리된 독립 프로젝트입니다. 공통된 기반에서 출발했지만 이후 기능, 설정 필드, 릴리스 주기는 각각 달라졌으므로 이름이 비슷하다고 완전히 호환된다고 볼 수는 없습니다.

안드로이드용 v2rayNG와 v2flyNG는 프로토콜이 아닌 클라이언트입니다. 구독 관리, 노드 편집, 로그 확인, 시스템 VPN 연결 등의 인터페이스를 제공하고, 실제 프록시 연결은 내장된 코어가 처리합니다. 이 글에서는 v2rayNG는 Xray 코어, v2flyNG는 V2Fly 코어를 사용하는 것으로 구분해 설명합니다. 실제 지원 기능은 설치 패키지에 포함된 코어 버전과 인터페이스 지원 여부에 따라 달라질 수 있습니다.

• 프로젝트 계층: Project V, V2Fly, Xray는 프로젝트 또는 기술 생태계를 가리키며, 구독 주소가 아닙니다.
• 코어 계층: 실제 프로토콜, 보안 방식, 전송 방식, 라우팅 필드를 지원하고 처리할 수 있는지 결정합니다.
• 클라이언트 계층: 공유 링크를 파싱하는 방법, 노드 편집 방식, 트래픽을 처리하는 방식을 결정합니다.
• 서버 계층: 실제로 사용할 수 있는 프로토콜 조합을 결정합니다. 클라이언트를 바꿔도 서버 설정은 자동으로 변경되지 않습니다.

데스크톱용 v2rayN도 클라이언트에 해당합니다. 데스크톱에서 정상 작동하는 노드는 안드로이드 설정을 참고하는 데 도움이 되지만, 데스크톱의 로컬 수신 포트, 시스템 프록시 설정, 라우팅 파일 경로를 안드로이드에 그대로 적용할 수는 없습니다. 확인할 것은 같은 노드 이름을 쓰는지가 아니라 서버 주소, 프로토콜 매개변수, 전송 설정입니다.

프로토콜과 전송 방식 비교: 노드 이름만으로 호환 여부를 알 수 없습니다

노드는 최소한 프로토콜, 전송 방식, 보안 계층이라는 세 가지 요소로 구성됩니다. 예를 들어 VMess는 프록시 프로토콜, WebSocket은 전송 방식, TLS는 보안 계층입니다. VLESS와 REALITY도 서로 같은 개념이 아닙니다. VLESS는 프록시 프로토콜이고, REALITY는 Xray의 보안 방식입니다. 공유 링크가 vless://로 시작한다는 사실만으로는 클라이언트를 선택하기 어렵습니다.

VLESS라는 이름 자체가 Xray 전용 기능을 뜻하지는 않습니다. 실제로 확인해야 할 것은 전송 방식, 보안 계층, 흐름 제어와의 조합입니다. REALITY 노드에는 해당 조합을 지원하는 Xray 클라이언트를 사용하세요. REALITY를 일반 TLS로 바꾸거나 flow를 삭제해 저장해도 서버가 다른 핸드셰이크 방식을 받아들이는 것은 아닙니다.

v2rayNG와 v2flyNG: 현재 사용하는 노드에 맞춰 선택

구독 제공자가 Xray, REALITY, Vision 사용을 명시적으로 요구한다면 선택할 클라이언트가 정해지는 경우가 많습니다. 일반적인 VMess 노드만 있다면 두 클라이언트 모두 사용할 수 있습니다. 이때는 코어 이름만 보고 어느 쪽이 더 빠르다고 단정하지 말고, 가져오기 결과의 완전성, 연결 안정성, 일상적인 사용 편의성을 비교하세요.

이미 v2flyNG를 사용하고 있고 연결이 안정적이며 노드에 Xray 전용 요구 사항이 없다면, 단지 ‘새 코어’라는 이유만으로 옮길 필요는 없습니다. 반대로 v2rayNG를 사용 중이라면 일반적인 VMess 노드 때문에 클라이언트를 하나 더 설치할 필요도 없습니다. 재현과 문제 해결이 가능한 설정을 하나 유지하는 편이 서로 일치하지 않는 라우팅 설정 두 벌을 관리하는 것보다 유용합니다.

구독과 공유 링크: 가져온 뒤 설정 필드 확인하기

구독은 클라이언트 관리 계층에서 콘텐츠를 가져오는 방법이지, 코어 최상위 설정 키가 아닙니다. 구독 주소는 보통 여러 공유 링크나 클라이언트에서 인식할 수 있는 설정을 반환합니다. Base64는 흔히 쓰이는 인코딩 형식일 뿐 암호화 기능은 없으며, 두 클라이언트가 같은 방식으로 파싱한다는 보장도 없습니다. 한 구독에 여러 프로토콜의 노드가 포함될 수 있으므로 사용 가능 여부는 노드마다 확인해야 합니다.

1. 주소 유형을 확인합니다. https://로 시작하는 구독 주소는 구독 관리 메뉴에 입력하세요. vmess:// 또는 vless://로 시작하는 개별 공유 링크는 공유 링크 또는 클립보드 가져오기 메뉴를 이용하세요. 웹사이트의 구독 신청 페이지를 구독 주소로 입력하지 마세요.
2. 업데이트한 다음 노드 상세 정보를 확인합니다. v2rayNG에서는 보통 메인 화면 메뉴에서 ‘구독 그룹 설정’으로 이동해 주소를 추가하고 구독을 업데이트합니다. 메뉴 이름은 버전에 따라 달라질 수 있습니다. 노드 이름이 목록에 나타나는지만 보지 말고 노드 상세 정보까지 확인하세요.
3. 인증 정보와 연결 지점을 확인합니다. 서버 주소, 포트, UUID 또는 비밀번호를 대조하세요. 전송 유형, WebSocket 경로, Host, TLS 서버 이름도 확인해 주소만 복사하고 핸드셰이크 매개변수를 빠뜨리는 일이 없도록 합니다.
4. Xray 전용 필드를 확인합니다. REALITY 노드는 공개 키, shortId, 서버 이름, 서버에서 요구하는 지문을 중점적으로 확인하고, Vision 노드는 flow도 살펴보세요. 필드가 비어 있거나 값이 일치하지 않으면 임의로 추측해 입력하지 말고 유효한 설정을 다시 받으세요.
5. 로그를 확인한 뒤 연결합니다. 알 수 없는 프로토콜이나 전송 방식, 설정 파싱 오류가 나타나면 먼저 코어 기능과 가져오기 도구의 지원 여부를 확인하세요. 설정은 불러왔지만 핸드셰이크에 실패한다면 매개변수, 시스템 시간, 서버 상태를 점검하세요.

일부 전체 설정에 포함된 라우팅, DNS, 아웃바운드 태그는 개별 공유 링크에 담기지 않을 수 있습니다. 양쪽에서 같은 이름의 노드가 보여도 서버 연결 매개변수만 같고 분할 라우팅 정책은 다를 수 있습니다. 따라서 ‘같은 구독’을 사용하면 중복 입력을 줄일 수는 있지만, 최종 실행 설정까지 완전히 같다는 뜻은 아닙니다.

연결 확인: 서버 포트, 로컬 프록시, 안드로이드 VPN 구분하기

포트는 용도에 따라 구분해야 합니다. 서버 포트는 원격 서버에 연결할 때 사용하고, 로컬 SOCKS 또는 HTTP 포트는 기기의 앱이 프록시에 연결할 때 사용합니다. 안드로이드 시스템의 VPN 권한은 클라이언트가 앱 트래픽을 처리할 수 있는지를 결정합니다. 아래 세 숫자는 용도를 설명하기 위한 설정 예시이며, 두 클라이언트의 모든 버전에 적용되는 기본값이나 실측 결과가 아닙니다.

예를 들어 노드가 서버의 443 포트에 연결해야 하고 로컬 SOCKS 수신 포트가 10808이라면, 노드의 443을 10808로 바꾸면 안 됩니다. 로컬 수신 기능이 실제로 활성화되어 있고 유형도 맞을 때만 앱에서 127.0.0.1:10808을 사용할 수 있습니다. 일반적인 안드로이드 앱은 클라이언트의 VPN 모드로 처리하므로 앱마다 프록시 포트를 직접 입력할 필요가 없습니다.

• 1단계: 시스템 권한 확인. 연결을 시작한 뒤 안드로이드 VPN 권한이 승인되었는지 확인하세요. 클라이언트를 바꿔 테스트하기 전에 다른 클라이언트를 중지해야 합니다. 그렇지 않으면 시스템 VPN 세션이 교체되어 노드가 작동하지 않는 것으로 잘못 판단할 수 있습니다.
• 2단계: 앱 적용 범위 확인. 앱별 프록시를 사용한다면 브라우저가 적용 대상에 포함되어 있는지 확인하세요. 목록이 ‘포함’ 앱을 뜻하는지 ‘제외’ 앱을 뜻하는지 주의해야 합니다. 두 설정의 의미는 서로 반대입니다.
• 3단계: 라우팅과 DNS 확인. 대상 트래픽이 규칙에 따라 프록시 아웃바운드로 전달되는지, 도메인이 정상적으로 조회되는지 확인하세요. IP 주소로는 연결되지만 도메인으로 실패한다면 코어를 바꾸기 전에 DNS 경로부터 살펴보세요.
• 4단계: 실제 접속 확인. 정상 작동이 확인된 HTTPS 페이지를 열고 로그를 함께 확인하세요. 지연 시간 테스트에서 값이 나와도 해당 테스트만 성공했다는 뜻일 뿐, 모든 앱 트래픽이 프록시를 통과한다는 의미는 아닙니다.

두 코어 방식 모두 라우팅과 분할 처리를 지원하지만, 규칙 적용 여부는 도메인 정보를 확인할 수 있는지, DNS가 어떻게 설정되어 있는지, 규칙 순서가 어떤지에 따라 달라집니다. 서로 다른 아웃바운드 태그가 포함된 설정을 그대로 복사하면 프록시로 보내야 하는 트래픽이 다른 아웃바운드로 전달될 수 있습니다. 설정 계층별 설명은 고급 설정에서 확인하고, 클라이언트 설정과 코어 필드를 각각 어느 메뉴에서 바꾸는지 먼저 파악하세요.

동일한 조건에서 비교하기: 네트워크 변동을 코어 성능으로 오해하지 마세요

‘코어를 바꾼 뒤 빨라졌다’는 결과는 다른 노드, 다른 라우팅, 테스트 시각 차이, 연결 재사용이나 캐시 변화에서 비롯됐을 수 있습니다. 두 클라이언트가 같은 프로토콜 조합을 사용하도록 서버가 지원하는 경우에만 직접 비교할 수 있습니다. REALITY 노드를 비교 목적으로 다른 프로토콜로 바꾼 뒤 그 결과를 코어 성능 차이라고 해석해서는 안 됩니다.

1. 두 클라이언트의 버전과 내장 코어 버전을 기록하고, 서버의 프로토콜, 전송 방식, 보안 계층도 함께 적으세요. 구체적인 버전 기록 대신 ‘최신 버전’이라고만 쓰지 마세요.
2. 같은 Wi-Fi 또는 모바일 네트워크를 유지하고 테스트 중에는 네트워크를 바꾸지 마세요. 기기의 배터리 잔량과 온도를 비슷하게 유지하고 백그라운드에서 진행 중인 대용량 전송을 중지하세요.
3. 노드, DNS, 앱별 적용 범위, 라우팅 규칙을 동일하게 맞추세요. 같은 HTTPS 페이지에서 번갈아 테스트하고, 각 클라이언트에서 최소 5회씩 진행하세요. 가장 빠른 결과만 골라 기록하지 마세요.
4. 연결 성공 횟수, 페이지 접속 여부, 지연 시간 테스트 유형, 장시간 전송 결과를 각각 기록하세요. 짧은 연결은 정상인데 장시간 전송이 끊긴다면 로그를 함께 확인해야 합니다. 지연 시간 하나만으로 결과를 요약할 수 없습니다.
5. 실패를 재현할 수 있는 절차를 기록하세요. 한 클라이언트에서만 파싱에 실패하면 먼저 가져오기 도구를 점검하세요. 두 클라이언트에서 모두 핸드셰이크가 실패한다면 서버와 공용 네트워크 조건을 우선 확인하세요.

데스크톱과 안드로이드 함께 사용하기: 구독은 공유하고 플랫폼별로 검증

데스크톱에서 v2rayN을, 안드로이드에서 v2rayNG 또는 v2flyNG를 사용할 때는 제공자가 허용하는 기기 수와 연결 제한 안에서 같은 구독을 사용할 수 있습니다. 구독 업데이트는 원본 콘텐츠를 동기화할 뿐입니다. 현재 선택된 노드, 라우팅 규칙, DNS, 앱별 목록은 각 기기에서 따로 확인해야 합니다.

최종 선택 기준은 두 가지입니다. Xray 전용 기능이 필요하다면 해당 매개변수를 지원하는 v2rayNG를 선택하고, 검증된 V2Fly 설정이 이미 있다면 v2flyNG를 선택하세요. 두 클라이언트가 모두 지원하는 일반적인 프로토콜 조합만 사용한다면 정확한 설정 가져오기, 안정적인 트래픽 처리, 재현 가능한 테스트를 기준으로 판단하세요. 플랫폼과 인터페이스별 차이는 클라이언트 비교에서, 용어 설명은 용어 빠른 안내에서 확인할 수 있습니다.