Xray 코어와 V2Fly 코어의 차이점은? VLESS·REALITY 기능 분석

먼저 Xray, V2Fly, Project V의 관계부터 정리하기

Project V는 초기 V2Ray 기술 체계의 출발점이며, 이후 v2ray-core는 V2Fly 커뮤니티가 이어서 유지보수했습니다. Xray는 같은 코드 기반에서 갈라져 독자적인 프로토콜 구현, 설정 필드와 릴리스 주기를 발전시켰습니다. 인바운드, 아웃바운드, 라우팅, DNS, VMess, VLESS 및 여러 전송 방식 같은 기본 개념은 공유하지만, 이제는 하나의 프로그램을 부르는 두 이름으로 단순하게 볼 수 없습니다.

코어는 노드 설정 해석, 로컬 포트 수신, 원격 전송 연결, DNS 조회와 라우팅 규칙 적용 등 실제 연결 처리를 담당합니다. v2rayN, v2rayNG, v2flyNG는 사용자 인터페이스와 설정 관리 계층에 해당합니다. 사용자가 화면에서 노드를 선택하면 클라이언트가 코어가 읽을 수 있는 설정을 생성한 뒤 해당 프로세스를 실행합니다. 따라서 같은 구독이 여러 클라이언트에서 같은 이름으로 표시되어도 하위 코어의 기능까지 완전히 같다는 뜻은 아닙니다.

두 계열의 차이는 주로 새로운 프로토콜 확장에서 나타납니다. V2Fly는 자체 설정 체계, 기본 프로토콜과 범용 전송 기능을 중시하고, Xray는 VLESS, XTLS Vision, REALITY 조합을 지속적으로 확장해 왔습니다. 노드가 VMess, TCP, WebSocket 또는 표준 TLS만 사용한다면 두 코어 모두 처리할 수 있지만, 설정에 특정 flow, REALITY 공개 키 또는 short ID가 포함되면 필드에 맞춰 코어를 선택해야 합니다.

VMess와 VLESS의 차이가 곧 코어의 차이는 아닙니다

VMess는 Project V 체계에서 비교적 일찍 사용된 프록시 프로토콜로, 노드에는 보통 서버 주소, 포트, 사용자 ID, 전송 방식과 TLS 설정이 포함됩니다. VLESS는 인증 구조가 더 간결하지만, 그 자체로 전송 방식과 암호화 방식을 결정하지는 않습니다. VLESS는 TCP, WebSocket, gRPC, TLS와 조합할 수 있고, Xray 계열에서는 XTLS Vision 또는 REALITY와도 함께 사용할 수 있습니다.

따라서 “Xray는 VLESS를 지원하고 V2Fly는 VMess만 지원한다”는 판단은 정확하지 않습니다. 두 코어 모두 기본적인 VLESS 시나리오를 지원하며, 실제로 확인해야 할 부분은 VLESS 뒤에 붙는 조합 필드입니다. 특히 노드 링크나 구독 기록에 flow=xtls-rprx-vision, security=reality, 공개 키, short ID 또는 지문 매개변수가 있다면 해당 필드를 해석할 수 있는 Xray 코어를 사용해야 합니다.

XTLS Vision과 REALITY는 각각 어떤 문제를 해결하나요?

XTLS는 Xray 계열의 전송 최적화 및 트래픽 처리 메커니즘입니다. 현재 설정에서는 VLESS와 xtls-rprx-vision을 조합하는 형태가 흔합니다. Vision은 연결 내용에 따라 데이터 처리 방식을 조정하며, 특정 TLS over TLS 상황에서 중복 처리를 줄이는 데 초점을 둡니다. 독립적인 노드 프로토콜이 아니므로 VLESS, 전송 계층과 서버 설정 없이 단독으로 활성화할 수 없습니다.

REALITY는 Xray에서 사용하는 전송 보안 방식입니다. 클라이언트 연결에는 서버 주소와 포트뿐 아니라 serverName, 공개 키, short ID를 정확히 입력해야 하며, 지문과 spiderX 같은 매개변수가 포함될 수도 있습니다. 일반 TLS와 설정 방식이 다르므로 보안 유형만 TLS에서 REALITY로 바꾸고 나머지 필드를 그대로 둘 수 없습니다. 서버의 개인 키와 클라이언트 공개 키, 허용된 serverName, short ID가 서로 맞는 구성으로 입력되어야 합니다.

일반적인 REALITY 노드는 원격 포트로 443을 사용하지만, 포트 번호만으로 프로토콜을 판별할 수는 없습니다. 443에서도 표준 TLS를 사용할 수 있고, 서버 설정에 따라 다른 포트도 이용할 수 있습니다. 443이라는 숫자보다 구독 기록의 보안 유형과 관련 필드를 확인해야 합니다.

REALITY 설정은 다음 순서로 확인하세요

