Shadowsocks, VMess, Trojan, Hysteria2 어떻게 선택할까? 프록시 프로토콜 비교

먼저 전체적으로 살펴보기

네 가지 프로토콜 중 절대적으로 「가장 좋은」 것은 없습니다. 「지금 내 네트워크 환경에 더 맞는」 것이 있을 뿐입니다. 대체로 다음과 같이 정리할 수 있습니다.

Shadowsocks: 가볍고 오래된 만큼 안정적

Shadowsocks는 구현이 단순해 거의 모든 플랫폼에 성숙한 클라이언트가 있고, 암복호화 부담도 작아 지연 성능이 꾸준히 좋습니다. 다만 트래픽 특징이 오랜 기간 널리 연구되어 있어, 제한이 심한 네트워크 환경에서는 순수한 Shadowsocks 연결이 상대적으로 식별되기 쉬운 편입니다. 이런 환경에서는 보통 obfs 같은 난독화 플러그인을 함께 사용합니다.

VMess: 유연하지만 설정 부담이 큼

VMess는 Shadowsocks의 인증 방식과 트래픽 특징 문제를 보완하기 위해 등장한 프로토콜 중 하나로, WebSocket, mKCP 등 다양한 전송 계층을 지원하고 TLS를 얹을 수도 있습니다. 유연함의 대가로 설정 항목이 눈에 띄게 늘어나는데, 서버 주소, 포트, UUID, alterId, 암호화 방식, 전송 방식, TLS 관련 파라미터가 모두 서버 쪽과 정확히 일치해야 하며, 하나라도 맞지 않으면 연결에 실패합니다. Shadowsocks보다 문제 진단 비용이 더 드는 편입니다.

Trojan: 평범한 웹사이트처럼 위장, 강한 차단 저항력

Trojan의 설계 방향은 직관적입니다. 표준 TLS 사용을 강제해 프록시 트래픽을 사용자가 일반 HTTPS 사이트에 접속하는 것처럼 위장하기 때문에, 트래픽 특징만으로는 실제 웹사이트와 구분하기가 쉽지 않습니다. 그 대가로 배포 난이도가 더 높아지는데, 실제 도메인과 유효한 인증서가 필요하고 sni는 인증서 도메인과 반드시 일치해야 하며, 그렇지 않으면 식별되거나 연결 자체가 실패할 수 있습니다. 다만 일반 사용자 입장에서는 노드 서비스 제공자가 이런 세부 사항을 이미 처리해 두었다면 다른 프로토콜과 사용 경험에 큰 차이가 없습니다.

Hysteria2: 새로운 프로토콜, 불안정한 네트워크에서 강점

Hysteria2는 QUIC(UDP)를 기반으로 구현되어 전방 오류 정정과 혼잡 제어 최적화를 기본적으로 갖추고 있어, 패킷 손실률이 높거나 지연이 큰 네트워크 환경(예: 국제 장거리 회선)에서 실제 체감 성능이 전통적인 TCP 계열 프로토콜보다 나은 경우가 많습니다. 다만 일부 공용 네트워크나 회사 네트워크는 UDP 트래픽을 제한하거나 우선순위를 낮추기도 하는데, 이런 환경에서는 Hysteria2의 강점이 제대로 발휘되지 않으므로 Trojan 같은 TCP 계열 프로토콜로 돌아가는 편이 대체로 더 안정적입니다.

어떻게 선택할까

• 제한이 심한 네트워크 환경에서 장기간 안정적으로 사용해야 한다면 — Trojan을 우선 고려하세요;
• 설정 유연성을 원하고 전송 방식을 직접 커스터마이징하고 싶다면 — VMess도 괜찮은 선택입니다;
• 단순하고 가벼운 방식이면 충분하고, 네트워크 환경도 비교적 자유롭다면 — Shadowsocks만으로도 충분합니다;
• 네트워크 지연이 높고 패킷 손실이 눈에 띄며 UDP가 제한되지 않은 환경이라면 — Hysteria2를 시도해 보세요. 대체로 속도 체감이 더 좋습니다.

실제로는 많은 구독이 여러 프로토콜의 노드를 동시에 제공합니다. 「하나만 써야 한다」는 부담을 가질 필요는 없으며, 이들을 같은 정책 그룹에 섞어 넣고 클라이언트가 자동으로 속도를 측정해 그때그때 가장 좋은 것을 고르게 하면 됩니다.

한 가지만 고집하기보다 섞어서 쓰는 편이 더 실용적

네 가지 프로토콜 중 「유일하게 옳은 정답」을 찾으려 애쓰기보다, 이들을 하나의 도구함 안에 든 서로 다른 선택지로 여기는 편이 실제 사용에 더 가깝습니다. 어느 정도 규모를 갖춘 구독 서비스는 대개 여러 프로토콜의 노드를 함께 제공하며, 클라이언트 쪽에서는 이를 같은 url-test 정책 그룹에 섞어 넣으면 됩니다. 속도 측정 로직이 지금 네트워크 환경에서 지연이 가장 낮고 안정적인 노드를 자동으로 골라주기 때문에, 어떤 프로토콜로 전환해야 할지 직접 판단할 필요가 없습니다.

네트워크 환경이 자주 바뀌는 경우(예: 낮에는 회사, 밤에는 집, 주말에는 모바일 데이터를 쓰는 경우) 혼합 편성의 효과가 더 두드러집니다. 네트워크마다 프로토콜을 대하는 우호도가 다른데, 회사 네트워크는 UDP를 엄격히 제한할 수 있어 Hysteria2의 성능이 떨어질 수 있고, 모바일 네트워크는 대체로 표준 TLS 트래픽(Trojan)에 더 관대한 편입니다. 클라이언트가 자동으로 속도를 측정해 전환하도록 두는 편이 직접 판단하는 것보다 편하고, 「환경이 바뀐 걸 깜빡해서 연결이 안 되는」 상황도 줄일 수 있습니다.

프로토콜을 바꾸는 데 드는 실제 비용

프로토콜을 서로 바꾸는 일은 본질적으로 노드 정보를 교체하는 것에 불과하며, 규칙이나 정책 그룹, DNS 같은 로직 계층 설정과는 무관합니다. 그래서 생각보다 비용이 훨씬 낮습니다. 대부분의 경우 클라이언트에서 구독을 업데이트하거나(서비스 제공자가 여러 프로토콜의 노드를 함께 제공한다면 보통 같은 구독 안에 묶여 있습니다) proxies 목록의 노드 필드를 직접 교체하는 것만으로 충분하며, 정책 그룹과 규칙은 그대로 두어도 됩니다. 오히려 신경 써서 테스트해야 할 부분은 프로토콜 자체의 호환성이 아니라 전환 후 노드 자체의 안정성과 속도입니다. 각 프로토콜을 config.yaml에서 어떻게 작성하는지 구체적으로 보고 싶다면 고급 문서의 프로토콜 파라미터 설명을 참고하세요.