REALITY 프로토콜과 XTLS Vision은 왜 빠를까: 인증서 없는 핸드셰이크와 트래픽 제어 원리

REALITY와 XTLS Vision은 VLESS 노드 설정에 함께 등장하는 경우가 많지만, 해결하는 문제의 층위는 서로 다릅니다. REALITY는 연결 수립과 인증, 외부에 보이는 연결 특성을 담당하고, Vision은 연결이 수립된 뒤 데이터 스트림을 처리합니다. 둘을 막연히 ‘가속 프로토콜’로 이해하면 속도 향상의 원인을 잘못 판단하거나 노드를 가져오고 로그를 점검할 때 확인할 필드를 놓치기 쉽습니다.

먼저 TLS 핸드셰이크와 이중 암호화 비용을 나눠 보기

일반적인 HTTPS 연결은 먼저 TCP 3방향 핸드셰이크를 완료한 뒤 TLS 핸드셰이크를 진행합니다. 연결 상태가 양호한 TLS 1.3은 보통 왕복 1회로 주요 핸드셰이크를 마칩니다. 클라이언트와 서버 사이의 왕복 지연 시간이 80ms라면 네트워크 왕복 대기만으로도 약 80ms가 걸릴 수 있습니다. DNS 조회, TCP 재전송, 인증서 체인 처리까지 더해지면 첫 바이트 도착 시간은 더 길어집니다.

프록시 경로에서는 암호화가 두 겹으로 적용될 수도 있습니다. 브라우저가 HTTPS 사이트에 접속하면 애플리케이션 데이터가 이미 사이트의 TLS로 암호화되어 있는데, 외부 프록시 전송 과정에서 전체 데이터를 일반적인 암호화로 한 번 더 처리하면 ‘내부 사이트 TLS + 외부 프록시 암호화’ 구조가 됩니다. 이것이 설계 오류라는 뜻은 아닙니다. 외부 계층은 여전히 인증과 전송 보호를 담당하지만, 대용량 파일 전송이나 고처리량 회선에서는 중복 처리가 CPU 사용량, 메모리 복사, 버퍼 스케줄링 비용을 높일 수 있습니다.

지연 시간과 처리량은 따로 관찰해야 합니다. 핸드셰이크 최적화는 첫 바이트 도착과 짧은 연결의 체감에 주로 영향을 주고, 트래픽 제어 최적화는 지속적인 다운로드·동영상 전송·대규모 동시 연결에서 더 잘 드러납니다. 회선이 20Mbps에 불과하고 CPU가 원래 여유롭다면 Vision을 적용해도 눈에 띄는 다운로드 차이가 없을 수 있습니다. 반대로 서버 출구 대역폭이 1Gbps이고 클라이언트 장치의 처리 성능이 제한적이라면 중복 암호화와 복사를 줄인 효과가 속도에 더 잘 나타납니다.

• 첫 바이트 도착 시간: DNS, TCP, 인증 및 핸드셰이크에 몇 번의 왕복이 필요한지 확인합니다.
• 지속 처리량: CPU가 한계까지 사용되는지, 메모리 복사가 빈번한지, 회선에서 패킷 손실이 발생하는지 확인합니다.
• 연결 안정성: NAT 타임아웃, 포트 접근 가능 여부, 서버 부하 및 중간 네트워크 품질을 확인합니다.
• 프로토콜 호환성: 클라이언트와 서버 모두 해당 REALITY 및 Vision 구현을 지원해야 합니다.

REALITY가 인증과 핸드셰이크 외형을 만드는 방식

REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS·TCP·Vision과 함께 사용하는 경우가 많습니다. 서버는 개인 키를 설정하고 클라이언트는 이에 대응하는 공개 키를 보유하며, shortId 등의 필드로 인증에 참여합니다. 클라이언트는 serverName과 fingerprint 등의 매개변수도 전달하여 특정 실제 사이트에 접속하는 TLS 특성에 가까운 핸드셰이크를 만듭니다.

여기서 ‘실제 사이트 인증서를 빌린다’는 표현은 정확히 이해해야 합니다. REALITY는 대상 사이트에서 검증 가능한 TLS 특성을 활용해 연결 외형을 구성하지만, 프록시 서버의 신원은 여전히 REALITY 키 체계로 확인합니다. 클라이언트가 serverName만 보고 노드를 신뢰해서는 안 되며, publicKey·shortId·주소·포트 등의 매개변수는 동일한 유효 설정에서 나온 것이어야 합니다.

