VLESS는 프록시 요청을 전달하고, Vision은 조건에 맞는 TLS 트래픽의 전달을 최적화하며, REALITY는 프록시 연결의 보안과 인증을 담당합니다. 세 요소를 함께 쓰면 회선 대역폭이 늘어나는 것이 아니라 불필요한 캡슐화와 중복 암호화 처리가 줄어듭니다. VLESS 구독 정보를 받아 v2rayN이나 v2rayNG에서 매개변수를 확인하려는 사용자에게 적합합니다. 각 계층의 역할을 구분하고 필드, 로그, 비교 테스트를 통해 문제를 찾는 방법을 살펴봅니다.
1. VLESS, Vision, REALITY의 역할
먼저 핵심부터 살펴보겠습니다. 흔히 말하는 ‘VLESS + REALITY + Vision’은 서로 동등한 세 가지 프록시 프로토콜이 아니라 계층별로 구성된 조합입니다. VLESS는 클라이언트가 대상 주소와 인증 정보를 전달하는 방식을 정하고, XTLS Vision은 Xray의 흐름 제어 방식이며, REALITY는 연결 보안을 담당합니다. 설정에서 각 항목을 잘못된 필드에 넣으면 이름을 올바르게 입력해도 의도한 연결을 구성할 수 없습니다.
| 계층 | 주요 필드와 값 | 주요 역할 |
|---|---|---|
| 프록시 프로토콜 | protocol: vless | 사용자 인증 정보와 대상 주소를 전달하고 프록시 요청을 처리합니다. |
| 흐름 제어 | flow: xtls-rprx-vision | 조건에 맞는 TLS 데이터 전달을 식별하고 최적화합니다. |
| 전송 | TCP(일부 최신 인터페이스에서는 RAW로 표시) | 클라이언트와 서버 간 바이트 스트림을 전달합니다. |
| 연결 보안 | security: reality | 보호된 연결을 수립하고 서버를 인증합니다. |
VLESS 자체에는 완전한 전송 암호화 기능이 없습니다. 일반적인 설정 화면에서 VLESS의 encryption을 none으로 지정해도 전체 연결이 평문으로 전송되는 것은 아닙니다. 바깥 계층에서 REALITY가 보호하기 때문입니다. 또한 VLESS의 이 필드를 VMess의 암호화 옵션과 직접 대응시키지 마세요. 두 프로토콜의 설계는 서로 다릅니다.
이 문서에서는 Xray의 VLESS, Vision, REALITY 조합을 다룹니다. ‘V2Ray’는 프로젝트나 생태계를 가리키는 이름이며, 모든 코어가 이 필드를 지원한다는 뜻은 아닙니다. 호환성을 판단할 때는 클라이언트 이름에 v2ray가 들어 있는지가 아니라 실제로 실행 중인 코어를 확인해야 합니다.
2. XTLS Vision은 어떻게 처리 부담을 줄일까
HTTPS 사이트에 접속하면 브라우저와 대상 사이트 사이에 이미 TLS 연결이 설정되어 있습니다. 프록시 터널에서도 같은 데이터를 계속 외부 암호화하면 흔히 말하는 ‘TLS 안의 TLS’가 됩니다. 정상적으로 작동하지만 암호화 처리, 레코드 캡슐화, 데이터 복사 등에 추가 비용이 듭니다. 저전력 기기나 고처리량 연결, CPU 사용률이 한계에 가까운 환경에서 이 부담이 더 두드러질 수 있습니다.
Vision은 프록시 연결에서 TLS 핸드셰이크와 데이터 전송 단계를 식별하고, 핸드셰이크 단계에는 패딩 등의 처리를 적용합니다. 조건이 맞으면 대상 TLS로 이미 보호된 데이터를 외부에서 계속 중복 암호화하지 않습니다. 대상 사이트와 브라우저 사이의 종단 간 TLS를 해제하거나 없애는 것은 아니며, 프록시가 HTTPS 본문을 볼 수 있게 되는 것도 아닙니다.
- 적용 대상에는 조건이 있습니다: 최적화는 식별 가능하고 요구 조건을 충족하는 TLS 트래픽에 적용됩니다. 모든 TCP 데이터를 같은 방식으로 최적화할 수는 없습니다.
- TLS가 아닌 데이터도 보호해야 합니다: Vision을 켠다고 일반적인 평문 애플리케이션 트래픽이 그대로 노출되는 것은 아닙니다.
- 전달 경로에 따라 효과가 달라집니다: 운영체제, 코어 구현, 연결 상태에 따라 복사와 전달 효율이 달라지므로 모든 환경에서 같은 성능 향상을 기대할 수는 없습니다.
- 대역폭 한계는 그대로입니다: 서버 속도 제한, 네트워크 간 혼잡, 패킷 손실은 여전히 발생할 수 있으며 흐름 제어로 이런 물리적 제약을 우회할 수는 없습니다.
따라서 ‘Vision은 어떤 방식보다 항상 빠르다’고 단정할 수 없습니다. 병목이 서버의 제한된 송신 대역폭이라면 로컬 CPU 부담을 줄여도 다운로드 속도는 달라지지 않을 수 있습니다. 반대로 기기의 암호화 처리 성능이 병목이라면 처리량이 늘거나 CPU 사용률이 낮아지는 변화를 확인할 가능성이 큽니다.
3. REALITY의 핸드셰이크와 인증서는 어떻게 다를까
REALITY의 핵심은 연결 인증과 외관 설계이지, 모든 핸드셰이크 단계를 생략하는 것이 아닙니다. 클라이언트는 서버가 제공한 공개 키 정보를 보유하고 serverName, shortId 등의 매개변수와 함께 연결을 검증합니다. 서버는 설정된 대상 사이트를 활용해 인증 조건을 충족하지 않는 연결을 처리함으로써 일반적인 TLS 서비스와 비슷하게 동작하도록 할 수 있습니다. 그렇다고 인증된 사용자의 트래픽까지 해당 대상 사이트를 거친다는 뜻은 아닙니다.
일반 TLS 인증서를 직접 배포하는 방식과 비교하면, 이 구성은 프록시 서버의 진입점에 쓸 도메인 인증서를 발급하고 갱신하는 절차가 대체로 필요하지 않습니다. 하지만 키, 허용된 serverName, 대상 사이트 조건, 클라이언트 매개변수는 정확히 설정해야 합니다. serverName을 임의의 유명 사이트로 바꾸거나 주소창에 표시되는 서버 IP를 serverName으로 사용해서는 안 됩니다.
주의: 포트 번호나 이름만으로 설정을 추측하지 마세요
구독 정보를 받으면 주소, 포트, serverName, 공개 키 정보, shortId를 하나씩 확인하세요. 연결에는 제공자가 명시한 값만 사용해야 합니다. 443은 흔히 쓰는 포트일 뿐 REALITY의 필수 포트는 아닙니다.
‘핸드셰이크 간소화’는 다음처럼 이해하는 편이 정확합니다. 일반적인 TCP 구성에서는 WebSocket의 HTTP Upgrade 같은 애플리케이션 계층 절차를 추가로 거치지 않으며, 서버 운영 측에서도 일반 인증서 관리 절차가 줄어듭니다. TCP 연결 수립, 연결 보안 협상, 대상 사이트 연결에는 여전히 시간이 필요하므로 ‘핸드셰이크가 없다’거나 특정 밀리초만큼 시간이 줄어든다고 단정할 수 없습니다.
4. 클라이언트와 코어 선택 방법
데스크톱에서는 v2rayN, Android에서는 v2rayNG를 사용할 수 있습니다. 둘 다 코어를 설정하고 실행하는 클라이언트 인터페이스이며, REALITY와 Vision 매개변수를 실제로 처리하는 것은 코어입니다. 클라이언트 프로그램을 업그레이드한 뒤에는 실행 중인 코어도 함께 업데이트되었는지, 해당 노드가 실제로 어떤 코어를 사용하는지도 확인하세요.
Xray 코어
권장이 문서의 구성은 Xray 구현을 기준으로 합니다. 데스크톱에서는 v2rayN에서 해당 VLESS 노드가 Xray를 사용하는지 확인하세요. Android에서는 v2rayNG를 사용하고 내장 코어가 가져온 매개변수를 지원하는지 확인하세요.
적합한 용도: VLESS + REALITY + Vision 설정, Xray 코어 로그를 통한 문제 해결
V2Fly 코어
v2flyNG는 V2Fly 코어 설정을 위한 클라이언트입니다. 이름이 비슷하다고 REALITY와 Vision이 포함된 Xray 설정을 그대로 적용해서는 안 됩니다. 해당 코어와 호환된다고 명시된 노드 매개변수를 사용하세요.
적합한 용도: V2Fly용으로 명확히 제공된 VMess 등의 설정. 이 문서의 구성을 대체하는 선택지는 아닙니다.
구독 링크에도 형식 호환성의 한계가 있습니다. 링크를 가져올 수 있다고 해서 모든 확장 필드가 보존되는 것은 아닙니다. 가져온 뒤 노드 편집 창을 열어 보안 유형, 흐름 제어, SNI, 지문, shortId를 확인하세요. 목록에 노드 이름이 표시되는지만 봐서는 안 됩니다. ‘호환성’을 높이려고 보안 유형을 REALITY에서 일반 TLS로 바꾸면 연결 방식 자체가 달라집니다.
5. v2rayN 설정 항목별 확인 방법
아래 메뉴 경로는 Windows 클래식 인터페이스의 v2rayN 6.x를 기준으로 한 예시이며, 최소 버전을 뜻하지는 않습니다. 크로스 플랫폼 버전이나 이후 버전에서는 필드 배치가 다를 수 있으므로 항목의 의미를 기준으로 찾아보세요. 제공자가 준 전체 구독 링크나 공유 링크를 우선 사용해 긴 매개변수를 직접 입력하지 않는 것이 좋습니다.
-
노드 가져오기
전체 공유 링크를 복사한 뒤 메인 화면에서 「서버」→「클립보드에서 URL 일괄 가져오기」를 선택합니다. 직접 추가하려면 「서버」→「[VLESS] 서버 추가」로 이동한 다음 프로토콜로 VLESS를 선택하세요.
-
코어 확인
「설정」→「매개변수 설정」→「Core 유형」으로 이동해 VLESS에 Xray가 지정되어 있는지 확인합니다. 현재 버전에서 코어 선택이 노드나 그룹 설정에 있다면 실제 적용 항목도 확인하세요. 실행한 뒤에는 로그에서 사용 중인 코어를 확인합니다.
-
전송 설정 확인
노드를 두 번 클릭해 편집 창을 열고 제공자가 안내한 주소, 포트, 사용자 ID를 입력합니다. 이 문서의 구성은 전송 방식으로 TCP를 사용하며, 일부 최신 버전에서는 RAW로 표시됩니다. VLESS encryption은 일반적으로
none입니다. -
보안 설정 확인
흐름 제어를
xtls-rprx-vision으로, 전송 계층 보안을reality로 설정합니다. SNI, Fingerprint, PublicKey, ShortId를 하나씩 대조하세요. 버전에 따라 공개 키 정보의 필드 이름이 다를 수 있으니 임의의 값으로 대체하지 마세요. -
실행 확인
노드를 저장하고 선택한 뒤 메인 화면에서 「시스템 프록시」를 「시스템 프록시 자동 설정」으로 지정하고 일반 HTTPS 페이지에 접속해 보세요. 먼저 코어가 정상적으로 시작되는지 확인한 다음 연결 로그를 살펴보세요. TUN을 사용한다면 트래픽 가로채기와 라우팅도 별도로 확인해야 합니다.
Fingerprint는 TLS 클라이언트 지문 설정입니다. 서버 공개 키가 아니며 브라우저 버전 번호를 자유롭게 입력하는 칸도 아닙니다. 인터페이스에서 지원하는 항목 중 노드 요구사항에 맞는 값을 선택하세요. ‘지문 이름이 현재 기기의 브라우저와 같아야 한다’를 인증 조건으로 오해하지 마세요. 실제 인증에는 해당 키 정보와 다른 매개변수도 사용됩니다.
전체 구독 링크, 사용자 ID, 서버 개인 키를 공개하지 마세요. 문제를 해결할 때는 필드 이름, 민감 정보를 가린 오류 유형, 코어 버전만 기록하면 됩니다. 클라이언트에 필요한 것은 서버가 제공한 공개 키 정보이지 서버 개인 키가 아닙니다.
6. 속도 향상의 원인을 확인하는 방법
먼저 지연 시간, 처리량, 기기 부하를 구분하세요. TCP 지연 시간 테스트는 서버 포트에 연결할 수 있는지를 주로 보여 줄 뿐, REALITY 인증 성공을 증명하지는 않습니다. 웹 페이지가 열린다고 Vision이 예상한 데이터 처리 경로에 진입했다고 단정할 수도 없습니다. 속도는 같은 회선과 비슷한 부하 조건에서 비교해야 합니다.
- 조건을 고정하세요: 같은 기기와 네트워크, 다운로드 대상, 프록시 적용 방식을 사용하세요. 비교 노드는 가급적 같은 서버에 두어야 회선 차이를 배제하기 쉽습니다.
- 반복 측정하세요: 설정마다 30초씩 3회 측정하고 중앙값을 기록하세요. 가장 빠른 결과만 남기지 않도록 연결 실패 횟수도 함께 적으세요.
- 항목별로 기록하세요: 처리량은 MB/s, 지연 시간은 ms로 기록하고 CPU 사용률도 확인하세요. Mbps와 MB/s를 혼동하지 마세요. 두 단위는 8배 차이가 납니다.
- 변수를 통제하세요: 테스트 중에는 구독 업데이트, 대용량 파일 동기화, 다른 다운로드를 일시 중지하세요. 라우팅, DNS, 코어를 동시에 바꾸면 결과를 Vision의 영향으로 판단할 수 없습니다.
속도가 비슷해도 CPU 사용률이 낮아졌다면 최적화 효과가 있을 수 있습니다. 첫 페이지가 더 빨리 열렸다면 DNS 캐시나 연결 재사용 때문일 수도 있습니다. 이 문서에서는 환경과 무관한 성능 향상률을 제시하지 않습니다. 한 번의 속도 측정 화면보다 재현 가능한 기록이 설정 유지 여부를 판단하는 데 더 유용합니다.
7. REALITY와 Vision 연결 문제 해결
포트 지연 시간은 정상인데 웹 페이지가 열리지 않는 이유는 무엇인가요?
포트에 연결된다는 것은 TCP 연결 수립에 성공했다는 뜻일 뿐입니다. 노드를 두 번 클릭해 REALITY의 serverName, 공개 키 정보, shortId를 먼저 확인하고, 코어 로그에서 인증 또는 핸드셰이크 오류를 살펴보세요. 시스템 날짜와 시간, 시간대가 올바른지도 확인해야 합니다.
로그에 flow가 지원되지 않는다고 표시됩니다. 값을 비워야 하나요?
먼저 노드가 실제로 Xray에서 실행 중인지 확인한 다음 코어 버전과 서버 요구사항을 살펴보세요. 서버가 xtls-rprx-vision을 요구한다면 흐름 제어 값을 임의로 지우는 것은 일반적인 해결 방법이 아닙니다. 호환되는 코어로 업데이트하거나 올바른 설정을 다시 가져오세요.
링크를 복사했는데 VLESS만 표시됩니다. REALITY 매개변수는 어디에 있나요?
노드 편집 창을 열어 보안 유형과 관련 필드를 확인하세요. 값이 없다면 공유 링크 전체를 다시 복사하고, 채팅 앱이 쿼리 매개변수를 잘라내지 않았는지도 확인하세요. 그래도 누락되면 클라이언트를 업데이트한 뒤 제공자에게 공유 형식이 현재 버전과 호환되는지 문의하세요.
Vision을 켰는데 속도가 달라지지 않습니다. 설정이 잘못된 건가요?
반드시 그렇지는 않습니다. 앞서 설명한 방법으로 처리량을 3회 측정하고 CPU 사용률을 살펴보세요. 주된 병목이 송신 대역폭이나 패킷 손실이라면 프로토콜 최적화만으로 눈에 띄는 속도 향상을 기대하기 어렵습니다. 연결이 끊긴다면 서버의 흐름 제어 설정과 코어 로그를 확인하세요.
브라우저는 정상인데 다른 프로그램은 왜 프록시를 사용하지 않나요?
먼저 해당 프로그램이 시스템 프록시 설정을 따르는지 확인하세요. v2rayN의 「시스템 프록시 자동 설정」이 모든 앱의 트래픽을 가로채는 것은 아닙니다. 더 많은 앱의 트래픽을 처리해야 한다면 TUN 사용을 검토하고 라우팅 규칙을 확인하세요. REALITY 매개변수를 바꿔도 앱의 프록시 연결 방식은 달라지지 않습니다.
문제 해결 순서는 일관되게 유지하세요. 코어가 시작되는지, 서버 포트에 연결되는지, REALITY 인증이 되는지, VLESS와 흐름 제어 설정이 일치하는지, 앱 트래픽이 프록시로 들어가는지 차례로 확인합니다. 실패한 계층부터 찾아 해당 매개변수를 수정하는 편이 프로토콜, DNS, 라우팅을 한꺼번에 바꾸는 것보다 효과적입니다.