REALITY와 XTLS Vision 기술 해설: 핸드셰이크와 데이터 전달 경로가 더 빠른 이유

REALITY가 먼저 해결하는 핸드셰이크와 인증 문제

REALITY는 Xray 생태계의 전송 보안 메커니즘으로, 일반적으로 VLESS, TCP, XTLS Vision과 함께 사용됩니다. 클라이언트가 서버를 확인하는 방법, 서버가 허용된 클라이언트를 식별하는 방법, 외부에서 관찰되는 TLS 핸드셰이크 특성을 처리합니다. 독립적인 프록시 프로토콜이 아니며 VLESS의 사용자 식별자와 아웃바운드 설정을 대신하지 않습니다.

기존 TLS 서비스에서는 일반적으로 서버가 도메인 인증서를 보유하고, 클라이언트가 인증서 체인·도메인·유효 기간으로 서버를 검증합니다. REALITY는 다른 인증 정보를 사용합니다. 서버는 X25519 개인 키를 보관하고, 클라이언트는 대응하는 공개 키와 함께 서버 이름, Short ID, 클라이언트 지문 등의 매개변수를 전달합니다. 항목이 일치하고 인증에 성공한 연결만 프록시 처리 경로로 진입합니다.

설정의 서버 이름은 보통 serverName 또는 SNI로 표시되며 서버에서 허용한 이름과 일치해야 합니다. 공개 키는 주로 publicKey로 표시되고, 일부 최신 인터페이스에서는 Password로 표기됩니다. Short ID는 16진수 문자열입니다. 세 항목은 클라이언트에서 임의로 추론할 수 없으며 서버 설정이나 구독 내용에서 제공되어야 합니다.

‘사이트 인증서를 보유하지 않는다’고 해서 신원 확인을 건너뛰는 것은 아닙니다. 클라이언트는 여전히 REALITY 공개 키로 대상 서버를 확인해야 하며, 서버도 클라이언트가 보낸 인증 정보를 검사합니다. 공개 키가 틀리거나 Short ID 길이가 맞지 않거나 SNI가 허용 목록에 없으면 연결은 대개 핸드셰이크 단계에서 종료되며, 애플리케이션 계층의 요청은 아직 VLESS 라우팅에 진입하지 않습니다.

• 주소와 포트: TCP 연결을 어디로 보낼지 결정합니다. 일반적으로 사용하는 수신 포트는 443이지만 서버는 다른 포트도 사용할 수 있습니다.
• UUID: VLESS 사용자 인증 정보이며 REALITY 공개 키로 대체할 수 없습니다.
• SNI: 노드 설정에서 가져와야 하며 서버 IP를 기준으로 임의 입력해서는 안 됩니다.
• 지문: 일반적인 값은 chrome이며 이에 맞는 클라이언트 핸드셰이크 특성을 생성합니다.
• SpiderX: 보통 /을 사용하며 다른 경로가 필요한지는 서버 설정에 따라 결정됩니다.

XTLS Vision이 데이터 전달 경로를 단축하는 이유

XTLS Vision은 VLESS의 흐름 제어 값 xtls-rprx-vision에 해당합니다. 최초 신원 인증이 아니라 연결 수립 후 데이터를 어떻게 전달할지에 초점을 둡니다. 많은 웹 페이지와 앱은 이미 TLS를 사용하므로 프록시 전송 계층에서 전체 내용을 다시 범용 암호화로 감싸면 버퍼링, 데이터 복사, 암복호화 스케줄링 비용이 늘어납니다.

Vision은 연결의 데이터 처리 단계를 분석하고 조건을 충족하면 더 직접적인 전달 방식을 사용해 이미 암호화된 트래픽의 중복 처리를 줄입니다. 여기서 ‘줄인다’는 모든 데이터가 보안 계층을 우회한다는 뜻이 아니며, 모든 운영체제가 동일한 제로 카피 구현을 사용한다는 의미도 아닙니다. 핸드셰이크 데이터, 제어 정보, 식별 조건을 충족하지 않는 데이터와 프로토콜상 필요한 패딩은 여전히 규칙에 따라 처리됩니다.

첫 데이터 구간에는 Vision의 패딩과 형태 처리도 적용되며, 초기 연결이 지나치게 일정한 구조로 보이지 않게 하는 것이 목적 중 하나입니다. 안정적인 전송 단계에 들어간 뒤에야 오버헤드가 더 낮은 경로로 전환될 수 있습니다. 따라서 짧은 연결은 핸드셰이크 시간의 영향을 더 크게 받고, 대용량 다운로드·동영상 세그먼트·장시간 전송에서는 데이터 경로 차이가 더 잘 나타납니다.

