2026-09-03 · 프로토콜 해설 · 약 10분

Hysteria2 프로토콜 원리와 사용법: QUIC 혼잡 제어 및 네트워크별 특성

Hysteria2는 QUIC/UDP 기반 전송과 자체 혼잡 제어로 패킷 손실이 많은 네트워크에 대응합니다. 작동 방식과 제약, Shadowrocket에서 선택할 상황을 알아봅니다.

이 글의 핵심

Hysteria2의 효과는 UDP 연결 가능 여부, 패킷 손실 원인, 대역폭 설정에 따라 달라지며 프로토콜을 바꾼다고 반드시 빨라지는 것은 아닙니다. 이미 보유한 서비스 제공업체의 설정 또는 구독이 있는 사용자를 대상으로 QUIC 전송, 혼잡 제어, 설정값 확인, Shadowrocket 라우팅 테스트를 차례로 설명합니다. 프로토콜 제약과 설정 오류, 네트워크 병목을 구분하는 데 도움이 됩니다.

1. Hysteria2와 QUIC, UDP의 관계

Hysteria2는 프록시 프로토콜이고 QUIC은 이를 뒷받침하는 전송 기반이며 UDP는 QUIC 패킷을 전달하는 전송 계층 프로토콜입니다. 서로 다른 계층을 가리키므로 Hysteria2를 ‘모든 요청을 UDP로 바꾸는 것’으로 단순화할 수 없습니다. 앱에서 시작된 TCP 연결은 Hysteria2의 QUIC stream을 통해 전달할 수 있으며, 앱의 UDP 트래픽은 해당 데이터그램 전송 방식으로 전달됩니다.

앱 요청 규칙 매칭 QUIC 캡슐화 UDP 전송 서버 전달

QUIC은 TLS 1.3을 기반으로 암호화 연결을 설정하고 각각 독립된 stream을 제공합니다. 한 stream에서 데이터가 손실되어도 여러 요청이 하나의 TCP 바이트 스트림을 공유할 때처럼 다른 stream까지 동일한 누락 바이트를 기다릴 필요는 없습니다. 다만 각 stream 안에서는 여전히 순서대로 전달해야 하며, 여러 stream은 경로 용량과 혼잡 제어를 공유합니다. 따라서 패킷 손실이 다른 요청에 전혀 영향을 주지 않는다고 단정할 수는 없습니다.

Hysteria2의 외부 연결은 UDP에 의존합니다. 웹에서 HTTPS를 사용할 수 있다고 해서 프록시 연결도 반드시 통과하는 것은 아닙니다. 네트워크에서 TCP 443은 허용하면서 UDP 443은 제한할 수 있으므로, 포트 번호가 같더라도 연결 가능 여부를 각각 확인해야 합니다.

UDP
Hysteria2 외부 전송은 UDP에 의존합니다. TCP 연결 여부로 대체 검증할 수 없습니다.
TLS 1.3
QUIC 암호화 핸드셰이크의 기반이며, 인증서를 올바르게 확인해야 합니다.
443
일반적인 서버 포트 예시이며 Hysteria2가 반드시 사용해야 하는 포트는 아닙니다.

2. 혼잡 제어가 패킷 손실이 많은 경로에 미치는 영향

혼잡 제어는 송신 측이 데이터를 언제, 어느 정도의 속도로 보낼지 결정합니다. 기존의 손실 기반 알고리즘은 패킷 손실을 혼잡 신호로 보고 전송 속도를 낮추는 경우가 많습니다. 하지만 무선 간섭이나 연결 품질 변동도 패킷 손실을 일으킬 수 있습니다. 손실이 경로 용량 부족을 뜻하지 않는다면 지나치게 보수적으로 속도를 낮춰 남은 용량을 활용하지 못할 수 있습니다.

Hysteria2는 Brutal 혼잡 제어를 사용해 설정된 대역폭 목표와 관측된 패킷 손실에 따라 전송 속도를 조정할 수 있습니다. 패킷 손실을 무시하는 방식이 아니라, 손실된 데이터 양을 보정해 유효 처리량을 목표에 가깝게 유지하려고 합니다. QUIC stream의 신뢰성은 확인 응답과 재전송 등의 메커니즘으로 보장됩니다. ‘혼잡 제어 보정’을 손실된 데이터를 복구할 필요가 없다는 뜻으로 이해해서는 안 됩니다.

Mbps와 MB/s도 구분해야 합니다. 일반적으로 Mbps는 초당 메가비트, MB/s는 초당 메가바이트를 뜻합니다. 십진 단위로 환산하면 80 Mbps는 약 10 MB/s이며, 여기에 프로토콜 오버헤드는 포함되지 않습니다. 값을 입력하기 전에 해당 필드의 단위를 확인하고, 다운로드 도구에 표시된 MB/s 값을 Mbps로 그대로 입력하지 마세요.

