Hysteria2와 TUIC 프로토콜: 높은 패킷 손실 환경에서의 속도 개선

Shadowsocks나 VMess 프로토콜을 사용해 봤다면 다음과 같은 상황을 겪었을 가능성이 큽니다. 노드의 지연 시간은 80ms에 불과한데 실제 다운로드 속도는 2MB/s밖에 안 되고, 영상을 볼 때 자주 버퍼링이 걸립니다. 문제는 노드 자체가 아니라 전송 프로토콜에 있는 경우가 많습니다. 기존 프록시 프로토콜은 TCP 기반이라, 높은 패킷 손실·높은 지연 네트워크 환경에서 성능이 급격히 떨어집니다. QUIC 기반의 차세대 프로토콜인 Hysteria2와 TUIC는 바로 이 문제를 해결하기 위해 탄생했습니다.

왜 TCP 프록시는 높은 패킷 손실 네트워크에서 느린가

TCP는 신뢰성 있는 전송 프로토콜로, 모든 데이터 패킷에 확인 응답(ACK)이 필요합니다. 네트워크 패킷 손실률이 높아지면 TCP의 혼잡 제어 알고리즘이 전송 속도를 낮추고 재전송을 유발하여 악순환이 형성됩니다. 더 나쁜 것은 TCP의 「헤드 오브 라인 블로킹」 문제입니다. 패킷 하나가 손실되면, 그 뒤의 모든 패킷은 재전송이 완료될 때까지 기다려야 처리될 수 있습니다.

프록시 시나리오에서는 TCP의 단점이 더욱 두드러집니다.

프록시 트래픽은 추가 캡슐화를 거쳐 모든 TCP 연결이 「TCP over TCP」가 되며, 이중 혼잡 제어가 서로 간섭합니다
국제 회선의 패킷 손실률은 흔히 5%~15%에 달하며, TCP는 이 환경에서 처리량이 대역폭의 30%에 못 미칠 수 있습니다
높은 지연은 패킷 손실의 영향을 증폭시킵니다. 모든 재전송이 한 번의 RTT를 기다려야 하기 때문입니다

이것이 바로 같은 노드인데도 SS 프로토콜로는 5MB/s밖에 안 나오던 것이, Hysteria2로 바꾸면 50MB/s 이상까지 나올 수 있는 이유입니다.

QUIC: 현대 전송 프로토콜의 토대

QUIC(Quick UDP Internet Connections)는 Google이 제안한 UDP 기반 전송 프로토콜로, 현재 HTTP/3의 표준 전송 계층이 되었습니다. TCP와 비교한 QUIC의 핵심 장점은 다음과 같습니다.

0-RTT 연결 수립 — 이전 연결 파라미터를 재사용하여, 두 번째 연결 시 핸드셰이크가 필요 없습니다
헤드 오브 라인 블로킹 없음 — 각 데이터 스트림이 독립적으로 전송되어, 한 스트림의 패킷 손실이 다른 스트림에 영향을 주지 않습니다
사용자 공간 혼잡 제어 — 운영체제 TCP 스택의 제약을 받지 않아, 더 적극적으로 대역폭을 활용할 수 있습니다
연결 마이그레이션 — 네트워크 전환(예: Wi-Fi에서 4G로) 시 연결이 끊기지 않습니다

Hysteria2와 TUIC는 모두 QUIC 위에 구축되었지만, 설계 철학과 최적화 방향이 다릅니다.

Hysteria2: 폭력적 미학

Hysteria2의 핵심 발상은 가능한 한 사용 가능한 대역폭을 모두 채우는 것입니다. Brutal 혼잡 제어 알고리즘을 사용하여, 패킷 손실 신호에 의존해 속도를 조절하는 대신 클라이언트와 서버가 협상한 대역폭 상한에 따라 직접 전송합니다. 이는 높은 패킷 손실·높은 지연 회선에서 매우 두드러진 효과를 냅니다.

Hysteria2의 주요 특징입니다.

QUIC 기반으로, TLS 1.3 암호화와 난독화를 내장
Brutal 혼잡 제어로, 높은 패킷 손실 환경에서도 높은 처리량 유지
포트 호핑(Port Hopping)을 지원하여 UDP 속도 제한과 차단에 대응
설정이 간단하여 서버와 클라이언트 모두 배포가 쉬움
서버 대역폭 요구가 비교적 높음 — 설정한 대역폭 상한을 실제로 채우려 시도함

