Hysteria2는 UDP를 통해 QUIC을 사용하며, 해당 서비스를 제공하는 업체를 이용할 수 있을 때 지연 시간이 길고 패킷 손실이 발생하는 네트워크 경로를 살펴보는 데 적합합니다. 이 글에서는 속도 향상이 가능한 조건, 대역폭 및 인증서 매개변수 확인법, Shadowrocket에서 프로토콜 오류와 규칙 문제, 배터리 소모 변화를 구분하는 순서를 설명합니다. 프로토콜 이름만으로 속도가 보장되는 것은 아닙니다.
Hysteria2와 QUIC의 관계
Hysteria2는 프록시 프로토콜이고 QUIC은 Hysteria2가 사용하는 하위 전송 기반입니다. Shadowrocket에서 Hysteria2를 선택하면 클라이언트가 해당 프로토콜을 지원하는 서버에 연결하고, 양쪽에서 동일한 인증 및 전송 매개변수를 사용해야 합니다. 기존 설정에서 Type만 Hysteria2로 바꾼다고 서버가 자동으로 지원하는 것은 아닙니다.
QUIC은 UDP를 기반으로 하지만, ‘UDP 기반’이라는 말이 모든 신뢰성 처리를 애플리케이션에 맡긴다는 뜻은 아닙니다. QUIC은 암호화 핸드셰이크, 신뢰성 있는 스트림, 패킷 손실 감지 및 재전송 등을 자체적으로 제공합니다. Hysteria2는 이러한 기능을 활용해 프록시 트래픽을 전달합니다. 대상 웹사이트가 TCP를 사용하더라도 클라이언트와 프록시 서버 사이의 구간은 QUIC으로 전송될 수 있으므로 두 전송 계층을 구분해서 이해해야 합니다.
QUIC이 HTTP/3와 같은 것은 아닙니다. HTTP/3는 QUIC에서 동작하는 HTTP 매핑이며, Hysteria2는 자체 인증 및 프록시 데이터 전달 방식을 사용합니다. 브라우저로 특정 HTTPS 페이지에 접속할 수 있다는 사실은 해당 페이지의 접속 경로가 동작한다는 것만 보여 줍니다. 같은 주소의 Hysteria2 인증, UDP 포트 및 데이터 전달까지 정상이라는 뜻은 아닙니다.
패킷 손실이 있는 경로에서 더 빠를 수 있는 이유
속도 차이는 주로 혼잡 제어, 패킷 손실 복구, 다중화가 함께 작용한 결과입니다. 기존 TCP 혼잡 제어는 일반적으로 패킷 손실을 네트워크 혼잡 신호로 보고 전송 윈도우를 줄입니다. 패킷 손실의 주된 원인이 무선 간섭이나 경로 품질이고 출구 구간이 혼잡한 것이 아니라면, 전송량을 줄이는 과정에서 사용 가능한 대역폭을 충분히 활용하지 못할 수 있습니다. Hysteria2는 대역폭 매개변수와 혼잡 제어 메커니즘을 통해 이러한 경로에 다른 전송 방식을 제공합니다.
QUIC의 독립 스트림 방식은 스트림 간의 헤드 오브 라인 블로킹도 줄일 수 있습니다. 한 스트림의 데이터 일부가 손실되어도 다른 모든 스트림이 해당 데이터의 재전송을 기다릴 필요는 없습니다. 다만 하나의 연결에 속한 스트림은 여전히 경로 용량을 공유하고 혼잡 제어의 영향을 함께 받을 수 있으며, 신뢰성 있는 스트림 내부 데이터는 순서대로 전달되어야 합니다. 즉, ‘패킷 손실에 따른 대가가 없다’는 뜻은 아닙니다.
- 지연 시간이 길고 무작위 패킷 손실이 발생하는 경우: 복구 대기와 전송 윈도우 변화의 영향이 커져 Hysteria2가 더 안정적인 지속 처리량을 낼 수 있습니다.
- 지연 시간이 짧고 패킷 손실이 적은 경우: 이미 대역폭을 충분히 활용하는 경로라면 프로토콜을 바꿔도 차이가 크지 않을 수 있습니다. 서버 부하와 경로 품질이 더 중요할 수 있습니다.
- UDP가 차단되거나 지속적으로 제한되는 경우: 핸드셰이크 시간이 초과되거나 연결되더라도 처리량을 유지하지 못할 수 있습니다. 대역폭 매개변수만 높여서는 네트워크 제한을 해소할 수 없습니다.
- 출구 구간이 이미 혼잡한 경우: 과도한 전송 목표는 대기열과 패킷 손실, 재전송을 늘려 다른 요청의 응답을 늦출 수 있습니다.
결론: 같은 경로에서 반복 측정해 판단하기
먼저 서버, 대상 리소스, 라우팅 모드를 동일하게 유지한 뒤 첫 화면 응답 시간, 지속 처리량, 연결 안정성을 비교하세요. 출구 경로가 달라진 뒤의 속도 변화를 Hysteria2의 효과로 단정하거나 고정된 향상 비율을 적용하지 마세요.
Home에서 매개변수 입력 및 확인
아래 절차는 서비스 제공업체에서 연결 매개변수를 이미 받은 경우를 전제로 합니다. 구독 정보는 이용 중인 서비스 제공업체에서 받으세요. 구독 가져오기와 직접 입력은 별개의 설정 방법입니다. 구독을 가져왔다면 먼저 가져온 내용을 확인하고, 직접 입력한다면 항목별로 입력하세요. 문제를 점검하는 동안 구독을 갱신하고 인증 정보와 대역폭을 동시에 변경하면 어떤 변경이 영향을 미쳤는지 파악하기 어렵습니다.
-
매개변수 확인
서버 주소, 포트, 인증 정보, 인증서 검증 이름, 난독화 사용 여부를 확인해 두세요. 대역폭 값과 단위도 서비스 제공업체의 안내를 따르세요. 도메인이나 포트만 보고 다른 매개변수를 추측하지 마세요.
-
유형 선택
Home → 오른쪽 상단 ‘+’ → Add Server → Type → Hysteria2를 선택합니다. 주소와 포트를 입력하세요. 구독에서 가져온 경우 해당 항목의 편집 화면을 열어 Type이 실제로 Hysteria2인지 먼저 확인합니다.
-
인증 정보 확인
서비스 제공업체가 안내한 Password 전체 값을 대소문자와 기호까지 그대로 입력하세요. 인증 정보가 사용자 이름과 비밀번호를 조합한 형식이라면 원본 그대로 입력하고 임의로 나누거나 구분 기호를 삭제하거나 공백을 추가하지 마세요.
-
TLS 확인
SNI가 서버 인증서의 이름과 일치하는지 확인하세요. 연결 주소는 IP일 수 있지만 인증서 검증에는 도메인이 사용될 수 있습니다. 두 값은 서로 다른 역할을 합니다. 난독화 유형과 키도 서버 설정과 일치해야 합니다.
-
저장 후 테스트
저장한 뒤 Home으로 돌아가 해당 항목을 선택하고 Global Routing을 확인한 다음 연결을 활성화하세요. 처음 설정할 때는 시스템 안내에 따라 VPN 구성 승인을 완료한 뒤 동일한 대상을 방문해 성공, 시간 초과, 인증서 오류 등의 결과를 기록합니다.
대역폭 입력값은 특히 혼동하기 쉽습니다. 입력란의 단위가 Mbps라면 20 Mbps는 초당 약 2.5 MB에 해당하며, 프로토콜 오버헤드는 포함하지 않은 값입니다. 20 MB/s를 그대로 20 Mbps로 입력하지 마세요. 업로드와 다운로드 값을 각각 확인해야 합니다. 실제 경로보다 훨씬 높은 값을 입력해도 성능이 보장되는 것은 아닙니다. 최종 동작은 서버 제한, 양쪽 설정 및 구현에 따라 달라지므로 입력값 하나만으로 실제 전송 속도를 판단할 수 없습니다.
Global Routing: 프로토콜과 규칙 구분하기
Home에 연결 성공으로 표시되더라도 연결 상태만 확인된 것이며, 특정 요청이 선택한 Hysteria2 항목을 거쳤다는 의미는 아닙니다. Global Routing에서 트래픽의 라우팅 모드를 정하고, Config의 규칙에서 요청에 적용할 정책을 결정합니다. ‘프로토콜을 바꿨는데 속도가 그대로’인 문제를 점검할 때는 먼저 테스트 요청이 실제로 어떤 경로로 전달되는지 확인하세요.
Config
Config현재 활성화된 Config에서 정책을 확인하세요. 규칙은 위에서 아래로 평가되며 가장 먼저 일치하는 규칙이 요청을 처리합니다. 일치하는 규칙이 없으면 FINAL이 적용됩니다. 평소 사용하기 전에 해당 정책이 예상한 연결 항목을 가리키는지 확인하세요.
적합한 경우: 규칙을 명확히 설정해 일상적으로 사용하는 경우
Proxy
클라이언트가 처리하는 트래픽을 프록시 모드로 라우팅합니다. 일반적인 분할 라우팅 규칙의 영향을 잠시 제외하는 데 적합합니다. 모든 시스템 트래픽이 동일한 연결을 거친다는 뜻은 아니며, 서버 인증 문제나 UDP 연결 문제를 해결하지도 않습니다.
적합한 경우: 프록시 경로 및 프로토콜 연결을 잠깐 확인할 때
Direct
클라이언트가 처리하는 트래픽을 직접 연결로 라우팅합니다. 이 상태에서 접속에 성공해도 Hysteria2 서버가 정상이라는 증거는 아닙니다. 직접 연결 경로를 비교할 때 사용할 수 있으며, 테스트 후에는 기존 모드로 되돌리세요.
적합한 경우: 로컬 네트워크와 대상 서비스의 연결 가능 여부를 비교할 때
Global Routing의 Scene은 상황별 라우팅 동작을 설정하는 기능이지 별도의 전송 프로토콜이 아닙니다. 문제를 점검하는 동안 현재 Scene이 선택에 영향을 주는지 확인하세요. Config를 사용한다면 활성화된 파일이 무엇인지 확인하고 DOMAIN-SUFFIX, IP-CIDR 등의 규칙이 DIRECT나 다른 정책에 먼저 일치하는지도 살펴보세요. 프로토콜 매개변수가 올바른지와 규칙이 올바른 연결을 선택하는지는 별개의 조건입니다.
연결 실패 및 속도 불안정 점검 순서
먼저 증상을 구분한 뒤 관련 매개변수를 변경하세요. TCP 포트 테스트에 성공해도 같은 번호의 UDP 포트를 사용할 수 있다는 뜻은 아닙니다. 반대로 일반적인 UDP 탐색에서 응답이 없더라도 포트가 닫혔다고 단정할 수 없습니다. 서버가 유효하지 않은 패킷에 응답하지 않을 수 있기 때문입니다. 클라이언트의 실제 핸드셰이크 결과, 네트워크를 바꿨을 때의 결과, 서비스 제공업체가 확인해 준 정보를 함께 살펴보세요.
| 증상 | 먼저 확인할 항목 | 다음 단계 |
|---|---|---|
| 연결 시간 초과가 계속됨 | 주소 확인, 실제 UDP 포트, 현재 네트워크에서의 연결 가능 여부 | Wi-Fi와 셀룰러 네트워크에서 각각 한 번씩 테스트하세요. 설정은 그대로 두고 인증 정보는 동시에 변경하지 마세요. |
| 인증 실패 메시지 | Password 전체 값과 대소문자, 서버 측 인증 허용 상태 | 원본 매개변수를 다시 확인하고 복사 과정에서 앞뒤에 공백이 포함되지 않았는지 살펴보세요. |
| 인증서 오류 메시지 | SNI, 인증서 이름과 유효 기간, 기기 시간 | 서버 인증서 설정을 확인하세요. 검증을 꺼서 오류를 감추지 마세요. |
| 연결되지만 처리량이 불안정함 | 대역폭 단위, 경로의 패킷 손실, 네트워크 제한, 서버 부하 | 대상 리소스를 그대로 유지하고 동시 연결 수를 줄인 뒤 시간대별로 결과를 기록하세요. |
| 일부 대상에 접속할 때 문제가 발생함 | 현재 Config, 규칙에 적용된 정책, DNS 확인 결과 | 잠시 Proxy 모드와 비교해 보세요. 증상이 달라지면 인증 정보를 다시 입력하기보다 라우팅 규칙을 먼저 확인하세요. |
작은 요청은 성공하지만 전송이 길어질수록 자주 멈춘다면 경로 MTU, UDP 데이터그램 처리, 속도 제한 정책을 서비스 제공업체에 추가로 확인할 수 있습니다. 한 번 멈췄다는 이유만으로 하위 매개변수를 임의로 바꾸지 마세요. 특정 Wi-Fi에서만 문제가 발생하고 셀룰러 네트워크로 바꾼 뒤 정상화된다면 경로 차이를 의심할 단서가 됩니다. 다만 일시적인 서버 부하 변화를 네트워크 문제로 오인하지 않도록 반복해서 확인하세요.
iPhone 배터리 사용량과 일상적인 테스트 방법
Hysteria2의 배터리 소모량이 일정한 비율로 늘어나는 것은 아닙니다. 암호화 처리, 데이터 처리량, 재전송, 연결 유지, 셀룰러 무선 모듈의 활성 시간 등이 전력 소모에 영향을 줍니다. 다운로드가 더 빨리 끝나면 무선 전송 시간이 줄어들 수 있지만, 지속적인 고속 전송과 약한 신호, 반복적인 재연결은 소모량을 늘릴 수도 있습니다. 따라서 프로토콜 이름만으로 어느 설정이 배터리를 덜 쓰는지 판단할 수 없습니다.
- 테스트 조건을 동일하게 유지: 같은 iPhone과 네트워크, 같은 리소스를 사용하고 화면 밝기, 충전 상태, 백그라운드 작업도 최대한 동일하게 맞추세요.
- 두 가지 사용 부하를 구분: 짧은 웹 요청과 지속 다운로드를 각각 관찰하세요. 장시간 최고 속도로 다운로드했을 때의 배터리 변화를 대기 상태의 소모량으로 간주하지 마세요.
- 측정 시간을 정해 기록: 예를 들어 매회 10분 동안 테스트하면서 전송 완료량, 발열, 재연결 횟수, 배터리 변화를 기록하고 최소 세 차례 반복하세요. 이는 테스트 방법의 예시이며 실제 성능 측정 결과가 아닙니다.
- 연결이 시작되는 조건 확인: Settings → On Demand에서 네트워크 조건에 따라 연결이 시작되는지 확인하고, Wi-Fi 전환 전후의 상태를 각각 관찰하세요. 자동 연결로 사용 시간이 달라진 것을 프로토콜 차이로 계산하지 않도록 주의하세요.
- 배터리 사용량을 별도로 확인: iPhone의 시스템 설정에서 배터리 사용 내역을 확인하고 화면과 셀룰러 신호의 영향도 고려하세요. VPN을 통한 전달 활동을 특정 전면 앱의 전체 전력 소모와 동일하게 볼 수는 없습니다.
결론: 최고 속도보다 안정성이 우선
대역폭 목표를 높인 뒤 순간 속도만 오르고 발열, 응답 지연, 재연결이 뚜렷해지면 기존 값으로 되돌려 다시 테스트하세요. 한 번의 속도 측정에서 최고 수치를 얻기보다 실제 작업을 안정적으로 완료할 수 있는 설정을 일상적으로 사용하는 편이 낫습니다.
Hysteria2를 검토하려면 서버가 해당 프로토콜을 지원하고 UDP 경로를 사용할 수 있으며 필요한 매개변수가 모두 있어야 합니다. Shadowrocket은 iPhone과 iPad에서 주로 사용하는 Apple 플랫폼용 유료 클라이언트입니다. 클라이언트 구매와 연결 서비스는 별개이며 구독 정보는 서비스 제공업체에서 받으세요. 구매 가능 범위와 시스템 요구 사항은 App Store 페이지를 확인하세요. 기본 설정부터 진행하려면 사용법 안내에서 Home, Config, 최초 VPN 구성 승인 절차를 확인한 다음 프로토콜을 테스트하세요.