VMess·VLESS·Trojan·Shadowsocks 프로토콜 비교 및 사용 상황별 선택

이 글 미리 보기

프로토콜을 고르기 전에 서버에서 제공하는 설정을 확인하고 클라이언트 코어, 전송 방식, 보안 계층이 맞는지 살펴보세요. 네 가지 프로토콜의 암호화 범위를 설명하고 데스크톱·Android·여러 기기에서의 선택 순서와 동일한 조건으로 회선을 비교하는 방법을 소개합니다. 노드나 구독 정보를 받은 뒤 설정이 맞는지 확인하려는 사용자에게 적합합니다.

프로토콜·전송 방식·보안 계층·클라이언트 구분하기

노드 이름에 적힌 “VLESS + WebSocket + TLS”는 세 프로토콜이 서로 경쟁한다는 뜻이 아닙니다. VLESS는 프록시 요청과 인증을, WebSocket은 데이터 전송을, TLS는 해당 연결 구간의 보안을 담당합니다. “VLESS”라는 이름만 보고 속도나 보안을 판단하기에는 정보가 부족합니다.

v2rayN은 데스크톱 클라이언트이지 다섯 번째 프록시 프로토콜이 아닙니다. 노드를 가져오고 선택하며 실행 설정을 관리하고, 실제 연결은 선택한 코어가 처리합니다. Android용 v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 같은 코어 계열이라도 버전에 따라 지원하는 기능은 다를 수 있습니다.

프록시 프로토콜: VMess, VLESS, Trojan, Shadowsocks가 있으며 클라이언트와 서버가 프록시 요청을 주고받는 방식을 정합니다.
전송 방식: TCP, WebSocket, gRPC 등이 있으며 서버에서 실제로 제공하는 방식과 일치해야 합니다.
보안 계층: TLS, REALITY 등은 각각 필요한 설정이 다르므로 드롭다운 옵션 하나만 바꿔서는 전환할 수 없습니다.
라우팅 및 트래픽 처리: 어떤 앱과 대상에 프록시를 적용할지 정하는 기능으로, 노드 프로토콜과는 별개입니다.

네 가지 프로토콜의 암호화 방식과 호환 조건

비교할 때는 프로토콜 이름에 “가장 빠름”이나 “가장 안전함”이라는 꼬리표를 붙이기보다 전체 구성을 살펴봐야 합니다. 아래 표는 일반적인 배포 사례를 정리한 것으로, 실제 사용 가능한 설정 항목은 노드 제공업체의 안내와 코어 버전, 설정 사양을 따릅니다.

프로토콜	인증 및 암호화	주요 설정	유지해도 좋은 조건
VMess	일반적으로 UUID로 인증하며, 최신 구성에서는 VMess AEAD를 사용합니다. 데이터 암호화 방식은 설정에 따라 달라집니다.	UUID, 암호화 옵션, 전송 매개변수, 기기 시간	기존 접속 지점이 안정적으로 작동하고 클라이언트와 서버의 매개변수가 정확히 일치하는 경우
VLESS	일반적으로 UUID로 인증합니다. 흔한 구성에서는 프로토콜 암호화 필드가 none이며, 보안은 함께 설정된 보안 계층에 의존합니다.	TLS 또는 REALITY 매개변수. Vision을 사용하는 경우 flow와 전송 방식 지원 여부도 확인해야 합니다.	서버에서 전체 설정을 제공하고 클라이언트 코어가 해당 조합을 지원하는 경우
Trojan	비밀번호로 인증하며 일반적인 배포에서는 TLS로 프록시 데이터를 보호합니다.	비밀번호, 서버 이름, 인증서 검증, 포트	정상적으로 관리되는 TLS 접속 지점이 있고 설정 관계가 명확한 구성을 원하는 경우
Shadowsocks	사전 공유 키를 사용합니다. 최신 AEAD 방식과 Shadowsocks 2022 방식은 키 요구 사항이 서로 다릅니다.	암호화 방식, 키 형식, TCP 및 UDP 지원 여부	서버와 클라이언트가 호환되는 최신 암호화 방식을 제공하고 간결한 연결 설정을 우선하는 경우

VMess: 기존 설정에서는 AEAD와 시간을 먼저 확인하세요