Clash에서의 Hysteria2 노드 설정 예시입니다.

- name: "HY2-Node"
  type: hysteria2
  server: example.com
  port: 443
  password: your-password
  sni: example.com
  skip-cert-verify: false
  up: 50        # 업로드 대역폭 Mbps
  down: 200     # 다운로드 대역폭 Mbps

up과 down은 Hysteria2의 핵심 파라미터로, Brutal 알고리즘에 대역폭 상한을 알려줍니다. 너무 낮게 설정하면 성능을 낭비하고, 너무 높게 설정하면 패킷 손실이 심해질 수 있습니다. 실제 대역폭의 70%~80%에서 시작하여 테스트하며 조정할 것을 권장합니다.

Hysteria2의 up/down 파라미터는 클라이언트 측의 대역폭 선언으로, 서버 설정과 완전히 일치할 필요는 없지만 실제 네트워크 대역폭에 가까워야 합니다.

TUIC: 균형 잡힌 선택

TUIC(The Universal Implicit Congestion Control)도 마찬가지로 QUIC 기반이지만, 다른 길을 택했습니다. sing-box 프로젝트 작성자가 개발했으며, 무작정 극한의 속도를 추구하기보다 낮은 지연과 안정성 사이의 균형을 설계 목표로 삼았습니다.

TUIC의 주요 특징입니다.

QUIC 기반으로, 네이티브 TLS 1.3 암호화
표준 QUIC 혼잡 제어(BBR/Cubic)를 사용하여 동작이 더 「온화함」
UDP over Stream 모드를 지원하여 호환성과 안정성이 더 우수
0-RTT 핸드셰이크를 지원하여 연결 수립이 매우 빠름
서버 리소스 점유율이 상대적으로 낮음

Clash에서의 TUIC 노드 설정 예시입니다.

- name: "TUIC-Node"
  type: tuic
  server: example.com
  port: 443
  uuid: your-uuid-here
  password: your-password
  sni: example.com
  alpn: [h3]
  skip-cert-verify: false
  congestion-controller: bbr
  udp-relay-mode: native

congestion-controller는 bbr 또는 cubic 중에서 선택할 수 있습니다. BBR은 높은 지연 회선에서 더 좋은 성능을 보이고, Cubic은 더 보수적이고 안정적입니다. 일반적으로 먼저 BBR을 사용하다가 불안정해지면 Cubic으로 전환할 것을 권장합니다.

Hysteria2 vs TUIC: 어떻게 고를까

두 프로토콜에 절대적인 우열은 없으며, 핵심은 자신의 네트워크 환경과 사용 시나리오입니다.

높은 패킷 손실·높은 지연 국제 회선 → Hysteria2. Brutal 알고리즘이 대역폭을 강제로 활용하여 속도 향상이 가장 두드러집니다
네트워크 품질이 중간이고 안정성을 추구 → TUIC. 표준 혼잡 제어가 더 예측 가능하여 장시간 사용해도 이상이 잘 생기지 않습니다
스트리밍 시청, 대용량 파일 다운로드 → Hysteria2. 극한 처리량이 더 높습니다
일상적인 브라우징, 소셜, 업무 → TUIC. 낮은 지연 연결 수립으로 경험이 더 매끄럽습니다
서버 대역폭이 제한적 → TUIC. Hysteria2처럼 대역폭을 채우려 하지 않습니다
서버 대역폭이 충분 → Hysteria2. 큰 대역폭의 이점을 실제 속도로 전환할 수 있습니다

실제 사용에서는 많은 사용자가 구독에 두 프로토콜의 노드를 함께 보관하고, 현재 네트워크 상황에 따라 유연하게 전환합니다. Clash의 url-test 프록시 그룹은 지연 시간이 가장 낮은 노드를 자동으로 선택할 수 있지만, 현재 네트워크에서 어느 프로토콜이 더 빠른지는 자동으로 판단할 수 없습니다. 이는 직접 몇 차례 테스트하여 경험을 쌓아야 합니다.

Clash에서 QUIC 프로토콜 경험 최적화하기

코어 버전이 충분히 최신인지 확인하기

