REALITY와 XTLS Vision 원리: 암호화 한 단계 줄이면 빨라지는 이유

먼저 세 가지 용어부터: VLESS, REALITY, Vision

v2rayN이나 v2rayNG에서 흔히 보는 노드 조합은 “VLESS + REALITY + XTLS Vision”입니다. 세 가지는 서로 바꿔 쓸 수 있는 프로토콜 이름이 아닙니다. VLESS는 프록시 요청에 사용자 인증 정보와 대상 주소를 담는 방식을 정의하고, REALITY는 연결의 보안 핸드셰이크와 인증을 담당합니다. Vision은 Xray의 흐름 제어 기능으로, 터널 안에서 일부 데이터를 처리하는 방식을 결정합니다. 이 세 계층을 구분해야 오류가 났을 때 어떤 항목부터 확인할지 알 수 있습니다.

VLESS의 encryption에는 보통 none이 사용됩니다. 이는 VLESS 프로토콜 자체에서 페이로드 암호화를 추가하지 않는다는 뜻이지, 연결 전체가 평문으로 전송된다는 뜻은 아닙니다. REALITY를 사용하면 연결 설정 과정에 보안 계층이 계속 관여하며, 브라우저가 HTTPS 사이트에 접속할 때는 애플리케이션의 TLS 암호화도 유지됩니다.

프록시로 HTTPS를 이용할 때 암호화가 두 겹이 되는 이유

브라우저에서 HTTPS 사이트를 열면 먼저 대상 사이트와 TLS 핸드셰이크를 진행합니다. 이후 웹 페이지 본문, 로그인 정보, 응답 내용은 애플리케이션 계층의 TLS 암호문이 됩니다. 프록시는 이 연결을 대상 사이트까지 전달할 뿐, 사이트 세션을 복호화하는 키를 얻는 것은 아닙니다.

프록시 터널 자체도 TLS를 사용하면 브라우저에서 생성된 암호문이 프록시 연결의 TLS 레코드에 한 번 더 담깁니다. 클라이언트가 바깥쪽을 암호화하고 서버가 이를 복호화한 뒤, 안쪽 암호문을 웹사이트로 전달합니다. 이런 ‘이중 캡슐화’는 흔하고 필요한 경우도 있지만, 트래픽이 많으면 암복호화와 버퍼 처리, 데이터 복사에 추가 비용이 발생합니다.

Vision의 핵심은 HTTPS를 없애는 것이 아니라 내부 TLS의 단계를 식별하고, 조건이 맞을 때 이후 데이터의 전달 방식을 바꾸는 데 있습니다. TLS 1.3 트래픽으로 인식되면 적절한 단계에서 직접 전달 모드로 전환해 이미 암호화된 애플리케이션 데이터가 바깥쪽 TLS 암복호화를 다시 거치지 않도록 할 수 있습니다. 초기 핸드셰이크와 필요한 프록시 정보는 여전히 보호해야 하므로, 연결되자마자 모든 데이터를 암호화 없이 보내는 것은 아닙니다.

• 웹사이트 측 암호화는 그대로 유지됩니다: 브라우저는 계속 대상 웹사이트의 인증서를 검증하며, 프록시 때문에 사용자가 사이트 인증서 검증을 끌 필요는 없습니다.
• 최적화에는 식별 조건이 필요합니다: 모든 TCP 데이터나 모든 TLS 버전이 같은 최적화 경로를 이용할 수 있는 것은 아닙니다.
• 일반 HTTP가 HTTPS로 바뀌지는 않습니다: Vision은 애플리케이션과 대상 웹사이트 사이에 종단 간 암호화를 추가하지 않습니다.
• 핸드셰이크 단계에서는 패딩도 적용됩니다: Vision은 초기 단계의 데이터에 패딩을 적용하므로 “모든 패킷이 더 작아진다”고 요약할 수 없습니다.

REALITY가 실제 사이트의 핸드셰이크 외관을 활용하는 방식

일반적인 TLS 프록시 서비스는 보통 자체 도메인과 인증서를 준비해야 합니다. REALITY는 다른 방식으로 설계되었습니다. 서버는 적절한 실제 TLS 대상을 설정하고, 클라이언트는 사전에 약속된 인증 매개변수를 담아 핸드셰이크를 시작합니다. 인증에 성공하면 클라이언트와 REALITY 서버 사이에 프록시 채널이 만들어집니다. 인증되지 않은 연결은 서버가 설정된 대상으로 전달해 실제 사이트와 정상적으로 TLS 통신하는 것처럼 처리할 수 있습니다.

