REALITY와 XTLS Vision 원리: VLESS flow로 암호화 오버헤드를 줄이는 방법

TLS 핸드셰이크와 프록시 터널: 중복 암호화는 어느 계층에서 발생할까

HTTPS 사이트에 접속하면 브라우저는 먼저 대상 사이트와 TLS를 협상합니다. 핸드셰이크 과정에서 프로토콜 매개변수를 확인하고 사이트의 신원을 검증한 뒤 세션 키를 설정합니다. 이후 HTTP 요청과 응답은 TLS 레코드 계층에서 암호화됩니다. 요청이 프록시를 거치더라도 사이트와 브라우저 사이의 TLS 연결은 일반적으로 종단 간으로 유지됩니다.

프록시 클라이언트와 프록시 서버 사이에도 TLS 터널이 만들어지면 브라우저가 생성한 TLS 암호문이 바깥 터널의 페이로드가 됩니다. 클라이언트는 이미 암호화된 데이터를 한 번 더 암호화하고, 서버는 바깥쪽 암호화를 푼 다음 안쪽 암호문을 사이트로 전달합니다. 흔히 TLS over TLS라고 하지만 두 계층은 서로 다른 연결을 보호합니다.

중복 암호화는 암호 연산과 레코드 캡슐화, 메모리 복사 작업을 늘립니다. 다만 이것이 연결 지연의 주원인인 경우만 있는 것은 아닙니다. 웹페이지를 처음 열 때는 DNS 조회, 네트워크 왕복 시간, 패킷 손실, 서버 대기열도 영향을 줍니다. Vision은 특정 데이터 경로를 최적화하지만 이런 비용까지 모두 없애지는 못합니다.

• 내부 TLS: 브라우저와 대상 사이트 사이의 암호화입니다. 프록시 서버는 일반적으로 대상 사이트의 세션 키를 갖고 있지 않습니다.
• 외부 보안 전송: 클라이언트와 프록시 입구 사이를 보호합니다. REALITY는 이 구간의 핸드셰이크와 인증을 처리합니다.
• VLESS: 프록시 요청에서 사용자 식별 정보와 대상 주소 등을 전달합니다. 그 자체로 애플리케이션 데이터를 암호화하는 알고리즘은 아닙니다.

REALITY: 실제 사이트 인증서와 클라이언트 인증

REALITY는 Xray의 전송 보안 메커니즘입니다. 일반적인 설정에서는 실제 TLS 대상 사이트를 지정하고, 해당 사이트와 호환되는 서버 이름 및 핸드셰이크 특성을 선택합니다. 대상 사이트의 실제 핸드셰이크 정보와 인증서 외형을 활용해 프록시 입구가 일반적인 TLS 서비스에 가까운 방식으로 동작하게 하며, 사전 설정된 클라이언트에는 별도의 인증 경로를 제공합니다.

‘인증서를 빌린다’고 해서 인증서 파일 하나를 내려받아 아무 사이트나 사칭할 수 있는 것은 아니며, 프록시 서버가 대상 사이트의 개인 키를 얻는다는 뜻도 아닙니다. REALITY 클라이언트는 TLS 핸드셰이크를 처리하는 동시에 미리 설정된 공개 키 등의 정보로 해당 REALITY 서버를 검증합니다. 실제 사이트의 인증서는 사용자가 설정하는 공개 키를 대신하지 않습니다.

인증에 실패한 연결은 REALITY 설정과 구현에 따라 대상 사이트로 전달될 수 있지만, 모든 탐지에 똑같은 응답을 보장한다는 뜻은 아닙니다. 대상 사이트에 접속할 수 있는지, TLS 동작이 호환되는지, 입구 주소와 네트워크 경로의 특성이 어떤지에 따라 결과가 달라집니다. 대상 사이트를 잘못 선택했다면 클라이언트 지문만 바꿔서는 해결되지 않는 경우가 많습니다.

XTLS Vision: 언제 암호화 한 단계를 줄일 수 있을까

Vision에 해당하는 대표적인 flow 값은 xtls-rprx-vision입니다. 단순한 설정 태그가 아니라 초기 연결 데이터의 식별과 패딩, 이후 전달 방식을 포함합니다. 양쪽이 이 동작을 지원하고 올바르게 설정해야 하며, 클라이언트 항목만 바꾸면 연결이 실패할 수 있습니다.

조건을 충족하는 내부 TLS 1.3 트래픽을 식별하면 Vision은 핸드셰이크 이후 데이터 처리 경로를 전환해, 내부 TLS로 이미 보호되는 애플리케이션 데이터에 외부 TLS 레코드 암호화를 반복 적용하지 않을 수 있습니다. 대상 사이트의 TLS는 그대로 유지되고 브라우저도 인증서를 계속 검증합니다. 줄어드는 것은 해당 암호문을 프록시 계층에서 중복 처리하는 작업입니다.

1. 외부 연결 설정: 클라이언트는 먼저 프록시 서버와 보안 연결을 맺고 인증을 완료합니다. REALITY 매개변수 확인을 생략해서는 안 됩니다.
2. 프록시 요청 전송: VLESS가 사용자 정보와 대상 정보를 전달하고, Vision은 초기 데이터를 처리하면서 내부 프로토콜의 특성을 확인합니다.
3. 조건 충족 여부 확인: 식별되고 요구 조건을 충족하는 TLS 트래픽만 외부 암호화를 줄이는 경로로 처리될 수 있습니다.
4. 후속 데이터 전달: 내부 TLS 암호문은 계속 전송됩니다. 조건을 충족하지 않는 트래픽이 ‘평문으로 바로 전송된다’고 이해해서는 안 됩니다.