VMess라고 해서 “오래된 노드는 사용할 수 없다”는 뜻은 아닙니다. 기존 회선이 안정적이라면 프로토콜 이름만 보고 바꿀 필요는 없습니다. 최신 VMess 구성에서 alterId는 대개 0입니다. 오래된 튜토리얼을 따라 비영(非零) 값을 임의로 입력하지 마세요. 시스템 시간이 크게 어긋나면 인증에 실패할 수 있으니 문제를 해결할 때 자동 시간 동기화를 켠 뒤 UUID와 전송 매개변수를 확인하세요.

VLESS: 경량 프로토콜이라고 보안 계층이 생략되는 것은 아닙니다

일반적인 VLESS 노드에서 encryption=none이라고 해서 연결 전체에 보호 기능이 없다는 뜻은 아닙니다. 외부 계층에 TLS나 REALITY가 설정되어 있는지도 확인해야 합니다. 반대로 이 필드만 보고 “기본적으로 안전하다”고 판단해서도 안 됩니다. REALITY와 Vision은 VLESS의 다른 이름이 아니므로 각각 지원 여부를 확인하세요. 노드에서 제공하지 않는 기능을 임의로 설정에 추가하지 마세요.

Trojan과 Shadowsocks: 비밀번호가 같아도 호환되는 것은 아닙니다

Trojan 비밀번호가 TLS 인증서 검증을 대신하지는 않습니다. 인증서 오류가 발생하면 검증을 계속 건너뛰기보다 도메인, 서버 이름, 인증서 체인을 확인하세요. Shadowsocks는 암호화 방식과 키가 모두 일치해야 합니다. 예를 들어 chacha20-ietf-poly1305와 2022-blake3-aes-128-gcm은 임의로 서로 바꿔 쓸 수 없으며, 후자는 규격에 맞는 키 형식도 필요합니다.

데스크톱 일상 사용: 설정이 완전하고 실제로 안정적인 접속 지점부터 선택

아래의 “추천”은 서버를 새로 구성할 수 있고 클라이언트가 해당 기능을 지원하는 상황에서 주력 설정을 새로 만들 때를 기준으로 합니다. 모든 환경에 적용되는 순위는 아닙니다. 기존 노드가 안정적으로 작동한다면 프로토콜을 자주 바꾸기보다 그대로 사용하는 편이 대체로 수월합니다.

VLESS: 보안 계층을 완전히 설정한 구성

Trojan: 이미 구축된 TLS 접속 지점

도메인과 인증서, 안정적인 서버가 이미 있다면 제공업체가 안내한 매개변수에 따라 바로 사용할 수 있습니다. 인증서 갱신과 비밀번호 관리도 유지 관리에 포함됩니다.

적합한 경우: 사용 가능한 TLS 구성이 이미 있고 기존 접속 지점을 계속 활용하려는 경우

Shadowsocks: 간결한 설정

클라이언트와 서버가 모두 지원하는 최신 암호화 방식을 선택하세요. 설정 항목은 적지만 연결 가능 여부는 네트워크 환경에 따라 달라지므로 어떤 네트워크에서도 더 빠르다고 단정할 수 없습니다.

적합한 경우: 안정적인 서버가 있고 설정이 간결한 일상 연결을 원하는 경우

VMess: 안정적인 기존 노드 유지

구독에 이미 작동이 확인된 VMess 노드가 있다면 먼저 실제 접속을 테스트하세요. 전송 및 보안 매개변수가 정확히 일치하는지 확인하고 프로토콜 이름만을 이유로 회선을 바꾸지 마세요.

적합한 경우: 현재 구독과 기기가 안정적으로 작동하는 환경

Windows에서 v2rayN을 테스트할 때는 메인 화면의 「시스템 프록시」 메뉴에서 「시스템 프록시 자동 설정」을 선택한 뒤 브라우저가 시스템 프록시를 따르는지 확인하세요. 화면 버전에 따라 메뉴 이름이 다를 수 있습니다. Linux와 macOS에서는 데스크톱 환경의 프록시 설정도 확인해야 합니다. 활성 노드만 바꿔도 모든 앱의 트래픽이 자동으로 프록시를 통과하는 것은 아닙니다.

리소스 사용량 측정: 포트·지연 시간·처리량을 따로 확인

같은 프로토콜에서 회선을 바꿨을 때의 차이가 같은 회선에서 프로토콜만 바꿨을 때보다 클 수 있습니다. CPU의 하드웨어 가속 지원, TLS 핸드셰이크 횟수, 전송 캡슐화, 네트워크 패킷 손실이 모두 결과에 영향을 줍니다. “VLESS가 항상 배터리를 덜 쓴다”거나 “Shadowsocks가 무조건 빠르다”는 주장은 테스트 조건이 빠져 있습니다.

