REALITY와 XTLS Vision 작동 원리: VLESS 전송 방식은 왜 더 빠를까?

VLESS, REALITY, Vision: 이름은 세 가지지만 역할도 세 가지

노드 목록의 “VLESS + REALITY + Vision”은 프록시 프로토콜 세 개를 겹쳐 쓰는 구성이 아닙니다. VLESS는 프록시 프로토콜이고, REALITY는 보안 계층 방식이며, Vision은 Xray의 흐름 제어 모드 중 하나로 설정값은 보통 xtls-rprx-vision입니다. 이 아래에는 전송 채널도 필요합니다. 흔히 TCP를 사용하며, 일부 최신 인터페이스나 설정에서는 이 전송 방식을 RAW로 표시합니다.

가장 쉽게 이해하는 방법은 “목적지 주소를 어떻게 전달하는가”, “상대의 신원을 어떻게 확인하는가”, “이후 데이터를 어떻게 운반하는가”를 구분하는 것입니다. VLESS 요청에는 사용자 식별 정보와 목적지 정보가 담기지만, UUID가 모든 내용을 암호화하는 비밀번호는 아닙니다. 일반적인 설정에서 VLESS의 encryption=none은 이 계층에서 별도 암호화를 하지 않는다는 뜻이지, 연결 전체가 평문으로 전송된다는 뜻은 아닙니다.

여기서는 Xray 구현을 다룹니다. v2rayN은 여러 코어를 사용할 수 있으므로 해당 노드가 이 조합을 지원하는 Xray로 실제 실행되는지 확인해야 합니다. v2rayNG는 Xray 코어를 사용합니다. v2flyNG는 V2Fly 코어를 사용하므로 일부 VLESS 정보를 가져올 수 있다는 이유만으로 Xray의 REALITY와 Vision까지 호환된다고 볼 수는 없습니다. 구독에 노드가 표시되는 것과 코어가 연결을 지원하는 것은 별개의 문제입니다.

TLS 위에 TLS: 암호화가 중복되는 지점

브라우저가 HTTPS 웹사이트에 접속하면 브라우저와 대상 웹사이트 사이에 TLS 연결이 설정됩니다. 프록시는 보통 이 HTTPS 내용을 복호화하지 않고 바이트만 전달합니다. 브라우저 트래픽을 TLS로 보호되는 프록시 터널에 다시 넣으면 같은 데이터가 웹사이트 연결에서 한 번 암호화되고, 프록시 터널에서 또 암호화될 수 있습니다. 흔히 말하는 “내부 TLS”와 “외부 TLS”가 이런 구조입니다.

위 흐름은 각 구성 요소의 역할을 보여 주며 모든 핸드셰이크가 반드시 순차적으로 진행된다는 뜻은 아닙니다. 연결을 설정할 때 클라이언트와 프록시 서버는 핸드셰이크 정보를 주고받고, 프록시 서버는 대상 웹사이트에도 연결해야 합니다. 일부 중복 암호화 작업을 줄여도 네트워크 왕복 시간, 웹사이트 응답 시간, TCP 패킷 손실과 재전송 비용은 여전히 발생합니다.

• 내부 보호: 브라우저와 대상 웹사이트 사이의 TLS가 웹사이트 내용을 보호합니다. 프록시 서버가 전달하는 것은 보통 암호화된 레코드입니다.
• 외부 보호: 로컬 클라이언트와 프록시 서버 사이의 보안 채널이 프록시 요청과 채널 내부 데이터를 보호합니다.
• 추가 비용: 중복 암·복호화, 레코드 캡슐화, 버퍼 처리와 데이터 복사에 CPU 자원과 처리량이 소모될 수 있습니다.
• 최적화의 한계: TLS가 아닌 트래픽에는 “내부에서 이미 암호화되었으니 외부 처리를 줄여도 된다”는 판단을 그대로 적용할 수 없습니다.

따라서 Vision의 성능 향상은 HTTPS 데이터를 지속해서 전송하고 클라이언트나 서버의 처리 능력이 병목인 상황에서 더 잘 나타날 수 있습니다. 회선 대역폭이 낮거나 저녁 시간대에 패킷 손실이 심하다면 캡슐화 방식을 바꿔도 혼잡이 저절로 해결되지는 않습니다.

XTLS Vision: 트래픽 식별, 패딩, 직접 전송 최적화

Vision은 프록시가 전달하는 내부 TLS 트래픽을 살펴보고, 연결 초기에 프로토콜에서 정한 패딩을 적용한 뒤 이후 데이터가 최적화 조건을 충족하는지 판단합니다. 구현이 식별할 수 있고 조건을 만족하는 내부 TLS 암호화 애플리케이션 데이터는 전용 직접 전송 경로로 처리할 수 있어 외부의 중복 암호화와 일부 버퍼 처리를 줄입니다.

