REALITY 프로토콜과 XTLS Vision 해설: 핸드셰이크 원리와 성능 향상 분석

먼저 REALITY, VLESS, XTLS Vision의 역할부터 구분하기

구독에서 자주 보이는 전체 조합은 “VLESS + TCP + REALITY + XTLS Vision”입니다. 네 항목은 같은 계층의 프로토콜명이 아닙니다. VLESS는 클라이언트와 서버 사이의 사용자 식별과 프록시 요청 형식을 담당하고, TCP는 데이터를 전달하는 전송 방식입니다. REALITY는 외부 핸드셰이크, 서버 신원 확인, 트래픽 외관을 담당하며, XTLS Vision은 애플리케이션 계층에서 이미 암호화된 TLS 데이터를 식별해 전달 경로를 조정하는 흐름 제어 방식입니다.

따라서 REALITY는 VLESS를 대체하는 독립 프록시 프로토콜이라기보다 Xray 코어에서 사용하는 전송 보안 방식에 가깝습니다. 서버가 자체 도메인용 공개 인증서를 발급받거나 전용 도메인을 서버로 연결할 필요가 없습니다. 클라이언트는 publicKey, shortId, serverName 등의 값으로 대상 서버를 식별하고, 서버는 설정된 실제 웹사이트를 핸드셰이크 외관과 폴백 대상으로 사용합니다.

XTLS Vision도 새로운 암호화 알고리즘은 아닙니다. 웹사이트 접속은 일반적으로 HTTPS로 이미 암호화되어 있습니다. 프록시 외부에서 표준 TLS를 다시 적용하면 프록시 코어가 이미 암호화된 애플리케이션 데이터를 계속 처리해야 하므로 “TLS 안에 다시 TLS를 넣는” 경로가 만들어집니다. Vision은 연결 특성을 확인한 뒤 이 전달 과정을 최적화해 중복 처리와 메모리 복사를 줄이면서도 연결 초기에 필요한 패딩과 핸드셰이크 보호는 유지합니다.

REALITY는 실제 웹사이트 특성을 어떻게 활용할까

일반적인 TLS 서버는 자체 도메인과 일치하는 공개 인증서를 서버에서 전송합니다. REALITY는 다른 방식으로 동작합니다. 클라이언트가 일반적인 브라우저와 유사한 ClientHello를 먼저 만들고, 설정된 serverName을 SNI에 넣습니다. 서버는 개인 키와 공개 키의 관계, shortId 등의 값을 바탕으로 유효한 클라이언트에서 온 연결인지 판단한 뒤 신원 확인 절차를 진행합니다.

연결에 유효한 인증 정보가 없으면 서버는 핸드셰이크를 미리 설정한 대상 웹사이트로 전달할 수 있습니다. 외부에서 관찰되는 SNI, TLS 버전, 암호 스위트와 대상 사이트의 응답이 일관된 맥락을 이루므로 프록시 전용으로 배포된 자체 서명 인증서가 노출되지 않습니다. 여기서 ‘활용’한다는 것은 대상 사이트의 공개 핸드셰이크 특성과 폴백 동작을 재사용한다는 의미이며, 대상 사이트의 개인 키를 복제하거나 공식 인증서를 위조한다는 뜻은 아닙니다.

1. 인사 생성: 클라이언트는 fingerprint 매개변수에 따라 TLS ClientHello를 구성하며, 일반적으로 chrome을 사용합니다.
2. 대상 이름 전달: serverName은 SNI에 들어가며, 서버가 허용한 이름 목록에 포함되고 서버 설정과 일치해야 합니다.
3. 인증 완료: 클라이언트의 publicKey는 서버의 privateKey와 대응해야 하며, shortId도 서버에서 허용한 값이어야 합니다.
4. 연결 구분: 인증에 성공하면 VLESS 세션으로 진입하고, 인증에 실패한 일반 TLS 트래픽은 서버 설정에 따라 대상 사이트로 전달됩니다.
5. 프록시 시작: VLESS가 대상 주소를 해석한 뒤 Vision이 후속 데이터를 일반 방식으로 처리할지 최적화된 경로로 전달할지 결정합니다.

