REALITY와 XTLS Vision 원리: VLESS의 이중 암호화 줄이기

VLESS, REALITY, Vision의 역할

노드 이름의 “VLESS + REALITY + Vision”은 서로 나란한 세 가지 프로토콜을 뜻하지 않습니다. VLESS는 프록시 프로토콜 계층에서 UUID 등의 정보로 사용자를 식별하고 목적지 주소를 전달합니다. VLESS 자체에는 VMess와 같은 데이터 암호화 기능이 없으므로 공용 네트워크에서 사용할 때는 적절한 보안 전송 방식으로 연결을 보호해야 합니다. VLESS의 encryption을 none으로 설정해도 전체 연결이 평문으로 전송되는 것은 아닙니다.

REALITY는 Xray 생태계의 보안 전송 방식입니다. TLS 핸드셰이크 특성, 서버 키, 클라이언트 인증 정보를 조합해 보호된 연결을 구성합니다. XTLS Vision은 flow 설정에 따라 초기 트래픽 처리와 패딩을 수행하고, 조건이 충족되면 전송 경로를 최적화합니다. V2Ray 이름이 들어간 클라이언트라고 해서 해당 설정을 지원하는 코어를 사용하는 것은 아닙니다. 여기서 설명하는 구현은 Xray 코어 기준입니다.

이 흐름은 각 단계의 논리적 역할을 보여 주며, 단계마다 네트워크 연결을 새로 만든다는 뜻은 아닙니다. 실제 연결에서는 인증, 핸드셰이크, 트래픽 처리가 서로 이어집니다. 문제를 진단할 때는 먼저 실패한 계층을 구분하세요. 포트 연결 실패는 연결 문제, 공개 키 불일치는 보안 핸드셰이크 문제, UUID 불일치는 프록시 인증 문제입니다. 웹 트래픽 라우팅이 잘못됐다면 대개 routing을 확인해야 합니다.

TLS 핸드셰이크로 알아보는 REALITY의 역할

브라우저가 HTTPS 사이트에 접속할 때는 먼저 지원하는 TLS 버전, 암호 스위트, 확장 정보 등을 담은 ClientHello를 보냅니다. 서버는 이에 맞는 핸드셰이크 메시지를 반환하고 양측이 키를 협상합니다. 기존 프록시의 외부 TLS 연결도 비슷한 과정을 거칩니다. 내부 연결도 브라우저와 웹사이트 간 HTTPS라면 ‘사이트 TLS가 프록시 TLS 안에 들어가는’ 구조가 됩니다.

REALITY는 유명한 도메인 이름을 임의로 입력하기만 하면 같은 핸드셰이크 특성을 얻도록 설계된 방식이 아닙니다. 서버에는 적절한 대상 사이트와 허용할 서비스 이름을 설정해야 합니다. 클라이언트에도 서버 설정에 맞는 공개 키와 shortId 등의 값이 필요합니다. 정상 클라이언트는 이 정보로 서버를 인증하고 연결을 구성하며, 대상 사이트의 일반적인 인증서 신뢰 경로에만 의존하지 않습니다.

• 연결 주소: 클라이언트가 실제로 연결하는 서버 IP 주소 또는 도메인입니다. serverName과 다를 수 있습니다.
• serverName: 핸드셰이크에 사용하는 서비스 이름으로, 보통 인터페이스의 SNI에 해당합니다. 서버에서 허용한 설정과 일치해야 합니다.
• 공개 키: 서버의 개인 키와 한 쌍을 이루며 REALITY 인증에 사용됩니다. 개인 키는 서버에 보관해야 합니다.
• shortId: 서버에서 허용하는 짧은 식별자입니다. 보통 16진수 문자열로 표시되며 UUID의 약칭이 아닙니다.

