REALITY와 XTLS Vision 원리: VLESS 전송이 더 빠른 이유

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

노드 이름에 ‘VLESS + TCP + REALITY + Vision’이 함께 적혀 있어도 서로 경쟁하는 네 가지 프로토콜을 뜻하는 것은 아닙니다. VLESS는 프록시 요청의 인증과 캡슐화를, TCP는 신뢰성 있는 바이트 스트림 전송을 담당합니다. REALITY는 외부 보안 연결을 처리하고, Vision은 Xray의 흐름 제어 모드로 내부 TLS 트래픽 중 최적화에 적합한 부분을 식별해 처리합니다.

이 흐름은 각 기능의 역할을 보여 주는 것으로, 모든 구현 단계가 엄격히 순차적으로 진행된다는 뜻은 아닙니다. 먼저 보안 핸드셰이크로 연결을 수립한 뒤 프록시 요청과 데이터가 전송됩니다. HTTPS 사이트에 접속하면 브라우저와 사이트 사이에도 별도의 TLS 연결이 만들어집니다. 외부 연결은 클라이언트와 프록시 서버 사이를 보호하고, 내부 연결은 브라우저와 목적지 사이트 사이의 데이터를 보호합니다.

• VLESS: UUID 등의 매개변수로 사용자를 식별합니다. VMess와 같은 페이로드 암호화 계층은 자체적으로 제공하지 않으며, 일반적으로 TLS 또는 REALITY와 함께 사용합니다.
• XTLS Vision: flow: "xtls-rprx-vision"에 해당합니다. TCP나 WebSocket을 임의로 바꿔 끼울 수 있는 전송 방식의 이름이 아닙니다.
• REALITY: streamSettings.security: "reality"에 해당하며, 일반적인 "tls"와는 다른 보안 설정입니다.
• Xray: 이 기능들이 구현된 코어입니다. 클라이언트에서 VLESS를 설정할 수 있다고 해서 현재 실행 중인 코어가 REALITY와 Vision을 지원하는 것은 아닙니다.

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

브라우저로 HTTPS 사이트에 접속하는 경우를 예로 들면, 애플리케이션 데이터는 먼저 사이트의 TLS로 암호화된 뒤 프록시 터널에 들어갑니다. 외부 터널에서도 모든 바이트를 다시 암호화하면 ‘암호화된 데이터의 재암호화’가 발생합니다. 이것이 항상 눈에 띄는 지연을 일으키는 것은 아니지만 암호 연산과 데이터 처리 부담을 늘립니다. 서버 CPU 사용량이 높거나 처리량이 많고 기기 성능이 제한적일수록 이 비용이 두드러질 수 있습니다.

Vision은 내부 TLS 트래픽의 단계를 살펴보고 시작 부분을 적절히 캡슐화하고 패딩합니다. 구현 조건을 충족하고 내부 TLS 1.3 암호화 데이터 단계에 진입한 것을 확인하면 최적화된 데이터 전송 경로로 전환해, 이미 암호화된 페이로드를 외부에서 반복 처리하는 일을 줄일 수 있습니다. 일부 환경에서는 더 효율적인 데이터 전달 방식도 활용할 수 있지만, 사용 여부는 운영체제와 연결 유형, 코어 구현에 따라 달라집니다.

따라서 ‘VLESS가 더 빠르다’는 말은 간단히 줄여 표현한 것입니다. 더 정확히는 같은 회선과 자원 조건에서 VLESS·Vision·보안 전송을 적절히 조합하면 캡슐화가 더 많거나 암호화가 중복되는 구성보다 처리 부담이 줄어들 수 있습니다. 병목이 저녁 시간대의 혼잡, 서버 속도 제한, 망 간 패킷 손실이라면 프로토콜 이름을 바꿔도 효과가 크지 않을 수 있습니다.

REALITY의 핸드셰이크와 인증 범위

REALITY는 TLS 1.3 메커니즘을 기반으로 보안 연결을 만들고, 특정 인증 정보를 핸드셰이크에 결합합니다. 클라이언트에는 서버에 해당하는 공개 키 정보와 허용된 서버 이름, shortId 등의 매개변수가 필요합니다. 일반적인 TLS 배포처럼 노드 도메인용 공개 신뢰 인증서를 발급받아 관리할 필요는 없지만, 대상 사이트와 서버 매개변수는 올바르게 설정해야 합니다.

