REALITY와 XTLS Vision이 빠른 이유: 핸드셰이크 재사용과 흐름 제어 원리 해설

이 글 한눈에 보기

이 글은 VLESS, REALITY, XTLS Vision을 비교하는 사용자를 위해 TCP 연결 수립부터 TLS 핸드셰이크, 인증, 데이터 전달까지의 전체 경로를 분석하고, v2rayN에서 설정값을 확인하고 성능 병목과 핸드셰이크 실패를 점검하는 방법을 안내합니다.

TLS 핸드셰이크가 첫 바이트 지연에 영향을 주는 이유

프록시 연결의 ‘속도’에는 최소 세 가지 지표가 있습니다. 연결 수립 시간, 지속 전송 처리량, 그리고 패킷마다 필요한 CPU 처리 비용입니다. REALITY는 주로 핸드셰이크와 외형적 특성을 바꾸고, XTLS Vision은 안정적인 전송 단계의 데이터 경로를 최적화합니다. 둘을 단순히 ‘대역폭 향상’으로 이해하는 것은 정확하지 않습니다.

TCP 기반 TLS 1.3을 예로 들면, 클라이언트는 먼저 TCP 3방향 핸드셰이크를 완료한 뒤 ClientHello를 보냅니다. 서버는 ServerHello, 인증서 관련 메시지와 핸드셰이크 완료 메시지를 반환합니다. 일반적인 TLS 1.3 전체 핸드셰이크에서는 네트워크 왕복 1회 후 보호된 애플리케이션 데이터를 전송할 수 있습니다. 클라이언트와 서버 사이의 왕복 시간이 길면 이 메시지 교환이 첫 웹 요청이나 애플리케이션 연결의 대기 시간으로 바로 나타납니다.

TLS 1.2의 전체 핸드셰이크는 보통 더 많은 메시지 왕복이 필요하므로 TLS 1.3은 시작 비용을 이미 줄였습니다. 하지만 프록시 경로에서는 외부 TLS 안에 브라우저 자체의 HTTPS가 들어갈 수 있습니다. 외부 계층은 프록시 채널을 보호하고 내부 계층은 사용자가 접속하는 사이트를 보호합니다. 프록시 계층이 이미 암호화된 TLS 레코드에 다시 일반 암호화, 복사, 캡슐화를 수행하면 CPU와 메모리 작업이 중복될 수 있습니다.

TCP 연결 수립인사 메시지 전송인증 완료내부 TLS 식별애플리케이션 데이터 전달

1 RTT

TLS 1.3 전체 핸드셰이크의 일반적인 네트워크 왕복

32바이트

REALITY에서 사용하는 X25519 공개 키 길이

8바이트

shortId의 최대 원시 길이

16바이트

VLESS 사용자 UUID의 바이너리 길이

REALITY가 실제로 처리하는 것

REALITY는 Xray에서 인증된 TLS 스타일 연결을 수립하는 보안 계층으로, VLESS 및 TCP와 함께 사용하는 경우가 많습니다. 클라이언트는 ClientHello에 REALITY 매개변수로 생성된 인증 정보를 담고, 서버는 개인 키와 공개 키의 관계, shortId, 시간 범위 등을 기준으로 연결의 유효성을 판단합니다. 인증이 완료되면 연결은 VLESS와 이후 흐름 제어 처리 단계로 넘어갑니다.

‘실제 사이트 인증서를 빌린다’는 표현은 대상 사이트의 개인 키를 복사한다는 뜻이 아니라, 해당 사이트의 TLS 외형과 핸드셰이크 컨텍스트를 재사용한다는 의미로 이해하는 편이 정확합니다. REALITY 서버가 대상 사이트의 인증서 개인 키를 보유할 필요는 없습니다. 설정의 serverName은 서버에서 허용한 이름과 일치해야 하며, 클라이언트도 올바른 publicKey, shortId, fingerprint를 사용해야 합니다. 이 필드 중 하나라도 일치하지 않으면 핸드셰이크 단계에서 실패할 수 있습니다.

