Xray 코어와 V2Fly 코어 차이: 프로토콜 지원·성능 특성·설정 호환성

클라이언트·코어·노드 프로토콜 구분하기

v2rayN, v2rayNG, v2flyNG는 구독 관리, 설정 편집, 로그 표시, 연결 제어를 담당하는 클라이언트입니다. 코어는 실제 프록시 연결을 만들고 라우팅 규칙을 적용하며 트래픽을 처리합니다. 노드 목록에 표시되는 VMess와 VLESS는 프로토콜 이름이지 클라이언트 이름이 아닙니다. 클라이언트 화면을 다른 앱으로 바꿔도 서버가 허용하는 프로토콜은 바뀌지 않습니다.

V2Fly 커뮤니티는 V2Ray 프로젝트를 관리하며, 이 글에서는 해당 구현을 ‘V2Fly 코어’라고 부릅니다. Xray는 V2Ray 프로젝트에서 분기해 발전한 독립 코어입니다. 두 코어는 공통된 역사를 갖지만, 현재는 ‘같은 프로그램의 다른 이름’으로 볼 수 없습니다. 프로토콜 확장, 설정 필드, 버전별 변경 사항이 서로 다를 수 있습니다.

• 데스크톱: v2rayN은 노드를 관리하고 설정된 코어를 실행합니다. 화면에서 특정 필드를 입력할 수 있다고 해서 현재 실행 중인 코어가 그 필드를 지원한다는 뜻은 아닙니다.
• 안드로이드: v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 노드 요구 사항에 맞는 앱을 선택하세요. 두 앱을 코어만 자유롭게 바꿔 끼우는 동일한 껍데기로 보면 안 됩니다.
• 서버: 프로토콜, 수신 포트, 인증 정보, 전송 방식, 보안 계층을 결정합니다. 클라이언트 설정은 이 값들과 일치해야 합니다.

프로토콜 지원: VLESS와 REALITY는 다르고, XTLS와 TLS도 다릅니다

코어를 비교할 때 가장 혼동하기 쉬운 부분은 프로토콜과 보안 계층을 하나로 묶어 생각하는 것입니다. VLESS는 프록시 프로토콜 계층을 담당하고, TCP와 WebSocket 등은 전송 방식입니다. TLS와 REALITY는 연결 보안 관련 설정이며, xtls-rprx-vision은 해당 구현이 지원해야 하는 flow 값입니다. 노드 설정을 이해하려면 각 계층을 따로 확인해야 합니다.

기본 VLESS 자체에는 전송 암호화 기능이 없습니다. VLESS라고 해서 보안 계층 설정을 생략하면 안 되며, REALITY 선택 항목을 TLS로 바꾸는 것도 호환 방법이 아닙니다. 서버에서 REALITY를 요구한다면 해당 구현을 지원하는 클라이언트를 사용하고 서버가 제공한 값을 입력해야 합니다.

XTLS의 과거 설정과 현재 Vision 설정도 서로 섞어 쓸 수 없습니다. 오래된 안내에 나온 flow 값, 전송 이름, 보안 필드는 현재 버전에서 더 이상 유효하지 않을 수 있습니다. 이전할 때는 노드 제공자가 준 전체 설정과 코어 로그를 기준으로 확인하고, 이름이 비슷하다는 이유만으로 대체하지 마세요.

클라이언트 선택: 노드에 따라 Xray 또는 V2Fly 결정

아래 권장 사항은 REALITY나 Vision이 필요한 경우에 한정됩니다. 모든 회선과 하드웨어에서 특정 코어가 더 빠르다는 뜻은 아닙니다. 서버에서 이미 사용할 수 있는 V2Fly 설정을 제공했고 추가 기능이 필요하지 않다면, 코어를 바로 바꾸기보다 기존 조합을 유지하는 편이 변수를 관리하기 쉽습니다.

