먼저 서버에서 제공하는 전체 구성과 클라이언트 커널의 지원 여부를 확인하세요. VMess는 프로토콜 계층에서 암호화하고, 일반적인 VLESS 구성은 TLS 또는 REALITY로 기밀성을 확보합니다. Trojan은 TLS에 의존하며, 최신 Shadowsocks는 사전 공유 키로 데이터를 암호화합니다. 구독 노드를 비교하거나 직접 서버를 구축하려는 분, 여러 기기에서 같은 설정을 사용하려는 분을 위한 글입니다. 프로토콜·전송 방식·보안 계층을 구분해 연결에 실패하는 일을 줄일 수 있습니다.
1. 프로토콜·전송 방식·클라이언트 구분하기
VMess·VLESS·Trojan·Shadowsocks는 프록시 프로토콜이지 클라이언트 종류가 아닙니다. v2rayN은 노드 저장, 구독 관리, 프록시 설정 및 커널 실행을 담당하는 데스크톱 클라이언트입니다. 안드로이드에서는 v2rayNG가 Xray 커널을, v2flyNG가 v2fly 커널을 사용합니다. 클라이언트에서 특정 유형의 노드를 추가할 수 있더라도 현재 커널이 해당 노드의 모든 전송·보안 옵션을 지원한다는 뜻은 아닙니다.
‘어떤 프로토콜이 가장 좋은가’를 외우기보다 노드를 여러 계층으로 나누어 살펴보는 편이 유용합니다. 구독에 표시된 프로토콜 이름은 첫 번째 항목일 뿐이며, 주소·포트·전송 방식·보안 계층·인증 정보가 서로 맞아야 합니다. 특히 VLESS 노드는 이름이 같다고 해서 다른 커널에서도 설정을 그대로 사용할 수 있는 것은 아닙니다.
- 프록시 프로토콜: VMess나 Trojan처럼 사용자를 인증하고 대상 주소를 지정하며 프록시 요청을 캡슐화하는 방식을 정합니다.
- 전송 방식: TCP·WebSocket·gRPC처럼 프록시 데이터를 전달하는 방식을 정합니다. 모든 프로토콜과 커널이 모든 조합을 지원하는 것은 아닙니다.
- 보안 계층: TLS 또는 Xray의 REALITY 등이 해당합니다. 프록시 프로토콜 이름과는 별개입니다.
- 클라이언트와 커널: 클라이언트는 사용자 인터페이스를 제공하고, 실제 연결 처리는 커널이 담당합니다. 호환성 문제를 확인할 때는 두 버전을 모두 기록하세요.
2. 네 가지 프로토콜의 인증 및 암호화 차이
먼저 ‘암호화를 담당하는 요소’를 확인한 다음 설정 복잡도를 비교하세요. 아래 표는 현재 흔히 쓰이는 구성인 VMess AEAD, encryption=none을 사용하는 VLESS, 표준 Trojan, 최신 Shadowsocks AEAD 계열을 기준으로 합니다. 과거 설정이나 새로 추가된 확장 기능에는 프로토콜 이름만 보고 같은 결론을 적용할 수 없습니다.
| 프로토콜 | 인증 방식 | 기밀성 제공 방식 | 주요 설정 항목 |
|---|---|---|---|
| VMess | UUID 및 프로토콜 인증 방식 | 프로토콜 계층에서 AEAD 암호화를 사용하거나 TLS를 추가할 수 있음 | UUID, 암호화 옵션, 시스템 시간, 전송 매개변수 |
| VLESS | 일반적으로 UUID 사용 | 일반적인 none 설정은 TLS 또는 REALITY 같은 보안 계층에 의존 | 보안 계층, 서버 이름, flow, 커널 지원 여부 |
| Trojan | 공유 비밀번호를 프로토콜 방식으로 처리해 인증 | TLS 연결 | 비밀번호, 인증서 검증, 서버 이름 |
| Shadowsocks | 공유 비밀번호 또는 지정된 형식의 사전 공유 키 | 선택한 암호화 방식이 제공하는 인증 암호화 | 암호화 방식, 키 형식, 양쪽 구현 간 호환성 |
VMess: AEAD와 시간 동기화 확인
VMess가 반드시 ‘구식 설정’을 써야 하는 것은 아닙니다. 최신 구성에서는 흔히 AEAD를 사용하며, 기존 VMess 설정의 alterId는 보통 0으로 지정합니다. 연결 문제를 해결하려고 이 값을 임의로 높이지 마세요. VMess 인증에는 시간 요소가 포함되므로 기기의 시간이 크게 어긋나면 UUID가 올바르더라도 인증에 실패할 수 있습니다. 먼저 운영체제의 자동 시간 동기화를 켠 다음 다른 설정을 확인하세요.
VLESS: none이라고 해서 연결 전체가 평문인 것은 아닙니다
일반적인 VLESS 설정에서 encryption=none은 해당 계층에서 페이로드를 암호화하지 않는다는 뜻입니다. 바깥 계층의 TLS나 REALITY까지 암호화되지 않는다는 의미는 아닙니다. 반대로 프로토콜 계층 암호화도 없고 신뢰할 수 있는 보안 계층도 없다면, 이름이 VLESS라는 이유만으로 연결이 보호된다고 볼 수 없습니다. 다른 암호화 확장을 사용하는 경우에는 양쪽 구현과 버전을 별도로 확인해야 하며, none 모드의 기준을 그대로 적용하면 안 됩니다.
Trojan과 Shadowsocks: 비밀번호 설정은 비슷해 보여도 방식은 다릅니다
Trojan은 TLS로 기밀성을 확보하므로 정상적인 구성에서는 서버 인증서를 올바르게 검증해야 합니다. Shadowsocks는 선택한 암호화 방식으로 프록시 데이터를 직접 보호하며, 기본 구성에는 도메인 인증서가 필요하지 않습니다. 기존 AEAD 방식과 Shadowsocks 2022의 키 요구사항은 서로 다릅니다. 예를 들어 2022-blake3-aes-128-gcm에는 지정된 길이의 키가 필요하므로 임의의 비밀번호를 그대로 사용하면 안 됩니다.
3. TLS·REALITY·WebSocket 조합 방식
‘VLESS + REALITY’와 ‘VMess + WebSocket + TLS’는 서로 다른 계층을 조합한 구성입니다. REALITY는 Xray가 제공하는 보안 기능이지 독립적인 프록시 프로토콜이 아닙니다. WebSocket은 전송 방식이며 TLS를 대신할 수 없습니다. 일반적인 CDN 리버스 프록시를 사용하려면 지원되는 HTTP 계열 전송 방식이 필요합니다. 임의의 TCP 노드 주소를 CDN 도메인으로 바꾸기만 해서는 연결되지 않습니다.
포트 번호는 서비스가 연결을 기다리는 위치일 뿐입니다. 서버가 443 포트에서 실행 중이어도 클라이언트와 맞지 않는 서비스를 제공할 수 있고, 다른 포트에서도 TLS를 구성할 수 있습니다. 연결을 확인할 때는 포트 숫자만 보지 말고 실제 설정과 핸드셰이크 로그를 확인하세요. 일반 TLS에서는 IP 주소로 연결할 수 있지만, 인증서 검증에 사용할 서버 이름은 인증서와 일치해야 합니다.
- 일반 TLS: 서버 이름, 인증서 유효기간, 인증서 체인, 기기 시간을 확인하세요. ‘인증서 검증 안 함’을 일반적인 해결책으로 사용하지 마세요.
- WebSocket: 경로와 Host를 확인하고, 리버스 프록시가 요청을 올바른 연결 지점으로 전달하는지 점검하세요. 경로의 대소문자나 끝의 슬래시가 다르면 일치하지 않을 수 있습니다.
- gRPC: 서비스 이름과 서버의 HTTP/2 지원 여부를 확인하세요. WebSocket의 경로 설정을 그대로 사용하면 안 됩니다.
- REALITY: 서버에서 제공한 공개 키, shortId, 서버 이름 및 관련 매개변수를 확인하세요. UUID가 맞더라도 이 항목들이 자동으로 올바른 것은 아닙니다.
VLESS의 flow도 임의로 지정하는 가속 옵션이 아닙니다. 서버가 해당 흐름을 사용하고 클라이언트 커널과 전송 조합도 지원할 때만 xtls-rprx-vision 등을 설정하세요. 필요한 항목을 직접 조합하는 것보다 구독 전체를 가져오는 편이 일반적으로 안정적이지만, 구독 출처가 신뢰할 수 있는지는 확인해야 합니다.
4. 성능 비교를 제대로 하는 방법
네트워크 환경과 무관하게 적용되는 고정 속도 순위는 없습니다. 같은 서버의 프로토콜도 연결 지점, 리버스 프록시, 속도 제한 정책에 따라 결과가 달라질 수 있습니다. 지역이 다른 두 노드의 다운로드 결과 한 번만으로 어느 프로토콜이 더 빠른지 입증할 수도 없습니다. 암호화 연산, 핸드셰이크, 전송 캡슐화, 네트워크 패킷 손실이 병목이 될 수 있으므로 실제 기기와 회선에서 확인해야 합니다.
- 암호화 연산: AES 하드웨어 가속 여부는 AES-GCM 성능에 영향을 줍니다. 일부 기기에서는 ChaCha20-Poly1305가 더 적합할 수 있습니다. 알고리즘 이름만으로 전력 소모나 속도를 판단하지 마세요.
- 핸드셰이크 비용: 짧은 연결을 자주 만들면 네트워크 왕복과 TLS 핸드셰이크가 첫 요청에 영향을 줍니다. 장시간 전송에서는 대역폭·혼잡·패킷 손실의 영향이 더 커집니다.
- 추가 캡슐화: WebSocket·gRPC·리버스 프록시는 처리 단계를 늘리지만 기존 서버 구성에 필요한 경우도 있습니다. 단계가 적다고 회선 속도가 반드시 빨라지는 것은 아닙니다.
- UDP 지원: 프로토콜·커널·서버·로컬 트래픽 처리 방식이 모두 UDP를 지원해야 합니다. 게임이나 음성 통화가 안 될 때 웹페이지가 열린다는 이유만으로 UDP 연결도 정상이라고 판단하지 마세요.
반복해서 사용할 수 있는 비교 절차
- 가능하면 같은 지역·같은 서버·같은 대역폭 제한이 적용되는 연결 지점을 사용하세요. 클라이언트 버전, 커널 버전, 프로토콜 구성, 테스트 시간을 기록합니다.
- 백그라운드 다운로드를 중지하고 동일한 리소스를 대상으로 테스트하세요. 먼저 한 번 예열한 뒤 세 차례씩 측정하고, 최고값 대신 중앙값을 기록합니다.
- 웹페이지 첫 로딩, 지속 다운로드, 실시간 통신을 나누어 확인하세요. 클라이언트의 지연 시간 측정은 특정 탐색 결과만 보여 주므로 실제 서비스 전체를 대신할 수 없습니다.
- 모바일 기기에서는 백그라운드 연결 유지와 배터리 소모도 확인하세요. 네트워크를 바꾼 뒤 다시 테스트해 무선 신호 변화가 프로토콜 문제로 오인되지 않도록 합니다.
5. 가정용·모바일·다중 기기 환경별 선택
아래의 ‘추천’은 서버 구성이 갖춰져 있고 양쪽에서 지원하는 일반적인 Xray 배포 환경에 한정되며, 모든 네트워크에 적용되는 속도 순위가 아닙니다. 안정적으로 작동하는 노드가 이미 있다면 전체 설정을 유지하세요. 새 연결 지점을 만들 때 인증서 관리, 커널 호환성, 기기 수를 고려하면 됩니다.
VLESS + 호환되는 보안 계층
추천새 Xray 환경을 구축한다면 우선 검토할 만합니다. 실제 조건에 따라 TLS 또는 REALITY를 선택하고 보안 매개변수를 정확히 맞추세요. 다른 커널과 호환해야 한다면 VLESS라는 이름만 확인하지 말고 구체적인 조합을 검증해야 합니다.
적합한 환경: 서버를 직접 관리하며 데스크톱과 안드로이드에서 호환 커널을 사용하는 경우
VMess AEAD
기존 VMess 구독이 정상 작동한다면 이름만 바꾸려고 이전할 필요는 없습니다. 올바른 전송 설정을 유지하고 시간 동기화 문제를 해결하며, 현재 구성에 맞지 않는 이전 인증 설정이 남아 있지 않은지 확인하세요.
적합한 환경: 안정적인 노드를 이미 사용 중이며 기존 설정을 유지하려는 경우
Trojan + TLS
비밀번호 인증과 TLS를 사용하며, 인증서와 서버 이름 설정이 중요합니다. 도메인·인증서·연결 지점 전달을 꾸준히 관리할 수 있는 환경에 적합합니다. 인증서 검증을 건너뛰어 유지 관리 부담을 줄여서는 안 됩니다.
적합한 환경: 도메인과 인증서를 관리하는 절차가 마련된 환경
Shadowsocks AEAD 계열
기본 설정 항목이 적고 일반적으로 인증서가 필요하지 않습니다. 여러 기기에서 사용할 때는 암호화 방식과 키 형식이 동일한지 확인하세요. 2022 계열을 선택하기 전에는 모든 기기와 서버의 지원 여부를 확인해야 합니다.
적합한 환경: 설정 항목이 적은 직접 연결 구성, 호환성을 확인한 다중 기기 환경
가정용 네트워크에서는 저녁 시간대의 안정성과 여러 기기의 동시 사용을 우선 확인하세요. 모바일 네트워크에서는 네트워크 전환, UDP 연결 가능 여부, 백그라운드 관리도 고려해야 합니다. 안드로이드의 배터리 절약 설정이 프록시 프로세스를 중단할 수 있으므로 프로토콜 변경만으로 해결되지 않을 수 있습니다. 먼저 시스템이 프로세스를 종료한 것인지, 커널은 실행 중이지만 연결이 시간 초과되는 것인지 구분하세요.
다중 기기 구성: 같은 구독을 쓰더라도 기기별 지원 여부 확인
데스크톱: v2rayN
- 클라이언트 버전만이 아니라 실제로 활성화된 커널과 버전도 기록하세요.
- 먼저 브라우저에서 시스템 프록시를 확인한 다음 필요에 따라 터미널이나 TUN을 설정하세요.
- 이미 검증한 노드를 하나 남겨 두면 업데이트 전후를 비교하기 쉽습니다.
안드로이드: v2rayNG 또는 v2flyNG
- v2rayNG에서는 Xray의 지원 여부를, v2flyNG에서는 v2fly의 지원 여부를 기준으로 노드를 확인하세요.
- 처음 실행할 때 VPN 권한을 허용하고 앱별 적용 범위에 대상 앱이 포함되어 있는지 확인하세요.
- 모바일 데이터와 가정용 Wi-Fi를 각각 테스트하고 한 번의 결과를 두 환경에 공통으로 적용하지 마세요.
같은 구독이라도 모든 기기에서 사용할 수 있는 노드가 완전히 같다고 보장할 수 없습니다. REALITY·flow·특정 암호화 방식은 양쪽의 실제 지원 여부를 기준으로 판단하세요.
6. 가져온 뒤 연결되지 않을 때 항목별로 점검하기
프로토콜을 선택한 뒤 발생하는 흔한 문제는 ‘프로토콜이 나빠서’가 아니라 설정 일부만 맞는 경우입니다. 원본 노드를 복사해 두고 한 번에 한 항목만 변경하며 로그에 기록된 시간을 적어 두세요. 공개적으로 도움을 요청할 때는 구독 주소·UUID·비밀번호·개인 키를 가리세요. 로그에 표시된 실제 노드 주소도 필요에 따라 익명화해야 합니다.
VLESS UUID가 맞는데도 연결되지 않는 이유는 무엇인가요?
주소와 포트, 보안 계층, 서버 이름, 전송 방식, flow 순서로 확인하세요. REALITY를 사용한다면 공개 키와 shortId가 같은 서버 연결 지점에서 제공된 값인지도 점검합니다. TLS 노드와 REALITY 노드의 설정을 섞지 마세요.
Trojan이 인증서 검증을 꺼야만 연결됩니다. 어떻게 해야 하나요?
인증서 검증을 다시 켜고 기기 시간과 서버 이름을 확인하세요. 서버 측에서는 인증서 유효기간과 전체 인증서 체인을 점검합니다. IP 주소로 연결하더라도 올바른 검증 이름을 유지해야 합니다. 핸드셰이크가 성공했다는 것만으로 서버 신원이 확인된 것은 아닙니다.
Shadowsocks 암호화 방식을 바꾸면 비밀번호가 같아도 연결되지 않나요?
클라이언트와 서버에서 같은 암호화 방식을 사용해야 합니다. 2022 계열로 바꾸는 경우에는 해당 방식의 길이와 인코딩 조건에 맞는 키를 새로 생성해야 합니다. 클라이언트의 드롭다운 항목만 바꾸거나 이전 비밀번호를 새 키로 간주해서는 안 됩니다.
노드 지연 시간 테스트는 성공했는데 브라우저에서 웹페이지가 열리지 않나요?
먼저 커널이 실행 중인지, 브라우저가 현재 로컬 프록시 포트를 사용하는지 확인한 뒤 DNS와 라우팅을 점검하세요. 인바운드가 127.0.0.1:10808에서 연결을 기다린다면 앱은 해당 인바운드가 지원하는 프록시 유형으로 접속해야 합니다. 포트는 예시이므로 실제 설정을 확인하세요.
구독의 VMess 노드가 갑자기 모두 작동하지 않습니다. 프로토콜을 바꿔야 하나요?
먼저 시스템 시간을 자동으로 동기화하고 구독을 업데이트한 뒤 노드가 만료되었거나 연결 지점이 변경되었는지 확인하세요. 로그에 인증 실패가 표시되면 UUID와 인증 관련 설정을 확인합니다. 연결 시간 초과라면 여러 프로토콜 항목을 동시에 바꾸지 말고 주소·포트·네트워크 연결 가능 여부부터 점검하세요.
마지막으로 개별 항목이 아닌 전체 구성을 기준으로 판단하세요. 프로토콜은 인증과 캡슐화 방식을 정하고, 보안 계층은 기밀성과 신원 확인 방식을 제공하며, 전송 방식과 회선은 연결 가능성과 사용 경험에 영향을 줍니다. 클라이언트를 비교하려면 클라이언트 비교를, DNS·라우팅·시스템 프록시의 관계를 알아보려면 사용 안내를 확인하세요. 프로토콜·커널·라우팅을 한꺼번에 바꾸기보다 설정 하나를 안정적으로 작동시킨 뒤 항목별로 조정하면 문제를 더 쉽게 찾을 수 있습니다.