443

일반적인 TLS 서버 포트(실제 설정에 따라 다름)

10808

로컬 수신 포트 예시(클라이언트 설정 확인 필요)

8388

Shadowsocks 서버 포트 예시(고정된 요구 사항 아님)

세 포트의 예시는 원격 접속 지점과 로컬 수신 포트의 차이를 보여줍니다. 원격 포트를 443으로 설정해도 HTTPS의 모든 속성이 자동으로 적용되거나 인증서가 올바르게 설정되는 것은 아닙니다. 브라우저에서 프록시를 직접 설정할 때는 원격 서버 주소가 아니라 로컬 주소와 해당 프로토콜의 수신 포트를 입력해야 합니다.

환경 고정: 가능한 한 같은 서버, 같은 네트워크, 같은 테스트 대상을 사용하세요. 라우팅 모드도 고정해 한쪽은 직접 연결하고 다른 쪽은 프록시를 사용하는 상황을 피합니다.
연결 가능 여부부터 확인: TCPing은 포트 수준의 연결 여부만 알려줄 뿐 인증, TLS, 프록시 요청의 성공을 보장하지 않습니다. 실제 연결 테스트와 웹페이지 접속도 진행하세요.
반복 측정: 각 구성에서 실제 연결 테스트를 5회 수행하고 실패 횟수와 성공 결과의 중앙값을 기록하세요. 가장 작은 값만 골라 기록하지 마세요.
지속 부하 테스트: 같은 테스트 리소스에 60초 동안 접속해 처리량과 CPU 사용량을 기록하세요. 모바일 기기는 같은 사용 시간 동안의 배터리 소모도 확인하고, 짧은 테스트 한 번으로 프로토콜 순위를 매기지 마세요.

Android 배터리 절약과 여러 기기 공유: 먼저 트래픽 처리 범위 조정

모바일 기기의 배터리 소모는 암호화 연산뿐 아니라 백그라운드 앱의 지속적인 네트워크 사용, 잦은 재연결, 약한 신호 때문에도 커집니다. v2rayNG의 로컬 VPN 방식과 원격 프록시 프로토콜은 서로 다른 계층입니다. 로컬 VPN 인터페이스를 켜도 원격 노드의 프로토콜이 바뀌는 것은 아닙니다.

일상적인 사용에서는 v2rayNG의 「설정」→「앱별 프록시」에서 트래픽 처리 범위를 확인하세요. 현재 모드가 “선택한 앱만 프록시 사용”인지 “선택한 앱 제외”인지 살펴보고, 정확한 메뉴 이름은 앱 버전을 기준으로 확인하세요. 브라우저에만 프록시가 필요하다면 불필요한 백그라운드 트래픽을 먼저 줄인 뒤 프로토콜별 배터리 사용량을 비교해야 의미 있는 결과를 얻기 쉽습니다.

데스크톱과 Android에서 함께 사용: 같은 구독을 쓰고 지원 기능은 각각 확인

데스크톱: v2rayN

필요한 프로토콜과 전송 방식을 지원하는 코어를 선택합니다.
가져온 뒤 서버, 포트, 보안 계층 항목을 확인합니다.
앱에 따라 시스템 프록시 또는 다른 트래픽 처리 방식을 선택합니다.
구독을 업데이트한 뒤 현재 활성 노드를 다시 확인합니다.

Android: v2rayNG / v2flyNG

v2rayNG는 Xray를, v2flyNG는 V2Fly를 사용합니다.
실제 앱 버전에서 노드 기능을 지원하는지 확인합니다.
필요에 따라 앱별 프록시와 라우팅 규칙을 설정합니다.
Wi-Fi와 모바일 데이터에서 각각 연결을 테스트합니다.

같은 구독을 사용하면 설정 출처를 동기화하기 쉽지만, 코어나 버전이 다르면 사용 가능한 노드를 완전히 똑같이 해석한다고 보장할 수는 없습니다.

여러 기기에서 공유하려면 서비스 제공업체의 기기 수, 동시 연결, 데이터 사용량 제한도 확인해야 합니다. 구독 주소에는 접속 인증 정보가 포함되는 경우가 많으므로 일반 URL처럼 공개하지 마세요. 자체 서버에서 기기별로 권한을 철회해야 한다면 서버에서 다중 사용자 설정을 지원하는지 확인한 뒤 기기마다 별도의 UUID, 비밀번호 또는 키를 할당할 수 있습니다.

