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

이 글 한눈에 보기

이 글은 구독 노드 이름을 확인하거나 서버를 배포하려는 사용자, 프로토콜 호환 문제를 점검하는 사용자에게 적합합니다. 프로토콜, 전송 방식, 보안 계층의 역할을 구분하고 현재 기기와 네트워크 조건에서 VMess, VLESS, Trojan, Shadowsocks가 적합한지 판단하는 데 초점을 둡니다.

먼저 프로토콜·전송 방식·보안 계층을 구분하기

VMess, VLESS, Trojan, Shadowsocks는 모두 클라이언트와 서버 사이에서 프록시 데이터를 주고받는 프로토콜입니다. 노드 이름에는 WebSocket, gRPC, TCP, TLS, Reality 등이 함께 표시되는 경우가 많지만, 이 항목들이 모두 프로토콜 이름인 것은 아닙니다. WebSocket, gRPC, TCP는 데이터 전송 방식을 설명하고, TLS와 Reality는 연결 보안이나 핸드셰이크 동작을 담당합니다. 도메인, 포트, 경로는 연결 매개변수에 해당합니다.

같은 프로토콜도 서로 다른 전송 방식과 조합할 수 있습니다. 예를 들어 VMess는 TCP 또는 WebSocket 위에서 사용할 수 있고, VLESS는 TCP, gRPC 및 여러 보안 계층과 결합할 수 있습니다. 이런 조합 조건을 무시하고 프로토콜을 비교하면 WebSocket의 추가 캡슐화 부담을 VMess 자체의 부담으로 잘못 계산하거나, 특정 보안 계층의 특성을 모두 VLESS의 특성으로 오해하기 쉽습니다.

Trojan은 일반적으로 TLS에 의존합니다. 핸드셰이크가 실패하면 노드가 만료되었다고 단정하기보다 먼저 도메인, 서버 시간, 인증서 상태, 포트를 확인해야 합니다. Shadowsocks는 독립적인 암호화 방식으로 프록시 데이터를 보호하지만, 완전한 웹사이트 접속 과정을 모방하는 것이 목적은 아닙니다. 설정 항목이 적고 구현이 성숙했으므로, 적합성은 서버가 제공하는 암호화 방식과 클라이언트 코어의 지원 여부에 달려 있습니다.

프로토콜	인증 및 핸드셰이크 핵심	일반적인 조합	문제 해결 시 먼저 확인할 항목
VMess	사용자 식별자, 시간 동기화, AEAD 데이터 처리	TCP, WebSocket, gRPC, TLS 추가 가능	사용자 식별자, 시스템 시간, 전송 매개변수
VLESS	경량 인증, 프로토콜 자체는 콘텐츠 암호화를 담당하지 않음	TCP, WebSocket, gRPC, TLS 또는 Reality 설정 가능	보안 계층, flow 값, 서버 및 코어 지원 여부
Trojan	비밀번호 인증 및 TLS 연결	일반적으로 TCP와 TLS	도메인, 포트, TLS 핸드셰이크, 서버 시간
Shadowsocks	사전 공유 비밀번호 및 지정 암호화 방식	일반적으로 TCP 또는 UDP에서 직접 실행	암호화 방식, 비밀번호, UDP 설정

4가지 프로토콜의 핸드셰이크와 호환 범위

VMess는 V2Ray 생태계에서 시간 기반 검증과 사용자 식별자를 사용합니다. 최신 설정은 일반적으로 AEAD 모드를 사용하며, 구형 튜토리얼에서 alterId를 큰 값으로 설정하던 방식은 새 설정의 기준으로 적합하지 않습니다. 클라이언트 로그에 인증 실패가 나타나고 같은 노드가 다른 기기에서도 연결되지 않는다면 서버와 단말의 시스템 시간 차이가 큰지 확인하고, 구독 업데이트 후 사용자 식별자가 바뀌었는지 점검해야 합니다.

VLESS는 프로토콜 계층의 데이터 처리를 간소화하고 보안 책임을 외부 보안 계층에 맡깁니다. 그렇다고 “암호화되지 않은 연결”을 뜻하는 것은 아닙니다. 실제 보안성은 전체 조합에 의해 결정됩니다. 공용 네트워크로 연결할 때는 TLS, Reality 또는 서버가 지정한 다른 보안 매개변수를 빠짐없이 확인해야 합니다. 주소, 포트, 사용자 식별자만 복사하고 serverName, publicKey, shortId 또는 flow를 누락하면 핸드셰이크가 실패합니다.