서버는 보통 접속 가능한 대상 주소도 설정합니다. REALITY 인증을 통과하지 못한 일반 탐색 연결은 설정에 따라 대상 사이트로 전달할 수 있어, 외부에서 관찰되는 응답이 일반적인 TLS 서비스와 더 비슷해집니다. 이 기능이 해결하는 것은 핸드셰이크 형태와 인증 문제이며, 서버 혼잡, 망 간 패킷 손실, 통신사 라우팅 우회 문제를 자동으로 해결하지는 않습니다.

VLESS + REALITY + Vision

네트워크: TCP
보안: REALITY
Flow: xtls-rprx-vision
지문: chrome
서비스 이름: 서버의 serverNames와 대응

클라이언트와 서버 모두 호환되는 Xray 코어를 사용하고 매개변수를 일치시킬 수 있는 환경에 적합합니다.

기존 외부 TLS 전송

네트워크: TCP 또는 WebSocket
보안: TLS
인증서: 서버 도메인 인증서
Flow: 일반적으로 비워 둠
추가 캡슐화: 전송 방식에 따라 결정

호환 범위가 직관적이지만, 전송 방식에 따라 추가 프레임과 복사 작업 및 배포 조건이 생길 수 있습니다.

결론: REALITY는 회선 가속기가 아닙니다

연결 지연의 원인이 망 간 라우팅, 서버 출구 회선 또는 지속적인 패킷 손실이라면 보안 계층을 바꿔도 사용 가능한 대역폭이 바로 늘어나지 않습니다. 핸드셰이크 비용, 외부 캡슐화 또는 CPU 처리가 병목일 때만 프로토콜 경로의 차이가 체감 성능에 뚜렷하게 반영됩니다.

XTLS Vision이 중복 처리를 줄이는 방식

VLESS 자체는 애플리케이션 데이터에 일반적인 콘텐츠 암호화 계층을 추가하지 않으며, 보안은 REALITY나 TLS 같은 외부 보안 계층이 제공합니다. XTLS Vision은 Xray의 흐름 제어 방식으로, 설정값은 보통 xtls-rprx-vision으로 작성합니다. 연결의 TLS 특성을 관찰한 뒤 필요한 핸드셰이크와 인증을 완료하면, 조건에 맞는 데이터에 더 직접적인 전달 경로를 적용합니다.

브라우저로 HTTPS 사이트에 접속하면 브라우저와 대상 사이트 사이에 이미 종단 간 TLS 계층이 형성됩니다. 기존 프록시 보안 채널이 내부 TLS 데이터 전체를 일반 페이로드로 취급해 계속 암호화하면 ‘TLS 데이터가 또 다른 보안 채널 안에 들어가는’ 처리 구조가 만들어집니다. Vision의 핵심은 대상 사이트의 HTTPS를 없애는 것이 아니라, 이미 암호화된 데이터 흐름을 식별해 외부의 중복 암호화, 버퍼링, 메모리 복사를 줄이는 데 있습니다.

이 최적화는 대용량 파일 전송, 다수의 HTTPS 연결 또는 서버 CPU 여유가 부족한 상황에서 더 쉽게 관찰됩니다. 짧은 연결의 전체 시간은 여전히 DNS, TCP 연결 수립, 네트워크 왕복에 좌우될 수 있으며, 저속 회선에서는 먼저 대역폭 제한을 받습니다. Vision은 대상 사이트 TLS의 인증서 검증 결과도 바꾸지 않으므로 브라우저와 대상 사이트 사이의 보안 경계는 그대로 유지됩니다.

