Hysteria2란? QUIC 기반 전송의 속도와 적합한 네트워크 환경

이 글의 핵심 내용

Hysteria2는 QUIC 기반 프록시 프로토콜입니다. UDP 경로를 사용할 수 있고 서버 설정이 올바르며 대역폭이 적절하다면, 지연 시간이 길거나 패킷 손실이 있는 일부 네트워크에서 전송 성능을 개선할 수 있습니다. 이 글에서는 이미 보유한 서버 설정 정보를 사용하는 Shadowrocket 사용자를 대상으로 전송 원리와 사용 조건, 설정 확인 방법, 재현 가능한 문제 해결 절차를 설명합니다. 프로토콜 이름만으로 속도가 보장되는 것은 아닙니다.

Hysteria2, QUIC, UDP의 역할

Shadowrocket에서 Hysteria2는 사용자가 이미 보유한 서버에 연결할 때 선택하는 프로토콜 유형입니다. 네트워크 회선이나 구독 자체를 뜻하지 않습니다. 구독은 클라이언트에 연결 항목을 제공하고, 프로토콜은 클라이언트와 서버의 인증 및 데이터 전송 방식을 정합니다. 실제 연결 성능은 로컬 네트워크, 서버 부하, 대상 사이트의 영향을 받습니다.

전송 경로는 세 계층으로 나눠 볼 수 있습니다. UDP는 데이터그램을 전달하고, QUIC은 그 위에서 암호화 연결과 스트림, 신뢰성 있는 전송 기능을 구현합니다. Hysteria2는 여기에 프록시 인증과 사용자 데이터의 캡슐화 방식을 정합니다. UDP 자체는 데이터 전달을 보장하지 않지만, UDP를 사용하는 QUIC의 신뢰성 있는 스트림에서 재전송이 없다는 뜻은 아닙니다. 웹 탐색처럼 신뢰성 있는 전송이 필요한 작업은 손실된 데이터가 복구될 때까지 기다립니다.

UDP

Hysteria2의 하위 전송 경로에서는 UDP를 사용할 수 있어야 합니다

TLS 1.3

QUIC에 통합된 암호화 핸드셰이크

443/UDP

포트 예시이며 모든 서버에 공통으로 적용되는 포트는 아닙니다

예를 들어 서비스 제공자가 포트로 443을 지정했다면 해당 UDP 포트에 연결할 수 있는지 확인해야 합니다. 같은 번호의 TCP 포트에 연결된다고 UDP도 통과한다는 뜻은 아닙니다. 포트는 기존 서버에서 제공한 값을 사용하세요. 흔히 쓰이는 예시가 443이라고 해서 다른 유효한 포트를 443으로 바꾸면 안 됩니다.

‘더 빠르다’는 말의 의미: 혼잡 제어와 스트림 격리

QUIC은 하나의 연결에서 여러 스트림을 전송할 수 있습니다. 한 스트림에서 데이터가 손실되더라도, 같은 TCP 바이트 스트림을 공유할 때처럼 누락된 바이트가 채워질 때까지 다른 스트림의 데이터 전달을 기다리지 않아도 되는 경우가 많습니다. 따라서 스트림 간 헤드 오브 라인 블로킹을 줄일 수 있지만, 하나의 신뢰성 있는 스트림 내부에서 생긴 누락은 여전히 복구해야 합니다. 모든 스트림은 실제 네트워크 용량과 혼잡 제약을 공유합니다.

Hysteria2의 전송 성능은 혼잡 제어에도 영향을 받습니다. 대역폭 설정은 전송 속도 제어에 관여할 수 있습니다. 대역폭 설정을 바탕으로 동작하는 Brutal 방식과 경로 용량을 자동으로 추정하는 방식은 원리가 다릅니다. 실제 적용 방식은 클라이언트 구현, 설정, 서버 협상에 따라 달라지므로 프로토콜 이름만 보고 현재 연결이 특정 알고리즘을 사용한다고 단정할 수 없습니다.

경로에서 간헐적으로 패킷이 손실되는 경우: 지속적인 혼잡이 원인이 아니라면 적절한 속도 제어로 높은 처리량을 유지할 수 있습니다. 다만 손실된 데이터를 복구하는 데 드는 트래픽과 시간은 감수해야 합니다.
경로가 이미 혼잡한 경우: 목표 전송 속도를 더 높이면 대기열, 지터, 패킷 손실이 늘어 웹 응답이 오히려 느려질 수 있습니다.
여러 스트림을 동시에 사용하는 경우: 스트림 격리로 일부 요청의 완료 시간이 줄어들 수 있지만, 무선 네트워크 회선의 병목까지 해결되지는 않습니다.
짧은 연결이나 작은 파일의 경우: DNS 조회와 핸드셰이크, 대상 서버의 응답 시간이 전체 과정에서 큰 비중을 차지할 수 있습니다. 지속 다운로드 속도만으로 웹페이지를 처음 열 때의 체감 성능을 판단할 수는 없습니다.