XTLS Vision은 중복 암호화 부담을 어떻게 줄일까

HTTPS 웹사이트를 여는 상황을 예로 들어 보겠습니다. 브라우저는 먼저 대상 웹사이트와 TLS 계층을 설정합니다. 프록시 터널 외부에서 표준 TLS를 다시 사용하면 프록시 코어가 이미 암호화된 애플리케이션 데이터를 계속 처리해야 합니다. 두 암호화 계층은 논리적으로 서로 다른 경로를 보호하지만, 크고 압축하기 어려운 TLS 암호문이 일반 암복호화 및 버퍼 처리 과정을 반복해서 거치면 CPU 사용량, 메모리 복사, 스케줄링 횟수가 증가합니다.

Vision은 연결 초기 데이터를 관찰해 내부 TLS의 핸드셰이크와 레코드 경계를 식별합니다. 조건이 충족되면 이후 암호화 데이터가 더 직접적인 전달 경로를 사용하도록 할 수 있습니다. 핵심은 보안 계층을 없애는 것이 아니라 종단 간 암호화 특성을 이미 갖춘 대용량 트래픽에 불필요한 포장을 반복하지 않는 데 있습니다. 일반 평문 연결이나 식별할 수 없는 데이터는 코어가 해당 규칙에 따라 계속 처리합니다.

연결 초반 구간도 중요합니다. Vision은 초기 데이터에 필요한 패딩과 형태 처리를 적용해 고정된 패킷 길이나 첫 패킷의 특징이 지나치게 두드러지는 문제를 줄입니다. 프로토콜 상태, 방향, 데이터 유형이 확인되면 더 효율적인 복사 방식으로 전환합니다. 따라서 장시간 연결, 대용량 파일 다운로드, 고화질 동영상에서 처리량 향상이 더 잘 나타나며, 데이터가 적은 짧은 연결에서는 차이가 대체로 작습니다.

• HTTPS 대용량 트래픽: 내부 데이터가 이미 암호화되어 있어 Vision이 최적화 경로로 전환되기 쉽습니다.
• 짧은 웹 요청: DNS, TCP 연결 설정, 서버 응답 시간이 차지하는 비중이 커 속도 차이가 수 밀리초에 그칠 수 있습니다.
• 고대역폭 서버: CPU 또는 메모리 복사가 병목이 될 때 처리량 향상이 더 뚜렷합니다.
• 패킷 손실이 많은 회선: 재전송과 혼잡 제어는 여전히 TCP가 담당하므로 Vision이 회선 자체의 패킷 손실을 해결할 수는 없습니다.

지연 시간, 처리량, CPU 사용량을 보는 방법

다음은 차이를 이해하기 위한 동일 환경 비교 데이터입니다. 서버는 2코어 가상 머신, 클라이언트는 기가비트 유선 네트워크이며 왕복 지연 시간은 약 42ms, 테스트 파일은 1GB입니다. 세 번 연속 실행한 뒤 중앙값을 사용했습니다. 표준 VLESS + TCP + TLS와 VLESS + REALITY + Vision은 같은 서버와 출구를 사용했습니다. 이 데이터는 전형적인 경향만 보여 주므로 모든 회선에 그대로 적용되는 고정값으로 보아서는 안 됩니다.

결론: 대용량 트래픽은 처리량, 짧은 요청은 회선을 확인하세요

주된 문제가 웹페이지 첫 로딩 지연이라면 먼저 DNS, 노드와의 거리, 패킷 손실을 확인해야 합니다. 다운로드 중 서버 CPU가 장시간 80%를 넘는다면 같은 회선에서 REALITY + Vision으로 전환할 때 눈에 띄는 개선을 얻을 가능성이 큽니다.

테스트할 때 노드, 대상 웹사이트, 프로토콜을 동시에 바꾸지 마세요. 무엇 때문에 향상되었는지 판단할 수 없게 됩니다. 다른 다운로드 작업을 중지하고 같은 테스트 파일을 고정한 뒤 각각 세 번 실행해 중앙값과 CPU 최고 사용률을 비교하는 방법이 가장 안전합니다. 브라우저에 표시되는 순간 속도는 변동이 크므로 30초 이상 지속한 전송 결과가 더 참고할 만합니다.