조건에 맞는 클라이언트를 확인하면 서버는 프록시 연결을 수립합니다. 관련 인증을 통과하지 못한 연결은 REALITY 설계에 따라 설정된 대상 사이트로 전환됩니다. 이 대상은 핸드셰이크의 외관과 폴백 동작에 관여할 뿐, 일반적인 CDN 중계가 아니며 정상적인 프록시 페이로드가 계속 대상 사이트를 경유한다는 뜻도 아닙니다.

shortId는 서버 허용 목록에 등록된 짧은 식별자이며 UUID나 공개 키가 아닙니다. 비어 있지 않은 값은 16진수 문자로 이루어져야 하고, 길이는 짝수이며 16자를 넘을 수 없습니다. 클라이언트 값은 서버의 허용 항목과 일치해야 합니다. 빈 값을 사용할 수 있는지도 서버 목록에 따라 달라지므로, 문제 해결을 위해 임의로 비우지 마세요.

원리를 config.json 설정 항목에 적용하기

문제를 확인할 때는 ‘프록시 프로토콜 매개변수’와 ‘전송 보안 매개변수’를 먼저 구분하세요. 일반적인 Xray VLESS 아웃바운드 구조에서 flow는 사용자 객체에, security는 streamSettings에 속합니다. 두 항목을 같은 계층에 넣거나 VLESS의 encryption에 reality를 입력하는 것은 올바른 대체 설정이 아닙니다.

아래는 필드 위치를 보여 주는 일부 예시로, 완전한 노드 구성이 아니며 단독으로 실행할 수도 없습니다. 첫 번째는 VLESS 사용자 객체의 흐름 제어 필드, 두 번째는 전송 보안 객체를 보여 줍니다. 실제 구성에는 서버 주소와 포트, 사용자 정보, REALITY 인증 매개변수도 필요합니다.

{
  "encryption": "none",
  "flow": "xtls-rprx-vision"
}

{
  "security": "reality",
  "realitySettings": {
    "fingerprint": "chrome"
  }
}

• 필드 이름은 코어 버전에 따라 달라집니다: 예전 구성에서는 publicKey가 흔히 사용됐지만, 최신 코어 문서와 클라이언트에서는 password라는 이름을 사용할 수 있습니다. 사용 중인 코어에 맞춰 클라이언트에서 생성하고, 필드 이름만 보고 설정을 옮겨 조합하지 마세요.
• 전송 이름도 버전을 확인하세요: 기존 구성에서는 network: "tcp"가 흔하고, 최신 구성에서는 raw로 표시될 수 있습니다. 화면에 표시되는 이름이 바뀌었다고 다른 전송 방식을 임의로 추가해도 되는 것은 아닙니다.
• 핑거프린트와 서버 이름은 다릅니다: fingerprint는 클라이언트 핸드셰이크 특성을 설정하고, serverName은 SNI에 해당합니다. 두 값을 서로 바꿔 입력하면 안 됩니다.
• 공개 키와 개인 키를 혼용하지 마세요: 클라이언트에는 서버 공개 키에 해당하는 정보를 입력합니다. 서버 개인 키는 서버에 보관해야 하며 공유 링크나 스크린샷에 포함하면 안 됩니다.

객체 계층을 더 확인하려면 설정 참고 자료를 확인하세요. 구독을 사용하는 경우, 먼저 서비스 제공자가 전달한 전체 노드를 다시 가져온 다음 내보낸 유효 설정을 대조하는 편이 생성 파일을 직접 수정하는 것보다 안전합니다. 클라이언트가 다음 코어 실행 때 생성 파일을 덮어쓸 수도 있습니다.

v2rayN과 Android 클라이언트에서 항목별로 확인하기