‘실제 사이트를 활용한다’는 표현은 이해를 돕기 위한 말입니다. 해당 사이트의 개인 키를 갖고 있다는 뜻도, 프록시 트래픽 전체가 먼저 그 사이트를 거친다는 뜻도 아닙니다. 인증에 성공한 뒤에는 서버가 대상 주소에 따라 프록시 데이터를 전달합니다. 설정된 실제 사이트는 주로 핸드셰이크 외관과 인증되지 않은 연결 처리에 관여합니다. 클라이언트가 REALITY 서버를 신뢰하는 근거도 대상 사이트의 공개 인증서를 단순히 로컬에 복사하는 방식이 아닙니다.

서버 주소, SNI, 실제 대상은 서로 다른 항목

• 서버 주소: 클라이언트가 실제로 연결하는 프록시 서버의 IP 주소 또는 도메인입니다. 핸드셰이크 대상인 웹사이트 주소로 임의 변경하면 안 됩니다.
• SNI / Server Name: 클라이언트가 핸드셰이크에서 사용하는 이름으로, 서버에서 허용하는 값이어야 합니다. 서버 주소에 연결할 수 있어도 이 항목이 올바르다는 뜻은 아닙니다.
• 서버 측 실제 대상: 서버 관리자가 선택합니다. TLS 1.3, HTTP/2 등의 호환 조건을 확인하고, 서버에서 대상 사이트까지의 지연 시간과 접속 가능 여부도 고려해야 합니다.
• 클라이언트 지문: chrome 같은 값으로 ClientHello 구성에 영향을 줍니다. 올바른 키, SNI, 인증 정보를 대신하지 않으며 실제 브라우저의 모든 동작과 완전히 같다고 보장하지도 않습니다.

v2rayN과 v2rayNG에서 확인할 설정 항목

신뢰할 수 있는 구독 링크에서 노드 전체 설정을 가져온 다음, 노드 편집 화면에서 각 항목을 확인하세요. 클라이언트 버전에 따라 메뉴 이름은 달라질 수 있지만 프로토콜, 전송 방식, 보안 계층, Flow의 의미는 같습니다. 아래 두 카드에는 같은 연결의 양쪽 설정을 대조해 두었으며, 그대로 복사해 쓸 수 있는 완성 노드 설정은 아닙니다. 포트 443은 흔히 쓰는 예시일 뿐이므로 실제 서버의 수신 포트를 기준으로 해야 합니다.

REALITY의 키 매개변수는 클라이언트 인터페이스와 Xray 설정 버전에 따라 이름이 다를 수 있습니다. 이전 설정에서는 publicKey를 흔히 사용했고, 최신 설정에서는 password를 사용할 수 있습니다. 항목 이름만 보고 JSON을 직접 옮기지 말고, 실제로 실행 중인 코어의 문서와 클라이언트의 가져오기 규칙을 따르세요. 서버 개인 키는 일반 사용자에게 절대 전달해서는 안 됩니다.

Short ID는 16진수 문자열을 사용합니다. 비어 있지 않다면 글자 수는 짝수여야 하며 최대 16자입니다. 빈 값을 허용하는지는 서버 설정에 따라 다릅니다. 사용자 ID나 임의로 입력하는 메모가 아닙니다. 구독에 Short ID가 포함되어 있다면 원래 값을 유지하세요. 한 글자만 임의로 바꿔도 인증에 실패할 수 있습니다.

암호화 한 단계가 줄면 빨라질 수 있는 이유와 꼭 그렇지만은 않은 이유

암호화가 성능 비용의 전부는 아니지만 처리량이 높은 연결에서는 큰 부담이 될 수 있습니다. Vision은 조건을 충족하는 데이터의 중복 암복호화를 줄이고, 구현이 허용하는 경우 더 효율적인 전달 경로를 활용해 CPU 사용량과 데이터 복사 부담을 낮춥니다. 서버에서 대용량 연결을 여러 개 처리할 때는 짧은 웹 요청보다 이런 개선 효과가 더 뚜렷하게 나타날 수 있습니다.