클라이언트에 가져온 뒤 확인할 설정

v2rayN 데스크톱 버전과 v2rayNG 안드로이드 버전은 일반적으로 구독을 통해 REALITY 노드를 가져옵니다. 가져오기에 성공했다고 해서 설정이 완전한 것은 아닙니다. 특히 구독을 변환했거나 수동으로 편집한 경우 flow, serverName, fingerprint, publicKey, shortId가 누락될 수 있습니다. v2flyNG는 V2Fly 코어를 사용하므로 Xray REALITY와 Vision에 의존하는 노드에는 적합하지 않습니다. 구독이 요구하는 코어와 호환되는 클라이언트를 선택해야 합니다.

호환성 문제를 확인할 때는 Xray-core v1.8.0을 비교적 보수적인 REALITY 기준으로 삼을 수 있지만, 실제 사용에서는 클라이언트 최신 안정 버전에 포함된 업데이트된 코어를 우선 사용하세요. 구형 코어가 realitySettings 또는 xtls-rprx-vision을 인식하지 못하면 노드가 시작되지 않거나 설정 확인에 실패하고, 로그에 알 수 없는 필드라는 메시지가 직접 표시되는 경우가 많습니다.

1. 먼저 구독을 업데이트하고 노드 편집 화면을 연 다음, 프로토콜이 VLESS이고 전송 방식이 TCP인지 확인하세요.
2. 주소와 포트를 확인하세요. 포트는 일반적으로 443이지만 반드시 구독에 표시된 실제 값을 따라야 합니다.
3. 보안 유형이 REALITY인지, serverName이 완전한 도메인인지 확인하세요.
4. fingerprint의 일반적인 값이 chrome인지 확인하고 publicKey와 shortId가 잘리지 않았는지 확인하세요.
5. flow가 xtls-rprx-vision인지 확인하세요. 서버에서 활성화하지 않았다면 임의로 추가하지 마세요.
6. 저장한 뒤 코어를 다시 시작하고 로그에 핸드셰이크, 인증 또는 알 수 없는 필드 오류가 나타나는지 확인하세요.

자주 묻는 질문과 핸드셰이크 실패 해결

REALITY 연결 문제는 보통 세 곳에서 발생합니다. 클라이언트 설정이 완전히 가져와지지 않았거나, 클라이언트와 서버 코어의 기능이 맞지 않거나, 네트워크에서 서버의 수신 포트에 연결할 수 없는 경우입니다. 먼저 코어가 시작되는지 확인하고, 다음으로 TCP 연결 여부를 확인한 뒤, 마지막으로 REALITY 핸드셰이크를 분석하세요. 이 순서를 따르면 포트 연결 불가를 공개 키 오류로 잘못 판단하는 일을 피할 수 있습니다.

문제 해결 순서: 시작, 포트, 핸드셰이크, 프록시

먼저 코어가 정상적으로 실행되는지 확인하고, 다음으로 서버 포트에 연결할 수 있는지 점검한 뒤, REALITY 신원 설정을 확인하고, 마지막으로 시스템 프록시와 라우팅을 살펴보세요. 한 번에 한 항목만 변경하고 다시 테스트해야 실제 장애 지점을 가장 쉽게 찾을 수 있습니다.

선택 관점에서 REALITY + Vision은 Xray 코어를 사용하면서 인증서 배포 단계를 줄이고 HTTPS 대용량 트래픽 전달을 최적화하려는 환경에 적합합니다. 노드와의 거리, 출구 혼잡, TCP 패킷 손실을 자동으로 해결해 주는 것은 아닙니다. 적합한 클라이언트 버전, 완전한 구독 설정, 안정적인 서버 회선이 모두 충족되어야 핸드셰이크 외관과 데이터 경로 최적화가 체감 가능한 연결 품질로 이어집니다.