데스크톱에서 v2rayN을 사용한다면 먼저 해당 노드를 REALITY와 Vision을 지원하는 Xray 코어가 실제로 실행하는지 확인하세요. Android용 v2rayNG는 Xray 코어를 사용하지만, 설치된 버전이 구독에 포함된 매개변수를 인식하는지도 확인해야 합니다. v2flyNG는 v2fly 코어를 사용하므로 VLESS를 인식한다는 이유만으로 Xray 전용 설정도 실행할 수 있다고 단정하면 안 됩니다.

1. 가져온 설정 확인: v2rayN 기본 화면에서 노드를 선택하고 마우스 오른쪽 버튼을 눌러 ‘편집’으로 이동한 뒤 주소, 포트, UUID, 흐름 제어, 전송 보안을 확인하세요. 화면의 항목 이름은 버전에 따라 달라질 수 있으므로 최종적으로는 내보낸 필드와 값을 기준으로 판단하세요.
2. 외부 보안 설정 확인: REALITY 노드에는 security=reality가, Vision 노드의 흐름 제어에는 xtls-rprx-vision이 설정되어야 합니다. ‘TLS’ 체크 항목을 모든 보안 모드에 공통으로 사용할 수 있는 대체 설정으로 여기지 마세요.
3. 프록시 적용 방식 확인: v2rayN 트레이 메뉴에서 ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 선택한 뒤 시스템 프록시를 따르는 브라우저로 테스트하세요. v2rayNG에서는 권한을 허용하고 시스템 VPN 연결을 시작했는지 확인해야 합니다.
4. 로컬 포트 확인: 예를 들어 로컬 프록시가 127.0.0.1:10808로 설정되어 있다면 애플리케이션의 포트와 프록시 유형이 실제 인바운드 설정과 일치해야 합니다. 10808은 예시일 뿐이며 현재 설정을 기준으로 확인하세요.
5. 로그는 필요한 만큼만 남기기: 웹페이지 접속을 한 번 테스트하고 시간과 오류 메시지를 기록한 뒤, 한 번에 한 항목씩 조정하세요. 로그를 공유하기 전에는 UUID와 구독 주소, 인증 매개변수를 가리세요.

‘더 빠르다’는 결과는 어떻게 측정할까

프로토콜을 비교할 때는 변수를 통제해야 합니다. 지역과 사업자가 다른 노드 두 개를 측정하면 결과에는 Vision의 처리 부담보다 회선 차이가 먼저 반영됩니다. 가능하면 같은 서버와 대역폭 제한, 비슷한 라우팅을 유지하고 비교할 전송 방식만 바꾸세요. 조건을 맞출 수 없다면 결과를 ‘노드 사용 경험 비교’라고 표현하고 프로토콜의 차이로 단정하지 마세요.

1. 기기와 네트워크, 테스트 대상, 시간을 동일하게 맞추고 백그라운드 다운로드를 종료하세요. 각 구성에서 3회 측정하고 중앙값을 기록합니다.
2. 같은 100 MiB 테스트 파일을 사용해 첫 바이트 대기 시간과 안정적인 다운로드 속도를 각각 기록하세요. 순간 최고 속도만 보지 마세요.
3. 서버의 CPU 사용률과 송신 대역폭을 함께 확인하세요. 송신 대역폭이 이미 포화 상태이고 CPU 사용률은 낮다면, 암호화 부담을 줄여도 처리량이 더 늘어나기 어렵습니다.
4. 테스트 사이에 간격을 두어 연속 다운로드로 대상 사이트의 속도 제한이 걸리지 않게 하세요. 자주 사용하는 웹페이지도 테스트해 대용량 파일 결과에 상호작용 지연이 가려지지 않았는지 확인합니다.

예를 들어 100 MiB 파일을 10초에 받았다면 평균 속도는 약 10 MiB/s, 환산하면 약 83.9 Mbps입니다. 단위 환산을 보여 주는 예시일 뿐 실제 측정 결과는 아닙니다. 클라이언트는 MB/s, 속도 측정 사이트는 Mbps로 표시할 수 있으니 차이를 판단하기 전에 단위를 통일하세요. 프록시 캡슐화와 연결 수립, 측정 시간 범위도 수치에 영향을 줍니다.

REALITY와 Vision 관련 자주 묻는 질문