VMess·VLESS·Trojan·Shadowsocks 차이와 선택 가이드: 4가지 프록시 프로토콜 비교

프록시 프로토콜을 고를 때는 노드 이름에 적힌 내용만 봐서는 안 됩니다. 프로토콜은 인증과 데이터 캡슐화를 담당하고, TLS·Reality·WebSocket·gRPC·TCP 등은 보안 계층이나 전송 계층을 담당하며, 클라이언트 코어가 특정 조합의 실제 실행 가능 여부를 결정합니다. 같은 회선의 VMess와 VLESS는 속도 차이가 작을 수 있지만, 같은 프로토콜이라도 패킷 손실이 심한 모바일 네트워크에서는 연결 안정성이 크게 달라질 수 있습니다.

이 글 한눈에 보기

이 글은 v2rayN, v2rayNG 또는 v2flyNG에서 노드 프로토콜을 고르는 사용자에게 적합합니다. 네 가지 프로토콜의 순위를 정하는 것이 아니라, 실행 가능한 판단 순서를 세우는 것이 핵심입니다. 먼저 클라이언트 코어 호환성을 확인하고, 보안 계층과 전송 설정을 점검한 뒤, 네트워크 패킷 손실·기기 성능·서버 조건을 함께 고려해 선택하세요.

헷갈리기 쉬운 네 가지 기술 계층부터 나누기

VMess·VLESS·Trojan·Shadowsocks는 모두 프록시 연결의 인증과 데이터 전달을 담당할 수 있지만, 설계 방식이 완전히 같지는 않습니다. VMess는 프로토콜 수준의 인증과 암호화 기능을 포함하고, VLESS는 주로 경량 인증과 전달을 처리하므로 일반적으로 TLS 또는 Reality와 함께 사용합니다. Trojan은 보통 TLS 위에 배포하며, Shadowsocks는 지정된 대칭 암호화 방식으로 프록시 트래픽을 보호합니다.

전송 방식은 별도의 계층입니다. 노드에 “VLESS + TCP + Reality”라고 적혀 있다면 VLESS는 프록시 프로토콜, TCP는 하위 전송 방식, Reality는 보안 및 핸드셰이크 방식입니다. “VMess + WebSocket + TLS”라면 WebSocket이 데이터를 전달하고 TLS가 암호화를 담당하며, VMess는 여전히 프로토콜 인증을 처리합니다. VMess와 VLESS만 비교하고 뒤의 조합을 무시하면 유효한 결론을 내리기 어렵습니다.

프로토콜	프로토콜 자체의 특징	일반적인 보안 조합	선택 시 우선 확인할 항목
VMess	인증, 시간 검증 및 프로토콜 수준 암호화 지원	TCP·WebSocket과 TLS 조합	시스템 시간, UUID, 전송 매개변수
VLESS	인증과 캡슐화가 가볍고 완전한 전송 암호화는 담당하지 않음	TLS、Reality、Vision	코어 지원 여부, serverName, flow
Trojan	비밀번호 인증을 사용하며 일반적으로 TLS 위에 배포	TCP + TLS、gRPC + TLS	인증서 도메인, SNI, 비밀번호, 포트
Shadowsocks	사전 공유 비밀번호와 지정된 암호화 방식을 사용	AEAD 또는 2022 계열 방식	method, 비밀번호, 코어의 방식 지원 여부

443

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

128-bit

UUID 식별자 길이

10808

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

10809

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

결론: 고립된 이름이 아니라 전체 프로토콜 스택을 비교하세요

노드 이름을 확인했다면 최소한 “프로토콜·전송·보안 계층·코어” 네 가지를 기록하세요. VLESS + Reality와 VLESS + WebSocket + TLS는 서로 다른 연결 구성이므로 안정성, 서버 요구 사항, 사용 가능한 클라이언트가 달라질 수 있습니다.

VMess·VLESS·Trojan·Shadowsocks는 각각 어떤 상황에 적합할까

VMess: 기존 설정과 검증된 구독을 계속 사용할 때

