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

이 글의 핵심 내용

이 글은 이미 이용 중인 서비스와 구독 정보가 있으며 Shadowrocket에서 Hysteria2를 사용하려는 분을 위한 안내입니다. QUIC, UDP, 혼잡 제어의 관계를 먼저 살펴본 뒤 주소, 포트, 인증 정보, TLS, 대역폭 항목을 확인하고 연결 상태에 따라 문제를 진단합니다. 네트워크에 적합한지 판단할 때는 한 번 측정한 지연 시간만 보지 말고 UDP 연결 가능 여부, 패킷 손실의 특성, 지속 전송 성능을 함께 확인해야 합니다.

Hysteria2와 QUIC, UDP의 관계

Hysteria2는 QUIC 기반 프록시 프로토콜입니다. 클라이언트인 Shadowrocket이 사용자가 이용하는 Hysteria2 서버에 연결하면 서버가 목적지 트래픽을 전달합니다. 앱 구매와 연결 서비스 이용은 별개입니다. 클라이언트를 구매해도 서버 주소, 인증 정보 또는 구독이 자동으로 제공되지는 않습니다.

UDP는 하위 전송 계층이며, QUIC은 그 위에서 암호화, 연결 관리, 신뢰성 있는 스트림, 혼잡 제어를 구현합니다. UDP 기반이라고 해서 데이터 손실을 처리하지 않는다는 뜻은 아닙니다. TCP 프록시 트래픽을 전달할 때 QUIC의 신뢰성 있는 스트림은 확인과 재전송을 수행합니다. 프록시 UDP 트래픽은 데이터그램 특성에 맞는 방식으로 전달됩니다.

UDP

클라이언트와 Hysteria2 서버 사이의 하위 전송 방식

TLS 1.3

QUIC 암호화 핸드셰이크의 기반

443/UDP

서버 리스닝 설정 예시이며 고정 포트가 아닙니다

여기서 443/UDP는 포트 예시일 뿐입니다. 서버는 다른 UDP 포트를 사용할 수도 있으므로 클라이언트에는 실제 포트를 입력해야 합니다. 어떤 네트워크에서 443/TCP를 허용한다고 해서 443/UDP도 허용되는 것은 아닙니다. 브라우저에서 일반 웹페이지가 열린다고 Hysteria2 전송 경로까지 사용할 수 있다는 뜻도 아닙니다.

전송 속도를 높일 수 있는 이유: 다중화와 혼잡 제어

QUIC은 하나의 연결에서 여러 스트림을 동시에 전송할 수 있습니다. 한 스트림에서 패킷 손실이 발생해도 여러 업무 스트림을 하나의 TCP 바이트 스트림에 담았을 때처럼 바깥의 순서 보장이 누락된 데이터를 채울 때까지 다른 스트림의 데이터 전달을 기다릴 필요가 없습니다. 다만 각 스트림은 여전히 같은 링크 용량과 혼잡 제어를 공유하며, 개별 신뢰성 스트림에도 순서대로 전달해야 하는 제약이 있습니다.

Hysteria2의 또 다른 특징은 대역폭 설정에 따라 동작하는 Brutal 혼잡 제어입니다. 설정한 목표 속도로 데이터를 전송하고 패킷 손실을 보완합니다. 무작위 패킷 손실이 있지만 링크에 여유 용량이 있다면, 손실 발생 시 전송 속도를 크게 낮추는 방식보다 처리량을 유지하는 데 유리할 수 있습니다. Brutal이나 BBR 같은 경로 중 무엇을 사용하는지는 대역폭 설정, 협상 결과, 클라이언트와 서버의 구현에 따라 달라지므로 프로토콜 이름만으로 판단할 수 없습니다.

방식	개선될 수 있는 현상	여전히 남는 한계
QUIC 다중화	바깥 전송 계층의 순서 보장으로 인해 스트림 간 발생하는 대기	모든 스트림이 같은 링크 용량을 두고 경쟁
신뢰성 스트림 재전송	패킷 손실 후 TCP 프록시 데이터의 무결성 복구	재전송에 드는 시간과 추가 대역폭
Brutal	무작위 패킷 손실로 인한 지속 전송 속도 저하	목표 대역폭을 지나치게 높게 설정하면 대기열과 패킷 손실이 늘어날 수 있음
BBR 방식	링크 상태 추정에 따라 전송 방식 조정	경로, 구현 방식, 서버 제약에 따라 효과가 달라짐

