VLESS는 요청 형식과 사용자 인증을, REALITY는 외부 보안 핸드셰이크를, XTLS Vision은 트래픽 식별과 전달 최적화를 담당합니다. 노드를 가져온 뒤 설정 항목과 성능 차이를 이해하려는 사용자를 위해 핸드셰이크, 인증서 검증, 흐름 제어, 클라이언트 설정 순으로 설명하고 연결 실패 시 확인할 매개변수도 짚습니다. 성능에 관한 설명은 작동 원리와 적용 조건에 한정하며, 프로토콜 이름만으로 실제 속도를 단정하지 않습니다.
VLESS, REALITY, Vision은 각각 무엇을 담당하나요?
이 세 가지는 서로 대체할 수 있는 세 종류의 프로토콜이 아닙니다. 흔히 말하는 ‘VLESS + REALITY + Vision’은 계층별 기능을 조합한 구성입니다. VLESS는 프록시 요청을 정의하고, REALITY는 전송 보안을 제공하며, Vision은 VLESS에서 사용하는 흐름 제어 방식입니다. 클라이언트의 노드 편집 화면에 함께 표시되다 보니 REALITY만 선택하면 Vision도 자동으로 적용된다고 오해하기 쉽습니다.
| 계층 | 주요 역할 | 확인 항목 |
|---|---|---|
| VLESS | 사용자 식별자, 대상 주소와 포트, 요청 유형 전달 | 프로토콜, UUID, encryption |
| REALITY | 인증을 포함한 TLS 방식의 핸드셰이크와 보안 전송 수행 | security, SNI, 공개 키 관련 매개변수, shortId |
| XTLS Vision | 초기 패딩을 처리하고 내부 TLS를 식별하며 조건에 따라 전달 최적화 | flow = xtls-rprx-vision |
| TCP | 하위 계층의 안정적인 바이트 스트림 제공 | 전송 유형과 서버 수신 포트 |
VLESS의 encryption은 일반적으로 none입니다. 여기서 ‘암호화 없음’은 VLESS 프로토콜 자체가 페이로드를 추가로 암호화하지 않는다는 뜻이지, 연결이 네트워크를 통해 평문으로 전송된다는 의미는 아닙니다. 이 구성에서는 외부 보안을 REALITY가 제공하며, 브라우저로 HTTPS 사이트에 접속할 때는 애플리케이션도 대상 사이트와 TLS 연결을 설정합니다.
클라이언트와 코어도 구분해서 이해해야 합니다. v2rayN은 데스크톱 클라이언트이며, 노드를 실행하려면 해당 기능을 지원하는 코어를 선택해야 합니다. v2rayNG는 Xray 코어를 사용합니다. v2flyNG는 V2Fly 계열 코어를 사용하므로, 화면에서 VLESS를 설정할 수 있다는 이유만으로 같은 REALITY·Vision 조합을 실행할 수 있다고 단정해서는 안 됩니다.
REALITY 핸드셰이크와 ‘인증서 차용’의 실제 의미
일반적인 TLS 프록시는 서버가 도메인 인증서를 제공하고 클라이언트가 인증서 체인과 도메인을 검증합니다. REALITY는 배포 및 인증 방식을 다르게 구성합니다. 서버는 대상 사이트를 설정하고, 클라이언트는 SNI와 지문, REALITY 인증에 필요한 매개변수를 전송합니다. 서버는 이를 바탕으로 유효한 클라이언트와 그 외 연결을 구분합니다.
‘인증서 차용’은 이해를 돕기 위한 표현이지, 대상 사이트의 개인 키를 프록시 서버에 복사한다는 뜻이 아닙니다. 인증에 성공한 연결에서는 REALITY가 자체 키와 검증 메커니즘으로 임시 인증서를 생성하고 검증합니다. 인증에 실패한 경우 등에는 메커니즘에 따라 설정된 대상 사이트로 연결을 전달해 해당 사이트의 정상적인 TLS 동작을 보여줄 수 있습니다. 구체적인 처리 방식은 서버 설정과 구현 버전에 따라서도 달라집니다.
따라서 클라이언트가 모든 검증을 끄고 아무 인증서나 받아들이는 것은 아닙니다. 클라이언트가 보유한 서버 공개 키 관련 매개변수가 인증에 사용되고, 짧은 식별자는 서버에서 허용한 클라이언트 매개변수와 일치해야 하며, SNI도 서버가 허용하는 이름이어야 합니다. ‘대상 사이트에서 온 것처럼 보이는 인증서’를 ‘아무 도메인이나 입력해도 된다’고 이해하면 핸드셰이크가 실패합니다.
REALITY를 일반적으로 배포하려면 적합한 TLS 1.3 대상 사이트가 필요합니다. 서버에서 대상 사이트에 정상적으로 접속할 수 있는지, SNI가 허용 목록에 있는지, 클라이언트의 시스템 시간이 크게 어긋나지 않는지에 따라 핸드셰이크 결과가 달라집니다. 오류가 발생하면 지문을 바꿔볼지 고민하기 전에 이처럼 명확한 조건부터 확인하세요.
XTLS Vision은 중복 암호화와 캡슐화를 어떻게 줄이나요?
브라우저로 HTTPS 사이트에 접속하면 브라우저와 사이트 사이에 이미 TLS 계층이 형성됩니다. 프록시가 이 TLS 암호문을 다시 다른 TLS 계층에 통째로 넣으면 흔히 말하는 ‘TLS over TLS’가 됩니다. 이 방식도 작동하지만, 외부 레코드 캡슐화와 암복호화, 버퍼 처리에 리소스가 필요합니다.
Vision은 임의의 데이터를 받자마자 암호화를 중단하는 기능이 아닙니다. 연결 초기 트래픽과 패딩을 처리하고, 내부 TLS의 핸드셰이크와 레코드 특성을 식별합니다. 구현에서 조건을 충족한다고 판단하면, 특히 직접 전달하기 적합한 내부 TLS 1.3 트래픽의 경우 더 직접적인 전달 경로로 전환해 이미 암호화된 데이터의 중복 처리를 줄일 수 있습니다.
- 연결 초기 단계: 인증, VLESS 요청, 트래픽 식별은 여전히 필요합니다. 외부 핸드셰이크를 완전히 건너뛴다고 이해해서는 안 됩니다.
- 조건을 충족하는 HTTPS 트래픽: 애플리케이션 측 TLS는 사이트 콘텐츠를 계속 보호합니다. Vision은 브라우저와 사이트 사이의 데이터를 복호화하는 것이 아니라 주로 외부 계층의 중복 처리를 줄입니다.
- 조건을 충족하지 않는 트래픽: 직접 전달 경로를 그대로 적용할 수 없으며, 필요한 보안 캡슐화와 프로토콜 처리를 계속 수행해야 합니다.
- 전달 구현: 시스템과 연결 조건이 허용하면 더 효율적인 전달 메커니즘을 사용할 수도 있습니다. 모든 플랫폼과 모든 연결이 같은 경로를 사용한다는 뜻은 아닙니다.
이런 이유로 CPU 성능이 낮거나 동시 연결이 많거나 데이터를 오래 전송할 때 중복 암호화 감소가 더 큰 도움이 될 수 있습니다. 하지만 Vision이 서버의 업로드 대역폭을 늘리거나 혼잡한 회선을 저지연 회선으로 바꾸지는 않습니다. 병목이 네트워크 간 패킷 손실이나 회선 대기열에 있다면, 로컬 암호화 비용이 줄어도 다운로드 속도에는 큰 차이가 없을 수 있습니다.
판단 방법: 핸드셰이크 시간과 지속 처리량을 따로 측정하세요
비교할 때는 서버, 대상 사이트, 테스트 시간을 동일하게 유지하고 첫 요청 시간, 지속 다운로드 속도, 클라이언트 CPU 사용량을 각각 기록하세요. 처리량만 높아지고 첫 요청 시간은 거의 그대로라면 전달 및 암호화 비용 감소로 보는 편이 타당합니다. 이를 곧바로 ‘네트워크 왕복이 한 번 줄었다’고 해석해서는 안 됩니다.
설정 항목: 포트, SNI, 짧은 식별자, flow
노드가 작동하려면 클라이언트와 서버의 매개변수가 한 세트로 일치해야 합니다. 먼저 서비스 제공자가 준 전체 설정을 확보한 뒤 클라이언트에 제대로 가져왔는지 확인하세요. 아래 숫자는 프로토콜 또는 설정상의 경계이며, 이 사이트에서 측정한 성능 결과가 아닙니다. 443은 흔히 쓰이는 포트일 뿐 REALITY에 허용되는 유일한 포트는 아닙니다.
프로토콜 및 전송 방식
- 프로토콜
- VLESS
- encryption
- none
- 전송 방식
- TCP. 일부 최신 설정에서는 RAW라고 표기
- security
- reality
- flow
- xtls-rprx-vision
이 옵션은 이 문서에서 다루는 구성을 설명할 뿐, 그대로 연결할 수 있는 완전한 노드 설정은 아닙니다.
인증 및 핸드셰이크
- 주소 및 포트
- 서비스 제공자가 안내한 연결 주소 사용
- UUID
- 해당 서버의 VLESS 사용자
- SNI
- 서버에서 허용한 serverNames와 일치
- 공개 키 관련 매개변수
- 서버의 REALITY 키 설정에서 제공
- shortId
- 서버 shortIds에 포함된 값과 일치
공개 키 매개변수는 버전에 따라 화면이나 설정 항목의 이름이 달라질 수 있습니다. 현재 사용 중인 코어 문서와 구독 형식을 기준으로 확인하세요.
shortId는 16진수로 표시합니다. 비어 있지 않은 값은 문자 수가 짝수여야 하며 최대 16자, 즉 최대 8바이트입니다. 빈 값을 사용할 수 있는지는 서버가 빈 짧은 식별자를 허용하는지에 달려 있습니다. UUID의 약칭이 아니며 노드 이름을 보고 임의로 만들 수도 없습니다. 가장 안전한 방법은 구독에서 받은 값을 그대로 사용하는 것입니다.
SNI와 서버 주소도 서로 다른 개념입니다. 주소는 실제로 연결할 호스트를 지정하고, SNI는 핸드셰이크에서 서버 이름을 알립니다. 노드 주소는 IP일 수 있지만 SNI는 설정에서 허용된 도메인일 수 있습니다. 주소가 다르다는 이유로 SNI를 서버 IP로 바꾸지 말고, 인증 매개변수 오류를 감추려고 인증서 검증을 건너뛰지도 마세요.
v2rayN 설정 및 연결 확인 순서
설정은 ‘정상적으로 가져오기, 코어 사용 가능 여부, 핸드셰이크 성공, 프록시 적용’ 순으로 확인하세요. 노드 목록에 지연 시간이 표시된다는 사실만으로 REALITY 인증 성공이 입증되지는 않습니다. 일반 TCP 탐색으로 확인할 수 있는 것은 해당 포트에 어떤 방식으로든 연결 가능한지 정도입니다.
- 노드 설정을 확인합니다. v2rayN 노드 목록에서 대상 노드를 두 번 클릭해 프로토콜이 VLESS인지, 보안 옵션이 REALITY인지, 흐름 제어가
xtls-rprx-vision인지 확인하세요. 화면에서 항목을 묶는 방식은 버전에 따라 달라질 수 있지만 각 설정의 의미는 같습니다. - 실행 코어를 확인합니다. ‘설정’ → ‘매개변수 설정’을 열어 코어 관련 옵션을 확인하고, 해당 노드가 실제로 REALITY와 Vision을 지원하는 Xray 코어에서 실행되는지 확인하세요. 클라이언트 설치 패키지 이름만으로 기능 지원 여부를 판단하지 마세요.
- 로컬 수신 주소를 확인합니다. 같은 설정 화면에서 로컬 프록시 포트를 확인하세요. 실제 수신 주소가
127.0.0.1:10808이면 외부 테스트 도구에서도 이 주소를 사용해야 합니다. 포트를 변경했다면 테스트 명령도 함께 수정하세요. - 실제 연결을 테스트합니다. 노드를 선택한 뒤 노드 목록 메뉴에서 실제 연결 지연 시간 테스트를 실행하고 코어 로그를 확인하세요. 인증 오류, 공개 키 매개변수 오류, 연결 시간 초과는 각각 다르게 처리해야 하며 모두 ‘노드가 느리다’고 뭉뚱그리면 안 됩니다.
- 애플리케이션 연결 경로를 확인합니다. 시스템 프록시를 켜고 HTTPS 페이지에 접속하세요. 애플리케이션이 시스템 프록시 설정을 읽지 않는 경우를 배제하려면 명령줄에서 SOCKS 프록시를 지정해도 됩니다.
아래 명령은 로컬 SOCKS 주소가 실제로 10808 포트에서 수신 중인 경우에만 사용하세요. socks5h를 사용하면 도메인 조회를 프록시 측에서 처리하므로 로컬 DNS 결과가 이번 테스트에 영향을 주지 않습니다. 반환된 상태 코드는 요청 완료 여부를 확인하는 데 도움이 되지만, 지정한 흐름 제어를 사용해 외부로 나갔다는 사실을 단독으로 입증하지는 못합니다. 현재 노드 설정과 로그도 함께 확인하세요.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/Android에서는 v2rayNG 역시 가져온 REALITY 매개변수를 확인하고 해당 VPN 연결 권한을 허용해야 합니다. 설정이 Xray 확장을 지원하는 구독에서 제공된 경우 v2flyNG로 그대로 옮겨 같은 결과를 기대하지 마세요. 구독 텍스트를 읽을 수 있는지와 코어가 모든 항목을 지원하는지는 서로 다른 문제입니다.
성능의 한계: 모든 회선이 더 빨라진다고 할 수 없는 이유
‘오버헤드가 줄어든다’는 것은 작동 원리에 관한 결론이고, ‘지연 시간이 줄어든다’는 것은 실제 측정이 필요한 결과입니다. REALITY도 하위 연결을 설정하고 보안 핸드셰이크를 완료해야 하며, Vision 최적화에도 적용할 수 있는 트래픽 조건이 있습니다. 웹페이지에 DNS 조회가 여러 번 필요하거나 다른 지역으로 접속하거나 서버가 요청을 처리하느라 대기 중이라면 암호화 계산 감소는 전체 시간에서 작은 비중만 차지할 수 있습니다.
| 관찰된 현상 | 우선 확인할 항목 | 바로 단정하면 안 되는 내용 |
|---|---|---|
| 포트에는 연결되지만 실제 연결은 실패 | UUID, SNI, 공개 키 관련 매개변수, shortId, 시스템 시간 | 포트에 연결되면 인증도 성공한 것 |
| 다운로드는 빠르지만 첫 페이지 로딩은 느림 | DNS, 연결 설정 시간, 대상 사이트 응답 | 지속 처리량이 높으면 모든 요청의 지연도 낮다는 것 |
| 저녁 시간대 처리량 저하 | 회선 혼잡, 패킷 손실, 서버 부하 | flow를 바꾸면 대역폭 병목이 해결된다는 것 |
| CPU 사용량은 줄었지만 속도는 그대로 | 외부 회선 속도 제한, 대상 속도 제한, 로컬 접속 대역폭 | 최적화가 적용되지 않았다는 것 |
비교 테스트에서는 다운로드 대상, 연결 수, 프록시 규칙을 동일하게 유지하고 최소 3회 반복해 중앙값을 기록하세요. 브라우저 캐시가 적중한 요청과 캐시 없이 처음 실행한 요청을 비교하지 말고, 지역이 다른 서버의 결과를 흐름 제어 탓으로 돌리지 마세요. 이렇게 해야 프로토콜 오버헤드, 라우팅 품질, 서버 리소스 차이를 구분할 수 있습니다.
자주 묻는 질문: 연결 실패와 설정 불일치 해결
REALITY를 선택했는데 Vision도 설정해야 하나요?
REALITY는 전송 보안 설정이고 Vision은 VLESS 흐름 제어입니다. 노드 편집 화면을 다시 열어 보안 옵션과 flow를 각각 확인하세요. 서비스 제공자가 xtls-rprx-vision을 요구한다면 클라이언트와 서버의 사용자 설정이 일치해야 합니다. 흐름 제어를 비워 두는 것으로 대체할 수 없습니다.
TCP 지연 시간은 표시되는데 실제 연결은 계속 실패하나요?
먼저 코어 로그를 열고 UUID, SNI, 공개 키 관련 매개변수, shortId를 확인하세요. 이어서 기기의 자동 시간 설정이 켜져 있는지, 서버에서 설정된 대상 사이트에 접속할 수 있는지 확인합니다. TCP 지연 시간 테스트에는 프록시 인증 절차 전체가 포함되지 않으므로 핸드셰이크 문제를 배제할 수 없습니다.
지문을 chrome으로 설정하면 실제 브라우저처럼 동작하나요?
그렇지 않습니다. 이 설정은 주로 클라이언트 TLS 핸드셰이크 특성에 영향을 주며, 이후 모든 네트워크 동작을 브라우저와 똑같이 바꾸지는 않습니다. 제공자가 권장하고 현재 코어가 지원하는 지문 값을 사용하세요. 로그에 미지원이라고 표시되면 호환 코어를 업데이트하거나 제공자에게 확인하고, 이름을 무작위로 바꾸지 마세요.
구독을 업데이트한 뒤에도 이전 공개 키와 짧은 식별자를 계속 사용할 수 있나요?
먼저 새 구독에 포함된 매개변수를 기준으로 확인하세요. 서버에서 키나 짧은 식별자 목록을 변경했다면 이전 값으로 인증되지 않을 수 있습니다. 노드를 다시 가져오거나 업데이트하고, 같은 이름의 이전 노드가 남아 있는지 확인하세요. 표시 이름만 바꾼 것이 아니라 실제로 업데이트된 설정을 선택했는지도 살펴보세요.
이 설정 조합을 이해할 때는 프록시 프로토콜, 외부 보안, 흐름 제어의 역할을 구분하는 것이 중요합니다. 먼저 매개변수와 코어가 서로 맞는지 확인한 뒤 핸드셰이크와 실제 요청을 살펴보세요. 연결 경로가 확인되어야 Vision이 CPU를 얼마나 절약하는지, 요청 시간이 줄었는지를 의미 있게 비교할 수 있습니다.