핵심 내용

구독을 이미 사용 중이라면 프로토콜 이름만 보고 속도를 판단하지 말고, 클라이언트 코어가 노드 설정을 온전히 지원하는지 먼저 확인하세요. 직접 설정할 때는 인증 방식, 암호화 계층, 전송 조건을 비교하면 됩니다. VMess, VLESS, Trojan, Shadowsocks의 차이를 알고 싶은 사용자를 위해 주요 설정 항목과 TLS 필요 여부, 데스크톱·안드로이드에서의 지원 범위를 정리했습니다.

프로토콜·전송·암호화 계층 구분하기

VMess, VLESS, Trojan, Shadowsocks는 프록시 프로토콜이지 클라이언트 이름이 아닙니다. v2rayN은 데스크톱 클라이언트이며, v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 클라이언트는 설정을 편집·가져오기·실행하고, 실제 연결은 선택한 코어가 담당합니다. 링크를 가져올 수 있다고 해서 코어가 링크에 포함된 모든 조합을 지원하는 것은 아닙니다.

노드 설정에는 서버 주소, 포트, 인증 정보, 전송 설정이 포함됩니다. 프로토콜은 인증 방식과 대상 주소 표현 방법을 정하고, TCP나 WebSocket 같은 전송 방식이 연결을 전달합니다. TLS나 REALITY 같은 보안 계층은 해당 전송 과정을 보호합니다. 문제를 해결할 때는 각 계층을 구분해야 WebSocket 경로 오류를 프로토콜 비호환으로 오해하지 않습니다.

네 가지 프로토콜의 암호화와 핸드셰이크 비교

프로토콜 인증과 데이터 암호화는 서로 다른 기능입니다. UUID나 비밀번호는 접속 권한을 확인하지만, 그 자체로 통신이 암호화되는 것은 아닙니다. 아래 표는 일반적인 구성 사례를 비교한 것으로, 실제 사용 가능한 설정 항목은 양쪽 코어 구현과 서버 설정에 따라 달라집니다.

프로토콜 인증 및 핸드셰이크 암호화와 TLS 관계 주요 확인 항목
VMess UUID를 사용자 인증 정보로 사용하며, 최신 설정은 AEAD 인증 방식을 사용합니다. 인증 과정에서 시스템 시간이 중요합니다. 프로토콜 자체에 데이터 보호 기능이 있습니다. 흔히 사용하는 페이로드 암호화 방식은 AES-GCM과 ChaCha20-Poly1305이며, TLS를 외부 계층으로 추가할 수도 있습니다. UUID, 암호화 옵션, 시스템 시간, 전송 유형, TLS 설정
VLESS UUID로 인증하며 프로토콜 헤더가 간결합니다. 일부 조합에서는 flow 설정도 일치해야 합니다. 일반적인 기본 VLESS 설정은 페이로드를 암호화하지 않으므로 TLS나 REALITY 같은 보안 계층과 함께 사용해야 합니다. 확장 기능은 코어에 따라 다릅니다. UUID, security, flow, TLS 또는 REALITY 관련 설정
Trojan TLS로 보호되는 연결에서 비밀번호 기반 인증 정보와 대상 요청을 전송합니다. 일반적인 구성에서는 인증 정보와 데이터를 보호하기 위해 TLS가 필요하며, 인증서를 올바르게 검증해야 합니다. 비밀번호, 서버 이름, 인증서 신뢰 여부, 전송 설정
Shadowsocks 선택한 방식에 따라 공유 비밀번호나 지정된 형식의 키를 사용하며, 프로토콜 내부에 대상 주소를 포함합니다. AEAD 방식은 자체적으로 인증 암호화를 제공하므로 기본 구성에 TLS가 필요하지 않습니다. 구형 방식과 세대가 다른 방식을 같은 것으로 취급하면 안 됩니다. method, 비밀번호 또는 키, 포트, 양쪽의 해당 방식 지원 여부

