Shadowrocket Hysteria2 사용법: QUIC 기반 전송 원리와 네트워크 환경

이 글의 핵심

Hysteria2는 QUIC 기반 프록시 프로토콜이며, 켜기만 하면 속도가 빨라지는 기능이 아닙니다. 서비스 제공업체에서 구독 정보나 노드 설정을 받은 Shadowrocket 사용자를 위해 UDP, QUIC, 혼잡 제어의 차이부터 확인하고, 가져온 설정 항목을 점검한 뒤 같은 대상과 네트워크에서 반복 테스트해 적합성을 판단하는 방법을 소개합니다. 설정 오류나 UDP 제한을 앱 문제로 오해하지 않도록 확인하세요.

Hysteria2, QUIC, UDP의 역할

Shadowrocket의 Hysteria2는 연결 프로토콜 옵션 중 하나입니다. 클라이언트와 서버 사이에서 UDP 기반 QUIC 연결로 프록시 트래픽을 전달합니다. 회선을 제공하는 기능은 아니므로 프로토콜을 바꿔도 서버 위치, 출구 대역폭, 대상 웹사이트의 처리 용량은 달라지지 않습니다. 구독과 노드 정보는 서비스 제공업체에서 받아야 합니다.

UDP는 데이터그램을 전송하지만 데이터가 순서대로 도착하거나 손실된 데이터가 재전송된다고 보장하지는 않습니다. QUIC은 UDP 위에서 암호화 연결, 신뢰성 있는 스트림, 손실 복구, 혼잡 제어 등의 기능을 구현합니다. 따라서 ‘기반 전송에 UDP를 사용한다’고 해서 웹 콘텐츠가 손실되어도 재전송되지 않는다는 뜻은 아닙니다. 앱에 필요한 신뢰성 있는 바이트 스트림은 해당 전송 메커니즘이 보장합니다.

앱 요청 규칙에 따른 라우팅 QUIC 캡슐화 UDP 전송 서버에서 전달

위 과정은 문제를 확인할 때 살펴볼 범위도 보여 줍니다. 프록시 정책과 일치하고 해당 정책에서 Hysteria2 노드를 선택한 트래픽만 이 경로를 거칩니다. Global Routing이 Direct로 설정된 상태에서 웹을 탐색한 결과로는 해당 노드의 전송 성능을 판단할 수 없습니다. Config 모드에서는 대상 요청에 실제로 어떤 규칙이 적용되는지 확인해야 합니다.

불안정한 네트워크에서 더 안정적일 수 있지만, 모든 연결이 더 빨라지는 것은 아닙니다

QUIC의 여러 스트림은 데이터를 독립적으로 전달할 수 있습니다. 한 스트림에서 손실된 데이터를 복구하느라 기다리는 동안 다른 스트림까지 전송 계층에서 같은 순서의 바이트 스트림 복구를 기다릴 필요는 없습니다. 이 방식은 스트림 간 HOL 블로킹을 줄이는 데 도움이 되지만, 각 스트림 안에서는 여전히 순서가 유지되어야 하며 여러 스트림이 네트워크 용량과 혼잡 상태를 공유합니다. ‘다중 스트림’이 실제 대역폭을 늘린다는 뜻은 아닙니다.

Hysteria2의 처리량은 혼잡 제어에도 영향을 받습니다. 프로토콜 체계는 대역폭 매개변수를 사용하는 Brutal 혼잡 제어와 적응형 제어 경로를 지원합니다. 실제 동작은 클라이언트 구현, 서버 설정, 협상 결과에 따라 달라집니다. 대역폭 값을 너무 높게 설정하면 지속적인 패킷 손실과 큐잉이 발생할 수 있고, 너무 낮으면 처리량이 제한될 수 있습니다. 현재 접속 환경과 무관한 값을 그대로 따라 설정하지 마세요.