연결 실패와 UDP 사용: 증상별 점검 방법

동영상이 재생된다고 UDP까지 연결된 것은 아니며, 웹페이지가 열리지 않는다고 프로토콜을 잘못 선택한 것도 아닙니다. 노드 변경에 앞서 클라이언트 미실행, 인증 실패, 인증서 오류, DNS 조회 실패, 라우팅 규칙 미적용을 구분하세요.

노드 지연 시간은 낮은데 웹페이지가 열리지 않는 이유는 무엇인가요?

먼저 표시된 결과가 TCPing인지 실제 연결 테스트인지 확인하세요. v2rayN에서 현재 활성 노드와 시스템 프록시 상태를 확인한 뒤 클라이언트 로그에서 인증, TLS, 포트 점유 오류를 살펴보세요. 마지막으로 브라우저가 시스템 프록시를 우회하지 않도록 브라우저 자체의 프록시 설정도 확인하세요.

VLESS 설정을 가져왔는데 연결이 바로 실패하는 이유는 무엇인가요?

서버, 포트, UUID, 전송 방식, 보안 계층을 하나씩 확인하세요. REALITY 접속 지점은 제공업체에서 요구한 공개 키, shortId, 서버 이름 등의 항목도 확인해야 하며, Vision 구성은 flow 설정이 일치해야 합니다. 가져오기에 성공했다는 것은 링크를 해석했다는 뜻일 뿐, 코어가 모든 항목을 지원한다는 의미는 아닙니다.

Trojan에서 인증서 오류가 표시되면 검증을 바로 건너뛰어도 되나요?

먼저 기기 시간을 맞춘 다음 서버 이름이 인증서에 포함된 도메인인지, 서버 인증서가 만료되지 않았는지, 인증서 체인이 완전한지 확인하세요. 인증서 검증을 계속 건너뛰는 것으로 문제를 대신하지 마세요. IP 주소로 연결하더라도 올바른 서버 이름 설정을 유지해야 합니다.

음성 통화나 게임에 UDP가 필요한데 네 가지 프로토콜을 모두 바로 사용할 수 있나요?

프로토콜 계층에서 UDP를 전달할 수 있어도 현재 연결 경로에서 사용할 수 있다는 뜻은 아닙니다. 로컬 트래픽 처리 방식, 코어 지원 여부, 서버의 UDP 전달, 방화벽을 확인하세요. Shadowsocks의 기본 UDP 전달에는 일반적으로 해당 UDP 포트를 열어야 합니다. 흔한 Trojan 구현은 TLS 연결 안에 UDP를 캡슐화하므로 패킷 손실이 있는 환경에서 직접 테스트하세요.

선택 기준 정리: 설정 호환성·안정성·유지 관리 비용 순으로 확인

구독 정보를 받은 사용자라면 먼저 가져오고, 지원 여부와 실제 접속을 확인한 뒤 성능을 비교하는 순서가 가장 효율적입니다. 자체 서버를 운영한다면 도메인과 인증서, 사용자 관리, 보안 계층 설정, 업데이트 및 유지 관리까지 함께 고려해야 합니다.

데스크톱 일상 사용: 실제 연결이 안정적이고 필요한 웹사이트에 접속할 수 있는 노드를 우선 선택하세요. 조건이 모두 갖춰져 있다면 VLESS 구성도 검토할 수 있습니다.
Android 배터리 절약: 불필요한 앱의 트래픽 처리와 반복적인 재연결을 먼저 줄인 뒤 동일한 조건으로 배터리 사용량을 비교하세요. 프로토콜 이름만으로 사용 시간을 예측하지 마세요.
여러 기기 공유: 모든 기기에서 공통으로 지원하는 기능을 선택하세요. 구독은 설정 배포를 돕지만 클라이언트 코어의 부족한 기능까지 보완하지는 않습니다.
안정적인 접속 지점이 있는 경우: VMess, Trojan, 최신 Shadowsocks 구성을 계속 검토해 사용할 수 있습니다. 프로토콜 이름만을 근거로 반드시 바꿔야 한다는 규칙은 없습니다.

최종적으로는 “프로토콜 + 전송 방식 + 보안 계층 + 코어 버전 + 회선”을 하나의 조합으로 기록하세요. 가져오기와 프록시 설정 방법은 사용 안내에서, 용어가 궁금하다면 용어집에서 확인할 수 있습니다. 여러 항목을 무작정 바꾸는 것보다 문제를 찾기 쉽습니다.