Trojan의 설정 구조는 비교적 직관적이며, 일반적인 핵심 항목은 서버 주소, 포트, 비밀번호, 도메인, TLS 관련 옵션입니다. 도메인 확인과 TLS 설정의 영향을 크게 받습니다. Shadowsocks의 핵심 항목은 서버, 포트, 비밀번호, 암호화 방식입니다. 클라이언트와 서버 중 한쪽이라도 구독에서 지정한 방식을 지원하지 않으면 시작에 실패하거나 연결이 즉시 끊길 수 있습니다.

VMess

기존 구독에서 지원 범위가 넓으므로 안정적으로 작동 중인 VMess 노드를 계속 사용하기에 적합합니다. 프로토콜 이름이 오래되었다는 이유만으로 이전할 필요는 없습니다.

적합한 경우: 기존 서비스, WebSocket 배포, 호환성 유지

VLESS

Trojan

연결 구조가 TLS를 중심으로 구성되어 항목을 이해하기 쉽지만, 도메인과 TLS 설정은 일치해야 합니다.

적합한 경우: 기존 도메인 및 TLS 환경, 간결한 설정 선호

Shadowsocks

설정 항목이 적고 구현이 성숙했으며, 서버가 지원 암호화 방식을 명확히 제공하는 경량 환경에 적합합니다.

적합한 경우: 제한된 리소스의 기기, 단순 프록시, 명확한 UDP 요구

v2rayN 데스크톱 버전은 일반적으로 Xray 코어로 위 프로토콜을 처리하지만, 실제로 사용할 수 있는 항목은 현재 코어 버전에 따라 달라집니다.
v2rayNG Android 버전은 Xray 코어를 사용하므로, 하나의 구독에 VMess, VLESS, Trojan, Shadowsocks 노드가 혼합된 경우에 적합합니다.
v2flyNG Android 버전은 v2fly 코어를 사용합니다. 최신 VLESS 조합을 가져오기 전에 코어 로그를 확인하여 현재 버전이 보안 계층과 flow 항목을 인식하는지 점검해야 합니다.

위장 기능은 프로토콜 이름만으로 판단할 수 없습니다

“어떤 프로토콜이 일반 트래픽과 더 비슷한가?”라는 질문은 설정을 제외하고 답할 수 없습니다. VMess 또는 VLESS를 WebSocket과 TLS로 전송하면 외부에서 관찰되는 것은 해당 TCP, TLS, HTTP 업그레이드 동작입니다. Trojan은 일반적으로 TLS 연결을 기반으로 하며, Shadowsocks는 암호화된 프록시 전송에 더 중점을 둡니다. 실제 동작은 포트, 도메인, 핸드셰이크 매개변수, 서버 응답, 네트워크 경로의 영향도 받습니다.

포트 번호만으로 트래픽 유형을 증명할 수도 없습니다. 443은 TLS에 자주 사용되지만 임의의 프로토콜을 443으로 변경한다고 올바른 TLS 핸드셰이크가 자동으로 이루어지는 것은 아닙니다. 반대로 서버가 8443, 2053 또는 다른 포트를 명확히 수신하도록 설정했다면 클라이언트는 구독에 제공된 정확한 값을 사용해야 합니다. 포트를 임의로 443으로 바꾸면 대개 연결이 거부되거나 핸드셰이크 단계에서 중단됩니다.

관리 가능한 서버에서는 배포자가 기존 조건에 따라 조합을 선택할 수 있습니다. 구독 사용자는 전달받은 매개변수를 우선 그대로 유지하고, “최적화”를 위해 경로, 도메인, 지문, flow 또는 보안 계층 항목을 삭제하지 않아야 합니다. 노드가 이미 작동한다면 프로토콜 이름은 일반적으로 첫 번째 조정 대상이 아닙니다. 지연 시간, 패킷 손실, 서버 부하, 경로 우회가 사용 경험에 더 직접적인 영향을 줍니다.

권장 구성: 데스크톱과 Android에서 함께 사용하는 호환 구독

데스크톱(v2rayN)

구독에서 지정한 Xray 코어 설정 사용
구독 업데이트 후 실제 연결 지연 시간을 한 번 테스트
로그에서 보안 계층과 flow 매개변수가 로드되었는지 확인

Android(v2rayNG)

같은 구독을 가져오고 전체 항목 유지
먼저 같은 이름의 노드를 테스트한 뒤 모바일 네트워크 결과 비교
필요한 경우 앱별로 프록시 적용 범위 설정

구독 서비스가 양쪽에 호환 가능한 노드를 함께 제공해야 합니다. 같은 이름의 노드라도 네트워크 환경에 따라 지연 시간과 패킷 손실이 다를 수 있습니다.

결론: 전체 조합을 먼저 확인한 뒤 프로토콜 비교

프로토콜 이름은 연결의 일부만 결정합니다. 도메인, 포트, 전송 방식, 보안 계층, 코어 버전 중 하나라도 맞지 않으면 정상 노드가 핸드셰이크 실패로 이어질 수 있습니다.