“직접 전송”은 프록시 서버를 우회한다는 뜻도, HTTPS를 복호화해 평문으로 만든다는 뜻도 아닙니다. 데이터는 여전히 클라이언트, 프록시 서버, 대상 웹사이트를 거쳐 이동하며 불필요한 중복 처리를 줄이는 것입니다. 또한 연결의 첫 바이트부터 보안 계층을 완전히 없앤다는 의미도 아닙니다. 핸드셰이크와 프록시 요청, 직접 전송 조건을 충족하지 않는 데이터에는 각각 필요한 보호 및 처리 절차가 적용됩니다.

1. 먼저 보안 연결을 설정합니다. 클라이언트와 서버가 보안 매개변수를 확인하고, VLESS 요청으로 사용자와 목적지 정보를 전달합니다.
2. 초기 트래픽을 처리합니다. Vision은 초기 데이터에 패딩을 적용하고 내부 TLS 핸드셰이크와 레코드를 식별합니다.
3. 조건을 충족할 때만 최적화합니다. 구현 요건을 충족하는 내부 암호화 애플리케이션 데이터만 직접 전송 경로를 사용합니다. 모든 바이트가 예외 없이 같은 지름길을 거치는 것은 아닙니다.
4. 그 밖의 트래픽은 보호를 유지합니다. 식별할 수 없거나 조건을 충족하지 않는 트래픽은 해당 경로에 따라 처리하며, 암호화된 데이터로 간주해 강제로 전달하지 않습니다.

Vision에는 일부 트래픽 특성을 줄이기 위한 설계도 포함되어 있지만, 연결을 식별할 수 없게 하거나 항상 사용할 수 있다는 뜻은 아닙니다. 대상 웹사이트 선택, 네트워크 환경, 서버 설정과 코어 구현이 모두 결과에 영향을 줍니다. 속도와 연결 가용성은 별도로 측정해야 하며, 한 번의 속도 측정만으로 장기적인 성능을 판단해서는 안 됩니다.

REALITY: 별도 인증서가 필요 없지만 인증을 없애지는 않음

일반적인 TLS 서버는 자체 도메인에 인증서를 설치하고 갱신해야 합니다. REALITY를 일반적인 방식으로 배포하면 프록시 서버 자체 도메인에 이 인증서를 신청할 필요가 없습니다. 대신 대상 웹사이트의 TLS 특성과 별도의 인증 메커니즘을 조합해 연결을 설정합니다. 클라이언트 설정의 서버 공개 키, ServerName, Short ID는 각각 실제 역할이 있으므로 정상적으로 보이는 도메인만 입력해서는 안 됩니다.

REALITY 서버는 개인 키를 보유하고, 클라이언트는 서버가 제공한 해당 공개 키 등의 매개변수로 연결을 확인합니다. 특정 웹사이트의 인증서가 보인다는 이유만으로 프록시 서버를 신뢰하는 방식이 아닙니다. 인증 조건을 충족하지 않는 연결은 보통 서버 설정에 따라 대상 웹사이트로 전달됩니다. 그렇다고 인증된 사용자의 모든 트래픽이 반드시 그 웹사이트를 거친다는 뜻은 아닙니다.

• 주소와 포트: 실제 프록시 서버를 가리켜야 합니다. 서버가 수신 대기하는 포트를 입력해야 하며, 무조건 443으로 바꾸면 안 됩니다.
• ServerName: 인터페이스에서 SNI로 표시되는 경우가 많습니다. 서버가 허용하는 이름을 사용해야 하며 노드 접속 주소와 다를 수 있습니다.
• 공개 키: 서버에서 제공한 해당 값을 사용합니다. 개인 키는 서버에 보관해야 하며 클라이언트의 공개 키 항목에 개인 키를 넣어서는 안 됩니다.
• Short ID: 서버에서 허용하는 값과 일치해야 합니다. 빈 값을 허용하는지는 실제 서버 설정에 따라 다릅니다.
• 지문: 예를 들어 chrome은 TLS ClientHello의 모방 특성을 선택합니다. 클라이언트 전체가 브라우저로 바뀌는 것은 아닙니다.

대상 웹사이트의 TLS 호환성, 접속 가능 여부, 응답 동작은 모두 서버에서 확인해야 합니다. ServerName을 무작위로 바꾸는 것은 신뢰할 수 있는 해결책이 아닙니다. 시스템 시간도 인증 판단에 영향을 주므로 시간 오차가 크다면 먼저 시스템 시간 동기화를 켠 뒤 다시 연결하세요.

v2rayN과 v2rayNG: 이름만 보고 설정하지 말고 항목별로 확인

