어떤 프록시 프로토콜을 써야 할까? Shadowsocks / VMess / Trojan / Hysteria2 완전 비교
노드 이름 뒤에 프로토콜 이름이 붙어 있는 경우가 많지만, 자신의 구독이 실제로 어떤 프로토콜을 쓰는지, 서로 무엇이 다른지 제대로 파악하지 못한 사람이 많습니다. 이 글은 암호화 방식, 검열 우회 능력, 속도라는 세 가지 축으로 나눠 비교하며, "같은 제공업체가 왜 여러 프로토콜의 노드를 동시에 제공하는지"를 이해하는 데 도움을 줍니다.
왜 이렇게 많은 프로토콜이 있을까
본질적으로 모든 프록시 프로토콜이 해결하려는 문제는 동일합니다: 네트워크 트래픽을 암호화하고 위장해 서버로 보낸 뒤 다시 전달하되, 최대한 "프록시 트래픽"으로 식별되지 않도록 하는 것입니다.
하지만 검열 기술도 계속 발전하면서 초기 프로토콜의 암호화 특징이 점점 식별되었고, 이에 커뮤니티는 트래픽 패턴 식별에 대항하는 새로운 프로토콜을 계속 설계해왔습니다. 이것이 Shadowsocks에서 Hysteria2로 이어지는 발전 과정입니다. 이 "군비 경쟁" 같은 배경을 이해하면 왜 어떤 프로토콜도 "영원히 최고"일 수 없는지 알 수 있습니다.
Shadowsocks (SS): 오래된 경량 프로토콜
가장 먼저 널리 퍼진 암호화 프록시 프로토콜로, 단순하고 빠르며 구현 비용이 낮은 것을 목표로 설계되어 거의 모든 클라이언트와 플랫폼에서 네이티브로 지원됩니다.
장점
- 프로토콜 자체가 매우 경량이라 암복호화 오버헤드가 적고 빠름
- 생태계가 가장 성숙해 서버/클라이언트 구현이 가장 많음
- 설정이 간단함:
비밀번호 + 암호화 방식 + 포트만 있으면 됨
단점
- 트래픽 특징이 비교적 고정적이어서 검열이 엄격한 네트워크에서는 식별되기 쉬움
- 자체적으로 트래픽 위장 기능은 없음(단,
obfs플러그인과 결합해 난독화는 가능)
네트워크 검열 압박이 크지 않고 속도와 안정성을 중시한다면 Shadowsocks는 여전히 가성비가 뛰어난 선택입니다.
VMess: V2Ray 생태계의 핵심 프로토콜
V2Ray 프로젝트에서 제안한 프로토콜로, Shadowsocks를 기반으로 신원 검증(UUID)과 더 유연한 전송 계층 래핑 기능을 추가했습니다. WebSocket, gRPC 등 다양한 전송 방식에 얹은 뒤 TLS 암호화를 더 씌워 정상적인 HTTPS 웹사이트 트래픽처럼 위장할 수 있습니다.
VMess 자체는 "내부 프로토콜"이며, 실제 검열 우회 능력은 외부 전송 방식의 선택에 크게 의존합니다 — 같은 VMess라도 맨 TCP로 실행할 때와 WebSocket + TLS를 씌웠을 때는 동작이 크게 다릅니다.
단점은 설정 항목이 비교적 많다는 점입니다(전송 방식, 경로, TLS 도메인 등을 모두 맞춰야 함). 실수할 확률도 높아지지만, 시간을 들여 설정을 맞추고 더 강한 식별 회피 능력을 원하는 경우에 적합합니다.
Trojan: HTTPS로 위장하는 프로토콜
Trojan의 설계 방식은 더 "적극적"입니다: 자신을 표준 HTTPS 서비스로 직접 위장하며, TLS 핸드셰이크와 인증서 모두 실제로 유효합니다. 트래픽 특징이 정상적인 웹사이트 접속과 거의 구별되지 않아, 검열 시스템이 트래픽 패턴만으로 일반 웹사이트 접속과 구분하기 매우 어렵습니다.
- 실제 도메인과 유효한 인증서가 필요함(Let's Encrypt 무료 인증서로 충분)
- 프로토콜 자체 설계가 단순해 VMess의 복잡한 전송 래핑보다 성능 오버헤드가 적음
- "그냥 웹사이트처럼 보이기" 때문에 많은 상황에서 검열 우회 성능이 우수함
사용자 입장에서 Trojan 노드의 설정은 보통 VMess보다 간단합니다 — 복잡함의 대부분이 서버 구축 단계에 있고, 클라이언트 쪽은 주소, 비밀번호, 도메인 몇 가지만 필요합니다.
Hysteria2: QUIC 기반의 차세대 프로토콜
앞서 소개한 프로토콜들은 대부분 TCP 기반이지만, Hysteria2는 QUIC(UDP) 기반으로 만들어진 차세대 프로토콜로, 두 가지 문제 해결에 집중합니다: 불안정하거나 패킷 손실이 많은 환경에서의 저항력, 그리고 더 적극적인 혼잡 제어로 얻는 속도 향상입니다.
| 특성 | 기존 TCP 계열 프로토콜 | Hysteria2 |
|---|---|---|
| 전송 계층 | TCP | QUIC (UDP) |
| 불안정한 네트워크에서의 성능 | 패킷 손실 시 재전송 비용이 높아 끊김이 잦음 | 혼잡 제어 최적화가 내장되어 불안정한 환경에서도 더 매끄러움 |
| 흔한 제약 | 속도 제한을 거의 받지 않음 | 일부 네트워크는 UDP에 속도 제한 정책이 있어 주의 필요 |
사용 중인 네트워크가 UDP에 친화적이지 않다면(일부 공공 Wi-Fi나 기업 네트워크는 UDP를 제한함) Hysteria2의 속도 장점이 제대로 발휘되지 않을 수 있습니다. 이 경우 TCP 계열 프로토콜로 되돌리는 것이 오히려 더 안정적입니다.
난독화와 이중 암호화: 프로토콜에 한 겹 더 위장 씌우기
프로토콜 자체의 설계 외에도, 많은 구현체는 외부에 난독화나 암호화를 한 겹 더 씌워 식별될 확률을 추가로 낮추는 것을 지원합니다:
obfs 난독화 플러그인
- 주로 Shadowsocks와 함께 사용되어, 트래픽을 일반적인 HTTP/TLS 핸드셰이크처럼 보이게 포장함
- 처리 오버헤드가 추가되지만, 단순한 트래픽 식별 규칙에 걸릴 확률을 효과적으로 낮춤
REALITY / XTLS
- 더 최신의 검열 우회 방식으로, 실제 웹사이트의 TLS 인증서 핸드셰이크 과정을 빌려 위장해 그 사이트에 대한 정상 접속과 거의 구별되지 않음
- 서버 측 설정 요구사항이 더 높지만, 현재 커뮤니티 평가에서는 식별 회피 능력이 대체로 강한 것으로 평가됨
이런 "프로토콜 + 난독화" 조합은 보통 구독 제공업체가 서버 측에서 미리 설정해 둡니다. 일반 사용자는 "REALITY나 XTLS 같은 이름을 보면 대체로 기존 프로토콜에 추가적인 검열 우회 강화가 적용된 것"이라고만 알면 충분하며, 직접 설정할 필요는 없습니다.
어떻게 골라야 할까: 3가지 실용적인 판단 기준
- 먼저 구독에 실제로 어떤 것이 제공되는지 확인 — 프로토콜은 제공업체가 결정하므로 대부분의 경우 당신은 "프로토콜을 선택"하는 게 아니라 "노드를 선택"할 뿐입니다. 너무 고민할 필요는 없습니다.
- 속도 우선이고 네트워크가 UDP에 친화적인 경우: Hysteria2를 선택. 속도 우선이지만 UDP가 제한된 경우: Shadowsocks가 가장 무난함.
- 검열 압박이 큰 네트워크 환경: Trojan이나 TLS를 씌운 VMess를 우선 선택해 속도를 조금 희생하고 더 강한 검열 우회 능력을 확보.
Clash 설정에서는 서로 다른 프로토콜의 노드를 같은 proxy-groups에 섞어 넣을 수 있으며, url-test 자동 속도 측정과 결합하면 클라이언트가 스스로 현재 가장 빠른 것을 골라주므로 "어떤 프로토콜을 선택해야 할지" 직접 고민할 필요가 없습니다.
직접 서버를 구축할 능력이 있다면(구독 제공업체에 완전히 의존하지 않는 경우) 이 논리를 반대로 적용할 수도 있습니다: 일상적으로는 Trojan이나 REALITY를 적용한 구성을 우선 배치해 속도와 검열 우회 능력의 균형을 맞추고, 여기에 불안정한 네트워크 환경을 위한 백업으로 Hysteria2 노드를 한두 개 준비해두는 것입니다. 둘을 서로 보완하는 관계로 보고, 굳이 하나의 "최적의 답"을 고를 필요는 없습니다.