Hysteria2는 QUIC을 기반으로 하며 UDP를 통해 연결을 전송합니다. 지연 시간이 길고 무작위 패킷 손실이 발생하는 일부 경로에서 처리량을 높일 수 있지만, UDP 연결이 가능하고 대역폭을 적절히 설정했으며 서버에 충분한 여유가 있어야 합니다. 자체 서비스와 구독을 이용하며 Shadowrocket에서 Hysteria2를 사용하려는 분을 위해 프로토콜 원리, 적합한 환경, 연결 확인 및 문제 해결 방법을 설명합니다. 프로토콜 이름만으로 속도가 보장되는 것은 아닙니다.
Hysteria2, QUIC, UDP의 역할
Shadowrocket에서 Hysteria2는 선택 가능한 연결 프로토콜입니다. 하위 전송 계층으로 QUIC을 사용하며, QUIC은 보통 UDP로 패킷을 전송합니다. 따라서 접속하려는 웹사이트가 HTTPS를 사용하더라도 기기와 Hysteria2 서버 사이의 전송까지 TCP를 사용한다는 뜻은 아닙니다. 문제를 해결할 때는 프록시 전송과 대상 웹사이트 연결을 구분해야 합니다.
UDP는 데이터가 순서대로 도착하도록 보장하지 않으며 재전송도 처리하지 않습니다. QUIC은 UDP 위에서 암호화 핸드셰이크, 신뢰성 있는 스트림, 패킷 손실 복구, 흐름 제어를 구현합니다. Hysteria2는 이러한 기능을 이용해 프록시 트래픽을 전달하고 자체 인증, 전달 및 혼잡 제어 방식을 결합합니다. 이를 단순히 “UDP는 재전송하지 않으니 더 빠르다”고 이해하는 것은 정확하지 않습니다.
포트는 본인의 서버 정보와 일치해야 합니다. 예를 들어 서버가 443/UDP로 설정되어 있다면 해당 UDP 포트에 연결할 수 있어야 합니다. 443/TCP 연결만 확인해서는 Hysteria2가 작동한다고 볼 수 없습니다. 포트 번호가 같더라도 프로토콜은 다를 수 있으며, 일반 HTTPS 서버를 Hysteria2 서버로 사용할 수는 없습니다.
패킷 손실이 많은 환경에서 더 빠를 수 있는 이유: 손실 원인부터 구분하기
일반적인 손실 기반 혼잡 제어는 패킷 손실을 네트워크 혼잡 신호로 간주하고 전송 속도를 낮춰 큐에 가해지는 부담을 줄입니다. 하지만 무선 간섭이나 링크 품질 변동으로 생기는 무작위 패킷 손실이 대역폭 포화를 뜻하는 것은 아닙니다. 왕복 지연 시간이 긴 경로에서는 속도를 낮춘 뒤 서서히 회복하는 동안 사용 가능한 대역폭을 충분히 활용하지 못할 수 있습니다.
Hysteria2의 대역폭 설정과 혼잡 제어 방식은 이런 성능에 영향을 줍니다. 대역폭 추정 기반의 Brutal 모드에서는 패킷이 손실될 때마다 기존 방식처럼 단순히 전송량을 줄이지 않고, 설정된 대역폭과 손실 상황을 함께 고려해 전송합니다. 일부 무작위 손실 경로에서 처리량을 개선할 수 있지만 물리적인 대역폭을 늘려 주지는 않습니다. 실제 제어 방식은 클라이언트 구현, 매개변수 및 서버 설정에 따라 달라집니다.
- 무작위 패킷 손실: 신호 간섭이나 링크 오류로 간헐적인 손실이 발생하지만 경로에 여유 용량이 남아 있는 경우로, 성능 개선을 기대할 수 있습니다.
- 혼잡으로 인한 패킷 손실: 업로드 또는 다운로드가 이미 포화된 상태입니다. 전송량을 계속 늘리면 지연 시간이 더 길어져 다른 트래픽에 영향을 줄 수 있습니다.
- UDP 속도 제한 또는 차단: 네트워크가 UDP에 별도의 제한을 적용한다면 QUIC 기반 프로토콜로 바꿔도 제한이 해소되지는 않습니다.
- 서버 병목: 회선 대역폭, 처리 성능 또는 대상 사이트의 속도 제한을 각각 확인해야 합니다. 로컬 설정만 바꿔서는 해결되지 않을 수 있습니다.
판단 기준: UDP 연결을 확인한 뒤 부하 시 지연을 관찰하세요
연결은 되지만 대용량 파일을 전송하기 시작하자 웹페이지가 눈에 띄게 느려진다면 대역폭 설정을 낮춰 다시 테스트하세요. 핸드셰이크조차 완료되지 않는다면 대역폭 값을 계속 높이기보다 UDP 연결 가능 여부부터 확인해야 합니다.
QUIC의 다중 스트림은 서로 다른 신뢰성 있는 스트림 사이에서 전송 계층의 헤드오브라인 블로킹을 줄일 수도 있습니다. 한 스트림의 데이터가 누락되어도 다른 스트림이 동일한 TCP 바이트 스트림의 복구를 기다릴 필요는 없습니다. 다만 모든 스트림이 같은 경로와 혼잡 상태를 공유하므로 모든 웹페이지가 더 빨라지거나 고지연이 사라진다고 단정할 수는 없습니다.
테스트해 볼 만한 네트워크와 먼저 확인해야 할 조건
프로토콜은 현재 네트워크 조건에 맞춰 선택해야 합니다. 서버 위치, 테스트 대상, 시간대, Global Routing 설정을 동일하게 유지하면서 연결 성공률과 지속 전송 성능을 관찰하세요. 위치가 다른 서버에서 Hysteria2와 다른 프로토콜을 비교한 뒤 차이를 모두 QUIC의 효과로 돌려서는 안 됩니다.
| 네트워크 환경 | 예상되는 현상 | 먼저 할 일 |
|---|---|---|
| 지연 시간이 길고 무작위 패킷 손실이 발생하는 환경 | 지속 전송에서 대역폭을 더 충분히 활용할 수 있음 | UDP 연결을 확인하고 유휴 상태와 부하 상태의 지연 시간을 기록하세요 |
| 패킷 손실이 적고 안정적인 Wi-Fi | 뚜렷한 개선이 없을 수도 있음 | 같은 대상의 로딩 시간과 안정성을 비교하세요 |
| UDP가 제한된 네트워크 | 핸드셰이크 시간 초과 또는 연결이 반복해서 끊김 | Wi-Fi와 셀룰러 네트워크를 바꿔 가며 확인하세요 |
| 다른 작업이 업로드 대역폭을 모두 사용 중인 환경 | 요청 전송이 느려지고 조작이 버벅임 | 백그라운드 업로드를 중지한 뒤 같은 테스트를 다시 실행하세요 |
셀룰러 네트워크에서 발생하는 변동은 기지국 부하와 신호 변화 때문일 수도 있습니다. 속도 측정 한 번으로 프로토콜의 우위를 입증할 수는 없습니다. 비슷한 조건에서 세 번 반복하고 연결 성공 여부, 페이지가 완전히 로드되는지, 대용량 파일 전송이 지속되는지를 각각 기록하세요. 구체적인 개선률은 실제 경로에서 측정해야 하므로 이 문서에서는 고정된 수치를 제시하지 않습니다.
Shadowrocket에서 Hysteria2 연결 확인하기
아래 단계는 본인의 서비스와 구독 정보가 이미 있는 경우를 전제로 합니다. 테스트 중 서버 주소, 인증 정보, 대역폭 값을 동시에 바꾸지 않도록 제공업체가 안내한 전체 매개변수나 이미 가져온 항목을 사용하세요. Hysteria와 Hysteria2는 이름만 바꿔 서로 변환할 수 없습니다. 항목이 Hysteria2로 설정되어 있는지 확인하세요.
-
항목 확인
Home으로 이동해 기존 서버 항목의 편집 화면을 열고 Type이 Hysteria2인지 확인하세요. 본인의 설정 정보와 대조해 서버 주소, 포트, 인증 정보를 확인합니다. SNI 또는 난독화 매개변수가 있다면 해당 값도 일치해야 합니다.
-
서버 선택
Home으로 돌아가 해당 서버를 선택하고 선택 표시가 테스트할 항목에 있는지 확인하세요. 구독에 항목이 여러 개 있다면 선택한 이름을 먼저 기록해 두어야 이후 결과가 다른 연결에서 나온 것으로 혼동되지 않습니다.
-
라우팅 설정 고정
Home → Global Routing을 열고 비교 테스트 중에는 Proxy를 선택해 요청이 프록시를 거치도록 합니다. 한 번의 테스트 도중 Config와 Proxy를 번갈아 전환하지 마세요.
-
연결 설정
Home에서 연결 스위치를 켭니다. 처음 사용할 때는 시스템 안내에 따라 VPN 구성 추가를 허용한 다음 Home → Connectivity Test를 실행하세요. 실패하면 핸드셰이크, 인증, UDP 경로부터 확인합니다.
-
실제 트래픽 확인
같은 웹페이지를 열고 지속 전송을 한 번 실행해 시간 초과나 중단 여부, 부하 중 조작 반응의 변화를 기록하세요. 완료한 뒤 Home → Global Routing으로 돌아가 평소 사용하는 Config 또는 기존 설정으로 복원합니다.
Connectivity Test는 연결 상태를 확인하는 단서이지, 전체 처리량 테스트가 아닙니다. 테스트 성공은 해당 시점에 탐지가 완료되었다는 뜻일 뿐, 모든 도메인, UDP 트래픽 또는 대용량 전송이 가능한 것을 보장하지 않습니다. 탐지는 성공했지만 특정 웹페이지가 열리지 않는다면 규칙, DNS, 대상 사이트를 계속 확인하세요.
Global Routing으로 프로토콜 문제와 규칙 문제 구분하기
Hysteria2는 프록시 연결의 전송 방식을 결정하고, Global Routing은 요청의 경로를 선택합니다. 두 기능은 서로 다른 계층에 있습니다. Config에 DOMAIN-SUFFIX,example.com,DIRECT 규칙이 있으면 일치하는 요청은 직접 연결됩니다. 따라서 Hysteria2 서버를 선택했더라도 해당 요청이 그 서버를 거친다는 뜻은 아닙니다.
일상적인 사용: Config
권장현재 Config의 규칙에 따라 전략을 선택하며 결과는 DIRECT, REJECT 또는 프록시 전략이 될 수 있습니다. 연결 상태를 해석하려면 테스트 대상이 어떤 규칙과 일치했는지 확인해야 합니다.
적합한 경우: 규칙 설정이 있으며 대상별로 트래픽을 분기하는 일상적인 사용
임시 문제 해결: Proxy
트래픽을 프록시로 처리해 규칙 분기가 테스트에 미치는 영향을 줄입니다. Proxy에서는 대상에 접속되지만 Config에서는 되지 않는다면 규칙 일치 여부와 선택한 전략을 중점적으로 확인하세요.
적합한 경우: 프록시 경로를 잠시 확인하거나 Config 규칙의 영향을 분리할 때
직접 연결 기준선: Direct
대상에 직접 연결하며 Hysteria2 터널 성능을 확인하는 용도는 아닙니다. 로컬 네트워크에서 대상에 직접 연결했을 때의 성능을 기록하면 대상 사이트 문제를 해결하는 데 참고할 수 있습니다.
적합한 경우: 로컬 네트워크에서 대상 사이트에 직접 접속할 수 있는지 확인할 때
Global Routing에는 Scene도 포함되어 있으며 기존 Scene 설정에 따라 동작을 선택할 수 있습니다. 프로토콜 성능을 비교할 때는 불필요한 Scene 전환을 추가하지 않는 것이 좋습니다. 규칙 문제를 확인하려면 DOMAIN-SUFFIX, IP-CIDR, GEOIP의 순서와 최종 FINAL 전략을 살펴보세요. 규칙의 의미는 규칙 매뉴얼에서 더 확인할 수 있습니다.
연결 시간 초과, 불안정한 속도, 대역폭 설정 관련 자주 묻는 질문
같은 항목이 셀룰러에서는 연결되지만 Wi-Fi에서는 계속 시간 초과되나요?
서버와 Global Routing 설정을 그대로 둔 채 두 네트워크에서 각각 Home → Connectivity Test를 실행하세요. 차이가 반복해서 나타나면 Wi-Fi 네트워크의 UDP 제한, 라우터 정책, 로그인 인증 상태부터 확인하세요. 이 현상만으로 인증 정보가 잘못되었다고 단정할 수는 없습니다.
대역폭 값은 높게 설정할수록 더 빠른가요?
그렇지 않습니다. 대역폭 설정은 전송 제어에 사용되며 대역폭을 구매하거나 속도 제한을 해제하는 스위치가 아닙니다. 먼저 입력란의 단위를 확인해 Mbps와 MB/s를 구분하세요. 두 단위는 8배 차이가 납니다. 현재 지속해서 사용할 수 있는 용량을 기준으로 보수적으로 설정하고, 한 번에 한 방향의 값만 바꾼 뒤 부하 시 지연과 연결 중단 여부를 살펴보세요.
네트워크를 바꾼 뒤 연결이 끊기고, 연결을 껐다 켜야 복구되나요?
먼저 Home에서 연결 스위치를 껐다가 다시 켜고 Connectivity Test를 실행하세요. QUIC에는 연결 마이그레이션 관련 기능이 있지만 실제 복구 여부는 구현, 네트워크 주소 변경, 시간 초과의 영향을 받습니다. Settings → On Demand가 활성화되어 있는지도 확인하세요. On Demand는 필요할 때 연결을 관리하는 기능이며, 제한된 UDP 경로를 연결 가능하게 만들지는 않습니다.
인증서 오류가 발생하면 검증을 건너뛰어도 되나요?
먼저 기기의 시간, 서버 도메인, SNI, 서버 인증서가 서로 일치하는지 확인하고 본인의 설정 제공업체에 문의하세요. 인증서 검증을 건너뛰면 신원 확인이 약해지므로 일반적인 속도 개선이나 문제 해결 방법으로 사용해서는 안 됩니다. 인증서 오류와 혼잡 제어는 서로 다른 문제입니다.
원인을 파악하기 어렵다면 사용 중인 네트워크, Type, 서버 포트, Global Routing 설정, 연결 단계와 지속 전송 단계 중 어느 시점에 실패하는지 정리하세요. 문제 해결 기록을 공유하기 전에는 비밀번호, 구독 token, 전체 구독 주소를 삭제하고 재현에 필요한 현상만 남기세요.