네트워크 조건	예상되는 결과	먼저 확인할 사항
간헐적인 패킷 손실, UDP 연결 가능	보수적으로 전송률을 낮추는 방식보다 처리량이 안정적일 수 있지만, 향상된다고 보장할 수는 없습니다.	반복 테스트에서 완료 시간, 멈춤 횟수, 지속 처리량을 확인합니다.
로컬 연결이 이미 포화 상태	전송 속도를 높이면 큐잉 지연이 늘어 대화형 요청이 오히려 느려질 수 있습니다.	테스트 중 업로드, 클라우드 백업 또는 다른 대용량 트래픽이 동시에 발생하는지 확인합니다.
서버 출구 대역폭 제한	QUIC으로 바꿔도 서버나 대상 측의 용량 한계를 넘을 수는 없습니다.	같은 시간대와 같은 대상에서 계속 동일한 한계에 부딪히는지 확인합니다.
UDP 패킷이 차단되거나 속도 제한됨	핸드셰이크 시간이 초과되거나 연결된 뒤에도 처리량이 계속 낮을 수 있습니다.	같은 설정이 UDP를 허용하는 다른 네트워크에서는 작동하는지 확인합니다.

요약: 먼저 UDP 연결 가능 여부를 확인한 다음 처리량을 비교하세요

같은 설정이 특정 네트워크에서만 시간 초과된다면 먼저 네트워크를 바꿔 비교하세요. 대역폭 값을 바로 높이거나 한 번 측정한 지연 시간만으로 프로토콜이 더 빠르다고 판단하지 마세요.

가져오기 전에 주소, 포트, 인증, TLS를 확인하세요

구독 정보가 있다면 서비스 제공업체가 제공한 전체 설정을 가져오는 것이 좋습니다. 인증 정보가 빠지는 일을 줄일 수 있습니다. 가져온 뒤 Home에서 해당 노드를 찾아 편집 화면을 열고 프로토콜 유형, 서버 주소, 포트, 인증 항목을 하나씩 확인하세요. 이름이 비슷하다는 이유만으로 Hysteria와 Hysteria2를 같은 설정으로 취급하면 안 됩니다. 가져올 때 서버 요구사항과 일치하는 유형을 선택하세요.

연결 및 인증 확인

프로토콜 유형: Hysteria2로 설정하고 서버 프로토콜과 일치하는지 확인합니다.
서버 주소: 제공된 도메인이나 IP를 그대로 입력합니다.
서버 포트: 제공된 값을 사용합니다. 포트가 443이라면 UDP 443도 허용되어야 합니다.
인증 정보: 대소문자와 기호를 그대로 유지하고, 복사할 때 함께 들어간 공백은 제거합니다.

443은 포트 예시일 뿐이며 모든 Hysteria2 노드에서 사용하는 고정 포트가 아닙니다.

TLS 및 추가 매개변수 확인

TLS: 인증서 검증 요구사항을 확인하세요. 검증을 끄는 방식으로 문제를 해결하는 것을 일반적인 방법으로 삼지 마세요.
SNI: 전용 이름이 제공되었다면 안내에 따라 입력하고 임의로 IP 주소로 바꾸지 마세요.
난독화 매개변수: 서버에서 요구하는 경우에만 입력하고, 유형과 비밀번호가 일치하는지 확인합니다.
대역폭 매개변수: 우선 가져온 값을 유지하세요. 변경하기 전에 단위와 항목의 의미를 확인합니다.

노드 편집 화면의 항목 배치는 다를 수 있습니다. 화면에서의 위치를 보고 추측하지 말고 각 항목의 의미를 기준으로 확인하세요.

TCP 443에 접속할 수 있다고 해서 UDP 443도 통과된다는 뜻은 아닙니다. 숫자는 같아도 전송 프로토콜과 방화벽 규칙은 서로 다릅니다. 회사, 학교, 호텔 네트워크 등에서는 일부 UDP 트래픽만 허용할 수 있습니다. DNS 조회가 된다고 해서 임의의 UDP 포트까지 연결 가능하다는 뜻도 아닙니다.