Vision의 효과는 코어와 시스템 네트워크 스택에도 좌우됩니다. 회선이 10 Mbps뿐이라면 CPU 오버헤드 감소가 눈에 띄는 속도 향상으로 이어지지 않을 수 있습니다. 수백 Mbps의 지속 전송에서는 데이터 복사와 스케줄링 비용이 제한 요소가 되기 쉽습니다. 병목이 저녁 시간대 혼잡, 망 간 우회 경로 또는 5% 이상의 패킷 손실이라면 Flow를 바꿔도 물리 회선 문제는 해결되지 않습니다.

지연 시간, 처리량, CPU 사용률은 어떻게 비교해야 할까

클라이언트 노드 목록의 지연 값만으로 Vision이 더 빠른지 판단하기는 어렵습니다. 지연 테스트는 보통 TCP 연결 수립, 코어 탐색 또는 특정 URL 응답 시간만 측정하며, 여기에 DNS, 대상 사이트 처리 시간과 회선 변동이 포함될 수 있습니다. 프로토콜 차이는 같은 서버·같은 출구·같은 테스트 파일·비슷한 시간대에 비교하고 최소 5회 반복해야 합니다.

이 글의 통제된 기록은 Windows 11 24H2, 기가비트 유선 LAN, 동일한 원격 서버와 동일한 공용 회선을 사용했습니다. 테스트 파일은 1 GiB이며 5회 연속 실행 후 중앙값을 계산했습니다. 두 노드 그룹은 전송 보안과 Flow만 변경했고 수신 포트는 모두 443이었습니다. 이 수치는 관찰 방법을 보여 주기 위한 것이며 다른 회선의 고정된 결과를 의미하지 않습니다.

이 기록에서는 첫 요청보다 처리량 차이가 더 크게 나타났으며, 장시간 연결에서 전달 경로 차이가 잘 드러난다는 예상과 일치합니다. 그러나 322 Mbps는 프로토콜의 상한이 아니며 이를 바탕으로 모바일 네트워크 결과를 추정할 수도 없습니다. 테스트 중 백그라운드 업데이트, 브라우저 캐시, 서버 디스크 읽기 또는 시스템 프록시 모드가 달랐다면 결론은 달라집니다.

1. 다른 다운로드와 클라우드 동기화 작업을 먼저 종료하고 유선 연결 또는 동일한 무선 위치를 고정하세요.
2. 두 노드 그룹에 동일한 서버 주소·포트·아웃바운드 회선을 사용하세요.
3. 각각 5회 이상 실행하고 중앙값을 기록하세요. 한 번의 최고 속도로 결과를 대신하지 마세요.
4. 코어 로그, 작업 관리자의 CPU 사용률, 실패 횟수와 테스트 시간대도 함께 확인하세요.
5. 지연 시간과 처리량을 따로 기록하고 노드 탐색 값을 웹 페이지 전체 로딩 시간으로 간주하지 마세요.

v2rayN과 v2rayNG의 설정 항목 위치

v2rayN에서 구독 또는 공유 링크로 노드를 가져온 뒤 노드를 두 번 클릭해 편집 창을 여세요. 주소, 포트, 사용자 ID, Flow, 전송 프로토콜, 전송 계층 보안, SNI, 지문, 공개 키, Short ID와 SpiderX를 확인해야 합니다. 인터페이스 버전에 따라 항목 순서는 달라질 수 있지만 의미는 같습니다.

전역 매개변수는 ‘설정’ → ‘매개변수 설정’에 있습니다. 코어는 REALITY와 Vision을 지원하는 Xray 코어를 선택해야 합니다. 코어를 변경한 뒤 클라이언트를 재시작하고 로그에서 실제로 로드된 코어를 확인하세요. 노드의 전송 프로토콜은 보통 TCP, 보안 유형은 reality, Flow는 xtls-rprx-vision으로 설정합니다.

v2rayNG에서 구성 목록을 연 다음 대상 노드를 눌러 편집 화면으로 이동하고 ‘전송 프로토콜’, ‘전송 계층 보안’, ‘Flow’, ‘SNI’, ‘Fingerprint’, ‘Public Key’, ‘Short ID’ 등의 항목을 확인하세요. v2rayNG는 Xray 코어로 이 조합을 처리하며, 구독을 업데이트하면 일반적으로 항목이 자동 입력됩니다. 수동 편집은 주로 구독 변환 과정에서 누락된 항목을 점검할 때 사용합니다.

