이 글은 구독을 가져올 줄 알고 VLESS + REALITY + XTLS Vision의 작동 방식을 이해하고 싶은 독자를 위한 내용입니다. REALITY와 Vision의 역할을 구분하고 속도 향상의 원인, 클라이언트 매개변수 확인법, 성능 병목과 핸드셰이크 실패를 점검하는 방법을 다룹니다.
TLS 핸드셰이크와 중복 암호화는 어디서 발생할까
일반 HTTPS 사이트에 접속하면 클라이언트는 먼저 서버와 TCP 연결을 맺은 뒤 TLS 핸드셰이크를 시작합니다. 이 과정에서 TLS 버전, 암호화 스위트, 서버 이름과 임시 키를 협상하고 서버가 제공한 인증서를 검증합니다. 핸드셰이크가 끝난 뒤에야 브라우저가 보내는 HTTP 데이터가 암호화 채널로 들어갑니다. 새로운 TCP 및 TLS 연결에는 보통 여러 차례의 네트워크 왕복이 필요하므로 회선 지연 시간이 높을수록 첫 페이지 로딩이 더 느리게 느껴집니다.
프록시 프로토콜이 외부에 TLS를 한 겹 더 씌우고 애플리케이션 자체도 HTTPS라면 '내부 HTTPS 데이터를 외부 암호화 채널에 넣는' 구조가 됩니다. 단순히 데이터를 두 번 암호화한다는 뜻은 아닙니다. 각 계층이 애플리케이션 연결과 프록시 전송을 따로 보호하지만, 외부 계층에서는 레코드 캡슐화, 암복호화, 버퍼 복사와 연결 상태 처리 작업이 추가됩니다. 고속 다운로드, 성능이 낮은 기기 또는 동시 연결이 많은 환경에서는 이러한 추가 작업이 CPU 사용량과 속도 차이로 나타나기 쉽습니다.
기존 VLESS + TCP + TLS는 서버가 도메인과 일치하는 인증서를 보유하고 인증서 갱신과 도메인 해석을 올바르게 처리해야 합니다. VLESS + REALITY도 TLS와 유사한 핸드셰이크를 수행하지만 인증 방식과 배포 모델이 다릅니다. XTLS Vision은 데이터 전송 계층에 위치해 직접 전송에 적합한 암호화 트래픽을 식별합니다. 둘은 같은 기능이 아니며 REALITY를 단순한 '가속 스위치'로 이해해서도 안 됩니다.
REALITY는 핸드셰이크와 신원 인증을 어떻게 처리할까
REALITY는 Xray 생태계의 전송 보안 방식으로, VLESS·TCP·Vision과 함께 사용하는 경우가 많습니다. 서버는 자체 공개 도메인 인증서를 준비할 필요 없이, 서버 위치에서 정상적으로 접속할 수 있고 적절한 TLS 특성을 갖춘 실제 대상 사이트를 선택합니다. 클라이언트가 핸드셰이크 매개변수를 보내면 서버는 REALITY 개인 키, 클라이언트 설정의 공개 키, Short ID와 시간 정보를 바탕으로 요청의 유효성을 판단합니다.
- 클라이언트가 핸드셰이크 구성: 설정의 Server Name, REALITY 공개 키, Short ID와 브라우저 지문으로 요청을 만들고 구독에 지정된 서버 주소와 포트에 연결합니다.
- 서버가 인증 수행: 서버는 개인 키로 클라이언트 매개변수를 확인합니다. 공개 키와 개인 키는 서로 짝이 맞아야 하며 Short ID는 서버에서 허용한 값이어야 합니다.
- TLS 외형 형성: 핸드셰이크 동작은 대상 사이트의 TLS 특성을 참고하므로 네트워크에서 관찰되는 연결 형태가 일반적인 TLS 접속과 비슷해집니다.
- VLESS 세션 진입: 인증이 통과되면 연결이 VLESS 데이터를 전달하며,
xtls-rprx-vision이 설정된 경우 이후 트래픽은 Vision이 처리합니다. - 예상과 다른 요청 처리: REALITY 인증 조건을 충족하지 못한 연결은 프록시 세션으로 진입하지 않으며, 서버는 설정에 따라 대상 사이트 연결로 처리합니다.
'실제 사이트의 핸드셰이크를 빌린다'는 표현은 핸드셰이크 특성과 대상 선택을 설명하는 말입니다. 대상 사이트의 개인 키를 얻는다는 뜻도 아니고 프록시 서버가 대상 사이트의 HTTPS 내용을 복호화한다는 의미도 아닙니다. 클라이언트가 최종적으로 신뢰하는 것은 REALITY 공개 키에 대응하는 서버의 신원입니다. Server Name만 복사하고 올바른 공개 키나 Short ID를 빠뜨리면 연결은 여전히 실패합니다.
VLESS + REALITY + Vision
- 네트워크
- TCP
- 보안
- reality
- Flow
- xtls-rprx-vision
- 포트
- 443
- 지문
- chrome
구독을 가져온 뒤에는 공개 키, Short ID, Server Name과 Flow를 그대로 유지해야 하며 서버 주소만 복사해서는 안 됩니다.
VLESS + WebSocket + TLS
- 네트워크
- WebSocket
- 보안
- tls
- 경로
- /ws
- 포트
- 443
- 인증서
- 도메인 일치
이는 다른 배포 방식입니다. 도메인, 인증서와 WebSocket 경로에 의존하므로 Vision의 Flow를 그대로 적용해서는 안 됩니다.
XTLS Vision은 어떻게 추가 처리를 줄일까
XTLS Vision은 VLESS의 Flow 모드이며 설정값은 xtls-rprx-vision입니다. 프록시 연결이 수립된 뒤 어떤 데이터를 외부 레코드 형식으로 계속 완전히 캡슐화해야 하는지, 어떤 조건을 충족하는 TLS 트래픽을 더 직접적인 전송 경로로 보낼 수 있는지를 판단합니다. 일반적인 웹, 동영상과 다운로드는 대부분 HTTPS를 사용하므로 이러한 데이터가 Vision 최적화의 주요 대상입니다.
| 비교 항목 | 일반 TLS 캡슐화 | XTLS Vision |
|---|---|---|
| 프로토콜 조합 | VLESS 외부 계층이 TLS 레코드 처리를 계속 담당 | VLESS Flow가 내부 TLS 트래픽을 식별 |
| 데이터 복사 | 일반적으로 더 많은 버퍼링, 캡슐화와 레코드 처리 과정을 거침 | 조건을 충족하면 중복 데이터 이동을 줄일 수 있음 |
| CPU 부담 | 고속 전송에서 외부 계층 처리가 더 뚜렷함 | 대용량 트래픽에서 사용량을 낮추기 쉬움 |
| 적용 프로토콜 | 다양한 TLS 조합에 사용 가능 | Flow는 VLESS 설정에만 적용되며 VMess에는 사용하지 않음 |
| 호환성 요구 사항 | 선택한 전송 및 보안 계층에 따라 달라짐 | 클라이언트와 서버의 Xray 기능이 일치해야 함 |
Vision은 HTTPS 암호화를 끄지 않으며 애플리케이션 데이터가 공개 인터넷을 평문으로 통과하게 만들지도 않습니다. 브라우저와 대상 사이트 사이의 TLS 보호는 계속 유지되고 REALITY가 담당하는 핸드셰이크 인증도 그대로 적용됩니다. 최적화는 데이터 경로와 캡슐화 방식에서 이루어지며, 이미 암호화된 연속 데이터를 불필요하게 중복 처리하지 않는 것이 목표입니다.
모든 연결이 즉시 직접 전송 경로로 들어가는 것은 아닙니다. Vision은 초기 데이터를 확인하고 TLS 레코드를 식별한 뒤 자체 흐름 제어 규칙을 적용해야 합니다. 일반 평문 TCP, 식별할 수 없는 페이로드 또는 조건을 충족하지 않는 연결은 기존 방식으로 전달됩니다. 따라서 테스트 결과는 업무 유형과 밀접합니다. 수십 KB의 짧은 요청보다 대용량 HTTPS 파일 다운로드에서 차이가 더 잘 나타납니다.
결론: Vision은 데이터 경로를 최적화할 뿐 네트워크 거리를 줄이지 않습니다
기본 왕복 지연 시간이 180ms라면 Vision을 켜도 물리적 지연 시간이 20ms가 되지는 않습니다. 지속적인 전송에서 CPU 사용량, 복사와 외부 레코드 처리 부담을 줄이는 효과가 더 기대됩니다. 첫 응답이 느리다면 먼저 회선과 핸드셰이크를 확인하고, 대역폭을 충분히 채우지 못할 때 Vision과 기기 성능을 살펴보세요.
지연 시간과 처리량 향상은 어떻게 이해해야 할까
REALITY와 Vision 조합의 체감 효과는 대체로 세 가지에서 비롯됩니다. 배포 측에서는 인증서 체인으로 인한 관리 변수를 줄이고, 핸드셰이크 형태는 일반 TLS에 가깝게 유지하며, Vision은 대용량 전송 단계에서 중복 캡슐화와 데이터 복사를 줄입니다. 혼잡, 우회 경로, 심각한 패킷 손실이나 서버의 출구 대역폭 부족을 해결할 수는 없으므로 비교할 때는 서버, 회선, 대상 파일과 테스트 시간을 동일하게 유지해야 합니다.
위 수치는 테스트 방법을 설명하기 위한 예시이며 모든 회선에서 재현되는 고정된 결론이 아닙니다. 조건은 동일한 쿼드코어 서버, 동일한 경로, 단일 2GB HTTPS 파일이며 5회 연속 테스트 후 중앙값을 사용했습니다. Vision 조합의 중앙 처리량은 36MB/s, 일반 VLESS + TCP + TLS는 31MB/s였습니다. 그러나 두 방식의 유휴 왕복 지연 시간은 모두 약 38ms로 비슷했으므로 처리량 향상이 네트워크 왕복 시간의 동반 감소를 의미하지는 않습니다.
- 첫 페이지 로딩이 느림: TCP 연결 수립, TLS 핸드셰이크와 첫 바이트까지의 시간을 기록하세요. 각 항목이 모두 높다면 먼저 회선 거리, DNS와 서버 부하를 확인합니다.
- 다운로드가 처음엔 빠르다가 느려짐: 서버 출구 대역폭이 한계에 도달했는지 확인하고 로컬 CPU 단일 코어 사용량, 시스템 절전 모드와 무선 네트워크 변동도 점검하세요.
- 속도 측정 차이가 작음: 저대역폭 회선이나 짧은 연결에서는 외부 계층 처리가 주요 병목이 아닙니다. 5% 이내의 변동은 네트워크 흔들림일 수 있습니다.
- 저녁 피크 시간에 뚜렷하게 느려짐: 동일한 노드를 서로 다른 시간대에 테스트하세요. RTT와 패킷 손실이 함께 증가한다면 프로토콜을 바꿔도 혼잡을 우회하기 어렵습니다.
- 여러 연결은 정상인데 단일 연결만 느림: TCP 혼잡 제어, 경로 MTU와 중간 네트워크 품질을 확인하세요. 집계 속도 측정만으로 프로토콜 성능을 판단하지 마세요.
결론: 먼저 비교군을 만든 뒤 프로토콜 효과를 판단하세요
동일한 서버와 대상 파일을 고정하고 각각 5회 테스트한 뒤 중앙값을 사용하세요. 처리량, CPU 사용량 또는 핸드셰이크 성공률에서 지속적인 차이가 나타날 때만 전송 조합의 효과로 볼 수 있습니다. 노드를 바꾼 뒤 바로 비교하면 회선 차이를 REALITY나 Vision의 효과로 오해하게 됩니다.
클라이언트 매개변수는 어떻게 확인할까
구독에는 보통 주소, 포트, 사용자 ID, Flow, 전송 방식, REALITY 공개 키, Short ID, Server Name과 지문이 한 번에 포함됩니다. 이 중 하나라도 서버와 다르면 시간 초과, 즉시 연결 종료 또는 로그의 인증 실패가 발생할 수 있습니다. 구독을 업데이트한 뒤 특정 필드 하나를 수동으로 덮어쓰는 것이 가장 흔한 매개변수 불일치 원인입니다.
데스크톱 확인
- 클라이언트
- v2rayN
- 진입 경로
- 서버 편집
- 코어
- Xray
- Flow
- xtls-rprx-vision
- 로컬 포트
- 10808
「설정」→「매개변수 설정」에서 로컬 수신 대기 포트를 확인하세요. 서버 편집 화면에서는 전송, 보안과 REALITY 필드를 중점적으로 점검합니다.
Android 확인
- 클라이언트
- v2rayNG
- 코어
- Xray
- 네트워크
- tcp
- 보안
- reality
- 지문
- chrome
설정을 길게 눌러 편집 화면으로 들어간 뒤 공개 키, Short ID, Server Name과 Flow를 확인하세요. 수정 후 저장하고 다시 연결합니다.
v2rayNG는 Xray 코어를 사용하므로 REALITY와 Vision을 바로 사용하기에 적합합니다. v2flyNG는 v2fly 코어를 사용하며 기능 범위는 v2fly 코어의 지원 여부에 따라 달라집니다. 화면의 필드가 비슷하다는 이유만으로 Xray 전용 조합이 작동한다고 가정해서는 안 됩니다. 구독에 REALITY 노드가 포함되어 있다면 선택한 클라이언트와 코어가 해당 매개변수를 명확히 지원하는지 먼저 확인하세요.
프로토콜: VLESS
전송: TCP
보안: REALITY
Flow：xtls-rprx-vision
서버 포트: 443
지문: chrome
일치 필수: 사용자 ID, 공개 키, Short ID, Server Name자주 묻는 질문과 설정 범위
REALITY, Vision과 VLESS는 같은 노드 정보에 함께 표시되는 경우가 많지만 역할은 서로 다릅니다. VLESS는 프록시 프로토콜이고 REALITY는 전송 보안과 서버 인증을 담당하며 Vision은 VLESS의 흐름 제어 모드입니다. 세 가지를 구분해서 이해해야 문제가 핸드셰이크, 인증, 전송 또는 클라이언트 처리 중 어디에서 발생했는지 찾을 수 있습니다.
REALITY는 항상 일반 TLS보다 지연 시간이 낮나요?
그렇지는 않습니다. 기본 RTT는 주로 물리적 거리와 네트워크 경로로 결정됩니다. 동일한 서버에서 핸드셰이크 시간을 연속 5회 측정하세요. 차이가 몇 ms에 불과하다면 프로토콜이 안정적으로 줄인 결과가 아니라 정상적인 변동으로 봐야 합니다.
구독을 가져온 뒤 핸드셰이크 실패가 표시되면 어떻게 하나요?
먼저 시스템 자동 시간 동기화를 켠 뒤 구독을 한 번 다시 업데이트하세요. 그다음 서버 포트, 공개 키, Short ID, Server Name과 지문을 확인합니다. 특히 일반 TLS의 도메인 필드를 REALITY 설정에 그대로 덮어쓰지 않도록 주의하세요.
Vision을 VMess 노드에 사용할 수 있나요?
사용할 수 없습니다. xtls-rprx-vision은 VLESS의 Flow입니다. VMess 노드는 구독에 지정된 전송 및 보안 방식을 사용해야 하며, 이 Flow를 수동으로 추가해도 노드가 VLESS로 변환되지는 않습니다.
연결은 성공했지만 속도가 달라지지 않는 것이 정상인가요?
정상입니다. 회선 한도가 20Mbps에 불과하거나 테스트 파일이 너무 작고 기기 성능이 충분하다면 중복 캡슐화는 병목이 아닙니다. 최소 1GB 이상의 HTTPS 파일로 테스트하고 CPU, RTT, 패킷 손실과 평균 처리량도 함께 기록하세요.
지문을 바꿔도 연결되지 않는 이유는 무엇인가요?
지문은 핸드셰이크 매개변수 중 하나일 뿐입니다. 구독에서 제공한 값으로 되돌린 뒤 코어 로그를 확인하세요. 계속 실패한다면 서버 관리자가 개인 키와 공개 키의 대응 관계, 허용된 Short ID, 대상 주소와 시스템 시간을 점검해야 합니다.
조합을 선택할 때 어떤 조건을 봐야 하나요?
- 서버와 클라이언트 모두 REALITY와 Vision을 지원하는 Xray 코어를 사용하고, 기능 버전이 설정 요구 사항을 충족해야 합니다.
- 노드에 VLESS, TCP, REALITY와
xtls-rprx-vision이 명확히 표시되어 있어야 하며 다른 프로토콜 조합에서 필드를 조합해서는 안 됩니다. - 구독에서 내려받은 매개변수를 기준으로 삼으세요. 구독을 업데이트한 뒤에는 먼저 원래 설정을 테스트하고 라우팅과 시스템 프록시를 조정할지 결정합니다.
- 문제를 점검할 때는 먼저 병렬 변수를 끄고 한 번에 하나의 필드만 변경하면서 해당 시점의 코어 로그를 보관하세요.
- 속도를 판단할 때 RTT, 패킷 손실, CPU와 서버 출구 대역폭을 함께 확인하세요. 한 번의 웹 속도 측정만으로 결론을 내리지 마세요.
정리하면 REALITY는 인증서 배포 방식과 핸드셰이크 인증 문제를 해결하고, XTLS Vision은 특정 데이터 흐름의 추가 처리 문제를 해결합니다. 두 기술을 조합하면 안정적인 회선, 고대역폭 전송과 지속적인 HTTPS 트래픽에서 장점이 더 잘 나타납니다. 병목이 혼잡, 패킷 손실이나 잘못된 라우팅에 있다면 프로토콜 이름을 바꾸기보다 네트워크와 설정을 먼저 바로잡는 편이 효과적입니다.