판단 방법: 사용 가능한 용량을 측정한 뒤 대역폭 설정

먼저 같은 경로에서 지속 다운로드·업로드 속도와 응답 지연을 기록한 다음 실제 용량에 맞춰 대역폭을 설정합니다. 값을 높여도 처리량은 그대로인데 웹페이지 응답이 느려진다면 설정을 낮추고 다시 측정하세요. 계속 값을 높이지 마세요.

속도는 프로토콜에 고정된 특성이 아닙니다. 지연 시간이 길면 핸드셰이크, 요청 왕복, 패킷 손실 복구에 더 많은 시간이 걸리며 QUIC도 물리적 거리를 줄일 수는 없습니다. 서버 출구 대역폭, 대상 웹사이트의 속도 제한, 로컬 무선 간섭도 프로토콜을 바꾼다고 사라지지 않습니다. 이 글에서는 검증되지 않은 속도 향상 비율을 약속하지 않습니다.

적합한 네트워크 환경과 먼저 확인해야 할 조건

UDP 연결이 가능하고 지연 시간이 높으며 어느 정도 무작위 패킷 손실이 있지만, 사용 가능한 대역폭도 있는 네트워크라면 우선 시험해 볼 수 있습니다. 패킷 손실이 대기열의 지속적인 포화에서 발생한다면 전송 속도를 더 높이는 것이 오히려 역효과를 낼 수 있습니다. 무작위 패킷 손실과 혼잡으로 인한 손실을 구분해서 관찰해야 하며, 손실률 하나만으로 판단해서는 안 됩니다.

장거리 경로: 지속 전송이 안정적인지 확인하고 웹페이지 응답 시간도 기록하세요. 대용량 파일 전송이 빠르다고 해서 상호작용도 반드시 빠른 것은 아닙니다.
무선 연결 변동: 먼저 액세스 포인트 가까이에서 테스트하고 다른 대용량 작업을 중지하세요. 로컬 무선 간섭을 프로토콜 문제로 오인하지 않도록 합니다.
UDP 제한 네트워크: 핸드셰이크가 계속 시간 초과되면 UDP 포트와 네트워크 정책을 먼저 확인하세요. 대역폭 값을 높여도 연결할 수 없는 문제는 해결되지 않습니다.
지속적인 혼잡이 있는 네트워크: 전송 중 지연 시간이 크게 늘고 전송을 멈추면 회복되는 경우, 먼저 목표 대역폭을 낮추고 다른 기기의 네트워크 사용량을 확인하세요.
패킷 손실이 적은 단거리 경로: 프로토콜을 바꿔도 효과가 크지 않을 수 있습니다. 안정성, 서버 지원 여부, 실제 사용 목적을 함께 고려하세요.

Shadowrocket에 Hysteria2 추가하기: 항목 확인 순서

사용 중인 구독에 포함된 전체 설정을 우선 사용하면 TLS나 인증 매개변수를 빠뜨릴 가능성이 줄어듭니다. Hysteria2와 이전 프로토콜인 Hysteria는 이름만 바꿔서 서로 전환할 수 없습니다. 가져온 뒤 항목을 열어 Type이 Hysteria2로 설정되어 있는지 확인하세요. 인터페이스 언어와 앱 버전에 따라 항목 순서가 다를 수 있으므로 비슷한 이름만 보고 값을 추측하지 말고 각 항목의 의미를 기준으로 확인합니다.

정보 출처 확인

이용 중인 서비스의 주소, UDP 포트, 인증 정보, TLS, 선택적 난독화 매개변수를 준비합니다. 구독 가져오기 경로는 Home → 오른쪽 위 “+” → Type → Subscribe입니다. 본인의 구독 URL을 입력한 뒤 저장하세요.
프로토콜 선택

수동으로 추가하려면 Home → 오른쪽 위 “+” → Type → Hysteria2로 이동합니다. 구독을 가져왔다면 해당 항목을 열고 Type을 확인하세요. 기존 매개변수를 그대로 둔 채 다른 프로토콜로 변경하지 마세요.
연결 정보 입력

