이미 구독을 이용 중이라면 프로토콜 이름만 보고 순위를 매기기보다 안정적으로 연결되는 전체 노드 구성을 먼저 선택하세요. 직접 서버를 구축한다면 인증 방식, 외부 보안 계층, 기기 부하를 비교하면 됩니다. 이 글에서는 네 가지 프로토콜을 각각 설명하고 데스크톱·Android·저사양 기기에서의 선택 순서를 안내합니다. 마지막에는 가져오기 설정을 확인하고 프로토콜을 바꾸면 실제로 속도가 빨라지는지도 판단할 수 있습니다.
프록시 프로토콜·전송 방식·암호화 계층 구분하기
VMess·VLESS·Trojan·Shadowsocks는 프록시 통신을 위한 프로토콜이지, 클라이언트 네 가지를 뜻하지 않습니다. v2rayN은 데스크톱 클라이언트이고, v2rayNG는 Xray 코어를 사용하는 Android 클라이언트이며, v2flyNG는 v2fly 코어를 사용하는 Android 클라이언트입니다. 클라이언트는 노드를 관리하고 코어를 호출합니다. 실제로 지원되는 프로토콜과 매개변수는 사용 중인 코어와 버전에 따라 달라집니다.
노드 하나에도 여러 프로토콜 태그가 붙을 수 있습니다. 예를 들어 VLESS + TCP + REALITY는 프록시 프로토콜, 전송 방식, 보안 메커니즘의 세 계층으로 구성됩니다. WebSocket은 VMess의 다른 이름이 아니며 TLS도 Trojan만의 기능이 아닙니다. 속도를 비교하면서 전송 방식·암호화·회선을 빼고 “VLESS와 VMess 비교”라고만 하면 실용적인 결론을 내리기 어렵습니다.
- 프록시 프로토콜: 사용자 인증, 대상 주소 표현, 데이터 전달 방식을 정합니다. VMess와 VLESS가 이에 해당합니다.
- 전송 방식: TCP, WebSocket처럼 프록시 데이터를 전달하는 방식을 정합니다. 양쪽에서 호환되는 조합을 사용해야 합니다.
- 보안 메커니즘: TLS나 REALITY 등이 핸드셰이크와 전송 보호를 담당합니다. 지원 여부는 코어에 따라 다릅니다.
- 라우팅 및 트래픽 처리: 시스템 프록시, TUN, 분할 라우팅 규칙에 따라 프록시를 거칠 앱이 정해집니다. 원격 프로토콜 자체를 바꾸지는 않습니다.
따라서 구독에 같은 프로토콜 이름으로 표시된 노드라도 실제 성능은 크게 다를 수 있습니다. 출구 위치, 저녁 시간대의 부하, 통신망 간 패킷 손실, 중계 경로가 프로토콜 자체보다 웹페이지 로딩과 다운로드 처리량에 더 큰 영향을 주는 경우가 많습니다.
네 가지 프로토콜의 배경·인증·암호화 차이
Shadowsocks는 가벼운 암호화 프록시를 지향하며 등장했습니다. VMess는 V2Ray 생태계의 인증·암호화 프록시 프로토콜이고, VLESS는 일부 기능을 분리해 더 간결한 구조를 취합니다. Trojan은 일반적으로 TLS로 프록시 연결을 보호합니다. 출발점이 서로 다르므로 이를 구형부터 신형까지의 성능 순위로 받아들여서는 안 됩니다.
| 프로토콜 | 인증 정보 | 데이터 보호 방식 | 가져올 때 확인할 항목 |
|---|---|---|---|
| VMess | UUID, 인증 시각 의존 | 프로토콜 자체의 데이터 암호화를 지원하며 TLS를 추가할 수도 있음 | UUID, 암호화 설정, 시스템 시간, 전송 매개변수 |
| VLESS | UUID | 일반적인 구성에서는 TLS 또는 REALITY로 연결 보호 | 보안 유형, 서버 이름, 흐름 제어 및 관련 공개 키 매개변수 |
| Trojan | 비밀번호 | 표준 구성에서는 TLS로 전송 보호 | 비밀번호, 서버 이름, 인증서 검증 |
| Shadowsocks | 비밀번호 또는 지정된 방식에서 요구하는 키 | 선택한 암호화 방식으로 프록시 데이터 보호 | 암호화 방식, 키 형식, 서버 호환성 |
VMess: 기존 설정을 유지할 수 있지만 시간과 인증 방식 확인 필요
VMess는 이미 보유한 안정적인 노드를 계속 사용하기에 적합합니다. 최신 구성에는 AEAD 인증을 사용해야 합니다. 이전 가이드에 나오는 0이 아닌 alterId는 과거 설정 방식이므로 새 노드의 일반적인 설정으로 적용하면 안 됩니다. 인증은 시스템 시간에 민감하므로 연결에 실패하면 먼저 자동 시간 동기화를 켜세요. UUID가 맞더라도 WebSocket 경로, Host, TLS 서버 이름이 올바르다는 뜻은 아닙니다.
VLESS: 가볍다고 보안 계층을 생략해도 되는 것은 아닙니다
일반적인 VLESS 설정에서 encryption=none은 해당 계층에서 기존 방식의 페이로드 암호화를 하지 않는다는 뜻이지, 연결 전체가 암호화되지 않는다는 뜻은 아닙니다. TLS 또는 REALITY와 함께 사용하면 해당 보안 메커니즘이 연결을 보호합니다. 이 설정을 이유로 공용 인터넷에 보안 계층 없는 연결을 구성하지 마세요. REALITY와 Vision 등의 기능을 사용하려면 Xray 지원 여부도 확인해야 합니다. Xray 설정을 모든 v2fly 코어에서 사용할 수 있다고 가정해서는 안 됩니다.
Trojan과 Shadowsocks: TLS 및 암호화 방식 확인
Trojan은 대개 비밀번호로 인증하고 TLS로 전송을 보호합니다. 인증서 검증과 서버 이름을 꼼꼼히 설정해야 합니다. Shadowsocks에서는 chacha20-ietf-poly1305처럼 암호화 방식을 명시해야 합니다. Shadowsocks 2022는 특정 키가 필요한 별도의 방식이므로 암호화 방식 이름만 바꾸고 아무 비밀번호나 그대로 사용하면 안 됩니다. 어느 쪽이든 서버 주소만 입력하면 무조건 연결되는 것은 아닙니다.
결론: 전체 구성을 먼저 확인한 뒤 프로토콜 지원 여부 판단
노드의 프로토콜, 전송 방식, 보안 유형, 인증 항목을 하나씩 맞춰 보세요. 프로토콜 이름이 같다는 사실만으로 클라이언트 연결을 보장할 수는 없습니다. 올바른 설정 대신 인증서 검증을 끄는 방법도 사용하지 마세요.
사용 환경별 선택: 웹 브라우징·기존 구독·저사양 기기
아래 권장 사항은 서버 구성을 직접 선택할 수 있는 사용자를 대상으로 합니다. 구독만 이용한다면 제공업체가 실제로 제공하는 매개변수를 기준으로 하세요. 클라이언트에서 VMess를 VLESS로 바꿔도 원격 서버가 자동으로 다른 프로토콜을 지원하게 되지는 않습니다.
VLESS + TLS 또는 REALITY
추천새 노드를 구성하고 양쪽 코어가 지원한다면 이 조합을 우선 검토하세요. 관련 매개변수를 모두 일치시켜야 합니다. Vision을 사용한다면 서버와 클라이언트의 흐름 제어 설정도 같아야 합니다. 이는 배포 구성에 대한 권장 사항이지, 모든 네트워크에서 속도를 보장한다는 뜻은 아닙니다.
추천 대상: 서버를 직접 관리하고 Xray 기능을 확인할 수 있는 일상용 주 연결
VMess
기존 노드가 안정적이라면 계속 사용하세요. 서버에서 WebSocket + TLS를 사용 중이라면 경로, Host, 서버 이름을 모두 유지하세요. 이미 정상 작동하는 구성을 통째로 다시 만들 필요는 없습니다.
추천 대상: 기존 구독이나 서버 구성을 유지하며 현재 연결 경로를 그대로 사용하려는 경우
Trojan
서버에 TLS가 올바르게 설정되어 있으면 비밀번호와 인증서 관련 항목을 비교적 쉽게 구성할 수 있습니다. 성능을 최적화하기 전에 서버 이름과 인증서 체인 문제부터 해결하세요.
추천 대상: 사용 가능한 인증서와 도메인이 있고 표준 TLS 설정 절차를 따르려는 경우
Shadowsocks AEAD
양쪽에서 같은 방식을 지원한다면 설정 항목이 적어 저사양 기기에서 검토해 볼 만합니다. AES 하드웨어 가속을 사용할 수 있는지에 따라 ChaCha20 방식과 실제 부하가 달라질 수 있습니다.
추천 대상: 설정을 단순하게 유지하고 CPU 사용량을 줄이고 싶은 기기와 환경
‘가볍다’는 표현은 처리 비용의 일부만 설명합니다. 저사양 기기에서 직접 연결할 트래픽까지 프록시로 보내고 있다면, 불필요한 트래픽 처리를 줄이는 편이 프로토콜을 바꾸는 것보다 효과적일 수 있습니다. 먼저 라우팅 규칙을 정리하고 같은 회선에서 CPU 사용량과 처리량을 비교해야 분할 라우팅의 차이를 프로토콜 성능으로 오해하지 않습니다.
모바일 배터리와 데스크톱 안정성: 프록시로 보낼 트래픽을 따로 조정
Android 배터리 소모는 프로토콜 이름만으로 판단할 수 없습니다. 신호가 약한 환경, 잦은 재연결, 백그라운드 앱의 지속적인 네트워크 사용, 프록시 연결의 활성 상태 유지 여부가 모두 배터리에 영향을 줍니다. 같은 기기와 네트워크에서 테스트하지 않았다면 특정 프로토콜이 얼마나 더 절전된다고 단정할 수 없습니다.
설정 방법: 같은 후보 노드로 트래픽 진입 범위 조절
데스크톱: v2rayN
- 먼저 시스템 프록시로 브라우저 접속을 확인한 다음 필요에 따라 TUN을 켜세요.
- 「설정」→「매개변수 설정」에서 실제 수신 대기 포트를 확인하세요. 메뉴 이름은 버전에 따라 달라질 수 있습니다.
- 직접 연결 규칙은 유지하고, 테스트 중에는 다운로드와 시스템 백그라운드 업데이트를 일시 중지하세요.
Android: v2rayNG / v2flyNG
- 앱별 프록시에서는 필요한 앱만 포함해 테스트 범위를 제한하세요.
- 네트워크, 화면 밝기, 테스트 시간을 동일하게 맞춘 뒤 배터리 소모량을 기록하세요.
- v2flyNG에서는 먼저 코어 지원 여부를 확인하고 Xray 전용 조합을 그대로 적용하지 마세요.
같은 구독을 사용하더라도 양쪽 클라이언트가 똑같은 기능을 지원하는 것은 아닙니다. 호환되는 노드를 각각 유지하고 테스트 조건을 동일하게 맞추세요.
화면을 끈 뒤 자주 연결이 끊긴다면 VMess나 Trojan 탓으로 돌리기 전에 시스템의 백그라운드 실행 제한과 로그의 재연결 기록을 확인하세요. 배터리 제한을 조정하면 연결이 더 오래 유지될 수 있지만 백그라운드 활동이 늘어날 수도 있으므로 실제 사용 환경에 맞춰 선택해야 합니다.
프로토콜 속도 측정법: 포트·회선·테스트 조건 고정
포트 번호는 프로토콜을 식별하는 값이 아닙니다. 443은 TLS 서비스에 자주 쓰이지만 노드의 포트를 443으로 바꾼다고 TLS가 자동으로 활성화되지는 않습니다. 로컬 수신 대기 포트는 앱과 클라이언트 사이의 연결에만 사용됩니다. 아래 세 숫자는 설정 항목의 역할을 구분하기 위한 예시이며, 모두 일괄 변경해야 하는 기본값은 아닙니다.
로컬 포트는 현재 클라이언트 화면에 표시된 값을 기준으로 하세요. 일부 버전은 혼합 수신을 사용하므로 HTTP와 SOCKS 포트를 따로 설정할 필요가 없습니다. 원격 포트는 서버 설정과 일치해야 합니다. 로컬 수신 대기는 이 기기에서만 사용한다면 루프백 주소로 제한해 LAN에 실수로 공개되지 않도록 하세요.
- 출구 위치 고정: 가능하면 같은 서버에서 여러 프로토콜을 비교하세요. 서로 다른 지역의 구독 노드를 비교하면 노드 사용 경험만 비교할 수 있으며 프로토콜의 영향을 분리할 수 없습니다.
- 테스트 작업 고정: 같은 다운로드 주소를 사용해 60초씩 3회 연속으로 테스트하고 평균 처리량, 실패 횟수, CPU 사용량을 기록하세요. 이는 테스트 방법이며 이 글에서 측정한 결과가 아닙니다.
- 첫 연결과 지속 전송을 따로 측정: 웹페이지의 첫 로딩은 핸드셰이크·DNS·왕복 지연 시간의 영향을 더 많이 받으며, 대용량 파일 다운로드는 지속 처리량을 더 잘 보여줍니다.
- 전체 구성 기록: TLS, 전송 방식, 흐름 제어, 다중화 설정, 코어 버전을 함께 적으세요. “VLESS가 빠르다”라고만 기록하지 마세요.
- 혼잡 시간대에 재측정: 프로토콜 간 차이가 여러 차례 측정한 결과의 편차보다 작다면 실패가 적고 관리가 쉬운 구성을 우선하세요.
결론: 병목을 먼저 찾고 프로토콜 변경 여부 결정
CPU 사용량이 계속 최대치에 가까울 때 암호화와 캡슐화 비용을 중점적으로 비교할 필요가 있습니다. CPU 여유가 있는데 모든 노드가 느리다면 먼저 회선, 패킷 손실, 서버 속도 제한을 확인하세요. 프로토콜을 바꿔도 이런 병목은 해결되지 않습니다.
가져온 뒤 연결되지 않을 때: 자주 발생하는 문제 네 가지
구독은 노드 매개변수를 배포할 뿐, 호환되지 않는 코어에 새로운 기능을 추가해 주지는 않습니다. 구독을 업데이트한 뒤 노드 항목이 모두 있는지 확인하고 클라이언트 로그를 살펴보세요. 문제 해결 정보를 공유할 때는 UUID, 비밀번호, 구독 주소와 인증 정보를 가리세요.
VMess UUID가 맞는데도 인증에 실패하는 이유는 무엇인가요?
먼저 시스템 날짜 설정에서 자동 시간 동기화를 켜고 서버에서 해당 사용자가 계속 활성화되어 있는지 확인하세요. 오래된 설정을 사용 중인 노드라면 과거 방식의 alterId 항목이 있는지 살펴보세요. 이전 가이드를 무작정 따라 하지 마세요. 마지막으로 전송 방식과 TLS 매개변수를 하나씩 비교하세요.
VLESS를 가져올 수 있는데 연결할 때 지원하지 않는다고 나오는 이유는 무엇인가요?
가져오기에 성공했다는 것은 클라이언트가 링크 형식을 인식했다는 뜻일 뿐입니다. 실제로 실행 중인 코어와 노드에서 REALITY나 Vision 같은 기능을 사용하는지 확인하세요. 누락된 보안 매개변수를 채우세요. 코어가 지원하지 않는다면 흐름 제어 항목을 지우고 시도하지 말고 호환되는 노드를 선택하세요.
Trojan에서 인증서 오류가 발생하면 검증을 건너뛰어도 되나요?
먼저 시간을 맞춘 다음 서버 이름과 서버 인증서가 일치하는지 확인하고, 서버 관리자에게 인증서 유효 기간과 인증서 체인을 점검해 달라고 요청하세요. 검증 건너뛰기를 장기적인 해결책으로 삼지 마세요. 연결 상대의 신원을 확인하는 기능이 약해집니다.
Shadowsocks 비밀번호가 같은데 클라이언트를 바꾸면 작동하지 않는 이유는 무엇인가요?
암호화 방식, 서버 포트, 키 형식을 모두 확인하세요. 특히 기존 AEAD 방식의 비밀번호를 Shadowsocks 2022의 고정 길이 키로 그대로 사용하면 안 됩니다. 양쪽에서 같은 방식을 지원하는지 확인한 뒤 UDP와 라우팅 요구 사항을 점검하세요.
선택 순서: 호환성과 안정성을 먼저, 리소스 사용량은 그다음
일상적인 웹 브라우징에는 회선이 안정적이고 필요한 매개변수가 모두 갖춰진 노드를 우선 선택하세요. 새로 구축한다면 보안 설정을 포함한 VLESS 구성을 검토할 수 있습니다. 기존 VMess나 Trojan 연결은 이름만 보고 바꿀 필요가 없습니다. 저사양 기기에서는 Shadowsocks AEAD 등을 후보로 테스트하되 기기의 CPU 사용량, 연결 실패율, 처리량 기록을 기준으로 결정하세요.
- 먼저 호환성 확인: 현재 코어에서 프로토콜·전송 방식·보안 메커니즘·흐름 제어가 함께 작동하는지 살펴보세요.
- 그다음 안정성 확인: 주로 사용하는 시간대에 연결이 자주 끊기지 않는지, 웹페이지와 실제 앱이 정상 작동하는지 확인하세요.
- 마지막으로 최적화: 조건을 동일하게 맞춘 테스트로만 프로토콜 변경에 따른 효과를 확인할 수 있습니다.
용어를 확인하려면 프로토콜 용어집을 참고하세요. 보안 매개변수를 설정하기 전에는 프로토콜 참고 자료를 먼저 읽어 보세요. 검증을 마친 설정 하나를 보존한 뒤 항목을 하나씩 변경하면 프로토콜·DNS·라우팅·코어를 한 번에 바꾸는 것보다 문제를 찾기 쉽습니다.