프로토콜 이름만으로 속도, 안정성, 배터리 소모를 판단할 수는 없습니다. 구독 정보를 받아 노드를 고르는 사용자를 위해 프록시 프로토콜, 전송 방식, 보안 계층을 구분하고 네 가지 프로토콜의 인증 방식과 연결 비용을 비교합니다. 먼저 클라이언트 커널의 지원 여부를 확인하고 TLS, 전송 방식, UDP 설정을 살핀 뒤 같은 네트워크 환경에서 테스트하세요.
프로토콜·전송 방식·보안 계층
VMess, VLESS, Trojan, Shadowsocks는 프록시 프로토콜 이름이며, v2rayN은 데스크톱 클라이언트이지 다섯 번째 프로토콜이 아닙니다. 클라이언트는 노드, 구독, 시스템 프록시와 라우팅을 관리하고 실제 연결은 커널이 처리합니다. 안드로이드의 v2rayNG는 Xray 커널을, v2flyNG는 v2fly 커널을 사용합니다. 화면 구성이 비슷하다고 두 앱의 기능 지원까지 같다고 볼 수는 없습니다.
노드 정보를 볼 때는 세 가지 계층을 함께 확인해야 합니다. 프로토콜은 인증과 프록시 요청을 정의하고, 전송 방식은 TCP나 WebSocket처럼 데이터를 전달하는 방법을 정하며, 보안 계층은 TLS처럼 연결을 보호합니다. REALITY는 Xray의 보안 메커니즘으로 VMess와 같은 프록시 프로토콜이 아니며, 아무 노드에나 적용하는 원클릭 가속 기능도 아닙니다.
- 프로토콜 항목: VMess, VLESS, Trojan, Shadowsocks 중 어떤 프로토콜인지 확인하고 서버 설정과 일치시킵니다.
- 전송 항목: TCP, WebSocket 등의 유형을 확인합니다. WebSocket을 사용한다면 경로와 Host도 맞춰야 합니다.
- 보안 항목: TLS, 서버 이름, 인증서 검증 설정을 확인합니다. REALITY는 서버에서 제공한 공개 키 등의 매개변수도 필요합니다.
- 클라이언트 설정: 시스템 프록시와 TUN은 어떤 트래픽을 커널로 보낼지 결정할 뿐, 원격 프로토콜을 다른 프로토콜로 바꾸지는 않습니다.
네 프로토콜의 배경과 암호화 범위
VMess는 V2Ray 프로젝트에서 시작했으며 사용자 인증과 데이터 보호 기능을 포함합니다. VLESS는 중복 처리를 줄이는 간결한 프로토콜로 설계됐고, 일반적인 구성에서는 TLS나 REALITY가 연결을 보호합니다. Trojan은 TLS 터널을 통해 프록시 요청을 전달합니다. Shadowsocks는 비교적 간결한 암호화 프록시 방식이며, 구체적인 기능은 사용한 방식과 구현에 따라 달라집니다.
| 프로토콜 | 인증 및 데이터 보호 | 가져온 뒤 확인할 항목 |
|---|---|---|
| VMess | UUID로 사용자를 식별합니다. 최신 구성은 VMess AEAD를 사용하며, 페이로드 암호화는 security 등의 설정에 따라 달라집니다. TLS를 추가로 적용할 수도 있습니다. | UUID, alterId, security, 전송 유형을 확인합니다. 최신 AEAD 구성에서는 일반적으로 alterId를 0으로 설정합니다. |
| VLESS | UUID로 인증합니다. encryption이 none인 일반적인 구성에서는 외부 TLS 또는 REALITY가 연결을 보호합니다. | UUID, encryption, flow, 보안 계층을 확인합니다. 추가 암호화 기능은 양쪽 커널 버전의 지원 여부에 따라 달라집니다. |
| Trojan | 비밀번호로 인증하며, 보통 TLS로 프록시 요청과 페이로드를 보호합니다. 비밀번호 인증은 서버 인증서 검증을 대신하지 않습니다. | 비밀번호, 포트, 서버 이름, 인증서 검증, 전송 방식을 확인합니다. |
| Shadowsocks | 선택한 암호화 방식으로 데이터를 보호합니다. 기존 AEAD와 Shadowsocks 2022는 키와 프로토콜 세부 사항이 다릅니다. | method, 비밀번호 또는 키 형식, UDP 지원을 확인합니다. 노드 이름에 ‘SS’가 있다고 해서 설정을 생략하면 안 됩니다. |
“VLESS는 암호화되지 않는다”는 표현은 일반적인 encryption: none 프로토콜 계층 설정에만 해당하며, 연결 전체의 암호화 여부를 뜻하지는 않습니다. 반대로 TLS를 켰더라도 매개변수를 임의로 입력해도 되는 것은 아닙니다. 서버 이름, 인증서 체인, 서버 설정이 서로 일치해야 합니다. 설정 오류를 감추려고 인증서 검증을 끄지 마세요.
핸드셰이크 비용: 최초 연결과 지속 전송 구분하기
핸드셰이크 비용은 연결을 처음 맺을 때의 대기 시간에 영향을 주며 다운로드 대역폭과는 다릅니다. TCP와 TLS 1.3으로 새 연결을 맺는 경우를 예로 들면, TCP 연결 수립에 보통 왕복 1회가 필요하고 전체 TLS 핸드셰이크에도 왕복 1회가 더 필요합니다. DNS, 프록시 요청, 대상 서버 연결은 별도로 계산해야 합니다. TLS 세션 재개, 연결 재사용, 네트워크 패킷 손실에 따라 실제 결과는 달라지므로 왕복 횟수를 단순히 더해 페이지 로딩 시간으로 볼 수는 없습니다.
- VMess: 프로토콜 인증과 페이로드 보호를 처리해야 합니다. 여기에 TLS나 WebSocket을 추가하면 해당 계층의 처리와 패킷 비용도 더해집니다.
- VLESS: 요청 헤더가 간결하다고 해서 연결 전체에 핸드셰이크가 없는 것은 아닙니다. TLS, REALITY, 전송 방식, flow의 실제 조합에 따라 연결 과정이 달라집니다.
- Trojan: 일반적인 구성에서는 먼저 TLS 터널을 맺은 다음 프록시 요청을 보냅니다. TLS 세션 재개 가능 여부는 구현과 연결 조건에 따라 달라집니다.
- Shadowsocks: 일반적인 AEAD TCP 연결은 별도의 TLS 핸드셰이크 없이 암호화된 요청 데이터를 바로 보낼 수 있습니다. 그렇다고 TCP 연결 수립이 필요 없는 것은 아니며, 종단 간 지연 시간이 더 짧다고 보장할 수도 없습니다.
WebSocket의 HTTP 업그레이드 과정에는 추가 단계가 필요합니다. 연결 재사용을 통해 여러 논리적 연결이 하나의 하위 연결을 공유할 수 있지만, 혼잡과 장애가 영향을 미치는 범위도 달라집니다. 따라서 “VMess + WebSocket + TLS”와 “Shadowsocks 직접 TCP 연결”을 비교하는 것은 프로토콜 헤더 크기만이 아니라 전체 연결 구성을 비교하는 것입니다.
결론: 전송 조합을 먼저 확인한 뒤 핸드셰이크 비용을 판단하세요
짧은 연결의 첫 요청이 느리다면 DNS, TLS 연결 수립, 잦은 재연결 여부부터 확인하세요. 대용량 파일 전송이 계속 느리다면 회선 대역폭, 패킷 손실, 서버 부하를 먼저 살펴보세요. 두 문제를 같은 ‘지연 시간’ 수치 하나로 설명해서는 안 됩니다.
모바일 배터리 소모: 프로토콜 이름보다 무선 통신이 중요합니다
모든 환경에 통하는 ‘배터리를 가장 적게 쓰는 프로토콜’ 순위는 없습니다. 암호화는 CPU를 사용하지만 기기의 AES 하드웨어 가속, ChaCha20 구현, 처리량 부하에 따라 결과가 달라집니다. 셀룰러 네트워크에서는 무선 모듈의 잦은 활성화, 연결 유지, 약한 신호로 인한 재전송, 앱의 백그라운드 동기화가 주요 배터리 소모 원인일 수 있습니다.
TUN은 단일 앱 프록시보다 더 많은 트래픽을 처리하는 경우가 많아 DNS 요청, UDP, 백그라운드 연결도 커널을 거칠 수 있습니다. 이때 발생하는 배터리 소모를 모두 VLESS나 Trojan 탓으로 돌릴 수는 없습니다. 테스트 중 상세 로그, 잦은 속도 측정, 대규모 노드 탐색을 함께 실행하지 마세요. 추가 작업에 드는 전력까지 측정하게 됩니다.
- 기기, 네트워크 유형, 화면 밝기를 고정하고 테스트를 시작하기 전에 배터리 잔량, 신호 상태, 백그라운드 앱을 기록합니다.
- 매회 같은 20분 활동을 진행합니다. 예를 들어 웹 탐색 10분, 동일한 화질의 동영상 시청 5분, 화면을 끈 채 대기 5분으로 구성합니다. 이는 테스트 방법 예시이며 이 사이트의 실측 결과가 아닙니다.
- TUN 또는 앱 프록시 방식, DNS, 라우팅 규칙을 동일하게 유지합니다. 매회 프로토콜 설정 하나만 바꾸고 실제 트래픽을 기록합니다.
- 각 후보를 3회씩 테스트하고 시스템 배터리 사용량과 커널 로그에서 재연결 여부를 확인합니다. 배터리 표시 정밀도보다 작은 차이는 단정적으로 해석하지 마세요.
사용 중인 노드와 클라이언트에 맞춰 선택
아래의 ‘추천’은 해당 서버 매개변수를 갖추고 호환되는 Xray 커널을 사용하는 일반적인 연결 환경을 기준으로 합니다. 프로토콜 순위를 뜻하지는 않습니다. 구독에서 사용할 수 있는 프로토콜이 하나뿐이라면 검증된 설정을 우선 사용하세요. 이름을 바꾸기 위해 연결 전체를 다시 구성할 필요는 없습니다.
VLESS: 보안 계층 매개변수를 모두 갖춘 경우
추천서버에서 제공한 TLS 또는 REALITY 설정 전체를 사용하고 flow와 커널 지원 여부를 확인하세요. 매개변수가 빠졌다면 옵션을 계속 바꿔가며 추측하지 마세요.
적합한 경우: Xray 커널을 사용하고 호환되는 VLESS 서버 설정을 갖춘 경우
VMess: 검증된 연결 유지
사용 중인 VMess AEAD 노드가 정상 작동한다면 계속 사용해도 됩니다. 문제 해결 시에는 프로토콜을 먼저 바꾸기보다 시스템 시간, UUID, alterId, 전송 매개변수를 확인하세요.
적합한 경우: 기존 구독이 주로 VMess를 제공하고 안정적으로 연결해 온 경우
Trojan: TLS가 이미 구성된 경우
비밀번호, 서버 이름, 인증서 설정을 확인해 연결하세요. TLS는 연결의 중요한 부분이므로 인증서 유효 기간과 양쪽의 서버 이름이 일치하는지 관리해야 합니다.
적합한 경우: 서버에 검증 가능한 TLS 터널이 구성된 경우
Shadowsocks: 암호화 방식과 UDP 요구 사항 확인
암호화 방식과 키 형식을 먼저 확인하고, 특히 기존 AEAD와 2022 방식을 구분하세요. 게임, 음성 통화 등의 환경에서는 UDP 전달도 별도로 검증해야 합니다.
적합한 경우: 매개변수가 명확하고 클라이언트가 해당 방식의 TCP 또는 UDP 프록시를 지원하는 경우
v2rayN에서 노드를 선택한 뒤 노드 편집 창을 열어 프로토콜과 전송 매개변수를 확인하세요. 버전에 따라 화면의 항목이 달라질 수 있습니다. 안드로이드에서 v2rayNG 또는 v2flyNG를 사용하는 경우에는 먼저 커널이 해당 프로토콜, 암호화 방식, 보안 확장을 지원하는지 확인하세요. 같은 구독이라도 두 커널에서 동일하게 작동한다고 볼 수는 없습니다.
같은 조건에서 검증: Tcping 결과만 보지 마세요
Tcping은 지정된 포트에 TCP로 연결할 수 있는지와 연결에 걸리는 시간을 주로 확인합니다. UUID, 비밀번호, TLS 이름, 프록시 요청의 정확성이나 UDP 사용 가능 여부는 검증하지 못합니다. 실제 연결 테스트는 프록시 요청을 더 가깝게 재현하지만, 결과는 테스트 대상, DNS, 라우팅, 연결 재사용에 따라 달라집니다.
- 접속 경로 고정: v2rayN에서 시스템 프록시 또는 TUN 상태를 동일하게 유지하고 로컬 수신 포트가 앱 설정과 일치하는지 확인합니다. 예를 들어 로컬 포트가
10808이라면 앱이 이전 포트를 계속 사용하지 않도록 확인하세요. 이는 설정 예시일 뿐 모든 버전의 기본값은 아닙니다. - 라우팅 규칙 확인: 테스트 트래픽이 선택한 프록시 아웃바운드를 실제로 통과하는지 확인합니다. 라우팅 규칙이 대상 트래픽을 직접 연결로 보내면 테스트 결과로 해당 노드의 성능을 판단할 수 없습니다.
- 항목별 측정: 첫 요청, 연속 요청, 대용량 파일 전송, UDP 앱 결과를 각각 기록하고 서로 다른 측정 항목을 하나의 점수로 합치지 마세요.
- 번갈아 재측정: A, B, A, B 순서로 테스트하고 후보별로 최소 5회 요청합니다. 중앙값과 실패 횟수를 기록해 네트워크 시간대에 따른 영향을 줄이세요.
결론: 사용할 수 있는 설정을 고른 뒤 반복 측정 결과를 비교하세요
인증 실패, 인증서 오류, 라우팅 미적중 후보를 먼저 제외한 뒤 같은 작업의 반복 테스트 결과를 비교하세요. 프로토콜마다 서버가 다르다면 결과를 ‘노드 비교’로 기록하고 프로토콜 성능에 관한 결론으로 표현하지 마세요.
프로토콜 선택 관련 자주 묻는 질문
VMess 노드 유형을 VLESS로 바꾸기만 하면 연결할 수 있나요?
아니요. 서버에도 VLESS 인바운드가 구성되어 있어야 하며 UUID, 보안 계층, 전송 매개변수가 일치해야 합니다. 클라이언트의 프로토콜 드롭다운만 바꾸지 말고 서버에서 제공한 VLESS 설정을 가져오세요.
Trojan의 Tcping은 정상인데 실제 연결은 왜 실패하나요?
먼저 클라이언트 로그에서 연결 시간 초과, TLS 검증 실패, 인증 실패를 구분하세요. 포트, 비밀번호, 서버 이름, 기기 시간, 인증서 유효 기간을 차례로 확인합니다. TCP 포트에 연결된다고 해서 TLS와 프록시 인증까지 통과한 것은 아닙니다.
Shadowsocks로 웹페이지는 열리는데 게임은 왜 연결되지 않나요?
먼저 게임이 UDP를 사용하는지 확인한 다음 앱 트래픽이 프록시를 통과하는지, 서버에서 UDP를 허용하는지, 현재 암호화 방식과 커널이 해당 전달 방식을 지원하는지 살펴보세요. 웹페이지의 TCP 요청이 성공해도 UDP 경로가 정상이라는 뜻은 아닙니다.
VLESS로 바꾼 뒤 휴대전화 배터리가 더 빨리 닳습니다. 바로 되돌려야 하나요?
전환 전후의 TUN, 라우팅, 백그라운드 제한, 로그 수준을 비교하고 지속적인 재연결이 있는지 확인하세요. 같은 트래픽 부하로 반복 테스트해야 합니다. 회선과 전송 방식도 함께 바꿨다면 배터리 소모 변화의 원인을 VLESS로 단정할 수 없습니다.