VMess、VLESS、Trojan、Shadowsocks 프로토콜 비교: 상황별 선택 가이드

이 글 한눈에 보기

이 글은 v2rayN, v2rayNG 또는 v2flyNG를 설정하면서 VMess, VLESS, Trojan, Shadowsocks 중 무엇을 선택해야 할지 고민하는 사용자를 위한 안내입니다. 핵심은 프로토콜의 신구가 아니라 서버 코어, 전송 계층, 보안 계층, 기기 성능과 네트워크 변동성이 서로 맞는지 확인하는 것입니다. 끝까지 읽으면 상황에 따라 선택지를 좁히고, 구독 설정에서 실제 성능에 영향을 주는 핵심 필드를 파악할 수 있습니다.

프로토콜·보안 계층·전송 계층부터 구분하기

VMess, VLESS, Trojan, Shadowsocks가 우선 해결하는 문제는 클라이언트와 서버가 트래픽을 인증하고 캡슐화하며 전달하는 방식입니다. TCP, WebSocket, gRPC 등은 전송 방식이고, TLS와 REALITY는 연결 보안 또는 핸드셰이크 방식입니다. 이 계층을 혼동하면 “특정 프로토콜은 원래 특정 포트에 적합하다”거나 “WebSocket으로 바꾸면 반드시 더 잘 숨겨진다”와 같은 잘못된 판단을 하게 됩니다.

예를 들어 VLESS 자체는 업무 데이터를 암호화하지 않으므로 일반적으로 TLS 또는 REALITY와 함께 사용해야 합니다. Trojan은 보통 TLS에 직접 의존하고, VMess는 인증 및 암호화 메커니즘을 내장하지만 TLS를 추가할 수도 있습니다. Shadowsocks는 사전 공유 키와 대칭 암호화를 사용합니다. 같은 프로토콜이라도 전송 계층이 다르면 연결 수립 시간, 추가 요청 헤더와 장애 양상이 달라질 수 있습니다.

4종

이 글에서 비교하는 프록시 프로토콜

443

TLS 서비스에서 자주 사용하는 포트

10808

v2rayN에서 자주 사용하는 로컬 SOCKS 포트

10809

일반적인 로컬 HTTP 프록시 포트

포트 번호는 서비스가 수신 대기하는 위치만 나타내며 프로토콜의 성능이나 보안 수준을 결정하지 않습니다. 443이 TLS 서비스에 자주 사용되는 이유는 표준 HTTPS 포트 관례에 맞기 때문입니다. Shadowsocks, VMess 및 다른 설정도 서로 다른 포트를 사용할 수 있습니다. v2rayN의 로컬 포트 역시 변경할 수 있으므로, 확인할 때는 10808이나 10809를 기계적으로 적용하지 말고 「설정」→「매개변수 설정」에 표시된 현재 값을 기준으로 삼아야 합니다.

프로토콜	인증 및 암호화의 핵심	일반적인 보안 조합	주요 주의사항
VMess	사용자 ID, 시간 검증 및 프로토콜 자체의 인증·암호화 사용	VMess + TCP + TLS 또는 VMess + WebSocket + TLS	클라이언트와 서버의 시간 차이가 너무 크면 인증에 실패할 수 있음
VLESS	인증과 데이터 전달을 간결하게 유지하며 데이터 암호화는 내장하지 않음	VLESS + TLS 또는 VLESS + REALITY + Vision	security, flow 및 전송 필드를 정확히 이해해야 함
Trojan	비밀번호로 인증하고 TLS에 의존해 연결을 보호	Trojan + TCP + TLS	인증서, 도메인과 시스템 시간이 모두 TLS 핸드셰이크에 영향을 줌
Shadowsocks	사전 공유 키와 AEAD 또는 2022 계열 암호화 방식	AES-GCM, ChaCha20-Poly1305 또는 2022 방식	양쪽에서 완전히 동일하고 지원되는 방식을 사용해야 함

4가지 프로토콜의 핵심 차이

VMess는 V2Ray 생태계에서 일찍 널리 사용된 프로토콜로, 현재도 안정적으로 운영되는 구독에서 자주 볼 수 있습니다. 인증, 시간 검증 및 암호화 과정을 포함하며 서버와 클라이언트는 일반적으로 UUID로 사용자를 식별합니다. 기존 설정의 적용 범위가 넓다는 점이 장점이며, v2rayN, v2rayNG, v2flyNG 모두 일반적인 조합을 처리할 수 있습니다. 반면 프로토콜 로직과 캡슐화가 VLESS보다 복잡하다는 대가가 있습니다.

