REALITY와 XTLS Vision 원리: 암호화 계층을 줄이면 왜 빨라질까?

REALITY, VLESS, Vision은 각각 어떤 문제를 해결할까?

세 기능은 서로 다른 계층에서 작동하며 함께 사용할 수 있지만 서로 대체할 수는 없습니다. VLESS는 프록시 요청과 사용자 식별 정보를 제공하지만 페이로드를 일반적으로 암호화하지는 않습니다. REALITY는 보안 핸드셰이크와 인증을 담당하고, Vision은 TLS 트래픽을 식별하고 패딩한 뒤 전송하는 경로에 초점을 둔 XTLS 흐름 제어 방식입니다.

VLESS + REALITY + Vision 노드는 보통 TCP 전송을 사용합니다. 클라이언트는 브라우저의 연결을 로컬 프록시로 전달하고, 코어가 프록시 서버에 연결한 뒤 서버가 대상 웹사이트에 접속합니다. 여기에는 적어도 ‘클라이언트와 프록시 서버 사이’와 ‘브라우저와 웹사이트 사이’라는 서로 다른 보안 연결이 있으므로 하나의 핸드셰이크로 혼동하면 안 됩니다.

이 기능을 실제로 처리하는 것은 클라이언트 이름이 아니라 코어입니다. v2rayN은 데스크톱 관리 인터페이스이므로 해당 노드를 사용할 때는 필요한 기능을 지원하는 Xray 코어가 선택되어 있는지 확인하세요. Android의 v2rayNG는 Xray 코어를 사용합니다. v2flyNG는 v2fly 코어를 사용하므로 VLESS를 가져올 수 있다는 이유만으로 Xray의 REALITY와 Vision 조합도 실행할 수 있다고 판단하면 안 됩니다.

• 프로토콜 계층: 구독에 포함된 VLESS와 사용자 ID가 프록시 요청의 구성 및 사용자 식별을 결정합니다.
• 보안 계층: REALITY는 서버에서 제공하는 공개 키와 서버 이름 등의 매개변수를 사용해 연결을 설정합니다.
• 흐름 제어 계층: xtls-rprx-vision은 클라이언트와 서버 모두에서 지원해야 합니다.
• 전송 계층: 일반적인 설정은 TCP를 사용합니다. 일부 인터페이스나 설정 문서에서는 RAW라고도 하므로 현재 코어의 필드에 맞춰 이해하세요.

‘TLS 위에 TLS’를 적용하면 왜 오버헤드가 생길까?

이미 암호화된 HTTPS 데이터를 다시 보호하면 프록시 계층의 처리 부담이 늘어납니다. 브라우저가 HTTPS 웹사이트에 접속하면 애플리케이션 데이터는 이미 웹사이트와의 TLS 세션으로 암호화됩니다. 기존 TLS 프록시 터널은 여기에 다시 외부 TLS 계층을 씌웁니다. 외부 계층이 웹페이지 내용을 해석할 필요는 없지만, 레코드 캡슐화와 암복호화, 버퍼링, 데이터 전달은 처리해야 합니다.

Vision의 핵심은 웹사이트 암호화를 끄는 것이 아닙니다. 조건에 맞는 내부 TLS 트래픽을 식별한 뒤 후속 데이터의 전송 방식을 바꿔, 이미 암호화된 데이터를 계속 외부 TLS 레코드에 통째로 넣지 않도록 합니다. 초기 패딩 등의 처리도 포함되므로 ‘연결 시작부터 모든 데이터를 그대로 전달한다’고 단순화해서는 안 됩니다.

복사 횟수를 줄이는 것과 암호화를 줄이는 것은 같은 일이 아닙니다. 코어 구현, 운영체제, 연결 유형에 따라 더 직접적인 데이터 경로를 사용할 수 있는지가 달라집니다. Vision을 쓴다고 모든 연결에서 제로 카피가 구현되는 것은 아닙니다. 특히 TLS 1.3 등 조건을 충족하는 내부 연결이 이러한 최적화를 이해할 때 핵심이며, 모든 UDP·동영상·다운로드 작업이 같은 비율로 빨라진다고 추정해서는 안 됩니다.