병목이 모바일 네트워크의 패킷 손실, 서버의 외부 대역폭, 통신사 혼잡 또는 대상 웹사이트의 속도 제한에 있다면 암호화 한 단계를 줄여도 다운로드 속도가 달라지지 않을 수 있습니다. TCP 혼잡 제어는 그대로 적용되며, REALITY가 회선의 물리적 대역폭을 늘려 주는 것도 아닙니다. 특정 노드 하나가 빠르다고 해서 “모든 REALITY 노드가 다른 조합보다 빠르다”고 결론 내릴 수는 없습니다.

비교 가능한 테스트를 하는 방법

1. 같은 기기, 네트워크, 서버, 다운로드 대상을 사용하고 다른 대용량 작업은 중단하세요. Wi-Fi 신호 변화가 프로토콜 성능 차이로 잘못 계산되지 않도록 합니다.
2. 서버에서 명시적으로 지원하는 두 가지 테스트 설정을 사용하세요. 비교를 위해 Flow 항목을 단순히 비우지 말고, 클라이언트와 서버 설정이 서로 일치하는지 확인해야 합니다.
3. 각 설정에서 60초 동안 연속으로 다운로드하고 3회 반복하세요. 평균 처리량, 클라이언트 CPU, 서버 CPU, 연결 오류를 함께 기록합니다.
4. 대용량 파일과 웹페이지 첫 로딩을 각각 테스트하세요. CPU 사용량만 줄고 처리량이 그대로라면 최적화는 작동했지만 현재 속도 병목은 다른 곳에 있을 수 있습니다.

연결에 실패하면 핸드셰이크 단계별로 확인하세요

‘핸드셰이크 실패’는 보안 연결이 완료되지 않았다는 뜻일 뿐, 인증서 문제라고 단정할 수는 없습니다. REALITY 인증 매개변수 불일치, 허용되지 않은 SNI, 접속할 수 없는 서버 대상, 기기의 시간 오차 등도 연결 실패를 일으킬 수 있습니다. 먼저 TCP 연결이 가능한지 확인하고, 다음으로 REALITY 인증을 점검한 뒤, 마지막으로 VLESS 사용자와 Flow를 확인하세요. 암호화 옵션을 계속 바꾸는 것보다 효과적인 방법입니다.

1. 먼저 연결 주소를 확인하세요: 클라이언트가 핸드셰이크 대상이 아닌 프록시 서버에 연결하는지 확인합니다. 로그에 연결 시간 초과나 연결 거부가 표시되면 수신 포트, 방화벽, 네트워크 접속 가능 여부를 점검하세요.
2. 다음으로 시스템 시간을 확인하세요: Windows의 ‘설정’ → ‘시간 및 언어’ → ‘날짜 및 시간’에서 자동 시간 설정과 동기화 상태를 확인합니다. 안드로이드에서도 날짜 및 시간 자동 설정을 켜야 합니다. REALITY는 서버 정책에 따라 허용되는 시간 오차를 제한할 수 있습니다.
3. 인증 매개변수를 대조하세요: SNI, 클라이언트 인증 키 매개변수, Short ID를 하나씩 확인합니다. 서버에서 키를 변경했다면 주소가 그대로여도 이전 구독을 더 이상 사용할 수 없을 수 있습니다.
4. 사용자와 Flow를 확인하세요: VLESS 사용자 ID가 서버에 등록되어 있고 양쪽이 호환되는 Vision 설정을 사용하는지 확인합니다. REALITY 보안 계층 옵션과 Flow 항목을 혼동하지 마세요.
5. 실제로 사용하는 코어를 확인하세요: v2rayN에서 현재 해당 조합을 지원하는 Xray 코어를 사용하는지 확인합니다. 인터페이스에서 노드를 저장할 수 있다고 해서 선택한 코어가 모든 항목을 지원한다는 뜻은 아닙니다.
6. 마지막으로 대상과 전달 경로를 확인하세요: 핸드셰이크에 성공했지만 페이지가 열리지 않으면 서버 DNS, 아웃바운드 라우팅, 대상 접속 가능 여부, 클라이언트에서 해당 트래픽을 프록시로 보내는지 확인합니다.