VMess는 오랫동안 V2Ray 계열 설정에 사용되어 왔으며, 주소·포트·UUID·전송 유형·경로·TLS 매개변수 등이 주요 항목입니다. 기기 시간이 정확해야 합니다. 로컬 시간이 크게 어긋나면 인증이 실패할 수 있습니다. 따라서 VMess 노드가 갑자기 모두 작동하지 않지만 네트워크 자체는 정상이라면 Windows·macOS·Android·Linux의 날짜, 시간, 시간대를 자동 동기화로 설정하세요.

안정적으로 작동 중인 VMess + WebSocket + TLS 구독이라면 새로운 프로토콜 이름이 등장했다는 이유만으로 즉시 이전할 필요는 없습니다. 구형 기기, 기존 서버 설정 또는 현재 접속 경로를 유지해야 하는 환경에서는 VMess의 설정 호환성이 이론적인 캡슐화 차이보다 더 중요할 수 있습니다. 최신 설정은 일반적으로 UUID를 사용하고 alterId를 0으로 유지합니다. 구형 매개변수가 여전히 포함되어 있다면 클라이언트에서 반복해 수정하지 말고 서비스 제공자에게 업데이트를 요청하세요.

VLESS: Xray 환경에서 우선 검토할 프로토콜

VLESS는 프로토콜 자체가 담당하는 암호화 기능을 줄이고, 일반적으로 전송 보안을 TLS 또는 Reality에 맡깁니다. 따라서 “기본적으로 이미 암호화된” 연결이 아니며, 올바른 보안 계층이 없을 때는 프로토콜 이름만으로 연결의 안전성을 판단할 수 없습니다. VLESS와 Reality, XTLS Vision 등의 조합은 Xray 코어에 의존하는 경우가 많고, UUID·serverName·공개 키·shortId·fingerprint·flow 등 클라이언트와 서버의 항목이 정확히 일치해야 합니다.

VLESS의 장점은 조합의 유연성과 최신 Xray 기능 지원에서 비롯되며, 모든 네트워크에서 반드시 더 빠르다는 뜻은 아닙니다. 가정용 인터넷에서 패킷 손실이 적다면 VLESS를 비롯한 합리적으로 구성된 프로토콜 대부분이 회선이 허용하는 처리량을 낼 수 있습니다. 모바일 네트워크에서 기지국을 자주 전환하거나 Wi-Fi와 셀룰러 네트워크 사이를 오갈 때는 전송 방식, 타임아웃 설정, 클라이언트의 백그라운드 상태가 연결 복구 성능에 더 큰 영향을 줍니다.

Trojan: 인증서와 표준 TLS 접속 경로가 이미 있을 때 관리하기 쉬운 선택

Trojan은 비밀번호 인증을 사용하며 일반적으로 TLS 위에서 직접 실행됩니다. 클라이언트에서 서버 주소·포트·비밀번호·SNI·인증서 도메인을 확인해야 합니다. 서버 주소는 IP일 수 있지만 serverName은 보통 인증서가 적용되는 도메인을 입력해야 합니다. 두 값이 일치하지 않고 SNI를 비워 두면 인증서 이름 불일치나 핸드셰이크 중단이 발생하기 쉽습니다.

Trojan은 도메인, 인증서, 443 포트 접속 경로를 이미 갖춘 환경에 적합합니다. 설정 항목은 비교적 직관적이지만 항목이 적다고 해서 문제 해결 요소까지 적은 것은 아닙니다. 인증서 유효 기간, 기기 시간, SNI, ALPN, 전송 유형, 중간 네트워크가 모두 핸드셰이크에 영향을 줄 수 있습니다. 클라이언트의 allowInsecure는 꺼 두고, 인증서 오류는 시간·도메인·인증서 체인을 확인해 해결하세요.

Shadowsocks: 리소스가 적은 기기와 명확한 암호화 방식에 적합