인증되지 않은 탐색 트래픽이 도착하면 서버는 연결을 미리 지정한 대상 사이트로 전달하여 외부에서 보이는 결과를 일반적인 TLS 서비스에 가깝게 만들 수 있습니다. 이 과정은 올바른 대상 사이트·포트·서버 설정에 의존하며, 모든 도메인이 대상에 적합하다는 뜻은 아닙니다. 대상은 안정적인 TLS 1.3 접속을 지원해야 하고 네트워크 경로가 서버 환경과도 잘 맞아야 합니다.

1. 클라이언트는 먼저 노드에 있는 주소, 포트, 사용자 ID, publicKey, shortId 및 serverName을 읽습니다.
2. 서버에 연결한 뒤 클라이언트는 지정된 fingerprint에 따라 해당 핸드셰이크 특성을 생성합니다.
3. 서버는 개인 키와 인증 매개변수를 사용해 연결이 유효한 클라이언트에 속하는지 판단합니다.
4. 인증에 성공하면 VLESS 데이터 채널로 진입하고, 인증에 실패한 트래픽은 서버 정책에 따라 대상 사이트로 전달됩니다.

XTLS Vision이 데이터 처리 비용을 줄이는 이유

Vision의 핵심은 ‘더 강력한 압축’을 사용하는 데 있지 않으며, 단순히 더 빠른 암호화 알고리즘으로 교체하는 것도 아닙니다. 연결에서 TLS 데이터의 형태를 식별하고, 필요한 인증과 초기 보호를 완료한 뒤 조건에 맞는 내부 TLS 1.3 데이터에 더 직접적인 처리 경로를 적용하여 외부의 중복 암호화·복호화와 메모리 복사를 줄입니다. 내부 HTTPS 데이터 자체는 여전히 애플리케이션과 대상 사이트 사이의 TLS로 보호됩니다.

이 최적화를 일반 평문 트래픽에 무조건 적용하는 것은 아닙니다. Vision은 데이터 내용과 연결 단계에 따라 트래픽 제어를 조정하며, 보안 경계를 확인할 수 없을 때는 외부 보호를 유지합니다. 따라서 실제 효과는 HTTPS 트래픽 비중, 클라이언트 CPU, 서버 CPU, 네트워크 처리량, 코어 구현 버전에 따라 달라집니다.

고정된 환경에서 비교하면 차이가 어디에서 발생하는지 확인할 수 있습니다. 1Gbps 유선 네트워크, RTT 38ms, 패킷 손실 약 0.2%, 동일한 서버와 1GB HTTPS 파일을 기준으로 외부 처리를 모두 적용한 방식은 10회 측정 중앙 처리량 684Mbps, 클라이언트 단일 프로세스 최대 CPU 63%를 기록했습니다. Vision을 활성화한 뒤에는 중앙 처리량 742Mbps, 최대 CPU 48%로 나타났습니다. 처리량은 약 8.5% 증가했고 CPU 최대치는 15%포인트 감소했습니다. 이 결과는 분석 방법을 보여 주기 위한 예시일 뿐 모든 회선에서 같은 비율이 나온다는 뜻은 아닙니다.

• 저사양 장치, 기가비트 회선, 대량 HTTPS 전송 환경에서 CPU 차이를 더 쉽게 확인할 수 있습니다.
• 패킷 손실이 많은 회선에서는 TCP 재전송이 먼저 병목이 될 수 있으므로, 트래픽 제어 최적화만으로 네트워크 품질을 대체할 수 없습니다.
• 짧은 웹 요청에서는 첫 바이트 도착 시간이 더 중요하며, 한 번의 다운로드 최고 속도만으로 웹 브라우징 경험 전체를 판단할 수 없습니다.
• 서버 부하가 지나치게 높다면 먼저 CPU steal, 연결 수, 출구 혼잡을 확인해야 합니다.

REALITY와 Vision을 함께 적용한 실제 연결 흐름

두 기능을 함께 사용할 때 연결은 보통 VLESS + TCP + REALITY로 구성하고 Flow는 xtls-rprx-vision으로 설정합니다. REALITY가 먼저 핸드셰이크 외형과 신원 인증을 처리하고, Vision이 인증 후 데이터 스트림을 처리합니다. VLESS는 가벼운 사용자 인증과 데이터 전달을 제공하며, 세 요소는 서로 대체하는 관계가 아닙니다.