서버에서 제공한 주소와 포트를 입력한 다음 인증 정보를 입력합니다. 주소란에는 호스트 이름이나 IP만 입력하고 웹페이지 경로, 프로토콜 접두사, 포트는 함께 입력하지 마세요. 포트는 별도 입력란에 넣습니다. 예를 들어 서버에서 443을 지정했다면 443을 입력합니다.
암호화 항목 확인

TLS의 서버 이름 SNI와 인증서 요구 사항을 확인합니다. 서버에서 난독화를 사용한다면 난독화 유형과 비밀번호도 각각 일치시켜 입력하세요. 인증 비밀번호와 난독화 비밀번호는 용도가 다르므로 서로 대신 사용할 수 없습니다.
저장 후 확인

저장한 뒤 Home으로 돌아가 해당 항목을 선택해 연결합니다. 현재 Global Routing 설정을 기록하고 접속 가능한 것으로 확인된 대상으로 테스트하세요. 테스트가 끝나면 평소 설정을 복원하고 DNS, 규칙, 대역폭을 동시에 변경하지 마세요.

항목 설명	입력 기준	자주 하는 실수
서버 주소	서버에서 제공한 호스트 이름 또는 IP	관리 페이지 주소나 구독 주소를 잘못 입력
Port	실제 리스닝 UDP 포트	다른 서비스의 TCP 포트를 해당 포트로 입력
인증 정보	서버에서 지정한 전체 인증 문자열	일부 내용을 빠뜨리거나 앞뒤에 공백을 포함
SNI	TLS 인증서에 지정된 서버 이름	IP로 연결하면 인증서 이름을 확인할 필요가 없다고 생각
난독화 매개변수	서버에서 난독화를 사용하도록 설정했는지와 해당 매개변수	클라이언트에서만 켜거나 비밀번호가 일치하지 않음
업로드 및 다운로드 대역폭	클라이언트 측 링크 용량 및 서버 제약	업로드와 다운로드 값을 바꿔 입력하거나 MB/s를 Mbps로 착각

대역폭 단위를 주의하세요. 1 MB/s = 8 Mbps이며 실제 유효 데이터 전송량은 전송 오버헤드의 영향을 받습니다. 다운로드는 일반적으로 서버에서 클라이언트로 보내는 방향이고 업로드는 반대 방향입니다. 입력 전 현재 항목의 설명을 확인하세요. 로컬 인터넷 회선의 표시 속도가 높다고 해서 같은 수치를 원격 경로에서 지속적으로 낼 수 있는 용량으로 간주해서는 안 됩니다.

연결 후 확인: 트래픽이 실제로 해당 항목을 통과하는지

Home에서 Hysteria2 항목을 선택해도 모든 요청이 해당 항목을 통과하는 것은 아닙니다. Global Routing의 Direct는 직접 연결을 의미하고 Proxy는 프록시 라우팅 확인에 사용됩니다. Config는 현재 설정 파일의 규칙에 따라 처리하며, Scene에서는 현재 시나리오의 세부 설정도 확인해야 합니다. 진단할 때 라우팅 상태를 기록하지 않으면 프로토콜 비교에서 실제로는 서로 다른 경로를 시험할 수 있습니다.

Config를 사용할 때는 Config로 이동해 현재 적용 중인 파일을 확인한 다음 대상 요청에 어떤 규칙이 적용되는지 살펴보세요. 규칙은 보통 순서대로 적용됩니다. 아래 내용은 문법 설명용일 뿐, 기존 파일을 그대로 대체할 수 있는 완전한 설정이 아닙니다. PROXY 정책은 실제 설정에 존재하며 예상한 경로를 가리켜야 합니다.

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

DOMAIN-SUFFIX는 도메인 접미사로 일치 여부를 판단합니다. 테스트 도메인이 이 유형의 규칙에 해당하는지 먼저 확인하세요.
IP-CIDR은 IP 대역으로 일치 여부를 판단합니다. 예시의 no-resolve는 이 규칙 때문에 도메인 조회가 추가로 발생하지 않도록 합니다.
GEOIP는 IP 위치 데이터로 일치 여부를 판단하며, 결과는 조회된 IP와 사용 데이터에 따라 달라집니다.
FINAL은 앞선 규칙에 하나도 일치하지 않을 때 적용되는 기본 처리입니다. 이 항목만 확인하고 앞에 있는 규칙을 놓치지 마세요.

