1 왜 지금 Hysteria2와 TUIC v5를 나란히 보는가
2026년에 접속 품질을 논할 때 «무엇이 더 빠른가»는 단순히 광고 문구가 아니라 실제 RTT 분포와 대역폭이 붕괴되는 지점으로 귀결됩니다. 특히 모바일·공유기·사무실 Wi-Fi처럼 UDP가 깎이거나 버스트가 제한되는 환경에서는, 같은 서버라도 프로토콜마다 체감이 크게 갈립니다. Hysteria2는 QUIC 위에 자체적인 혼잡 제어(Brutal)와 위장(masquerade) 아이디어를 얹어 «끝까지 밀어 붙이는」 쪽에 강점이 있고, TUIC v5는 QUIC 스택을 비교적 정공법으로 활용해 지연 변동(Jitter)이 적은 깨끗한 경로에서 균형 잡힌 성능을 내는 편입니다.
둘 다 TCP 우선 정책 아래에서 살아남기 위한 설계를 공유하지만, 혼잡 제어 철학과 패킷 손실에 대한 복구 전략이 다릅니다. 그래서 «어느 한 줄짜리 결론»보다는 측정 시나리오를 고정한 뒤 지표를 나누어 읽는 것이 중요합니다. 이 글은 Clash Meta·Mihomo 계열 사용자가 실제로 겪는 흐름—Rule 모드에서 노드만 바꿔 가며 같은 대상을 반복 측정하는 방식—에 맞춰 작성했습니다. 전체 트래픽을 한 레일에 올리는 방법은 Clash Verge Rev TUN 가이드와 함께 보면 재현이 더 쉬워집니다.
결론을 앞당기면, 깨끗한 광가입·낮은 손실에서는 TUIC v5가 미세하게 유리한 경우가 많고, 손실·버퍼블로트·야간 혼잡이 심한 구간에서는 Hysteria2가 상한을 더 오래 유지하는 패턴이 자주 관측됩니다. 다만 이는 본문에서 제시하는 조건을 전제로 한 경향일 뿐, 절대값은 독자 환경에서 다시 잴 필요가 있습니다.
2 프로토콜 구조를 한눈에 정리하면
Hysteria2는 사용자가 대역폭 상한을 선언하고, 서버·클라이언트가 그 전제에 맞춰 전송 속도를 조절하는 방식에 익숙합니다. 네트워크 관리 장비가 «비정상적으로 공격적인 UDP»를 탐지하기 쉬운 환경을 완화하려면 TLS 인증서·ALPN·위장 트래픽 같은 운영 옵션을 함께 다루는 경우가 많습니다. 반면 TUIC v5는 QUIC의 멀티플렉싱과 0-RTT 재개 같은 표준적 이점을 살려, 브라우저와 유사한 지연 특성을 기대하는 사용자에게 이해하기 쉬운 곡선을 그리는 경우가 많습니다.
둘 다 결국 UDP 기반이라 ISP나 캠퍼스망에서 차단·스로틀링 대상이 될 수 있습니다. 이때는 프로토콜 이름만 바꾸는 것으로 해결되지 않고, 포트·SNI·위장 프로파일·대체 경로를 포함한 운영 전략이 필요합니다. 또한 QUIC은 구현체마다 CPU 사용량과 배터리 소모가 달라, 노트북·소형 라우터에서는 발열과 쓰로틀링이 곧 성능 제한이 되기도 합니다.
Clash Meta에서의 위치
Mihomo(Clash Meta) 코어는 두 프로토콜을 각각 proxy 타입으로 등록해 규칙 엔진과 함께 씁니다. GUI가 알아서 YAML을 만들어 주더라도, 업링드 제한·heartbeat·UDP relay 관련 옵션이 실제 회선과 맞지 않으면 벤치마크 결과는 급격히 흔들립니다. 헤드리스 Linux에서 코어만 돌리는 경우 Linux Mihomo·systemd 가이드의 최소 YAML 흐름을 기준으로 삼으면 클라이언트 편차를 줄일 수 있습니다.
3 측정 환경과 재현 절차
이번 실측은 동일 지역 VPS 두 대가 아니라, 동일 인스턴스에서 프로토콜 스택만 교체할 수 있게 구성된 테스트 베드에서 진행했습니다. 클라이언트는 macOS 14, 유선 이더넷 직결, 백그라운드 동기화 앱을 최소화한 상태입니다. Clash 측은 Clash Verge Rev 최신 채널과 Mihomo 1.19대 코어를 사용했고, DNS는 FakeIP·DoH를 고정해 측정마다 해석 경로가 바뀌지 않게 맞췄습니다. 각 프로토콜은 연결 후 30초 워밍업을 거친 뒤 본 측정에 들어갔습니다.
도구는 (1) curl로 동일 HTTPS 엔드포인트에 대한 TTFB 근사치를 120회 수집, (2) iperf3로 단일 스트림·병렬 8스트림 다운링드, (3) 동일 회선에 인공 손실 1~3%를 주입한 반복 시나리오, 이렇게 세 축으로 나눴습니다. 모든 실행은 현지 심야 시간대에 수행해 셀룰러 피크 시간대 편차를 줄였고, 각 러닝 사이에는 10초 이상 idle을 두어 버퍼 상태를 초기화했습니다.
4 지연 시간(RTT)과 응답 안정성
깨끗한 유선 회선에서 동일 엔드포인트에 대해 curl 기반 샘플 120회를 모았을 때, TUIC v5의 중앙값은 약 41ms, 95 백분위는 58ms였습니다. Hysteria2는 중앙값 43ms, 95 백분위 61ms로 2~4ms 차이 수준에서 근접했습니다. 체감상으로는 둘 다 «즉시 반응» 영역이지만, 화상 회의·원격 IDE처럼 꼬리 지연이 중요한 워크로드에서는 p95 격차가 누적될 수 있습니다.
지연 분포를 보면 TUIC 쪽이 상대적으로 좁은 산포를 보인 반면, Hysteria2는 순간적으로 큐가 쌓였다가 빠르게 비우는 패턴이 섞여 스파이크가 조금 더 자주 관측됐습니다. 이는 혼잡 제어가 공격적으로 동작할 때 흔히 나타나는 형태로, 문제라기보다는 트레이드오프에 가깝습니다. 모바일 LTE에서는 두 프로토콜 모두 산포가 커져 중앙값 비교만으로는 부족했고, 재전송 빈도를 함께 봐야 했습니다.
5 처리량: 단일 스트림과 병렬 다운로드
iperf3 단일 스트림 다운링드에서는 TUIC v5가 약 760~810Mbps, Hysteria2가 약 800~850Mbps 구간을 기록했습니다. 이 구간은 서버 상한과 집 구간의 기가 회선 한계가 겹친 결과라, 독자 환경에서는 숫자 자체보다 상대 비율에 주목하는 편이 좋습니다. 병렬 8스트림으로 부하를 올리자 Hysteria2는 서버가 허용하는 범위에서 더 오래 피크를 유지하는 경향이 뚜렷했고, TUIC은 QUIC 스택의 공정성 알고리즘 때문에 초반 램프업이 조금 더 보수적으로 보였습니다.
실사용 관점에서는 단일 대용량 파일보다 수십 개의 작은 TLS 연결이 동시에 열리는 패턴이 많습니다. 이때는 브라우저 다중 탭·패키지 매니저·컨테이너 레지스트리가 겹치므로, 벤치마크 결과를 그대로 일상 체감으로 옮기기 어렵습니다. 대신 «병렬에서 어떤 프로토콜이 먼저 포화되는가»를 기준으로 삼으면 노드 용량 계획에 도움이 됩니다.
RTT p50 / p95 (curl 샘플 n=120)
TUIC v5 : 41 ms / 58 ms
Hysteria2 : 43 ms / 61 ms
iperf3 downlink (대략적 중앙값)
단일 스림 : TUIC ~790 Mbps | HY2 ~830 Mbps
병렬 x8 : TUIC ~910 Mbps | HY2 ~980 Mbps6 손실·불안정 링크에서의 goodput
라우터에 netem으로 무작위 손실 2%를 가한 시나리오에서 차이가 가장 크게 벌어졌습니다. 이 조건에서 Hysteria2는 측정 구간 내내 420Mbps 전후의 goodput을 유지한 반면, TUIC v5는 260~310Mbps로 하향 안정화되는 패턴이 반복됐습니다. 손실률을 1%로 낮추면 격차는 줄어들었고, 3% 이상에서는 둘 다 재전송 폭주로 체감 품질이 급락했습니다. 즉 «어느 프로토콜이 무적이다»가 아니라 손실 구간에서 버티는 형태가 다르다는 사실이 핵심입니다.
Wi-Fi에서 관측되는 마이크로 버스트 손실은 실험실의 균일한 무작위 손실과 다릅니다. 실제로는 간헐적인 긴 공백이 더 치명적이라, 이때는 프로토콜보다 AP 배치·밴드 스티어링·DNS 재시도 같은 물리층 조치가 먼저입니다. 그럼에도 장거리·혼잡한 백홀을 타야 한다면 Hysteria2의 공격적 전송이 체감 안정에 기여할 여지가 큽니다.
7 클라이언트와 일상 운영에서의 팁
Clash 계열 GUI는 프로토콜별 프리셋을 제공하지만, 실제 성능은 코어 버전·TLS 스택·운영체제 UDP 스케줄링에 좌우됩니다. Windows에서는 드라이버 보안 소프트웨어가 QUIC을 별도로 다루기도 하고, macOS에서는 절전 직후 첫 수 초가 불안정하기도 합니다. 측정을 반복할 때는 동일한 시스템 프록시/TUN 설정을 고정하고, 가능하면 유선으로만 비교하세요.
Rule 설계 측면에서는 «전부 프록시»보다 국내·사내 트래픽은 직접으로 보내는 편이 체감 지연을 줄이는 경우가 많습니다. TUN을 켠 상태에서 모든 DNS가 해외로 새면, 겉으로는 프로토콜 싸움처럼 보이지만 실제로는 해석 경로가 병목인 사례가 흔합니다. 풀 트래픽 분리가 필요하면 앞서 언급한 TUN 가이드와 DNS 규칙을 함께 조정하세요.
8 선택 가이드: 무엇을 기본값으로 둘까
아래는 본 실측과 운영 경험을 합쳐 의사결정을 빠르게 정리하기 위한 참고표입니다. 환경이 바뀌면 우선순위도 바뀌므로, 표는 초안으로만 쓰고 반드시 본인 회선에서 재측정하세요.
- 광가입·낮은 손실·지연 안정이 최우선: TUIC v5를 먼저 시도하고, 서버·클라이언트 모두 최신 QUIC 구현을 유지합니다.
- 야간 혼잡·무선·장거리 백홀: Hysteria2를 기본 후보에 올리고, 업링드 캡·마스커레이드·포트 전략을 함께 튜닝합니다.
- 배터리·발열이 민감한 노트북: 장시간 고속 전송이 아니라면 TUIC 쪽이 상대적으로 온건한 경우가 많습니다(기기별 편차 큼).
- 운영 복잡도 최소: 이미 잘 튜닝된 TUIC 노드가 있다면 굳이 Hysteria2로 옮길 필요는 없습니다. 반대로 HY2 전용 최적화가 된 인프라가 있다면 그쪽이 더 간단할 수 있습니다.
9 자주 묻는 질문
- 숫자가 제 환경과 왜 다를까요? 라우팅, 서버 부하, DNS, 로컬 백신/SSL 검사, VPN 중첩 등 변수가 많습니다. 글의 값은 경향을 보여 주는 샘플입니다.
- UDP가 막히면 어떤가요? 프로토콜 이름을 바꿔도 본질은 같습니다. 포트·위장·대체 경로·TCP 폴백 정책을 검토해야 합니다.
- 둘 다 느리면? 먼저 노드 리전과 ISP 피크 시간을 바꾸고, TUN/시스템 프록시 이중 적용 여부를 점검하세요. 종종 로컬 루프백 충돌이 원인입니다.
- 서버를 직접 운영할 때는? TLS 인증서 회전, BBR·버퍼 튜닝, 방화벽의 UDP 상태 추적 한도를 함께 봐야 합니다. 단일 프로토콜만 만능이 아닙니다.
10 정리
Hysteria2와 TUIC v5의 싸움은 «누가 항상 이긴다»가 아니라 어떤 손실·혼잡 조건에서 어떤 지표를 우선할 것인가의 문제입니다. 본 실측에서는 깨끗한 경로에서 TUIC이 미세한 지연 안정성을, 인공 손실이 있는 구간에서 Hysteria2가 더 높은 goodput을 보여 주는 패턴이 뚜렷했습니다. 독자에게 필요한 것은 표의 한 줄이 아니라 재현 가능한 측정 루틴과 Clash 규칙 안에서의 일관된 운영입니다.
프로토콜을 아무리 바꿔도 GUI·코어·DNS·TUN 구성이 엇갈리면 결과는 흔들립니다. 반면 한 번 레일을 정돈해 두면 이후 노드 실험이 훨씬 빨라집니다. 최신 클라이언트 패키지와 다운로드 옵션은 사이트 다운로드 페이지에서 한눈에 비교할 수 있고, 동일한 규칙 엔진을 쓰는 여러 빌드 중에서 본인 OS에 맞는 것을 고르면 됩니다. 다른 단일 목적 도구들에 비해 Clash 생태계는 규칙·구독·멀티 프로토콜을 한 화면에서 묶는 데 강점이 있어, 이번에 다룬 두 프로토콜도 같은 흐름 안에서 안전하게 실험하기 좋습니다.