Shadowsocks 설정의 핵심은 서버, 포트, 비밀번호, 암호화 방식입니다. 기존 AEAD 방식과 2022 계열 방식은 임의로 바꿔 쓸 수 있는 동의어가 아니며, 클라이언트와 서버가 동일한 method를 사용해야 합니다. 구독을 가져온 뒤 “지원되지 않는 암호화 방식”이 표시되면 먼저 코어 버전과 방식 지원 여부를 확인하세요. 비슷해 보이는 다른 값으로 method를 바꾸면 인증에 반드시 실패합니다.

CPU와 메모리가 제한된 기기에서는 합리적으로 구성한 Shadowsocks가 배포와 관리에 유리한 경우가 많습니다. 다만 암호화 방식, 서버 구현, 네트워크 품질에 따라 연결 성능은 달라집니다. 사용할 때는 구독에 완전한 설정이 포함되어 있는지 먼저 확인하고, 실제 네트워크에서 웹페이지 연결, 대용량 파일 다운로드, 장시간 연결 유지를 테스트하세요. 한 번 측정한 지연 시간만으로 판단해서는 안 됩니다.

VMess

검증된 설정이 많아 기존 WebSocket 또는 TCP 노드를 계속 사용하기 좋으며, 문제 해결 시 시스템 시간을 먼저 확인해야 합니다.

적합: 기존 구독, 기존 설정, 호환성 유지

VLESS

Trojan

올바른 TLS·인증서 도메인·SNI가 필요하며, 항목이 직관적이라 표준 TLS 접속 경로가 이미 있는 환경에 적합합니다.

적합: 명확한 인증서 관리, 443 포트 접속 경로

Shadowsocks

설정이 간결하고 암호화 방식이 정확히 일치해야 하므로, 리소스가 제한된 기기와 단순한 전달 용도에 적합합니다.

적합: 구형 기기, 경량 설정, 백업 연결

네트워크와 기기 환경에 따라 프로토콜 선택하기

가정용 인터넷은 대체로 출구 주소가 안정적이고 패킷 손실이 적으므로 장기적인 유지 관리가 우선입니다. 새 Xray 서버를 구축한다면 VLESS + Reality 또는 VLESS + TLS를 먼저 검토할 수 있습니다. 기존 VMess·Trojan 노드가 안정적으로 작동한다면 되돌릴 수 있는 설정을 남겨 두세요. 프로토콜을 바꾸면서 포트·전송·보안 계층까지 한꺼번에 변경하면 장애 발생 후 원인을 찾기 어려워집니다.

모바일 네트워크의 핵심 문제는 보통 최고 속도가 아니라 연결 변동, 절전 상태에서의 연결 회수, 네트워크 전환입니다. v2rayNG는 Xray 코어를 사용할 때 일반적인 VMess·VLESS·Trojan·Shadowsocks 설정을 실행할 수 있지만, 백그라운드 연결은 Android의 배터리 절전 정책에도 영향을 받습니다. 화면을 끈 뒤 몇 분 후 연결이 끊긴다면 먼저 v2rayNG를 시스템 배터리 최적화 예외 목록에 추가한 다음 프로토콜 차이를 테스트하세요.

권장 구성: 주력 프로토콜과 호환 프로토콜을 함께 유지

안정적인 가정용 인터넷

VLESS + TLS 또는 Reality를 주력으로 사용
VMess 또는 Trojan 노드를 하나 백업으로 유지
서버에서 실제로 개방한 443 등의 포트 사용
한 번에 프로토콜 스택 항목 하나만 변경

모바일 네트워크와 구형 기기

먼저 Shadowsocks 또는 기존 VMess 설정 테스트
Android에서 클라이언트의 배터리 제한 해제
최초 연결과 화면을 끈 뒤 복구 결과 기록
복잡한 전송 설정과 잦은 재연결을 동시에 적용하지 않기

구독에는 독립적으로 검증할 수 있는 서로 다른 프로토콜 조합을 최소 두 가지 유지하세요. 주 연결에 장애가 발생하면 먼저 노드를 전환한 뒤 서버 설정을 점검합니다.

구형 기기에서 최신 조합만 좇지 마세요