구독 업데이트와 노드 연결은 서로 다른 경로입니다. 업데이트 성공은 구독 내용을 가져왔다는 뜻일 뿐, 구독에 포함된 Hysteria2 서버에 연결할 수 있다는 의미는 아닙니다. 업데이트에 실패하면 먼저 현재 네트워크에서 구독 주소에 접속할 수 있는지, 서비스 제공업체가 안내한 링크가 여전히 유효한지 확인하세요. 인증 정보가 포함된 전체 구독 주소를 공개하지 마세요.

조건을 고정해 핸드셰이크, 라우팅, 처리량 문제를 구분하세요

테스트에서는 한 번에 하나의 변수만 바꾸세요. 네트워크, 노드, 대상 콘텐츠, 테스트 시간이 동시에 바뀌면 결과의 원인을 파악하기 어렵습니다. 아래는 기록 방법이며, 이 글에서 실제 측정한 성능 수치가 아닙니다. 실제 값은 사용 중인 기기와 현재 회선에서 측정해야 합니다.

네트워크 고정: 먼저 같은 Wi-Fi를 사용하고 대용량 파일 업로드와 백업을 일시 중지합니다. 다른 기기가 대역폭을 사용 중인지 기록하세요. 이후 셀룰러 네트워크를 별도로 테스트하고 두 결과를 섞지 마세요.
라우팅 확인: Home에서 Global Routing을 일시적으로 Proxy로 설정하고 테스트할 노드를 선택합니다. 이 설정은 테스트 중 트래픽 처리에 영향을 줍니다. 테스트가 끝나면 평소 사용하는 Config로 되돌리세요.
실제 접속 확인: 같은 HTTPS 페이지에 접속해 페이지가 끝까지 로드되는지 기록합니다. 노드가 사용 가능으로 표시되거나 한 번의 지연 시간 측정에 값이 나온다고 해서 프록시 연결 전체가 지속적으로 데이터를 전송할 수 있는 것은 아닙니다.
전송 반복: 신뢰할 수 있는 같은 대용량 파일을 연속 3회 테스트하고 매번 최소 30초 동안 관찰합니다. 순간 최고 속도만 기록하지 말고 평균 속도, 뚜렷한 멈춤, 실패 횟수를 확인하세요.
네트워크를 바꿔 재확인: 노드와 매개변수를 그대로 유지하고 다른 네트워크로 전환해 테스트를 반복합니다. 한 네트워크에서만 실패한다면 우선 해당 네트워크의 UDP 처리 방식을 확인하세요.

단위에 유의하세요. Mbps는 초당 메가비트, MB/s는 초당 메가바이트입니다. 십진 단위로 환산하면 80 Mbps는 약 10 MB/s이며, 실제 앱 처리량은 프로토콜 오버헤드의 영향을 받습니다. 이는 단위 예시일 뿐 속도를 보장하는 수치가 아닙니다. 속도 측정 결과와 설정의 대역폭 항목을 비교하기 전에 단위를 통일해야 합니다.

Config와 On Demand는 프로토콜의 기본 동작을 바꾸지 않습니다

Global Routing은 트래픽 처리 방식을 정하고, 노드 프로토콜은 프록시가 선택된 뒤 서버에 연결하는 방식을 정합니다. 평소 Config를 사용하면 규칙에 따라 각 요청이 지정된 정책으로 전달됩니다. Proxy는 테스트 범위를 좁힐 때 사용할 수 있고, Direct는 프록시를 거치지 않고 연결합니다. Scene은 상황에 따라 처리 방식을 선택하는 기능이지, Hysteria2의 또 다른 혼잡 제어 방식이 아닙니다.

