구독에 포함된 노드 종류는 다양합니다——ss, vmess, trojan, hysteria2 등. 많은 사람이 서비스 제공처가 준 기본 설정을 그대로 쓰고 있으며, 사실 이 프로토콜들이 서로 어떻게 다른지는 잘 모릅니다. 이 글은 "속도", "검열 우회", "설정 복잡도" 세 가지 관점에서 비교해, 여러분이 판단하는 데 도움을 드리겠습니다.
먼저 전체 개요표부터
| 프로토콜 | 전송 계층 | 검열 우회 | 대표적인 사용처 |
|---|---|---|---|
| Shadowsocks | TCP/UDP | 보통, 특징이 비교적 식별되기 쉬움 | 가벼움, 빠른 도입, 오래된 프로토콜 |
| VMess | TCP + WS/gRPC | 양호(CDN 위장과 함께 사용) | 정상적인 HTTPS 트래픽처럼 위장이 필요할 때 |
| VLESS | TCP + WS/gRPC/XTLS | 우수, VMess보다 성능이 좋음 | 성능과 탐지 저항성을 모두 원할 때 |
| Trojan | TLS | 우수, 트래픽 특징이 일반 HTTPS와 유사 | 단순하고 신뢰할 수 있는 위장 능력 추구 |
| Hysteria2 | QUIC (UDP) | 강력, 열악한 네트워크 환경에 최적화 | 높은 지연/패킷 손실 환경에서 속도 추구 |
| TUIC | QUIC (UDP) | 강력, 연결 시작이 빠름 | 모바일 네트워크, 빈번한 네트워크 전환 환경 |
Shadowsocks: 단순하고 신뢰할 수 있는 오래된 프로토콜
Shadowsocks(SS)는 가장 먼저 널리 사용된 암호화 프록시 프로토콜 중 하나로, 설정이 간단합니다. server, port, cipher, password 네 가지 핵심 필드만 필요합니다. 단점은 트래픽 특징이 비교적 고정되어 있어, 특징 탐지가 엄격한 네트워크 환경에서는 표적이 되어 제한이나 차단을 당하기 쉽다는 점입니다.
VMess / VLESS: CDN과 결합한 위장 능력
VMess와 그 후속인 VLESS는 보통 WebSocket이나 gRPC 전송 계층과 결합하고, 그 위에 TLS를 한 번 더 씌워 트래픽이 일반적인 HTTPS 요청처럼 보이게 하며, CDN을 경유시킬 수도 있습니다. VLESS는 VMess보다 일부 암호화 오버헤드를 줄였고, XTLS와 함께 사용하면 성능이 더 좋습니다.
Trojan: "정상적인 웹사이트"로 위장하기
Trojan의 설계 방식은 명확합니다. 연결 전체가 표준 HTTPS 요청처럼 보이며, 탐지될 경우 서버가 정상적인 웹사이트 콘텐츠를 "위장"으로 그대로 반환할 수도 있습니다. 설정 필드도 비교적 간결해서, 단순함과 위장 능력의 균형을 원할 때 자주 선택됩니다.
Hysteria2 / TUIC: QUIC 기반의 신세대 프로토콜
두 프로토콜 모두 QUIC(UDP 기반) 위에 구축되어 있어 더 나은 혼잡 제어와 연결 마이그레이션 능력을 자연스럽게 갖추고 있습니다. 높은 지연, 열악한 네트워크, 빈번한 네트워크 전환(모바일 네트워크가 Wi-Fi와 4G/5G 사이를 오갈 때 등) 환경에서는 대체로 전통적인 TCP 계열 프로토콜보다 체감이 좋습니다.
연결 다중화가 실제 체감 속도에 미치는 영향
프로토콜 자체 외에도, 전송 계층의 연결 다중화 방식이 체감 속도에 큰 영향을 줍니다. VMess/VLESS와 함께 쓰이는 gRPC 전송은 하나의 물리적 연결 위에 여러 논리 스트림을 다중화할 수 있어 연결을 반복적으로 맺는 오버헤드를 줄이며, 열악한 네트워크나 높은 지연 경로에서 특히 두드러집니다. 반면 요청마다 새 연결을 별도로 맺는 방식은, 웹페이지에서 여러 개의 작은 리소스(이미지, 스크립트)를 동시에 불러올 때 눈에 띄는 끊김이 발생하기 쉽습니다. 같은 노드인데도 웹 서핑과 대용량 파일 다운로드에서 체감이 크게 다르다면, 대부분 전송 계층의 다중화 전략과 관련이 있으며 단순히 대역폭 문제만은 아닙니다.
같은 프로토콜인데 제공처마다 체감이 크게 다른 이유
많은 사람이 "결국 어떤 프로토콜이 가장 빠른가"를 두고 고민하지만, 실제로 테스트해보면 같은 Trojan 프로토콜이라도 제공처에 따라 노드 속도가 몇 배씩 차이 나는 것을 발견하게 됩니다. 이는 최종 체감에 영향을 주는 변수가 프로토콜 종류만이 아니기 때문입니다. 서버 자체의 대역폭 출구 품질, 여러분이 위치한 지역과의 물리적 거리, 중계 경로가 최적화되었는지, 심지어 같은 시간대에 서버를 이용하는 동시 접속자 수까지 모두 겹쳐서 최종 결과에 영향을 줍니다. 프로토콜이 결정하는 것은 "전송 계층에서 데이터를 어떻게 감싸는가"일 뿐이며, 속도의 상한을 실제로 결정하는 것은 기반 네트워크 인프라입니다.
노드의 실제 속도를 어떻게 테스트할까
프록시 그룹에 표시되는 지연 수치(ms)만으로는 실제 체감을 완전히 반영할 수 없습니다. 이는 보통 한 번의 TCP/HTTP 프로브의 왕복 시간일 뿐이며, 지연을 반영할 뿐 대역폭은 반영하지 않기 때문입니다. 더 종합적인 테스트 방법은, 먼저 url-test의 지연 순위로 1차 필터링을 하고, 후보 노드 두세 개에서 각각 적당한 크기의 테스트 파일을 다운로드해 순간적인 최고치만 보지 말고 실제 다운로드 속도 곡선이 안정적인지 관찰하는 것입니다. 어떤 노드의 지연이 매우 낮은데도 다운로드 속도가 불안정(빠르다가 느려짐)하다면, 대부분 서버 측 동시 접속 부담이 크거나 출구 대역폭이 제한적이기 때문입니다.
실전 조언: 어떻게 선택할까
- 그냥 안정적으로 쓰고 싶다면: 서비스 제공처가 준 프로토콜을 그대로 쓰세요. Clash 클라이언트가 자동으로 인식하고 처리하므로 고민할 필요가 없습니다.
- 네트워크 검열이 엄격한 경우: 트래픽 특징이 일반 HTTPS와 가까운 Trojan이나 VLESS를 우선 선택하세요.
- 네트워크 품질이 나쁜 경우(높은 지연/높은 패킷 손실): Hysteria2나 TUIC를 먼저 시도해보세요. QUIC은 대체로 패킷 손실 저항성이 더 좋습니다.
- 여러 프로토콜의 노드가 모두 있는 경우: 같은
url-test그룹에 넣어두면, 클라이언트가 현재 네트워크에서 지연이 가장 낮은 것을 자동으로 골라줍니다.
프로토콜은 "구식"이 될까
업데이트와 발전은 있겠지만, "예전 프로토콜이 언젠가 못 쓰게 될까" 걱정할 필요는 없습니다. Shadowsocks는 몇 년째 여전히 활발하게 쓰이고 있으며, 이는 단순하고 신뢰할 수 있는 방식에는 그 자체의 생명력이 있음을 보여줍니다. 새로운 프로토콜(Hysteria2, TUIC 등)은 특정 상황(열악한 네트워크, 더 높은 검열 우회 요구)에서 더 나은 선택지를 제공하는 것일 뿐, 예전 프로토콜을 완전히 대체하는 것이 아닙니다. 실제 사용에서 더 주목해야 할 것은 노드 제공처가 지속적으로 유지 관리를 하고 있는지이며, 프로토콜 자체의 신구 여부가 아닙니다——오랫동안 관리되지 않은 최신 프로토콜 노드는, 잘 관리되고 있는 오래된 프로토콜 노드보다 체감이 나쁠 수도 있습니다.
정리
프로토콜에 절대적인 "최고"는 없으며, "현재 네트워크 환경에서 가장 적합한 것"만 있습니다. 구독에 여러 프로토콜의 노드가 함께 제공된다면, 모두 남겨두고 자동 속도 테스트 그룹에 넣어 Clash가 실제 네트워크 상황에 따라 자동으로 선택하게 하는 것이, 한 프로토콜만 고집하는 것보다 훨씬 편합니다.