VMess·VLESS·Trojan·Shadowsocks 프로토콜 비교: 사용 환경별 선택 가이드

이 글 한눈에 보기

이 비교 글은 구독을 정리하거나 노드를 직접 추가하거나 프로토콜 변경을 준비하는 사용자에게 적합합니다. 네 가지 프로토콜의 순위를 정하는 것이 아니라, 현재 클라이언트가 노드 매개변수를 제대로 지원하는지, 네트워크 환경이 안정적인지, 서버에서 어떤 전송 계층 조합을 제공하는지를 판단하는 데 초점을 둡니다.

먼저 결론: 프로토콜 이름만으로 결정할 수 없다

VMess, VLESS, Trojan, Shadowsocks는 모두 프록시 트래픽을 전달할 수 있지만 문제를 해결하는 방식은 서로 다릅니다. VMess는 인증, 시간 검증, 데이터 암호화를 프로토콜 내부에서 처리합니다. VLESS는 프로토콜 계층을 가볍게 설계하고 기밀성을 TLS, REALITY 같은 외부 보안 계층에 주로 맡깁니다. Trojan은 처음부터 TLS 연결을 중심으로 인증과 데이터 전송을 구성합니다. Shadowsocks는 단순한 구조, 검증된 구현, 낮은 리소스 사용량이 강점입니다.

구독에 네 가지 노드가 함께 표시되더라도 프로토콜 이름만 보고 속도를 판단할 필요는 없습니다. 실제 체감 성능에는 회선 대역폭, 왕복 지연 시간, 패킷 손실, 전송 방식, TLS 핸드셰이크, 서버 부하, 클라이언트 코어가 모두 영향을 줍니다. 같은 서버에서는 프로토콜 계층의 오버헤드가 전체 소요 시간의 일부에 불과합니다. 회선 자체의 지연 시간이 180밀리초이거나 패킷 손실이 계속된다면 VMess를 VLESS로 바꾼다고 회선 품질이 자동으로 개선되지는 않습니다.

VMess

프로토콜 내부에 인증과 암호화가 포함되어 있으며, 기존 설정이 많아 오래된 구독과 현재 운영 환경에서 지원 범위가 넓습니다.

적합한 경우: 안정적인 기존 노드 유지, 구형 설정과의 호환

VLESS

Trojan

암호화를 TLS에 의존하며 표준 TLS 포트를 자주 사용합니다. 배포할 때 인증서, 도메인, 핸드셰이크 매개변수를 정확히 설정해야 합니다.

적합한 경우: 안정적인 도메인과 TLS 배포 환경을 갖춘 경우

Shadowsocks

설정 필드가 적고 AEAD 암호화 방식이 검증되어 있어 저사양 기기와 단순한 접속 환경에서 관리하기 쉽습니다.

적합한 경우: 가벼운 접속, 낮은 리소스 사용량, 단순한 설정

실행하기 쉬운 출발점이 필요하다면 먼저 클라이언트 코어를 기준으로 고르세요. v2rayN에서 Xray 코어를 사용할 때는 VLESS, VMess, Trojan 노드를 우선 확인하고, v2rayNG도 Xray 코어로 일반적인 프로토콜을 처리합니다. v2flyNG에서 v2fly 코어를 사용한다면 현재 코어가 실제로 지원하는 프로토콜과 전송 매개변수를 기준으로 선택해야 합니다. 노드를 가져올 수 있다고 해서 현재 코어가 모든 확장 필드를 인식하는 것은 아니므로 연결 전에 로그를 확인하세요.

네 가지 기준별 비교: 암호화·오버헤드·전송·호환성

VMess는 사용자 식별자와 시간 정보를 사용해 인증하고, 프로토콜 내부에서 데이터를 보호합니다. 시스템 시간에 민감하므로 기기 시간의 오차가 크면 인증에 실패할 수 있습니다. VLESS는 UUID 등의 정보로 사용자를 식별하지만 자체적으로 완전한 콘텐츠 암호화를 담당하지 않으므로, 보안 전송 계층을 제외하고 프로토콜 이름만 봐서는 안 됩니다. 실제 설정에서는 security, flow, TLS 또는 REALITY 등의 필드를 함께 확인해야 합니다.