Home: 선택된 노드와 Global Routing을 확인해 속도 테스트 중 다른 노드나 Direct가 실제로 사용되는 일을 방지합니다.
Config: 현재 활성화된 설정과 규칙 순서를 확인합니다. DOMAIN-SUFFIX는 도메인 접미사를 매칭하고, IP-CIDR은 주소 범위를 매칭하며, GEOIP는 지리적 주소 분류를 사용합니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다.
Settings → On Demand: 자동 연결 조건이 테스트에 영향을 주는지 확인합니다. Wi-Fi와 셀룰러 네트워크를 전환한 뒤에는 현재 연결 상태를 다시 확인하세요.

On Demand는 조건에 따라 자동으로 연결하는 기능입니다. 네트워크에서 UDP가 제한되어 있어도 이를 허용하게 만들지는 않으며, 노드 인증을 대신하지도 않습니다. 문제를 확인하는 동안 현재 조건을 기록하고, 필요한 경우 자동 실행을 잠시 끈 뒤 수동으로 연결하세요. 확인이 끝나면 다시 설정을 복원합니다. 평소 연결 동작을 잊지 않고 되돌릴 수 있도록 변경 전에 기존 설정을 기록해 두세요.

Hysteria2 연결 문제 해결

Wi-Fi에서는 계속 시간 초과되는데 셀룰러에서는 연결됩니다. 무엇을 확인해야 하나요?

주소, 포트, 인증, TLS 매개변수는 그대로 두고 두 네트워크에서 각각 반복 연결해 보세요. 차이가 일관되게 재현된다면 해당 Wi-Fi에서 먼저 네트워크 로그인이 필요한지, 대상 UDP 포트가 제한되는지 확인합니다. 관리되는 네트워크라면 관리자에게 규칙을 문의하세요. 포트를 무작정 바꾸지 마세요. 서버에서 수신 대기하지 않는 포트로는 연결할 수 없습니다.

지연 시간은 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?

Home으로 돌아가 노드와 Global Routing을 확인하고 Proxy로 제어된 접속 테스트를 한 번 수행한 뒤 Config로 되돌리세요. Proxy에서는 되지만 Config에서는 되지 않는다면 대상 요청에 적용된 규칙과 정책을 확인합니다. 두 설정 모두 실패한다면 인증, TLS, 서버 상태를 점검하세요. 지연 시간 값만으로 대상 요청이 성공적으로 전달되었다고 판단할 수는 없습니다.

대역폭 값을 높일수록 더 빨라지나요?

그렇지 않습니다. 가져온 매개변수를 그대로 둔 채 다른 대용량 트래픽을 중지하고 3회 테스트 결과를 기록하세요. 항목의 단위, 서버 요구사항, 로컬에서 사용 가능한 용량을 명확히 확인한 뒤에만 하나씩 조정합니다. 값을 바꾼 뒤 멈춤, 패킷 손실, 대화형 지연이 늘어나면 원래 값으로 되돌리고 더 높이지 마세요.

구독을 업데이트해도 계속 실패하면 앱을 다시 구매해야 하나요?

먼저 Home에서 업데이트된 노드가 실제로 선택되어 있는지 확인한 다음 프로토콜과 포트가 바뀌었는지 살펴보세요. 설정이 유효한지는 서비스 제공업체에 문의합니다. 앱 구매와 회선 서비스는 별개입니다. 클라이언트를 다시 구매해도 서버 장애나 현재 네트워크의 UDP 제한은 해결되지 않습니다.

최종 판단은 같은 조건에서 반복해서 확인할 수 있는 결과를 기준으로 해야 합니다. 멈춤이 줄었는지, 요청이 완료되는지, 대화형 지연이 허용 가능한 수준으로 유지되는지 확인하세요. Hysteria2는 UDP 연결이 가능한 환경에서 다른 방식을 비교할 때 활용할 수 있지만, 프로토콜 이름만 보고 모든 연결을 바꾸는 것은 적절하지 않습니다. 검증된 설정을 보관해 두면 네트워크 조건이 바뀌었을 때 이전 설정으로 되돌리고 문제를 파악하는 데 도움이 됩니다.