VLESS는 인증과 전달 구조를 간결하게 설계했으며 사용자 식별자는 일반적으로 UUID이고 바이너리 길이는 16바이트입니다. VLESS는 데이터 계층을 자체적으로 암호화하지 않으므로 배포할 때 보안 설계를 생략해서는 안 됩니다. Xray 코어에서 자주 사용하는 VLESS + REALITY + XTLS Vision 조합의 핵심은 ‘VLESS’라는 이름 하나에 의존하는 것이 아니라 보안 핸드셰이크와 흐름 제어가 함께 작동하도록 구성하는 데 있습니다.

VMess

기존 V2Ray 구독과 전통적인 WebSocket·TCP 설정을 호환하므로 기존 서버를 이전할 때 변경 사항이 적습니다.

적합한 경우:안정적인 VMess 노드를 이미 사용 중이며 기존 설정과의 호환성이 필요한 경우

VLESS

권장

프로토콜 계층이 간결하며 Xray의 REALITY, XTLS Vision 등의 기능과 조합할 수 있어 매개변수 구성이 명확합니다.

적합한 경우:새 Xray 서버를 구축하거나 데스크톱·안드로이드에서 주력으로 사용하는 경우

Trojan

TLS를 기반으로 하며 도메인, 인증서, 비밀번호와 서버 수신 관계가 설정의 핵심입니다.

적합한 경우:표준적인 TLS를 이미 구축했고 설정 구조를 직관적으로 유지하고 싶은 경우

Shadowsocks

프로토콜 구현이 비교적 간결하며 지원되는 암호화 방식을 선택하면 저사양 기기의 처리 부담을 줄일 수 있습니다.

적합한 경우:간단한 전달, 리소스가 제한된 기기, 양쪽 버전을 명확히 통제할 수 있는 경우

Trojan은 일반적으로 표준 TLS 연결 위에서 작동하며 인증 정보는 TLS로 보호되는 연결 내부에 있습니다. 문제 해결 경로도 비교적 명확합니다. 먼저 도메인 DNS 해석을 확인하고, 다음으로 인증서 유효성과 시스템 시간을 점검한 뒤 비밀번호, 포트 및 전송 설정을 확인합니다. TLS 핸드셰이크가 완료되지 않았다면 라우팅 규칙을 계속 조정해도 문제가 해결되지 않는 경우가 많습니다.

Shadowsocks의 성능은 선택한 암호화 방식, 프로세서 명령어 집합 및 구현 버전에 직접 영향을 받습니다. AES 하드웨어 가속을 지원하는 데스크톱 프로세서라면 AES-GCM이 적합한 경우가 많고, 해당 가속 기능이 없는 기기라면 ChaCha20-Poly1305를 비교해 볼 수 있습니다. 2022 계열 방식은 키 관리와 재전송 공격 방어를 한층 체계화했지만, 클라이언트와 서버가 모두 지원해야 하며 한쪽만 변경해서는 안 됩니다.

결론:프로토콜 이름만으로는 전체 설정을 대신할 수 없습니다

VLESS를 확인했다면 security, flow, network 및 serverName을 계속 점검해야 하고, Shadowsocks라면 method와 키를 확인해야 합니다. 구독 설정에서 핵심 필드 하나라도 누락되면 프로토콜 자체의 이론적인 오버헤드보다 연결 결과에 더 큰 영향을 줄 수 있습니다.

가정용 인터넷·모바일 네트워크·저사양 기기별 선택법

가정용 인터넷은 대체로 연결이 안정적이고 패킷 손실이 적어 선택의 폭이 가장 넓습니다. 서버가 Xray를 사용하고 매개변수가 완전하다면 VLESS + REALITY + XTLS Vision을 우선 검토할 수 있습니다. 기존 VMess + TLS 노드가 장기간 안정적으로 작동한다면 이름만 바꾸기 위해 새로 구축할 필요는 없습니다. 도메인과 TLS 서비스를 올바르게 관리하는 환경에는 Trojan이 적합하고, 구조가 간결하며 양쪽 버전을 통제할 수 있는 전달에는 Shadowsocks가 적합합니다.

모바일 네트워크에서는 기지국 전환, 주소 변경과 짧은 끊김이 발생할 수 있습니다. 이때는 먼저 불필요한 전송 계층 중첩을 줄인 다음 프로토콜을 비교해야 합니다. WebSocket은 기존 HTTP 인프라를 통해 전달하기 편리하지만 HTTP 헤더와 프레임 캡슐화가 추가됩니다. 직접 TCP를 사용하면 구조는 단순하지만 서버 진입점과 네트워크 환경이 안정적인 연결을 허용하는지 확인해야 합니다. 모든 모바일 네트워크에서 우세한 고정 답은 없습니다.

권장 구성:안정적인 네트워크와 변동성이 큰 네트워크에 각각 테스트 그룹 설정

가정용 인터넷 데스크톱

v2rayN에서 Xray 코어 사용
VLESS와 기존 VMess를 우선 비교
시스템 프록시 포트는 매개변수 설정을 기준으로 확인
회선 차이를 배제하기 위해 동일한 서버만 사용