처리 단계	REALITY의 역할	XTLS Vision의 역할	해결하지 못하는 문제
연결 수립	TLS 스타일 핸드셰이크를 형성하고 클라이언트 매개변수를 검증	아직 주요 최적화 단계에 진입하지 않음	TCP 패킷 손실과 물리적 거리
신원 인증	공개 키 관계, shortId, 서비스 이름 등의 조건을 검증	VLESS 사용자와 Flow 설정을 사용	만료된 구독과 잘못된 UUID
안정적인 전송	외부 보안 컨텍스트 유지	내부 TLS를 식별하고 중복 처리 감소	서버 대역폭 부족
애플리케이션 접속	대상 사이트의 인증서 검증을 대체하지 않음	브라우저와 사이트 사이의 콘텐츠를 복호화하지 않음	사이트 자체의 느린 응답

짧은 웹 요청: 왕복 시간, DNS, 최초 핸드셰이크의 영향을 더 크게 받으며 처리량 차이는 뚜렷하지 않을 수 있습니다.
지속 다운로드: 메모리 복사, 암호화 처리, 서버 CPU 사용량의 차이를 더 쉽게 확인할 수 있습니다.
고동시성 연결: Xray 로그, 프로세스 CPU 사용량, 시스템 연결 수를 함께 관찰해야 하며 단일 연결만으로 판단해서는 안 됩니다.
패킷 손실이 큰 네트워크: TCP 재전송과 혼잡 제어가 보통 주요 원인이며, Vision도 하위 계층의 재전송을 우회할 수 없습니다.

REALITY와 Vision이 자주 함께 언급되는 이유

REALITY와 Vision은 같은 연결의 서로 다른 단계를 처리합니다. REALITY는 특정 TLS 외형과 인증 기능을 갖춘 채널을 수립하고, Vision은 채널이 만들어진 뒤 조건에 맞는 데이터 흐름을 최적화합니다. 따라서 일반적인 조합은 VLESS가 사용자와 요청을 표현하고, REALITY가 보안 핸드셰이크를 담당하며, Vision이 흐름을 제어하고, TCP가 신뢰성 있는 전송을 맡는 방식입니다.

이 조합을 사용하려면 클라이언트와 서버의 매개변수가 정확히 일치해야 합니다. 클라이언트에는 publicKey만 있고 서버의 privateKey는 없으며, shortId는 서버 허용 목록에서 가져와야 합니다. serverName은 서버 설정과 일치해야 하고, Flow는 xtls-rprx-vision으로 설정해야 합니다. 일반 TLS 노드의 도메인과 포트를 REALITY 필드에 그대로 넣는다고 사용할 수 있는 연결이 만들어지지는 않습니다.

v2rayN에서 구독으로 가져오면 이 값들이 서버 설정에 자동으로 입력되는 경우가 많습니다. 직접 확인하려면 「서버」→「서버 편집」으로 이동해 주소, 포트, 사용자 ID, Flow, 전송 프로토콜, 보안 유형, SNI, 지문, 공개 키, shortId를 확인하세요. 그런 다음 「설정」→「매개변수 설정」에서 현재 Core 유형이 이 조합을 지원하는 Xray 코어인지 확인합니다.

프로토콜: VLESS
전송: TCP
보안: REALITY
Flow：xtls-rprx-vision
SNI: 서버의 serverNames와 일치
Fingerprint：chrome
Public key: 서버 공개 키로 생성
Short ID: 서버 허용 값과 완전히 일치

먼저 구독을 업데이트하고 해당 서버를 다시 선택해 이전 publicKey나 shortId를 계속 사용하지 않도록 하세요.
v2rayN의 서버 편집 창을 열고 VLESS, TCP, REALITY, Vision을 항목별로 확인하세요. 주소와 포트만 점검해서는 안 됩니다.
저장한 뒤 연결을 시작하고, 「도움말」→「로그 보기」에서 Xray 시작 과정과 핸드셰이크 및 아웃바운드 오류를 확인하세요.
시스템 프록시를 활성화한 뒤 일반 HTTPS 페이지에 접속하고 지속 다운로드도 테스트해 핸드셰이크 단계와 전송 단계를 나누어 판단하세요.
로컬 애플리케이션에서 프록시를 수동으로 사용하는 경우 v2rayN의 현재 수신 포트를 가리키는지 확인하세요. 일반적인 로컬 혼합 프록시 포트는 10808이지만, 실제 값은 「설정」→「매개변수 설정」에 표시된 값을 기준으로 해야 합니다.

