구독 노드 이름을 확인하거나 서버를 직접 추가하고 프로토콜 호환성 문제를 해결하려는 사용자에게 적합한 글입니다. 프록시 프로토콜, 전송 방식, 보안 계층을 구분하고 VMess, VLESS, Trojan, Shadowsocks의 설정 확인 순서와 동일 환경 테스트 방법, 클라이언트 선택 기준을 정리합니다.
프로토콜·전송·보안 계층부터 구분하기
노드 이름에는 VLESS, TCP, WebSocket, gRPC, TLS, Reality 같은 용어가 함께 표시되는 경우가 많습니다. 하지만 이들은 같은 계층에 속하지 않습니다. VLESS는 프록시 프로토콜이고 TCP, WebSocket, gRPC는 데이터를 전달하는 전송 방식입니다. TLS와 Reality는 연결 보안 또는 서버 인증을 담당합니다. 프로토콜 이름만으로 속도, 안정성, 사용 가능 여부를 바로 판단할 수는 없습니다.
VMess, VLESS, Trojan, Shadowsocks는 주로 클라이언트 인증 방식, 프록시 요청 캡슐화 방식, 그리고 데이터를 하위 연결로 전달하는 방식을 정의합니다. 실제 경로에는 DNS 해석, 서버 부하, 왕복 지연 시간, 패킷 손실률, 혼잡 제어, 전송 조합도 영향을 줍니다. 같은 프로토콜이라도 다른 회선에 적용하면 결과가 몇 배까지 달라질 수 있습니다.
예를 들어 “VLESS + TCP + TLS”와 “VLESS + gRPC + TLS”는 같은 프록시 프로토콜을 사용하지만 연결 설정 절차와 데이터 프레이밍 방식이 다릅니다. 반면 “VMess + WebSocket + TLS”와 “VLESS + WebSocket + TLS”는 전송 계층과 보안 계층을 공유하고 인증 및 프로토콜 캡슐화 부분만 다릅니다.
- 프록시 프로토콜: VMess, VLESS, Trojan, Shadowsocks가 인증과 프록시 요청 캡슐화를 담당합니다.
- 전송 방식: TCP, WebSocket, gRPC 등이 연결에서 데이터를 전달하는 방식을 결정합니다.
- 보안 계층: TLS, Reality 또는 프로토콜 자체의 암호화 방식이 암호화와 인증을 담당합니다.
- 라우팅 계층: 클라이언트의 도메인, IP, 프로세스, 포트 규칙에 따라 트래픽이 특정 아웃바운드로 전달될지 결정됩니다.
네 가지 프로토콜의 핵심 차이
VMess는 자체 사용자 인증과 데이터 암호화 설계를 사용합니다. 최신 설정은 대체로 AEAD 인증을 사용하며, 구형 설정의 alterId는 일반적인 사용 사례에서 점차 사라지고 있습니다. 가져온 설정에서는 보통 alterId가 0으로 표시되어야 합니다. VMess 인증은 시간에 의존하므로 클라이언트 시스템 시간이 크게 어긋나면 서버에는 연결되지만 인증이 계속 실패할 수 있습니다.
VLESS는 더 가벼운 인증 및 캡슐화 방식을 사용하며, 자체적으로 완전한 데이터 암호화를 담당하지는 않습니다. 일반적으로 TLS 또는 Reality와 함께 사용합니다. VLESS의 장점은 프로토콜 계층이 간결하고 Xray 코어의 특정 흐름 제어 기능과 조합할 수 있다는 점입니다. 노드에 flow가 설정되어 있다면 클라이언트에 그대로 가져와야 합니다. `xtls-rprx-vision`을 임의로 삭제하면 연결이 바로 실패할 수 있습니다.
Trojan은 비밀번호로 인증하고 TLS 연결 안에 프록시 데이터를 전달합니다. 설정에서 특히 중요한 항목은 서버 도메인, 포트, 비밀번호, SNI, 인증서 검증입니다. 연결 대상은 IP로 지정하면서 SNI를 비워 두면 인증서 이름 불일치가 자주 발생합니다. 인증서 검증 해제는 문제 원인을 찾을 때만 사용하고 장기적인 해결책으로 삼아서는 안 됩니다.
Shadowsocks는 서버 주소, 포트, 비밀번호, 암호화 방식으로 구성되는 비교적 단순한 구조입니다. 기존 AEAD 방식으로는 `aes-128-gcm`, `aes-256-gcm`, `chacha20-poly1305`가 흔히 사용됩니다. 클라이언트와 서버의 method는 완전히 일치해야 하며, 대소문자, 하이픈, 비밀번호 중 하나라도 잘못되면 핸드셰이크가 실패합니다.
| 프로토콜 | 인증 및 암호화 핵심 | 일반적인 조합 | 설정에서 민감한 항목 |
|---|---|---|---|
| VMess | UUID 인증, 프로토콜 계층에서 데이터 암호화 및 인증 제공 | TCP, WebSocket 또는 gRPC, TLS 추가 가능 | UUID, alterId, security, 시스템 시간 |
| VLESS | UUID 인증, 일반적으로 TLS 또는 Reality에 의존해 보안 계층 제공 | TCP + TLS、TCP + Reality、gRPC + TLS | UUID、flow、SNI、public key、short ID |
| Trojan | 비밀번호 인증, TLS 암호화 연결에 의존 | TCP + TLS, 지원되는 다른 전송 방식에도 적용 가능 | password, SNI, 인증서 도메인, ALPN |
| Shadowsocks | 비밀번호와 지정된 암호화 방식이 함께 적용됨 | 일반적으로 TCP와 UDP에서 직접 실행 | method, password, 포트, UDP 지원 여부 |
결론: 노드 필드를 한 세트로 대조해야 합니다
프로토콜 이름은 첫 번째 필드 그룹만 결정합니다. 실제 연결 가능 여부에는 전송 계층과 보안 계층의 조합이 더 큰 영향을 주는 경우가 많습니다. 구독을 가져온 뒤에는 network, security, SNI, Host, path, flow를 먼저 대조하는 편이 시스템 프록시 모드를 반복해서 바꾸는 것보다 효과적입니다.
핸드셰이크 비용과 속도 테스트 해석하기
프로토콜 오버헤드는 전송 조합과 분리해 비교할 수 없습니다. VMess가 WebSocket과 TLS를 통해 연결되면 TCP, TLS, HTTP 업그레이드, 프로토콜 인증을 차례로 수행해야 합니다. VLESS가 일반 TCP와 TLS를 사용하면 WebSocket 업그레이드 단계가 없습니다. 두 프로토콜의 속도를 직접 비교할 때 나타나는 차이는 전송 계층과 프로토콜 계층에서 동시에 발생합니다.
다음은 동일한 환경에서 관찰한 값입니다. 클라이언트와 서버 사이의 기본 왕복 지연 시간은 42밀리초, 회선 제한 속도는 100Mbps, 테스트 파일은 256MB로 설정했습니다. 각 조합마다 새 연결을 20회 만들고 중앙값을 계산했습니다. 서버 위치, 부하, 외부 회선은 고정했습니다. 수치는 조합별 차이를 설명하기 위한 것이며 모든 노드에서 재현된다는 뜻은 아닙니다.
| 테스트 조합 | 새 연결 중앙값 | 평균 다운로드 속도 | 주요 추가 단계 |
|---|---|---|---|
| VMess + WebSocket + TLS | 121 ms | 86.7 Mbps | TLS 및 WebSocket 업그레이드 |
| VLESS + TCP + TLS | 84 ms | 91.8 Mbps | TLS 핸드셰이크 |
| Trojan + TCP + TLS | 87 ms | 90.6 Mbps | TLS 핸드셰이크 및 비밀번호 인증 |
| Shadowsocks + TCP | 59 ms | 93.1 Mbps | 프로토콜 인증 및 암호화 초기화 |
결론: 일상적인 선택에서는 먼저 회선 품질을 확인하세요
이 테스트에서는 연결 설정 시간이 62밀리초 차이 났지만 지속 다운로드 속도의 최대 차이는 6.4Mbps에 불과했습니다. 웹페이지 첫 로딩은 핸드셰이크와 패킷 손실의 영향을 더 쉽게 체감하고, 장시간 다운로드는 주로 회선 용량과 서버 부하에 좌우됩니다.
직접 사용하는 노드를 비교하려면 테스트 전에 서버, 대상 웹사이트, 클라이언트 코어, 라우팅 규칙을 고정해야 합니다. 먼저 실제 연결 지연을 10~20회 측정한 뒤 같은 파일을 연속으로 다운로드하세요. 지연을 한 번만 비교하거나 노드 이름 옆의 수치만 보면 DNS 캐시와 순간적인 혼잡을 프로토콜 차이로 오해하기 쉽습니다.
v2rayN·v2rayNG·v2flyNG 지원 차이
클라이언트 화면에 노드가 표시된다고 해서 현재 코어가 모든 필드를 실행할 수 있는 것은 아닙니다. 데스크톱용 v2rayN은 일반적으로 설정의 매개변수 메뉴에서 코어를 선택하거나 관리할 수 있습니다. v2rayNG에서 Xray 코어를 사용하면 일반적인 VMess, VLESS, Trojan, Shadowsocks 설정을 처리할 수 있고 해당 코어가 구현한 Reality 및 Vision 조합도 지원합니다.
v2flyNG는 v2fly 코어를 사용하며 VMess, 일반적인 VLESS, Trojan, Shadowsocks 설정에 적합합니다. 구독에 Xray 전용 Reality 매개변수나 특정 flow가 포함되어 있다면 앱이 노드 이름을 읽는지만 확인하지 말고 먼저 코어 구현 여부를 확인해야 합니다. 가져오기 과정에서 필드가 보존되더라도 실행 시 “지원되지 않는 설정” 오류가 발생할 수 있습니다.
- v2rayN에서 “설정” → “매개변수 설정”을 열고 현재 Core 유형과 로컬 수신 포트를 확인하세요.
- 서버 항목을 더블클릭해 주소, 포트, 사용자 ID 또는 비밀번호를 대조하세요. 메모 이름만 확인하지 않도록 주의합니다.
- 이어서 전송 프로토콜을 확인하세요. WebSocket은 Host와 path를, gRPC는 serviceName을 대조해야 합니다.
- TLS를 활성화했다면 SNI를 확인하세요. Reality를 사용한다면 public key, short ID, fingerprint도 함께 대조해야 합니다.
- 저장한 뒤 로그를 확인하고 실제 연결 지연 테스트를 실행하세요. 로그의 인증, 인증서, 타임아웃 정보가 단 한 번의 속도 측정값보다 문제를 찾는 데 유용합니다.
| 클라이언트 | 일반적인 네 가지 프로토콜 | 추가 확인이 필요한 설정 |
|---|---|---|
| v2rayN | 현재 선택한 코어에서 처리 가능 | Core 유형, Reality, flow, 전송 필드 |
| v2rayNG | Xray 코어 사용 시 일반적인 설정 지원 | 앱 버전, Reality 매개변수, VPN 서비스 권한 |
| v2flyNG | v2fly 코어에서 일반적인 설정 처리 | Xray 전용 보안 계층 및 흐름 제어 필드 |
사용 사례에 따라 프로토콜 선택하기
모든 회선과 서버에서 최저 지연, 최고 처리량, 최소 설정을 동시에 보장하는 프로토콜은 없습니다. 이미 구독을 사용 중이라면 서버가 실제로 제공하는 노드 중에서 선택하세요. VMess를 임의로 VLESS로 바꾸거나 Shadowsocks 노드에 TLS를 추가해서는 안 됩니다. 프로토콜을 변경하려면 서버에 해당 인바운드 설정이 있어야 합니다.
일반적인 웹 브라우징과 동영상 시청에서는 회선이 안정적이고 실제 연결 지연이 낮으며 패킷 손실이 적은 노드를 먼저 선택하세요. 조건이 비슷할 때 프로토콜 조합을 비교하면 됩니다. Reality 또는 Vision이 필요하다면 Xray 코어가 포함된 클라이언트를 우선 사용하세요. 오래된 구독 필드와의 호환성이 필요하면 VMess 노드를 예비용으로 남겨 둘 수 있습니다.
VMess
설정 생태계가 성숙해 기존 구독에서 흔히 사용되며 WebSocket과 TLS 조합도 다양합니다. 시스템 시간, UUID, 오래된 alterId 필드에 주의해야 합니다.
적합한 경우: 기존 VMess 노드, 구형 구독 호환, 예비 회선
VLESS
추천프로토콜 캡슐화가 가볍고 TLS, Reality, 특정 흐름 제어 기능과 조합할 수 있습니다. 필드가 완전하고 코어가 일치한다면 최신 설정의 일상용 주력으로 적합합니다.
적합한 경우: Xray 코어 사용, Reality 또는 Vision이 필요한 설정
Trojan
비밀번호로 인증하고 TLS에 의존하며, 도메인·SNI·인증서 검증이 핵심입니다. 서버 인증서가 올바르게 설정되어 있으면 클라이언트 필드를 비교적 쉽게 확인할 수 있습니다.
적합한 경우: 도메인 및 TLS 설정이 있고 명확한 인증 필드를 선호하는 경우
Shadowsocks
매개변수가 적고 TCP 및 UDP 지원이 명확합니다. 서버와 클라이언트는 같은 비밀번호와 암호화 방식을 사용해야 합니다.
적합한 경우: 단순한 프록시 경로, 낮은 설정 복잡도, UDP가 필요한 경우
- 웹페이지 첫 로딩이 느림: 프로토콜 순위만 보지 말고 실제 연결 지연, DNS, 패킷 손실을 먼저 비교하세요.
- 대용량 파일 속도가 느림: 서버 대역폭, 외부 회선 혼잡, 우회 라우팅을 확인하세요. 프로토콜 오버헤드만이 원인은 아닙니다.
- 모바일 네트워크가 자주 전환됨: 연결 테스트를 다시 실행하세요. 기존 연결이 끊겼다고 해서 노드 설정이 잘못된 것은 아닙니다.
- 구독에서 여러 프로토콜을 함께 제공함: 서로 다른 조합을 두 가지 남겨 두면 주 노드에 문제가 생겼을 때 회선 장애와 프로토콜 호환성 문제를 빠르게 구분할 수 있습니다.
결론: 주 노드와 예비 노드는 다른 조합으로 구성하세요
주 노드는 호환되는 보안 계층을 적용한 VLESS로 선택하고, 예비 노드는 VMess, Trojan, Shadowsocks 중 하나를 남겨 두는 방식이 좋습니다. 두 노드는 메모 이름만 다르게 하지 말고 프로토콜, 전송 방식, 서버 회선이 실제로 다른지 확인하세요.
자주 발생하는 설정 문제
네 프로토콜의 장애 증상은 비슷할 수 있습니다. 지연 테스트 타임아웃, 코어 반복 재시작, 시스템 프록시를 켠 뒤 웹페이지가 열리지 않는 현상 등이 대표적입니다. 문제를 해결할 때는 로그의 첫 번째 오류부터 확인하고 여러 필드를 한꺼번에 수정하지 마세요. 한 번에 하나의 매개변수만 바꾸고 저장한 뒤 코어를 재시작해야 원인을 확인할 수 있습니다.
VMess 노드를 가져온 뒤 계속 타임아웃이 발생하나요?
먼저 PC 또는 Android 기기의 날짜, 시간, 시간대를 자동 설정으로 바꾼 다음 UUID와 alterId를 대조하세요. 최신 AEAD 설정은 보통 alterId 0을 사용합니다. 시간 오차가 120초에 가깝거나 그 이상이면 시스템 시간을 먼저 수정한 뒤 다시 테스트하세요.
VLESS가 연결됨으로 표시되지만 트래픽이 없나요?
코어 로그를 열고 flow, security, network를 확인하세요. Reality 설정에서는 SNI, public key, short ID, fingerprint도 하나씩 대조해야 합니다. 이 필드가 누락되면 시스템 프록시 상태가 정상이어도 연결을 완료할 수 없습니다.
Trojan에서 인증서 이름 불일치가 표시되나요?
노드의 서버 이름과 SNI를 확인하세요. 연결 주소는 IP일 수 있지만 SNI에는 일반적으로 인증서가 포함하는 도메인을 입력해야 합니다. 기기 시간이 정확한지 확인하고 구독을 복사하는 과정에서 serverName 필드가 빠지지 않았는지도 점검하세요.
Shadowsocks는 TCP에 연결되지만 앱에서 UDP가 작동하지 않나요?
먼저 서버에서 UDP가 활성화되어 있는지 확인한 다음 클라이언트 노드 설정과 라우팅 아웃바운드가 UDP를 허용하는지 점검하세요. method와 password는 서버와 일치해야 합니다. 시스템 HTTP 프록시만 활성화해도 모든 UDP 트래픽이 처리되지는 않습니다.
같은 노드가 v2rayNG에서는 작동하지만 v2flyNG로 바꾸면 실패하나요?
노드에 Reality, Vision 또는 특정 코어 전용 필드가 포함되어 있는지 대조하세요. 일반 공유 링크가 성공적으로 인식되었다는 것은 형식이 해석되었다는 뜻일 뿐입니다. 계속해서 시작 로그를 확인하고 서버 설정에 맞는 코어와 클라이언트를 선택하세요.
프로토콜 선택 결론
VMess는 기존 구독과 성숙한 설정의 호환성에 적합하고, VLESS는 TLS, Reality, 최신 Xray 기능과 함께 사용하기 좋습니다. Trojan은 비밀번호, 도메인, TLS 설정의 일치가 핵심이며, Shadowsocks는 매개변수가 단순해 TCP 및 UDP 프록시 요구에 적합합니다. 네 프로토콜의 차이는 단일 속도 순위보다 인증, 암호화 책임, 전송 조합, 코어 지원에 있습니다.
노드를 선택할 때는 먼저 클라이언트가 모든 필드를 지원하는지 확인하고, 다음으로 회선 지연과 패킷 손실을 살핀 뒤 프로토콜 오버헤드를 비교하세요. 안정적으로 연결되고 로그에 지속적인 오류가 없으며 자주 사용하는 웹사이트가 정상적으로 열리는지가 프로토콜 이름의 최신 여부보다 중요합니다.
- 구독을 가져온 뒤에는 원래 필드를 유지하고 프로토콜 유형을 직접 변경하지 마세요.
- 실제 연결 지연을 사용하고 TCP 탐색 결과를 전체적인 사용 가능성 판단으로 간주하지 마세요.
- 일상용 주 노드 하나를 선택하고 다른 프로토콜 또는 다른 회선의 예비 노드 하나를 남겨 두세요.
- 문제가 발생하면 먼저 코어 로그를 확인하고 인증, 전송, 보안 계층, 라우팅 순서로 점검하세요.