프록시 프로토콜, 전송 방식, 보안 계층을 구분한 뒤 서버 설정과 클라이언트 코어를 확인하세요. 구독 노드를 선택하거나 데스크톱·Android 설정을 옮기려는 사용자, 직접 서버를 구축하려는 사용자에게 유용한 글입니다. VMess, VLESS, Trojan, Shadowsocks가 각각 어떤 설정값을 사용하는지, 서로 바꿔 쓸 수 없는 조합은 무엇인지, 연결에 실패했을 때 어느 계층부터 점검해야 하는지 알아봅니다.
1. 프록시 프로토콜·전송 방식·보안 계층은 서로 다릅니다
VMess, VLESS, Trojan, Shadowsocks는 클라이언트와 프록시 서버가 요청을 인증하고 캡슐화해 전달하는 방식을 정합니다. TCP, WebSocket, gRPC는 연결 또는 전송 방식이고, TLS와 REALITY는 보안 메커니즘입니다. 노드 이름에는 여러 계층의 정보가 함께 표시되는 경우가 많으므로, 프로토콜 이름만 보고 전체 설정을 판단해서는 안 됩니다.
예를 들어 VLESS + WebSocket + TLS와 VLESS + TCP + REALITY는 모두 VLESS를 사용하지만 서버의 접속 지점, 핸드셰이크 매개변수, 중간 네트워크 요구 사항이 다릅니다. 첫 번째 노드의 전송 방식을 TCP로 바꾼다고 두 번째 노드가 되는 것은 아닙니다. 서버에서 해당 방식으로 수신 대기하지 않으면 클라이언트 연결은 실패합니다.
- 프록시 프로토콜: UUID, 비밀번호 또는 특정 키 정보를 어떻게 사용하는지, 요청을 어떤 형식으로 캡슐화하는지 정합니다.
- 전송 방식: 스트림 연결을 직접 만들지, WebSocket이나 gRPC 등을 전송 계층으로 사용할지 정합니다. 사용할 수 있는 조합은 코어와 서버 구현에 따라 달라집니다.
- 보안 계층: 연결을 보호하고 서버 신원을 확인하는 방식을 정합니다. TLS를 사용할 때는 서버 이름과 신뢰할 수 있는 인증서를 올바르게 설정해야 합니다.
- 라우팅 및 트래픽 가로채기: 시스템 프록시, TUN, 도메인별 분기는 클라이언트의 트래픽 유입 경로와 출구 선택에 해당하며, 네 가지 프로토콜 자체의 속성은 아닙니다.
2. 네 가지 프로토콜의 암호화 및 설정 차이
암호화 방식을 비교할 때는 두 가지를 함께 확인해야 합니다. 프록시 프로토콜 자체가 데이터를 암호화하는지, 바깥 계층에서 TLS 같은 보호 기능을 추가하는지입니다. 특정 필드에 none이라고 표시되어도 연결 전체가 암호화되지 않는다는 뜻은 아닙니다. 반대로 포트가 443이라고 해서 TLS가 활성화된 것도 아닙니다.
| 프로토콜 | 인증 및 암호화 | 일반적인 조합 | 주요 확인 항목 |
|---|---|---|---|
| VMess | UUID로 사용자를 식별합니다. 최신 설정은 VMess AEAD를 사용하며, 데이터 암호화 여부는 security 설정에 따라 달라집니다. | TCP;WebSocket + TLS | UUID, security, alterId, 전송 방식, 보안 계층, 시스템 시간 |
| VLESS | UUID로 사용자를 식별합니다. 프로토콜 자체는 데이터 암호화를 담당하지 않습니다. | TCP + TLS; WebSocket + TLS; Xray의 TCP + REALITY | UUID, encryption, flow, TLS 또는 REALITY 설정 |
| Trojan | 비밀번호로 인증합니다. 일반적인 구성에서는 TLS로 연결을 보호합니다. | TCP + TLS. 다른 전송 방식은 양쪽 구현이 모두 지원해야 합니다. | 비밀번호, 포트, 서버 이름, 인증서 검증, 전송 방식 |
| Shadowsocks | method와 비밀번호 또는 키 정보를 이용해 암호화합니다. AEAD와 2022 계열은 요구 사항이 다릅니다. | 기본 TCP 및 UDP 전달. 추가 전송 방식은 별도 지원이 필요합니다. | method, 비밀번호 또는 키 형식, 포트, UDP 지원 여부 |
VMess: AEAD와 이전 설정 필드 확인
최신 VMess 설정에서는 보통 AEAD 방식으로 alterId: 0을 사용합니다. 이전 튜토리얼의 0이 아닌 alterId를 현재 설정에 그대로 적용하지 마세요. VMess 인증에는 시간도 중요합니다. Windows나 Android의 시스템 시간이 크게 어긋났다면 UUID가 잘못된 것인지 판단하기 전에 자동 시간 설정부터 켜세요. TLS를 추가로 사용할지는 서버 구성을 따릅니다.
VLESS: 데이터 암호화 기능이 내장되지 않았다고 해서 평문으로 사용해도 되는 것은 아닙니다
VLESS의 encryption: "none"은 일반적인 설정값이며, 연결 보호는 TLS나 REALITY 같은 메커니즘이 담당합니다. 일반적인 공용 네트워크 환경에서는 “VLESS는 오버헤드가 적다”는 이유만으로 보안 계층을 제거해서는 안 됩니다. xtls-rprx-vision은 특정 조합에서 사용하는 flow 값입니다. 모든 WebSocket 노드에 그대로 적용하거나 클라이언트에서만 활성화하면 안 됩니다.
Trojan과 Shadowsocks: 비밀번호 외에도 맞춰야 할 설정이 있습니다
Trojan은 비밀번호가 맞더라도 TLS 서버 이름이 잘못되면 인증에 도달하기 전에 핸드셰이크가 실패할 수 있습니다. Shadowsocks는 암호화 방식을 정확히 맞춰야 합니다. aes-128-gcm과 2022-blake3-aes-128-gcm은 서로 바꿔 쓸 수 있는 이름이 아닙니다. 후자는 키 형식에 대한 구체적인 요구 사항이 있으므로 일반 비밀번호를 임의로 입력해서는 안 됩니다.
결론: 먼저 보안 계층을 확인한 뒤 프로토콜을 비교하세요
노드 편집 화면에서 TLS 또는 REALITY 설정과 인증서 검증 상태를 확인하세요. VLESS의 encryption이 none이라고 보안 계층을 끄지 마세요. Trojan 문제를 장기적으로 해결하기 위해 인증서 검증을 비활성화하는 것도 바람직하지 않습니다.
3. 속도 순위 대신 사용 환경에 맞춰 선택하세요
구독을 사용하는 경우 선택할 수 있는 범위는 우선 서비스 제공자가 정합니다. 서로 다른 프로토콜의 노드가 서버, 회선, 부하, 출구까지 다르다면 속도 측정 결과만으로 특정 프로토콜이 전반적으로 더 빠르다고 볼 수 없습니다. 직접 서버를 구축한다면 인증서, 도메인, 네트워크 접속 조건부터 정한 다음 전송 조합을 선택하세요.
VLESS: 새 Xray 설정 구축
추천서버와 클라이언트가 모두 지원한다는 전제에서 배포 환경에 맞춰 TLS 또는 REALITY를 선택하세요. UUID, 보안 설정, flow를 먼저 확인하고, 설정값이 적다는 이유로 보안 계층을 생략하지 마세요. 이 추천은 서버를 직접 관리할 수 있는 새 설정에 한정됩니다.
적합한 경우: Xray 사용, 서버 관리 가능, 연결 매개변수를 직접 관리할 수 있는 환경
VMess: 검증된 기존 노드 유지
기존 VMess AEAD 노드가 안정적으로 연결되고 데스크톱과 Android에서 모두 가져올 수 있다면 계속 사용해도 됩니다. 프로토콜을 바꾸기 전에 이전 설정 필드와 시간 설정을 확인하세요. 프로토콜 이름을 바꾸기 위해 서버를 새로 구축할 필요는 없습니다.
적합한 경우: 기존 구독 사용, WebSocket + TLS 구성 보유, 기존 설정과의 호환성 필요
Trojan: 도메인과 인증서를 이미 보유한 경우
일반적인 TCP + TLS 구성은 설정 구조가 비교적 단순하지만 인증서 유효 기간, 도메인 DNS, 서버 이름을 계속 관리해야 합니다. 비밀번호뿐 아니라 TLS 핸드셰이크 경로도 점검해야 합니다.
적합한 경우: 인증서를 관리할 수 있고 서버에서 Trojan 접속 지점을 제공하는 환경
Shadowsocks: 명확한 암호화 전달 요구 사항
기본 연결에서는 확인할 설정 필드가 비교적 적으며, method, 키, 포트가 핵심입니다. UDP가 필요하다면 서버 전달 설정과 네트워크 허용 여부를 별도로 확인하세요. 웹페이지가 열린다는 사실만으로 UDP를 사용할 수 있다고 판단할 수 없습니다.
적합한 경우: 설정이 일치하는 서버를 보유하고 기본 TCP/UDP 전달 구조를 유지하려는 환경
네 가지 프로토콜 중 어느 것도 익명성을 완벽하게 보장하지 않습니다. 서버 운영 방식, DNS 경로, 앱의 로그인 상태, 클라이언트의 트래픽 분기 설정도 실제 사용 결과에 영향을 줍니다. 프로토콜 이름만 보고 모든 보안 특성을 추정하지 말고 배포 조건을 기록하세요.
4. v2rayN, v2rayNG, v2flyNG의 지원 범위
v2rayN은 데스크톱 클라이언트이고, v2rayNG는 Xray 코어를 사용하는 Android 클라이언트이며, v2flyNG는 v2fly 코어를 사용합니다. 클라이언트는 노드를 관리하고 설정을 생성하며, 실제 프로토콜 처리는 코어가 담당합니다. 구독 항목을 인식한다고 해서 현재 코어가 모든 확장 매개변수를 지원하는 것은 아닙니다.
| 클라이언트 | 확인 위치 | 선택 시 유의 사항 |
|---|---|---|
| v2rayN | 노드 편집 창의 프로토콜, 전송 방식, 보안 설정 및 시작 로그의 코어 정보 | 데스크톱에서 실제로 선택한 코어를 기준으로 확인하세요. VLESS + REALITY는 Xray 지원 여부와 매개변수를 점검해야 합니다. |
| v2rayNG | 노드를 길게 눌러 편집하세요. 로그 화면에서 시작 오류를 확인할 수 있습니다. | 네 가지 기본 프로토콜은 해당 설정에 맞춰 사용할 수 있습니다. 최신 확장 기능 지원 여부는 앱에 포함된 Xray 버전에 따라 달라집니다. |
| v2flyNG | 노드 편집 화면, 앱 버전, 시작 로그 | v2fly 코어의 실제 지원 범위를 따르세요. Xray 전용 REALITY 및 Vision 설정을 그대로 가져올 수 없습니다. |
마이그레이션 방법: 먼저 프로토콜 계열을 확인하고 확장 필드를 점검하세요
데스크톱: v2rayN
- 가져온 뒤 노드 편집 창에서 주소, 포트, 전송 방식, 보안 계층을 확인합니다.
- REALITY를 사용하는 경우 공개 키, shortId, 서버 이름, 지문 설정을 확인합니다.
- 시작 후 코어 로그를 확인하고, 웹페이지를 테스트하기 전에 설정 파싱 오류부터 해결합니다.
Android: v2rayNG 또는 v2flyNG
- 앱 화면에 표시된 프로토콜 이름만 비교하지 말고 서버 설정과 일치하는 코어를 사용합니다.
- v2flyNG로 옮기기 전에 Xray 전용 확장 기능이 포함되어 있는지 확인합니다.
- 시스템 VPN 권한과 앱별 설정을 점검해 트래픽 유입 문제를 프로토콜 문제로 오인하지 않도록 합니다.
구독 주소를 공유하면 반복 입력을 줄일 수 있지만, 두 기기에서 같은 노드를 사용할 수 있는지는 각 코어의 지원 여부에 달려 있습니다. 구독 업데이트도 각 기기에서 따로 실행해야 합니다.
5. 포트와 로그로 연결 실패 지점 구분하기
아래 세 숫자는 서로 다른 계층에서 포트가 어떻게 쓰이는지 보여주는 예시이며, 모든 클라이언트의 기본값이나 필수 배포값이 아닙니다. 서버 인바운드 포트와 로컬 프록시 수신 포트는 연결의 양쪽 끝에 해당하므로 서로 대신 사용할 수 없습니다. 입력하기 전에 노드 설정과 실제 로컬 수신 포트를 확인하세요.
- 먼저 코어가 시작되는지 확인하세요. 로그에 설정 파싱 실패, 알 수 없는 필드, 포트 충돌이 표시되면 우선 설정을 수정하세요. 이 단계에서는 프로토콜 속도를 측정해도 의미가 없습니다.
- 다음으로 앱이 트래픽을 전달하는지 확인하세요. 데스크톱에서는 시스템 프록시가 실제 수신 포트를 가리키는지 확인합니다. Android에서는 VPN이 연결되었는지, 대상 앱이 제외되지 않았는지 확인하세요.
- 서버에 연결할 수 있는지 확인하세요. 연결 시간이 초과되면 주소, 인바운드 포트, 방화벽, 서비스 실행 상태를 먼저 점검합니다. 시간 초과만으로 UUID가 잘못됐다고 단정할 수 없습니다.
- 보안 핸드셰이크와 사용자 인증 오류를 구분하세요. 인증서 오류가 발생하면 기기 시간, 서버 이름, 인증서 체인을 먼저 확인합니다. 인증 오류가 발생하면 UUID, 비밀번호, 키, 암호화 방식을 점검하세요.
- 마지막으로 전송 매개변수를 확인하세요. WebSocket은 path와 Host를, gRPC는 serviceName을 확인합니다. REALITY는 서버에서 제공한 공개 키와 shortId 등의 필드를 점검하세요.
예를 들어 로컬 SOCKS 수신 주소가 127.0.0.1:10808로 확인되면 아래 명령으로 클라이언트를 통해 요청이 전달되는지 테스트할 수 있습니다. 여기서는 구독 인증 정보가 필요 없는 도메인 테스트 페이지를 사용합니다. 실제 포트가 다르면 해당 값을 사용하세요.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://example.com/
socks5h는 대상 도메인 처리를 SOCKS 프록시에 맡긴다는 뜻입니다. 이 테스트는 시스템 프록시 설정을 우회하지만 코어의 라우팅 규칙까지 우회하지는 않습니다. 해당 도메인이 직접 연결 규칙에 걸리면 요청이 성공하더라도 원격 프록시 출구가 정상이라는 뜻은 아닙니다. 로그에서 적용된 규칙과 출구를 함께 확인한 뒤 판단하세요.
6. 성능 비교에서 일치시켜야 할 조건
서로 다른 회선에서는 지연 시간, 혼잡, 패킷 손실, 서버 부하가 프로토콜 캡슐화 방식의 차이보다 더 큰 영향을 주는 경우가 많습니다. VMess, VLESS, Trojan, Shadowsocks라는 이름만으로 처리량을 비교할 수는 없습니다. 하드웨어의 암호화 가속 지원 여부, 추가 전송 방식 사용 여부, 테스트 트래픽이 같은 출구를 통과하는지도 결과에 영향을 줍니다.
- 같은 기기와 네트워크 사용: 데스크톱의 유선 네트워크 결과와 Android의 모바일 네트워크 결과를 직접 비교하지 마세요.
- 같은 서버와 출구 사용: 가능한 한 프로토콜 조합만 바꾸고 지역, 대역폭, 테스트 대상은 동일하게 유지하세요.
- 같은 시간대에 테스트: 각 조합을 최소 3회 반복하고 연결 시간, 지속 전송 속도, 실패 횟수를 각각 기록하세요.
- TCP와 UDP를 각각 확인: 웹페이지가 정상적으로 열려도 UDP 전달이 확인된 것은 아닙니다.
- 전체 조합 이름 기록: “VLESS + TCP + REALITY”처럼 적으세요. “VLESS”만 기록하면 중요한 조건이 빠집니다.
결론: 안정적인 조합을 유지하고 변수를 하나씩 테스트하세요
복구할 수 있도록 설정을 먼저 내보내고, 서버가 지원하는 옵션 하나만 바꿔가며 테스트하세요. 같은 출구를 사용했다는 점을 로그로 확인하고 테스트 결과가 3회 연속 개선되면 일상적으로 사용하는 노드 교체를 고려하세요.
7. 프로토콜 선택 FAQ
VLESS의 encryption이 none인데 AES로 직접 바꿔야 하나요?
그럴 필요 없습니다. VLESS의 이 필드는 VMess나 Shadowsocks의 암호화 방식 선택 항목이 아닙니다. 노드 편집 화면에서 서버 요구 사항에 맞게 TLS 또는 REALITY 보안 계층이 설정되어 있는지, 관련 매개변수가 올바른지 확인하세요. encryption에 다른 프로토콜의 알고리즘 이름을 입력하지 마세요.
Trojan에서 443 포트를 사용하는데 인증서 오류가 발생하는 이유는 무엇인가요?
포트는 서버 신원을 검증하지 않습니다. 먼저 기기의 자동 시간 설정을 켠 다음 TLS 서버 이름이 서버 인증서에 포함된 도메인과 일치하는지 확인하고, 인증서가 만료되지 않았는지와 인증서 체인이 완전한지 점검하세요. 연결 주소와 서버 이름은 달라도 되지만, 서버 이름은 배포 요구 사항에 맞아야 합니다. 장기간 인증을 끈 상태로 사용해서는 안 됩니다.
같은 구독이 v2rayNG에서는 작동하지만 v2flyNG에서는 작동하지 않으면 어떻게 해야 하나요?
먼저 해당 노드의 편집 화면에서 REALITY 또는 xtls-rprx-vision이 포함되어 있는지 확인하세요. 이러한 Xray 확장 기능은 일반적인 VLESS 매개변수처럼 다른 코어로 옮길 수 없습니다. 서버에서 별도로 제공하는 호환 노드를 선택하거나 해당 설정을 지원하는 코어를 사용하세요. 서버에서 필요한 설정일 수 있으므로 오류가 난 필드만 삭제하지 마세요.
Shadowsocks로 웹페이지는 열리는데 게임 트래픽이 실패합니다. 프로토콜을 잘못 선택한 건가요?
먼저 게임이 UDP를 사용하는지 확인한 다음 서버의 UDP 전달 활성화 여부, 방화벽에서 해당 포트가 허용되는지, 클라이언트의 트래픽 가로채기 설정이 게임을 포함하는지 확인하세요. TCP 웹페이지 접속 성공은 UDP 테스트를 대신할 수 없습니다. 이 조건을 확인한 뒤에야 다른 서버에서 제공하는 프로토콜 조합을 비교하세요.
기존 VMess 노드가 안정적으로 작동하는데 모두 VLESS로 바꿔야 하나요?
프로토콜 이름만을 이유로 바꿀 필요는 없습니다. 기존 설정이 최신 AEAD 방식인지, 시스템 시간이 정확한지, 보안 설정이 배포 요구 사항에 맞는지 먼저 확인하세요. 새 기능이나 유지 관리 때문에 변경이 필요하다면 기존 노드를 덮어쓰지 말고, 조건에 맞는 VLESS 서버 설정을 추가해 테스트를 마친 뒤 옮기세요.