해당 인증을 통과하지 못한 연결은 REALITY 설정에 따라 대상 사이트로 전달될 수 있어 외부에서 보이는 동작이 실제 웹사이트와 비슷해집니다. 여기서 ‘빌려 쓴다’는 말은 정상적인 프록시 트래픽이 모두 해당 사이트를 경유한다거나, 대상 사이트가 프록시 서버 대신 사용자 데이터를 전달한다는 뜻이 아닙니다. 대상 사이트의 선택, 연결 가능 여부, 핸드셰이크 호환성은 배포 결과에 영향을 줍니다.

XTLS Vision은 TLS in TLS를 어떻게 줄일까요?

일반적인 암호화 프록시로 HTTPS를 전달하면 브라우저가 애플리케이션 데이터를 TLS 레코드로 암호화하고, 프록시 외부 계층에서 다시 암호화합니다. 터널 보호에는 도움이 되지만 암복호화와 캡슐화 작업이 늘고, 중첩된 트래픽 특성이 관찰될 수도 있습니다. Vision은 적합한 내부 TLS 트래픽을 식별해 조건이 충족되면 이미 암호화된 페이로드에 같은 외부 암호화 경로를 다시 적용하지 않는 것을 목표로 합니다.

Vision은 연결 초기에 데이터를 처리하고 패딩을 적용한 뒤, 식별한 TLS 상태에 따라 이후 경로를 결정합니다. 지원되는 TLS 1.3 트래픽 중 식별 가능하고 구현 조건을 충족하는 경우 최적화된 전송 단계로 넘어갈 수 있습니다. 모든 바이트와 프로토콜, 연결을 처음부터 바로 전달한다는 뜻은 아닙니다. TLS가 아니거나 조건을 충족하지 않는 연결은 계속 터널 보호가 필요합니다.

Vision은 브라우저와 대상 사이트 사이의 HTTPS 내용을 복호화할 필요가 없습니다. 사이트 인증서 검증은 계속 브라우저가 수행하며 내부 TLS의 종단 간 연결도 유지됩니다. REALITY는 클라이언트와 프록시 서버 사이의 연결을 보호하고 인증합니다. 웹사이트 TLS는 브라우저와 대상 사이트 사이의 애플리케이션 데이터를 보호하므로, 두 보안 경계를 혼동해서는 안 됩니다.

flow와 fingerprint: 클라이언트 설정 항목별 점검

v2rayN에서 현재 노드가 Xray 코어로 실행 중인지 먼저 확인한 다음 기존 VLESS 노드를 편집하세요. 일반적인 인터페이스에서는 노드를 선택하고 마우스 오른쪽 버튼을 눌러 ‘서버 편집’을 선택합니다. 수동 추가는 보통 ‘서버’ 메뉴의 VLESS 추가 항목에서 할 수 있습니다. 버전에 따라 메뉴 이름이 다를 수 있으므로 노드 메모만 보지 말고 편집 창의 프로토콜, 전송 방식, 보안, flow 항목을 확인하세요.

flow는 흐름 제어 방식이며 암호화 알고리즘을 고르는 메뉴가 아닙니다. 서버 사용자 설정과 클라이언트가 서로 호환되어야 합니다. 서버에서 Vision을 요구하는데 클라이언트의 값을 비워 두면 인증 또는 흐름 제어 검사에 실패할 수 있습니다. 오래된 자료에 나온 다른 XTLS flow 값을 xtls-rprx-vision 대신 사용하면 안 됩니다.

fingerprint는 클라이언트 TLS ClientHello의 모방 특성을 설정합니다. chrome이 자주 사용되지만, 이 값을 설정해도 프록시 프로그램이 브라우저로 바뀌거나 연결을 식별할 수 없게 되는 것은 아닙니다. 임의의 문자열은 코어에서 거부될 수 있으며 fingerprint를 자주 바꿔도 공개 키 오류는 해결되지 않습니다. 명확한 호환성 문제가 없다면 노드에 제공된 설정을 유지하세요.