3. Shadowrocket에서 기존 설정 확인하기

Shadowrocket의 Hysteria2 설정에는 사용자가 이미 보유한 연결 정보를 입력해야 합니다. 먼저 Home에서 해당 항목의 편집 화면을 열고 프로토콜 유형과 서버 매개변수를 확인하세요. 구독에서 생성된 항목이라면 수동으로 수정하기 전에 기존 값을 기록해 두세요. 이후 업데이트에서 로컬 수정 내용이 덮어써질 수 있습니다. 화면 구성은 버전에 따라 달라질 수 있습니다. 아래의 영문 명칭은 매개변수의 의미를 식별하기 위한 것으로, 모든 버전에서 필드가 똑같이 배치된다는 뜻은 아닙니다.

연결 및 인증

Type
항목 이름만 바꾸지 말고 Hysteria2를 선택하세요.
Server
기존 설정에 있는 호스트 이름 또는 IP를 입력하세요.
Port
서버에서 수신 대기하는 UDP 포트와 일치시킵니다. 예: 443
Password
서버의 인증 정보와 일치시킵니다. 임의로 공백이나 줄바꿈을 추가하지 마세요.

포트는 예시일 뿐, 실제 연결 정보는 사용자가 보유한 설정을 기준으로 해야 합니다.

암호화 및 전송

SNI
인증서 검증에 필요한 도메인과 일치해야 합니다.
Certificate
인증서 검증을 유지하고 도메인, 유효 기간, 기기 시간을 먼저 확인하세요.
Obfuscation
설정에서 Salamander를 요구하면 양쪽의 모드와 키를 동일하게 맞추세요.
Bandwidth
업로드와 다운로드 방향 및 단위를 확인하고 실제 용량에 맞춰 설정하세요.

SNI 또는 인증서 설정 오류를 숨기기 위해 인증서 검증을 건너뛰지 마세요.

Server와 SNI는 서로 다른 역할을 할 수 있습니다. Server는 연결 대상 위치를 결정하고, SNI는 TLS 핸드셰이크에서 서버 이름을 전달하며 일반적으로 인증서 이름 확인과 관련됩니다. 연결 주소로 IP를 사용하더라도 인증서에 해당하는 도메인을 설정해야 할 수 있습니다. 인증서 오류가 발생하면 포트를 계속 바꾸기보다 먼저 기기 시간과 도메인이 올바른지 확인하세요.

  1. Home에서 현재 선택된 항목이 테스트하려는 Hysteria2 항목인지 확인하세요. 한 항목을 수정하고 다른 항목으로 연결하는 실수를 방지할 수 있습니다.
  2. 테스트 중에는 Global Routing에서 Proxy를 임시로 선택해 규칙 우회가 결과에 미치는 영향을 줄이세요. 기존 설정을 기록해 두었다가 테스트가 끝나면 복원합니다.
  3. 연결을 설정한 뒤 동일한 테스트 대상에 접속하고, 접속 여부와 첫 응답 시간, 지속 전송 성능을 각각 기록하세요.
  4. 구독을 업데이트했다면 업데이트 후 유형, 포트, 대역폭 필드를 다시 확인해 테스트에 예상한 설정이 적용됐는지 확인하세요.

4. 라우팅을 먼저 확인한 뒤 프로토콜 적용 여부 판단하기

항목에서 Hysteria2를 지원하더라도 모든 요청이 해당 항목을 통과하는 것은 아닙니다. Global Routing에서 Direct를 선택하면 프록시 출구를 사용하지 않습니다. Config는 현재 설정된 규칙에 따라 요청을 처리하고, Proxy는 프록시 라우팅 테스트에 사용합니다. Scene은 현재 장면 설정을 함께 확인해야 합니다. 문제를 해결할 때 라우팅 설정을 먼저 고정하세요. 그렇지 않으면 ‘프로토콜을 바꿨는데 속도가 그대로’인 이유가 요청이 계속 직접 연결되기 때문일 수 있습니다.

아래는 규칙 매칭 순서를 설명하는 최소 예시이며 완전한 연결 설정이 아닙니다. PROXY는 정책 대상이지 Hysteria2라는 규칙 키워드가 아닙니다. 실제로 어떤 출구를 사용하는지는 현재 선택과 설정을 함께 확인해야 합니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

Settings → On Demand는 자동 연결이 시작되는 조건을 제어합니다. 도메인에 Hysteria2를 지정하거나 위 규칙의 순서를 바꾸지는 않습니다. 재현 가능한 연결 과정을 확인하려면 먼저 On Demand 설정을 기록한 뒤 테스트를 수동으로 진행하세요. 네트워크 전환으로 인한 자동 재연결과 매개변수 문제를 구분하기 쉽습니다.

