VMess와 VLESS는 Type만 바꿔 서로 전환할 수 없습니다. 두 프로토콜 모두 UUID를 사용하지만, 인증 방식과 프로토콜 내부의 암호화 설계가 다릅니다. 이 글에서는 이미 이용 중인 서비스 제공자와 구독 정보가 있는 경우를 전제로, Shadowrocket에서 프로토콜, TLS, 전송 설정을 확인하는 방법과 연결 문제를 규칙 분기 문제와 구분해 점검하는 방법을 설명합니다.
먼저 결론: 프로토콜은 서버 설정과 일치해야 합니다
Shadowrocket에서 VMess와 VLESS 중 무엇을 선택할지는 어느 이름이 더 최신인지가 아니라, 기존 연결 정보에 지정된 유형에 따라 결정됩니다. 서버가 VMess를 받으면 클라이언트에도 해당 VMess 설정을 사용해야 하며, 서버가 VLESS를 받으면 이에 맞는 VLESS 설정이 필요합니다. 주소, 포트, UUID가 같아 보여도 Type을 바꾸면 인증이나 핸드셰이크에 실패할 수 있습니다.
프로토콜 선택과 트래픽 라우팅은 별개의 설정입니다. Home에서 선택한 서버는 프록시 연결에 사용할 매개변수를 결정하고, Global Routing은 요청의 라우팅 방식을 결정합니다. Config에서는 구성 파일과 규칙을 관리하며, Settings에는 앱 설정이 모여 있습니다. 프로토콜 문제를 점검할 때 규칙 변경, 서버 전환, TLS 변경을 한꺼번에 하면 어떤 변경이 영향을 미쳤는지 파악하기 어렵습니다.
판단 기준: 전체 설정을 먼저 확인한 뒤 프로토콜 차이를 비교하세요
기존 연결 정보의 Type, 주소, 포트, UUID, TLS, 전송 설정을 하나씩 대조하세요. 서버가 사용 가능한 VMess와 VLESS 설정을 각각 제공해야 두 연결을 비교할 수 있습니다.
암호화 차이: VMess의 프로토콜 암호화와 VLESS의 외부 보호
VMess에는 인증 및 데이터 암호화 메커니즘이 정의되어 있습니다. 일반적인 VMess AEAD 설정은 해당 인증 방식을 사용하며, 데이터 암호화 방식도 서버에서 지원하는 설정과 일치해야 합니다. VMess에 TLS를 추가로 적용할 수도 있습니다. 프로토콜 자체의 데이터 암호화와 TLS 보호는 서로 다른 계층이므로, 한쪽을 다른 쪽의 대체 설정으로 보면 안 됩니다.
VLESS 자체는 페이로드를 암호화하지 않으므로, 일반적으로 TLS와 같은 외부 메커니즘으로 전송을 보호합니다. 따라서 연결 정보의 VLESS 암호화 항목이 none이라고 해서 전체 연결이 평문이라고 단정할 수는 없습니다. 반대로 VLESS를 선택하기만 하면 TLS가 자동으로 활성화되는 것도 아닙니다. 연결 정보에서 요구하는 외부 보호 방식과 클라이언트 설정을 추가로 확인해야 합니다.
| 확인 항목 | VMess | VLESS |
|---|---|---|
| 사용자 식별 정보 | UUID를 사용하며 프로토콜 인증에 관여합니다 | UUID를 사용하며 서버가 사용자 정보를 확인합니다 |
| 프로토콜 페이로드 암호화 | 프로토콜 내부에 데이터 암호화 메커니즘이 있으며, 구체적인 옵션은 설정 정보를 확인해야 합니다 | 자체적으로 페이로드를 암호화하지 않으므로 외부 보호 방식을 확인해야 합니다 |
| TLS | 서버 요구 사항에 따라 추가할 수 있으며, VMess의 암호화 옵션과는 다릅니다 | 흔히 사용하는 외부 보호 방식이며 서버 요구 사항과 일치해야 합니다 |
| Type만 변경해도 되는가 | Type만 바꿔 VLESS로 전환할 수 없습니다 | Type만 바꿔 VMess로 전환할 수 없습니다 |
Allow Insecure는 TLS 인증서 검증과 관련된 설정입니다. 속도를 높이는 옵션도, 잘못된 UUID나 전송 경로를 해결하는 방법도 아닙니다. 인증서 오류가 발생하면 기기의 날짜와 시간, 서버 인증서, TLS에 사용할 도메인을 확인하세요. 이러한 점검 대신 인증서 검증을 건너뛰지 마세요. 표시되는 항목은 선택한 유형과 전송 설정에 따라 달라집니다.
UUID 사용법: 형식이 같아도 계정을 서로 사용할 수 있는 것은 아닙니다
UUID는 사용자 식별 정보이지 서버 주소나 구독 주소가 아닙니다. 표준 텍스트 형식은 보통 16진수 문자와 하이픈으로 구성됩니다. 예: 123e4567-e89b-42d3-a456-426614174000. 이 예시는 형식만 보여 주며 연결에 사용할 수 없습니다. 실제 UUID를 붙여넣을 때 공백, 줄바꿈, 따옴표가 포함되지는 않았는지, 공유 문자열 전체를 해당 필드에 입력하지는 않았는지 확인하세요.
두 프로토콜 모두 UUID를 사용한다고 해서 같은 UUID가 모든 서버에서 유효한 것은 아닙니다. 서버에는 해당 사용자와 인바운드 프로토콜이 설정되어 있어야 합니다. 기존 구독에 주소가 비슷하지만 유형이 다른 항목이 있다면 각 항목의 전체 설정을 그대로 유지하세요. 한 항목의 UUID, 다른 항목의 포트, 또 다른 항목의 전송 옵션을 섞어 사용하지 마세요.
- Home에서 확인할 항목을 찾아 편집 화면을 열고, Type이 VMess인지 VLESS인지 먼저 확인합니다.
- 기존 연결 정보와 주소 및 Port를 대조하세요. 주소에는 지정된 호스트 이름이나 IP만 입력하고, 프로토콜 접두사나 경로를 덧붙이지 마세요.
- UUID는 앞부분과 끝부분만 비교하지 말고 전체를 확인하세요. 문제 해결을 위해 정보를 공유할 때 실제 UUID를 공개하지 마세요.
- VMess 정보에 AlterId가 있다면 안내된 값대로 입력하세요. 일반적인 VMess AEAD 설정에서는
0을 사용하지만, 익숙한 설정이라는 이유로 다른 항목까지 임의로 바꾸면 안 됩니다. - 기기의 날짜와 시간이 정확한지 확인하세요. VMess 인증에는 시간 요소가 포함되므로 시스템 시간이 크게 틀리면 연결에 영향을 줄 수 있습니다.
전송 계층 설정: TLS, WebSocket, Host의 역할
VMess와 VLESS는 프록시 프로토콜이고, TCP와 WebSocket 등은 연결에 사용하는 전송 방식이며, TLS는 외부 보안 채널을 제공합니다. 각 설정은 함께 작동하지만 같은 의미는 아닙니다. 연결 정보에 WebSocket이 지정되어 있다면 Type과 UUID만 입력해서는 충분하지 않습니다. Path, Host, TLS 관련 요구 사항도 확인해야 합니다.
다음은 가상의 설정 예시입니다. 연결 정보에서 포트 443, WebSocket 경로 /connect, TLS 활성화를 요구한다면 이 설정을 한 묶음으로 유지해야 합니다. 443이 HTTPS에서 자주 쓰인다는 이유로 TLS 확인을 생략해서는 안 되며, WebSocket을 사용한다는 이유만으로 포트를 임의로 80으로 바꾸어서도 안 됩니다. 두 값은 단순한 포트 번호이며, 실제 수신 방식은 서버에서 결정합니다.
계층별 확인: 연결 주소와 전송 설정
서버 및 사용자 식별 계층
- Type은 서버의 VMess 또는 VLESS 설정과 일치해야 합니다.
- 주소와 Port가 연결 대상 서버를 결정합니다.
- UUID는 서버에 등록된 사용자와 일치해야 합니다.
- VMess의 추가 인증 및 암호화 항목은 연결 정보에 따라 설정합니다.
외부 보호 및 전송 계층
- TLS 활성화 여부는 서버 요구 사항과 일치해야 합니다.
- SNI는 TLS 핸드셰이크에 사용할 서버 이름입니다.
- WebSocket의 Host는 HTTP 요청 헤더에 해당합니다.
- Path는 첫 슬래시와 대소문자를 포함해 연결 정보에 적힌 그대로 유지합니다.
SNI와 Host는 같을 수도, 다를 수도 있습니다. 주소가 같다는 이유만으로 두 값을 같은 값으로 바꾸지 마세요.
gRPC 등 다른 전송 방식도 서버에서 지원해야 하며 각각 별도의 매개변수가 필요합니다. WebSocket의 Path를 모든 전송 방식에 공통으로 사용하는 경로로 간주해서는 안 됩니다. 연결 정보가 불완전하다면 누락된 항목을 임의로 입력해 반복 시도하기보다 설정 제공자에게 확인하세요. 여기서 다루지 않은 확장 옵션도 전체 설정을 기준으로 확인해야 합니다. 모든 구성을 단순히 “VLESS + TLS”로 설명할 수는 없습니다.
가져오기와 수동 입력: 전체 설정을 유지하세요
기존 구독에는 여러 항목과 각각의 매개변수가 함께 포함될 수 있어, 수동으로 옮겨 적는 일을 줄일 수 있습니다. 가져온 뒤에도 Home에서 항목의 유형과 주요 설정을 확인하세요. 표시 이름만으로 프로토콜을 판단해서는 안 됩니다. 이름에는 설명 문구가 들어갈 수 있으며, 실제 연결 방식은 항목 내부 설정에 따라 결정됩니다. 구독을 업데이트하면 원격 콘텐츠를 다시 가져오므로, 구독 항목을 로컬에서 수정한 내용은 이후 업데이트 과정에서 덮어써질 수 있습니다.
기존 구독의 전체 설정 유지
권장먼저 사용 중인 구독을 가져온 다음 Type, Port, UUID, 전송 옵션을 확인하세요. 원본 항목을 그대로 보관하면 문제 해결 후 복구하기 쉽고, 서로 다른 항목의 설정을 섞는 일을 방지할 수 있습니다.
적합한 사용자: 사용 가능한 구독이 있고 VMess와 VLESS의 차이를 확인하려는 경우
전체 연결 정보에 따라 직접 입력
Home → Add Server에서 연결 정보에 맞는 Type을 선택하고 주소, 포트, 사용자 식별 정보, 전송 설정을 차례대로 입력하세요. 주소와 UUID만 있고 TLS 또는 전송 정보가 없다면 연결 정보가 완전하다고 볼 수 없습니다.
적합한 사용자: 단일 연결의 전체 매개변수를 알고 있으며 항목별로 확인하려는 경우
변경 전후 동작을 비교하려면 원본 설정을 먼저 보관하고, 별도 항목에서 한 번에 하나씩 변경한 뒤 내용을 기록하세요. 구독 업데이트 실패와 특정 VMess 또는 VLESS 항목의 인증 실패도 별도로 다뤄야 합니다. 전자는 구독 콘텐츠를 가져오는 과정이고, 후자는 기존 설정으로 프록시 연결을 수립하는 과정이므로 원인이 같지 않을 수 있습니다.
- 가져온 뒤 원하는 항목이 보이지 않음: 구독을 정상적으로 가져왔는지, 응답에 해당 항목이 포함되어 있는지 확인하세요.
- 업데이트 후 설정이 바뀜: 최신 구독 콘텐츠와 대조하세요. 예전 항목의 스크린샷만 계속 참고하지 마세요.
- 수동으로 수정한 항목만 연결에 실패함: 먼저 원본 항목으로 복구해 확인한 다음 변경한 내용을 점검하세요.
연결 문제 점검: 인증, 전송, 라우팅을 구분하세요
지연 시간 테스트에 숫자가 표시된다고 웹페이지도 반드시 열리는 것은 아닙니다. 포트 연결 가능 여부, 프로토콜 인증 성공 여부, TLS 정상 여부, DNS 사용 가능 여부, 요청이 예상한 정책에 매칭되는지는 각각 별개의 점검 항목입니다. 테스트할 때는 동일한 기기, 네트워크, 요청 대상을 사용하세요. 이 조건을 통제하지 않으면 한 번의 속도 결과만으로 VMess나 VLESS의 고유 속도를 판단할 수 없습니다.
Global Routing의 Proxy, Direct, Config, Scene은 라우팅 방식을 나타내며 프로토콜을 변환하지 않습니다. Config는 현재 구성에 따라 요청을 처리하고, Direct는 프록시 항목의 사용 가능 여부를 확인하는 데 적합하지 않습니다. Scene은 해당 시나리오 설정과 함께 확인해야 합니다. 라우팅 문제를 배제하려면 선택한 프록시 연결을 Proxy로 임시 확인한 뒤, 테스트를 마치면 원래 설정으로 되돌리세요. 실제 요청 경로는 앱 내 요청 기록도 함께 확인해야 합니다.
UUID가 같으면 VMess를 VLESS로 바꿔도 사용할 수 있나요?
그렇게 판단할 수 없습니다. Home에서 해당 항목의 편집 화면을 열고 원래 Type으로 되돌린 뒤, 기존 연결 정보에 따라 Port, TLS, 전송 설정을 확인하세요. 서버에서 해당 VLESS 설정을 제공하는 경우에만 그에 맞는 전체 설정을 사용해야 합니다.
포트가 443인데도 TLS 문제가 표시되는 이유는 무엇인가요?
포트 443이라고 해서 TLS가 설정되어 있다고 볼 수는 없습니다. 연결 정보에 따라 TLS가 활성화되어 있는지, SNI가 정확한지, 기기 시간이 올바른지, 서버 인증서가 유효한지 확인하세요. Allow Insecure를 켜서 인증서 오류나 도메인 불일치를 감추지 마세요.
Proxy로 전환하면 접속되지만 Config로 돌아가면 실패합니다. 프로토콜을 바꿔야 하나요?
먼저 서버 항목은 그대로 두고 Config에서 현재 활성화된 구성과 요청에 적용되는 규칙을 확인하세요. 대상이 DOMAIN-SUFFIX 등의 규칙에 먼저 매칭되는지, 예상한 정책으로 연결되는지, 매칭되지 않은 요청을 FINAL이 어떻게 처리하는지 확인한 다음 DNS 설정도 점검하세요.
WebSocket 연결이 계속 실패하는데 UUID가 잘못된 건가요?
반드시 그런 것은 아닙니다. 먼저 Type, 주소, 포트를 확인한 뒤 WebSocket의 Path와 Host, TLS의 SNI를 점검하세요. 경로의 대소문자가 맞지 않거나 첫 슬래시가 빠진 경우, Host가 잘못된 경우에는 인증 전에 연결이 실패할 수 있습니다.
실제 사용에서는 먼저 서버 설정과 완전히 일치하는 항목 하나를 정상적으로 연결한 뒤 평소 사용하는 규칙 설정을 복원하세요. 프로토콜 이름만으로 회선 품질, 서버 부하, 특정 네트워크에서의 성능을 알 수는 없습니다. VLESS가 프로토콜 자체의 암호화 역할을 줄였다고 해서 어떤 환경에서든 VMess보다 빠른 것도 아닙니다. 일반 사용자에게는 프로토콜 이름만 보고 선택하기보다 전체 설정을 유지하고 계층별로 점검하는 편이 더 실용적입니다.