1. 프로토콜이 VLESS인지 확인하고 서버 주소, 원격 포트와 사용자 ID를 점검합니다. 불필요한 공백이나 잘린 문자가 없는지도 확인하세요.
2. 보안 유형이 표준 TLS가 아닌 REALITY인지 확인하고, 전송 유형도 서버 설정과 일치하는지 점검하세요.
3. serverName의 전체 도메인을 확인하세요. 이 필드는 서버 주소와 다를 수 있으므로 노드 주소가 숫자 주소라는 이유만으로 serverName을 삭제하면 안 됩니다.
4. 공개 키와 short ID를 확인하세요. short ID는 16진수 값이므로 복사할 때 따옴표, 쉼표 또는 줄바꿈이 포함되지 않아야 합니다.
5. flow 필드가 있다면 서버 설정과 값이 일치하는지 확인하세요. 흔한 값은 xtls-rprx-vision이며, vision만 입력해서는 안 됩니다.
6. 저장한 뒤 연결을 다시 시작하고 코어 로그를 확인하세요. 이전 프로세스가 종료되지 않았다면 수정 전 설정을 계속 사용할 수 있습니다.

구독은 같은데 코어를 바꿔도 왜 실패할 수 있나요?

구독은 노드 정보를 전달할 뿐, 모든 클라이언트가 모든 필드를 손실 없이 해석한다고 보장하지는 않습니다. 일반적인 구독 형식은 프로토콜, 주소, 포트, 사용자 ID, 전송 및 보안 매개변수를 링크나 구조화된 기록으로 인코딩합니다. 구독 생성 측에서 최신 Xray 필드를 사용했는데 클라이언트 파서에 대응 매핑이 없으면 노드가 목록에 표시되더라도 공개 키, flow 또는 short ID가 실제로 비어 있을 수 있습니다.

또 다른 문제는 설정 변환에서 발생합니다. 클라이언트는 보통 구독 내용을 그대로 코어에 넘기지 않고 자체 데이터 모델로 변환한 뒤 실행 설정을 생성합니다. 이 과정에서 REALITY를 TLS로 처리하거나 serverName을 서버 주소로 바꾸거나 flow를 무시하면 코어 로그에 필드 오류, 인증 실패 또는 핸드셰이크 중단이 나타납니다. 이때 구독을 반복해서 업데이트해도 해결되지 않으므로 노드 세부 정보에서 항목별로 확인해야 합니다.

라우팅 규칙도 “코어 비호환”처럼 보이는 문제를 만들 수 있습니다. 노드 연결은 성공했지만 대상 도메인이 규칙에 의해 직접 연결 아웃바운드로 전달되면 예상과 다른 결과가 나옵니다. 문제를 해결할 때는 먼저 단순 라우팅 모드로 기본 연결을 확인한 뒤 도메인·주소 규칙과 규칙 세트 분할을 복원하세요. 특히 DNS 결과와 라우팅 조건이 일치하지 않을 때는 DNS도 별도로 점검해야 합니다.

로그로 장애 단계를 찾아보세요

• 코어가 시작되지 않음: 설정 문법, 코어 파일, 수신 포트와 중복 프로세스를 확인하세요. 로그에 address already in use가 표시되면 해당 포트를 점유한 프로세스를 종료하거나 로컬 수신 포트를 변경해야 합니다.
• 연결이 즉시 끊김: 서버 주소, 포트, 사용자 ID, flow, 보안 유형, 공개 키와 short ID를 확인하고 필드 누락을 우선 점검하세요.
• 연결 대기 후 시간 초과: 현재 네트워크에서 원격 주소와 포트에 도달할 수 있는지 확인한 다음 서버가 실제로 수신 중인지 점검하세요. 복잡한 라우팅 규칙부터 조정하지 마세요.
• 코어 연결은 성공했지만 웹 페이지가 열리지 않음: 시스템 프록시, 로컬 SOCKS 또는 HTTP 포트, DNS와 라우팅 아웃바운드 방향을 확인하세요.
• 일부 도메인만 정상이고 일부는 실패: 코어를 바로 바꾸기보다 도메인 규칙, 주소 규칙, DNS 응답과 분할 우선순위를 확인하세요.

v2rayN, v2rayNG와 v2flyNG는 어떻게 선택해야 하나요?

Windows, macOS와 Linux 사용자는 보통 v2rayN으로 데스크톱 연결을 관리합니다. 노드를 선택하기 전에 프로토콜 세부 정보를 확인하세요. 노드가 VLESS, XTLS Vision 또는 REALITY를 사용한다면 실제로 Xray 코어가 실행되는지 확인해야 합니다. VMess, WebSocket과 표준 TLS만 사용한다면 프로토콜 이름 때문에 자주 바꾸기보다 검증된 기존 설정을 유지해도 됩니다.