성능 부담은 같은 경로에서 측정해야 합니다

프로토콜 성능은 한 번의 속도 측정만으로 결론 내릴 수 없습니다. 서버 위치, 인바운드 대역폭, 피크 시간대 혼잡, TCP 혼잡 제어, 전송 캡슐화, 단말 처리 성능이 결과를 바꿉니다. 네 가지 프로토콜을 비교하려면 최소한 노드를 같은 서버 또는 같은 데이터센터에 두고, 출구 경로, 테스트 파일, 측정 시간을 동일하게 유지한 뒤 여러 차례 반복해 중앙값을 구해야 합니다.

다음은 테스트 방법을 설명하기 위한 통제된 기준 조건입니다. 클라이언트는 유선 네트워크로 연결하고 접속 대역폭은 300 Mb/s로 제한했습니다. 서버까지 유휴 상태 왕복 지연 시간은 41 ms, 평균 패킷 손실률은 0.2%이며, 각 프로토콜을 10분 동안 연속 전송했습니다. 테스트 조합은 VMess + WebSocket + TLS, VLESS + TCP + Reality, Trojan + TLS, Shadowsocks 2022입니다.

300 Mb/s

클라이언트 접속 상한

41 ms

서버 유휴 상태 왕복 지연 시간

0.2%

테스트 중 평균 패킷 손실

10분

각 조합의 연속 전송 시간

이 환경에서 네 그룹의 다운로드 중앙값은 각각 268 Mb/s, 286 Mb/s, 281 Mb/s, 289 Mb/s였습니다. 이 결과는 패킷 손실이 적고 대역폭이 아직 포화되지 않은 특정 환경에서 네 설정 모두 접속 상한에 근접했다는 점만 보여줍니다. Shadowsocks가 다른 경로에서도 반드시 가장 빠르다고 결론 내릴 수는 없습니다. VMess 조합의 WebSocket 캡슐화, VLESS 조합의 보안 계층, 서버 구현 차이가 모두 최종 결과에 영향을 주었습니다.

실제 연결 지연 시간은 ICMP Ping과 구분해야 합니다. Ping은 네트워크 계층의 왕복만 보여주지만, 실제 연결 지연 시간에는 프록시 핸드셰이크, 보안 계층 협상, 대상 연결 과정이 포함됩니다. 특정 노드의 Ping이 45 ms이고 실제 연결 지연 시간이 92 ms인 것은 이상하지 않습니다. 실제 연결 지연 시간이 계속 800 ms를 넘거나 시간 초과가 발생한다면 코어 로그와 함께 핸드셰이크, 이름 확인, 서버 응답 중 어느 단계의 문제인지 판단해야 합니다.

결론: 차이가 네트워크 변동보다 작다면 프로토콜을 바꿀 필요가 없습니다

같은 경로에서 세 차례 반복한 처리량 차이가 10% 미만이라면, 한 번의 최고 속도를 기준으로 이전하기보다 연결이 안정적이고 클라이언트가 완전히 지원하며 구독 매개변수가 정상적으로 관리되는 노드를 우선 선택해야 합니다.

이름이 아니라 사용 시나리오에 따라 선택하기

안정적으로 작동 중인 구독이라면 먼저 구독을 업데이트한 다음 같은 지역의 노드에서 실제 연결 지연 시간을 테스트하는 것이 가장 직접적인 방법입니다. VMess 노드가 여러 날 연속으로 사용 가능하고 지연 시간이 안정적이며 대역폭도 충분하다면 프로토콜을 바꾸기 위해 조정할 필요가 없습니다. 프로토콜 이전에는 서버, 방화벽, 도메인 확인, 구독 생성 규칙까지 바뀔 수 있으므로 변경 비용도 판단에 포함해야 합니다.

새로 배포하고 양쪽 모두 최신 Xray 코어를 사용한다면 VLESS와 적절한 보안 계층 조합을 우선 검토할 수 있습니다. 이미 표준 TLS 환경이 있다면 Trojan은 매개변수 구조를 확인하기 쉽습니다. 리소스가 제한적이고 설정이 단순하며 서버가 해당 암호화 방식을 명확히 지원한다면 Shadowsocks도 여전히 적합합니다. 오래된 V2Ray 서버 설정을 유지해야 한다면 VMess가 기존 매개변수를 이어가기 쉽습니다.

