VMess와 VLESS는 서로 다른 프로토콜이며, 같은 서버의 속도 설정만 달리하는 것이 아닙니다. 둘 다 사용자 식별에 UUID를 자주 사용하지만 암호화 방식과 서버 설정은 다릅니다. 서비스 제공업체의 접속 정보를 보유하고 Shadowrocket의 Add Server에서 직접 입력하거나 가져온 설정을 확인하려는 사용자를 위한 안내입니다. 프로토콜, 전송 방식, TLS를 먼저 구분한 뒤 각 항목을 확인하고 동일한 조건에서 테스트해 설정 오류와 프로토콜 성능 문제를 혼동하지 않도록 합니다.
1. VMess와 VLESS의 핵심 차이
먼저 결론부터 말하면 프로토콜 유형은 서버 설정과 일치해야 합니다. VMess 서버에 연결할 때 클라이언트의 Type만 VLESS로 바꿔서는 안 되며, 반대의 경우도 마찬가지입니다. 주소, 포트, UUID가 모두 같아도 프로토콜의 핸드셰이크 형식이 다르면 연결되지 않습니다. 기존 구독은 서비스 제공업체에서 받아야 하며, 직접 입력할 때도 동일한 전체 접속 정보를 기준으로 설정하세요.
| 확인 항목 | VMess | VLESS |
|---|---|---|
| 사용자 식별자 | 일반적으로 UUID를 사용하며 서버의 사용자 설정과 일치해야 함 | 일반적으로 UUID를 사용하며 서버의 사용자 설정과 일치해야 함 |
| 프로토콜 자체 암호화 | 프로토콜 계층의 인증 및 데이터 암호화 기능을 제공하며, 구체적인 방식은 선택한 암호화 옵션에 따라 다름 | 기본 프로토콜에는 데이터 암호화가 내장되어 있지 않으므로 외부 보안 전송을 함께 고려해야 함 |
| 전송 방식 조합 | 서버 설정에 따라 TCP, WebSocket 등의 전송 방식 사용 | 서버 설정에 따라 TCP, WebSocket 등의 전송 방식 사용 |
| TLS | 프로토콜 내부 암호화 설정과는 별개의 항목 | 외부 전송 계층의 보안에 주로 사용되며 UUID를 사용한다고 생략할 수는 없음 |
| 프로토콜 유형 변경 | 해당 프로토콜을 지원하는 서버가 필요하며 클라이언트의 Type만 바꿔서는 안 됨 | |
“VLESS가 더 가볍다”는 프로토콜 설계상의 선택을 설명하는 말이지, 모든 네트워크에서 더 빠르다는 뜻은 아닙니다. 실제 사용 경험은 서버 부하, 회선 혼잡, 전송 방식, 로컬 네트워크에도 영향을 받습니다. 주소가 다른 두 서버를 비교한 속도 측정 결과만으로 VMess와 VLESS의 일반적인 우열을 판단할 수는 없습니다.
2. UUID, 암호화 방식, TLS의 역할
UUID는 사용자를 식별하는 값으로, 서버 주소나 TLS 인증서가 아닙니다. 보통 하이픈으로 구분된 16진수 문자열로 표시됩니다. 복사할 때 전체 값을 빠짐없이 옮기고 공백이나 줄바꿈이 섞이지 않도록 하세요. 같은 UUID를 여러 프로토콜에서 사용할 수 있는지는 서버에 해당 사용자가 설정되어 있는지에 따라 달라지며, 문자열 형식만으로 판단할 수 없습니다.
VMess의 암호화 옵션과 TLS 설정은 서로 다른 계층에 속합니다. VMess 프로토콜 내부에서는 AES-128-GCM, ChaCha20-Poly1305 등의 방식을 사용할 수 있습니다. 실제 설정은 서버 정보와 앱에서 제공하는 옵션을 기준으로 확인하세요. TLS가 켜져 있다고 해서 VMess의 암호화 설정을 임의로 바꿔도 되는 것은 아닙니다.
확인 순서: 보안 전송을 확인한 다음 연결 가능 여부 판단
설정이 VLESS이고 TLS가 꺼져 있다면, 먼저 서비스 제공업체에 외부 보안 전송이 명확히 구성되어 있는지 확인하세요. “UUID를 입력했다”거나 “포트가 443이다”라는 사실만으로 연결이 암호화되었다고 볼 수 없습니다.
TLS에는 서버 신원 확인도 포함됩니다. 연결 주소는 IP일 수 있지만 인증서 확인에 사용하는 Server Name은 도메인일 수 있으며, 둘이 같을 필요는 없습니다. 오류를 없애려고 인증서 검증을 바로 건너뛰지 마세요. 먼저 Server Name, 인증서 도메인, 기기의 날짜와 시간을 확인하세요. VMess 인증에도 시간 동기화가 필요하므로 기기 시간이 크게 어긋났다면 시스템의 자동 시간 설정을 복원한 뒤 다시 시도하세요.
3. Home → Add Server에서 항목별로 설정하기
Home에서 Add Server로 이동해 Type을 먼저 선택한 다음 주소와 인증 정보를 입력합니다. 프로토콜이나 전송 방식에 따라 표시되는 항목이 다르므로, 화면에 없는 값을 다른 항목에 억지로 입력하지 마세요. 앱 업데이트에 따라 화면 배치가 달라질 수 있습니다. 예전 스크린샷의 위치를 그대로 따르기보다 항목의 의미가 서버 설정과 일치하는지 확인하세요.
- Type: 서비스 제공업체가 지정한 VMess 또는 VLESS를 선택합니다. 가져온 뒤에도 메모 이름만 보지 말고 유형을 확인하세요.
- Address 및 Port: Address에는 연결할 호스트 이름이나 IP만 입력하고 전체 공유 링크를 붙여 넣지 마세요. Port는 서비스 제공업체가 안내한 값을 사용합니다. 예를 들어 설정에 8443이라고 되어 있다면 TLS를 켰다는 이유로 443으로 바꾸면 안 됩니다.
- UUID: 사용자 식별자 전체를 빠짐없이 복사합니다. VMess에 별도의 Alter ID 값이 있다면 실제 접속 정보를 따르세요. 최신 VMess AEAD 설정에서는 보통 0을 사용하며, VLESS는 VMess의 Alter ID 방식을 사용하지 않습니다.
- VMess 암호화 설정: 서비스 제공업체가 지정한 방식을 확인하세요. 프로토콜 암호화 옵션과 TLS, WebSocket을 하나의 설정으로 혼동하지 마세요.
- 전송 설정: 제공된 정보에 따라 TCP나 WebSocket 등을 선택합니다. WebSocket을 사용한다면 Host와 Path도 확인하세요. Path 앞에 붙는 슬래시도 설정값의 일부입니다.
- TLS 및 Server Name: TLS 사용 여부, 확인할 도메인, 추가 요구 사항을 점검하세요. Flow 등의 확장 매개변수가 제공된 경우 현재 선택한 설정에서 지원되는지, 값이 올바르게 지정되었는지도 확인해야 합니다.
4. TCP와 WebSocket: 전송 설정을 따로 확인하기
VMess와 VLESS는 프록시 프로토콜을, TCP와 WebSocket은 전송 방식을 설명하며 TLS는 보안 전송의 한 부분입니다. 예를 들어 “VLESS + WebSocket + TLS”는 함께 사용하는 설정 조합이지, 서로 바꿔 쓸 수 있는 프로토콜 옵션 세 가지가 아닙니다. 서버에서 WebSocket을 사용한다면 UUID와 TLS만 올바르게 입력해도 연결이 완성되지 않습니다.
자주 쓰이는 전송 조합별 확인 사항
TCP + TLS
- Address, Port, UUID를 확인합니다.
- 전송 방식이 서버 설정과 일치하는지 확인합니다.
- TLS의 Server Name과 인증서 검증을 확인합니다.
- 서비스 제공업체가 추가 매개변수를 안내했다면 각 항목의 지원 여부를 확인합니다.
WebSocket + TLS
- 먼저 주소, 포트, UUID, TLS를 확인합니다.
- 그다음 WebSocket의 Host를 글자 단위로 확인합니다.
- Path의 대소문자, 슬래시, 필요한 쿼리 매개변수를 그대로 유지합니다.
- 연결 주소, Host, Server Name의 용도를 구분합니다.
Address, Host, Server Name이 모두 같다고 가정하지 마세요. 각각 연결 대상, WebSocket 요청, TLS 서버 신원 확인에 사용됩니다.
예를 들어 연결 주소가 edge.example.com, WebSocket Host가 ws.example.com, Server Name이 tls.example.com일 수 있습니다. 특정 서버 구성에서는 세 항목이 서로 다를 수 있으며, 실제 값은 해당 설정을 따라야 합니다. 세 항목을 모두 연결 IP로 바꾸면 TLS 검증에 실패하거나 요청이 올바른 서버로 전달되지 않을 수 있습니다.
5. 연결 테스트: Global Routing의 영향을 먼저 확인하기
서버를 저장한 뒤 Home에서 해당 서버를 선택하고 Global Routing을 확인하세요. 이 설정은 트래픽을 어떻게 분배할지 결정할 뿐, VMess를 VLESS로 바꾸지는 않습니다. Config는 설정된 규칙에 따라 트래픽을 처리하고, Proxy는 프록시 처리 대상 트래픽을 프록시로 전달하며, Direct는 직접 연결합니다. Scene은 설정된 시나리오에 따라 처리하므로 이름만으로 실제 트래픽 경로를 판단할 수 없습니다.
Config: 평소 규칙으로 돌아가기
권장서버를 개별적으로 테스트해 사용할 수 있는지 확인한 뒤 Config에서 실제 규칙이 어떻게 적용되는지 확인하세요. 규칙에 따라 PROXY, DIRECT 또는 REJECT가 지정될 수 있으므로 모든 요청이 현재 서버를 거친다고 가정하면 안 됩니다.
적합한 경우: 기존 설정으로 평소처럼 사용하거나 트래픽 분배 규칙을 확인할 때
Proxy: 규칙의 영향을 잠시 분리하기
테스트 중에는 Proxy를 임시로 선택하고 같은 서버와 테스트 대상을 유지해 규칙 때문에 직접 연결되는 상황을 줄이세요. 테스트가 끝나면 기존 Global Routing 설정으로 복원합니다.
적합한 경우: 문제 원인이 서버 연결인지 트래픽 분배 규칙인지 확인할 때
Direct: 로컬 네트워크 기준 상태 확인
로컬 네트워크에서 원래 직접 연결할 수 있는 대상에 접속되는지 확인할 때 사용합니다. 이 상태에서 웹페이지가 열린다고 VMess 또는 VLESS 서버가 정상이라는 뜻은 아닙니다.
적합한 경우: Wi-Fi, 셀룰러 네트워크, 로컬 연결 문제를 배제할 때
테스트에서는 한 번에 조건 하나만 바꾸세요. 네트워크, 서버, 대상을 고정한 상태에서 시간 초과 여부, TLS 오류 여부, 특정 사이트만 실패하는지 기록한 다음 로컬 네트워크를 바꿔 다시 테스트합니다. 포트에 연결되거나 지연 시간이 표시된다는 것은 해당 테스트에 응답이 있었다는 뜻일 뿐, 프록시 인증과 전송 경로, 전체 요청이 정상이라는 보장은 아닙니다.
- 연결 직후 TLS 오류가 발생하는 경우: UUID를 바꾸기 전에 Server Name, 기기 시간, 인증서 검증을 확인하세요.
- WebSocket 핸드셰이크에서 404 등의 HTTP 상태가 표시되는 경우: 먼저 Host, Path, 서버의 전달 경로를 확인하세요. 상태 코드만으로 UUID가 올바르다고 판단할 수는 없습니다.
- 오랫동안 시간 초과가 발생하는 경우: 먼저 Address, Port, 네트워크 연결 상태를 확인한 뒤 전송 방식과 인증 정보를 점검하세요. 시간 초과만으로 특정 항목의 문제라고 단정할 수는 없습니다.
- Proxy에서는 연결되지만 Config에서 일부 대상이 실패하는 경우: 프로토콜을 바로 바꾸기보다 Config의 규칙 순서와 적용 정책을 확인하세요.
6. 가져오기, 업데이트, 자주 발생하는 설정 문제
기존 구독은 서비스 제공업체가 안내한 가져오기 방법으로 추가한 뒤, 가져온 설정의 Type, 전송 방식, TLS 정보를 확인하세요. 구독 업데이트로 서버 설정이 덮어써질 수 있으므로 직접 수정하기 전에 원래 정보를 보관하세요. 업데이트 후 문제가 생기면 주소, 포트, 전송 설정이 바뀌었는지 먼저 비교하세요. 여러 항목을 연달아 수정한 뒤 이전 값을 기억하려고 하지 마세요.
UUID가 있는데도 연결되지 않는 이유는 무엇인가요?
UUID는 사용자 식별 문제의 일부만 해결합니다. Home → Add Server에서 해당 서버의 편집 화면을 열고 Type, Address, Port, UUID, 전송 방식, TLS 순서로 확인하세요. 특히 WebSocket의 Host와 Path, TLS의 Server Name을 빠뜨리지 마세요.
VMess를 VLESS로 바꾸면 더 빨라지나요?
그렇게 바꿀 수는 없습니다. 서비스 제공업체에서 VLESS에 맞는 전체 접속 정보를 받아 별도의 서버 항목으로 저장하세요. 서버, 회선, 테스트 조건이 비교 가능할 때만 테스트 결과에 의미가 있습니다. 회선이 다르면 성능 차이를 프로토콜 이름 탓으로 돌릴 수 없습니다.
구독을 업데이트한 뒤 이전에 수정한 Path가 사라졌다면 어떻게 해야 하나요?
먼저 구독에서 설정이 다시 내려온 것인지 확인하고 서비스 제공업체에 최신 값을 문의하세요. 임시로 확인해야 한다면 해당 설정을 별도의 수동 항목으로 저장해 테스트하세요. 구독이 관리하는 항목을 장기간 수동 설정처럼 사용하지 않는 것이 좋습니다. 확인되지 않은 이전 Path를 반복해서 입력하지 마세요.
On Demand를 켜면 프로토콜 오류를 해결할 수 있나요?
아니요. Settings → On Demand는 필요할 때 연결하는 조건을 관리하며 UUID, TLS, 전송 설정 오류를 수정하지 않습니다. 먼저 수동 연결이 되는지 확인한 다음 On Demand 설정을 점검하세요. 테스트 중에는 자동 연결 상태가 달라져 판단을 방해하지 않도록 트리거 조건을 일정하게 유지하세요.
마지막으로 확인할 사항은 간단합니다. 프로토콜 유형을 서버 설정과 일치시키고, 전송 방식과 TLS 항목을 하나씩 대조한 뒤, 요청이 예상한 정책에 따라 전달되는지 확인하세요. 원인을 찾기 어렵다면 “VMess가 느리다” 또는 “VLESS가 연결되지 않는다”고만 설명하기보다 인증 정보를 가린 설정 항목, 네트워크 종류, 오류 증상을 서비스 제공업체에 전달하는 편이 문제 해결에 도움이 됩니다. 자세한 조작 방법은 서버 관리와 Global Routing 사용 안내를 참고하세요.