REALITY와 XTLS Vision의 원리: VLESS 차세대 전송 방식은 왜 더 빠를까

VLESS·REALITY·Vision은 각각 어떤 계층일까

노드 이름에 표시되는 ‘VLESS + TCP + REALITY + Vision’은 서로 대체하는 네 가지 프로토콜이 아닙니다. 하나의 프록시 연결을 구성하는 서로 다른 설정을 나타냅니다. VLESS는 사용자 정보와 대상 주소를 전달하고, TCP는 바이트 스트림을 운반합니다. REALITY는 보안 핸드셰이크와 인증을 제공하며, Vision은 조건이 맞을 때 이후 데이터 경로를 최적화하는 VLESS의 흐름 제어 방식입니다.

VLESS 자체는 일반적인 의미의 페이로드 암호화를 제공하지 않습니다. 흔히 볼 수 있는 encryption=none 설정도 연결 전체가 평문으로 전송된다는 뜻은 아닙니다. REALITY를 사용하면 외부 계층의 보안 메커니즘이 연결을 보호합니다. ‘보안을 강화’하겠다며 VLESS 암호화 필드를 다른 프로토콜의 옵션으로 임의 변경하지 마세요.

이 글에서는 Xray의 VLESS + REALITY + Vision 조합을 다룹니다. v2rayN은 노드를 관리하고 코어를 실행하는 클라이언트이지, 이 조합 자체가 아닙니다. 연결 가능 여부는 프로그램 이름만으로 판단할 수 없으며 실제로 실행된 코어와 생성된 설정을 확인해야 합니다.

HTTPS 트래픽이 프록시를 통과할 때 중복 암호화는 어디서 생길까

브라우저가 HTTPS 사이트에 접속하면 대상 사이트와 TLS 세션을 맺습니다. 프록시는 대개 이미 암호화된 데이터를 전달할 뿐, 웹페이지 내용을 복호화하지 않습니다. 프록시 연결에도 TLS를 사용하면 클라이언트가 내부 TLS 데이터를 다시 감싸 암호화한 뒤 프록시 서버로 보내고, 서버는 바깥쪽 암호화를 해제할 수 있습니다.

여기에는 서로 다른 두 가지 보안 구간이 있습니다. 안쪽은 브라우저와 웹사이트 사이의 데이터를 보호하고, 바깥쪽은 클라이언트와 프록시 서버 사이의 전송을 보호합니다. 두 계층은 각각 역할이 있지만, 이미 암호화된 대용량 데이터를 다시 완전히 암호화하면 CPU 연산, 버퍼 처리, 데이터 복사 비용이 늘어납니다. 처리량이 높거나 프로세서 성능이 낮은 환경에서는 이런 비용이 병목이 되기 쉽습니다.

모든 요청이 이 방식으로 처리되는 것은 아닙니다. 일반 HTTP에는 웹사이트 TLS 계층이 없고, UDP 트래픽도 HTTPS 바이트 스트림과 같은 경로를 그대로 적용할 수 없습니다. 따라서 ‘이중 암호화 감소’가 모든 앱에서 일정한 비율의 속도 향상을 보장한다는 뜻은 아닙니다.

XTLS Vision은 데이터 전달 경로를 어떻게 최적화할까

Vision은 연결이 시작되자마자 보호 기능을 끄지 않습니다. 먼저 프로토콜 헤더와 초기 데이터를 처리하고 내부 TLS 상태를 확인합니다. 조건에 맞는 TLS 1.3 트래픽은 적절한 시점에 최적화된 데이터 경로로 전환해, 이미 암호화된 앱 데이터에 불필요한 외부 암호화를 반복하지 않도록 합니다.

1. 먼저 연결을 설정합니다. 클라이언트와 서버가 외부 보안 핸드셰이크를 완료하고 VLESS 사용자 정보와 대상 주소를 주고받습니다.
2. 그다음 트래픽을 식별합니다. Vision은 내부 TLS 핸드셰이크와 레코드 특성을 확인합니다. 초기 단계에서는 패딩을 사용해 초기 패킷의 특성도 조정합니다.
3. 조건이 맞을 때만 전환합니다. 최적화에 적합한 TLS 1.3 트래픽은 직접 전달 경로를 사용하며, 웹사이트 데이터는 내부 TLS가 계속 보호합니다.
4. 그 밖의 트래픽은 해당 방식으로 처리합니다. 조건을 충족하지 않으면 외부 암호화가 제거됐다고 단정할 수 없습니다. 실제 경로는 코어가 판단합니다.

‘직접 전달’이 특정 운영체제 수준의 제로카피 기능을 항상 사용한다는 뜻은 아닙니다. 복사를 더 줄일 수 있는지는 시스템, 연결 형태, 코어 구현에 따라 다릅니다. 설정에 xtls-rprx-vision이 있다고 해서 해당 흐름 제어가 활성화된 것은 맞지만, 모든 연결이 같은 고속 경로를 사용한다고 보장할 수는 없습니다.

REALITY는 어떻게 별도 인증서를 생략할까

일반적인 TLS 서버는 보통 자체 도메인에 인증서와 개인 키를 설치해야 합니다. REALITY는 다른 핸드셰이크와 인증 설계를 사용하고 대상 사이트의 TLS 핸드셰이크 특성을 활용해, 프록시 서버가 프록시 도메인용 공개 인증서를 일반적인 방식으로 발급받고 갱신할 필요를 없앱니다. 임의의 웹사이트 인증서를 서버에 복사해 사용하는 방식은 아닙니다.