요약: 먼저 연결 가능성을 확인한 뒤 속도를 조정하세요

UDP 경로에 안정적으로 연결되고 인증이 성공하며 대상 요청이 실제로 해당 연결을 통과하는지 확인한 뒤 대역폭 설정을 비교하세요. 값을 높인 후 웹페이지 로딩이 느려지면 더 높이지 말고 기존 값으로 되돌리세요.

대역폭을 입력할 때는 단위도 구분해야 합니다. Mbps는 초당 메가비트, MB/s는 초당 메가바이트이며 숫자는 8배 차이가 납니다. 요금제의 표시 대역폭이 높더라도 현재 무선 신호 상태와 공유 출구에 따라 실제 사용 가능한 용량은 더 낮을 수 있습니다. 클라이언트에 표시된 단위와 기존 서버 안내를 기준으로 입력하고, 요금제의 최대 대역폭을 현재 측정 속도로 간주하지 마세요.

테스트할 만한 네트워크 환경과 먼저 확인할 조건

패킷 손실이 많은 환경, 장거리 경로, 모바일 네트워크는 직접 측정해 봐야 하는 조건이지 자동으로 적합하다고 볼 수 있는 환경이 아닙니다. 먼저 로컬 네트워크에서 UDP를 사용할 수 있는지 확인한 다음, 간헐적 패킷 손실과 혼잡으로 인한 패킷 손실, 서버 이상을 구분하세요. 모두 연결 지연으로 나타날 수 있지만 해결 방법은 서로 다릅니다.

네트워크 조건	확인할 사항	먼저 할 일
지연 시간이 길고 간헐적으로 패킷이 손실되는 경우	연속 요청이 완료되는지, 지속 전송이 자주 멈추는지 확인	대상과 서버를 고정해 여러 번 테스트하고, 한 번의 지연 시간만 보지 않습니다
Wi-Fi와 셀룰러 네트워크 간 전환	전환 후 기존 요청이 재개되는지, 새 요청이 성공하는지 확인	전환 전후 결과를 각각 기록하고, 필요하면 연결을 다시 설정합니다
UDP가 제한된 네트워크	다른 네트워크에서는 사용할 수 있지만 현재 네트워크에서는 핸드셰이크 시간이 계속 초과되는 경우	네트워크 이용 조건을 확인하고 UDP를 허용하는 네트워크에서 다시 테스트합니다
패킷 손실과 지연 시간이 적은 네트워크	웹 응답과 지속 전송이 이미 안정적인지 확인	안정적인 설정을 유지하고 프로토콜 이름만 보고 설정을 반복해서 바꾸지 않습니다
공유 네트워크 출구의 혼잡	다운로드 중 다른 요청의 지연 시간이 늘고 다운로드를 멈추면 회복되는지 확인	부하를 낮추고 대역폭 설정을 다시 평가합니다

QUIC에는 연결 마이그레이션을 지원하는 메커니즘이 있지만, 네트워크를 전환할 때마다 Shadowrocket에서 전송이 끊김 없이 이어진다는 뜻은 아닙니다. 클라이언트 구현과 서버 정책, 주소 변경, 네트워크 중간 장비가 모두 결과에 영향을 줄 수 있습니다. 모바일 네트워크에서는 한 네트워크를 계속 사용할 때와 네트워크를 전환할 때를 각각 테스트하세요. 전환 실패를 모든 Hysteria2 연결의 문제로 오해하지 않도록 합니다.

Shadowrocket에서 기존 Hysteria2 설정 확인하기

아래 절차는 사용자가 이미 서비스와 연결 설정 정보를 보유한 경우를 전제로 합니다. 현재 작동하는 설정은 먼저 보관하고 프로토콜, 주소, 포트, 인증, TLS 정보를 하나씩 확인하세요. 연결 정보 유형은 Type만 바꿔 서로 전환할 수 없으며, Hysteria와 Hysteria2도 같은 프로토콜로 취급하면 안 됩니다.

연결 항목 확인

Home으로 이동해 기존 항목의 편집 화면을 열고 Type이 Hysteria2인지 확인합니다. 직접 추가하려면 Home 오른쪽 위의 ‘+’를 누른 다음 기존 서버 안내에 따라 Type을 선택하세요. 서비스 제공자 이름을 프로토콜 유형으로 선택하지 마세요.
연결 정보 확인