설정 난이도: 항목이 적다고 연결이 쉬운 것은 아닙니다

VMess를 가져올 때는 UUID, 암호화 옵션, 전송 매개변수를 확인하는 경우가 많습니다. 최신 VMess AEAD 설정은 보통 alterId=0을 사용합니다. 호환성을 높이겠다며 오래된 가이드의 0이 아닌 값을 그대로 따라 하지 마세요. 인증에 실패하면 UUID를 계속 바꾸기보다 기기와 서버의 시간을 함께 확인하세요.

VLESS는 기본 설정 항목이 적지만, 특정 보안 계층을 사용하면 확인해야 할 조합이 늘어납니다. 예를 들어 VLESS와 REALITY를 함께 사용할 때는 서버 이름, 공개 키, short ID 등의 값이 서버 설정과 일치해야 합니다. xtls-rprx-vision은 특정 flow 값이므로 모든 VLESS 노드에 입력해야 하는 것은 아니며, WebSocket 설정에 임의로 추가해서도 안 됩니다.

  1. 먼저 프로토콜 확인: 서비스 제공자의 안내나 원본 구독 정보로 확인하세요. 포트 번호만 보고 추측하면 안 됩니다.
  2. 다음은 인증 정보 확인: UUID, 비밀번호, 키를 빠짐없이 복사하고, 복사 과정에서 들어간 공백이나 줄바꿈을 제거하세요.
  3. 그다음 전송 설정 확인: WebSocket 경로와 Host, TLS 서버 이름은 각각 따로 확인하세요. 세 값이 서로 다를 수 있습니다.
  4. 마지막으로 확장 설정 확인: 서버에서 명시적으로 사용하도록 설정한 flow, 보안 계층, 방식만 입력하세요. 관련 없는 매개변수를 임의로 추가하지 마세요.

Trojan은 인증서가 유효한지, 서버 이름이 인증서와 일치하는지 확인해야 합니다. Shadowsocks는 aes-128-gcm과 chacha20-ietf-poly1305처럼 암호화 방식을 정확히 맞춰야 합니다. Shadowsocks 2022 방식을 사용한다면 코어 지원 여부와 키 형식도 확인하세요. 일반 비밀번호를 어떤 방식에나 쓸 수 있는 키로 취급하면 안 됩니다.

사용 환경별 선택: 서버를 먼저 확인하고 클라이언트를 살펴보세요

아래 권장 사항은 새 설정을 만들고 Xray를 사용하며 서버를 직접 관리할 수 있다는 전제에 따른 것이며, 속도 순위가 아닙니다. 이미 안정적으로 작동하는 구독이 있다면 호환되는 기존 프로토콜을 계속 사용하는 편이 직접 변경하는 것보다 간편합니다. 지연 시간과 처리량은 회선, 혼잡도, 서버 부하, 전송 방식, 기기 성능에도 영향을 받으므로 프로토콜 이름만으로 판단할 수 없습니다.

VLESS: Xray 새 설정

권장

양쪽에서 지원하고 TLS 또는 REALITY를 올바르게 설정할 수 있다면 새 구성을 위한 우선 후보로 고려할 수 있습니다. 먼저 보안 계층과 전송 조합을 정한 뒤 인증 정보를 입력하세요.

적합한 경우: 서버를 관리할 수 있고 Xray를 사용하며 관련 보안 설정을 유지할 수 있는 경우

VMess: 기존 구성 유지

사용 가능한 VMess 구독이나 서버가 이미 있다면 계속 사용하는 편이 간편합니다. AEAD 설정, 시스템 시간, 기존 WebSocket 또는 TLS 매개변수를 함께 확인하세요.

적합한 경우: VMess 서버를 이미 사용 중이며 기존 설정과의 호환성을 유지해야 하는 경우

Trojan: 인증서와 도메인을 관리할 수 있는 환경

주요 설정은 비밀번호와 TLS입니다. 인증서 갱신, 서버 이름, 신뢰 체인을 지속적으로 관리해야 하며, 인증서 검증을 끄는 것을 장기적인 해결책으로 삼으면 안 됩니다.