클라이언트는 여전히 연결의 신뢰성을 검증해야 합니다. 일반적인 배포에서는 서버가 생성한 X25519 키 쌍을 사용합니다. 개인 키는 서버에만 보관하고 공개 키는 클라이언트에 전달합니다. 클라이언트에는 올바른 SNI와 Short ID 등의 설정도 필요합니다. Short ID는 연결 식별에 쓰이지만 키 인증을 대신하지 않으며, 유일한 로그인 비밀번호로 봐서도 안 됩니다.

• SNI: 서버에서 허용하는 서버 이름과 일치해야 합니다. 연결 주소는 IP일 수 있지만 SNI는 보통 도메인입니다. 둘은 서로 다른 필드입니다.
• 공개 키: 해당 노드의 서버 설정에서 받아야 합니다. 대상 웹사이트의 인증서 공개 키를 사용하거나 다른 노드의 키를 임의로 복사하면 안 됩니다.
• Short ID: 서버에서 허용하는 값과 일치해야 합니다. 16진수로 표시하며 길이도 설정에 따라 제한됩니다. 구독에서 받은 원래 값을 그대로 사용하는 것이 좋습니다.
• 지문: 클라이언트에서 흔히 chrome을 선택합니다. 해당 핸드셰이크 특성을 구성하는 옵션이지, 반드시 그 브라우저를 사용해야 한다는 뜻은 아닙니다.
• 시간: 기기의 시스템 시간을 정확하게 맞추세요. 서버에 시간 차이 제한이 설정돼 있다면 시계가 크게 어긋날 경우 인증에 실패할 수 있습니다.

서버는 핸드셰이크 대상도 설정합니다. 설정 이름은 target 또는 구버전의 dest로 표시될 수 있습니다. 대상 사이트는 적절한 TLS 기능을 제공하고 서버에서 접속할 수 있어야 하며, 잘못 선택하면 핸드셰이크에 영향을 줍니다. 인증에 실패한 연결은 대상 사이트로 전달될 수 있지만, 이것이 모든 네트워크 환경에서 프록시를 식별할 수 없다는 뜻은 아닙니다.

v2rayN 설정: 노드 이름을 추측하지 말고 필드별로 확인하세요

먼저 서비스 제공자가 준 전체 구독 링크나 공유 링크를 가져온 뒤 노드 편집 창을 여세요. 아래 두 카드는 하나의 연결에서 확인할 필드를 보여 주는 예시이며, 그대로 사용할 수 있는 노드 설정값이 아닙니다. 포트 443은 흔한 구성 예시일 뿐이므로 실제 값은 서버 설정을 따르세요.

v2rayN에서 ‘설정’ → ‘매개변수 설정’으로 이동해 로컬 수신 포트를 확인한 다음, 현재 노드에서 실제로 사용하는 코어를 확인하세요. 메뉴 세부 항목은 버전에 따라 달라질 수 있지만 로컬 포트와 원격 포트는 서로 다른 값입니다. 브라우저는 로컬 프록시 진입점에 연결하고, 코어가 노드의 원격 포트에 연결합니다.

Android에서 v2rayNG를 사용할 때도 VLESS, REALITY, Flow 설정과 코어 지원 여부를 확인해야 합니다. v2flyNG는 v2fly 코어를 사용하므로 이 글의 Xray 전용 조합을 범용 설정처럼 그대로 적용할 수 없습니다. 노드가 목록에 표시된다고 해서 현재 코어가 모든 기능을 지원한다는 뜻은 아닙니다.

지연 시간 숫자만 보지 않고 속도 향상을 확인하는 방법

프로토콜을 비교할 때는 가능한 한 같은 서버, 출구, 테스트 대상을 사용하세요. 서로 다른 지역의 서버 두 대를 비교하면 회선 차이가 프로토콜의 성능 효과로 잘못 계산될 수 있습니다. 일반 TCP 연결 테스트는 특정 포트에 연결할 수 있다는 점만 보여 줍니다. REALITY 인증 성공이나 Vision 최적화 경로 진입을 증명하지는 않습니다.

1. 조건을 동일하게 유지하세요: 클라이언트와 코어 버전, 노드 주소, 전송 방식, Flow, 시스템 프록시 상태를 기록하고 다른 다운로드 작업은 종료합니다.
2. 실제로 프록시를 거치는지 확인하세요: 로그에서 대상 연결과 라우팅 결과를 확인해 속도 측정 도메인이 직결 규칙에 걸리지 않도록 합니다.
3. 지표를 나눠 기록하세요: 웹페이지 첫 응답 시간, 지속 다운로드 속도, 클라이언트와 서버의 CPU 사용률을 기록하고 한 번 측정한 지연 시간만으로 전체 성능을 평가하지 마세요.
4. 여러 번 측정하세요: 각 조건에서 60초씩 3회 실행하고 중앙값을 비교합니다. 이는 권장 테스트 방법이며 이 글에서 직접 측정한 결과는 아닙니다.
5. 이상 결과를 살펴보세요: 속도가 떨어지면 패킷 손실, 서버 부하, 출구 속도 제한을 함께 확인하세요. CPU 사용률은 낮아졌는데 속도가 그대로라면 대역폭이 상한일 수 있습니다.

REALITY·Vision 연결 실패 시 자주 묻는 질문

문제 해결 순서는 로컬 진입점, 원격 포트, 인증 설정, 코어 호환성, DNS와 라우팅으로 유지한 뒤 마지막에 성능을 비교하세요. REALITY 배포 방식과 Vision의 데이터 전달 최적화로 특정 구간의 부담을 줄일 수 있지만, 실제 사용 가능 여부는 전체 연결 경로에 달려 있습니다.