기존 구독을 통해 완전한 노드 설정을 가져오는 것이 좋습니다. 직접 수정할 때는 먼저 보안 계층을 확인한 다음 Flow, 전송 방식, ServerName, 공개 키, Short ID를 점검하세요. 아래 두 카드는 보안 계층이 다른 일반적인 조합을 비교한 것으로, 그대로 복사해 실행할 수 있는 완성된 노드 설정이 아닙니다. 주소, 사용자 식별 정보, 인증 매개변수는 서버에서 제공한 값을 사용해야 합니다.

1. 데스크톱에서 노드 확인. v2rayN 노드 목록에서 대상 VLESS 노드를 두 번 클릭하고 프로토콜, 전송 방식, 보안 계층, Flow를 하나씩 확인하세요. 해당 노드가 이 기능을 지원하는 Xray 코어를 사용하는지도 확인해야 합니다. 버전에 따라 항목 이름이 조금 다를 수 있습니다.
2. 로컬 프록시 확인. v2rayN에서 「설정」→「매개변수 설정」으로 이동해 로컬 수신 포트 관련 항목을 확인하세요. 예를 들어 클라이언트가 실제로 127.0.0.1:10808에서 수신 대기한다면, 애플리케이션의 수동 프록시 설정에도 해당 주소, 포트, 프록시 유형을 입력해야 합니다. 여기서 10808은 확인을 위한 예시이며 모든 설치 환경의 고정값은 아닙니다.
3. Android에서 항목 확인. v2rayNG 노드 목록에서 대상 노드의 편집 화면을 열고 전송 방식, 보안 설정, 흐름 제어를 확인하세요. 저장한 뒤 노드를 다시 선택하고 연결을 시작해 다른 설정을 테스트하는 일이 없도록 합니다.
4. 진입 경로와 출구 경로 구분. 데스크톱 시스템 프록시 설정이나 Android VPN 연결은 앱 트래픽이 클라이언트로 들어오는지를 결정합니다. 노드의 보안 매개변수는 프록시 연결을 설정할 수 있는지를 결정하고, 라우팅 규칙은 트래픽이 프록시와 직접 연결 중 어느 경로를 사용할지 결정합니다.

REALITY 연결 오류를 해결하려고 인증서 검증 건너뛰기를 켜거나 공개 키를 삭제하거나 Short ID를 임의로 바꾸지 마세요. 이런 변경은 올바른 서버 매개변수를 대신하지 못하고 문제 진단을 더 어렵게 만들 수 있습니다. 설정 화면을 공유할 때는 구독 주소, 사용자 식별 정보 등 민감한 항목을 가리세요.

속도 저하와 연결 오류: 비교 테스트로 원인 찾기

“왜 더 빠른가?”라는 질문에는 작동 원리로 답할 수 있지만 모든 회선에서 같은 결과를 보장할 수는 없습니다. Vision과 다른 조합을 비교할 때는 가능한 한 같은 서버와 비슷한 시간대, 같은 대상 리소스를 사용하고 최초 연결 지연, 지속 다운로드 처리량, CPU 사용량을 구분해 측정하세요. 서로 다른 지역의 노드 두 개는 프로토콜 이름이 다르더라도 유효한 프로토콜 성능 비교가 아닙니다.

• 조건 통일: 네트워크, 대상 리소스, 라우팅을 동일하게 유지하고 백그라운드 다운로드를 중지하세요. 테스트할 앱의 트래픽이 실제로 대상 노드를 통과하는지도 먼저 확인해야 합니다.
• 항목별 기록: 최초 요청 시간은 밀리초로, 지속 처리량은 MB/s 또는 Mbit/s로 기록하고 단위를 명시하세요. 두 단위의 수치는 약 8배 차이가 나므로 혼용하면 안 됩니다.
• 반복 측정: 각 조합에서 30초간 전송을 3회 진행하고 중앙값과 큰 변동을 기록하세요. 이는 권장 테스트 방법이며, 이 글에서 측정한 결과가 아닙니다.
• 리소스 확인: 클라이언트와 서버의 CPU 사용량을 함께 확인하세요. CPU 사용률이 거의 최대치라면 중복 처리 감소가 도움이 될 수 있습니다. 처리량은 낮은데 CPU 여유가 있다면 회선과 대상 서비스부터 확인하세요.

마지막으로 세 가지 질문을 따로 확인해야 합니다. 보안 핸드셰이크가 완료되는지, 앱 트래픽이 올바른 출구를 사용하는지, 지속 전송에서 처리 비용이 줄었는지입니다. REALITY는 일반적인 배포에서 별도 인증서를 관리할 필요를 줄이고, Vision은 적합한 내부 TLS 트래픽의 중복 처리를 줄이며, VLESS는 프록시 요청을 전달합니다. 설정 항목이 정확하고 코어가 호환되며 테스트 조건이 동일해야 현재 네트워크에 이 조합이 적합한지 판단할 수 있습니다.