적합한 경우: 도메인, 유효한 인증서, 표준 TLS 서비스를 관리할 수 있는 경우

Shadowsocks: 방식이 명확한 간결한 설정

기본 연결에는 주소, 포트, 방식, 인증 정보를 맞추면 됩니다. 양쪽에서 지원하는 최신 AEAD 방식을 선택하고 UDP 등 실제 필요한 기능도 별도로 확인하세요.

적합한 경우: 사용할 암호화 방식과 인증 정보가 정해져 있고 전송 계층 설정을 줄이고 싶은 경우

데스크톱과 안드로이드에서 같은 구독을 사용할 때 확인할 사항

하나의 구독에 여러 프로토콜이 포함될 수 있습니다. v2rayN과 v2rayNG에서 같은 구독 주소를 사용할 수 있지만, 양쪽에서 동일한 노드를 사용할 수 있는지는 구독 형식, 클라이언트의 파싱 기능, 코어 지원 범위에 따라 달라집니다. 특히 flow, REALITY, 최신 암호화 방식을 사용하는 노드는 가져오기에 성공한 뒤에도 상세 설정을 확인하세요.

두 기기에서 사용하기: 같은 구독을 사용하되 코어와 연결 설정을 각각 확인

데스크톱 v2rayN
  • 실제로 실행 중인 코어를 확인한 뒤 해당 코어에서 지원하는 노드를 선택하세요.
  • 노드의 프로토콜, 전송, 보안 계층, flow 설정이 모두 포함되어 있는지 확인하세요.
  • 「설정」→「매개변수 설정」에서 로컬 수신 포트를 확인하세요. 메뉴 이름과 위치는 인터페이스 업데이트에 따라 달라질 수 있습니다.
  • 시스템 프록시가 활성화되어 있는지와 원격 노드에 연결되는지는 따로 확인하세요.
안드로이드 v2rayNG / v2flyNG
  • v2rayNG는 Xray를 사용하므로 해당 코어에서 지원하는 조합에 맞춰 노드를 선택하세요.
  • v2flyNG는 V2Fly를 사용합니다. Xray의 확장 기능을 기준으로 호환성을 판단하면 안 됩니다.
  • 가져온 뒤 인증, 전송, 보안 매개변수를 하나씩 확인하세요.
  • 시스템 VPN 권한을 허용한 다음 실제 앱으로 연결을 확인하세요.

구독 주소는 함께 사용할 수 있어도 실행 설정은 각 기기에서 검증해야 합니다. 한쪽에서 작동한다고 다른 쪽에서도 반드시 작동하는 것은 아닙니다.

구독 링크에는 접속 정보가 포함될 수 있으므로 민감 정보로 취급하세요. 가져오기 결과가 다르면 프로토콜과 누락된 항목을 비교하되, 구독 주소 전체나 UUID, 비밀번호, 키를 공개하지 마세요. 로그를 다른 사람에게 전달할 때도 서버 주소와 인증 정보를 삭제하세요.

포트와 연결 상태: 정확한 연결 지점으로 원인을 좁히기

로컬 프록시 포트와 원격 서버 포트는 서로 다릅니다. 아래의 10808과 10809는 로컬 연결 지점을 설명하기 위한 예시이고, 443은 흔히 사용하는 TLS 서버 포트일 뿐입니다. 모든 노드가 이 값을 사용해야 하는 것은 아닙니다. 명령을 실행하기 전에 클라이언트가 실제로 수신 중인 포트를 확인하세요.

10808
로컬 SOCKS 연결 예시 포트
10809
로컬 HTTP 연결 예시 포트
443
일반적인 원격 TLS 서버 포트