성능이 낮은 기기의 병목은 TLS 핸드셰이크, 암호화 연산 또는 그래픽 클라이언트 자체에 있을 수 있습니다. 판단할 때는 작은 리소스가 많은 웹페이지 열기, 큰 파일 다운로드, 10분간 장시간 연결 유지라는 세 가지 작업을 연속으로 실행해 보세요. 지연 시간은 정상인데 다운로드 중 CPU 사용률이 오랫동안 최고치라면 기기의 연산 성능이 제한 요소일 수 있습니다. CPU 사용률은 높지 않지만 연결이 자주 재수립된다면 네트워크 패킷 손실과 전송 매개변수를 확인하세요.

가정용 인터넷: 장기적으로 관리하기 쉬운 VLESS 또는 Trojan 조합을 우선 사용하고 호환 노드를 함께 보관하세요.
모바일 네트워크: 프로토콜별 연결 복구 성능을 비교하기 전에 백그라운드 제한과 네트워크 전환 문제부터 해결하세요.
구형 기기: 항목이 적고 코어가 명확히 지원하는 설정을 우선하며, 불필요한 전송 계층은 추가하지 마세요.
기존 구독 이전: 원래 노드는 보존하고 새 설정을 복사본으로 만들어 비교하세요. 유일하게 작동하는 접속 경로를 바로 덮어쓰지 마세요.

클라이언트 코어가 가져오고 실행할 수 있는 설정을 결정합니다

v2rayN은 데스크톱 그래픽 클라이언트이며, 일반적인 7.x 버전 인터페이스에서 Xray 코어로 네 가지 프로토콜을 실행할 수 있습니다. v2rayNG는 Xray 코어를 사용하는 Android 그래픽 클라이언트로, VLESS·Reality 등의 조합이 필요한 모바일 환경에 적합합니다. v2flyNG는 v2fly 코어를 사용하므로 V2Fly 설정 체계에 적합합니다. Xray 전용 항목이 포함된 경우 공유 링크 이름만 바꾸면 호환될 것이라고 가정해서는 안 됩니다.

구독을 가져오는 것은 노드 기록을 클라이언트에 저장하는 과정일 뿐, 현재 코어가 모든 노드를 실행할 수 있다는 뜻은 아닙니다. 구독 링크에는 클라이언트가 인식하지 못하는 flow·보안 유형·암호화 방식이 포함될 수 있습니다. 같은 구독이 v2rayN과 v2rayNG에서는 작동하지만 v2flyNG에서 실패한다면, 먼저 프로토콜 확장 항목과 코어 기능을 비교하세요. 처음부터 구독 주소가 손상되었다고 의심할 필요는 없습니다.

v2rayN 7.x에서 「구독 그룹」→「구독 그룹 설정」으로 들어가 구독 주소가 완전하고 그룹이 활성화되어 있는지 확인하세요.
메인 화면으로 돌아가 「구독 그룹」→「모든 구독 업데이트」를 실행하고 노드 수와 업데이트 시간이 바뀌는지 확인하세요.
노드를 선택한 뒤 「서버」→「서버 실제 연결 지연 시간 테스트」를 실행하세요. ICMP 방식의 지연 시간만으로 프록시 사용 가능 여부를 판단하지 마세요.
「설정」→「매개변수 설정」으로 들어가 로컬 SOCKS 및 HTTP 수신 포트를 확인하세요. 일반적인 기본값은 각각 10808과 10809이지만 실제 값은 현재 화면을 기준으로 합니다.
v2rayNG 1.10.x에서 왼쪽 상단 메뉴의 「구독 설정」으로 들어가 주소를 저장한 뒤 메인 화면으로 돌아와 「구독 업데이트」를 실행하세요.
연결하기 전에 노드 편집 화면을 열고 주소·포트·사용자 식별자 또는 비밀번호·전송 방식·TLS·SNI·flow를 항목별로 확인하세요.

프로토콜 설정 예시
프로토콜: VLESS
전송: TCP
보안: Reality
코어: Xray
포트: 서버에서 실제로 개방한 포트
확인 항목: UUID / serverName / publicKey / shortId / fingerprint / flow