Trojan은 TLS 연결 위에서 인증과 데이터 전달을 수행하므로 서버 인증서, 도메인 일치 여부, 시스템 시간이 핸드셰이크에 영향을 줍니다. Shadowsocks는 사전 공유 비밀번호와 지정된 암호화 방식을 사용합니다. 최신 설정에서는 AEAD 또는 Shadowsocks 2022 계열 방식을 사용해야 하며, 클라이언트와 서버의 암호화 방식 이름이 완전히 일치해야 합니다. 구형 방식이 기존 설정에 남아 있더라도 새 배포의 기본값으로는 적합하지 않습니다.

비교 항목	VMess	VLESS	Trojan	Shadowsocks
프로토콜 계층 암호화	인증 및 데이터 보호 기능 포함	주로 외부 TLS 또는 REALITY에 의존	TLS에 의존	선택한 AEAD 방식이 제공
일반적인 인증 정보	UUID, alterId 등 기존 필드	UUID、flow	비밀번호	비밀번호 및 암호화 방식
일반적인 전송 조합	TCP、WebSocket、gRPC	TCP、WebSocket、gRPC、REALITY	TCP 기반 TLS, 특정 전송 방식과 조합 가능	기본 TCP/UDP, 확장 기능은 구현에 따라 다름
설정 복잡도	중간, 기존 필드가 비교적 많음	중간, 보안 계층 매개변수 확인 필요	중간, TLS 조건 처리 필요	낮음, 핵심 필드가 적음
시간 민감 항목	정확한 시간이 인증에 필요	TLS 또는 REALITY 핸드셰이크가 시간의 영향을 받음	인증서 검증이 시간의 영향을 받음	일반적으로 인증서 시간에 의존하지 않음
대표적인 장점	기존 설정과의 호환 범위가 넓음	간결한 프로토콜 계층, 유연한 조합	TLS 배포 경로가 명확함	가벼움, 적은 매개변수, 낮은 리소스 오버헤드

결론: 전체 매개변수를 먼저 확인하고 프로토콜 이름을 비교하자

VLESS 노드는 최소한 주소, 포트, UUID, 전송 방식, 보안 계층, flow를 하나의 묶음으로 확인해야 합니다. Shadowsocks 노드는 포트, 비밀번호, 암호화 방식이 모두 일치해야 합니다. 필드 누락으로 인한 연결 실패가 프로토콜 간 이론적인 오버헤드 차이 몇 퍼센트보다 훨씬 흔합니다.

데스크톱·모바일·저사양 기기별 선택법

데스크톱 작업 환경에서는 브라우저, 동기화 도구, 메신저를 동시에 실행하는 경우가 많고 연결도 오래 유지됩니다. 짧은 속도 측정보다 안정성이 중요합니다. 구독에서 TLS 또는 REALITY를 사용하는 VLESS를 제공하고 v2rayN이 Xray 코어로 실행 중이라면 먼저 주 연결로 사용해 보세요. 같은 회선을 비교할 수 있도록 VMess 또는 Trojan 노드도 하나 남겨 두는 것이 좋습니다. 전환할 때 서버 지역, 전송 방식, 프로토콜을 동시에 바꾸면 어떤 변화가 결과에 영향을 줬는지 판단할 수 없습니다.

Android 기기는 Wi-Fi와 모바일 네트워크 사이를 자주 전환하므로 한 번의 최고 속도보다 재연결 속도, 배터리 소모, UDP 사용 가능 여부가 더 중요할 수 있습니다. v2rayNG는 일반적인 Xray 노드를 처리할 수 있어 VLESS, VMess, Trojan이 포함된 통합 구독을 받는 데 적합합니다. v2flyNG를 사용할 때는 구독의 노드가 v2fly 코어의 기능과 맞는지 확인해야 합니다. 양쪽에서 같은 구독을 사용하면 노드 목록은 동기화할 수 있지만, 라우팅 규칙, 앱별 프록시, 로컬 포트는 클라이언트의 로컬 설정이므로 구독과 함께 자동으로 이전되지 않습니다.

