Hysteria2는 UDP 기반 QUIC 전송을 사용하며, UDP를 사용할 수 있는 환경에서 지연이 크거나 무작위 패킷 손실이 있는 회선을 비교 테스트할 때 활용할 수 있습니다. 다른 프로토콜보다 항상 빠른 것은 아니며 모든 UDP 제한을 우회할 수도 없습니다. 서비스 제공업체와 구독 정보를 이미 보유한 Shadowrocket 사용자를 위해 전송 원리, 대역폭 설정, 가져온 설정 확인 방법, 규칙 문제와 인증 실패 및 네트워크 제한을 구분하는 방법을 설명합니다.
Hysteria2, QUIC, UDP의 관계
Hysteria2는 프록시 프로토콜이고, QUIC은 Hysteria2가 사용하는 전송 기반이며, UDP는 QUIC 패킷을 전달합니다. 세 요소는 서로 다른 계층에 있습니다. 앱 요청은 프록시로 캡슐화된 뒤 QUIC 연결을 통해 서버로 전송됩니다. 기반 전송에 UDP를 사용한다고 해서 Hysteria2가 패킷 손실을 처리하지 않고 데이터만 보내는 통신 경로라고 이해해서는 안 됩니다.
UDP 자체는 전송 순서나 안정적인 전달을 보장하지 않지만, QUIC은 UDP 위에서 연결 관리, 신뢰성 있는 스트림, 패킷 손실 복구 및 혼잡 제어를 구현합니다. 원래 TCP를 사용하는 웹 트래픽도 프록시를 통해 QUIC 스트림으로 전달할 수 있습니다. 서비스 트래픽이 UDP를 사용하는지 여부와 클라이언트에서 서버까지의 연결이 UDP를 사용하는지는 별개의 문제입니다.
QUIC은 HTTP/3와 밀접한 관련이 있지만 둘을 같은 것으로 볼 수는 없습니다. QUIC을 사용한다고 해서 모든 프록시 트래픽이 일반 웹 요청으로 바뀌거나 네트워크 관리 장비가 반드시 이를 허용하는 것은 아닙니다. 브라우저에서 TCP 443으로 웹사이트가 열린다고 해서 같은 주소의 UDP 443으로 Hysteria2 연결을 설정할 수 있다고 단정할 수도 없습니다.
더 빠를 수 있는 이유: 복구 방식과 혼잡 제어
‘빠르다’는 말은 핸드셰이크 시간, 첫 응답, 지속 처리량, 상호작용 안정성으로 나눠 살펴봐야 합니다. QUIC은 보안 핸드셰이크를 통합하고 여러 독립 스트림을 지원합니다. 한 스트림에서 손실된 데이터를 기다리는 동안 다른 스트림은 동일한 전송 계층의 순서 있는 바이트 스트림 때문에 모두 대기할 필요가 없습니다. 다만 각 스트림은 연결의 혼잡 제어와 실제 회선 용량을 공유하므로 서로 완전히 독립적이지는 않습니다.
Hysteria2의 처리량은 혼잡 제어 방식에도 영향을 받습니다. 프로토콜 체계는 목표 대역폭을 기반으로 하는 Brutal 방식과 BBR 계열 혼잡 제어를 지원할 수 있습니다. 실제 동작은 클라이언트 구현, 대역폭 매개변수 및 서버 제한에 따라 달라집니다. 프로토콜 이름만 보고 현재 연결에 적용된 알고리즘을 단정해서는 안 됩니다. 특정 구현의 선택 옵션이 Shadowrocket에도 반드시 존재한다고 여겨서도 안 됩니다.
- 무작위 패킷 손실: 회선에 여유 용량이 남아 있다면 더 적극적인 전송·복구 방식으로 처리량을 높게 유지할 수 있습니다. 그렇다고 데이터를 재전송하지 않는다는 뜻은 아닙니다.
- 실제 혼잡: 병목 구간이 이미 포화된 상태에서 전송량을 더 늘리면 대기열과 패킷 손실, 지연이 커져 통화와 웹 이용에 영향을 줄 수 있습니다.
- 왕복 지연이 큰 경우: 핸드셰이크와 패킷 손실 복구에 필요한 대기 시간이 더 두드러집니다. 프로토콜의 작동 방식이 사용 경험을 개선할 수는 있지만, 물리적 거리와 우회 경로로 인한 지연을 없애지는 못합니다.
- 서버 속도 제한: 서버의 대역폭, 부하 및 외부 연결 제한이 여전히 상한입니다. 클라이언트에 입력하는 값을 높여도 서버의 실제 용량은 늘어나지 않습니다.
테스트해 볼 만한 환경과 먼저 네트워크를 확인해야 하는 경우
지연이 크고 패킷 손실이 불규칙하며 UDP에 연결할 수 있는 환경은 Hysteria2를 테스트해 볼 만한 조건이지, 속도를 보장하는 조건은 아닙니다. 가정용 인터넷, 공용 Wi-Fi, 셀룰러 네트워크는 UDP를 서로 다르게 처리할 수 있습니다. 같은 서버 회선도 접속 네트워크에 따라 안정적으로 전송되거나, 잠시만 연결되거나, 계속 시간 초과가 발생할 수 있습니다.
| 네트워크 증상 | 우선 확인할 사항 | 점검 방법 |
|---|---|---|
| 지연이 크고 간헐적으로 패킷 손실 발생 | 비교 테스트에 적합할 수 있으나 UDP 사용 가능 여부를 확인해야 합니다 | 서버와 테스트 대상을 고정하고 첫 응답, 처리량, 연결 중단 횟수를 각각 기록합니다 |
| 웹사이트는 바로 열리지만 Hysteria2는 계속 시간 초과 | TCP 연결이 가능해도 UDP 연결까지 가능한 것은 아닙니다 | 실제 UDP 포트를 확인한 뒤 Wi-Fi와 셀룰러 네트워크에서 각각 다시 테스트합니다 |
| 다운로드가 빠르게 시작된 뒤 크게 느려짐 | 대기열 누적, 속도 제한 또는 서버 부하일 수 있습니다 | 다른 다운로드를 중단하고 대역폭 입력값을 확인한 뒤 같은 파일로 다시 테스트합니다 |
| 지연이 낮고 패킷 손실이 적으며 현재 연결이 안정적 | 프로토콜을 바꿔도 이점이 없을 수 있습니다 | 한 번의 최고 속도보다 안정성을 우선 비교합니다 |
| 네트워크를 바꾸면 연결이 끊김 | 주소 변경, NAT 상태 또는 네트워크 정책이 연결에 영향을 줄 수 있습니다 | 연결을 다시 설정하고 로그를 확인합니다. QUIC의 연결 마이그레이션 기능이 끊김 없는 연결을 보장한다고 가정하지 마세요 |
결론: UDP 연결 여부를 확인한 뒤 처리량을 비교하세요
같은 설정이 셀룰러 네트워크에서는 작동하지만 현재 Wi-Fi에서 계속 시간 초과가 발생한다면, 먼저 네트워크별 차이를 기록하고 UDP가 허용되는지 확인하세요. 이때 대역폭 값을 계속 높여도 연결 설정 실패는 해결되지 않습니다.
Shadowrocket에 Hysteria2를 가져오고 설정 확인하기
구독 정보와 연결 매개변수는 서비스 제공업체에서 받아야 합니다. 직접 옮겨 적다가 발생하는 오류를 줄이려면 제공업체가 안내한 기존 설정을 가져오는 것이 좋습니다. 구독을 업데이트해도 서버에 반드시 연결할 수 있는 것은 아닙니다. 업데이트 후에는 현재 선택한 항목과 프로토콜, 인증 정보가 그대로인지도 확인하세요.
-
구독 가져오기
Home 오른쪽 상단의 “+”를 선택하고 Add Server로 이동한 다음 Type을 Subscribe로 설정합니다. 본인의 구독 주소를 입력해 저장하세요. Home으로 돌아와 해당 구독을 업데이트한 뒤 생성된 항목을 확인합니다.
-
프로토콜 확인
Home에서 대상 항목의 편집 화면을 열고 Type이 Hysteria2인지 확인한 다음 서버 주소, 포트 및 인증 정보를 하나씩 확인합니다. 이전 프로토콜의 비밀번호나 포트를 새 항목에 그대로 사용하지 마세요.
-
보안 설정 확인
서비스 제공업체가 안내한 값에 따라 TLS, SNI 및 선택적 난독화 매개변수를 확인하세요. 연결 주소와 인증서에 사용된 도메인이 서로 다를 수 있으므로 SNI는 서버 요구사항에 맞아야 합니다. 인증서 오류가 발생하면 도메인, 기기 시간 및 인증서 체인을 먼저 확인하세요.
-
테스트 경로 고정
Home → Global Routing에서 잠시 Proxy를 선택하고 테스트할 Hysteria2 항목을 지정합니다. Config 규칙 때문에 테스트 요청이 DIRECT로 전달되는 상황을 줄일 수 있습니다. 테스트가 끝나면 원래 사용하던 설정으로 되돌리세요.
-
연결 결과 기록
연결한 뒤 고정된 테스트 대상에 접속해 연결이 설정되는지, 첫 응답이 눈에 띄게 지연되는지, 전송이 중단되는지 각각 기록하세요. 연결이 자동으로 다시 설정된다면 Settings → On Demand도 확인해 필요 시 연결 동작을 수동 조작 실패로 오해하지 않도록 합니다.
포트는 서버 설정과 일치해야 합니다. 예를 들어 서버가 UDP 443을 사용한다면 항목의 포트가 443인지 확인하고, 서버에서 해당 UDP 포트도 허용하는지 확인하세요. 난독화 비밀번호가 제공된 경우 연결 인증 비밀번호와 용도가 다를 수 있으므로 임의로 바꿔 사용하면 안 됩니다. 문제를 해결하겠다며 인증서 검증을 장기간 해제하지 마세요. 먼저 일치하지 않는 매개변수를 수정해야 합니다.
Global Routing 설정과 프로토콜 성능 구분하기
프로토콜은 클라이언트와 서버 사이의 전송 방식을 결정하고, Global Routing은 요청이 프록시 경로로 전달될지 결정합니다. Home → Global Routing의 Proxy, Direct, Config, Scene은 네 가지 프로토콜이 아닙니다. Scene의 동작은 기존 시나리오 설정에 따라 달라집니다. 점검할 때는 실제 적용 중인 설정을 먼저 확인해 테스트 도중 경로가 조건에 따라 바뀌지 않도록 하세요.
Config
권장현재 Config에 설정된 규칙에 따라 요청을 처리합니다. 대상이 DIRECT 규칙에 해당하면 Hysteria2 항목을 선택했더라도 해당 연결을 자동으로 사용하지 않습니다. 규칙을 확인한 뒤 평소에 사용하기에 적합합니다.
적합한 용도: 규칙을 확인한 뒤 대상별로 분리해 일상적으로 사용
Proxy
요청을 현재 프록시 경로로 전달하므로 테스트 중 Config 규칙의 영향을 잠시 줄이는 데 적합합니다. 선택한 항목과 트래픽 경로에 영향을 줄 수 있는 다른 설정도 확인해야 합니다.
적합한 용도: 프록시 항목을 고정해 프로토콜 연결을 짧게 점검
Direct
직접 연결 경로를 사용하므로 Hysteria2 서버의 처리량을 측정할 수 없습니다. 로컬 접속 네트워크를 비교하는 데는 도움이 되지만, 대상 자체에 연결할 수 있는지도 결과에 영향을 줍니다.
적합한 용도: 로컬 네트워크와 직접 연결 대상의 정상 여부 확인
Config에서 DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 IP 주소 대역으로, GEOIP는 IP 주소 위치 데이터베이스로 요청을 매칭합니다. FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 규칙 순서와 각 규칙의 정책이 함께 경로를 결정합니다. 테스트 대상이 DIRECT에 매칭된다면 Hysteria2 탓으로 돌리기 전에 규칙부터 확인하세요.
자주 묻는 질문: 시간 초과, 인증서, 대역폭 설정
같은 항목인데 Wi-Fi를 바꾸면 왜 시간 초과가 발생하나요?
먼저 항목 매개변수를 그대로 둔 채 Wi-Fi와 셀룰러 네트워크에서 각각 연결을 다시 설정하세요. 한 네트워크에서만 실패한다면 발생 시간, 서버 포트, 오류 메시지를 기록한 뒤 해당 네트워크가 UDP를 제한하는지 확인합니다. 웹사이트가 열리는지만으로 UDP 연결이 가능하다고 판단하지 마세요.
인증서 오류가 표시되면 무시해도 되나요?
먼저 기기 시간을 확인한 뒤 서비스 제공업체가 안내한 SNI와 인증서 도메인을 비교하세요. 연결 주소가 IP라고 해서 인증서도 해당 IP와 일치해야 한다고 단정할 수는 없습니다. 그래도 일치하지 않으면 서비스 제공업체에 설정을 확인하고, 검증을 계속 건너뛰는 방식으로 해결하려 하지 마세요.
대역폭을 크게 설정할수록 다운로드가 빨라지나요?
그렇지 않습니다. 먼저 입력 단위와 업로드·다운로드 방향이 클라이언트 기준에 맞는지 확인하세요. 서비스 제공업체가 안내한 값이나 실제 회선에 맞는 보수적인 값을 사용해 테스트하고, 한 번에 하나씩만 조정하면서 웹 응답과 지속 다운로드 속도를 살펴보세요. 순간 최고 속도만 확인하지 마세요.
지연 시간 테스트에는 수치가 나오는데 웹사이트가 열리지 않는 이유는 무엇인가요?
테스트 결과가 대상 웹사이트의 전체 요청 과정을 확인하지 못할 수 있습니다. Home으로 돌아가 선택한 항목을 확인한 다음 Global Routing을 점검하세요. 규칙의 영향을 배제해야 한다면 잠시 Proxy를 사용합니다. 이후 DNS 조회 오류, TLS 오류, 연결 시간 초과를 구분하고 오류 유형에 맞게 설정을 확인하세요.
재현 가능한 비교 테스트하기
프로토콜을 비교할 때는 한 번에 하나의 변수만 바꾸는 것이 좋습니다. 서버, 외부 연결 경로, 테스트 시간이 다르면 속도 차이를 QUIC의 영향으로 단정할 수 없습니다. 서비스 제공업체가 여러 프로토콜 연결을 제공하더라도 같은 회선과 같은 대역폭 제한을 사용하는지 먼저 확인하세요. 이러한 조건이 맞지 않으면 테스트 결과는 두 연결의 종합적인 차이만 보여줍니다.
- 환경 고정: 같은 기기와 접속 네트워크, 테스트 대상을 사용하고 백그라운드 업데이트와 대용량 작업은 일시 중지합니다.
- 반복 측정: 각 조건에서 최소 세 번 테스트하고 날짜와 시간대, 첫 응답, 지속 속도 및 실패 횟수를 기록합니다. 이는 기록을 권장하는 항목이며, 이 글에서 실제 측정 결과를 주장하는 것은 아닙니다.
- 부하 시 지연 확인: 지속적으로 다운로드하면서 일반 웹페이지도 열어 보세요. 처리량은 늘었지만 상호작용이 눈에 띄게 느려진다면 목표 대역폭과 회선의 대기열을 확인합니다.
- 오류 유형별 기록: 시간 초과, 인증 실패, 인증서 오류, 전송 중단을 각각 기록하고 모든 실패를 ‘속도 저하’로 뭉뚱그리지 마세요.
- 인증 정보 보호: 기록을 공유하기 전에 구독 주소의 token, 인증 비밀번호, 난독화 비밀번호를 삭제하고 문제 해결에 필요한 네트워크 및 오류 정보만 남기세요.
최종 선택은 현재 네트워크에서 반복해 확인할 수 있는 결과를 기준으로 하세요. 처리량의 이점을 논하려면 UDP 연결이 가능하고, 매개변수가 올바르며, 지속 전송이 안정적이어야 합니다. Hysteria2는 이미 보유한 서비스 설정에서 선택할 수 있는 전송 방식 중 하나입니다. 패킷 손실이나 지연이 크다는 점은 테스트할 이유일 뿐, 반드시 더 빠르다는 뜻은 아닙니다.