1. 필드 확인: 노드 편집 화면에서 security=reality 또는 flow=xtls-rprx-vision이 있는지 확인하세요. 해당 값이 있으면 우선 Xray 설정으로 처리하는 것이 좋습니다.
2. 데스크톱 설정 확인: v2rayN에서 ‘설정’ → ‘매개변수 설정’으로 이동해 현재 버전의 코어 관련 항목을 찾으세요. 프로토콜별 코어 지정이 가능한 버전이라면 해당 노드 프로토콜에 어떤 코어가 연결되어 있는지 확인해야 합니다. 버전에 따라 메뉴 위치가 달라질 수 있습니다.
3. 실행 결과 확인: 노드를 저장하고 활성 서버로 설정한 뒤 로그에서 코어 이름, 버전, 시작 오류를 확인하세요. 설정 화면에서 선택한 값만 확인해서는 안 됩니다.
4. 안드로이드 앱 확인: v2rayNG 또는 v2flyNG의 노드 목록에서 해당 노드를 길게 눌러 편집 화면을 열고 설정을 확인하세요. 앱에서 필요한 필드를 입력할 수 없다면 필드를 삭제하지 말고 노드에 맞는 클라이언트로 바꾸세요.

설정 호환성: 공유 링크를 가져올 수 있어도 JSON 설정까지 그대로 바꿔 쓸 수 있는 것은 아닙니다

구독 가져오기와 전체 설정 이전은 별개의 작업입니다. 공유 링크에는 보통 특정 아웃바운드 노드 하나의 정보만 들어 있습니다. 클라이언트는 링크를 해석한 뒤 로컬 인바운드, DNS, 라우팅 등 다른 설정을 추가로 생성합니다. 전체 JSON에는 특정 코어용 확장 필드가 포함될 수도 있습니다. 양쪽 클라이언트에서 같은 VMess 링크를 가져올 수 있어도 전체 JSON 설정을 그대로 덮어써 사용할 수 있다는 뜻은 아닙니다.

예를 들어 아래 세 필드는 Xray의 REALITY 및 Vision 설정에서 쓰이는 값입니다. 식별 방법을 보여 주기 위한 예시일 뿐, 실행 가능한 설정이 아니며 이 값만으로 노드를 구성할 수도 없습니다.

"protocol": "vless"
"security": "reality"
"flow": "xtls-rprx-vision"

이전이 실패하면 먼저 ‘설정 파싱 실패’와 ‘원격 핸드셰이크 실패’를 구분하세요. 로그에 알 수 없는 필드, 알 수 없는 보안 유형, 미지원 flow가 표시되면 아직 로컬 설정 단계의 문제입니다. 코어는 시작되지만 핸드셰이크에 실패한다면 주소, 포트, 인증 정보, 보안 계층, 시스템 시간을 확인하세요. 오류 원인을 찾는 대신 인증서 검증을 끄지 마세요.

성능 특성: 같은 조건에서 테스트하고 코어 이름만으로 순위를 매기지 마세요

Xray의 Vision은 특정 TLS 트래픽 처리 경로를 최적화하지만, 모든 프로토콜과 부하에서 똑같은 성능 향상을 보장하지는 않습니다. 회선 혼잡, 서버 부하, 전송 캡슐화, 기기 CPU, 네트워크 전환이 코어 차이보다 더 큰 영향을 줄 수 있습니다. 서로 다른 노드의 지연 시간을 비교해서는 코어 성능을 판단할 수 없습니다.

먼저 테스트 접속 지점을 동일하게 맞추세요. 아래는 문제 해결에 사용할 수 있는 포트 예시이며 클라이언트 기본값은 아닙니다. 실제 값은 설정 화면과 시작 로그를 기준으로 확인하세요. 원격 포트가 443이라고 해서 일반 TLS 서비스라고 단정할 수도 없습니다.