서버 주소와 포트, 인증 정보를 정확히 확인합니다. 예시 주소 hy2.example.com과 포트 443은 각 입력란의 관계를 설명하기 위한 것이며 실제로 사용할 수 있는 서버 정보가 아닙니다. 인증 정보의 앞뒤에 공백이나 줄바꿈이 들어가지 않도록 하세요.
TLS 확인

기존 서버 안내에 따라 TLS 서버 이름(SNI)과 인증서 요구 사항을 확인합니다. 연결 주소와 인증서 이름은 다를 수 있습니다. 인증서 오류가 발생하면 먼저 이름과 기기 시간을 확인하고, 일반적인 해결 방법으로 인증서 검증을 건너뛰지 마세요.
추가 옵션 확인

서버에서 obfuscation을 사용한다면 방식과 비밀번호가 함께 제공되었는지 확인합니다. 사용하지 않는 경우 임의로 추가하지 마세요. 대역폭 관련 항목은 화면에 표시된 단위에 맞춰 입력하고, 되돌릴 수 있도록 변경 전 값을 보관하세요.
연결 후 다시 확인

저장한 뒤 Home으로 돌아가 해당 항목을 선택하고 Global Routing을 확인합니다. 연결을 켠 다음 Connectivity Test를 실행하세요. 이어서 고정된 테스트 대상에 접속해 테스트 결과와 실제 요청 결과를 각각 기록합니다.

Global Routing이 프로토콜 테스트에 미치는 영향

‘Hysteria2 항목을 선택한 것’과 ‘현재 요청이 해당 항목을 사용하는 것’은 서로 다릅니다. Home → Global Routing에서 라우팅 방식을 정합니다. Config를 사용하면 일부 요청이 규칙에 따라 DIRECT로 연결될 수 있으므로 웹페이지가 한 번 열렸다는 사실만으로 Hysteria2 연결이 작동한다고 판단할 수 없습니다.

Config: 규칙에 따라 확인

권장

현재 설정에 따라 요청을 라우팅합니다. 테스트 전에 대상 요청이 어떤 규칙과 일치해야 하는지, 해당 규칙에서 어떤 정책을 사용하는지 확인하세요. 정책이 다른 선택 항목을 참조한다면 최종 출구도 확인해야 합니다.

적합한 상황: 일상적으로 규칙을 적용하거나 일치 조건을 명확히 한 상태에서 재테스트할 때

Proxy: 일시적으로 변수를 분리

프록시를 사용할 수 있는 요청을 선택한 프록시로 보내 규칙의 영향을 줄입니다. 테스트 중에는 선택한 항목이 테스트할 Hysteria2 연결인지 확인하고, 테스트가 끝나면 기존 라우팅 방식으로 되돌리세요.

적합한 상황: Config의 라우팅 규칙이 실패 원인인지 잠시 확인할 때

Direct: 직접 연결과 비교

프록시를 거치지 않을 때 대상에 접속되는지 확인하는 데 사용합니다. Direct에서 웹페이지가 열린다고 해도 해당 대상에 직접 연결할 수 있다는 뜻일 뿐, Hysteria2 연결을 검증한 것은 아닙니다.

적합한 상황: 대상 사이트와 로컬 네트워크의 기본 접속 상태를 확인할 때

아래는 규칙의 일치 방식을 이해하기 위한 최소한의 예시이며, 완전한 설정이 아니고 실제 테스트 서비스로 연결되지도 않습니다. DOMAIN-SUFFIX는 지정된 도메인과 하위 도메인에 일치하고, FINAL은 앞선 규칙과 일치하지 않은 요청을 처리합니다. 실제 규칙은 기본 처리 규칙보다 앞에 배치해야 합니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

이 예시에서는 example.com과 그 하위 도메인에 접속할 때만 PROXY와 일치하고, 나머지 요청은 DIRECT로 전달됩니다. 실제 테스트 대상이 다른 도메인이라면 그 결과로 테스트할 프록시를 평가할 수 없습니다. On Demand는 조건에 따라 VPN 연결을 언제 설정할지 제어합니다. 연결 항목의 프로토콜이나 Rule의 일치 범위와는 다른 설정입니다. 문제 해결 중 자동 연결이 수동 테스트에 영향을 주지 않도록 Settings → On Demand에서 기존 조건을 확인하세요.

변수를 고정해 결과를 기록하고 한 번의 속도 테스트로 판단하지 마세요

