프로토콜을 선택하기 전에 서버 설정을 확인하고, 클라이언트 코어와 네트워크 조건을 살펴보세요. 이 글에서는 프로토콜, 전송 방식, 보안 계층을 구분하고 네 가지 프로토콜의 인증 방식, 암호화 범위, 연결 비용을 비교합니다. 데스크톱과 Android에서 확인할 항목도 정리했습니다. 기존 구독을 사용하는 경우 호환성을 판단하고, 직접 서버를 운영한다면 프로토콜 이름만 보고 속도를 추측하는 대신 테스트 순서를 정하는 데 활용할 수 있습니다.
1. 프로토콜·전송 방식·보안 계층 구분하기
VMess, VLESS, Trojan, Shadowsocks는 프록시 프로토콜입니다. TCP, WebSocket, gRPC는 전송 설정에서 자주 볼 수 있는 옵션이고, TLS와 REALITY는 연결을 보호하는 방식입니다. 구독 정보의 ‘VLESS + TCP + REALITY’는 하나의 설정 조합을 뜻하며, 서로 바꿔 쓸 수 있는 세 가지 프로토콜이 아닙니다.
클라이언트 설정은 서버 설정과 항목별로 일치해야 합니다. 서버가 VMess를 제공한다면 클라이언트 유형만 VLESS로 바꿔서는 안 됩니다. 서버에서 WebSocket을 사용한다면 클라이언트 설정을 임의로 일반 TCP로 바꿀 수도 없습니다. 프로토콜, 포트, 인증 정보, 전송 매개변수, 보안 계층 중 하나라도 다르면 연결에 실패할 수 있습니다.
- 프로토콜 계층: 사용자 인증 방식, 대상 주소 표현 방식, 프록시 데이터를 자체적으로 암호화하는지 여부를 결정합니다.
- 전송 계층: 프록시 데이터를 전달하는 방식을 정합니다. WebSocket은 HTTP 업그레이드 과정을 거치고, gRPC는 일반적으로 HTTP/2를 사용합니다. 두 방식 모두 서버 측 지원이 필요합니다.
- 보안 계층: TLS는 인증서를 검증하고 연결을 보호합니다. REALITY를 사용하려면 호환되는 구현과 공개 키, 서버 이름 등의 설정이 필요하며, 일반 인증서 설정을 그대로 대체할 수는 없습니다.
- 라우팅 계층: 어떤 요청을 프록시로 보내고, 직접 연결하거나 차단할지 결정합니다. 프로토콜을 바꿔도 DNS, 분할 라우팅 규칙, 앱 트래픽이 프록시를 거치지 않는 문제는 자동으로 해결되지 않습니다.
2. 네 가지 프로토콜의 암호화와 인증 방식
| 프로토콜 | 주요 인증 정보 | 데이터 보호 방식 | 주요 확인 항목 |
|---|---|---|---|
| VMess | UUID 및 올바른 시스템 시간 | 일반적인 설정에서는 프로토콜 자체의 인증·암호화를 사용하며 TLS를 추가할 수도 있습니다. | UUID, AEAD 설정, 암호화 방식, 전송 매개변수 |
| VLESS | UUID | 기존 설정은 encryption이 none이며, 보통 TLS 또는 REALITY로 연결을 보호합니다. | UUID, flow, 보안 계층 및 서버 측 대응 설정 |
| Trojan | 비밀번호 | 표준 구성에서는 TLS로 인증 정보와 프록시 데이터를 보호합니다. | 비밀번호, 서버 이름, 인증서 유효성 |
| Shadowsocks | 암호화 방식 및 해당 비밀번호 또는 키 | 선택한 방식으로 대칭 암호화를 수행하며, AEAD 방식은 무결성 보호도 제공합니다. | method, 키 형식, TCP 및 UDP 지원 여부 |
VMess에서 흔히 쓰는 AEAD 설정은 alterId: 0입니다. 오래된 공유 링크에 들어 있는 0이 아닌 alterId를 최신 설정에 그대로 적용하지 말고, 실제 동작 모드를 서버 관리자에게 확인하세요. 시스템 시간이 틀려도 VMess 인증에 실패할 수 있으므로 UUID를 계속 바꾸기보다 먼저 시스템의 자동 시간 동기화를 켜세요.
VLESS의 encryption: none은 기존 VLESS 프로토콜 계층에서 암호화를 담당하지 않는다는 뜻이지, 외부 TLS나 REALITY가 작동하지 않는다는 뜻은 아닙니다. 반대로 보안 계층 없이 VLESS와 일반 TCP만 사용하는 공용 네트워크 연결은 UUID를 사용하더라도 데이터 기밀성이 보장되지 않습니다. 확장 기능의 지원 여부는 양쪽 코어 버전을 기준으로 확인하세요.
Shadowsocks의 aes-128-gcm, chacha20-ietf-poly1305, Shadowsocks 2022 방식은 서로 다른 설정입니다. 2022 방식은 키 형식과 길이 요구사항이 정해져 있어 임의의 문자열 비밀번호를 그대로 가져다 쓸 수 없습니다. 양쪽 클라이언트에 모두 Shadowsocks라고 표시되어도 같은 방식을 지원한다는 보장은 없습니다.
요점: 프로토콜을 바꾸기 전에 설정 조합 전체를 확인하세요
‘프로토콜 + 전송 방식 + 보안 계층 + 인증 매개변수’를 기록해 두세요. 기존 노드에서 시간 초과가 발생한다면 이 네 항목과 서버 연결 가능 여부부터 확인하세요. 프로토콜 이름만 바꿔서는 포트가 열려 있지 않거나 인증서가 일치하지 않는 문제가 해결되지 않습니다.
3. 핸드셰이크 비용과 속도: 프로토콜 이름만으로 순위를 매길 수 없습니다
웹페이지를 처음 열 때 걸리는 시간에는 DNS 조회, TCP 연결, TLS 핸드셰이크, 프록시 인증, 대상 사이트의 응답이 모두 포함될 수 있습니다. TLS 1.3의 전체 핸드셰이크에는 보통 왕복 통신 한 번이 필요하며 TCP 연결에도 별도의 왕복 비용이 듭니다. 연결 재사용과 세션 재개 여부에 따라 이후 요청의 비용은 달라집니다. 따라서 ‘새 연결’과 ‘연결된 뒤의 다운로드 속도’를 구분해 기록해야 합니다.
VMess와 Shadowsocks는 자체 암호화를 제공하지만, 그렇다고 모든 구성에서 TLS를 사용하는 방식보다 빠른 것은 아닙니다. 기기의 AES 하드웨어 가속 지원 여부, 서버 부하, 네트워크 경로의 패킷 손실, 혼잡 제어가 모두 결과에 영향을 줍니다. Trojan은 TLS를 사용하지만, 연결이 한 번 성립한 뒤에는 초기 핸드셰이크 비용이 데이터 패킷마다 반복해서 더해지지 않습니다.
- 테스트 조건을 동일하게: 같은 기기, 같은 네트워크, 같은 대상 사이트를 사용하고 백그라운드 다운로드를 끄세요. 가능하면 같은 위치의 서버를 선택해야 프로토콜이 아닌 네트워크 경로를 비교하는 일을 피할 수 있습니다.
- 최초 연결과 재사용 연결을 따로 측정: 연결을 다시 시작한 뒤 첫 요청에 걸리는 시간을 기록하고, 이어서 같은 대상에 연속으로 요청하세요. 재사용 연결 결과를 최초 핸드셰이크 결과로 간주하지 마세요.
- 최소 5회 반복: 중앙값, 실패 횟수, 장시간 전송 성능을 기록하세요. 한 번 측정한 최저 지연 시간으로 안정성을 판단할 수는 없습니다.
- UDP는 별도로 확인: 웹페이지가 열린다는 것은 해당 TCP 경로가 작동한다는 뜻일 뿐입니다. 음성 통화, 게임, QUIC 트래픽도 정상이라고 볼 수는 없습니다.
4. 전송 조합, 포트, 서버 조건
VMess와 VLESS는 일반 TCP, WebSocket 등과 조합해 쓰는 경우가 많습니다. Trojan의 표준 설정은 TLS 연결을 기반으로 하며, 다른 전송 방식은 구현에 따라 달라집니다. Shadowsocks 기본 프로토콜에는 WebSocket이나 일반 HTTPS 사이트의 특성이 내장되어 있지 않습니다. 리버스 프록시나 CDN을 사용할 수 있는지는 포트만 볼 것이 아니라 서버가 지원하는 전송 방식을 하나씩 확인해야 합니다.
서버 포트를 443으로 설정해도 TLS가 자동으로 켜지거나 CDN 호환성이 생기지는 않습니다. WebSocket을 사용한다면 경로도 일치해야 합니다. 예를 들어 서버 경로가 /proxy-ws라면 클라이언트에 /를 입력하면 안 됩니다. HTTP Host는 관련 HTTP 요청에 사용되고 TLS의 SNI는 서버 이름 협상에 사용됩니다. 둘 다 도메인처럼 보여도 용도는 다르므로 임의로 바꿔 쓸 수 없습니다.
- 일반 TLS: 인증서는 설정한 서버 이름을 포함해야 하며 유효 기간 내에 있어야 합니다. 인증서 검증을 건너뛰는 방식은 상시 해결책으로 사용하지 마세요.
- VLESS + REALITY: 서버 설정에 따라 공개 키, shortId, 서버 이름 등의 항목을 입력하세요. REALITY 옵션만 켠다고 설정이 완료되는 것은 아닙니다.
- VLESS flow:
xtls-rprx-vision은 모든 환경에서 쓸 수 있는 속도 향상 옵션이 아닙니다. 지원되는 전송 방식, 보안 계층, 클라이언트, 서버가 서로 맞아야 합니다. - UDP: 서버 방화벽, 코어 지원 여부, 클라이언트 진입점, 실제 전송 방식까지 확인하세요. TCP가 작동한다고 UDP도 검증된 것은 아닙니다.
5. v2rayN, v2rayNG, v2flyNG 선택하기
클라이언트는 설정 화면이자 연결을 시작하는 도구이며, 실제 프로토콜 기능은 사용하는 코어가 구현합니다. 데스크톱용 v2rayN에서는 현재 설정이 어떤 코어를 호출하는지 확인하세요. Android용 v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 공유 링크를 가져올 수 있더라도 flow, REALITY, Shadowsocks 암호화 방식 등의 항목이 올바르게 유지되었는지 확인해야 합니다.
v2rayNG: Android에서 Xray 설정 사용
추천서버에서 VLESS + REALITY 또는 Vision 설정을 제공한다면 v2rayNG에 포함된 Xray 코어 버전과 가져온 설정 항목부터 확인하세요. 이 추천은 해당 설정을 Android에서 사용할 때에 한하며, 모든 네트워크에서 더 빠르다는 뜻은 아닙니다.
적합한 환경: 서버가 제공하는 Xray 기능을 사용하려는 Android 기기
v2rayN: 데스크톱에서 실제 코어 확인
데스크톱에서 여러 노드와 구독을 관리하기에 적합합니다. 테스트 전에 현재 노드 유형과 사용 중인 코어 및 버전을 확인하세요. 클라이언트 버전과 코어 버전은 별개의 정보이므로, 클라이언트 프로그램을 업데이트한 뒤에도 코어가 함께 업데이트되었는지 확인해야 합니다.
적합한 환경: 데스크톱에서 구독과 라우팅 설정을 한곳에서 관리할 때
v2flyNG: v2fly 지원 범위에 맞춰 선택
기존 설정이 v2fly와 호환된다고 확인된 Android 환경에 적합합니다. Xray 전용 REALITY 또는 Vision 항목을 그대로 가져오지 마세요. 다른 프로토콜과 암호화 방식도 실제 코어 버전에 따라 지원 여부를 확인해야 합니다.
적합한 환경: 기존 v2fly 설정과 동일한 구현을 유지해야 할 때
확인하려면 클라이언트의 노드 편집 화면에서 ‘주소’, ‘포트’, ‘전송’, ‘TLS’ 항목을 차례로 살펴본 다음 실행 로그를 확인하세요. 버전에 따라 메뉴 이름이 달라질 수 있으므로 오래된 화면 캡처만 보고 옵션을 찾지는 마세요. 공유 링크의 vmess://, vless://, trojan://, ss://는 서로 다른 파싱 형식을 나타냅니다. 접두어만 바꾼다고 프로토콜이 변환되지는 않습니다.
6. 기존 구독과 신규 서버 구축에 따른 선택
선택 순서: 먼저 연결을 확인하고 테스트 변수를 통제하세요
기존 구독 또는 제공받은 서버를 사용하는 경우
- 서버가 제공한 프로토콜과 매개변수를 기준으로 설정하고, 프로토콜 유형을 임의로 바꾸지 마세요.
- 클라이언트 코어가 완전히 지원하고 실제 요청도 성공하는 구성을 우선 선택하세요.
- 같은 라우팅 및 DNS 정책을 유지하고, 같은 지역의 노드끼리 안정성을 비교하세요.
- 업데이트 전에 작동하는 설정을 보관하고 구독 주소와 인증 정보를 공개하지 마세요.
신규 구축 또는 서버를 직접 관리하는 경우
- 일반 TLS 인증서로 서버를 구성해야 한다면 Trojan 또는 VLESS + TLS를 검토할 수 있습니다.
- 이미 안정적으로 운영 중인 VMess 설정이 있다면 먼저 호환성과 유지 관리 비용을 확인하세요.
- 대칭 암호화 프록시가 필요하다면 Shadowsocks 방식과 UDP 지원 여부를 확인하세요.
- REALITY가 필요하다면 양쪽에서 Xray를 구현하는지, 설정 매개변수가 일치하는지 먼저 확인하세요.
먼저 재현 가능한 정상 설정을 확보한 뒤 한 번에 매개변수 하나만 변경하세요. 프로토콜, 전송 방식, 네트워크 경로를 동시에 바꾸면 문제 원인을 찾기 어려워집니다.
일반적인 웹 브라우징은 네트워크 경로 품질과 최초 연결 시간의 영향을 더 많이 받고, 지속적인 다운로드는 대역폭, 혼잡, 서버 리소스에 더 크게 좌우됩니다. 음성 통화와 게임에서는 UDP 전달과 지터를 확인해야 합니다. ‘VLESS가 VMess보다 최신이다’ 또는 ‘Shadowsocks 설정이 짧다’는 이유만으로 일괄적인 속도 순위를 정할 수는 없습니다.
요구 사항이 시스템 프록시를 따르지 않는 프로그램의 트래픽을 프록시로 보내는 것뿐이라면, 먼저 프로토콜을 바꾸기보다 TUN 또는 Android VPN의 트래픽 처리 범위를 확인하세요. 프록시 프로토콜은 클라이언트와 서버 간 데이터 교환을 담당하며, 앱 트래픽이 클라이언트에 들어오는지는 별개의 문제입니다. 관련 설정은 클라이언트 사용 안내에서 확인할 수 있습니다.
7. 프로토콜 선택 관련 자주 묻는 질문
VLESS의 encryption이 none인데 AES로 바꿔야 하나요?
기존 VLESS 설정은 서버에서 요구하는 none을 그대로 사용하세요. VMess 암호화 옵션을 적용하면 안 됩니다. 대신 TLS 또는 REALITY가 서버 요구사항에 맞게 활성화되어 있는지, 서버 이름과 인증 매개변수가 올바른지 확인하세요. 서버에서 특정 확장 기능을 사용한다면 양쪽 코어의 문서에 따라 설정하세요.
Trojan 포트에 연결되는데 왜 인증서 오류가 발생하나요?
포트에 연결할 수 있어도 TLS 검증에 성공했다는 뜻은 아닙니다. 노드 편집 화면에서 서버 이름을 확인한 다음 인증서에 해당 도메인이 포함되어 있는지, 유효 기간이 지났는지, 시스템 시간이 정확한지 확인하세요. 서버 인증서 체인이 불완전하다면 서버 측에서 수정해야 합니다. 인증서 검증을 장기간 끄지 마세요.
Shadowsocks 암호화 방식을 바꾼 뒤 연결되지 않는 이유는 무엇인가요?
method와 비밀번호 또는 키가 서버 설정과 일치하는지 확인하세요. 특히 기존 AEAD 방식에서 2022 방식으로 바꿀 때는 클라이언트가 해당 방식을 지원하는지, 요구사항에 맞는 키를 사용하는지 확인해야 합니다. 드롭다운 옵션만 바꾸고 기존 비밀번호를 그대로 쓰는 것으로는 전환할 수 없는 경우가 많습니다.
같은 VLESS 링크를 한 클라이언트에서는 사용할 수 있는데 다른 클라이언트에서는 실패하는 이유는 무엇인가요?
양쪽에서 실제로 사용하는 코어 버전과 가져온 뒤의 전송 방식, 보안 계층, flow, 공개 키, shortId를 비교하세요. 링크에 Xray 전용 기능이 포함되어 있다면 호환되는 구현을 사용해야 합니다. 가져오기에 성공했다고 호환성이 확인된 것은 아니므로 로그에서 실패 단계를 찾은 뒤 조정하세요.
네 가지 프로토콜 모두 시간 초과가 발생하는데 하나씩 계속 바꿔 봐야 하나요?
프로토콜을 바꿔 가며 시험하는 것을 멈추고, 먼저 로컬 네트워크와 시스템 시간, 서버 주소 및 포트가 올바른지 확인하세요. 이어서 서버가 실행 중인지, 방화벽에서 연결을 허용하는지도 살펴보세요. 여러 프로토콜이 같은 네트워크 경로를 공유하며 문제가 발생한다면 프로토콜을 바꿔도 근본적인 연결 불가 문제는 해결되지 않습니다. 기본 점검 방법은 문제 해결 가이드에서 확인하세요.