v2rayN 7.x에서 구독 그룹을 업데이트하고 노드 이름, 주소, 포트, 프로토콜 항목이 새로 반영되었는지 확인합니다.
같은 지역의 서로 다른 프로토콜 노드를 선택해 각각 실제 연결 지연 시간을 테스트하고, 노드마다 최소 세 번 반복합니다.
코어 로그를 열어 인증 실패, TLS 핸드셰이크 실패, 도메인 확인 실패, 포트 충돌을 배제합니다.
같은 대상 파일을 사용해 계속 다운로드하고 1분 후 안정 속도를 기록합니다. 시작 직후의 최고 속도는 사용하지 않습니다.
일상적으로 사용하는 네트워크에서도 다시 테스트합니다. 고정 회선과 모바일 네트워크는 경로가 다르므로 데스크톱 결과를 Android 결과로 바로 대체할 수 없습니다.

로컬 SOCKS 수신: 127.0.0.1:10808
로컬 HTTP 수신: 127.0.0.1:10809
테스트 횟수: 노드별 3회
1회 시간 초과: 10초
기록 항목: 실제 연결 지연 시간, 다운로드 중앙 속도, 연결 끊김 횟수, 코어 로그 오류

로컬 포트는 현재 클라이언트 화면에 표시된 값을 기준으로 해야 합니다. 확인하려면 「설정」→「매개변수 설정」에서 로컬 수신 설정을 확인할 수 있습니다. 10808과 10809는 일반적인 예시 값이며, 버전이나 기존 설정에 따라 다른 포트를 사용할 수 있습니다. 브라우저나 시스템 프록시에 입력한 포트는 클라이언트가 실제로 수신 중인 포트와 일치해야 합니다.

자주 묻는 선택 및 문제 해결

프로토콜 선택은 실행 가능한 점검으로 마무리해야 합니다. 클라이언트가 구독 항목을 해석할 수 있는지, 코어가 해당 조합을 지원하는지, 현재 네트워크에서 핸드셰이크를 완료할 수 있는지, 지속 전송이 안정적인지를 확인해야 합니다. 다음 질문들은 “어떤 프로토콜이 가장 좋은가”보다 일상적인 사용 환경에서 더 현실적인 판단 기준을 제공합니다.

구독에 네 가지 프로토콜이 모두 있다면 무엇부터 선택해야 하나요?

먼저 지역별로 필터링한 뒤 프로토콜마다 노드 하나씩 선택해 실제 연결 지연 시간을 세 번 테스트합니다. 시간 초과 노드를 제외하고 같은 대상을 3분 동안 연속 다운로드한 다음, 지연 변동이 작고 연결 끊김이 없으며 용도에 맞는 속도를 내는 노드를 선택합니다.

VLESS 노드 가져오기는 성공했지만 계속 시간 초과가 발생하면 어떻게 하나요?

노드 설정을 펼쳐 포트, 전송 방식, 보안 계층, serverName, publicKey, shortId, flow를 항목별로 확인합니다. 그런 다음 코어 로그를 확인합니다. 지원되지 않는 매개변수라는 메시지가 나오면 클라이언트 코어를 업데이트하고, 핸드셰이크 실패라면 서버 시간과 도메인 설정을 점검합니다.

Trojan은 연결되지만 브라우저에서 웹페이지가 열리지 않으면 어떻게 하나요?

먼저 v2rayN 시스템 프록시가 활성화되어 있는지 확인한 다음 「설정」→「매개변수 설정」에서 로컬 수신 포트를 점검합니다. 로그에 10808 또는 10809가 사용 중이라고 표시되면 해당 프로그램을 종료하거나 사용하지 않는 포트로 변경한 뒤 코어를 다시 시작합니다.

Shadowsocks에서 암호화 방식이 지원되지 않는다고 표시되면 어떻게 하나요?

서버도 같은 설정을 사용해야 하므로 암호화 방식을 임의로 바꾸지 마세요. 먼저 구독과 클라이언트 코어를 업데이트합니다. 그래도 인식하지 못하면 현재 코어에서 처리할 수 있는 노드를 구독에서 선택하거나, 서버가 명확히 제공한 호환 설정을 사용합니다.

데스크톱에서는 되는데 Android에서 같은 노드가 실패하면 어떻게 하나요?

양쪽의 구독 업데이트 시간이 같은지 확인하고 노드의 전체 항목을 비교합니다. v2rayNG와 v2flyNG는 서로 다른 코어를 사용하므로 최신 보안 계층이나 flow 매개변수의 버전 지원 여부가 다를 수 있습니다. 모바일 네트워크의 데이터 절약 제한도 해제한 뒤 다시 테스트하세요.

간단한 선택 규칙은 다음과 같습니다. 기존 설정이 안정적이면 계속 사용하고, 새로 배포할 때는 양쪽 코어의 지원 범위를 먼저 확인합니다. TLS 조건이 갖춰졌다면 Trojan을, 설정이 가볍고 암호화 방식이 명확하다면 Shadowsocks를 검토합니다. 어떤 프로토콜이든 노드 이름만 보지 말고 실제 연결 지연 시간, 지속 다운로드, 로그 결과를 함께 확인해야 합니다.