추천 구성: 주 프로토콜과 보조 프로토콜을 나눠 사용

데스크톱(v2rayN)

매개변수가 완비된 VLESS 노드를 주 연결로 사용
VMess 또는 Trojan을 비교용으로 유지
로그에서 핸드셰이크와 재연결 기록 확인

Android(v2rayNG 또는 v2flyNG)

같은 구독으로 노드 이름을 일관되게 유지
현재 코어가 인식할 수 있는 노드만 선별
Wi-Fi와 모바일 네트워크를 각각 테스트

먼저 서버 지역과 회선을 고정한 뒤 프로토콜만 바꿔 보세요. 일정 시간 연속 사용하면 한 번의 속도 측정보다 안정적인 조합을 찾기 쉽습니다.

저사양 기기나 작은 연결을 대량으로 동시에 사용해야 하는 환경에서는 Shadowsocks를 먼저 테스트해 볼 수 있습니다. 핵심 설정이 보통 서버, 포트, 비밀번호, 암호화 방식뿐이라 문제를 추적하는 경로가 짧습니다. 복잡한 라우팅, 특정 트래픽 제어, REALITY가 반드시 필요하다면 몇 개의 필드를 줄이려고 맞지 않는 프로토콜을 억지로 사용하지 말고 해당 기능을 지원하는 Xray 조합으로 전환하세요.

업무용 주 연결: VLESS와 Trojan의 장시간 연결 안정성을 먼저 비교하고, VMess 노드는 호환성용 예비로 사용하세요.
네트워크를 자주 전환하는 경우: 네트워크 변경 후 최초 복구 시간을 기록하고 UDP 앱이 정상 작동하는지 확인하세요.
저사양 기기: 먼저 Shadowsocks의 CPU 사용량과 지속 처리량을 측정한 뒤 더 복잡한 전송 계층이 필요한지 결정하세요.
기존 구독: 안정적인 VMess 노드는 프로토콜이 오래되었다는 이유만으로 바로 교체할 필요가 없습니다. 먼저 회선과 서버 유지 관리 상태를 평가하세요.

한 번의 속도 측정 대신 반복 가능한 테스트 사용

프로토콜 테스트에서는 서버, 출구 회선, 대상 파일, 테스트 시간을 고정해야 합니다. 실행 가능한 기본 조건은 클라이언트와 서버 사이의 왕복 지연 시간 약 50밀리초, 유휴 상태 패킷 손실률 1% 미만, 로컬 접속 대역폭 100Mbps입니다. 각 노드를 3회 연속 테스트하고 시작 전에 백그라운드 동기화 작업을 종료하세요. 아래 수치는 테스트 기록 방식을 설명하기 위한 예시이며, 모든 네트워크에서의 고정 순위를 의미하지 않습니다.

100 Mbps

로컬 접속 대역폭 고정

50 ms

예시 왕복 지연 시간

3회

노드별 반복 테스트

10분

지속 연결 관찰 시간

테스트 결과에는 최소한 최초 연결 소요 시간, 지속 다운로드 속도, 10분 동안의 재연결 횟수, UDP 사용 가능 여부를 기록하세요. 최고 속도는 특정 순간만 보여 줄 뿐 네트워크 전환이나 불안정한 네트워크에서 프로토콜이 안정적인지는 알려 주지 못합니다. 네 노드가 같은 서버에 있지 않다면 결과를 ‘회선 종합 성능’으로 표시해야 하며 프로토콜 자체의 특성으로 단정해서는 안 됩니다.

간단한 교차 검증도 할 수 있습니다. 먼저 VLESS, VMess, Trojan, Shadowsocks 순서로 테스트한 다음 역순으로 한 번 더 반복하세요. 가장 먼저 테스트한 노드가 항상 빠르다면 백그라운드 작업, 서버의 순간 부하, 네트워크 혼잡이 변하고 있을 가능성이 있습니다. 정순과 역순의 결과가 비슷할 때만 평균값을 비교하는 것이 적절합니다.

