REALITY는 외부 연결의 인증과 핸드셰이크 동작을 담당하고, XTLS Vision은 조건을 충족하는 데이터 흐름의 전달을 처리합니다. 두 기능은 같은 프로토콜 설정이 아닙니다. VLESS 설정을 받은 뒤 SNI, 공개 키, shortId, flow의 의미를 알고 싶은 독자를 위해 핸드셰이크, 암호화 계층, 클라이언트 점검 순서로 설명합니다. 설정 항목별 역할을 구분하고 ‘핸드셰이크 실패’와 ‘연결은 됐지만 웹페이지가 열리지 않음’ 중 어디부터 확인할지 판단할 수 있습니다.
1. VLESS, REALITY, Vision의 역할
흔히 사용하는 ‘VLESS + REALITY + Vision’은 계층별 기능을 조합한 구성입니다. VLESS는 사용자 식별 정보와 대상 주소 등 프록시 요청 정보를 전달하며, 그 자체로 애플리케이션 데이터를 암호화하지 않습니다. REALITY는 이 조합에서 안전한 전송과 인증을 제공하고, Vision은 조건에 맞는 트래픽을 더 효율적으로 전달합니다. 세 가지를 모두 ‘암호화 프로토콜’이라고 부르면 설정 항목의 역할을 혼동하기 쉽습니다.
연결 및 인증 계층
- 프록시 프로토콜
- VLESS
- 사용자 식별 정보
- UUID
- 안전한 전송
- REALITY
- 서버 인증
- 공개 키 및 핸드셰이크 검증
UUID와 REALITY 공개 키는 역할이 다르므로 서로 대체할 수 없습니다.
이 글에서 다루는 전송 조합
- 하위 전송 방식
- TCP / RAW, 버전에 따라 명칭이 다름
- 흐름 제어 값
xtls-rprx-vision- 핸드셰이크 지문 예시
chrome- 일반적인 원격 포트
- 443, 실제 설정을 기준으로 확인
이 조합에 WebSocket 경로나 다른 전송 캡슐화를 추가하지 마세요.
v2rayN은 데스크톱 그래픽 클라이언트이며, 특정 기능을 실제로 사용할 수 있는지는 선택한 코어에 따라 달라집니다. v2rayNG는 Xray 코어를 사용합니다. v2flyNG는 v2fly 코어를 사용하므로 이름이 비슷하다고 해서 같은 REALITY 및 Vision 설정을 처리할 수 있다고 가정하면 안 됩니다. 가져오기에 성공했다는 것은 클라이언트가 입력을 받아들였다는 뜻일 뿐, 현재 실행 중인 코어가 해당 기능을 지원한다는 의미는 아닙니다.
2. REALITY의 ‘핸드셰이크 활용’은 대상 사이트의 개인 키를 가져오는 것이 아닙니다
일반적인 TLS 연결에서는 브라우저가 인증서 체인과 도메인을 검증해 웹사이트의 신원을 확인합니다. REALITY는 올바른 인증 정보를 가진 클라이언트와 유효한 인증 정보 없이 접속하는 일반 사용자 또는 탐지 연결, 두 가지 상황을 모두 고려합니다. 대상 사이트의 핸드셰이크 동작과 폴백 전달 방식을 활용해 인증되지 않은 연결이 프록시 오류를 그대로 드러내는 대신 해당 사이트에 접속한 것처럼 보이게 합니다.
위 흐름은 인증에 성공한 프록시 연결을 설명합니다. 클라이언트는 미리 설정된 서버 공개 키와 핸드셰이크 정보를 바탕으로 REALITY의 임시 인증서 메커니즘을 검증하며, 아무 인증서나 신뢰하는 것은 아닙니다. 서버가 대상 사이트의 개인 키를 얻는 것도 아니고, 대상 사이트를 대신해 공개적으로 신뢰받는 인증서를 발급하는 것도 아닙니다. ‘인증서 특성을 활용한다’는 표현은 이해를 돕기 위한 것이며, 인증서를 복사해 아무 웹사이트로든 위장할 수 있다는 뜻은 아닙니다.
REALITY 인증에 실패한 연결은 서버 설정에 따라 지정된 대상 사이트로 전달될 수 있으며, 접속자에게는 대상 사이트의 실제 TLS 동작이 표시됩니다. 따라서 대상 사이트는 임의로 넣는 장식용 항목이 아닙니다. 서버에서 대상 사이트까지 연결할 수 있는지, TLS 1.3을 지원하는지, 연결이 어떻게 동작하는지가 설정 품질에 영향을 줍니다. Xray 설정 버전에 따라 서버의 대상 항목은 target 또는 이전 이름인 dest로 표시될 수 있으니 실행 버전에 맞춰 확인하세요.
3. Vision이 줄이는 중복 암호화는 어느 계층일까요?
브라우저가 HTTPS 사이트에 접속하면 브라우저와 대상 사이트 사이에는 이미 TLS 계층이 있습니다. 여기에 프록시의 외부 TLS로 연결 전체를 다시 감싸면 같은 애플리케이션 암호문이 외부 레코드 캡슐화와 암호화를 한 번 더 거칠 수 있습니다. 프록시 서버도 외부 계층을 복호화하고 데이터를 전달해야 하므로 연산 및 데이터 이동 부담이 늘어납니다. 증가 폭은 구현 방식, 하드웨어, 트래픽 종류에 따라 달라집니다.
| 단계 또는 트래픽 | Vision의 처리 방식 | 이 설명만으로 단정할 수 없는 내용 |
|---|---|---|
| 연결 초기 및 프록시 요청 | 외부 보안 핸드셰이크와 인증을 마치고 필요한 프로토콜 처리를 수행합니다. | 첫 바이트부터 보안 채널을 우회하는 것은 아닙니다. |
| 식별 조건을 충족하는 내부 TLS 1.3 트래픽 | 안전한 전환 조건이 충족되면 직접 복사 경로로 전환해 외부 TLS를 계속 적용하는 데 따른 부담을 줄일 수 있습니다. | 모든 HTTPS 연결이 반드시 이 경로를 사용하는 것은 아닙니다. |
| 일반 평문 트래픽 또는 전환 조건을 충족하지 못하는 트래픽 | 각 트래픽에 맞는 보호된 전달 경로로 처리합니다. | 모든 데이터에서 암호화 계층 하나를 제거한다고 단정할 수 없습니다. |
| 하위 계층의 시스템 데이터 전달 | 커널, 운영체제, 연결 조건이 허용하면 더 효율적인 데이터 이동 방식을 활용할 수도 있습니다. | Vision을 켠다고 반드시 제로 카피가 구현되는 것은 아닙니다. |
여기서 말하는 ‘직접 복사’는 웹페이지의 평문이 네트워크에 노출된다는 뜻이 아닙니다. 해당 경로로 전달되는 데이터도 브라우저와 대상 사이트 사이의 TLS로 보호됩니다. Vision은 내부 프로토콜 상태를 식별해 전환하며, 단순히 암호화를 끄는 기능이 아닙니다. 조건을 충족하지 못하는 경우에는 이 설명을 그대로 적용할 수 없습니다.
판단 기준: 먼저 양쪽의 flow 설정을 확인한 뒤 처리량을 비교하세요
먼저 클라이언트와 서버 양쪽에서 xtls-rprx-vision을 사용하는지 확인하세요. 그런 다음 같은 회선과 HTTPS 대용량 파일, 비슷한 시간대를 기준으로 CPU 사용률과 처리량을 비교합니다. 한 번 웹페이지를 열어본 속도만으로 직접 복사 경로의 작동 여부를 입증할 수 없으며, 고정된 속도 향상률을 제시할 수도 없습니다.
4. 가져온 뒤 항목별로 확인할 설정
구독으로 대부분의 매개변수가 입력되지만, 업데이트 중 설정이 빠지거나 직접 편집한 내용 및 코어 버전 차이로 오류가 발생할 수 있습니다. 먼저 처음 가져온 설정을 보관한 뒤 복사본을 하나씩 수정하는 편이 좋습니다. 한 번에 한 항목만 변경하면 로그 변화와 설정 변경을 비교하기 쉽습니다.
- 서버 주소 및 포트: 프록시 서버가 실제로 수신 대기하는 주소와 포트를 지정해야 합니다. 원격
443포트와 클라이언트의 로컬 SOCKS 수신 포트는 서로 다른 항목이므로 바꿔 쓸 수 없습니다. - UUID 및 flow: UUID는 서버의 VLESS 사용자에 해당합니다. 클라이언트의
flow는 해당 사용자의 서버 설정과 일치해야 합니다.xtls-rprx-vision을 입력한다고 해서 Vision이 활성화되지 않은 서버에서 자동으로 지원되는 것은 아닙니다. - 공개 키: 서버 REALITY 개인 키에 대응하는 공개 키를 입력합니다. 웹사이트 인증서 내용이 아닙니다. 공유 링크에서는 보통
pbk로 이 값을 전달합니다. 그래픽 인터페이스와 코어 JSON의 필드 이름은 버전에 따라 달라질 수 있으므로 해당 버전의 문서를 확인하고, 링크 매개변수 이름을 JSON 필드에 그대로 사용하지 마세요. - SNI 및 지문:
serverName은 서버에서 허용하는 이름 범위에 포함되어야 합니다.fingerprint의 예시 값인chrome은 ClientHello 지문을 지정합니다. 로컬 브라우저를 변경하거나 모든 네트워크 특성을 숨기는 설정은 아닙니다. - shortId: 클라이언트 값은 서버의 허용 목록에 있는 항목과 일치해야 합니다. 16진수로 표현하며 최대 16자이고 길이는 짝수여야 합니다. 서버에서 빈 값을 허용하는 경우에만 클라이언트 값을 비워 둘 수 있습니다.
v2rayNG에서는 해당 설정을 길게 눌러 ‘편집’으로 들어간 뒤 서버 주소, 포트, 전송 보안, SNI, 공개 키 등을 확인하세요. 메뉴 이름은 버전에 따라 조금씩 다를 수 있습니다. v2rayN에서는 설정을 더블 클릭해 편집 창을 열고 실제 선택된 코어를 확인합니다. 문제 해결을 위해 ‘안전하지 않은 인증서 허용’ 같은 옵션을 켜지 마세요. REALITY 공개 키 인증을 대신할 수 없습니다.
5. 핸드셰이크, 프록시 요청, 앱 접속 순서로 점검하기
‘노드에 연결할 수 없음’에는 여러 종류의 문제가 포함됩니다. TCP 포트에 연결할 수 없는 상황에서는 SNI를 바꿔도 해결되지 않습니다. REALITY 인증 실패는 라우팅 규칙을 조정해도 해결할 수 없습니다. 모든 매개변수를 무작위로 다시 입력하기보다 연결이 진행되는 순서에 따라 정보를 확인하세요.
- 먼저 연결 대상 확인: 서버 주소와 실제 포트, 서버 수신 대기 상태, 방화벽 규칙을 확인합니다. 연결 시간 초과와 연결 거부는 서로 다른 결과입니다. 시간 초과는 회선의 패킷 손실이나 필터링 때문일 수도 있습니다.
- 다음으로 핸드셰이크 인증 확인: 공개 키, SNI, shortId, 지문 설정을 대조합니다. 서버에 핸드셰이크 시간차 제한이 설정되어 있다면 양쪽 시스템 시간이 동기화되어 있는지도 확인하세요. 시간 오차를 키 오류로 오해하지 않도록 주의해야 합니다.
- 그다음 VLESS 사용자 확인: 핸드셰이크가 완료된 뒤에도 실패한다면 UUID, flow, 서버 사용자 설정을 계속 확인합니다. 외부 연결이 성립했다고 해서 프록시 요청까지 승인된 것은 아닙니다.
- 마지막으로 앱 연결 경로 확인: 앱 트래픽이 클라이언트에 들어오는지 확인한 다음 DNS, 라우팅 규칙, 서버의 아웃바운드를 살펴봅니다. 연결 성공 로그만으로 브라우저 트래픽이 해당 프록시를 거쳤다고 볼 수는 없습니다.
공개 키와 UUID를 모두 입력했는데도 핸드셰이크가 실패하는 이유는 무엇인가요?
먼저 원본 구독에서 설정을 다시 가져와 복사본을 만든 다음 SNI, shortId, 전송 보안이 REALITY로 설정되었는지 하나씩 비교하세요. 개인 키를 교체한 뒤 서버 공개 키도 함께 갱신했는지 확인하고, 같은 시점의 양쪽 로그를 살펴보세요. 지연 시간 테스트 결과만으로 판단하지 마세요.
연결은 되는데 웹페이지가 열리지 않아요. 지문을 바꿔야 하나요?
먼저 브라우저가 시스템 프록시 또는 지정한 로컬 프록시를 사용 중인지 확인하고, 요청이 클라이언트 로그에 나타나는지 살펴보세요. 요청이 프록시에 들어왔다면 DNS 확인과 라우팅 출구를 점검합니다. 핸드셰이크 오류가 없다면 지문을 계속 바꾸는 것을 우선할 필요는 없습니다.
Vision을 켰는데 속도가 달라지지 않아요. 설정이 적용되지 않은 건가요?
꼭 그렇지는 않습니다. 먼저 양쪽의 flow를 확인하고 다운로드 소스와 테스트 시간을 동일하게 맞춘 뒤 CPU 사용률과 처리량을 살펴보세요. 회선 대역폭, 패킷 손실, 대상 서버의 속도 제한이 병목일 수 있습니다. 일반적인 작은 웹페이지로는 데이터 전달 부담 감소 효과를 확인하기 어렵습니다.
v2flyNG로 바꾸니 같은 구독 설정을 바로 사용할 수 없는 이유는 무엇인가요?
먼저 설정이 Xray의 REALITY 및 Vision 기능에 의존하는지 확인하세요. 해당 설정은 기능을 지원하는 v2rayNG 또는 적절한 코어를 선택한 v2rayN에서 사용해야 합니다. 클라이언트 이름이나 전송 항목을 바꿔도 코어 기능의 차이는 해결되지 않습니다.
6. 적용 범위를 이해한 뒤 설정 변경 여부 결정하기
REALITY는 프록시 서버의 IP를 숨기지 않으며 트래픽을 식별할 수 없다고 보장하지도 않습니다. 대상 사이트 선택, 서버 구성, 네트워크 경로, 클라이언트 버전이 모두 실제 동작에 영향을 줍니다. Vision의 주요 이점은 조건에 맞는 데이터 흐름의 처리 효율이며, 물리적인 회선 대역폭이나 왕복 지연 시간을 바꾸지는 않습니다. 패킷 손실, 혼잡, 서버 부하는 별도로 점검해야 합니다.
- 안정적으로 작동하는 설정이 있다면 비교를 위해 그대로 보관하고, 서버·전송 방식·DNS를 한꺼번에 바꾸지 마세요.
- 설정을 직접 관리해야 한다면 코어 버전과 필드 변경 내역을 기록하고, 업그레이드 후 설정 하나를 먼저 테스트한 다음 일괄 업데이트하세요.
- 문제 해결 정보를 공유할 때는 UUID, 구독 주소, 서버 개인 키를 가리고 오류 유형, 발생 시각, 필요한 필드 이름만 남기세요.
- 필드 설명은 사이트의 JSON 매뉴얼에서 확인할 수 있습니다. 처음 설정을 가져오고 프록시를 활성화하는 방법은 입문 가이드를 참고하세요.
마지막으로 확인할 것은 화면에 세 가지 이름이 함께 표시되는지가 아니라 전체 연결이 제대로 작동하는지입니다. 클라이언트가 올바른 서버에 연결하고, REALITY 인증을 통과하며, VLESS 사용자와 flow가 일치하고, 앱 요청이 의도한 경로로 전달되어야 합니다. 각 계층을 구분하면 설정과 문제 해결 과정을 재현하기 쉬워집니다.