일반 HTTP, 식별할 수 없는 트래픽, UDP 및 QUIC이 사용하는 UDP 경로에는 ‘TLS 1.3 암호문 직접 전달’ 설명을 그대로 적용할 수 없습니다. TLS 1.2 트래픽도 같은 최적화 효과가 있다고 단정할 수 없습니다. 효율적인 경로가 실제로 적용되는지는 커널 구현과 전송 조합, 운영체제에도 영향을 받습니다.

프로토콜 수치: TLS 버전, 443 포트와 성능의 한계

아래 수치는 프로토콜과 일반적인 배포 설정을 설명하며, 이 글에서 측정한 속도 결과가 아닙니다. 이를 통해 ‘연결 입구가 무엇인지’와 ‘데이터가 어떻게 처리되는지’를 구분할 수 있지만, 특정 구독 노드의 실제 속도를 추정할 수는 없습니다.

대용량 파일을 전송할 때 클라이언트나 서버의 CPU가 한계에 도달하면 중복 암호화를 줄여 CPU 사용량을 낮추고 실제 처리량을 높일 수 있습니다. 일부 환경에서는 데이터 복사 작업을 더 효율적으로 처리할 수도 있습니다. 하지만 Mac 데스크톱 클라이언트와 서버의 시스템 기능은 다르므로, 특정 플랫폼의 제로카피 성능을 모든 기기에 그대로 적용할 수는 없습니다.

지연 시간 개선에도 조건이 있습니다. 부하가 높은 상황에서는 처리 오버헤드를 줄여 대기 시간이 짧아질 수 있지만, 유휴 연결에서 발생하는 작은 요청은 네트워크 왕복 시간이 여전히 큰 영향을 미칩니다. Vision은 압축 알고리즘이 아니며 프록시 서버와 대상 사이트 사이의 물리적 거리를 줄여 주지도 않습니다.

• CPU 사용량을 비교할 때는 클라이언트와 서버를 모두 확인하세요. 내 기기의 사용량만 줄고 서버가 병목이 되는 상황을 놓치지 않도록 해야 합니다.
• 처리량을 비교할 때는 같은 입구, 대상 리소스, 라우팅 규칙, 동시 연결 수를 사용하세요. 각 조건에서 최소 3회 반복 측정하고 결과를 기록합니다.
• 웹페이지 지연 시간을 비교할 때는 최초 연결과 재사용 연결을 구분하세요. DNS 캐시와 연결 재사용이 결과에 큰 영향을 줄 수 있습니다.
• 비교 테스트를 한다며 flow를 바로 삭제하지 마세요. 서버에서 각 설정에 맞는 구성을 제공해야 합니다. 그렇지 않으면 정상 연결과 잘못된 설정을 비교하게 됩니다.

v2rayN과 v2rayNG: 구독 가져온 뒤 설정 항목 확인

데스크톱에서 v2rayN을 사용한다면 먼저 구독을 가져와 그룹을 업데이트한 뒤 해당 노드의 편집 창에서 항목을 확인하세요. Android용 v2rayNG에서는 Xray 커널을 사용하므로 같은 개념의 설정을 살펴볼 수 있습니다. v2flyNG는 v2fly 커널을 사용합니다. 일부 VLESS 링크를 인식한다고 해서 Xray의 REALITY와 Vision 조합까지 지원한다고 단정해서는 안 됩니다.

버전에 따라 편집 화면과 번역, 내부 설정 항목의 이름이 달라질 수 있습니다. 따라서 아래에서는 특정 버전의 메뉴를 기준으로 삼지 않고 매개변수의 의미에 따라 확인 항목을 정리합니다. 공유 링크에서 자주 보이는 pbk는 REALITY 공개 키 정보에 해당합니다. 화면에 다른 이름으로 표시될 수도 있으니 현재 사용 중인 커널의 요구 사항을 기준으로 확인하세요.

공유 링크에는 encryption=none도 자주 표시됩니다. 이는 VLESS 프로토콜 계층의 설정을 뜻하며 연결 전체가 암호화되지 않는다는 의미는 아닙니다. REALITY가 외부 보안 전송을 담당하고 HTTPS 트래픽에는 내부 TLS도 적용됩니다. 항목을 더 ‘안전해’ 보이게 만들기 위해 프로토콜에서 지원하지 않는 값을 임의로 설정하지 마세요.

핸드셰이크 실패 또는 연결은 되지만 사이트가 열리지 않을 때

문제를 해결할 때는 먼저 세 단계로 나눠 확인하세요. 입구에 TCP로 연결할 수 있는지, REALITY 인증이 성공했는지, 애플리케이션 트래픽이 프록시로 들어가는지 살펴봅니다. 한 번에 한 항목만 바꾸고 해당 로그를 기록하세요. SNI, 포트, flow, 지문을 계속 바꾸면 원인을 찾기 어려워집니다.

로그에 TCP 연결 시간 초과가 표시되면 먼저 네트워크 경로와 입구의 연결 대기 상태, 방화벽 문제를 확인하세요. 인증이 끝난 뒤 특정 사이트만 문제가 생긴다면 해당 사이트의 DNS 조회 결과와 외부 연결 상태, 분할 라우팅 규칙을 살펴보세요. 모든 연결 오류를 REALITY 탓으로 돌리거나 설정 오류를 감추려고 전체 모드를 반복해서 전환하지 마세요.