VMess와 VLESS의 차이: 일반 사용자가 알아야 할 4가지

인증: 같은 UUID, VMess는 alterId가 하나 더

두 프로토콜 모두 UUID로 사용자 신원을 식별합니다. 서버는 clients 배열에 UUID 문자열을 고정해 두고, 클라이언트 설정의 id는 문자 단위로 정확히 일치해야 하며 한 글자만 달라도 인증에 실패합니다. 이 점만 보면 VMess와 VLESS는 차이가 없습니다.

차이는 VMess 초기에 추가된 alterId 필드에서 나옵니다. UUID에서 파생한 임시 식별자 묶음을 타임스탬프와 함께 사용해 재전송 공격을 막는 방식이며, 예전 기본값은 64였습니다. 대신 클라이언트와 서버의 시간 차이를 90초 이내로 유지해야 해서, 시스템 시간이 틀어지거나 시간대가 다른 환경에서는 연결이 안 되는 일이 잦았습니다.

2022년 1월에 공개된 V2Ray v4.35에서 alterId는 폐기 예정으로 표시되었고, v5에서는 필드 자체가 제거되었습니다. 지금 v2rayN 6.x에서 VMess 노드를 새로 만들면 alterId 기본값이 0이고 AEAD 인증을 사용하므로 타임스탬프를 검사하지 않습니다. 양쪽 모두 0으로 맞추면 이 차이는 사실상 사라집니다.

VLESS는 설계 단계부터 alterId가 없었고, 재전송 방어는 전송 계층에 맡기며 서버가 세션 상태를 유지할 필요도 없고 프로토콜 헤더도 더 짧습니다. 그래서 첫 번째 항목은 한 문장으로 정리됩니다. 최신 버전에서는 둘 다 똑같이 단순하고, alterId가 0이 아닌 예전 노드를 만났을 때만 시간 동기화를 신경 쓰면 됩니다.

전송 계층 의존성: VLESS는 이중 암호화를 하지 않음

VMess 프로토콜에는 자체 암호화 계층이 있습니다. TLS를 적용하지 않아도 VMess 트래픽 자체가 암호화되며, 설정의 security 필드에 auto, aes-128-gcm, chacha20-poly1305, none을 넣을 수 있습니다. 덕분에 TCP로 그대로 돌릴 수 있고, TLS에 의존하지 않는 mKCP 같은 전송 방식과도 조합할 수 있습니다.

VLESS는 반대입니다. 프로토콜 자체는 인증과 전달만 담당하고 바이트 하나도 암호화하지 않으며, 설정에는 "encryption": "none"이 고정으로 들어가고 페이로드는 평문 그대로 전송 계층에 넘깁니다. TCP로 그대로 돌리는 VLESS는 평문 전송과 같으므로 실제 배포에서는 반드시 TLS, XTLS 또는 REALITY를 적용해야 합니다.

{
  "outbounds": [{
    "protocol": "vless",
    "settings": {
      "vnext": [{
        "address": "node.example.com",
        "port": 443,
        "users": [{
          "id": "b831381d-6324-4d53-ad4f-8cda48b30811",
          "encryption": "none",
          "flow": "xtls-rprx-vision"
        }]
      }]
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality"
    }
  }] // VLESS 아웃바운드: 암호화는 REALITY 전송 계층에 맡김
}

자주 쓰이는 VLESS 배포 조합은 세 가지입니다:

• VLESS + TCP + TLS: 443 포트, 가장 단순한 구성, 자체 도메인과 인증서 필요
• VLESS + XTLS Vision + REALITY: Xray 코어에서 지원, 도메인과 인증서를 직접 준비할 필요 없음
• VLESS + WebSocket + TLS: CDN 중계를 쓸 때 사용하며, VMess의 같은 조합과 구조가 동일

REALITY와 XTLS Vision은 현재 VLESS에만 구현되어 있고 VMess에는 없습니다. 노드 정보에 flow: xtls-rprx-vision 또는 security: reality가 보인다면 그것은 반드시 VLESS입니다.

암호화 오버헤드: 2계층과 1계층의 실제 차이

차이를 CPU 오버헤드로 환산하면 더 직관적입니다. VMess가 TLS를 쓸 때는 암복호화가 두 번 일어납니다. 바깥 TLS에서 한 번, 프로토콜 내부에서 한 번입니다. VLESS는 바깥 TLS 한 번뿐입니다. 암복호화는 매번 CPU 사이클을 소모하므로 연결 수가 많을수록 차이가 커집니다.

이 차이가 체감되는 기기는 무엇일까요? 데스크톱의 최신 프로세서에서는 사실상 측정이 어렵습니다. 단일 코어 저사양 서버나 오래된 스마트폰, 공유기에서는 VLESS가 아낀 한 계층이 연결 수와 처리량으로 나타납니다.

클라이언트 호환성: 코어 버전이 VLESS 사용 가능 여부를 결정

VLESS를 쓸 수 있는지는 클라이언트에 내장된 코어 버전에 달려 있습니다. v2rayN 6.x는 기본적으로 Xray 코어를 사용해 VMess와 VLESS를 모두 지원하고, v2rayNG도 Xray 코어 기반입니다. v2flyNG는 v2fly 코어를 사용하며 v4.27부터 VLESS를 지원하지만 REALITY는 지원하지 않습니다.

버전 번호는 넘을 수 없는 기준입니다. V2Ray 코어 v4.26 이하에서는 vless:// 링크를 인식하지 못하므로, 구독에 VLESS 노드가 섞여 있으면 가져오기 자체가 실패합니다. 확인 방법: v2rayN 메인 화면에서 '설정' → '매개변수 설정' → 'Core: 기본 설정'으로 들어가면 되고, Xray 코어 버전은 1.x, v2fly 코어는 4.x 또는 5.x입니다.

공유 링크의 접두사로도 구분할 수 있습니다. vmess:// 뒤에는 base64로 인코딩된 JSON이 오고, vless://는 vless://uuid@주소:포트?파라미터#메모 형태의 URI 쿼리 문자열입니다. 한 구독 안에 두 링크를 함께 담아도 클라이언트가 접두사별로 따로 파싱하므로 노드 목록에 항목이 몇 개 더 늘어날 뿐입니다.

언제 신경 써야 할까

네 가지 비교 항목을 일상 사용에 대입해 보면, 프로토콜 차이를 실제로 신경 써야 하는 상황은 세 가지뿐입니다.

나머지 두 가지는 판단이 더 간단합니다. 기기 성능이 빠듯하면 암복호화가 한 계층 적은 VLESS를 우선하고, CDN 중계가 필요하거나 구형 클라이언트를 함께 지원해야 하면 VMess + WebSocket + TLS의 적용 범위가 더 넓습니다.

프로토콜은 서버와 클라이언트 사이의 약속이며, 아무 때나 바꿀 수 있는 스위치가 아닙니다. 이 네 가지 차이만 구분해도 일상적인 노드 사용과 연결 문제 해결에는 충분합니다.