구독 노드를 고르고 PC와 안드로이드 기기에 같은 서비스를 설정하려는 사용자에게 적합한 글입니다. 먼저 프로토콜, 전송 방식, 보안 계층을 구분하고 네 가지 프로토콜의 인증·암호화 방식을 비교한 뒤, 클라이언트 호환성과 동일 조건 테스트를 통해 주력 노드를 선택합니다. 프로토콜 이름만으로 속도를 판단할 수는 없습니다. 서버 회선, 전체 설정, 실제 커널 지원 여부가 연결 결과에 더 큰 영향을 주는 경우가 많습니다.
1. 노드 이름부터 구분하기: 프로토콜·전송 방식·보안 계층
구독 목록에서 흔히 보이는 “VLESS + WebSocket + TLS”는 서로 대체할 수 있는 세 가지 프로토콜이 아닙니다. VLESS는 프록시 요청과 사용자 인증을 처리하고, WebSocket은 데이터를 전달하며, TLS는 연결을 보호합니다. 이름이 VLESS로 시작한다는 이유만으로 더 빠르거나 안전하다고 단정하면 연결에 영향을 주는 설정을 놓칠 수 있습니다.
클라이언트와 커널도 구분해서 봐야 합니다. v2rayN, v2rayNG, v2flyNG는 설정을 관리하는 클라이언트이고, 실제 연결은 커널이 처리합니다. V2Ray와 Xray의 지원 범위는 완전히 같지 않습니다. 따라서 이름이 모두 VLESS인 노드라도 특정 전송 방식이나 보안 기능에 의존할 수 있습니다.
- 프록시 프로토콜: VMess, VLESS, Trojan, Shadowsocks가 있으며 요청 형식, 사용자 인증, 일부 암호화 동작을 결정합니다.
- 전송 방식: TCP, WebSocket, gRPC 등이 있으며 프록시 데이터의 네트워크 전송 방식을 정합니다. 양쪽의 설정이 서로 호환되어야 합니다.
- 보안 계층: TLS나 REALITY 등이 있습니다. 포트 번호만으로 사용 여부를 판단할 수 없으며 서로 임의로 바꿔 쓸 수도 없습니다.
- 라우팅: 요청을 direct, proxy, block 중 어디로 보낼지 결정합니다. 프록시 노드를 선택해도 모든 앱의 트래픽이 반드시 해당 노드를 통과하는 것은 아닙니다.
2. 네 가지 프로토콜의 암호화와 인증 방식 비교
네 가지 프로토콜 모두 프록시 연결에 사용할 수 있지만 데이터를 보호하는 방식은 서로 다릅니다. 아래 표는 널리 쓰이고 호환성이 높은 설정 조합을 기준으로 합니다. 새로운 확장 기능이나 특정 커널 매개변수를 사용하는 경우에는 서버 요구 사항과 로컬 커널 지원 여부를 확인하세요.
| 프로토콜 | 인증 방식 | 암호화 및 보안 범위 | 일반적인 설정 |
|---|---|---|---|
| VMess | UUID 기반 사용자 식별. 최신 설정에서는 AEAD 인증 사용 | 프로토콜 자체 암호화 기능을 제공하며, 실제 동작은 security 설정에 따라 달라집니다. TLS를 추가로 적용할 수도 있습니다. | TCP；WebSocket + TLS |
| VLESS | 일반적으로 UUID 사용 | 흔히 쓰이는 encryption=none 설정은 프로토콜 자체의 페이로드 암호화를 제공하지 않으므로 TLS나 REALITY 등으로 보호해야 합니다. | TCP + TLS；WebSocket + TLS；TCP + REALITY + Vision |
| Trojan | 공유 비밀번호 | 일반적인 구성에서는 TLS로 인증과 프록시 데이터를 보호합니다. 인증서 검증을 올바르게 설정하는 것이 중요합니다. | TCP + TLS |
| Shadowsocks | 공유 키. 입력 형식은 암호화 방식에 따라 달라집니다. | 선택한 암호화 방식으로 프록시 데이터를 보호합니다. 기존 AEAD와 2022 계열은 구분해야 합니다. | 기본 TCP / UDP, 서버에서 지정한 확장 조합 |
VMess: 먼저 AEAD를 확인한 뒤 전송 설정을 살펴보기
VMess라고 해서 오래된 노드는 무조건 쓸 수 없는 것은 아닙니다. 정상적으로 유지 관리되는 AEAD 노드는 여전히 유용합니다. 예전 설정의 alterId는 혼동하기 쉽습니다. 최신 설정에서는 보통 0을 사용하며 AEAD 방식으로 동작합니다. 임의로 더 큰 값으로 바꾸지 마세요. VMess 인증은 시간 정보에도 영향을 받으므로 PC와 휴대폰의 시스템 시간을 정확하게 맞춰야 합니다.
VLESS: 일반적인 설정에서는 암호화를 외부 계층에 맡김
VLESS에서 흔히 쓰는 encryption=none 설정이 연결 전체에 암호화가 없다는 뜻은 아닙니다. 외부 계층의 TLS나 REALITY가 연결을 보호할 수 있습니다. 반대로 VLESS + TCP만 사용하고 보안 계층을 적용하지 않았다면, 접속하는 앱이 HTTPS를 사용한다는 이유만으로 프록시 경로 전체가 똑같이 보호된다고 볼 수 없습니다. 일부 최신 구현은 추가 암호화 확장을 제공하지만 모든 클라이언트에 그대로 적용할 수는 없습니다.
Trojan과 Shadowsocks: 비밀번호 항목의 의미가 다름
Trojan의 공유 비밀번호는 인증에 쓰이고, TLS가 연결을 보호합니다. Shadowsocks는 비밀번호나 키와 암호화 방식이 함께 맞아야 연결할 수 있습니다. 예를 들어 aes-128-gcm과 chacha20-ietf-poly1305는 임의로 바꿔 쓸 수 없습니다. 2022 계열에는 별도의 키 형식 요건이 있으므로 기존 비밀번호를 그대로 옮긴 뒤 method만 바꾸면 안 됩니다.
3. 핸드셰이크 부담과 속도: 프로토콜 순위를 고정하지 마세요
웹페이지를 처음 열 때의 대기 시간에는 도메인 조회, 서버 연결, 외부 보안 핸드셰이크, 프록시 인증, 대상 사이트 연결이 모두 포함됩니다. WebSocket은 HTTP 업그레이드 절차가 필요한 경우가 많고, gRPC는 HTTP/2를 사용합니다. TLS 세션 재사용 여부도 연결 비용에 영향을 줍니다. 이런 조합을 두고 특정 프로토콜은 언제나 “핸드셰이크가 한 번 적다”고 단정할 수 없습니다.
처리량은 별개의 문제입니다. 서버 대역폭, 저녁 시간대 혼잡, 패킷 손실, 기기의 처리 성능이 병목이 될 수 있습니다. 조건이 맞으면 VLESS + Vision이 암호화 관련 중복 부담을 줄일 수 있지만, 모든 VLESS 노드에서 기본 제공되는 기능은 아니며 어떤 회선에서든 다른 프로토콜보다 빠르다고 보장하지도 않습니다.
이 포트 예시는 연결 계층의 위치를 설명하기 위한 것으로, 속도를 측정한 결과가 아닙니다. 서버 포트와 로컬 프록시 포트는 서로 다릅니다. 브라우저는 로컬 수신 포트에 연결하고, 커널은 구독 정보에 지정된 서버 포트로 연결합니다. 서버의 443을 로컬 SOCKS 설정에 입력한다고 프록시가 자동으로 연결되지는 않습니다.
- 같은 기기와 네트워크에서 같은 시간대에 테스트하고, 가능하면 동일한 서버 회선에서 제공하는 서로 다른 프로토콜 노드를 비교하세요.
- 후보 노드마다 같은 페이지를 처음 열어 5회 기록한 다음, 동일한 다운로드 작업을 30초씩 3회 진행하세요. 한 번 측정한 최고 속도를 지속 가능한 속도로 간주하지 마세요.
- 테스트 전에 시스템 프록시 또는 VPN 적용 상태와 라우팅 규칙을 고정하고, 대상 요청이 실제로 현재 노드를 통과하는지 확인하세요. 직접 연결 결과가 비교에 섞이지 않도록 주의해야 합니다.
- 시간 초과 횟수, 페이지 로딩 시간의 중앙값, 안정적인 다운로드 속도를 기록하세요. TCP 지연 시간만 비교해서는 웹, 동영상, UDP 앱의 사용 가능 여부를 판단하기 어렵습니다.
4. 사용 환경에 맞는 프로토콜 선택: 먼저 서버 조건 확인
서버 측 설정이 없다면 클라이언트에서 VMess를 VLESS로 바꾸는 것만으로 전환할 수 없습니다. 아래 권장 사항은 서비스 제공자가 해당 프로토콜을 지원하는 완전한 노드를 제공한다는 전제에 따릅니다. 안정적으로 사용 중인 노드는 이름이 새것인지 오래된 것인지가 아니라, 실제 측정 결과를 기준으로 이전 여부를 결정하세요.
VLESS + REALITY + Vision
추천클라이언트와 서버가 모두 지원하고 서버 매개변수가 완비되어 있다면 Xray 환경의 주력 후보로 고려할 수 있습니다. 공개 키, 서버 이름, shortId, flow를 반드시 확인하세요. 일반 VLESS 노드에서 이 값을 임의로 만들어서는 안 됩니다.
적합한 환경: Xray 커널을 사용하며 서버에서 필요한 REALITY 설정을 모두 제공한 PC와 안드로이드 기기
VMess + WebSocket + TLS
기존 구독에서 비교적 흔히 볼 수 있는 구성입니다. AEAD, WebSocket 경로, Host, TLS 서버 이름을 중점적으로 확인하세요. 서버가 허용한다면 WebSocket 전달이 필요한 환경에서 사용할 수 있습니다.
적합한 환경: 정상적으로 관리되는 기존 VMess 서비스 또는 WebSocket 전달 설정을 이미 사용하는 경우
Trojan + TLS
인증과 전송 설정은 비교적 명확하지만 유효한 인증서와 올바른 서버 이름이 필요합니다. 기존 Trojan의 TLS 동작이 모든 전달 서비스에서 지원된다는 뜻은 아닙니다. 일반 HTTP 리버스 프록시로 TCP 전달을 그대로 대체할 수도 없습니다.
적합한 환경: 도메인과 TLS를 이미 설정했고 비밀번호 인증을 사용하려는 서비스
Shadowsocks AEAD
일반적인 설정은 주소, 포트, 암호화 방식, 비밀번호를 중심으로 구성됩니다. UDP를 사용하려면 서버와 클라이언트, 현재 트래픽 적용 방식을 모두 확인하세요. TCP 지원만으로 UDP까지 사용할 수 있다고 판단할 수는 없습니다.
적합한 환경: 암호화 방식이 일치하는 서비스를 이미 사용하거나 기본 TCP / UDP 프록시 구성을 유지하려는 경우
5. v2rayN·v2rayNG·v2flyNG 함께 사용하기
호환성을 확인할 때는 클라이언트 이름만 보지 말고 “클라이언트 버전 + 커널 버전 + 전체 프로토콜 조합”을 확인해야 합니다. v2rayN은 데스크톱 클라이언트로, 배포 패키지와 설정에 따라 여러 커널을 사용할 수 있습니다. v2rayNG는 Xray 커널을, v2flyNG는 V2Fly 커널을 사용합니다. 이름이 비슷하다고 해서 두 앱에서 모든 노드를 서로 바꿔 쓸 수 있는 것은 아닙니다.
PC와 안드로이드에서 함께 사용하기: 같은 구독을 쓰되 커널과 트래픽 적용 방식을 각각 확인
PC: v2rayN
- Windows, macOS, Linux 중 사용 중인 운영체제에 맞는 배포 패키지를 선택하세요.
- REALITY / Vision 노드를 사용하기 전에 실제로 실행 중인 Xray 커널이 해당 조합을 지원하는지 확인하세요.
- 노드를 선택해 연결한 다음 시스템 프록시 또는 TUN 상태와 라우팅 규칙을 확인하세요.
- 로컬 수신 포트는 현재 설정에서 확인하고 다른 기기의 값을 그대로 사용하지 마세요.
안드로이드: v2rayNG / v2flyNG
- v2rayNG는 Xray 기능이 필요한 노드에 사용할 수 있지만, 설치된 버전이 호환되는지 확인해야 합니다.
- v2flyNG에서는 V2Fly 커널의 지원 범위에 맞는 노드를 선택하세요. Xray 전용 조합이 기본 지원된다고 가정해서는 안 됩니다.
- 같은 구독을 가져온 뒤 노드 매개변수를 확인하고 시스템 VPN 권한을 승인하세요.
- 앱별 프록시 설정을 확인해 테스트할 앱이 프록시에서 제외되지 않도록 하세요.
같은 구독으로 노드 목록은 공유할 수 있지만, 로컬 포트, 라우팅 규칙, DNS, 앱별 설정까지 자동으로 동기화되지는 않습니다.
v2rayN 클래식 인터페이스의 일반적인 경로를 예로 들면, 「구독 그룹」→「구독 그룹 설정」에서 구독을 관리하고 「설정」→「매개변수 설정」에서 로컬 설정을 확인할 수 있습니다. 데스크톱의 크로스 플랫폼 인터페이스에서는 메뉴 이름이 다를 수 있으므로 현재 화면을 기준으로 하세요. 안드로이드에서는 메인 화면의 추가 메뉴에서 공유 링크를 가져온 다음 선택한 노드의 편집 화면을 확인하면 됩니다. 버전이 다른 앱의 버튼 위치를 그대로 따라 하지 마세요.
- 가져오기는 됐지만 연결이 시작되지 않음: 비밀번호부터 바꾸지 말고 커널 시작 로그를 확인해 지원되지 않는 전송 방식, 보안 유형 또는 암호화 방식이 있는지 살펴보세요.
- PC에서는 되지만 안드로이드에서는 안 됨: 두 기기의 실제 커널 버전과 노드 설정을 비교하세요. 특히 flow, 지문, 서버 이름, 전송 경로를 확인해야 합니다.
- 노드 목록은 같은데 접속 결과가 다름: DNS, 라우팅, 트래픽 적용 범위를 추가로 비교하세요. 노드 동기화와 전체 설정 동기화는 서로 다른 작업입니다.
6. 프로토콜 설정 점검: 연결이 안 될 때 확인할 항목
설정을 바꾸기 전에 서비스 제공자의 원본 설정을 보관해 비교 자료로 활용하세요. 근거가 있는 항목 하나씩만 변경하고, 연결을 다시 시작한 뒤 로그를 확인해야 합니다. 포트, SNI, 전송 방식을 한 번에 바꾸면 원인을 추적하기 어렵습니다.
| 노드 유형 | 우선 확인할 항목 | 흔한 실수 |
|---|---|---|
| VMess | UUID, alterId, security, 시스템 시간, 전송 경로 | 오래된 가이드의 0이 아닌 alterId를 최신 AEAD 노드에 적용 |
| VLESS + TLS | UUID, encryption, 서버 이름, 전송 유형, flow | WebSocket 노드에 Vision을 억지로 추가하거나 TLS를 빠뜨림 |
| VLESS + REALITY | UUID, 공개 키, shortId, 서버 이름, 지문, flow | 다른 노드의 공개 키를 복사하거나 보안 유형만 REALITY로 변경 |
| Trojan | 비밀번호, 포트, TLS 서버 이름, 인증서 검증 | 연결 주소가 IP이면 서버 이름에도 반드시 같은 IP를 입력해야 한다고 오해 |
| Shadowsocks | method, 비밀번호 또는 키, 포트, UDP 지원 | 2022 계열과 기존 AEAD의 키 형식을 혼용 |
TLS 노드의 서버 이름은 일반적으로 인증서에 포함된 도메인이며 연결 주소와 다를 수 있습니다. WebSocket의 Host는 HTTP 계층의 필드입니다. 서버에서 별도로 설정할 수 있는 TLS의 SNI와 값이 다를 수 있지만, 두 항목 모두 서버 요구 사항에 맞아야 합니다. 인증서 오류가 발생하면 시스템 시간, 도메인, 인증서 체인을 확인하세요. allowInsecure를 일상적인 해결 방법으로 사용해서는 안 됩니다.
로그에 연결 성공이 표시되는데 일부 사이트가 열리지 않는다면 DNS, 규칙 매칭, 대상 사이트 연결을 중심으로 확인하세요. 프로토콜을 바꿔 다른 회선으로 연결되면 문제가 해결되는 경우도 있지만, 원래 프로토콜 자체에 문제가 있었다는 뜻은 아닙니다. 기본 점검 절차는 문제 해결을 참고하고, 개념이 헷갈릴 때는 개념 빠른 참조를 확인하세요.
7. 프로토콜 선택 관련 자주 묻는 질문
VLESS의 encryption이 none인데 암호화 옵션으로 바꿔야 하나요?
임의로 바꾸지 마세요. 먼저 노드 편집 화면에서 서버가 요구하는 TLS 또는 REALITY가 설정되어 있는지 확인하세요. 일반적인 VLESS 구성에서는 none을 사용하고 외부 계층이 연결을 보호합니다. 새로운 암호화 확장은 양쪽 모두 명시적으로 지원해야 하며 클라이언트에서만 켤 수 없습니다.
Trojan 비밀번호를 입력했는데도 핸드셰이크에 실패하는 이유는 무엇인가요?
먼저 포트와 TLS 서버 이름을 확인한 다음 시스템 시간과 인증서 오류를 살펴보세요. 비밀번호 인증 전에 TLS 핸드셰이크 단계에서 실패할 수 있으므로 이 경우 비밀번호를 계속 바꿔도 해결되지 않습니다. 서버 이름은 노드 제공자가 안내한 값으로 입력하고 노드 설명만 보고 추측하지 마세요.
Shadowsocks로 웹페이지는 열리는데 게임은 연결되지 않아요. 왜 그런가요?
게임에서 UDP를 사용하는지 확인한 다음 서버의 UDP 전달, 로컬 트래픽 적용 방식, 앱별 규칙을 점검하세요. 일반 HTTP 프록시는 모든 UDP 앱을 처리할 수 없습니다. PC에서 TUN을 사용한다면 설정이 올바른지 확인하고, 안드로이드에서는 게임이 VPN 적용 대상에서 제외되지 않았는지 살펴보세요.
같은 구독인데 v2flyNG에서 사용할 수 있는 노드가 몇 개 빠졌어요. 어떻게 해야 하나요?
누락되었거나 연결에 실패한 노드의 전체 설정 조합을 확인하세요. Xray의 REALITY / Vision 기능이 필요하다면 해당 조합을 지원하는 v2rayNG를 사용하거나 서비스 제공자에게 V2Fly 호환 노드를 요청하세요. 지원되지 않는 보안 유형을 TLS로 임의 변경하지 마세요.
지연 시간이 가장 낮은 프로토콜을 선택하면 되나요?
먼저 측정값이 TCP 연결 지연인지 실제 프록시 요청 결과인지 확인하세요. 앞서 설명한 동일 조건으로 여러 번 테스트하고 웹페이지 로딩, 지속 다운로드, 시간 초과 횟수를 비교하세요. 프로토콜 이름순으로 고르는 것보다 안정적인 주력 노드와 검증된 예비 노드를 하나씩 확보하는 편이 낫습니다.
최종 선택은 세 단계로 정리할 수 있습니다. 먼저 서버가 어떤 구성을 제공하는지 확인하고, 다음으로 클라이언트와 커널이 전체 구성을 지원하는지 확인한 뒤, 현재 네트워크에서 실제 성능을 비교하세요. VMess, VLESS, Trojan, Shadowsocks 모두 설정이 맞아야 사용할 수 있습니다. 프로토콜 이름만 바꾼다고 라우팅, DNS, 회선 품질 문제가 저절로 해결되지는 않습니다.