VLESS는 프록시 프로토콜과 사용자 식별을, REALITY는 연결의 핸드셰이크와 인증을, XTLS Vision은 트래픽 캡슐화 방식을 담당합니다. REALITY 노드를 가져오거나 직접 설정하려는 사용자를 위해 세 기능의 역할 분담과 성능 향상의 조건, v2rayN에서 주소·SNI·공개 키·Short ID·Flow가 각각 어떤 설정에 해당하는지 설명합니다.
VLESS, REALITY, Vision은 각각 무엇을 담당할까?
노드 이름에 적힌 ‘VLESS + TCP + REALITY + Vision’은 서로 바꿔 쓸 수 있는 네 가지 표현도, 암호화를 네 겹으로 적용한다는 뜻도 아닙니다. 각 항목의 계층을 나눠 보면 같은 VLESS 노드라도 설정과 연결 결과가 달라지는 이유를 알 수 있습니다.
- VLESS: 사용자 식별자와 목적지 주소 등의 정보를 전달하는 프록시 프로토콜입니다. 사용자는 보통 UUID로 식별하며, VLESS 자체는 TLS와 같은 콘텐츠 암호화 기능을 담당하지 않습니다.
- TCP: 여기서 사용하는 하위 전송 방식입니다. 최신 Xray 설정이나 일부 인터페이스에서는 RAW라는 이름을 쓰기도 하므로, 클라이언트와 코어의 필드 설명을 기준으로 확인하세요.
- REALITY: Xray 생태계의 전송 보안 메커니즘입니다. 핸드셰이크와 서버 인증, 인증에 실패한 연결의 처리 등을 다룹니다.
- XTLS Vision: VLESS의 흐름 제어 방식입니다. 일반적으로
xtls-rprx-vision값을 사용하며, 초기 데이터 형태를 조정하고 조건이 맞으면 중복 캡슐화와 암호화를 줄입니다.
v2rayN은 관리 인터페이스이며, 실제 연결은 v2rayN이 실행하는 코어가 처리합니다. 이 설정을 살펴볼 때는 클라이언트 창이 열리는지만 볼 것이 아니라, 해당 기능을 지원하는 Xray 코어가 노드를 처리하는지 확인해야 합니다. V2Fly와 Xray의 기능 발전 방향은 완전히 같지 않습니다. 둘 다 V2Ray 기술 계열에서 출발했다는 이유만으로 같은 REALITY 설정을 서로 바꿔 사용할 수는 없습니다.
REALITY 핸드셰이크: 주소, SNI, 인증 정보
브라우저가 HTTPS 사이트에 접속하면 먼저 TLS 매개변수를 협상하고 상대방의 신원을 확인합니다. 프록시를 사용하면 브라우저와 웹사이트 사이에 클라이언트에서 프록시 서버로 이어지는 연결이 추가됩니다. REALITY는 주로 이 구간을 처리하며, 브라우저가 접속하려는 웹사이트의 인증서를 대신 발급하지 않습니다.
REALITY 클라이언트는 서버가 제공한 공개 키 등의 매개변수로 연결을 인증하고, 핸드셰이크 과정에서 필요한 인증 정보를 전달합니다. 서버는 설정에서 허용한 서버 이름과 Short ID 등의 조건도 확인합니다. 인증에 실패한 연결은 REALITY 메커니즘에 따라 서버에 설정된 목적지 사이트로 전달될 수 있습니다. 구체적인 동작은 설정과 실패 시점에 따라 다르므로, 오류가 발생하면 언제나 웹페이지가 열린다고 볼 수는 없습니다.
혼동하기 쉬운 주소가 두 가지 있습니다. 노드의 ‘주소’는 클라이언트가 연결할 프록시 서버를 지정하고, SNI(서버 이름)는 핸드셰이크에 포함되는 이름 매개변수로, 보통 서버에서 허용한 이름 중 하나여야 합니다. SNI에 노드 IP를 입력하거나 노드 주소를 SNI에 해당하는 웹사이트 주소로 바꾸면 기존 설정이 작동하지 않을 수 있습니다.
- 노드 주소와 포트: 노드 제공자가 안내한 값을 사용합니다.
443포트를 흔히 사용하지만, 이는 관례일 뿐 다른 포트를 사용할 수 없다는 뜻은 아닙니다. - 서버 이름:
serverName에 해당합니다. 공유 링크에서는sni라는 매개변수 이름을 흔히 사용하므로 그대로 입력하세요. - 공개 키: 서버의 개인 키와 한 쌍을 이루는 값이어야 합니다. 클라이언트에는 연결에 필요한 공개 키만 입력하면 되며, 서버의 개인 키를 요청하거나 입력해서는 안 됩니다.
- Short ID: 서버에서 허용하는 짧은 식별자입니다. UUID에서 잘라낸 값도, 임의로 만든 메모도 아닙니다.
- 지문: 흔히
chrome을 사용하며, 클라이언트 핸드셰이크 특성을 선택합니다. 애플리케이션에서 실제로 사용하는 브라우저를 Chrome으로 바꾸는 설정은 아닙니다.
REALITY를 사용하면 이 프록시 연결에 기존 방식대로 사이트 관리자의 도메인 인증서를 설정할 필요가 없습니다. 다만 서버에서 지정한 목적지 사이트의 선택과 접속 가능 여부는 여전히 중요합니다. 또한 모든 네트워크 환경에서 트래픽을 식별할 수 없게 되는 것은 아닙니다. 핸드셰이크 외에도 연결 지속 시간, 패킷 크기, 접속 패턴은 네트워크에서 관찰할 수 있습니다.
XTLS Vision은 어떻게 처리 부담을 줄일까?
일반적인 TLS 프록시로 HTTPS 트래픽을 전달하면 보호 계층이 두 겹으로 생깁니다. 브라우저와 목적지 사이트 사이에 이미 TLS가 적용되어 있는데, 클라이언트와 프록시 서버 사이에도 TLS가 한 겹 더 씌워집니다. 이중 보호가 콘텐츠에 문제가 있다는 뜻은 아니지만, 중복된 외부 처리는 CPU 자원을 사용하고 기록 캡슐화와 데이터 복사 등에 따른 부담을 늘립니다.
Vision은 프록시를 통과하는 연결의 초기 데이터를 식별하고, 초반에는 패딩 등을 적용해 데이터 형태를 조정합니다. 조건에 맞는 TLS 트래픽, 특히 식별 가능한 TLS 1.3 연결은 적절한 단계에서 데이터 처리 방식을 전환할 수 있습니다. 그 결과 이미 암호화된 애플리케이션 데이터를 계속 같은 방식으로 외부에서 다시 암호화하지 않아도 됩니다. 브라우저와 목적지 사이트 사이의 TLS 연결은 그대로 유지됩니다.
‘더 빠르다’는 말에는 분명한 조건이 있습니다. 서버의 암호화 처리나 데이터 전달이 이미 CPU 한계에 가까우면 중복 처리를 줄여 성능이 향상될 수 있습니다. 반면 병목이 해외 구간의 혼잡, 서버 속도 제한, 패킷 손실이라면 Vision을 사용해도 대역폭이 저절로 늘어나지는 않습니다. TLS가 아닌 트래픽이나 최적화 조건을 충족하지 않는 연결에도 같은 성능 향상을 기대할 수 없습니다.
확인 방법: 처리량과 CPU 사용률을 함께 살펴보세요
같은 서버에서 같은 파일을 비슷한 시간대에 내려받으며 결과를 비교하고 CPU 사용률도 기록하세요. 처리량이 증가하거나 같은 처리량에서 CPU 사용률이 낮아져야 처리 부담이 줄었다고 판단할 수 있습니다. 한 번 측정한 지연 시간만으로 Vision이 더 빠르다고 입증할 수는 없습니다.
v2rayN 설정 항목: 서버 매개변수와 하나씩 대조하기
가능하면 먼저 전체 구독이나 공유 링크를 가져온 다음 주요 필드를 확인하세요. v2rayN 데스크톱 버전에 따라 메뉴 이름은 조금씩 다를 수 있습니다. 일반적으로 공유 링크를 복사한 뒤 ‘서버’ → ‘클립보드에서 URL 일괄 가져오기’를 선택하고, 해당 항목의 편집 창을 엽니다. 노드 이름에 REALITY가 들어 있다는 이유만으로 필드가 모두 설정되었다고 판단하지 마세요.
VLESS 및 전송 설정
- 프로토콜
- VLESS
- 사용자 ID
- 서버에서 할당한 UUID
- 암호화
- 일반적인 조합에서는 none 사용
- 전송 방식
- TCP / RAW, 버전에 맞는 인터페이스 선택
- Flow
xtls-rprx-vision
이 항목은 일반적인 REALITY + Vision 조합을 설명하며, 제공자가 별도로 안내한 설정을 대체하지 않습니다.
REALITY 핸드셰이크 설정
- 전송 보안
- reality
- SNI
- 서버에서 허용하는 서버 이름
- 공개 키
- 서버에서 제공한 REALITY 공개 키
- Short ID
- 서버에서 허용하는 16진수 식별자
- Fingerprint
- 예: chrome. 기존 설정값을 그대로 사용
버전에 따라 공개 키 필드가 Public key 또는 Password 등으로 표시될 수 있습니다. 코어와 가져온 설정을 함께 확인하세요.
VLESS의 none은 이 조합에서 해당 필드에 흔히 사용하는 값입니다. 연결 전체가 평문으로 전송된다는 뜻은 아닙니다. 데이터 보호는 선택한 전송 보안 메커니즘이 담당합니다. 반대로 이 값을 VMess에서 흔히 쓰는 auto로 바꾼다고 암호화가 강화되는 것도 아닙니다. 서로 다른 프로토콜의 설정 필드를 혼동한 것입니다.
- 먼저 주소, 실제 포트, UUID를 확인한 다음 전송 방식과 보안 유형, Flow를 확인하세요. 이 값들이 연결이 의도한 프로토콜 경로로 진행되는지 결정합니다.
- 그다음 SNI, 공개 키, Short ID를 원본과 한 글자씩 대조하고, 복사 과정에서 공백이 들어가지 않았는지 확인하세요. Short ID를 입력하는 경우 16진수 문자의 개수는 짝수여야 하며, 길이는 16자를 넘을 수 없습니다. 빈 값을 허용하는지는 서버 설정에 따라 다릅니다.
- 해당 노드가 REALITY와 Vision을 지원하는 Xray 코어에서 실제로 실행되는지 확인한 뒤 활성 서버로 지정하세요. ‘인터페이스에서 저장됨’이 ‘코어가 지원함’을 의미하지는 않습니다.
- ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트를 확인한 다음, ‘시스템 프록시’ → ‘시스템 프록시 자동 설정’을 선택하세요. 현재 버전에서 메뉴 이름이 다르면 같은 기능의 항목을 찾으면 됩니다.
성능 비교: 조건을 먼저 맞춘 뒤 프로토콜 차이를 살펴보세요
서로 다른 구독의 노드 두 개를 비교하면 프로토콜보다 회선과 서버 자원의 차이가 먼저 결과에 반영되는 경우가 많습니다. 부하가 적은 일반 TLS 노드가 혼잡한 REALITY 노드보다 빠를 수도 있습니다. Vision의 영향을 확인하려면 가능한 한 흐름 제어 방식만 바꾸고, 두 서버 설정이 모두 정상인지 확인해야 합니다.
| 테스트 항목 | 권장 방법 | 확인할 수 있는 내용 |
|---|---|---|
| 연결 설정 | 같은 HTTPS 주소에 새 연결을 각각 5회 설정 | 핸드셰이크와 첫 응답의 안정성 확인 |
| 지속 처리량 | 같은 대용량 파일로 매회 60초 이상, 번갈아 가며 3회 테스트 | 순간적인 속도 급증과 시간대 차이의 영향 줄이기 |
| 리소스 사용량 | 테스트 중 클라이언트와 서버의 CPU 사용률 기록 | 중복 처리가 병목인지 판단 |
| 네트워크 환경 | 같은 접속 네트워크와 라우팅 규칙, 목적지 사이트 유지 | 직접 연결·프록시·회선 차이를 프로토콜 성능으로 오해하지 않도록 하기 |
위 표는 테스트 방법이며, 이 사이트에서 직접 측정한 결과가 아닙니다. 속도를 기록할 때는 단위를 구분하세요. 100 Mbps는 이론상 약 12.5 MB/s에 해당하며, 실제 애플리케이션 처리량은 프로토콜 오버헤드와 회선 상태에 따라 달라집니다. 라우팅 규칙에 따라 테스트 도메인이 직접 연결되었다면 해당 결과로 REALITY 성능을 평가할 수 없습니다.
- 웹페이지 첫 접속은 느리지만 이후 다운로드는 빠르다면 DNS, 핸드셰이크 소요 시간, 목적지 사이트 응답을 먼저 확인하세요.
- 다운로드 속도가 점차 떨어지고 CPU 사용률이 거의 최대치에 이르면 코어의 리소스 사용량과 기기 성능, 백그라운드 작업을 확인하세요.
- 혼잡 시간대에 모든 노드가 느리다면 회선과 시간대부터 비교하세요. 공개 키나 Flow를 반복해서 바꾸지 마세요.
REALITY 연결 실패 관련 자주 묻는 질문
포트 연결 테스트는 정상인데 웹페이지가 열리지 않는 이유는 무엇인가요?
TCP 포트에 연결된다는 것은 해당 포트에 접속할 수 있다는 뜻일 뿐, REALITY 인증에 성공했다는 뜻은 아닙니다. 먼저 코어 로그를 확인한 다음 주소, SNI, 공개 키, Short ID, UUID 순으로 원본 구독 정보와 대조하세요. 인증 관련 오류가 있다면 DNS를 계속 바꿔도 해결되지 않는 경우가 많습니다.
로그에 Flow를 지원하지 않는다고 표시됩니다. Flow를 비워야 하나요?
먼저 실제 실행 중인 코어와 버전을 확인한 다음 서버에서 xtls-rprx-vision을 요구하는지 살펴보세요. 서버가 Vision을 요구한다면 Flow를 비워도 올바른 설정을 대신할 수 없습니다. 코어를 업데이트하거나 전환한 뒤 코어를 재시작하고 로그를 다시 확인하세요.
Short ID에 16자를 임의로 입력해도 되나요?
안 됩니다. 16자리 16진수는 길이 상한이며 8바이트에 해당합니다. 입력값은 서버에서 허용하는 목록에도 포함되어야 합니다. 노드 메모나 UUID 일부, 일반 단어를 넣지 마세요. 가장 안전한 방법은 제공자가 준 전체 링크를 다시 가져오는 것입니다.
노드를 선택했는데 브라우저 트래픽이 프록시를 통과하지 않아요.
먼저 ‘시스템 프록시’가 설정되어 있는지 확인한 뒤 브라우저가 시스템 프록시를 사용하는지, 대상 도메인의 라우팅 규칙은 어떤지 살펴보세요. 로컬 HTTP 프록시 수신 포트를 10808로 설정했다면 브라우저에서 직접 설정할 때도 같은 포트를 지정해야 합니다. 해당 요청이 로그에 기록되었는지도 확인하세요.
같은 설정이 기기 두 대에서 다르게 작동하면 어떻게 해야 하나요?
코어 버전과 기기의 시스템 시간, 실제 네트워크 환경을 비교하세요. 핸드셰이크 인증은 시간 오차의 영향을 받을 수 있으므로 먼저 시스템 자동 시간 설정을 켜세요. 그런 다음 같은 네트워크에서 다시 테스트해 한쪽 기기의 네트워크 차단을 UUID나 공개 키 오류로 오인하지 않도록 하세요.
설정 순서: 먼저 연결하고 최적화 효과를 확인하세요
REALITY와 Vision은 각각 핸드셰이크 방식과 데이터 처리 경로에 영향을 줍니다. 설정할 때는 먼저 인증 정보가 일치하는지 확인하고, 애플리케이션 요청이 실제로 프록시를 통과하는지 검증한 뒤 성능을 비교하세요. 이렇게 하면 핸드셰이크 실패와 라우팅 문제, 대역폭 병목을 구분해 해결할 수 있습니다. 한 번에 설정 항목 열 개씩 바꾸지 않아도 됩니다.
- 전체 설정 가져오기: 제공자가 안내한 주소와 사용자 정보, 핸드셰이크 설정을 유지하고 스크린샷을 보고 직접 조합하지 마세요.
- 코어 확인: 해당 조합을 지원하는 Xray 코어를 사용하세요. 설정 항목을 인식하지 못한다면 먼저 버전을 확인하세요.
- 연결 경로 확인: 시스템 프록시와 로컬 수신 포트, 라우팅을 확인해 대상 요청이 해당 노드를 통과하는지 검증하세요.
- 테스트 결과 기록: 같은 대상과 비슷한 시간대에 여러 차례 테스트해 효과를 판단하세요. 지연 시간을 다운로드 속도로 오해하지 마세요.
구독 가져오기와 시스템 프록시의 기본 사용법은 사용 설명서에서 확인할 수 있습니다. 프로토콜과 전송 방식, 라우팅 규칙을 구분하려면 고급 안내서의 프로토콜 설명을 참고하세요. 노드 이름만 보고 ‘최신 프로토콜’을 고르는 것보다 각 기능의 차이를 이해하는 편이 안정적인 설정에 도움이 됩니다.