REALITY는 왜 자체 도메인 인증서가 필요 없을까?

REALITY는 일반 웹사이트의 인증서 배포와 다른 인증 방식을 사용하므로, 서버는 보통 이 프록시 연결을 위해 자체 도메인 인증서를 발급받거나 갱신할 필요가 없습니다. 서버는 개인 키를 보유하고, 클라이언트는 이에 대응하는 공개 키 등의 매개변수로 연결을 검증합니다. 이는 ‘인증이 없다’는 뜻도, 아무 웹사이트 이름이나 입력하면 연결된다는 뜻도 아닙니다.

서버에는 대상 사이트와 허용할 서버 이름도 설정해야 합니다. 인증에 실패한 연결은 REALITY의 동작 방식에 따라 설정된 대상 사이트로 전달될 수 있으며, 유효한 클라이언트는 필요한 인증을 완료합니다. 대상 웹사이트는 배포 요구사항을 충족해야 합니다. 일반적인 기준에는 TLS 1.3과 HTTP/2 지원이 포함되지만, 브라우저에서 열린다는 사실만으로 호환성이 완전히 입증되지는 않습니다.

공개 키는 보통 인코딩된 텍스트로 표시되므로 ‘32바이트’라는 이유로 입력란에 32자만 남겨야 하는 것은 아닙니다. 공개 키와 개인 키는 한 쌍으로 생성됩니다. 서버 개인 키를 클라이언트에 복사해서는 안 되며, 구독에서 제공한 공개 키를 새로 생성한 키로 바꾸면 양쪽 키가 일치하지 않습니다.

v2rayN에서 flow, 공개 키, shortId 설정하기

먼저 구독 정보를 전체 가져온 다음 제공받은 매개변수와 하나씩 대조하는 편이 직접 조합하는 것보다 안전합니다. v2rayN 기본 창에서 노드를 선택하고 더블클릭해 편집 창을 연 뒤 VLESS 노드의 전송·보안·흐름 제어 항목을 확인하세요. 인터페이스 버전에 따라 중국어 필드 이름이 다를 수 있으므로 이름이 같은 메뉴를 찾으려고 관련 없는 설정을 바꾸지 말고 필드의 의미를 기준으로 확인하세요.

아래 두 카드는 동일한 노드에 필요한 두 설정 묶음을 설명하며, 그대로 연결할 수 있는 예시 계정이 아닙니다. 포트 443은 흔한 예시일 뿐입니다. 실제 포트, 사용자 ID, 공개 키, shortId, 서버 이름은 모두 동일한 서버 설정에서 가져와야 합니다.

• flow: 일반적인 값은 xtls-rprx-vision이며 철자와 하이픈을 정확히 입력해야 합니다. 오래된 가이드의 다른 flow 값을 그대로 대신 사용하거나 Vision을 사용하지 않는 노드에 억지로 추가하지 마세요.
• 공개 키: 공유 링크에서는 보통 매개변수 이름으로 pbk를 사용합니다. 코어나 인터페이스 버전에 따라 publicKey, password 등의 필드에 해당 값이 들어갈 수 있으므로 현재 버전의 안내를 확인하세요. 원본 설정에 여러 필드를 확인 없이 동시에 입력하지 마세요.
• shortId: 보통 짝수 길이의 16진수 문자열이며, 최대 16개의 16진수 문자로 구성됩니다. 빈 값은 서버에서 허용하는 경우에만 사용할 수 있습니다. 임의로 적는 ‘노드 메모’가 아닙니다.
• 지문: chrome은 핸드셰이크 지문 옵션을 뜻합니다. 해당 브라우저로 접속해야 하는 것은 아니며 브라우저를 설치해 주는 기능도 아닙니다.

