REALITY·XTLS Vision 원리와 속도 개선: 핸드셰이크 위장과 중복 암호화 줄이기

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

‘VLESS + TCP + REALITY + Vision’은 네 가지 계층으로 나눠 볼 수 있습니다. VLESS는 사용자 식별 정보와 요청 대상 등을 전달하는 프록시 프로토콜이며, 자체적으로 전송을 암호화하지는 않습니다. TCP는 연결을 전달하는 전송 방식이고, REALITY는 보안 핸드셰이크와 인증을 제공합니다. Vision은 프록시 데이터를 캡슐화하고 전달하는 방식을 제어하는 XTLS 흐름 제어 모드입니다.

따라서 REALITY는 단독으로 가져와 사용할 수 있는 완성된 노드가 아니며, Vision도 서버 주소만 바꾸면 켜지는 가속 옵션이 아닙니다. 클라이언트와 서버가 같은 조합을 지원해야 합니다. Xray와 V2Ray는 같은 코어가 아니므로 이름이 비슷하다고 설정 항목을 그대로 서로 바꿔 쓸 수는 없습니다.

이 흐름은 논리적인 처리 단계를 보여 줄 뿐, 각 단계마다 네트워크 왕복이 한 번씩 더 발생한다는 뜻은 아닙니다. 라우팅으로 출구를 선택한다는 것은 클라이언트가 요청을 직접 연결할지 특정 프록시 노드에 전달할지 판단하는 과정입니다. 해당 노드를 실제로 통과하는 트래픽만 그 노드의 REALITY 및 Vision 설정을 사용합니다. 사이트에 직접 연결했을 때의 속도로 노드 프로토콜 성능을 판단할 수는 없습니다.

REALITY의 ‘핸드셰이크 활용’은 무엇을 활용하는 걸까?

먼저 핵심부터 말하면, 실제 사이트의 개인 키를 빌리거나 대상 사이트가 프록시 서버 대신 데이터를 복호화하는 방식은 아닙니다. 여기서 ‘활용’은 핸드셰이크 외관과 전달 방식을 쉽게 설명하기 위한 표현입니다. 이해할 때는 인증 정보가 유효한 클라이언트 연결과 일반 접속 또는 인증에 실패한 연결을 구분해야 합니다.

1. 클라이언트가 핸드셰이크를 시작합니다. 클라이언트는 프록시 서버의 주소와 포트에 연결하고 설정에 따라 TLS ClientHello를 보냅니다. SNI는 핸드셰이크에서 선언하는 서버 이름이며, 클라이언트 지문은 핸드셰이크 메시지가 구성되는 방식에 영향을 줍니다.
2. REALITY 서버가 인증 정보를 확인합니다. 인증된 클라이언트는 설정된 공개 키 등의 매개변수를 사용해 인증 및 키 협상에 참여하고, 서버는 이에 대응하는 개인 키로 핸드셰이크를 처리합니다. Short ID는 추가로 확인하는 매개변수이며 사용자 식별 정보를 대신하는 비밀번호가 아닙니다.
3. 인증된 연결은 프록시 처리를 시작합니다. 인증이 성공하면 양측이 보호된 연결을 설정한 뒤 VLESS 요청을 처리합니다. 브라우저가 최종적으로 접속하는 사이트는 핸드셰이크에 선언된 이름과 다를 수 있습니다.
4. 인증에 실패한 연결은 대상 사이트로 전달될 수 있습니다. 서버는 설정에 따라 이런 트래픽을 실제 TLS 사이트로 전달해 일반 사이트처럼 응답하도록 합니다. 구체적인 동작은 구현 방식, 대상 사이트, 네트워크 상태에 따라 달라집니다.

일반적으로 서버는 이 방식에 사용되는 이름의 공개 인증서와 개인 키를 보유할 필요가 없지만, 자체 REALITY 키 쌍은 올바르게 설정해야 합니다. 클라이언트에는 공개 키를 제공하며 서버 개인 키를 구독 정보에 넣어서는 안 됩니다. 실제 대상 사이트의 핸드셰이크 동작이 바뀌면 연결에 영향을 줄 수 있으므로, 이 방식을 언제나 같은 외관을 유지하는 고정 설정으로 이해해서는 안 됩니다.

포트 번호는 서버가 연결을 수신하는 위치일 뿐, 프로토콜을 증명하지 않습니다. 노드 포트가 443이라고 해서 반드시 REALITY를 사용하는 것은 아닙니다. 실제 사이트가 TLS 1.3을 지원하더라도 모든 서버 환경에서 대상 사이트로 적합한 것은 아닙니다. 일반 구독 사용자는 제공된 설정을 유지하고, 대상 사이트를 임의로 바꿔 가며 시험하지 않는 것이 좋습니다.

XTLS Vision은 중복 암호화를 어떻게 줄일까?

브라우저로 HTTPS 사이트에 접속하면 브라우저와 사이트 사이에 이미 TLS 암호화가 적용됩니다. 이 암호화된 데이터를 프록시의 외부 TLS로 한 번 더 통째로 감싸면 추가 캡슐화와 처리가 발생합니다. 이런 ‘TLS 안의 TLS’도 정상적으로 동작하지만 연산, 복사, 레코드 처리 비용이 늘어날 수 있습니다.

Vision은 내부 TLS 트래픽을 식별하고 조건을 충족하면 더 직접적인 전달 경로로 전환해, 이미 암호화된 애플리케이션 데이터를 외부에서 다시 암호화하는 처리를 줄이는 데 초점을 둡니다. 초기 데이터에 패딩을 적용해 특정 길이 패턴을 완화하기도 합니다. 브라우저의 HTTPS를 끄거나 웹 페이지 데이터를 평문으로 전송하는 기능은 아닙니다.