안드로이드 모바일 네트워크

v2rayNG에서 Xray 코어 사용
무선 네트워크와 모바일 네트워크를 각각 테스트
구조가 간단한 예비 설정 하나 유지
네트워크 전환 후 연결 로그 다시 확인

프로토콜을 비교할 때는 서버, 출구 회선과 테스트 시간을 동일하게 유지해야 합니다. 그렇지 않으면 측정되는 것은 프로토콜 차이가 아니라 대부분 회선 차이입니다.

저사양 기기에서는 암호화 연산과 캡슐화 계층 수가 핵심입니다. 프로세서에 AES 명령어 가속 기능이 있다면 Shadowsocks의 AES-128-GCM을 평가의 출발점으로 삼을 수 있고, 없다면 양쪽 구현이 모두 지원하는 조건에서 ChaCha20-Poly1305를 비교할 수 있습니다. VLESS는 프로토콜 계층이 가볍지만 TLS, REALITY 또는 복잡한 전송을 추가하면 연산 자원이 필요하므로, 프로토콜 계층이 간결하다는 이유만으로 전체 경로의 부하가 가장 낮다고 단정해서는 안 됩니다.

먼저 서버 프로토콜, 코어, 보안 계층, 전송 방식과 포트를 기록하고 노드 이름만 적어 두지 마세요.
같은 네트워크와 같은 서버에서 후보 설정을 각각 연결해 서로 다른 회선이 비교에 섞이지 않도록 하세요.
첫 연결의 안정성, 연속 접속 중단 여부와 기기의 뚜렷한 발열 또는 배터리 소모 변화를 관찰하세요.
모바일 네트워크 테스트에는 최소 한 번의 네트워크 전환을 포함해 전환 후 클라이언트가 연결을 복구할 수 있는지 확인하세요.
이미 작동이 검증된 설정 하나를 대체 설정으로 남겨 두고, 이후 매번 하나의 매개변수만 단계적으로 조정하세요.

v2rayN·v2rayNG·v2flyNG에서 설정 확인하기

데스크톱에서 v2rayN을 사용할 때는 먼저 구독을 업데이트하고 노드 편집 화면을 열어 주소, 포트, 사용자 ID 또는 비밀번호, 전송 프로토콜, 보안 유형, SNI 또는 serverName을 확인합니다. 이어서 「설정」→「매개변수 설정」으로 이동해 로컬 SOCKS 및 HTTP 수신 포트를 확인하세요. 브라우저나 다른 애플리케이션에서 10808을 수동으로 지정했다면 클라이언트의 포트를 변경한 뒤 호출하는 쪽의 설정도 함께 수정해야 합니다.

VLESS + REALITY 설정에서는 publicKey, shortId, serverName, fingerprint와 flow도 확인해야 합니다. 일반적인 flow 값은 xtls-rprx-vision이지만 활성화 여부는 서버 설정과 일치해야 합니다. REALITY는 기존 웹사이트 인증서 파일을 사용하는 방식으로 같은 배포 절차를 진행하지 않으므로 Trojan의 인증서 문제 해결 방식을 그대로 적용해서는 안 됩니다.

v2rayN에서 대상 서버를 선택하고 편집 창을 연 다음, 구독 파싱 과정에서 프로토콜 필드가 다른 유형으로 바뀌지 않았는지 확인합니다.
VMess에서는 UUID, alterId, security, network 및 TLS를 중점적으로 확인합니다. 최신 설정에서 alterId는 일반적으로 0입니다.
VLESS에서는 UUID, encryption, flow, security, network 및 serverName을 중점적으로 확인합니다. 일반적인 encryption 값은 none입니다.
Trojan에서는 비밀번호, 포트, TLS, serverName과 인증서에 연결된 도메인을 중점적으로 확인합니다.
Shadowsocks에서는 method, 비밀번호와 포트를 중점적으로 확인하며, 방식 이름은 서버 설정과 한 글자까지 동일해야 합니다.

프로토콜 문제 해결 기록 예시
프로토콜: VLESS
주소 및 포트: 서버와 확인 완료
전송: tcp
보안 계층: reality
flow: xtls-rprx-vision
serverName: 서버와 확인 완료
로컬 SOCKS: 10808
로컬 HTTP: 10809

안드로이드에서 Xray의 REALITY와 Vision 기능이 필요하다면 Xray 코어가 포함된 v2rayNG를 사용하고, 가져온 뒤 관련 필드가 누락되지 않았는지 확인해야 합니다. v2flyNG는 v2fly 코어를 사용하므로 해당 코어가 지원하는 VMess, VLESS, Trojan 및 Shadowsocks 설정을 처리하는 데 적합하지만, 일부 Xray 전용 조합은 공유 링크의 이름만으로 작동 여부를 판단할 수 없습니다.