속도·지연 시간·위장성은 어떻게 비교해야 할까

프로토콜 속도 테스트에서는 변수를 통제해야 합니다. 같은 기기, 같은 네트워크, 같은 서버 회선, 비슷한 시간대에 테스트하고 네 노드가 가능한 한 같은 출구를 사용하게 하세요. VMess 노드는 한 지역에 있고 VLESS 노드는 다른 지역에 있다면 결과는 주로 회선 차이를 반영하므로 프로토콜의 우열을 입증할 수 없습니다.

지연 시간도 유형을 구분해야 합니다. TCP 연결 설정 지연은 클라이언트가 대상 포트에 연결을 완료하는 데 걸린 시간만 나타냅니다. 실제 연결 지연에는 프록시 핸드셰이크가 포함되고, 웹페이지 로딩은 DNS·TLS·동시 연결 수·대상 사이트 응답의 영향을 함께 받습니다. v2rayN에서 80ms가 측정되었다고 해서 웹페이지의 모든 리소스가 80ms 안에 로드된다는 뜻은 아닙니다.

재현 가능한 테스트를 세 차례 진행하세요

1차 연결 설정: 각 노드의 실제 연결 지연을 5회 측정하고 최고값과 최저값을 제외한 뒤, 가운데 3회의 안정성을 비교하세요.
지속 전송: 동일한 고정 테스트 파일을 60초 동안 계속 다운로드하면서 속도가 자주 0으로 떨어지는지 확인하세요. 순간 최고 속도로 결론을 내리지 마세요.
장시간 연결: 웹 세션 또는 터미널 연결을 10분간 유지하며 재연결 여부와 기기 화면을 끈 뒤 중단되는지 기록하세요.
장애 재테스트: 가정용 Wi-Fi에서 모바일 네트워크로 전환하는 것처럼 네트워크를 바꾼 뒤 한 번 더 테스트하고, 대역폭보다 복구 시간을 비교하세요.

“위장성” 역시 프로토콜 하나만으로 결정되지 않습니다. VMess에 일반 TCP를 조합한 경우와 WebSocket + TLS를 조합한 경우의 외부 특성은 다릅니다. VLESS + Reality와 VLESS + 일반 TLS도 서로 다르며, Trojan의 배포 품질은 TLS와 서버 접속 경로 설정에 좌우됩니다. 프로토콜은 전체 연결의 한 계층일 뿐이고, 도메인·인증서·SNI·전송 방식·서버 응답이 함께 핸드셰이크 결과를 결정합니다.

결론: 속도가 비슷하면 장애 요인이 적은 설정을 우선하세요

5회 실제 연결 테스트와 60초 지속 전송에서 두 프로토콜의 결과가 비슷하다면, 항목을 확인하기 쉽고 클라이언트 코어의 지원이 명확하며 서버 업데이트 절차가 분명한 설정을 우선 유지하세요. 전송 계층을 계속 추가할 필요는 없습니다.

가져오기 실패·핸드셰이크 실패·연결 후 트래픽 없음의 점검 순서

프로토콜 선택의 최종 목표는 연결 가능한 상태입니다. 가져오기 실패는 대개 링크 형식이나 클라이언트 인식 문제이고, 핸드셰이크 실패는 인증·시간·보안 계층·전송 항목과 관련되는 경우가 많습니다. 연결됨으로 표시되지만 트래픽이 없다면 시스템 프록시, 라우팅 규칙, DNS, 로컬 수신 포트를 계속 확인해야 합니다. 세 가지 문제를 분리하면 불필요한 변경을 줄일 수 있습니다.

