REALITY와 XTLS Vision 원리: 자체 서명 인증서 없이 핸드셰이크하고 중복 암호화를 줄이는 방법

프로토콜 계층: VLESS, REALITY, Vision

먼저 결론부터 말하면, 일반적인 ‘VLESS + TCP + REALITY + Vision’은 여러 계층을 조합한 것이며 서로 바꿔 쓸 수 있는 네 가지 프로토콜 이름이 아닙니다. VLESS는 프록시 요청 형식과 사용자 인증 정보를 제공하고, TCP는 연결을 전달합니다. REALITY는 인증 기능을 갖춘 보안 연결을 설정하며, Vision은 Xray에서 특정 전송 방식과 함께 사용하는 흐름 제어 모드입니다.

VLESS 자체는 페이로드를 암호화하지 않습니다. 따라서 클라이언트에서 VLESS 암호화 항목이 none으로 표시되더라도 네트워크에 평문이 전송된다고 단정할 수는 없습니다. 외부 계층에서 REALITY나 TLS를 사용하는지, 애플리케이션 자체가 HTTPS를 사용하는지도 확인해야 합니다. VMess는 프로토콜 동작 방식이 다르므로 VLESS의 항목을 VMess 설정에 그대로 옮겨서는 안 됩니다.

REALITY 핸드셰이크와 자체 서명 인증서 없이 사용하는 방식

‘자체 서명 인증서 없이 사용한다’는 것은 일반적으로 프록시 서버가 기존 TLS 방식처럼 프록시 도메인용 인증서를 발급받아 갱신하거나, 사용자가 자체 서명 인증서를 수동으로 신뢰할 필요가 없다는 뜻입니다. 인증 절차를 생략하거나 인증서 관련 검사를 꺼도 된다는 의미는 아닙니다. REALITY는 자체 인증 설계를 사용하므로 클라이언트에 올바른 서버 공개 키와 기타 설정값이 있어야 합니다.

서버에는 핸드셰이크 대상으로 사용할 실제 TLS 사이트를 설정합니다. REALITY는 해당 사이트와 관련된 핸드셰이크 동작을 활용해 외부에서 정상적인 TLS 서비스처럼 보이도록 합니다. 올바른 인증 정보를 갖춘 클라이언트는 프록시 처리 경로로 연결됩니다. 인증 조건을 충족하지 못한 연결은 구현과 설정에 따라 대상 사이트로 전달될 수 있지만, 프록시 권한을 얻는 것은 아닙니다. ‘실제 사이트의 핸드셰이크를 빌린다’는 말은 동작을 간략히 설명한 것이며, 해당 사이트의 개인 키를 복사한다는 뜻이 아닙니다.

혼동하기 쉬운 주소가 두 가지 있습니다. 클라이언트는 프록시 서버 주소에 연결하고, serverName은 핸드셰이크에 사용하는 이름으로 서버에서 허용한 값이어야 합니다. 익숙한 웹사이트 도메인으로 임의 변경한다고 연결이 자동으로 성공하는 것은 아닙니다. 실제 대상 사이트도 프록시 서버를 대신하지 않습니다. 인증된 프록시 트래픽은 일반적으로 프록시 서버가 대상 서비스에 접속하며, 해당 사이트가 모든 트래픽을 중계하는 것은 아닙니다.

Vision 흐름 제어와 중복 암호화

HTTPS 사이트를 열면 브라우저와 웹사이트 사이에 이미 TLS 연결이 설정됩니다. 이 암호화 트래픽이 다시 TLS 계열 프록시 터널을 통과하면 암호화된 데이터가 한 겹 더 암호화되는 구조가 됩니다. 추가 레코드 캡슐화와 버퍼링, 암·복호화 처리로 CPU 사용량이 늘 수 있으며, 관찰 가능한 중첩 트래픽 특성이 생길 수도 있습니다.