구독 가져오기에 성공했다는 것은 클라이언트가 텍스트를 인식했다는 의미일 뿐, 서버 매개변수가 올바르다는 뜻은 아닙니다. 연결에 실패하면 클라이언트 로그를 열어 DNS 해석 실패, 연결 거부, TLS 핸드셰이크 실패, 인증 실패와 로컬 포트 사용 중을 구분해야 합니다. 오류 유형마다 처리해야 할 계층이 다르므로, 프로토콜을 반복해서 바꾸는 것은 실제 문제를 가릴 뿐입니다.

자주 묻는 선택 질문과 해결 방법

가정용 인터넷이라면 VLESS를 바로 선택하면 되나요?

먼저 서버가 Xray를 사용하고 완전한 VLESS 매개변수를 제공하는지 확인하세요. 기존 VMess 노드가 안정적이라면 프로토콜 이름만 바꾸기 위해 이전할 필요는 없습니다. 새 설정을 만들 때는 VLESS + REALITY + XTLS Vision을 우선 검토할 수 있습니다.

VMess를 가져온 뒤 계속 인증 실패가 표시되면 어떻게 해야 하나요?

먼저 시스템 자동 시간 동기화를 활성화한 다음 UUID, alterId와 security를 확인하세요. VMess 인증은 시간에 의존하므로 기기와 표준 시간의 차이가 크면 주소와 포트가 올바르더라도 실패할 수 있습니다.

Trojan 비밀번호가 맞는데 TLS 핸드셰이크에 실패하면 어떻게 해야 하나요?

도메인 DNS 해석, 443 또는 실제 수신 포트, serverName, 인증서에 연결된 도메인과 기기 시간을 차례로 확인하세요. TLS가 아직 수립되지 않았다면 Trojan 비밀번호를 변경해도 인증서나 도메인 문제는 해결되지 않습니다.

Shadowsocks에서는 AES와 ChaCha20 중 무엇을 선택해야 하나요?

데스크톱 프로세서가 AES 하드웨어 가속을 지원한다면 AES-128-GCM을 먼저 시도할 수 있고, 저사양 기기에서는 ChaCha20-Poly1305를 비교해 볼 수 있습니다. 최종 방식은 서버가 제공해야 하며 클라이언트 코어가 명확히 지원하는지도 확인해야 합니다.

프로토콜을 바꿨는데 속도가 그대로인 것이 정상인가요?

정상입니다. 대역폭 병목은 서버 출구, 망간 회선 또는 로컬 무선 네트워크에 있는 경우가 많습니다. 같은 서버와 같은 시간대에서 프로토콜 설정만 바꿔야 캡슐화와 암호화에 따른 차이를 판단할 수 있습니다.

프로토콜 선택 체크리스트

새 Xray 설정을 만들고 데스크톱에서는 v2rayN, 안드로이드에서는 v2rayNG를 사용한다면 Xray가 지원하는 보안 조합과 VLESS를 먼저 검토할 수 있습니다. VMess 설정이 많고 안정적으로 작동한다면 올바른 매개변수를 유지·관리하는 편이 현실적입니다. 표준적인 TLS 도메인과 인증서를 관리할 수 있다면 Trojan은 구조가 명확하고, 기기 리소스가 제한되어 있으며 서버가 호환되는 방식을 지원한다면 Shadowsocks도 별도로 테스트할 가치가 있습니다.

기존 구독과의 호환성을 우선: VMess를 선택하고 기존 UUID, 전송 및 TLS 매개변수를 유지합니다.
새 Xray 주력 설정 구축: VLESS + REALITY + XTLS Vision을 검토하고 flow와 공개 키 매개변수를 항목별로 확인합니다.
표준 TLS 서비스를 이미 운영 중: Trojan을 검토하고 도메인, 인증서, 비밀번호와 수신 포트를 중점적으로 관리합니다.
리소스가 제한되고 양쪽 버전을 통제 가능: Shadowsocks를 검토하고 프로세서 성능에 맞춰 서버가 지원하는 암호화 방식을 선택합니다.
모바일 네트워크 변동이 큼: 불필요한 캡슐화를 줄이고 예비 설정을 유지하며 네트워크 전환 후 복구 성능을 테스트합니다.
병목 위치를 판단하기 어려움: 프로토콜 변경을 논하기 전에 코어 로그와 시스템 프록시 포트를 먼저 확인합니다.

최종 판단:이론적인 순위보다 안정적인 재현성이 우선

같은 프로토콜도 회선, 코어와 전송 조합에 따라 성능이 완전히 달라질 수 있습니다. 전체 매개변수 기록을 남기고 같은 서버에서 항목별로 비교한 뒤, 일상적인 네트워크에서 안정적으로 복구되고 문제 해결도 쉬운 조합을 선택하세요.