{
  "flow": "xtls-rprx-vision"
}

{
  "security": "reality",
  "realitySettings": {
    "fingerprint": "chrome"
  }
}

위 내용은 각 설정이 어디에 속하는지 보여 주는 두 개의 JSON 발췌본이며, 완전한 설정 파일이 아니므로 그대로 합쳐 실행할 수 없습니다. 첫 번째 발췌본에서 flow는 VLESS 아웃바운드 사용자 객체에 있습니다. 두 번째 발췌본의 보안 설정은 streamSettings에 있습니다. 실제 설정에는 서버 주소, UUID, 서비스 이름, 키 관련 항목도 필요합니다. 공개 키의 필드 이름은 인터페이스, 공유 링크, 코어 버전에 따라 다를 수 있습니다. 클라이언트가 생성한 설정을 사용하고 버전 차이를 무시한 채 그대로 복사하지 마세요.

포트, 코어, 로그 순으로 연결 점검하기

문제를 해결하기 전에 원격 서버 포트와 로컬 프록시 포트를 구분하세요. 노드에서 사용하는 원격 포트는 서버 설정에 따라 결정되며, 443은 자주 쓰일 뿐 REALITY의 필수 포트가 아닙니다. 로컬 프록시 수신 포트는 클라이언트가 정합니다. 앱이 잘못된 로컬 포트에 연결하면 원격 노드 설정이 모두 정확해도 요청이 예상한 아웃바운드로 전달되지 않습니다.

1. 현재 설정을 기록하세요. 노드 주소, 원격 포트, UUID, flow, SNI, 공개 키, shortId의 원래 값을 보관하세요. 스크린샷을 공유할 때는 인증 정보를 가리고 구독 주소 전체를 공개하지 마세요.
2. 실행 중인 코어를 확인하세요. 시작 로그에서 코어 이름과 버전을 확인합니다. v2rayN은 여러 코어를 관리할 수 있으므로 인터페이스가 최신 버전이라고 현재 실행 중인 코어까지 바뀐 것은 아닙니다. Android용 v2rayNG는 Xray 코어를 사용합니다. V2Fly 코어를 사용하는 v2flyNG를 REALITY 설정을 위한 동등한 대안으로 취급하지 마세요.
3. TCP 연결 가능 여부를 확인하세요. 연결 시간 초과 또는 거부가 발생하면 먼저 원격 수신 포트, 방화벽, 주소 해석을 확인합니다. TCPing에 성공해도 포트에서 TCP 연결을 수립할 수 있다는 뜻일 뿐, REALITY 인증을 통과했다는 의미는 아닙니다.
4. 핸드셰이크와 인증을 확인하세요. 포트에 연결되는데 요청이 실패하면 서비스 이름, 공개 키, shortId, UUID, flow를 하나씩 비교하고 양쪽 시스템 시간을 동기화하세요. 키 오류는 라우팅 규칙으로 해결할 수 없습니다.
5. 새 요청으로 다시 테스트하세요. 설정을 저장하고 노드를 새로고침한 다음 새 웹 요청을 보내세요. 브라우저의 기존 연결은 이전 세션을 계속 사용할 수 있습니다. 로그에서 아웃바운드 태그도 확인해 요청이 실제로 대상 프록시로 들어가는지 점검하세요.

코어가 실행되고 노드 테스트도 통과하지만 일부 웹사이트만 열리지 않는다면 DNS와 routing을 확인하세요. 도메인이 직결 규칙에 먼저 매칭되거나, 앱이 시스템 프록시를 사용하지 않거나, UDP 요청이 프록시로 전달되지 않을 수 있습니다. 이런 상황에서 REALITY 공개 키를 반복해서 수정하면 변숫값만 늘어납니다. 각 설정 항목의 의미는 전체 설정 문서에서, 처음 연결하는 방법은 사용 가이드에서 확인하세요.

REALITY와 Vision 자주 묻는 질문