REALITY 프로토콜과 XTLS Vision 흐름 제어 원리: 중복 암호화를 줄이면 속도가 빨라지는 이유

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

흔히 쓰는 ‘VLESS + TCP + REALITY + Vision’은 설정 조합이지, 서로 바꿔 쓸 수 있는 네 가지 프로토콜 이름이 아닙니다. VLESS는 프록시 요청과 사용자 식별 정보를 처리하고, TCP는 전송 연결을 제공하며, REALITY는 보안 계층을 담당합니다. Vision은 xtls-rprx-vision으로 지정하는 흐름 제어 방식입니다. UUID만 올바르게 입력했다고 보안 계층과 흐름 제어까지 맞게 설정된 것은 아닙니다.

여기서는 Xray의 구현 방식을 다룹니다. v2rayN은 데스크톱 설정 관리 클라이언트이며 특정 코어와 같은 뜻이 아닙니다. 이 조합을 사용하려면 실제로 이를 지원하는 Xray 코어를 실행해야 합니다. Android용 v2rayNG는 Xray 코어를 사용합니다. v2flyNG는 v2fly 코어를 사용하므로 일부 VLESS 링크를 가져올 수 있다는 이유만으로 이 조합 전체를 지원한다고 볼 수는 없습니다.

TLS 중첩: HTTPS 데이터가 다시 암호화되는 이유

브라우저로 HTTPS 사이트에 접속하면 브라우저와 사이트 사이에 이미 TLS 연결이 설정됩니다. 이 요청을 프록시에 전달하면 일반적인 TLS 프록시 터널은 암호화된 데이터를 한 번 더 감쌉니다. 따라서 클라이언트와 프록시 서버 사이에는 ‘외부 TLS 안에 내부 TLS가 들어 있는’ 데이터가 오갈 수 있습니다.

내부 TLS는 프록시 서버를 지난 뒤에도 유지되며 대상 웹사이트에 도달해야 종료됩니다. 프록시 서버는 보통 웹사이트 세션 키를 갖고 있지 않고, 웹 페이지 내용을 복호화할 필요도 없습니다. 외부 TLS는 클라이언트와 프록시 서버 사이의 연결을 보호해 암호화되지 않은 프록시 요청이나 기타 트래픽이 그대로 노출되지 않도록 합니다. 두 계층은 보호하는 구간이 다르므로 어느 한쪽을 ‘쓸모없다’고 단정할 수 없습니다.

• 연산 비용: 이미 암호화된 데이터를 다시 암호화하고 복호화합니다. 처리량이 많거나 프로세서 성능이 낮을수록 부담이 두드러질 수 있습니다.
• 캡슐화 비용: TLS 레코드에는 헤더와 인증 태그가 붙고 버퍼 처리도 필요합니다. 암호화 알고리즘을 한 번 더 실행하는 것만이 비용의 전부는 아닙니다.
• 트래픽 패턴: 내부·외부 핸드셰이크와 데이터 길이의 관계가 관찰 가능한 패턴을 만들 수 있습니다. 포트만 바꿔서는 이를 없앨 수 없습니다.

따라서 ‘핸드셰이크 지연이 낮다’고 해서 다운로드 속도도 반드시 빠른 것은 아닙니다. 핸드셰이크는 연결 설정에 관한 지표이고, 지속적인 다운로드 속도는 대역폭, 패킷 손실, 혼잡 제어, CPU에도 영향을 받습니다. 중복 암호화는 여러 변수 중 하나일 뿐입니다.

Vision은 중복 암호화를 어떻게 줄이고 어떤 보호를 유지할까

Vision은 모든 데이터를 평문으로 보내는 기능이 아닙니다. 내부 TLS의 핸드셰이크와 데이터 단계를 식별하고, 연결 초기에 오가는 트래픽에 패딩을 적용합니다. 조건에 맞는 내부 TLS 1.3 트래픽을 감지하면 더 직접적인 전달 경로로 전환해, 이미 TLS로 보호되는 데이터에 외부 암호화를 계속 덧씌우지 않도록 합니다.

전환 후에도 웹 페이지 내용은 브라우저와 웹사이트 사이의 TLS로 보호됩니다. 식별 조건에 맞지 않는 트래픽이 ‘직접 전달 경로로 전환됐다’고 볼 수는 없으며, 해당 트래픽은 적절한 보안 전송 경로를 거쳐야 합니다. 특히 일반 HTTP, TLS를 사용하지 않는 앱, UDP 요청은 노드에 Vision이 설정돼 있다는 이유만으로 같은 최적화가 적용된다고 단정할 수 없습니다.

여기서 말하는 ‘흐름 제어’는 대역폭 제한이 아닙니다. xtls-rprx-vision을 사용해도 100 Mbps 요금제가 더 빨라지거나 인터넷 회선 혼잡이 해결되지는 않습니다. 특정 트래픽의 추가 처리 부담을 줄이고 일부 TLS 중첩 패턴을 개선하는 것이 목적이며, 실제 효과는 연결 상태에 따라 달라집니다.

REALITY 핸드셰이크: 공개 키, SNI, 대상 사이트의 연동 방식

REALITY는 보안 핸드셰이크와 인증을 담당합니다. TLS 핸드셰이크 구조에 서버 키와 클라이언트 설정의 인증 정보를 결합해, 정식 클라이언트가 서버를 확인하고 보호된 연결을 맺도록 합니다. 프록시 접속 지점에 기존 웹사이트 TLS 방식으로 공개 신뢰 인증서를 발급받아 설치할 필요는 없습니다.