속도 차이가 8% 미만이면: 재연결이 적고 로그가 깔끔한 노드를 우선 선택하세요.
지연 시간 차이가 30밀리초를 넘으면: 먼저 서버 지역과 회선을 확인하고 프로토콜 탓으로 단정하지 마세요.
패킷 손실이 5%를 넘으면: 먼저 네트워크 품질 문제를 해결하세요. 암호화 방식을 계속 조정해도 효과가 제한적입니다.
UDP만 실패한다면: 노드가 UDP를 지원하는지, 클라이언트에서 해당 전달 기능을 켰는지, 라우팅 규칙이 차단하고 있지 않은지 확인하세요.

결론: 최고 속도보다 안정성 지표를 우선하자

100Mbps 접속 환경에서 10분 동안 재연결이 없고, 네트워크 전환 후 복구되며, UDP가 예상대로 작동한다면 특정 테스트에서 5Mbps 더 빠른 것보다 실제 가치가 큰 경우가 많습니다.

v2rayN 및 Android 클라이언트에서 프로토콜 매개변수 확인

v2rayN에서는 먼저 서버 목록의 유형 열에서 노드가 VMess, VLESS, Trojan, Shadowsocks 중 무엇인지 확인한 뒤 해당 서버 설정을 여세요. VLESS는 주소, 포트, 사용자 ID, 전송 프로토콜, TLS 또는 REALITY, 보안 흐름을 중점적으로 확인합니다. VMess는 사용자 ID, 전송 방식, 보안 설정을 확인하고, Trojan은 비밀번호, 서버 이름, 인증서 관련 옵션을 확인합니다. Shadowsocks는 비밀번호와 암호화 방식을 확인하세요.

로컬 프록시 포트도 브라우저 또는 시스템 설정과 일치해야 합니다. 흔히 SOCKS 포트 10808, HTTP 포트 10809를 사용하지만 사용자가 이 값을 변경할 수 있으므로 모든 설치 환경의 고정값으로 보면 안 됩니다. 앱이 인터넷에 연결되지 않으면 ‘설정’ → ‘매개변수 설정’을 열어 현재 로컬 수신 포트를 확인한 뒤 앱의 프록시 주소와 항목별로 비교하세요.

VMess 인증 실패: 먼저 시스템 시간을 동기화한 다음 UUID가 서버와 일치하는지 확인하세요.
VLESS 핸드셰이크 실패: 실제 설정에 포함된 security, flow, serverName, publicKey, shortId 등의 필드를 확인하세요.
Trojan TLS 오류: 기기 시간, 서버 이름, 포트, 인증서 도메인이 서로 대응하는지 확인하세요.
Shadowsocks 연결 후 트래픽 없음: 클라이언트와 서버가 완전히 동일한 암호화 방식과 비밀번호를 사용하는지 확인하세요.
구독을 가져온 후 유형이 이상함: 구독을 업데이트하고 기존 코어가 원본 노드의 확장 매개변수를 무시했는지 확인하세요.

Android에서도 점검 순서는 비슷합니다. v2rayNG에서는 먼저 노드 편집 화면을 열어 프로토콜 필드를 확인한 다음 실행 로그에서 DNS, 핸드셰이크, 연결 오류를 살펴보세요. v2flyNG는 노드가 사용하는 기능이 현재 v2fly 코어에 포함되어 있는지도 추가로 확인해야 합니다. 같은 구독이 데스크톱에서는 작동하지만 Android에서는 작동하지 않는다면 곧바로 서버 장애로 판단하지 말고 양쪽 코어와 노드 필드를 먼저 비교하세요.

자주 하는 오해와 최종 선택 목록

