VMess·VLESS·Trojan·Shadowsocks는 속도 등급이 아니라 인증, 암호화, 트래픽 전달 방식이 서로 다른 프로토콜입니다. 기존 구독을 이용한다면 먼저 서버 설정과 클라이언트 코어의 호환성을 확인하세요. 새 연결을 구성할 때는 필요한 전송 방식과 기기 성능을 고려하면 됩니다. 이 글에서는 프로토콜, TLS, 전송 방식을 구분해 설명하고 데스크톱과 Android에서 설정을 확인하는 방법을 안내합니다.
프로토콜·전송 방식·코어 구분하기
노드 이름의 “VLESS + WebSocket + TLS”는 세 가지 요소를 뜻합니다. VLESS는 프록시 프로토콜의 인증과 요청 형식을 담당하고, WebSocket은 데이터를 전달하며, TLS는 이 조합에 암호화된 통신 채널과 서버 인증을 제공합니다. “VLESS”만 기억하고 나머지 두 요소를 놓치면 연결 설정을 제대로 구성하기 어렵습니다.
v2rayN은 데스크톱 클라이언트입니다. 설정 가져오기, 노드 선택, 시스템 프록시 설정은 인터페이스에서 처리하고 실제 연결은 코어가 담당합니다. Android에서는 v2rayNG가 Xray 코어를, v2flyNG가 v2fly 코어를 사용합니다. 특정 공유 링크를 클라이언트가 읽을 수 있다고 해서 현재 코어가 링크의 모든 확장 매개변수를 지원하는 것은 아닙니다.
- 프로토콜: VMess, VLESS, Trojan, Shadowsocks 중 무엇을 사용하는지 확인합니다. 인증 항목과 프로토콜 처리 방식이 달라집니다.
- 전송 방식: TCP, WebSocket, gRPC 등의 항목을 확인합니다. 클라이언트와 서버의 설정이 서로 맞아야 합니다.
- 보안 계층: TLS 또는 REALITY 설정을 확인합니다. REALITY는 다섯 번째 프록시 프로토콜이 아닙니다.
- 라우팅: 요청을 직접 연결할지, 프록시를 거칠지, 차단할지 결정합니다. 노드의 프로토콜과는 별개의 설정입니다.
프로토콜 4종의 암호화와 인증 방식 비교
비교할 때는 먼저 “암호화가 어느 계층에서 제공되는지”, 다음으로 “서버가 사용자를 어떻게 식별하는지” 확인하세요. UUID나 비밀번호는 인증 정보일 뿐, 보안 설정 전체를 의미하지 않습니다. 포트가 443이라고 해서 TLS를 사용하지 않는 연결에 TLS 보호가 자동으로 적용되는 것도 아닙니다.
| 프로토콜 | 인증 및 암호화 | 일반적인 조합 | 주요 확인 항목 |
|---|---|---|---|
| VMess | UUID로 사용자를 식별합니다. 프로토콜 자체의 데이터 암호화를 지원하며, 최신 구성에서는 AEAD 인증 방식을 사용합니다. | TCP 또는 WebSocket + TLS 등의 조합 | UUID, 암호화 옵션, 전송 방식, 기기의 시스템 시간 |
| VLESS | UUID로 인증합니다. 일반적인 구성에서는 프로토콜 자체의 데이터 암호화를 사용하지 않고 TLS나 REALITY 등의 방식으로 연결을 보호합니다. | WebSocket + TLS 또는 해당 기능을 지원하는 Xray 구성의 TCP + REALITY | 보안 계층, 서버 이름, 전송 항목, flow, REALITY 관련 매개변수 |
| Trojan | 비밀번호로 인증합니다. 일반적인 표준 구성에서는 TLS로 암호화와 서버 인증을 처리합니다. | 주로 TCP + TLS를 사용합니다. 다른 전송 조합은 구현 방식에 따라 달라집니다. | 비밀번호, 인증서 유효성, 서버 이름, 전송 방식 지원 여부 |
| Shadowsocks | 합의된 암호화 방식과 키 자료를 사용합니다. 기존 AEAD와 Shadowsocks 2022는 형식과 요구 사항이 서로 다릅니다. | TCP 및 UDP 트래픽을 직접 전달합니다. 추가 캡슐화는 양쪽 모두 지원해야 합니다. | method, 비밀번호 또는 키 형식, UDP 지원 여부 |
VMess의 AEAD 인증과 Shadowsocks에서 말하는 AEAD 암호화 방식은 같은 설정 항목이 아닙니다. 오래된 가이드의 VMess alterId 값을 그대로 적용해서도 안 됩니다. 최신 VMess AEAD 구성에서는 보통 0을 사용하며, 기존 노드는 서버의 실제 설정을 기준으로 확인하세요.
Shadowsocks도 “비밀번호가 맞다”는 이유만으로 설정이 완전하다고 볼 수 없습니다. 예를 들어 aes-128-gcm과 2022-blake3-aes-128-gcm은 서로 다른 암호화 방식이며, 후자는 별도의 키 형식 요건도 있습니다. 암호화 방식을 다른 값으로 바꿔도 서버 설정이 자동으로 변경되지는 않습니다.
이름 순위가 아니라 사용 조건에 따라 선택하기
아래 추천은 서버 구성을 직접 선택할 수 있는 경우를 기준으로 합니다. 서비스에서 한 가지 프로토콜만 제공한다면 클라이언트에서 다른 프로토콜로 억지로 바꾸기보다 현재 기기에서 완전히 작동하는지 먼저 확인하세요. 회선, 설정, 기기 조건을 무시한 채 프로토콜별 속도를 일률적으로 순위 매길 수는 없습니다.
VLESS: 새 설정에서 우선 확인
추천서버에서 TLS 또는 REALITY 매개변수를 모두 제공하고 클라이언트 코어가 해당 조합을 지원한다면 새 설정의 우선 후보로 고려할 수 있습니다. 추천 이유는 배포 환경과의 호환성이지, 모든 네트워크에서 더 빠르기 때문은 아닙니다.
적합한 경우: 코어의 지원 여부를 확인할 수 있고, 해당 전송 방식과 보안 계층을 사용하려는 새 연결
VMess: 검증된 기존 설정 유지
기존 VMess 구독이 안정적으로 작동한다면 프로토콜 이름이 오래됐다는 이유만으로 바꿀 필요는 없습니다. 최신 인증 설정을 적용하고 시스템 시간을 정확하게 유지하며 서버의 전송 방식을 확인하세요.
적합한 경우: 작동 중인 구독을 사용하거나 기존 서버가 VMess 기반으로 구성된 사용자
Trojan: 기존 TLS 구성 활용
서버에 유효한 인증서와 명확한 서버 이름이 설정되어 있고 Trojan을 지원한다면 기존 TLS 환경에 맞춰 구성할 수 있습니다. TLS를 사용한다고 해서 인증서 검증을 생략해도 되는 것은 아닙니다.
적합한 경우: 서버에서 Trojan 설정을 모두 제공하고 기존 TLS 구성을 유지하려는 사용자
Shadowsocks: 암호화 방식 일치 여부 확인
설정 항목이 비교적 간단해 서버에서 method와 키를 명확하게 제공하는 연결에 적합합니다. 기존 AEAD와 2022 방식 중 무엇을 선택할지는 양쪽의 지원 여부를 확인해야 합니다. 클라이언트에 Shadowsocks 옵션이 보이는지만으로 결정해서는 안 됩니다.
적합한 경우: 기존 Shadowsocks 서버를 사용하거나 기기별 암호화 방식의 부하를 비교하려는 사용자
웹 브라우징·모바일 네트워크·구형 기기별 확인 방법
일반적인 웹 페이지 접속은 회선 왕복 시간, DNS 조회, 서버 부하의 영향을 크게 받습니다. 프로토콜을 바꾸면서 접속 지역과 서비스 제공 업체까지 함께 변경하면 차이가 어디서 비롯됐는지 알기 어렵습니다. 비교할 때는 서버, 테스트 대상, 네트워크 환경을 가능한 한 동일하게 유지하세요.
- 웹 브라우징: 먼저 HTTPS 페이지가 계속 로드되는지, 이미지 요청이 완료되는지 확인한 다음 대용량 파일을 내려받아 보세요. 지연 시간 테스트에 한 번 성공했다고 브라우저의 모든 요청이 정상이라는 뜻은 아닙니다.
- 모바일 네트워크: Wi-Fi에서 셀룰러 네트워크로 전환하면 기존 연결을 다시 설정해야 할 수 있습니다. 먼저 터널이 복구됐는지 확인하고 DNS와 UDP를 점검하세요. 연결이 끊길 때마다 모바일 기기와 프로토콜의 호환성 문제라고 단정하지 마세요.
- 구형 기기: 실제 부하는 CPU의 암호화 가속, 코어 구현, 추가 캡슐화에 따라 달라집니다. Shadowsocks가 항상 전력을 가장 적게 쓴다거나 VLESS라는 이름의 “경량”이 반드시 사용량을 줄여 준다고 단정할 수 없습니다.
- 실시간 음성 통화 및 게임: 클라이언트 진입점, 프록시 프로토콜 구현, 서버, 라우팅이 모두 UDP 전달을 지원해야 합니다. 웹은 정상인데 음성 통화가 실패한다면 UDP 경로를 따로 점검하세요.
클라이언트에서 설정을 확인하는 4단계
데스크톱에서는 먼저 v2rayN으로 설정 하나가 완전히 작동하는지 확인한 다음 라우팅과 앱 트래픽 전달을 살펴보세요. 아래 메뉴 경로는 일반적인 중국어 데스크톱 인터페이스를 기준으로 합니다. 버전에 따라 메뉴 문구가 조금 다를 수 있으므로 이름이 같은 옵션을 찾느라 관련 없는 설정을 바꾸지 말고 기능을 기준으로 확인하세요.
-
전체 링크 가져오기
서비스 제공자가 준 공유 링크 전체를 복사한 다음 v2rayN 메인 창에서 Ctrl + V를 눌러 가져옵니다. 구독 주소를 단일 노드 링크로 착각하지 말고 노드 링크를 여러 부분으로 나누어 붙여 넣지도 마세요.
-
노드 설정 항목 확인
노드를 두 번 클릭해 편집 창을 열고 주소, 포트, 사용자 ID 또는 비밀번호, 전송 프로토콜, TLS 설정을 차례로 확인합니다. WebSocket을 사용한다면 경로와 Host를 확인하고, REALITY를 사용한다면 서버 설정에 맞춰 공개 키, shortId, 서버 이름, flow를 확인하세요.
-
실행 후 로그 확인
대상 노드를 활성 서버로 설정하고 메인 화면의 로그 영역에서 코어가 시작되는지 먼저 확인합니다. “지원하지 않는 전송 방식”이나 설정 분석 오류가 표시되면 로컬 수신 포트를 계속 바꾸지 말고 코어 호환성을 먼저 확인하세요.
-
앱 트래픽 프록시로 전달
트레이 아이콘의 오른쪽 클릭 메뉴에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택한 뒤 브라우저로 확인합니다. 로컬 수신 포트를 확인하려면 「설정」→「매개변수 설정」에서 실제 포트를 살펴보세요. 프록시를 수동으로 설정하는 앱에는 해당 포트와 일치하는 주소를 입력해야 합니다.
Android에서는 먼저 어떤 코어를 사용하는지 확인해야 합니다. v2rayNG의 Xray 기능과 v2flyNG의 v2fly 기능은 동일하지 않습니다. 특히 VLESS 확장 기능, 보안 계층, flow를 사용한다면 앱에 포함된 코어가 해당 기능을 지원하는지 확인하세요. 가져오기에 성공했더라도 연결을 직접 시작해 봐야 합니다. 노드가 목록에 표시되는 것은 링크 분석이 끝났다는 뜻일 뿐입니다.
포트·도메인·보안 옵션을 혼동하지 않기
원격 포트는 서버가 연결을 받는 포트이고, 로컬 포트는 앱이 클라이언트에 연결하는 포트입니다. 다음 숫자 세 개는 설정을 설명하기 위한 예시일 뿐, 네 가지 프로토콜의 필수 포트나 v2rayN의 공통 기본값이 아닙니다.
예를 들어 브라우저에서 127.0.0.1:1080 SOCKS 프록시를 수동으로 사용하려면 클라이언트가 실제로 해당 주소에서 SOCKS 서비스를 제공해야 합니다. 원격 노드에 example.com:443을 입력했더라도 브라우저 프록시 포트를 443으로 바꿔서는 안 됩니다. 여기서 example.com은 설정 항목 간의 관계를 설명하기 위한 예시입니다.
- 서버 주소와 서버 이름: 서버 주소는 연결을 설정할 때 사용하고, 서버 이름은 일반적으로 TLS의 SNI와 인증서 검증에 사용합니다. 두 값은 다를 수 있지만 서버 구성에 맞아야 합니다.
- WebSocket Host와 경로: 전송 설정 항목입니다. UUID와는 관계가 없으며 다른 노드의 값을 그대로 복사해서도 안 됩니다.
- 안전하지 않은 연결 허용: 인증서 검증을 건너뛰는 방법을 일반적인 해결책으로 사용하지 마세요. 먼저 시스템 시간, 인증서 도메인과 유효 기간, 서버 인증서 체인을 확인하세요.
- REALITY 매개변수: 서버에서 제공한 매개변수 세트를 사용해야 합니다. 일반 TLS 노드의 항목을 REALITY 노드에 그대로 복사하지 마세요.
프로토콜 선택 관련 자주 묻는 질문
구독에 VMess만 있는데 VLESS로 바꿔야 하나요?
프로토콜 이름만 바꾸려고 전환할 필요는 없습니다. 먼저 기존 노드를 실행해 접속이 되는지 확인하세요. 서비스에서 VLESS 링크도 제공한다면 별도의 노드로 가져와 비교하면 됩니다. 편집 창에서 프로토콜 유형만 바꿔도 서버 설정이 함께 변경되지는 않습니다.
VLESS를 가져왔는데 실행하자마자 오류가 나는 이유는 무엇인가요?
로그에 처음 표시된 설정 오류부터 확인한 다음 전송 방식, 보안 계층, flow를 점검하세요. Android 사용자는 v2rayNG와 v2flyNG 중 어떤 앱을 쓰는지 확인하고 해당 코어의 지원 여부를 살펴봐야 합니다. 링크가 vless://로 시작한다는 이유만으로 모든 항목이 작동한다고 단정하지 마세요.
Trojan에서 인증서 오류가 나면 검증을 꺼도 되나요?
먼저 기기의 시간을 맞춘 다음 노드에 설정된 서버 이름이 인증서의 도메인과 일치하는지 확인하세요. 인증서가 만료됐거나 인증서 체인이 완전하지 않다면 서버 측에서 수정해야 합니다. 검증을 끄면 서버 신원 확인이 약해지므로 장기적인 해결책으로 적합하지 않습니다.
웹 페이지는 열리는데 음성 통화가 계속 연결되지 않나요?
먼저 앱 트래픽이 프록시로 전달되는지 확인한 뒤 해당 설정의 UDP 지원 여부와 서버 방화벽을 점검하세요. 시스템 HTTP 프록시로는 임의의 앱에서 발생한 UDP 트래픽을 처리하지 못하는 경우가 많습니다. 필요한 경우 클라이언트가 실제로 제공하는 TUN 또는 시스템 터널 기능을 사용하고 라우팅 규칙을 다시 확인하세요.
프로토콜을 바꿔도 시간 초과가 발생하면 다음으로 무엇을 확인해야 하나요?
로컬 수신 상태, 앱 프록시 설정, 코어 로그, 원격 주소, 서버 연결 가능성 순으로 확인하세요. 먼저 요청이 실제로 클라이언트에 들어오는지 확인한 다음 핸드셰이크 실패 여부를 살펴보세요. 연결이 클라이언트에 도달하지 않는다면 UUID나 암호화 방식을 바꿔도 대개 도움이 되지 않습니다.
최종 선택은 세 가지로 정리할 수 있습니다. 서버가 어떤 완전한 설정을 제공하는지, 기기의 코어가 이를 실행할 수 있는지, 실제 네트워크에서 안정적인지 확인하세요. 이미 작동하는 노드는 유지하고 새 설정은 별도로 가져와 비교하세요. 프로토콜 호환성을 확인한 뒤 시스템 프록시, DNS, 분할 라우팅을 설정하면 문제를 더 명확하게 진단할 수 있습니다.