코어 확인: 현재 v2rayN·v2rayNG·v2flyNG 중 무엇을 사용하는지, 노드에 해당 코어가 지원하지 않는 확장 항목이 포함되어 있는지 먼저 확인하세요.
시스템 시간 확인: VMess와 TLS 계열 연결은 잘못된 시간의 영향을 받을 수 있으므로 자동 날짜·자동 시간·자동 시간대를 활성화하세요.
인증 항목 확인: VMess/VLESS는 UUID를, Trojan은 비밀번호를, Shadowsocks는 비밀번호와 method를 확인하세요.
보안 항목 확인: TLS에서는 serverName과 인증서 도메인을, Reality에서는 공개 키·shortId·fingerprint·flow를 확인하세요.
전송 항목 확인: TCP·WebSocket·gRPC 등의 유형과 경로·서비스 이름·Host가 서버 설정과 일치하는지 확인하세요.
코어 로그 확인: timeout, connection refused, authentication failed, certificate, unsupported method를 구분해 확인하세요.
로컬 출구 확인: 시스템 프록시가 켜져 있고 애플리케이션이 사용하는 포트가 v2rayN의 현재 수신 포트와 일치하는지 확인하세요.

프로토콜 선택 시 자주 묻는 질문

VLESS가 항상 VMess보다 빠른가요?

그렇지는 않습니다. 같은 회선에서 동일한 전송 방식을 사용하고 패킷 손실이 적다면 두 프로토콜의 차이는 네트워크 변동보다 작을 수 있습니다. 각각 실제 연결 지연을 5회 측정한 뒤 60초간 지속 전송을 실행하세요. 결과가 비슷하다면 서버와 클라이언트 모두 관리하기 쉬운 설정을 우선하세요.

Trojan에서 인증서 오류가 발생하면 allowInsecure를 켜야 하나요?

일반적인 해결 방법으로 사용해서는 안 됩니다. 먼저 기기 시간을 동기화하고, 노드의 serverName이 인증서 적용 도메인인지 확인한 뒤 연결 포트가 서버의 TLS 접속 경로와 일치하는지 점검하세요. 인증서 연결을 바로잡은 후에도 allowInsecure는 꺼 두세요.

Shadowsocks를 가져온 뒤 지원되지 않는 암호화 방식이 표시되면 어떻게 하나요?

노드 편집 화면에서 전체 method를 기록하고 클라이언트 코어가 해당 방식을 지원하는지 확인하세요. aes-128-gcm 같은 다른 값으로 임의 변경하지 마세요. 암호화 방식과 비밀번호는 서버와 완전히 일치해야 하며, 필요하면 구독 제공자에게 호환 설정을 다시 발급해 달라고 요청하세요.

같은 노드가 v2rayN에서는 작동하지만 v2flyNG에서는 작동하지 않는 이유는 무엇인가요?

먼저 노드에 Reality·Vision 또는 Xray에 의존하는 다른 항목이 포함되어 있는지 확인하세요. 데스크톱 클라이언트에서 가져오고 실행된다고 해서 v2fly 코어가 동일한 기능을 제공하는 것은 아닙니다. v2flyNG에서는 서버가 공식적으로 제공하는 VMess·Trojan 또는 호환 가능한 Shadowsocks 노드를 사용해 보세요.

네 가지 프로토콜 중 백업으로 몇 개를 남겨야 하나요?

일반적으로 실제 검증을 마친 서로 다른 조합 두 가지면 충분합니다. 예를 들어 VLESS + Reality를 주력으로 사용하고 VMess + TLS 또는 Shadowsocks를 백업으로 둘 수 있습니다. 두 조합 모두 연결 설정, 60초 전송, 10분 장시간 연결 테스트를 각각 완료해야 합니다.

최종 선택 절차는 한 문장으로 정리할 수 있습니다. 먼저 코어 지원 여부를 확인하고, 전체 프로토콜 스택을 확인한 다음, 실제 네트워크에서 안정성을 테스트하세요. 새 Xray 설정에서는 VLESS가 흔히 쓰이는 주력 후보이고, 기존 구독을 유지해야 한다면 VMess를 남겨 두세요. 표준 TLS 접속 경로가 있다면 Trojan을 사용할 수 있으며, 기기 리소스가 제한되거나 간결한 백업 설정이 필요하면 Shadowsocks를 검토하세요. 어떤 선택이든 서버가 실제로 제공하는 매개변수를 기준으로 해야 합니다.