v2rayN에서는 「서버」→「클립보드에서 URL 일괄 가져오기」를 통해 공유 링크를 가져올 수 있습니다. 가져온 뒤 노드를 편집하면서 전송 프로토콜이 TCP인지, 보안 유형이 REALITY인지, Flow가 xtls-rprx-vision인지, serverName·publicKey·shortId가 존재하는지 중점적으로 확인합니다. 전역 코어 설정은 「설정」→「매개변수 설정」에서 열 수 있으며, 코어를 바꾼 뒤에는 현재 연결을 다시 시작해야 합니다.

1. 먼저 v2rayN에서 사용하는 Xray 코어를 업데이트한 다음 노드를 가져오세요. 오래된 코어가 REALITY 필드를 인식하지 못하는 문제를 피할 수 있습니다.
2. 연결하기 전에 로컬 수신 포트가 다른 프로그램과 충돌하지 않는지 확인하세요. 일반적인 SOCKS 포트는 10808, HTTP 포트는 10809이며 실제 값은 「매개변수 설정」을 따릅니다.
3. 노드를 시작한 뒤 정보 영역을 확인하세요. 정상이라면 Xray 시작 기록과 인바운드 수신 대기 기록이 표시되며, unknown security 또는 unsupported flow가 나타나지 않아야 합니다.
4. 직접 연결 지연 시간, 프록시 첫 바이트 도착 시간, 지속 다운로드를 각각 테스트하세요. 노드 목록의 TCP 지연 시간만으로 대역폭을 판단하지 마세요.

어떤 환경에 적합하며, 어떤 병목은 해결되지 않을까

REALITY + Vision은 서버와 클라이언트 모두 최신 Xray 코어를 실행할 수 있고, 주로 HTTPS 트래픽을 처리하며, 인증서 운영 절차를 줄이고 고처리량 환경의 CPU 비용을 낮추려는 경우에 적합합니다. 표준 Web 사이트의 리버스 프록시에 의존하지 않고 단일 서버에 직접 연결하는 구조에도 알맞습니다.

현재 배포가 WebSocket 경로, 표준 TLS 종료 또는 다른 Web 서비스와의 진입점 공유에 의존한다면 security만 reality로 바꿔서는 안 됩니다. REALITY는 보통 TCP와 함께 사용하며 서버 수신 설정, 대상 주소, 개인 키, 공개 키, shortId를 모두 한 세트로 조정해야 합니다. 구독 서비스가 생성한 노드에도 이 필드가 빠짐없이 포함되어야 합니다.

REALITY도 서버와의 거리가 너무 멀거나, 망 간 혼잡, 불안정한 무선 신호, TCP 패킷 손실을 해결하지는 못합니다. RTT 180ms, 패킷 손실 5%인 회선을 예로 들면 CPU 사용량이 매우 낮더라도 TCP 혼잡 윈도가 반복해서 줄어들어 최종 처리량이 RTT 38ms, 패킷 손실 0.2%인 회선보다 훨씬 낮을 수 있습니다. 이때는 프로토콜 매개변수를 계속 추가하기보다 먼저 출구를 바꾸거나 회선 품질을 개선해야 합니다.

자주 묻는 설정 질문과 문제 해결 순서

REALITY 노드 문제는 대개 매개변수 누락, 너무 오래된 클라이언트 코어, 시스템 시간 오차 또는 서버 대상에 연결할 수 없는 문제에서 발생합니다. 문제를 해결할 때는 원본 구독 내용을 보존하고 항목별로 비교하세요. serverName·fingerprint·shortId를 한꺼번에 수정하면 어떤 항목 때문에 연결이 복구되거나 계속 실패하는지 판단할 수 없습니다.

최종 판단은 전체 연결 경로를 기준으로 해야 합니다. 클라이언트 버전이 필드를 인식하고, Xray 코어가 정상적으로 시작되며, REALITY 매개변수가 한 세트로 일치하고, 양쪽의 Vision Flow가 동일하며, 시스템 프록시 또는 애플리케이션 프록시가 올바른 로컬 포트를 가리켜야 합니다. 이 조건이 모두 충족되어야 속도 측정 결과가 프로토콜과 트래픽 제어의 차이를 제대로 보여 줍니다.