• 연결 조건 고정: 같은 기기, 네트워크, 서버를 사용하고 양쪽 코어가 모두 지원하는 프로토콜 조합으로 비교하세요. 한쪽은 WebSocket을 쓰고 다른 쪽은 다른 전송 방식을 쓰는 식으로 비교하면 안 됩니다.
• 부하 고정: 각 조건에서 3회 테스트하고, 매회 같은 테스트 파일을 30초 동안 다운로드해 처리량 중앙값, CPU 사용률, 오류 횟수를 기록하세요. 이는 테스트 방법이며 이 사이트의 실측 결과가 아닙니다.
• 지표 구분: TCP 핸드셰이크 지연 시간은 연결 진입 구간만 보여 줍니다. 실제 연결 테스트에는 대상 사이트와 보안 핸드셰이크도 영향을 줍니다. 다운로드 처리량이 지속 전송 성능을 더 잘 반영합니다.
• 백그라운드 작업 통제: 구독 자동 업데이트와 다른 다운로드를 일시 중지하세요. 안드로이드에서는 시스템의 성능 제한을 코어 차이로 오인하지 않도록 전원 모드를 동일하게 유지하는 것이 좋습니다.

사용 가능한 노드가 REALITY뿐이라면 같은 프로토콜을 유지한 채 V2Fly로 바꿔 비교할 수 없습니다. 이 경우 비교를 위해 서버 프로토콜을 바꾸지 말고, 현재 기기에서 Xray 연결이 안정적인지와 리소스를 얼마나 사용하는지 평가하세요.

전환 후 문제 해결: 코어 시작 상태를 확인한 뒤 라우팅과 DNS 점검

코어가 정상적으로 시작되어도 앱 트래픽이 프록시를 통과한다는 보장은 없습니다. 데스크톱 시스템 프록시는 해당 설정을 따르는 앱에만 적용됩니다. 안드로이드에서는 VPN 연결과 앱별 적용 범위에 따라 프록시를 이용하는 앱이 결정됩니다. 코어를 바꾸면서 라우팅, DNS, 프록시 모드까지 함께 변경하면 문제를 재현하기 어려워지므로 한 번에 한 항목씩 바꾸세요.

1. 시작 로그 확인: 먼저 설정 파싱 오류와 address already in use를 확인하세요. 예시 포트 10808을 이전 프로세스가 사용 중이라면 해당 프로세스를 중지한 뒤 새 설정을 시작하세요.
2. 트래픽 진입 경로 확인: 데스크톱에서는 시스템 프록시나 앱에 직접 설정한 프록시 주소를 확인하세요. 안드로이드에서는 VPN 사용 권한을 허용했는지, 앱별 목록에 테스트할 앱이 포함되어 있는지 확인하세요.
3. 라우팅 태그 확인: 사용자 지정 설정에서 아웃바운드 태그가 존재하는지 확인하세요. 이전 후에도 규칙이 예전 태그를 참조하면 시작에 실패하거나 트래픽이 예상과 다르게 전달될 수 있습니다.
4. DNS 확인: DNS 서버에 접근하는 경로와 도메인 규칙 및 도메인 해석 정책의 관계를 확인하세요. DNS 조회 실패를 VMess나 VLESS 탓으로만 돌릴 수는 없습니다.
5. 단일 노드로 재테스트: 자동 선택과 복잡한 분기 설정을 잠시 제외하고, 명확한 프록시 아웃바운드를 통해 고정된 대상에 접속해 보세요. 연결이 확인되면 라우팅 규칙을 하나씩 다시 추가하세요.

도메인, IP, 아웃바운드 규칙의 관계는 프로토콜 설명의 라우팅 안내를 참고하세요. 프록시 진입 설정을 다시 구성하려면 입문 가이드에 따라 클라이언트 설정을 확인하고, 전체 실행 설정을 그대로 덮어쓰지 마세요.

자주 묻는 질문: 구독·핸드셰이크·안드로이드 앱 선택

최종 선택은 두 단계로 정리할 수 있습니다. 먼저 클라이언트와 코어가 노드의 프로토콜 요구 사항을 충족하는지 확인한 다음, 같은 조건에서 연결과 성능을 검증하세요. REALITY와 Vision은 코어를 선택할 명확한 기능 기준입니다. 일반적인 VMess나 기본 VLESS 설정은 코어 이름만 보고 결정하지 말고 전송 방식, 보안 계층, 설정 형식까지 확인해야 합니다.