로컬 SOCKS 연결이 127.0.0.1:10808에서 수신 중임을 확인했다면 다음 명령으로 프록시를 지정할 수 있습니다. Windows PowerShell에서는 curl.exe를 사용하고, curl이 설치된 다른 터미널에서는 curl을 사용할 수 있습니다. 여기서는 예시용으로 예약된 도메인에 접속해 테스트 방법만 설명하며, 속도 측정 결과를 의미하지 않습니다.

curl.exe --head --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 https://example.com

socks5h는 대상 도메인 처리를 프록시 쪽에 맡긴다는 뜻입니다. 실제 설정이 HTTP 연결이라면 해당 프록시 주소를 사용하세요. SOCKS 포트만 다른 숫자로 바꾸고 잘못된 프로토콜 접두사는 그대로 두면 안 됩니다.

curl.exe --head --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10809 https://example.com

자주 묻는 질문: 프로토콜을 바꾸기 전에 확인할 사항

VLESS의 encryption이 none인데, 보호 기능이 없는 건가요?

기본 VLESS에서 encryption=none은 프로토콜 계층에서 페이로드를 암호화하지 않는다는 뜻이지, 연결 전체에 보호 기능이 없다는 뜻은 아닙니다. 노드 상세 정보에서 TLS 또는 REALITY가 서버 요구 사항에 맞게 활성화되어 있는지 확인하세요. 이 항목만으로 판단하지 말고, 보호 계층이 없는 기본 VLESS를 신뢰할 수 없는 네트워크에서 직접 사용하지 마세요.

VMess가 작동하는데 VLESS로 바꾸면 더 빨라지나요?

그대로 바꿀 수는 없습니다. 서버에 VLESS 연결 지점이 있어야 하며 UUID, 포트, 전송 방식, 보안 계층도 모두 일치해야 합니다. 사용 가능한 노드가 두 개라면 같은 기기에서 비슷한 시간대와 같은 대상을 기준으로 여러 번 비교하고, 패킷 손실과 로그도 함께 살펴보세요. 지연 시간을 한 번 비교하는 데 그치면 안 됩니다.

Trojan에서 인증서 오류가 발생하면 검증을 건너뛰어도 되나요?

먼저 노드의 서버 이름이 올바른지, 기기 시간이 맞는지, 인증서가 만료되지 않았는지 확인하세요. IP 주소로 연결하더라도 TLS 서버 이름에는 인증서에 해당하는 도메인을 입력해야 할 수 있습니다. 장기간 검증을 건너뛰면 중요한 서버 신원 확인을 놓치게 되므로 설정이나 서버 인증서를 수정하세요.

Shadowsocks 비밀번호가 맞는데도 연결되지 않는 이유는 무엇인가요?

method, 포트, 키 형식을 함께 확인한 뒤 양쪽 코어가 해당 방식을 지원하는지도 점검하세요. 일반 웹페이지는 열리지만 특정 앱에서 실패한다면 UDP 지원, 라우팅 규칙, 대상 주소 확인도 살펴봐야 합니다. 비밀번호가 같다는 이유만으로 설정 문제를 배제할 수는 없습니다.

프로토콜을 바꾸면 라우팅 규칙도 달라지나요?

프로토콜은 원격 연결 방식을 정하고, 라우팅 규칙은 트래픽을 어느 아웃바운드로 보낼지 결정합니다. 노드를 바꾼 뒤 라우팅에서 참조하는 outboundTag가 여전히 유효한 아웃바운드와 연결되는지 확인하고 같은 대상으로 다시 테스트하세요. 안드로이드에서는 앱별 설정도 확인해 앱의 우회 연결을 노드 장애로 오해하지 않도록 하세요.

선택 순서는 서버가 제공하는 프로토콜을 확인하고, 코어가 필요한 기능을 모두 지원하는지 살핀 다음, 유지 관리 비용과 실제 연결 상태를 비교하는 것입니다. 기존 설정은 호환성을 우선하고, 새 설정은 보안 계층과 인증 요건부터 분명히 정하세요. 프로토콜 이름은 출발점일 뿐이며, 판단할 때는 전체 설정과 실행 로그를 확인해야 합니다.