‘VLESS가 항상 VMess보다 빠르다’는 가장 흔한 단순화된 판단입니다. VLESS는 프로토콜 계층이 더 가볍지만 실제 연결에서는 TLS, 전송 캡슐화, 네트워크 왕복, 서버 부하가 더 큰 비중을 차지하는 경우가 많습니다. Trojan을 일반 웹 트래픽과 동일하게 보는 것도 오해입니다. TLS 기반으로 동작하는 것은 맞지만 실제 네트워크 특성은 핸드셰이크 매개변수, 전송 동작, 배포 방식의 영향을 받으므로 프로토콜 이름만으로 절대적인 결론을 내릴 수 없습니다.

Shadowsocks가 단순한 웹 접속에만 쓰인다는 뜻도 아닙니다. UDP, 동시 연결, 특정 라우팅 지원 여부는 클라이언트·서버·설정 조합에 따라 달라집니다. 반대로 설정 필드가 많다고 연결이 자동으로 더 안정적인 것도 아닙니다. 모든 프로토콜에는 올바른 서버 매개변수, 사용 가능한 회선, 호환되는 코어가 필요합니다.

구독에 네 가지 프로토콜이 있다면 무엇부터 테스트해야 하나요?

같은 지역과 같은 통신 회선의 노드를 선택해 VLESS, Trojan, VMess, Shadowsocks를 각각 3회 테스트하세요. 서버가 서로 다르다면 먼저 지연 시간과 패킷 손실을 기준으로 회선을 선별한 뒤 프로토콜을 비교하세요.

VMess 노드를 계속 사용해도 되나요?

가능합니다. 클라이언트 코어가 설정을 인식하고 서버가 계속 관리되며 연결이 안정적이라면 프로토콜 이름만을 이유로 바꿀 필요는 없습니다. 새로 배포할 때는 보안 계층과 유지 관리 조건을 기준으로 VLESS 등의 방식을 평가하세요.

VLESS 가져오기는 성공했지만 연결되지 않으면 어떻게 하나요?

포트, UUID, 전송 방식, security, flow, 서버 이름을 순서대로 확인하세요. REALITY를 사용하는 경우 publicKey, shortId, 지문 매개변수도 대조하고 코어 로그에서 핸드셰이크 단계를 확인하세요.

Trojan이 443 포트를 사용하면 설정이 반드시 올바른가요?

아닙니다. 443은 흔히 사용하는 포트일 뿐입니다. 비밀번호, 서버 이름, TLS 핸드셰이크, 서버 수신 상태도 확인해야 합니다. 포트를 다른 서비스가 사용 중이면 로그에 연결 거부 또는 핸드셰이크 실패가 표시되는 경우가 많습니다.

Shadowsocks는 왜 연결되는데 트래픽이 없나요?

먼저 암호화 방식과 비밀번호를 대조한 뒤 로컬 SOCKS 또는 HTTP 포트를 확인하세요. 특정 앱에서만 실패한다면 시스템 프록시, 앱별 프록시, 라우팅 규칙이 해당 앱에 적용되는지도 살펴보세요.

최종 선택은 세 단계로 정리할 수 있습니다. 첫째, 현재 클라이언트와 코어가 노드 필드를 완전히 지원하는지 확인합니다. 둘째, 고정된 회선에서 연결, 재연결, UDP를 테스트합니다. 셋째, 다른 프로토콜의 예비 노드를 하나 남겨 둡니다. 데스크톱 주 연결은 Xray 코어와 함께 사용하는 VLESS를 우선 평가할 수 있고, 안정적인 기존 VMess 노드는 계속 사용해도 됩니다. TLS 배포 조건이 갖춰졌다면 Trojan을 선택할 수 있으며, 저사양·단순 접속 환경에서는 Shadowsocks를 먼저 테스트할 수 있습니다.

프로토콜은 한 번 정하면 영구적으로 유지하는 설정이 아닙니다. 구독 제공자가 서버를 조정하거나 클라이언트 코어가 업데이트되거나 네트워크 환경이 바뀌면 기존의 최적 조합도 달라질 수 있습니다. 테스트 기록을 남기고 같은 조건에서 재검증하는 편이 특정 프로토콜 이름만 좇는 것보다 안정적입니다.