결론: 프로토콜 이름보다 매개변수 일치가 중요합니다

노드 이름에 REALITY나 Vision이 포함되어 있다고 설정이 적용되었다는 뜻은 아닙니다. 편집 창의 security, flow, serverName, publicKey, shortId를 기준으로 확인한 뒤 Xray 로그에서 핸드셰이크 결과를 검증해야 합니다.

어떤 환경에 적합하고, 어떤 병목은 사라지지 않는가

VLESS, REALITY, Vision 조합은 클라이언트와 서버 모두 Xray 코어를 안정적으로 사용할 수 있는 환경에 적합합니다. 특히 HTTPS 사용이 많고 지속 전송이 잦으며 중복 처리를 줄이고 싶은 데스크톱 또는 안드로이드 연결에 유용합니다. v2rayN은 Windows, macOS, Linux 데스크톱 환경에서 사용할 수 있으며, 안드로이드에서 이 조합이 필요하다면 Xray 코어를 사용하고 해당 매개변수를 지원하는 v2rayNG를 사용해야 합니다.

v2flyNG는 v2fly 코어를 사용하므로 설정 기능은 해당 코어가 실제로 지원하는 범위에 따라 판단해야 합니다. REALITY나 Vision이 포함된 구독 항목을 받았을 때 구독을 성공적으로 가져왔다는 사실만으로 연결이 가능하다고 단정해서는 안 됩니다. 클라이언트 화면에 필드가 표시된다고 해서 현재 코어가 해당 핸드셰이크와 흐름 제어를 구현했다는 뜻도 아닙니다.

회선 자체의 품질은 여전히 성능 상한을 결정합니다. 서버 출구 회선에 고정 대역폭만 제공된다면 Vision도 그 제한을 넘을 수 없습니다. 지역 간 경로에서 지속적으로 패킷이 손실되면 TCP는 속도를 낮추고 재전송합니다. 서버 시간 오차가 너무 커도 REALITY 인증이 실패할 수 있습니다. 프로토콜 선택은 로그, 네트워크 경로, 리소스 사용량을 함께 관찰한 결과를 바탕으로 해야 합니다.

연결 성공으로 표시되지만 웹 페이지가 계속 로딩 중인가요?

먼저 v2rayN에서 시스템 프록시가 활성화되어 있는지 확인한 다음 「설정」→「매개변수 설정」에서 로컬 수신 포트를 점검하세요. 프록시를 수동으로 설정한 애플리케이션은 같은 포트를 사용해야 합니다. 예를 들어 설정 페이지에 10808이 표시된다면 애플리케이션이 이전 포트를 계속 가리켜서는 안 됩니다.

REALITY 핸드셰이크가 실패하면 무엇부터 확인해야 하나요?

serverName, publicKey, shortId, fingerprint, 시스템 시간 순서로 확인하세요. 구독을 업데이트한 뒤에는 서버를 다시 선택하고 코어를 재시작해 이전 프로세스가 기존 매개변수를 계속 사용하지 않도록 해야 합니다.

일반 VLESS는 연결되는데 Vision은 연결되지 않는 이유는 무엇인가요?

클라이언트와 서버 양쪽의 Flow가 xtls-rprx-vision으로 설정되어 있는지 확인하고, 현재 Xray 코어를 사용 중인지 점검하세요. Flow가 한쪽에만 설정되어 있거나 코어가 너무 오래되었거나 전송 조합이 호환되지 않으면 연결이 바로 실패할 수 있습니다.

Vision으로 바꿨는데 속도 측정 수치가 달라지지 않는 이유는 무엇인가요?