Hysteria2와 TUIC는 모두 Mihomo 코어의 지원이 필요합니다. 클라이언트 설정에서 코어 버전을 확인하고, 최상의 호환성과 성능을 위해 v1.18 이상 버전 사용을 권장합니다.

UDP 연결성

QUIC는 UDP 기반이므로, 네트워크 환경이 UDP 트래픽을 차단하거나 속도를 제한하면 두 프로토콜 모두 작동하지 않습니다. Hysteria2의 포트 호핑 기능은 여러 포트 간을 번갈아 사용하여 단일 포트가 차단될 확률을 낮춤으로써 차단을 어느 정도 완화할 수 있습니다.

- name: "HY2-Hopping"
  type: hysteria2
  server: example.com
  port: 443
  ports: 443,8443,2053,2083,2087,2096
  password: your-password

TUN 모드와 함께 사용하기

QUIC 프로토콜은 TUN 모드에서 잘 작동하지만, DNS 설정이 올바른지 확인해야 합니다. fake-ip 모드를 사용하고 udp 지원을 켜는 것을 권장하며, 그렇지 않으면 일부 QUIC 연결이 DNS 해석 문제로 실패할 수 있습니다.

난독화를 과도하게 중첩하지 않기

QUIC 자체에 이미 TLS 암호화가 있으므로, obfs 난독화를 한 겹 더 씌울 필요가 없습니다. 추가 캡슐화 계층은 오버헤드만 늘리고 성능을 떨어뜨립니다. 트래픽 특징이 걱정된다면 Hysteria2의 Salamander 난독화만으로 충분합니다.

자주 묻는 문제 해결

노드가 시간 초과로 표시되거나 연결할 수 없음

먼저 UDP가 원활한지 확인하세요. 명령줄에서 nc -u example.com 443을 실행하여 UDP 연결성을 테스트합니다. UDP가 차단되어 있다면, 서비스 제공자에게 TCP 폴백 지원 여부를 확인하거나 TCP 계열 프로토콜 노드로 바꿔야 합니다.

Hysteria2 속도가 기대에 못 미침

up/down 파라미터가 너무 낮게 설정되어 있지 않은지 확인하세요. 또한 Brutal 알고리즘은 패킷 손실률이 20%를 초과하면 속도가 크게 떨어집니다. 이는 프로토콜의 문제가 아니라 물리 회선의 한계입니다. 다른 회선의 노드로 전환하여 비교해 보세요.

TUIC가 자주 끊김

congestion-controller를 BBR에서 Cubic으로 바꿔 보세요. udp-relay-mode: native를 사용하고 있다면 quic으로 바꾸는 것도 안정성을 개선할 수 있습니다. 서버 측에서 단일 IP 연결 수를 제한하고 있는지 확인하세요.

두 프로토콜 모두 SS/VMess보다 느림

이는 네트워크 환경이 UDP에 우호적이지 않거나, 노드 서버가 너무 멀다는 의미입니다. QUIC의 장점은 중간~높은 패킷 손실 회선에서만 발휘됩니다. 패킷 손실률이 1% 미만이고 지연이 50ms 미만이라면, 기존 TCP 프로토콜이 오히려 더 안정적일 수 있습니다. 속도 측정 도구로 동일한 노드의 서로 다른 프로토콜을 비교하여 실제로 가장 빠른 것을 선택하세요.

정리

Hysteria2와 TUIC는 프록시 프로토콜이 TCP에서 QUIC로 진화하는 방향을 대표합니다. Hysteria2는 Brutal 혼잡 제어로 극한의 속도를 추구하여 높은 패킷 손실·큰 대역폭 환경에 적합하고, TUIC는 표준 QUIC 혼잡 제어로 균형과 안정성을 추구하여 일상 사용에 적합합니다. 둘 다 Mihomo 코어의 지원이 필요하며, Clash에서 설정이 간단하여 구독이나 설정 파일에 해당 노드를 추가하기만 하면 됩니다.

구독에 여러 프로토콜의 노드를 보관해 두고 실제 네트워크 환경에서 테스트·비교하여, 자신에게 가장 맞는 프로토콜 조합을 찾을 것을 권장합니다. 이 새로운 프로토콜을 코어 버전이 지원하도록, 본 사이트에서 최신 버전 Clash 클라이언트를 받는 것도 잊지 마세요.