구독을 이용 중이라면 필요한 매개변수가 모두 포함되어 있고 클라이언트 양쪽의 코어가 지원하는 노드를 우선 선택하세요. 서버를 직접 설정한다면 인증 방식과 보안 계층, 전송 조합을 비교하면 됩니다. 먼저 프로토콜과 코어의 관계를 살펴본 뒤 네 가지 방식의 차이를 비교하고, 데스크톱과 Android에서 확인할 항목을 안내합니다. VMess를 유지할 때와 VLESS + REALITY를 선택할 때, Trojan과 Shadowsocks가 각각 적합한 조건을 파악할 수 있습니다.
프로토콜·전송 방식·보안 계층·클라이언트 구분하기
노드 이름의 “VLESS + TCP + REALITY”는 서로 같은 종류의 선택지가 세 개 있다는 뜻이 아닙니다. VLESS는 프록시 요청과 사용자 인증을 처리하고, TCP는 하위 전송을 담당하며, REALITY는 연결의 보안 핸드셰이크와 인증 관련 기능을 맡습니다. 이 계층을 혼동하면 “VLESS를 선택했는데 왜 연결이 안 되지?” 또는 “포트를 443으로 바꾸면 TLS가 자동으로 켜지나?” 같은 오해가 생길 수 있습니다.
v2rayN, v2rayNG, v2flyNG는 그래픽 클라이언트이지 네 가지 프로토콜의 다른 이름이 아닙니다. v2rayN의 실제 기능은 선택한 코어와 버전에 따라 달라지고, v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용합니다. 인터페이스에 필드가 표시된다고 해서 구형 코어가 해당 조합을 지원하는 것은 아닙니다. 구독을 가져올 수 있어도 모든 매개변수가 올바르게 유지된다는 보장은 없습니다.
- 프록시 프로토콜: VMess, VLESS, Trojan, Shadowsocks가 요청 형식과 인증 방식을 결정합니다.
- 전송 방식: TCP, WebSocket, gRPC 등이 연결을 통해 프록시 데이터를 전달하는 방식을 정합니다. 지원 범위는 구현에 따라 다릅니다.
- 보안 메커니즘: TLS, REALITY 또는 프로토콜 자체 암호화가 사용됩니다. 노드 이름만으로 판단하면 안 됩니다.
- 접속 및 트래픽 분기: 시스템 프록시, TUN, 라우팅 규칙이 어떤 앱과 대상에 노드를 사용할지 결정하며 노드 프로토콜을 자동으로 바꾸지는 않습니다.
네 가지 프로토콜 비교: 암호화·인증·REALITY
아래 표는 현재도 널리 쓰이는 일반적인 설정을 다룹니다. VMess는 최신 AEAD 설정을 전제로 하며, Shadowsocks는 기존 AEAD 방식과 2022 시리즈를 구분해야 합니다. 프로토콜 이름이 같아도 알고리즘과 구현 버전에 따라 호환 범위가 달라질 수 있습니다.
| 프로토콜 | 인증 및 암호화 | 주요 전송 방식 | REALITY와의 관계 | 주요 확인 항목 |
|---|---|---|---|---|
| VMess | 사용자 ID로 인증하며, 일반적으로 AEAD로 데이터를 암호화하고 TLS를 추가로 적용할 수 있음 | TCP, WebSocket + TLS 등 | 일반적인 REALITY 조합으로 선택하지 않음 | UUID, 암호화 옵션, 전송 매개변수, 시스템 시간 |
| VLESS | 일반적인 설정은 UUID로 인증하며, 기존 설정은 자체 데이터 암호화 없이 외부 보안 계층에 의존함 | TCP + TLS, TCP + REALITY, WebSocket + TLS 등 | Xray에서 흔히 사용하는 조합으로, 클라이언트와 서버 양쪽의 지원 여부 확인 필요 | UUID, flow, 보안 계층, 서비스 이름, 공개 키 관련 매개변수 |
| Trojan | 비밀번호로 인증하며, 일반적으로 TLS로 데이터를 보호함 | 주로 TCP + TLS이며, 추가 전송 방식은 구현에 따라 다름 | 일부 Xray 설정에서 조합할 수 있지만 이름만으로 호환성을 판단할 수 없음 | 비밀번호, TLS 서비스 이름, 인증서, 전송 방식 |
| Shadowsocks | 알고리즘과 키가 함께 호환성을 결정하며, 일반적인 방식은 AEAD 또는 2022 시리즈 | 기본 TCP 및 UDP 지원, 추가 캡슐화는 별도 확인 필요 | 프로토콜 자체 기능이 아니므로 VLESS 매개변수를 그대로 적용하면 안 됨 | method, 비밀번호 또는 키 형식, UDP 지원 여부 |
VMess의 auto는 구현에서 제공하는 암호화 선택 로직이지 별도의 프로토콜이 아닙니다. 최신 설정은 보통 AEAD 인증 헤더를 사용합니다. 호환성이 불분명한 구형 가이드에 맞추려고 alterId를 임의로 추가하지 마세요. 시간 기반 인증은 기기 시각도 정확해야 하므로 UUID를 계속 바꾸기보다 먼저 시스템 자동 시간 설정을 켜는 것이 좋습니다.
VLESS 설정에서 흔히 보이는 encryption=none은 보안 계층과 함께 해석해야 합니다. 연결 전체가 반드시 평문이라는 뜻도, VLESS가 자동으로 암호화한다는 뜻도 아닙니다. 바깥 계층에 TLS 또는 REALITY를 적용하면 해당 메커니즘이 연결을 보호합니다. 최신 버전에 추가된 확장 기능은 별도로 확인해야 하며, 이 글에서는 모든 코어가 지원하는 기본 기능으로 간주하지 않습니다.
Shadowsocks의 aes-128-gcm과 2022-blake3-aes-128-gcm은 서로 바꿔 쓸 수 없습니다. 2022 시리즈는 별도의 키 길이와 인코딩 규칙을 따릅니다. 128비트 키는 16바이트, 256비트 키는 32바이트이며 설정에 맞게 인코딩해야 합니다. 임의의 짧은 비밀번호를 입력해 클라이언트가 올바른 키로 자동 변환해 주기를 기대하면 안 됩니다.
핸드셰이크와 속도: 프로토콜 이름만으로 순위를 매길 수 없는 이유
첫 연결에 걸리는 시간에는 도메인 이름 확인, 노드까지의 왕복 시간, 보안 핸드셰이크, 프록시 요청, 대상 사이트의 응답이 포함됩니다. TCPing은 대개 노드 포트에 TCP 연결을 맺을 수 있는지만 확인하며 UUID, 비밀번호, 인증서, REALITY 매개변수는 검증하지 않습니다. 따라서 TCPing 결과만으로 프로토콜의 전체 연결 속도를 판단할 수 없습니다.
일반적인 TCP 환경에서 새 TCP 연결에는 보통 왕복 한 번이 필요합니다. TLS 1.3의 전체 핸드셰이크에도 대개 왕복 한 번이 더 필요하지만, 단계 중첩이나 세션 재개, 연결 재사용 여부는 구현에 따라 달라집니다. WebSocket은 업그레이드 요청과 추가 HTTP 계층 때문에 첫 연결 시간이 늘어날 수 있습니다. 패킷 손실이 발생하면 이런 비용이 커지지만, 모든 환경에 적용되는 지연 시간 공식처럼 단순히 더해서는 안 됩니다.
위 숫자는 포트의 용도를 나타낼 뿐 속도 측정 결과가 아닙니다. 서버가 443 포트를 사용해도 브라우저에서 검증할 수 있는 인증서가 있다는 뜻은 아닙니다. 로컬 SOCKS 포트로 1080을 사용한다고 해서 원격 서버도 같은 포트를 써야 하는 것은 아닙니다. 로컬 수신 포트와 원격 접속 포트를 구분해야 로컬 연결 설정 오류를 프로토콜 성능 문제로 오해하지 않습니다.
- 비교 조건 통일: 가능하면 같은 서버와 회선, 같은 시간대에 테스트하세요. 서로 다른 지역의 노드를 비교해 프로토콜의 우열을 증명할 수는 없습니다.
- 응답 시간과 처리량을 따로 측정: 먼저 실제 연결 지연 시간을 측정한 뒤 같은 대상 파일을 내려받으며 속도를 확인하세요. 5회 연속 측정하고 중앙값과 실패 횟수를 기록합니다.
- 기기 상태도 기록: CPU 사용률과 온도, 배터리 변화를 확인하세요. Android에서 다운로드를 오래 할 때 생기는 발열은 핸드셰이크 차이 수십 밀리초보다 사용 경험에 더 큰 영향을 줄 수 있습니다.
- 한 번에 하나씩 변경: 먼저 연결 재사용, 라우팅, DNS 설정을 그대로 둔 채 전송 방식과 보안 계층을 비교하세요. 여러 항목을 동시에 바꾸면 차이가 생긴 원인을 파악하기 어렵습니다.
서버 조건에 따라 선택하기: 네 가지 방식의 적합한 범위
서버 회선과 매개변수 관리, 로컬 코어를 고려하지 않고 모든 환경에 최적인 프로토콜은 없습니다. 아래 권장 사항은 서버를 직접 관리하고 지속적으로 유지할 수 있는 경우를 전제로 합니다. 구독만 이용한다면 서비스 제공자가 안내한 완전한 설정을 따르세요. 이름이 더 최신이라는 이유로 매개변수를 임의로 조합하지 마세요.
VLESS + REALITY
권장클라이언트 양쪽에서 호환되는 Xray 코어를 사용하고 서버 매개변수를 관리할 수 있다면 우선 검토할 만한 방식입니다. 일반적인 Vision 조합을 사용할 때는 xtls-rprx-vision, 서비스 이름, 공개 키 관련 매개변수, shortId를 확인하세요. UUID만 복사해서는 안 됩니다.
적합한 경우: 서버를 직접 관리하고 데스크톱과 Android 설정을 함께 유지할 수 있는 사용자.
Trojan + TLS
도메인과 인증서, 갱신 절차가 이미 있다면 설정 관계가 비교적 명확합니다. 인증서 신뢰 여부와 서비스 이름, 비밀번호를 각각 확인하면 문제를 찾기 쉽습니다. 인증서가 만료되거나 SNI가 일치하지 않으면 프록시 요청 전에 연결이 차단될 수 있습니다.
적합한 경우: TLS 운영 환경이 갖춰져 있고 표준 인증서 검증 절차를 그대로 사용하려는 환경.
VMess + WebSocket + TLS
사용 중인 리버스 프록시와 VMess 노드가 있다면 그대로 유지할 수 있습니다. CDN을 거치는 경우 WebSocket 전달과 포트, 트래픽 용도를 CDN이 지원하는지 확인해야 합니다. 경로, Host, TLS 서비스 이름은 서로 다른 필드입니다.
적합한 경우: 기존 구독이나 서비스 구성에서 VMess를 안정적으로 사용 중인 경우.
Shadowsocks AEAD / 2022
기본 설정 항목이 비교적 적어 주소와 포트, 알고리즘, 키를 주로 확인하면 됩니다. 지원 알고리즘과 UDP 전달, 추가 캡슐화는 각각 따로 확인해야 합니다. 입력 항목이 적다고 모든 네트워크에서 더 안정적인 것은 아닙니다.
적합한 경우: 서버가 해당 알고리즘을 명시적으로 제공하고 기본 TCP 및 UDP 전달을 확인하려는 환경.
v2rayN·v2rayNG: 가져온 뒤 항목별로 확인하기
구독은 노드 매개변수를 배포하는 방식이지 다섯 번째 프록시 프로토콜이 아닙니다. 같은 구독을 두 클라이언트에서 가져와 노드 이름이 똑같이 표시되어도 이름만 일치한다는 뜻일 뿐, flow와 전송 경로, 보안 계층이 모두 올바르게 해석됐다는 보장은 없습니다. 처음 가져온 뒤에는 노드 편집 화면을 열고 서비스 제공자가 안내한 정보와 항목별로 비교하세요.
확인 방법: 같은 노드를 데스크톱과 Android에서 각각 테스트
데스크톱: v2rayN
- 화면에 표시된 앱 버전만 기록하지 말고 현재 실제로 사용하는 코어와 버전을 확인하세요.
- 노드 편집 창을 열어 프로토콜과 주소, 원격 포트, 보안 계층을 확인하세요.
- 실제 로컬 포트로 연결을 테스트한 뒤 시스템 프록시 또는 TUN이 사용 목적에 맞는지 확인하세요.
- 연결에 실패하면 실행 로그에서 연결 시간 초과와 인증 실패, 인증서 오류를 구분하세요.
Android: v2rayNG
- 내장된 Xray 버전이 서버에서 제공한 전체 조합을 지원하는지 확인하세요.
- 노드의 전송 프로토콜과 TLS 또는 REALITY 설정, 서비스 이름을 확인하세요.
- 연결을 시작하고 시스템 VPN 권한을 허용했는지 확인하세요.
- 테스트하는 앱의 트래픽이 프록시에서 빠지지 않도록 앱별 제외 규칙을 잠시 끄세요.
구독 업데이트는 구독에 포함된 노드 필드만 동기화합니다. 로컬 라우팅과 DNS, 시스템 프록시, 앱별 설정은 각각 따로 확인해야 합니다.
VLESS + REALITY에서 빠뜨리기 쉬운 항목은 서비스 이름과 공개 키 관련 매개변수, shortId, flow입니다. VMess + WebSocket은 경로와 Host를, Trojan은 비밀번호와 인증서 서비스 이름을, Shadowsocks는 method와 키 형식을 먼저 확인하세요. 필드 이름은 클라이언트 버전에 따라 달라질 수 있으니 화면 위치가 아니라 항목의 의미를 기준으로 맞춰야 합니다.
- 주소와 서비스 이름 구분: 연결 주소로 서버 IP를 사용하더라도 TLS 서비스 이름은 보통 인증서 또는 서버에서 허용한 이름과 일치해야 합니다. 무조건 IP를 입력하면 안 됩니다.
- 인증서 검증 유지: 인증서 오류가 발생하면 먼저 시간과 서비스 이름, 신뢰 체인, 인증서 유효기간을 확인하세요. 검증을 건너뛰는 방식은 장기적인 해결책이 아닙니다.
- UDP는 별도로 확인: 웹페이지가 열린다고 UDP까지 사용할 수 있는 것은 아닙니다. 프로토콜 구현과 서버 전달, 방화벽, 클라이언트 접속 모드를 확인하세요.
- 인증 정보는 민감 정보로 취급: 구독 주소와 UUID, 비밀번호, 키, 전체 공유 링크를 공개 스크린샷에 노출하지 마세요.
프로토콜 선택 관련 자주 묻는 질문
VLESS가 VMess보다 항상 빠른가요?
그렇지 않습니다. 일반적인 VLESS 설정은 프로토콜 자체의 데이터 암호화 처리를 줄이지만, 실제 연결에는 TLS나 REALITY가 사용될 수 있습니다. 서버와 테스트 대상을 고정하고 실제 연결 테스트와 다운로드 테스트를 각각 5회 진행한 뒤 중앙값과 실패율, CPU 사용률을 비교하세요. 회선이 서로 다르면 결과 차이를 프로토콜 이름 탓으로 돌릴 수 없습니다.
노드에 REALITY라고 표시되는데 가져온 뒤 시간 초과가 발생하는 이유는 무엇인가요?
먼저 서버 주소와 원격 포트에 접속할 수 있는지 확인한 다음 노드 편집 화면에서 서비스 이름과 공개 키 관련 매개변수, shortId, flow를 확인하세요. 이어서 양쪽의 Xray 버전을 확인합니다. TCPing이 성공해도 포트 연결만 확인한 것이므로 REALITY 핸드셰이크 성공을 뜻하지 않습니다. 로그에 핸드셰이크 오류가 있으면 구체적인 매개변수를 확인해 해결해야 합니다.
Shadowsocks로 웹페이지는 열리지만 게임이 연결되지 않으면 어떻게 하나요?
먼저 게임 트래픽이 프록시를 통과하는지 확인한 뒤 서버와 클라이언트에서 UDP를 사용하도록 설정했는지, 양쪽 구현이 UDP를 지원하는지 확인하세요. 브라우저 또는 시스템 HTTP 프록시만 설정해서는 게임의 UDP 트래픽을 처리하지 못하는 경우가 많습니다. 프로토콜이 UDP를 지원하더라도 서버 방화벽이나 현재 네트워크가 해당 트래픽을 차단할 수 있습니다.
v2flyNG에서 같은 REALITY 노드를 바로 사용할 수 있나요?
구독을 가져올 수 있다는 이유만으로 사용할 수 있다고 판단하지 마세요. v2flyNG는 v2fly 코어를 사용하지만, 이 글에서 다루는 일반적인 REALITY 방식은 Xray 구현을 기반으로 합니다. 해당 노드가 필요하다면 먼저 코어의 지원 여부를 확인하세요. Android에서는 v2rayNG로 서비스 제공자가 안내한 조합을 테스트할 수 있습니다. 노드 이름을 바꿔도 호환성이 생기지는 않습니다.
Trojan으로 바꾸면 기존 라우팅 규칙도 계속 적용되나요?
규칙이 변경되지 않은 아웃바운드 태그를 참조하고 새 노드가 해당 아웃바운드에 올바르게 연결되어 있다면 계속 사용할 수 있습니다. 규칙이 노드 이름이나 그룹, 특정 아웃바운드에 의존한다면 다시 확인해야 합니다. 직접 연결되어야 하는 대상과 프록시를 통과해야 하는 대상을 하나씩 테스트하고 로그에서 실제 아웃바운드를 확인하세요. 클라이언트에 “연결됨”이라고 표시되는 것만으로는 충분하지 않습니다.