그렇다고 ‘아무 도메인이나 입력해도 된다’는 뜻은 아닙니다. 서버에서 대상 사이트와 허용할 서버 이름을 설정하므로 클라이언트 SNI가 서버 설정과 맞아야 합니다. 공개 키는 서버의 개인 키와 짝을 이뤄야 합니다. SNI는 핸드셰이크에 포함되는 이름 정보이지 노드 서버 주소를 대신하지 않으며, 아무 웹사이트나 프록시 서버로 바꾸는 기능도 아닙니다.

1. 연결 주소: 먼저 클라이언트에서 노드가 제공한 IP 또는 도메인과 포트로 연결합니다. 예를 들어 서비스 제공자가 지정한 443에 연결해야 하며, SNI에 해당하는 웹사이트에 직접 연결하는 것이 아닙니다.
2. 핸드셰이크 매개변수: 지정된 서버 이름, 지문, REALITY 인증 정보를 클라이언트에 입력합니다. 각 항목은 같은 노드 설정에서 가져와야 합니다.
3. 인증 처리: 서버는 인증에 성공한 요청을 식별해 프록시 연결을 설정합니다. 인증 조건에 맞지 않는 연결은 REALITY의 동작 방식에 따라 설정된 대상 사이트로 전달될 수 있습니다.
4. 프록시 요청: 보안 계층이 설정된 다음 VLESS 사용자를 확인하고 대상 연결을 처리합니다. Vision을 설정한 경우 이후 트래픽 식별도 이뤄집니다.

클라이언트 입력 항목: 두 그룹을 따로 확인하세요

먼저 제공자가 안내한 전체 링크나 구독을 가져온 뒤 항목을 확인하세요. 직접 입력하려면 v2rayN에서 ‘서버’ → ‘VLESS 서버 추가’를 선택해 설정하거나 기존 노드의 편집 창을 여세요. v2rayNG에서는 오른쪽 위 ‘＋’를 눌러 VLESS 설정을 직접 입력할 수 있습니다. 버전에 따라 메뉴 이름과 위치가 달라질 수 있으므로 화면 위치만 보지 말고 각 항목의 의미에 맞춰 설정하세요.

shortId는 16진수 문자열이며, 보통 16자를 넘지 않고 길이는 짝수여야 합니다. 빈 값을 허용하는지는 서버 설정에 따라 다릅니다. 임의로 0을 채우거나 여기에 UUID를 입력하지 마세요. 클라이언트에는 서버에 대응하는 공개 키 인증 매개변수만 필요하며 서버 개인 키를 클라이언트에 전달해서는 안 됩니다.

• 암호화 항목 확인: 일반적인 VLESS 설정의 encryption=none은 연결 전체가 보호되지 않는다는 뜻이 아닙니다. 이 글에서 다루는 조합은 REALITY가 보안 계층을 담당합니다.
• 로컬 포트 확인: v2rayN의 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 항목을 확인하세요. 실제 포트가 10808이라면 브라우저나 테스트 도구도 해당 포트에 연결해야 합니다. 다른 곳에 나온 포트를 그대로 사용하지 마세요.
• 실행 중인 코어 확인: 시작 로그에서 실제로 Xray가 실행됐는지 확인하고 코어 버전도 기록하세요. 클라이언트 버전과 코어 버전은 서로 다릅니다.
• 링크 인코딩 확인: 매개변수가 포함된 공유 링크는 전체를 복사해 채팅 앱이 물음표 뒤의 내용을 잘라내지 않도록 하세요. 구독 주소와 단일 노드 링크는 각각 해당하는 가져오기 메뉴에서 불러와야 합니다.

속도 비교 테스트: 지연 시간으로 처리량을 판단하지 마세요

‘중복 암호화를 줄이면 속도가 빨라지는지’를 확인하려면 비교 가능한 조건이 필요합니다. 가능하면 같은 서버에서 설정 두 개를 받아 관찰할 변수 하나만 바꿔 테스트하세요. 서버 지역, 전송 방식, 라우팅까지 함께 바꾸면 차이가 Vision 때문인지 판단할 수 없습니다. 서버를 직접 관리할 수 없다면 테스트 결과는 두 노드의 전반적인 사용 경험을 비교한 것에 불과합니다.

1. 경로 고정: 같은 기기와 네트워크, 다운로드 대상을 사용하세요. 요청이 프록시 규칙을 따르는지 확인해 한 번은 직접 연결하고 다른 한 번은 프록시를 사용하는 일이 없도록 하세요.
2. 접속 지점 고정: 두 테스트 모두 같은 로컬 프록시 포트를 사용하세요. 다른 다운로드 작업은 먼저 중지해 백그라운드 트래픽이 대역폭을 나눠 쓰지 않도록 합니다.
3. 반복 측정: 각 설정으로 60초씩 연속 3회 테스트하고, 테스트 순서는 번갈아 진행하세요. 평균 처리량, CPU 사용률, 실패 횟수를 각각 기록합니다.
4. 단위 통일: 100 Mbps는 이론상 12.5 MB/s입니다. 실제 속도는 프로토콜 오버헤드에도 영향을 받습니다. 두 단위로 표시된 값을 그대로 비교하지 마세요.
5. 로그 보관: 테스트 시간, 코어 버전, 노드 설정 유형, 오류 정보를 기록하세요. 공유하기 전 UUID, 구독 주소 등 접속 정보는 삭제해야 합니다.

테스트 횟수와 시간은 권장 방식일 뿐, 이 사이트에서 직접 측정한 결과가 아닙니다. 처리량이 비슷하더라도 CPU 사용량이 줄었다면 리소스 부담이 개선됐을 수 있습니다. 처음 연결하는 데 걸리는 시간만 줄었다면 지속적인 다운로드 속도가 빨라졌다고 볼 수 없습니다. 핸드셰이크와 설정 항목은 프로토콜 참고 자료의 REALITY 설명에서 더 확인할 수 있습니다.

REALITY와 Vision 자주 묻는 질문