저장한 뒤 해당 노드를 다시 선택해 코어가 설정을 새로 불러오도록 하세요. 노드 목록의 항목만 수정하고 현재 실행 중인 아웃바운드를 갱신하지 않으면 로그와 편집 창의 내용이 서로 다르게 보일 수 있습니다. Android의 v2rayNG에서는 노드 편집 화면에서 관련 필드를 확인하고, 기본 화면의 로그 메뉴에서 실행 결과를 확인할 수 있습니다.

연결 실패와 속도 변화 없음, 각각 어떻게 해결할까?

성능 최적화를 생각하기 전에 연결이 어느 단계에서 멈추는지 먼저 확인하세요. 핸드셰이크가 완료되지 않았다면 Vision의 예상 처리량을 논할 의미가 없습니다. 웹사이트가 정상적으로 열린다면 속도 측정 결과가 오르지 않았다는 이유만으로 공개 키 오류라고 단정해서도 안 됩니다. 한 번에 한 항목만 변경하고, 되돌릴 수 있도록 변경 전 노드 설정을 보관하세요.

1. 코어가 실행되는지 확인: 로그에서 알 수 없는 필드, 잘못된 flow, 설정 파싱 실패 등의 오류를 먼저 확인하세요. 이 단계에서는 DNS를 바꾸기보다 코어 종류와 설정 형식을 우선 점검해야 합니다.
2. 주소와 포트 확인: 실제 연결 주소와 포트가 구독 정보와 일치하는지 확인하세요. 포트로 TCP 연결이 된다는 것은 네트워크 진입점에 접근할 수 있다는 뜻일 뿐, REALITY 인증 성공을 의미하지는 않습니다.
3. 인증 매개변수 확인: 사용자 ID, 공개 키, shortId, SNI를 대조하고 시스템 날짜와 시간이 올바른지 확인하세요. 핸드셰이크 오류는 원인이 다양하므로 연결이 종료됐다는 로그 한 줄만 보고 공개 키 오류라고 단정할 수 없습니다.
4. 앱 트래픽이 프록시를 거치는지 확인: 브라우저, 터미널, 기타 앱이 같은 연결 경로를 사용한다고 볼 수 없습니다. 먼저 로그에 해당 대상 요청이 나타나는지 살펴본 다음 시스템 프록시나 앱 자체 프록시 설정을 확인하세요.
5. 마지막으로 라우팅과 이름 해석 확인: 프록시 연결은 성공했지만 특정 도메인만 실패한다면 DNS, 분기 규칙, 대상 웹사이트 접근성을 추가로 확인하세요. 이 문제는 REALITY나 Vision과 관련이 없을 수도 있습니다.

성능을 비교하려면 서버, 대상 파일, 네트워크 접속 방식, 동시 연결 수를 동일하게 유지하고 클라이언트와 서버의 CPU 사용률, 지속 처리량, 실패 여부를 각각 기록하세요. 예를 들어 조건별로 3회씩, 매회 60초 동안 실행하고 시작 직후의 순간 최고치가 아닌 중간의 안정 구간을 관찰할 수 있습니다. 이는 테스트 방법의 예시이며 이 글에서 직접 측정한 결과가 아닙니다.

헷갈리기 쉬운 설정 문제

대부분의 오해는 ‘기능 지원’, ‘인증 성공’, ‘앱 트래픽의 프록시 경유’를 하나의 문제로 취급해서 생깁니다. 다음 질문을 차례로 확인하면 원인을 좁히는 데 도움이 됩니다. 라우팅을 더 자세히 확인하려면 사이트의 심화 설정 안내를 참고하세요.

노드를 선택할 때는 먼저 제공업체가 안내한 전체 매개변수와 코어 요구사항을 확인한 다음 현재 네트워크에 적합한지 살펴보세요. REALITY는 자체 인증서 배포 부담을 줄이고 Vision은 조건을 충족하는 TLS 트래픽에 더 효율적인 전송 경로를 제공합니다. 하지만 어느 쪽도 신뢰할 수 있는 서버, 정상적인 네트워크 연결, 정확한 클라이언트 설정을 대신할 수는 없습니다.