프로토콜을 테스트할 때는 연결 가능 여부와 응답 시간, 지속 전송 상태를 함께 확인해야 합니다. Connectivity Test는 초기 점검에 활용할 수 있지만 테스트 대상과 방법이 실제 작업과 다르므로 결과를 다운로드 대역폭으로 간주할 수 없습니다. 이 글에서는 여러 네트워크에 공통으로 적용되는 속도 차이나 패킷 손실 임계값을 제시하지 않습니다. 이런 수치는 테스트 조건을 명확히 해야 의미가 있기 때문입니다.

입력 조건 고정: 같은 기기와 네트워크, 서버, 테스트 대상을 사용하고 다른 대용량 작업은 일시 중지하세요. 한 번에 하나의 설정만 변경합니다.
반복해서 관찰: 각 설정을 최소 3회 테스트하고 성공 횟수와 첫 응답 시간, 지속 전송 상태를 기록하세요. 가장 좋은 결과만 남기지 마세요.
경로 기록: Global Routing 방식과 선택한 연결 항목, 대상 도메인, 네트워크 전환 여부를 적어 테스트 결과가 실제로 확인하려는 경로에서 나온 것인지 파악할 수 있도록 합니다.
복구 지점 보관: 대역폭이나 추가 설정을 변경한 뒤 실패율이 높아지면 먼저 기존 값으로 되돌리고 네트워크와 서버를 확인하세요. 여러 항목을 동시에 바꾸지 마세요.

예를 들어 ‘Wi-Fi, Config, 대상이 PROXY 규칙에 일치, 3회 모두 성공, 전송 시작 후 웹 응답이 느려짐’처럼 관찰 가능한 현상을 메모해 두세요. 이는 ‘더 빠른 것 같다’는 느낌보다 문제를 찾는 데 도움이 되며, 일시적인 네트워크 변동을 프로토콜의 고정된 특성으로 오해하는 것도 막아 줍니다. 기존 서비스 제공자에게 문의할 때 필요한 오류 정보는 전달하되 인증 비밀번호나 전체 구독 주소는 공개하지 마세요.

자주 묻는 질문: 핸드셰이크, 인증서, 네트워크 전환

같은 연결 항목이 Wi-Fi에서는 시간 초과되지만 셀룰러 네트워크에서는 연결되는 이유는 무엇인가요?

연결 항목 설정은 그대로 두고 두 네트워크에서 각각 Home → Connectivity Test를 실행한 뒤 같은 대상에 접속해 보세요. 한 네트워크에서만 계속 실패한다면 해당 네트워크의 UDP 제한이나 이용 조건을 우선 확인하세요. TCP 443을 사용할 수 있다는 이유만으로 UDP 443도 사용할 수 있다고 판단하지 마세요.

인증서 오류가 표시되면 무시해도 되나요?

먼저 기기의 날짜와 시간을 확인한 다음 Home에서 연결 항목 편집 화면을 열어 서버 주소와 TLS 서버 이름을 확인하세요. 기존 서비스 제공자에게 정확한 이름과 인증서 상태를 문의하세요. 인증서 검증은 유지하고 오류 무시를 장기적인 해결책으로 삼지 마세요.

대역폭을 더 높게 설정했는데 웹페이지가 오히려 멈추는 이유는 무엇인가요?

목표 속도를 높이면 현재 경로의 용량을 초과해 대기열과 패킷 손실이 발생할 수 있습니다. 이전 설정값으로 되돌리고 지속 다운로드를 일시 중지한 뒤 같은 대상으로 다시 테스트하세요. 단위가 Mbps인지 확인해 MB/s 값을 다른 단위의 입력란에 그대로 넣지 않도록 합니다.

구독을 업데이트한 뒤 갑자기 연결할 수 없습니다. 무엇부터 확인해야 하나요?

Home에서 업데이트된 연결 항목을 열고 Type, 포트, 인증 정보, 추가 설정이 바뀌었는지 확인한 다음 선택된 항목과 Global Routing도 확인하세요. 설정이 실제로 바뀌었다면 이용 중인 서비스 제공자에게 문의하세요. 의미를 모르는 입력란에 임의의 값을 반복해서 넣지 마세요.

네트워크를 전환한 뒤 연결이 끊겼습니다. On Demand 설정이 잘못된 건가요?

먼저 새 네트워크에서 직접 다시 연결해 보고 해당 네트워크에서 UDP를 사용할 수 있는지 확인하세요. 그런 다음 Settings → On Demand에서 자동 연결 조건을 확인합니다. 직접 연결도 실패한다면 네트워크와 연결 항목부터 점검하세요. 자동 연결 동작만 예상과 다를 때 On Demand 설정을 별도로 조정하면 됩니다.