프록시 프로토콜이 해결하는 핵심 문제는, 트래픽을 어떻게 위장하거나 암호화해서 중간의 네트워크 검사를 통과시키면서도 전송 효율을 유지하느냐입니다. 각 프로토콜은 "보안성", "속도", "검열 회피 능력" 사이에서 서로 다른 절충안을 택하고 있으며, 절대적인 "최고"는 없고 "현재 상황에 맞는 것"만 있을 뿐입니다.
다섯 가지 프로토콜 한눈에 보기
| 프로토콜 | 기반 전송 방식 | 특징 |
|---|---|---|
| Shadowsocks | TCP / UDP + 단순 암호화 | 역사가 가장 길고 구현이 가볍고 속도가 빠르지만, 트래픽 특징이 비교적 쉽게 식별됨 |
| VMess | TCP / WebSocket / mKCP | V2Ray 생태계의 네이티브 프로토콜로, 트래픽 위장을 지원하며 설정 항목이 많음 |
| VLESS | TCP + TLS, XTLS와 자주 조합 | VMess보다 더 가벼우며 내장 암호화를 제거(외부 TLS에 의존). XTLS와 함께 사용하면 성능 우위가 뚜렷함 |
| Trojan | TCP + TLS | 정상적인 HTTPS 트래픽처럼 위장하여 식별 난이도가 높으며, 실제 도메인 인증서에 의존함 |
| Hysteria2 | QUIC(UDP) 기반 | 패킷 손실 및 불안정한 네트워크에 대한 저항력이 강하고, 콜드 스타트 속도가 빠름 |
속도와 검열 회피 능력, 어떻게 균형을 잡을까
일반적으로 프로토콜 스택이 "가벼울수록"(암호화와 캡슐화 단계가 적을수록) 속도는 빨라지지만, 트래픽 분석 도구에 특징이 더 쉽게 식별됩니다. 반대로 프로토콜의 위장이 "무거울수록"(예: HTTPS 핸드셰이크를 완전히 모방) 검열 회피 능력은 강해지지만, 추가적인 성능 부담이 발생합니다.
- Shadowsocks는 경량급 선수로, 속도 우위가 확실합니다. 검열이 심하지 않은 네트워크 환경에 적합합니다.
- VMess / VLESS는 생태계가 성숙되어 있으며, WebSocket이나 TLS 같은 전송 방식과 결합하면 위장을 한층 더할 수 있어 유연성이 높습니다.
- Trojan은 "일반 웹사이트 접속과 완전히 똑같이 보이는 것"을 목표로 설계되어, 트래픽 검사가 엄격한 네트워크 환경에서도 더 안정적으로 동작합니다.
- Hysteria2는 QUIC 기반으로 패킷 손실 저항력을 기본적으로 갖추고 있어, 이동 통신망에서 기지국을 자주 전환하는 것처럼 네트워크 품질이 불안정한 환경에서 TCP 기반 프로토콜보다 체감상 뚜렷하게 우수합니다.
프로토콜은 그저 "어떻게 전송하는가"에 대한 하나의 계층일 뿐입니다. 실제로 안정적으로 사용할 수 있는지를 결정하는 것은 대개 서버 회선의 품질과 노드 수입니다 — 프로토콜 선택은 "상한선"을 최적화하고, 회선 품질은 "하한선"을 결정합니다.
Clash / Mihomo에서 모두 지원할까?
위 다섯 가지 프로토콜은 모두 Mihomo 코어(현재 Clash 생태계에서 사용하는 핵심 엔진)에서 네이티브로 지원하므로, 별도의 플러그인을 설치할 필요가 없습니다. 구독 링크를 가져오면 클라이언트가 각 노드가 사용하는 프로토콜 종류를 자동으로 인식합니다. 신경 써야 할 것은 노드가 사용 가능한지, 지연 시간이 적절한지뿐이며, 프로토콜 관련 세부 사항은 프로바이더 쪽에서 이미 처리되어 있습니다.
직접 서버를 구축하는 경우(프로바이더의 구독을 사용하지 않는 경우)에는 자신의 상황에 맞춰 프로토콜을 선택해야 합니다. 속도를 중시한다면 Shadowsocks 또는 VLESS + XTLS, 검열 회피를 중시한다면 Trojan 또는 Hysteria2, 네트워크가 불안정하다면 Hysteria2를 우선적으로 고려하세요.
일반 사용자는 어느 정도까지 신경 써야 할까
프로바이더가 제공하는 구독을 사용하는 것뿐이라면, 각 프로토콜의 구현 세부 사항까지 깊이 이해할 필요는 없습니다 — 프로바이더가 이미 적절한 프로토콜과 회선 조합을 선택해 두었기 때문입니다. 실제로 신경 쓸 만한 부분은, 같은 프로바이더가 여러 프로토콜의 노드를 동시에 제공한다면 네트워크 환경이 나쁠 때 Hysteria2처럼 불안정한 네트워크에 강한 프로토콜로 전환해 보는 것입니다. 종종 체감할 수 있을 정도로 확연한 차이를 가져다줍니다.
구독 속 노드가 어떤 프로토콜을 쓰는지 확인하는 방법
구독 링크를 Clash에 가져오면 노드 이름에 프로토콜이나 회선에 대한 힌트가 포함되는 경우가 많지만, 가장 정확한 방법은 설정 파일을 직접 열어보거나(또는 클라이언트의 노드 상세 정보에서) 확인하는 것입니다. Mihomo의 설정 형식을 예로 들면, 각 노드에는 type 필드가 있으며 값은 ss, vmess, vless, trojan, hysteria2 중 하나로, 한눈에 해당 노드가 사용하는 구체적인 프로토콜을 알 수 있습니다:
- name: HK-01
type: trojan
server: example.com
port: 443
구독 링크만 있고 해석된 평문 설정이 없다면, 먼저 구독을 클라이언트에 가져온 뒤 노드 목록에서 상세 정보를 확인하면 됩니다 — 대부분의 그래픽 클라이언트는 각 노드의 프로토콜 종류를 표시해 주므로, 구독 내용을 직접 디코딩할 필요가 없습니다.
난독화와 전송 계층 위장: 함께 사용할 수 있을까
앞서 언급한 "검열 회피 능력"은 주로 프로토콜 자체의 트래픽 특징에 따라 결정되지만, 실제 배포 환경에서는 프로토콜에 추가적인 전송 계층 위장을 함께 사용하여 식별될 확률을 더 낮추는 경우가 많습니다.
- WebSocket + TLS: 외부에서 보면 일반적인 웹 WebSocket 연결처럼 보이게 하며, CDN을 경유하는 VMess / VLESS 환경에서 흔히 사용됩니다.
- gRPC 전송: 트래픽을 gRPC 호출처럼 포장하는 방식으로, 마찬가지로 흔히 쓰이는 위장 수단이며 설정과 문제 해결 방식은 WebSocket과 유사합니다.
- XTLS: VLESS를 위해 전용으로 설계된 전송 최적화 방식으로, TLS 위장을 유지하면서 추가적인 암호화 부담을 줄여, 현재 VLESS 환경에서 가장 성능이 좋은 조합 중 하나입니다.
일반 사용자에게는 이러한 전송 계층의 세부 사항 역시 프로바이더가 이미 처리해 둔 부분이므로, 직접 설정할 필요가 없습니다. 이런 용어를 알아 두면, 노드 이름에 "WS", "gRPC", "XTLS" 같은 표시가 붙어 있을 때 이것들이 대략 전송 계층 위장 방식에 해당한다는 것을 알 수 있으며, 완전히 다른 프로토콜이 아니라는 점을 이해할 수 있습니다.
어떤 프로토콜을 선택할지 모르겠다면
어떤 프로토콜이 현재 네트워크 환경에 더 적합한지 바로 판단하기 어렵다면, 이론적인 우열을 따지기보다 직접 테스트해 보는 것이 가장 실질적입니다. 같은 프로바이더라면 대개 여러 프로토콜의 노드 조합을 제공하므로, 각각 url-test 프록시 그룹으로 속도를 측정해 지연 시간과 안정성을 비교해 보면, 자료를 반복해서 찾아보는 것보다 훨씬 효율적으로 몇 분 안에 직관적인 결론을 얻을 수 있습니다.