이 과정을 ‘모든 데이터의 암호화가 한 번 줄어든다’고 단순화해서는 안 됩니다. 최적화 경로를 사용할 수 있는지는 내부 프로토콜과 구현의 판단에 달려 있습니다. TLS가 아닌 데이터가 내부 TLS의 보호를 받는 데이터로 바뀌는 것도 아닙니다. 직접 전달이 운영체제의 저복사 기능까지 활용할 수 있는지는 플랫폼, 커널, 연결 조건에 따라 달라지며 Flow를 입력했다고 반드시 제로 카피가 되는 것은 아닙니다.

클라이언트에서 확인할 설정 항목

데스크톱에서는 v2rayN 노드 목록에서 해당 노드를 선택하고 마우스 오른쪽 버튼을 눌러 ‘편집’을 선택한 다음 프로토콜, 전송 방식, 보안 유형, Flow를 확인합니다. 버전에 따라 편집 창에서 항목을 묶는 방식이 다를 수 있으니 노드 메모만 보지 말고 각 필드의 이름을 확인하세요. Android에서는 v2rayNG 노드 카드를 눌러 편집 아이콘을 선택하고 해당 항목을 확인합니다. 구독 노드는 먼저 구독 정보를 새로고침해 설정을 가져오고, 직접 수정하기 전에는 비교할 수 있도록 사본을 만들어 두세요.

• 주소와 포트: 연결할 서버를 지정합니다. 도메인을 사용하면 DNS 조회도 필요하며, SNI가 서버 주소를 대신하지는 않습니다.
• 서버 이름: SNI 또는 Server Name으로 표시되는 경우가 많으며, 서버에서 허용한 값을 사용해야 합니다. 도메인이 브라우저에서 열린다고 해서 현재 노드에도 사용할 수 있는 것은 아닙니다.
• 공개 키와 Short ID: 복사 과정에서 문자가 빠지지 않도록 구독 정보를 항목별로 그대로 유지하세요. Short ID와 UUID는 서로 다른 필드이므로 바꿔 입력하면 정상적으로 인증되지 않습니다.
• 지문: 예를 들어 chrome은 핸드셰이크 지문 옵션일 뿐, 반드시 해당 브라우저를 사용해야 한다는 의미는 아닙니다. 프록시 클라이언트가 보내는 핸드셰이크에 영향을 주는 설정이며 브라우저 확장 프로그램 설정이 아닙니다.
• Flow: 서버가 해당 흐름 제어를 사용할 때만 xtls-rprx-vision을 입력하세요. VMess 노드에 이 값을 추가하거나 WS 경로를 Flow로 입력하지 마세요.

커널도 확인해야 합니다. v2rayNG는 Xray 커널을 사용하므로 해당 조합을 지원할 수 있습니다. v2flyNG는 v2fly 커널을 사용하므로 REALITY 및 Vision 노드와 동등한 실행 환경으로 볼 수 없습니다. v2rayN에서 여러 커널 설정을 지원한다면 클라이언트가 실행 중인지 여부만 확인하지 말고, 현재 노드가 해당 매개변수를 지원하는 Xray 커널에서 실제로 실행되는지 확인하세요.

REALITY와 Vision을 적용해도 속도가 나아지지 않을 수 있는 이유

두 기능은 서비스 제공업체의 대역폭을 늘리거나 다른 네트워크 구간의 혼잡을 해결하지 못합니다. 장거리 연결의 왕복 시간, 저녁 시간대의 패킷 손실, 서버 부하, 노드 속도 제한, 기기의 처리 성능이 중복 암호화 비용보다 더 큰 영향을 줄 수 있습니다. 병목이 외부 회선 대역폭에 있다면 암호화 처리를 줄여도 다운로드 속도가 회선 한계를 넘을 수는 없습니다.

1. 먼저 테스트 조건을 통일하세요. 같은 기기와 접속 네트워크, 같은 다운로드 파일을 사용하고 다른 다운로드 작업은 중지하세요. 지역과 통신사가 다른 두 노드를 비교해 특정 흐름 제어가 더 빠르다는 근거로 삼기는 어렵습니다.
2. 트래픽이 프록시를 통과하는지 확인하세요. v2rayN 메인 화면의 ‘시스템 프록시’에서 ‘시스템 프록시 자동 설정’을 선택한 다음 라우팅 모드를 확인합니다. 시스템 프록시는 해당 설정을 따르는 앱에만 영향을 주며 모든 프로그램의 트래픽을 자동으로 처리하지는 않습니다.
3. 지연 시간과 처리량을 따로 확인하세요. 연결이 안정적으로 설정되는지, 지속 다운로드 속도가 변하는지, 로그에 연결 재시도가 반복되는지 기록하세요. 지연 시간이 낮다는 것은 대기 시간이 짧을 수 있다는 뜻이지 다운로드 대역폭이 크다는 의미는 아닙니다.
4. 한 번에 하나씩만 변경하세요. 비교가 필요하다면 서버에서 명확히 지원하는 두 설정을 사용하세요. 클라이언트에서 Flow만 삭제한 뒤 인증 실패를 성능 저하로 판단해서는 안 됩니다.

핸드셰이크 오류와 자주 생기는 오해

로그 오류는 문제를 좁히기 위한 단서이지 원인을 하나로 확정하는 결론이 아닙니다. EOF, 시간 초과, 연결 재설정이 나타나면 발생 단계를 살펴보세요. 먼저 서버에 연결됐는지 확인하고, 다음으로 핸드셰이크 성공 여부를 확인한 뒤, 마지막으로 프록시 요청이 완료됐는지 확인합니다. 로그를 공유하기 전에는 구독 주소와 사용자 식별 정보 등 인증 정보를 가리세요.