먼저 병목이 프로토콜 처리에 있는지 판단하세요. 같은 서버와 네트워크를 유지하면서 최초 연결, 지속 다운로드, CPU 사용량, 재전송 상황을 각각 기록해야 합니다. 출구 대역폭이 이미 가득 찼다면 프로토콜 처리 최적화로 최고 수치가 더 올라가지는 않는 경우가 많습니다.

모바일 네트워크를 전환한 뒤 다시 가져와야 하나요?

대개 그럴 필요는 없습니다. 먼저 연결을 끊었다가 다시 연결해 v2rayNG가 TCP와 REALITY 핸드셰이크를 새로 수립하도록 하세요. 로그에 인증 필드 불일치가 표시되거나 구독 매개변수가 갱신된 경우에만 구독을 업데이트하고 항목을 다시 선택하면 됩니다.

성능 향상이 어디에서 비롯되었는지 판단하는 방법

현재 네트워크에 프로토콜이 적합한지 판단하려면 먼저 재현 가능한 비교 조건을 만들어야 합니다. 같은 서버 주소, 같은 출구 포트, 같은 테스트 파일을 유지하고 보안 계층이나 Flow만 변경하세요. 각 조건은 최소 3회 실행하고 테스트 전에 연결을 새로 수립해야 합니다. 그렇지 않으면 DNS 캐시, 서버 부하, 네트워크 변동이 실제 차이를 가릴 수 있습니다.

첫 바이트가 느리지만 지속 다운로드가 정상이라면 네트워크 왕복, DNS, 핸드셰이크를 우선 확인하세요. 첫 바이트는 정상인데 장시간 연결에서 CPU 사용량이 높다면 중복 암호화나 복사 비용의 영향일 가능성이 큽니다. 처리량이 주기적으로 떨어지면서 TCP 재전송이 동반되면 먼저 패킷 손실을 해결해야 합니다. 로그의 핸드셰이크 실패는 설정 문제이므로 성능 문제와 섞어 분석해서는 안 됩니다.

v2rayN 또는 v2rayNG에서 연결 버튼을 누른 시점부터 코어가 사용 가능 상태를 보고할 때까지의 시간을 기록하세요.
동일한 HTTPS 리소스를 최소 60초 동안 계속 전송하며 순간 최고치가 아닌 안정 구간을 관찰하세요.
데스크톱 시스템의 작업 관리자나 시스템 모니터링 도구에서 Xray 프로세스의 CPU 사용량을 기록하세요.
직접 연결 규칙과 프록시 규칙을 각각 테스트해 라우팅이 테스트 대상을 잘못된 출구로 보내지 않는지 확인하세요.
코어 로그에 핸드셰이크 시간 초과, 연결 재설정, 포트 사용 중, DNS 해석 오류가 있는지 확인하세요.

핸드셰이크 단계 점검

관찰 항목: 최초 연결 시간
핵심 필드: SNI, 공개 키, shortId
네트워크 지표: RTT 및 패킷 손실
로그 위치: 도움말 → 로그 보기

연결이 아직 수립되지 않았다면 먼저 인증과 네트워크 왕복 문제를 배제하세요.

전송 단계 점검

관찰 항목: 안정적인 처리량
핵심 필드: xtls-rprx-vision
시스템 지표: CPU 및 재전송
테스트 시간: 최소 60초

연결이 안정된 뒤에 Vision이 처리 비용을 줄였는지 판단하세요.

따라서 REALITY와 XTLS Vision의 장점은 하나의 ‘가속 스위치’에서 나오는 것이 아닙니다. REALITY는 검증 가능한 매개변수로 대상 TLS 외형에 맞는 연결을 수립하고, Vision은 보안 채널 안에서 이미 암호화된 애플리케이션 트래픽을 식별해 중복 처리를 줄입니다. 매개변수가 일치하고 코어가 호환되며 라우팅이 올바르고 회선 병목이 허용될 때에만 이 조합이 더 짧은 시작 대기 시간, 낮은 리소스 사용량 또는 안정적인 지속 전송으로 나타납니다.