Vision은 터널 내부의 TLS 핸드셰이크와 데이터 단계를 식별하고, 초기 단계에서 패딩 등의 처리를 합니다. 조건을 충족하는 내부 TLS 1.3 트래픽은 직접 복사 등의 최적화 경로로 전환해 외부 계층의 중복 처리를 줄일 수 있습니다. 모든 연결을 평문으로 바꾸는 기능도 아니고, 브라우저와 웹사이트 사이의 HTTPS를 해제하는 기능도 아닙니다. 애플리케이션과 웹사이트 간 종단 간 TLS는 계속 유지됩니다.

• 조건을 충족하는 HTTPS 트래픽: 중복 암호화를 줄이는 경로를 사용할 수 있습니다. 실제 효과는 커널 버전, 플랫폼, 연결 방식에 따라 달라집니다.
• 일반 평문 트래픽: ‘이미 HTTPS로 보호되고 있다’는 전제를 적용할 수 없으므로 외부 보안 계층으로 보호해야 합니다.
• UDP 및 기타 트래픽: TCP 내부 TLS의 최적화 결과를 그대로 적용할 수 없습니다. UDP 전송과 전달 지원 여부를 별도로 확인해야 합니다.
• WebSocket 등 다른 조합: 기존 노드에 Vision 항목만 추가한다고 작동하는 것은 아닙니다. 해당 커널이 지원하는 전체 조합을 확인해야 합니다.

따라서 ‘Vision은 암호화하지 않는다’보다 ‘Vision은 중복 암호화를 줄인다’가 정확한 설명입니다. 모든 연결과 모든 바이트가 같은 최적화 경로를 사용하는 것은 아닙니다. 흐름 제어 이름을 올바르게 입력하는 것은 해당 기능을 활성화하기 위한 조건일 뿐, 대역폭 향상을 보장하지 않습니다.

주요 수치와 클라이언트 설정 항목

아래 수치는 프로토콜을 이해하고 설정을 확인하기 위한 것으로, 속도 측정 결과가 아닙니다. 443은 흔히 사용하는 포트이지만 REALITY의 필수 포트는 아닙니다. 서버가 다른 포트에서 실제로 수신 대기 중이라면 클라이언트도 같은 포트로 설정해야 합니다. shortId는 16진수로 입력해야 하며, 길이는 커널 요구 사항에 맞고 서버에서 허용하는 값이어야 합니다.

기존 필드를 사용하는 Xray REALITY 설정에서 shortId는 최대 8바이트, 즉 16개의 16진수 문자이며 문자 수는 짝수여야 합니다. 빈 값을 허용하는지는 서버 설정에 따라 다르므로 인터페이스에서 비워 둘 수 있다는 이유만으로 구독에 포함된 값을 삭제하면 안 됩니다. 클라이언트에 공개 키 항목이 Public key 또는 커널 업데이트에 따라 달라진 이름으로 표시될 수 있으니, 구독 형식과 현재 커널 문서를 함께 확인하세요.

v2rayN에서는 먼저 현재 노드가 해당 조합을 지원하는 Xray 커널을 사용하는지 확인한 다음, 해당 VLESS 서버 설정을 편집하세요. v2rayNG도 Xray 커널을 사용하므로 노드 항목 전체가 필요합니다. v2flyNG는 V2Fly 커널을 사용하므로 인터페이스에서 VLESS를 가져올 수 있다는 이유만으로 Xray의 REALITY와 Vision을 지원한다고 판단해서는 안 됩니다. 클라이언트 버전, 커널 기능, 구독 파싱 기능은 각각 별도로 확인해야 합니다.

속도, 지연 시간, 안정성의 한계

REALITY의 주된 목적은 지리적 거리를 줄이는 것이 아니며, Vision이 서버 대역폭을 늘려 주지도 않습니다. 병목이 사용량이 많은 시간대의 혼잡, 지역 간 회선, 서버 출구 대역폭 제한에서 발생한다면 암호화 처리 부담을 일부 줄여도 변화가 뚜렷하지 않을 수 있습니다. CPU 사용률이 이미 한계에 가깝고 조건을 충족하는 HTTPS 장기 연결을 주로 사용하는 경우에 Vision의 리소스 절감 효과가 더 잘 드러날 수 있습니다.