v2flyNG는 v2fly 코어를 사용하므로 프로토콜 지원 범위가 Xray 코어와 다릅니다. REALITY와 XTLS Vision은 Xray 기능이 필요한 설정이므로 이러한 노드는 v2rayN의 Xray 코어 또는 v2rayNG를 사용해야 합니다. 보안 유형을 reality로 바꾸는 것만으로 다른 코어에서도 연결된다고 가정해서는 안 됩니다.

연결 실패 시 핸드셰이크·프록시·시스템 계층별로 점검하기

REALITY 노드에 오류가 발생하면 먼저 어느 계층에서 실패했는지 확인하는 것이 가장 효과적입니다. TCP 연결 시간 초과는 주소·포트·방화벽·회선을 가리키는 경우가 많습니다. REALITY authentication failed, invalid response와 같은 메시지는 공개 키·Short ID·SNI·지문 또는 시스템 시간을 의심해야 합니다. 핸드셰이크는 성공했지만 웹 페이지가 열리지 않는다면 시스템 프록시, TUN 모드, DNS와 라우팅 규칙을 계속 확인하세요.

컴퓨터에서는 클라이언트가 실행 중인지와 시스템 트래픽이 실제로 클라이언트에 들어가는지를 구분해야 합니다. v2rayN이 코어를 시작했더라도 브라우저가 프록시를 거치는지는 시스템 프록시, TUN 모드 또는 앱 자체의 프록시 설정에 따라 달라집니다. 시스템 프록시를 사용한다면 현재 모드가 활성화되었는지 확인하세요. TUN 모드라면 가상 네트워크 어댑터 생성 로그와 관리자 권한 관련 메시지를 확인해야 합니다.

로컬 포트 충돌도 ‘노드를 사용할 수 없음’이라는 착각을 만들 수 있습니다. 예를 들어 클라이언트가 10808에서 수신 대기하도록 설정되어 있는데 해당 포트를 다른 프로세스가 사용 중이면 코어가 정상적으로 시작되지 않을 수 있습니다. 이때는 로그로 포트 점유 프로세스를 찾거나 매개변수 설정에서 로컬 포트를 변경하세요. 노드 테스트만 반복해서는 수신 대기 실패를 해결할 수 없습니다.

• 1단계: 서버 주소가 해석되고 TCP 포트 연결이 수립되는지 확인합니다.
• 2단계: UUID, 공개 키, Short ID, SNI, 지문과 Flow를 대조합니다.
• 3단계: 코어 로그에 핸드셰이크 성공 후 대상 연결 기록이 나타나는지 확인합니다.
• 4단계: 시스템 프록시, TUN 모드, 로컬 포트와 DNS 설정을 점검합니다.
• 5단계: 복잡한 라우팅 규칙을 일시 중지하고 직접 연결 규칙으로 최소 테스트를 진행합니다.

선택할 때는 프로토콜 이름보다 호환 범위를 확인하세요

VLESS + REALITY + XTLS Vision은 클라이언트와 서버 모두 호환되는 Xray 코어를 실행할 수 있고 인증서 구축 절차를 줄이면서 장시간 연결의 전달을 최적화하려는 환경에 적합합니다. 일반적인 VLESS + TCP보다 설정 항목이 많으므로 구독 생성 및 변환 과정에서도 관련 매개변수를 빠짐없이 보존해야 합니다.

현재 서비스가 표준 TLS 인증서로 안정적으로 운영되고 있거나 REALITY를 지원하지 않는 코어와 연동해야 한다면 VLESS + TCP + TLS를 계속 사용하는 편이 관리하기 쉬울 수 있습니다. 프로토콜 선택은 단순한 신구 교체가 아닙니다. 호환성, 서버 제어권, 구독 형식, 클라이언트 코어와 회선 품질을 모두 고려해야 합니다.

VMess, Trojan과 Shadowsocks에도 각각의 구축 및 호환 환경이 있지만 Flow를 입력한다고 Vision의 동작 방식을 얻을 수는 없습니다. xtls-rprx-vision은 특정 조합에서 사용하는 설정 값이며 어떤 프로토콜에나 추가할 수 있는 범용 가속 스위치가 아닙니다.

최종 판단은 세 가지로 정리할 수 있습니다. REALITY는 핸드셰이크와 양측 인증을 담당하고, Vision은 조건에 맞는 데이터 전달을 최적화하며, VLESS는 사용자 및 프록시 연결 정보를 전달합니다. 클라이언트 항목, 서버 인바운드와 코어 기능이 모두 일치해야 조합이 예상대로 작동합니다.