VMess와 VLESS는 프록시 프로토콜이지 클라이언트나 전송 방식이 아닙니다. 구독에 포함된 노드를 사용할 수 있는지 확인하려면 프로토콜, 전송 방식, 보안 계층, 실제 실행되는 코어를 함께 살펴봐야 합니다. 구독을 가져오거나 노드 설정을 확인하고 데스크톱·안드로이드 클라이언트를 고르는 사용자를 위한 글입니다. UUID, TLS, REALITY, flow의 역할을 구분하고 설정 항목별로 연결 실패 원인을 찾아보세요.
VMess와 VLESS: 인증·암호화·전송 방식부터 구분하기
노드는 ‘VMess’나 ‘VLESS’라는 라벨 하나로만 구성되지 않습니다. 일반적으로 서버 주소, 포트, 사용자 인증 정보, 전송 방식, 보안 계층이 함께 설정됩니다. 프로토콜은 프록시 요청을 전달하고 사용자를 식별하며, TCP와 WebSocket 등은 데이터를 전송합니다. TLS나 REALITY는 해당 보안 핸드셰이크와 연결 보호를 담당합니다.
VMess는 프로토콜 자체의 데이터 암호화를 지원하며, 최신 설정에서는 보통 AEAD 인증 방식을 사용합니다. 일반적인 VLESS 설정은 encryption을 none으로 지정하고 TLS나 REALITY 같은 외부 보안 계층에 연결 보호를 맡깁니다. 여기서는 흔히 쓰이는 구독 설정을 다루며, 모든 확장 기능이나 코어 구현이 동일하다는 뜻은 아닙니다.
| 비교 항목 | VMess | VLESS |
|---|---|---|
| 사용자 인증 정보 | UUID 등의 설정값으로 인증하며, 최신 방식은 AEAD를 사용합니다. | 일반적인 설정에서는 UUID로 사용자를 식별하며 서버 설정과 일치해야 합니다. |
| 데이터 암호화 | 프로토콜 자체의 데이터 암호화를 지원하며, 구체적인 알고리즘은 설정과 코어 구현에 따라 달라집니다. | 일반적인 encryption: none 설정은 프로토콜 자체의 데이터 암호화를 제공하지 않습니다. |
| 외부 보호 | TLS를 추가로 적용할 수 있습니다. 프로토콜 자체의 암호화가 있더라도 전송 관련 설정을 확인해야 합니다. | 공개 인터넷에서 흔히 쓰이는 조합은 TLS 또는 REALITY로 연결을 보호합니다. |
| 전송 방식 | 서버 설정에 따라 TCP, WebSocket 등을 조합해 사용합니다. | 코어와 서버 설정에 따라 TCP, WebSocket, gRPC 등을 조합해 사용합니다. |
| 추가 확인 항목 | 시스템 시간, 인증 방식, 기존 설정에 남아 있는 alterId를 확인합니다. | flow, 보안 계층, REALITY에 필요한 항목을 확인합니다. |
확인 순서: 전체 조합을 먼저 살펴본 뒤 프로토콜 이름 비교하기
노드 정보를 받으면 먼저 ‘프로토콜＋전송 방식＋보안 계층＋flow’를 기록하세요. VLESS라는 라벨만 보고 클라이언트를 바꾸거나 VMess의 UUID를 VLESS 노드에 복사해도 프로토콜을 전환할 수는 없습니다.
암호화 방식: VLESS의 none이 연결 전체의 평문 통신을 뜻하지는 않습니다
‘VLESS는 암호화되지 않는다’는 말에는 중요한 전제가 빠져 있습니다. 보통 encryption: none 설정에서 VLESS 프로토콜 자체가 프록시 데이터를 암호화하지 않는다는 뜻이지, 외부 보안 계층도 없다는 뜻은 아닙니다. VLESS＋TLS 노드라면 클라이언트와 TLS 종료 지점 사이의 연결이 TLS로 보호됩니다. REALITY를 사용한다면 해당 기능을 지원하는 코어가 이에 맞는 핸드셰이크를 수행해야 합니다.
반대로 VLESS＋TCP에 보안 계층도 none으로 설정되어 있다면 위와 같은 외부 보호를 받을 수 없습니다. 앱 자체의 HTTPS는 해당 앱 계층의 콘텐츠만 보호하므로 프록시 연결 전체가 암호화되었다고 볼 수 없습니다. 문제 해결을 위해 보안 계층을 함부로 끄지 말고, 인증서 검증을 비활성화한 상태를 장기적인 해결책으로 삼지 마세요.
- VMess의 UUID: 서버 인증서가 아니라 인증 정보입니다. UUID가 올바르더라도 TLS 서버 이름이 틀리면 문제를 해결할 수 없습니다.
- VMess의
security: VMess 사용자 설정에서는 보통 데이터 암호화 옵션을 뜻합니다. 전송 계층 설정에 있는 같은 이름의 항목과 혼동하지 마세요. - VLESS의
encryption: 흔히none을 사용합니다. 노드에 외부 보호가 적용되어 있는지는 TLS 또는 REALITY 설정을 추가로 확인해야 합니다. - TLS의 SNI: 핸드셰이크에 포함되는 서버 이름 정보이며, 보통 인증서 이름 확인에도 사용됩니다. 연결 주소가 IP여도 서버 이름을 임의로 비워 두면 안 됩니다.
- REALITY 설정: UUID뿐 아니라 서버에서 제공한 공개 키, 서버 이름, shortId와 클라이언트에서 요구하는 지문 등의 항목도 확인해야 합니다.
전송 조합: WebSocket, TLS, REALITY, Vision
WebSocket은 암호화 프로토콜이 아니며, TLS도 특정 프록시 프로토콜과만 함께 써야 하는 것은 아닙니다. 따라서 VMess＋WebSocket＋TLS와 VLESS＋WebSocket＋TLS는 전송 형태가 비슷해 보여도 인증과 프로토콜 처리는 다릅니다. 주소와 포트가 같더라도 클라이언트의 프로토콜 드롭다운만 바꿔서는 안 됩니다.
| 조합 | 주요 설정 항목 | 흔한 오해 |
|---|---|---|
| VMess＋WebSocket＋TLS | UUID, 암호화 옵션, WebSocket Path, Host, TLS 서버 이름 | WebSocket Host와 TLS 서버 이름을 같은 설정 항목으로 생각합니다. |
| VLESS＋WebSocket＋TLS | UUID, encryption, Path, Host, TLS 설정 | 다른 노드의 경로를 그대로 복사하거나 필요하지 않은 flow를 추가합니다. |
| VLESS＋TCP＋TLS | UUID, TLS 서버 이름. 서버에서 Vision을 요구한다면 flow도 일치해야 합니다. | 모든 VLESS 노드에 xtls-rprx-vision을 입력해야 한다고 생각합니다. |
| VLESS＋TCP＋REALITY | UUID, 공개 키, shortId, 서버 이름, 지문, 서버에서 요구하는 flow | 주소와 UUID만 가져오고 REALITY 설정을 빠뜨립니다. |
xtls-rprx-vision은 flow 설정값이지, 어떤 전송 방식에서나 사용할 수 있는 범용 가속 옵션이 아닙니다. 일반적인 Vision 조합은 TCP와 TLS 또는 REALITY를 사용합니다. 경험에만 의존해 WebSocket 노드에 입력하지 마세요. 서버에서 요구하지 않는 항목은 구독에 설정된 값을 그대로 두는 것이 좋습니다.
위 숫자는 각 설정 항목의 역할을 구분하기 위한 예시이며, 모든 노드를 수정하라는 뜻은 아닙니다. 원격 포트는 서버에서 정하고 로컬 포트는 클라이언트의 현재 설정에서 확인하세요. 원격 포트가 443이라고 해서 보안 계층을 자동으로 판단할 수는 없습니다. 오래된 가이드에 나오는 0이 아닌 alterId는 과거 설정일 수 있으므로 서버에 확인하지 않고 그대로 적용하지 마세요.
클라이언트 호환성: 화면에서 가져올 수 있어도 코어에서 실행된다는 뜻은 아닙니다
v2rayN은 데스크톱 클라이언트이며, 각 노드는 클라이언트가 선택한 코어에서 실행됩니다. v2rayNG는 Xray 코어를 사용하는 안드로이드 클라이언트이고, v2flyNG는 v2fly 코어를 사용하는 안드로이드 클라이언트입니다. 클라이언트는 구독, 화면, 라우팅 등의 관리 기능을 담당하지만, 프로토콜 조합을 실제로 사용할 수 있는지는 코어 버전과 기능 지원 여부에 따라 결정됩니다.
PC와 안드로이드에서 확인하기: 같은 구독으로 실행 여부 각각 점검
데스크톱: v2rayN
- 구독을 가져온 뒤 대상 노드의 편집 창을 열고 프로토콜, 전송 방식, 보안 계층을 확인합니다.
- VLESS＋REALITY 또는 Vision을 사용할 때는 해당 조합을 지원하는 Xray 코어가 실제로 실행 중인지 확인합니다.
- 시작 로그를 확인해 설정 구문 분석 오류와 연결 단계 오류를 구분합니다.
안드로이드: v2rayNG / v2flyNG
- v2rayNG에 포함된 Xray 코어가 구독에서 사용하는 설정 항목을 지원하는지 확인합니다.
- v2flyNG에서는 v2fly 코어의 지원 범위에 맞는 노드를 선택하고 Xray 전용 조합을 적용하지 마세요.
- 구독을 업데이트한 뒤 대상 노드를 다시 확인해 이전에 수동으로 가져온 복사본을 선택하고 있지 않은지 점검합니다.
하나의 구독에 서로 다른 프로토콜 조합이 포함될 수 있습니다. 목록이 같아도 모든 클라이언트가 모든 노드를 똑같이 지원하는 것은 아닙니다.
v2flyNG는 화면에 ‘VLESS’라고 표시된다는 이유만으로 REALITY나 Vision을 사용할 수 있다고 판단하면 안 됩니다. 앱과 코어의 실제 지원 정보를 확인하세요. VMess도 호환성 문제가 전혀 없는 것은 아닙니다. 오래된 공유 형식, 인증 방식, 전송 설정 때문에 가져온 뒤 연결되지 않을 수 있습니다.
- 먼저 클라이언트의 ‘정보’ 또는 코어 정보에서 앱과 코어의 현재 버전을 기록하고, 서비스 제공자에게 필요한 조합을 확인하세요.
- 구독 업데이트가 끝나면 이름이 같은 노드가 여러 그룹에 있는지 확인하고, 어떤 노드를 테스트할지 구분하세요.
- 오류 메시지를 전체 보관하세요. 시작 단계에서 종료된다면 라우팅 규칙을 먼저 바꾸지 말고 지원되지 않는 설정 항목부터 확인하세요.
구독 가져오기: 속도를 프로토콜 이름으로 판단하지 말고 설정 항목별로 확인하기
일반적인 VMess 공유 링크는 vmess://를 사용하고, VLESS 공유 링크는 보통 vless://를 사용합니다. 전자는 설정 데이터를 인코딩하는 경우가 많고, 후자는 URI 쿼리 매개변수에 전송 및 보안 옵션을 포함하는 경우가 많습니다. 구독은 여러 노드를 한 번에 반환할 수도 있습니다. 링크 접두사를 인식한다는 것은 파싱을 시작할 수 있다는 뜻일 뿐입니다.
문제를 확인할 때는 원본 구독 노드를 보존하고 복사본을 만들어 점검하는 것이 좋습니다. 공유 링크와 구독 주소에는 유효한 인증 정보가 포함되는 경우가 많으므로 다른 사람에게 문제 해결을 요청하기 전에 UUID, 토큰, 계정과 연결될 수 있는 정보를 가리세요. 전체 구독 주소를 공개 로그나 스크린샷에 올리지 마세요.
같은 구독에서 VMess는 되는데 VLESS는 왜 안 되나요?
연결에 실패한 노드의 편집 창을 열고 보안 계층이 REALITY인지, flow가 xtls-rprx-vision인지 확인한 뒤 현재 코어의 지원 여부를 살펴보세요. 이어서 공개 키, shortId, 서버 이름이 모두 가져와졌는지 확인합니다. 먼저 계정이 만료되었다고 단정하지 마세요.
노드 지연 시간은 표시되는데 브라우저가 열리지 않습니다. 프로토콜 호환성 문제인가요?
꼭 그렇지는 않습니다. TCP 연결 테스트에 성공했다는 것은 포트에 연결할 수 있다는 뜻일 뿐입니다. 먼저 어떤 항목을 테스트했는지 확인하고 시스템 프록시와 로컬 인바운드를 점검하세요. 실제 로컬 SOCKS 포트가 10808이라면 아래 명령으로 브라우저의 프록시 선택 과정을 건너뛰고 직접 테스트할 수 있습니다.
VMess 인증에 갑자기 실패하면 VLESS로 바꿔야 하나요?
먼저 시스템 시간 자동 동기화를 켜고 UUID를 확인한 뒤 구독을 다시 업데이트하세요. VMess 인증은 시간 정보에 영향을 받으므로 시스템 시간 차이가 크면 실패할 수 있습니다. 서버 설정도 함께 변경하지 않은 채 프로토콜 이름만 바꿔서는 인증 문제를 해결할 수 없습니다.
두 프로토콜 모두 연결된다면 어느 쪽이 더 빠른가요?
비슷한 시간대에 같은 테스트 대상을 사용해 연결 시간, 지속 다운로드 속도, 실패 여부를 각각 기록하세요. 회선, 서버 부하, 전송 방식, 테스트 조건이 비슷해야 결과를 비교할 수 있습니다. 서버가 서로 다른 노드의 속도 차이를 프로토콜 탓으로만 돌릴 수는 없습니다.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/이 명령은 로컬에서 127.0.0.1:10808을 SOCKS 인바운드로 실제 수신 중이라고 가정합니다. 클라이언트에서 다른 포트를 사용한다면 실제 포트로 바꾸세요. socks5h는 대상 도메인의 이름 확인을 프록시 측에 맡기고, --connect-timeout 10은 연결 단계의 제한 시간을 초 단위로 설정하며, -I는 응답 헤더를 요청합니다. 이는 연결 확인용이지 대역폭 테스트가 아닙니다. 요청은 코어에 전달된 뒤에도 현재 라우팅 규칙을 따릅니다.
선택 가이드: 작동하는 노드를 유지하고 서버가 제공한 조합에 맞춰 설정하기
프로토콜 선택은 이름을 한 단계 올리는 일이 아닙니다. 기존 VMess 노드가 안정적으로 작동한다면 VLESS라는 이름만 보고 설정을 직접 바꿀 필요는 없습니다. 서버에서 완전한 VLESS＋TLS 또는 REALITY 노드를 제공한다면 ‘호환성’을 이유로 VMess로 바꿀 필요도 없습니다. 양쪽에서 지원하는 프로토콜 구현과 전체 연결 설정을 맞추는 것이 중요합니다.
전체 설정이 검증된 구독을 그대로 사용하기
권장서버에서 제공한 프로토콜, 전송 방식, 보안 계층을 유지하고 코어 지원 여부를 확인한 뒤 바로 연결을 테스트하세요. 문제를 줄이려면 구독 업데이트와 라우팅 변경을 따로 진행하세요.
추천 대상: 일상적인 사용, 여러 기기에서 가져오기, 이미 작동하는 노드가 있는 경우
기존 배포 환경과 호환되도록 VMess 사용하기
서버에 VMess가 구성되어 있고 클라이언트가 해당 인증 및 전송 방식을 지원한다면 기존 설정을 유지하세요. 문제가 생기면 먼저 시스템 시간, UUID, 전송 설정을 확인합니다.
추천 대상: 기존 VMess 서버 사용, 호환성이 확인된 설정으로 문제 해결
요구사항에 맞춰 VLESS 보안 조합 사용하기
서버에서 TLS 또는 REALITY 설정을 명확히 제공한다면 해당 조합을 지원하는 코어를 선택하세요. Vision flow는 서버에서 요구할 때만 입력하고 다른 설정을 임의로 추가하지 마세요.
추천 대상: 전체 VLESS 설정을 받았고 코어 지원 범위가 명확한 경우
- 가져오기 전: 구독 출처, 노드 조합, 클라이언트 코어 요구사항을 확인하세요.
- 시작 실패: 설정 파싱 오류와 지원되지 않는 항목을 확인한 뒤 코어 선택을 살펴보세요.
- 핸드셰이크 실패: 시스템 시간, 인증 정보, 서버 이름, 보안 계층 설정을 확인하세요.
- 연결 후 접속 이상: DNS, 시스템 프록시, TUN, 라우팅 규칙을 추가로 점검하고 프로토콜을 반복해서 바꾸지 마세요.