1. 비교 조건을 동일하게 유지: 같은 기기, 네트워크, 테스트 파일, 비슷한 시간대를 사용하세요. 서버에서 실제로 비교 가능한 설정 두 가지를 제공하는 경우에만 프로토콜을 비교합니다.
2. 측정 항목을 구분: 연결 지연 시간, 웹페이지 첫 바이트 도달 시간, 지속 다운로드 속도는 서로 다른 지표입니다. 측정 방식을 기록하고 클라이언트에 표시된 한 번의 지연 시간만으로 전체 성능을 판단하지 마세요.
3. 기기 리소스도 기록: 테스트 중 CPU 사용률과 클라이언트 로그를 확인하세요. 기기 발열에 따른 성능 저하나 백그라운드 다운로드의 영향을 프로토콜 탓으로 돌리지 않도록 합니다.
4. 반복해서 측정: 각 설정을 최소 3회 테스트하고 실패와 시간 초과도 기록하세요. 가장 빠른 결과만 고르면 잘못 판단하기 쉽습니다.

안정성은 서버에서 핸드셰이크 대상까지의 연결 가능성, 대상 사이트의 TLS 동작, 시스템 시간, 양쪽 구현의 호환성에도 영향을 받습니다. REALITY는 연결이 보이는 방식을 바꿀 수 있지만 모든 네트워크 환경에서 계속 사용할 수 있다고 보장하지는 않습니다. 대상 사이트 선택은 서버 운영자가 관리할 영역이므로, 구독 사용자는 ‘회선 문제를 해결’하려고 로컬 serverName만 바꾸지 않는 것이 좋습니다.

연결 문제 해결과 자주 묻는 질문

확인하기 쉬운 항목부터 차례로 점검하세요. 주소와 포트, 사용자 ID, 전송 방식, 보안 계층, 흐름 제어, 공개 키, shortId, 핸드셰이크 이름을 확인한 다음 라우팅과 DNS를 살펴봅니다. 한 번에 하나만 변경하고 다시 연결해 보며, 원래 구독 설정은 비교용으로 보관하세요. 로그를 공유하기 전에는 구독 링크, 사용자 ID, 서버의 민감한 정보를 삭제하세요.

설정 선택 및 적용 순서

이미 사용할 수 있는 구독이 있다면 서버에서 제공한 설정 조합을 우선 유지하세요. 노드 이름에 REALITY나 Vision이 있는지만 보고 적합성을 판단해서는 안 됩니다. 클라이언트가 필요한 기능을 모두 지원하는지, 연결이 안정적인지, 자주 사용하는 앱이 정상 작동하는지, 실제 회선이 용도에 맞는지 확인해야 합니다.

• 먼저 커널 확인: REALITY와 Vision은 Xray의 지원 여부를 기준으로 선택하세요. Project V, V2Fly, Xray 계열이라는 이름만으로 완전한 호환이 보장되지는 않습니다.
• 그다음 전체 설정 가져오기: 신뢰할 수 있는 구독을 사용하고 서로 다른 노드의 공개 키, 사용자 ID, 핸드셰이크 이름을 섞지 마세요.
• 마지막으로 사용 경로 확인: 먼저 HTTPS 사이트 하나에 접속해 본 뒤 시스템 프록시, Tun, DNS, 라우팅 분할을 확인하세요.

규칙 적용 순서를 확인하려면 고급 설정을 참고하세요. 구독 가져오기와 기본 연결 방법은 입문 가이드의 구독 안내에서 확인할 수 있습니다. 여러 프로토콜 항목을 한꺼번에 바꾸기보다 반복해서 확인할 수 있는 기준 설정을 먼저 마련한 다음 하나씩 조정하면 문제를 찾기 쉽습니다.