Android에서는 v2rayNG가 Xray 코어를 사용하므로 Xray 확장 필드가 포함된 구독에 적합합니다. v2flyNG는 V2Fly 코어를 사용하므로 V2Fly 설정 경로를 유지하려는 사용자에게 알맞습니다. 두 앱의 조작 방식은 비슷하지만 하위 설정 기능이 항목별로 동일한 것은 아닙니다. 노드를 옮길 때는 구독 그룹과 노드 이름만 비교하지 말고 세부 정보 화면을 확인해야 합니다.

클라이언트 선택 시 라우팅 규칙의 출처도 고려해야 합니다. Xray와 V2Fly 모두 라우팅과 DNS를 지원하지만 필드 구조, 규칙 기능과 버전 발전 방향은 다릅니다. 고급 설정 전체를 그대로 복사하면 알 수 없는 필드 오류가 발생할 수 있습니다. 노드 연결 매개변수만 먼저 가져온 다음 대상 클라이언트에서 라우팅 규칙을 다시 만들고, 로그로 도메인과 주소가 예상한 아웃바운드로 들어가는지 확인하는 편이 안전합니다.

클라이언트를 바꾸기 전에 다음 정보를 보관하세요

• 노드 프로토콜, 원격 주소, 포트, 사용자 ID, 전송 방식과 보안 유형을 기록하세요.
• VLESS 노드는 flow를 추가로 기록하고, REALITY 노드는 공개 키, short ID, serverName, 지문과 경로 필드를 추가로 기록하세요.
• 현재 로컬 SOCKS 및 HTTP 수신 포트를 기록해 시스템 프록시가 이전 클라이언트를 계속 가리키지 않도록 하세요.
• 라우팅 규칙과 노드 매개변수를 따로 저장해 라우팅 문제를 노드 장애로 오해하지 않도록 하세요.
• 전환 후 먼저 단일 노드를 테스트한 다음 전체 구독 그룹과 자동 업데이트 작업을 갱신하세요.

자주 묻는 질문: 호환성, 속도와 설정 이전

코어 이름만으로 연결 속도를 결정할 수는 없습니다. 실제 결과에는 서버 회선, 혼잡, 왕복 지연 시간, 패킷 손실, 전송 캡슐화, TLS 처리, 기기 성능과 라우팅 규칙이 함께 영향을 줍니다. XTLS Vision은 특정 상황에서 중복 처리를 줄이는 것을 목표로 하지만, 이를 근거로 고정된 속도 향상 비율을 예측할 수는 없습니다.

마찬가지로 REALITY도 일반 VMess 노드의 옵션 하나를 바꾼다고 활성화되는 기능이 아닙니다. 서버와 클라이언트 양쪽에 맞는 설정이 필요하며 올바른 키와 식별 필드에 의존합니다. 구독에 관련 매개변수가 없다면 클라이언트가 임의로 채울 수 없습니다. 연결 오류가 발생하면 공개 키나 short ID를 무작위로 생성하지 말고 설정 출처로 돌아가 필드를 확인하세요.

코어 선택 시 이 체크리스트를 사용하세요

코어 선택은 프로젝트 역사를 추측하는 것부터 시작할 필요 없이 노드의 실제 필드를 확인하면 됩니다. VMess, WebSocket, gRPC와 표준 TLS 같은 일반 조합은 현재 호환성을 우선하고, VLESS 설정은 보안 유형과 flow를 추가로 확인하세요. XTLS Vision, REALITY, 공개 키와 short ID가 있으면 Xray 계열을 선택하는 것이 가장 직접적입니다.

노드 연결은 되지만 접속 결과가 이상하다면 로컬 포트, 시스템 프록시, DNS와 라우팅 분할을 먼저 점검하세요. 로그에서 알 수 없는 필드, 설정 해석 실패 또는 프로토콜 핸드셰이크 불일치가 명확히 확인될 때만 코어 호환성에 집중하면 됩니다. 계층별로 처리하면 노드, 코어, 라우팅과 시스템 프록시를 번갈아 바꾸는 일을 줄일 수 있습니다.

1. 프로토콜 확인: VMess인지 VLESS인지 확인하고 노드 이름에 의존하지 마세요.
2. 보안 유형 확인: 표준 TLS와 REALITY를 구분하고 serverName을 기록하세요.
3. flow 확인: xtls-rprx-vision이 있으면 Xray를 선택하고 서버 설정과 일치하는지 확인하세요.
4. 클라이언트 확인: 데스크톱에서는 v2rayN으로 해당 코어를 관리하고, Android에서는 Xray 또는 V2Fly 계열에 맞춰 v2rayNG와 v2flyNG를 선택하세요.
5. 로컬 수신 확인: 시스템 프록시, 브라우저 프록시와 클라이언트 포트가 모두 일치해야 합니다.
6. 로그 확인: 코어 시작, 원격 연결, TLS 핸드셰이크, DNS와 라우팅이 각각 어느 계층에 있는지 먼저 판단하세요.
7. 마지막으로 복잡한 설정 복원: 기본 연결이 확인된 뒤 구독 자동 업데이트, DNS 정책과 라우팅 규칙 세트를 다시 활성화하세요.