5. 테스트에 적합한 네트워크와 효과를 제한하는 조건

Hysteria2를 테스트하려면 대상 UDP 포트에 연결할 수 있고 사용자가 그에 맞는 서버 설정을 보유해야 합니다. 지연 시간이 길거나 혼잡 이외의 원인으로 패킷 손실이 발생하지만 남은 대역폭이 있는 경로에서 처리량을 확인해 볼 만합니다. 병목이 로컬 Wi-Fi, 서버 출구 또는 대상 웹사이트의 속도 제한에 있다면 프로토콜 자체로 이러한 한계를 없앨 수 없습니다.

  1. 비교 조건을 동일하게 유지: 같은 기기와 네트워크, 같은 대상 파일을 사용하고 비슷한 시간대에 테스트하세요. 구독을 업데이트하거나 여러 매개변수를 동시에 바꾸지 마세요.
  2. 연결 설정과 지속 전송을 따로 확인: 핸드셰이크가 완료되는지 기록한 다음 지속 다운로드 성능을 측정하세요. 연결 테스트 성공은 특정 탐색이 성공했다는 뜻일 뿐, 전체 처리량 측정을 대신하지 않습니다.
  3. 부하가 걸릴 때 지연 시간 확인: 다운로드 중 웹 응답도 함께 확인하세요. 처리량은 약간 높아졌지만 상호작용이 눈에 띄게 느려진다면 대역폭 목표가 너무 높거나 대기열 혼잡이 발생했을 수 있습니다.
  4. 접속 네트워크를 바꿔 재확인: 같은 설정이 Wi-Fi에서는 실패하고 셀룰러에서는 성공한다면 접속 네트워크의 UDP 정책, NAT 또는 경로 품질 차이가 원인일 수 있습니다. 그렇다고 설정이 반드시 올바르다는 뜻은 아닙니다.
  5. 한 번에 하나만 변경: 먼저 연결 가능 여부를 확인하고, 다음으로 인증 및 인증서를 점검한 뒤 마지막으로 대역폭을 조정하세요. 변경할 때마다 동일한 테스트 조건으로 되돌려 비교합니다.

6. 자주 묻는 질문과 확인 순서

다른 연결은 되는데 Hysteria2는 계속 시간 초과되는 이유는 무엇인가요?

먼저 Home에서 Server와 Port를 확인한 다음 서버의 해당 UDP 포트에 연결할 수 있는지 확인하세요. TCP 연결 성공만으로 UDP가 허용된다고 볼 수 없습니다. 설정을 유지한 상태에서 다른 접속 네트워크로 재시험하세요. 네트워크에 따라 결과가 달라진다면 인증 정보나 서버의 수신 대기 상태보다 네트워크 정책을 먼저 확인합니다.

대역폭 값을 높게 설정할수록 더 빨라지나요?

아닙니다. 먼저 필드의 단위와 업로드·다운로드 방향을 확인하고, 사용자가 직접 안정적으로 측정한 값을 기준으로 조금씩 조정하세요. 목표를 높인 뒤 지연 시간이 크게 늘고 유효 처리량은 개선되지 않았다면 계속 값을 높이지 말고 이전 설정으로 되돌리세요.

연결은 됐는데 왜 접속 결과가 직접 연결한 것처럼 보이나요?

Home에서 선택된 항목을 확인한 다음 Global Routing을 점검하세요. 우선 Proxy로 테스트 기준을 잡으세요. Config로 되돌렸을 때 동작이 달라진다면 Config에서 대상이 DIRECT에 먼저 매칭되는지, FINAL이 예상한 정책을 사용하는지 확인하세요.

네트워크를 바꾼 뒤 연결이 끊겼습니다. 매개변수를 모두 다시 입력해야 하나요?

먼저 매개변수를 바꿀 필요는 없습니다. 새 네트워크에서 연결이 가능한지 확인하고 터널을 다시 설정한 뒤 Settings → On Demand의 트리거 조건을 점검하세요. QUIC에는 연결 마이그레이션 관련 기능이 있지만 연결이 계속 유지되는지는 구현, NAT, 경로 정책에 따라 달라집니다. 네트워크를 바꿔도 연결이 끊기지 않는다고 보장하는 기능은 아닙니다.

먼저 UDP 연결 가능 여부를 확인하고 인증, 인증서, 라우팅을 점검한 뒤 혼잡 제어와 대역폭 목표를 살펴보세요. 같은 조건에서 처리량과 지연 시간, 실패 양상을 기록해야 현재 경로에 Hysteria2가 적합한지 판단할 수 있습니다. Shadowrocket은 폐쇄형 상용 앱이며 앱을 일회성으로 구매하는 것과 회선 요금제는 별개입니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다.

App Store 정품 확인