테스트 중 연결 상태가 저절로 회복된다면 Settings → On Demand의 기존 설정을 확인해 필요 시 연결이 실행된 것인지 살펴보세요. On Demand는 연결을 시작하는 조건을 제어할 뿐, 잘못된 인증 정보나 포트, TLS 매개변수를 수정하지는 않습니다. 설정을 임시로 바꾸기 전에 원래 값을 기록하고 진단이 끝나면 복원하세요.

Hysteria2 자주 묻는 질문: 증상별 문제 해결

계속 시간 초과되는데 일반 웹페이지는 왜 열리나요?

먼저 주소의 DNS 조회 결과와 실제 UDP 포트를 확인한 다음, 허용된 다른 네트워크에서 같은 항목으로 연결해 비교하세요. 일반 웹페이지는 TCP를 사용할 수 있으므로 UDP 경로가 정상이라는 증거가 되지 않습니다. 한 네트워크에서만 실패하면 해당 네트워크의 UDP 정책을 먼저 확인하세요. 두 네트워크 모두에서 실패한다면 서버의 리스닝 설정, 방화벽, 서비스 상태를 확인합니다.

인증 또는 인증서 오류가 표시되는 이유는 무엇인가요?

인증 오류가 발생하면 전체 문자열과 앞뒤 공백을 확인하고 비밀번호 대신 구독 URL을 입력하지 않았는지 살펴보세요. 인증서 오류는 기기 시간, SNI, 서버 인증서를 확인해야 합니다. IP로 연결하더라도 인증서에 지정된 도메인을 입력해야 할 수 있습니다. 난독화 설정이 일치하지 않아 핸드셰이크가 실패할 수도 있으므로 서버 설정과 항목별로 대조하세요.

대역폭을 높였는데 왜 오히려 느려지나요?

목표 속도가 경로 용량을 초과하면 대기열, 재전송, 보완 트래픽이 늘어날 수 있습니다. 목표 대역폭을 낮추고 다른 대용량 작업을 중지한 뒤 연속 전송 중 웹페이지 응답을 비교하세요. 처리량은 늘지 않고 응답 지연만 커졌다면 낮은 설정을 유지하고 서버가 실제 사용 가능한 속도를 제한하는지 확인합니다.

연결은 되었는데 일부 웹사이트가 열리지 않는 이유는 무엇인가요?

먼저 Home에서 Global Routing을 확인해 Direct로 연결되거나 규칙이 다른 경로를 가리키는지 살펴보세요. 그런 다음 Config의 규칙 일치 결과와 DNS 조회를 확인합니다. 큰 응답에서만 또는 특정 네트워크에서만 연결이 끊긴다면 경로 MTU, UDP 단편화, 중간 네트워크 제한을 확인하세요. 원인을 찾기 전에 DNS, 포트, 난독화 매개변수를 한꺼번에 바꾸지 마세요.

구독을 업데이트한 뒤 수동으로 수정한 내용이 사라지는 이유는 무엇인가요?

구독을 업데이트하면 구독에서 관리하는 항목이 다시 작성될 수 있습니다. 먼저 수정한 내용을 기록하고 원본 구독에서 올바른 매개변수를 제공하는지 확인하세요. 장기 설정에는 본인이 이용하는 서비스에서 제공한 유효한 정보를 사용해야 합니다. 구독 업데이트, Config 업데이트, App Store 앱 업데이트는 서로 다른 작업이며 대체할 수 없습니다.

설정을 최종적으로 유지하기 전에 네트워크 유형, 서버 항목, Global Routing 상태, 대역폭 설정, 문제가 발생한 구체적인 작업을 기록하세요. 한 번의 최고 속도보다 같은 작업을 여러 번 실행한 결과를 비교하는 편이 더 유용합니다. 특정 서버에서만 문제가 발생한다면 오류 상황에서 개인 정보를 가린 뒤 이용 중인 서비스 제공자에게 문의하세요. 인증 정보는 공개하지 마세요.