Shadowrocket Hysteria2 사용법: QUIC 기반 전송의 속도와 적합한 네트워크

Hysteria2, QUIC, UDP의 역할

요점: Hysteria2는 QUIC으로 클라이언트와 서버 사이의 전송 채널을 만들고, QUIC 패킷은 UDP를 통해 전송됩니다. UDP는 하위 계층의 전송 수단일 뿐, 모든 애플리케이션 데이터가 신뢰할 수 없는 방식으로 전송된다는 뜻은 아닙니다. QUIC은 UDP 위에서 암호화, 확인 응답, 패킷 손실 복구, 신뢰성 있는 스트림 전송을 제공할 수 있습니다.

앱에서 웹사이트에 접속할 때 원래 연결과 프록시 전송 채널은 서로 다른 계층입니다. 예를 들어 웹사이트 요청 자체는 TCP를 사용할 수 있지만, Shadowrocket과 Hysteria2 서버 사이의 외부 연결은 여전히 QUIC을 사용합니다. 방화벽이나 서버 포트를 점검할 때는 외부 연결에 사용되는 UDP를 확인해야 합니다. 같은 숫자의 TCP 포트가 열려 있는지만 확인해서는 충분하지 않습니다.

QUIC의 여러 스트림은 서로 독립적으로 진행될 수 있습니다. 한 스트림에서 패킷이 손실되더라도 다른 스트림에서 이미 받은 데이터까지 반드시 대기해야 하는 것은 아닙니다. 따라서 스트림 간 헤드 오브 라인 블로킹을 줄일 수 있지만, 같은 신뢰성 있는 스트림에서 누락된 데이터는 여전히 복구해야 하며 여러 스트림은 같은 네트워크 회선을 공유합니다. 동영상, 웹페이지, 파일 전송이 서로 전혀 영향을 주지 않는다고 볼 수는 없습니다.

속도가 빨라질 수 있는 이유: UDP 자체보다 혼잡 제어가 중요합니다

요점: 일부 패킷 손실이 많은 회선에서 Hysteria2가 유리할 수 있는 이유는 혼잡 제어와 전송 방식에 있으며, “UDP가 원래 TCP보다 빠르기 때문”은 아닙니다. 회선의 패킷 손실은 혼잡, 무선 간섭 또는 그 밖의 무작위 손실 때문에 발생할 수 있습니다. 모든 손실을 혼잡으로 간주해 전송량을 크게 줄이면 사용 가능한 대역폭을 충분히 활용하지 못할 수 있습니다.

Hysteria2의 Brutal 혼잡 제어는 설정된 대역폭 목표와 손실 상황을 바탕으로 전송 방식을 조정합니다. 실제 전송량을 늘려 유효 처리량을 높일 수 있습니다. 대역폭 협상을 지원하는 설정에서는 클라이언트가 알리는 수신 성능, 서버 제한, 실제 경로 용량이 모두 결과에 영향을 줍니다. BBR 등의 혼잡 제어 방식이 사용되는 경우도 있으므로, 이름만 보고 현재 연결이 반드시 특정 모드라고 단정해서는 안 됩니다.

• 무작위 패킷 손실이 눈에 띄지만 회선 용량은 충분한 경우: 손실을 보완하는 전송 방식으로 처리량을 더 잘 유지할 수 있지만, 같은 작업을 반복 테스트해 확인해야 합니다.
• 실제로 회선이 혼잡한 경우: 전송량을 더 늘리면 대기열이 길어져 파일 전송 중 웹페이지 응답이 느려질 수 있습니다.
• 패킷 손실이 적고 지연 시간이 안정적인 경우: 프로토콜 차이가 주요 병목이 아닐 수 있으며, 서버 부하와 사용 가능한 대역폭, 대상 웹사이트가 속도를 좌우할 수 있습니다.
• UDP가 차단되거나 엄격하게 제한되는 경우: 연결을 설정하지 못하거나 처리량이 매우 낮을 수 있습니다. 대역폭 값을 바꿔도 네트워크 제한은 해제되지 않습니다.

대역폭 필드에서는 단위도 확인해야 합니다. Mbps는 초당 메가비트, MB/s는 초당 메가바이트를 뜻합니다. 십진 단위로 계산하면 80 Mbps의 이론상 최대 속도는 약 10 MB/s이며, 실제 애플리케이션 데이터 속도에서는 프로토콜 오버헤드와 재전송을 제외해야 합니다. 설정값은 앱의 필드 설명을 기준으로 입력하고, 파일 전송 도구에 표시된 숫자를 그대로 옮기지 마세요.

Shadowrocket에서 확인할 Hysteria2 설정값

요점: 성능 옵션을 조정하기 전에 서버에서 제공한 정보를 앱에 빠짐없이 입력하세요. Hysteria2는 이전 Hysteria 프로토콜과 이름만 바꿔 서로 전환할 수 없습니다. 가져온 뒤 Type이 실제로 Hysteria2인지 확인하세요. 아래는 설정값의 의미를 설명한 내용이며, Config에 그대로 붙여 넣을 수 있는 설정 문법이 아닙니다.

연결 주소는 데이터를 서버로 전달하고, SNI는 TLS 핸드셰이크에서 서버 이름을 전달하며 일반적인 인증서 이름 확인에도 사용됩니다. 두 값은 서로 다를 수 있지만 신뢰할 수 있는 설정 안내를 따라야 합니다. 인증서 오류가 발생하면 이름, 기기 시간, 서버 인증서 상태를 확인하세요. 먼저 인증서 검증을 끄지는 마세요.

• 필드 이름과 표시되는 옵션, 고급 설정은 앱에 실제로 표시되는 내용을 기준으로 확인하세요. 구독에 선택 항목이 없다고 해서 임의로 값을 추가할 필요는 없습니다.
• 구독을 사용 중이라면 먼저 구독을 업데이트해 수정된 설정값을 받으세요. 수동으로 변경하기 전에는 기존 값을 기록해 두어 다음 업데이트 후 설정이 섞이지 않도록 하세요.
• 문제 해결 정보를 공유할 때는 오류 유형과 설정 항목 이름만 남기세요. 인증 문자열, 구독 주소에 포함된 토큰, 관련 비밀번호는 가려야 합니다.

가져오기와 첫 연결 확인: 먼저 연결한 다음 규칙을 점검하세요

요점: 먼저 Home에서 설정을 가져오고 항목을 선택한 다음, 단일 테스트 요청으로 연결을 확인하세요. Home에서는 서버와 연결 상태를 관리하고 Config에서는 규칙 설정을, Settings에서는 앱 설정을 관리합니다. 전송 실패와 규칙 선택 오류를 따로 살펴봐야 원인을 좁힐 수 있습니다.

1. 설정값 준비

   이미 이용 중인 서비스 제공업체의 안내에서 서버 주소, 포트, 인증 정보, TLS 요구 사항을 확인하세요. 구독을 사용한다면 구독에 Hysteria2 항목이 실제로 포함되어 있는지 확인하세요. 항목의 메모나 이름만으로 프로토콜을 판단하지 마세요.

2. 구독 가져오기

   Home 오른쪽 위에서 “+”를 선택한 다음 Type → Subscribe로 이동해 본인의 구독 주소를 입력하고 저장하세요. 그런 다음 Home에서 해당 구독을 업데이트합니다. 주소에 인증 토큰이 포함되어 있다면 비밀번호처럼 다루세요.

3. 유형 확인

   가져온 항목의 편집 화면을 열어 Type이 Hysteria2인지 확인하고 위 표에 따라 설정값을 점검하세요. 직접 추가하려면 Home → “+” → Type → Hysteria2를 선택한 다음 기존 설정을 기준으로 항목을 하나씩 입력하세요.

4. 연결 확인

   Home으로 돌아가 해당 항목을 선택하고 연결을 켠 다음, 시스템 안내에 따라 VPN 구성을 추가하도록 허용하세요. 연결을 시작한 뒤 나타나는 결과를 기록하세요. 계속 대기 중인지, 구체적인 오류가 표시되는지, 지정한 테스트 페이지가 열리는지 확인합니다.

5. 라우팅 확인

   Home → Global Routing에서 현재 모드를 확인하세요. 규칙의 영향을 잠시 분리해야 한다면 Proxy로 같은 요청을 테스트한 뒤 평소 사용하는 Config로 돌아가 대상 도메인에 실제로 적용된 정책을 확인하세요.

첫 테스트 중에는 Settings → On Demand도 확인하세요. 주문형 연결이 활성화되어 있다면 그 상태를 기록하세요. 연결을 끊거나 네트워크를 전환하는 테스트에서는 자동 연결이 관찰을 방해하지 않도록 잠시 끄고, 테스트 후 다시 켤 수 있습니다. On Demand는 연결이 시작되는 조건을 관리하며 Hysteria2의 인증, TLS, UDP 연결 문제를 해결하지는 않습니다.

Global Routing으로 프로토콜 문제와 규칙 문제 구분하기

요점: 같은 Hysteria2 항목으로 Proxy에서는 접속되지만 Config에서는 안 된다면 전송 설정을 바로 바꾸기보다 규칙이 적용된 방식과 선택된 정책을 먼저 확인하세요. 아래 비교는 이번 검증에 사용하는 Global Routing의 세 가지 모드에만 해당합니다. Direct는 대상에 원래 직접 연결할 수 있을 때만 기준으로 사용하세요.

규칙을 확인할 때 DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 IP 주소 대역으로 일치 여부를 판단하며 GEOIP는 IP 지리 데이터베이스를 기준으로 판단합니다. FINAL은 앞선 규칙이 일치하지 않을 때 적용할 최종 정책입니다. 규칙은 순서대로 처리되므로 앞쪽의 DIRECT 또는 REJECT가 일치하면 뒤의 프록시 정책으로 해당 결과를 바꿀 수 없습니다. DNS 조회 결과도 IP 기반 판정에 영향을 줄 수 있습니다.

연결 실패, 저속, 연결 끊김을 단계별로 점검하는 방법

요점: “서버에 도달했는지 → 핸드셰이크와 인증이 완료됐는지 → 라우팅이 올바른지 → 처리량 병목이 있는지” 순서로 확인하세요. 지연 시간 하나로는 특정 탐색 결과만 알 수 있으며 UDP 연결 가능 여부, 인증 유효성, 지속적인 전송 안정성을 모두 입증할 수 없습니다. 탐색 시간이 초과되었다면 실제 연결 결과와 함께 판단해야 합니다.

위 내용은 오류를 식별하기 위한 조건이며 이 사이트에서 직접 측정한 결과가 아닙니다. 직접 비교 기록을 남기려면 같은 네트워크에서 같은 파일을 연속으로 세 번 테스트하고, 매번 30초 동안 성공 여부와 안정된 구간의 속도, 동시에 웹페이지를 열었을 때의 응답을 기록하세요. 테스트 시간과 대상을 고정하면 캐시, 대상 사이트의 속도 제한, 순간적인 네트워크 변동으로 인한 오판을 줄일 수 있습니다.

• 매 회차 변수는 하나만 바꾸세요: 예를 들어 첫 회차에는 Wi-Fi와 셀룰러 네트워크만 전환하고, 두 번째 회차에서 대역폭 설정값을 확인하세요.
• 지연 시간과 처리량을 함께 확인하세요: 속도는 높아졌지만 응답성이 뚜렷하게 떨어졌다면 대기열이 늘어난 것일 수 있습니다. 설정이 더 나아졌다고 단정할 수는 없습니다.
• 데이터 사용량에 유의하세요: 지속적인 전송과 패킷 손실 보정은 추가 데이터를 사용할 수 있으므로 테스트 전에 네트워크 요금 조건을 확인하세요.
• 다시 확인할 수 있도록 기록을 남기세요: 연결 네트워크, 선택한 항목, Global Routing 모드, 테스트 대상, 오류 문구를 기록하되 인증 정보는 공개하지 마세요.

적합성 판단과 사용 전제

UDP를 사용할 수 있고 무작위 패킷 손실이나 지연 시간 변동이 있는 네트워크에서는 기존 설정을 사용해 Hysteria2를 비교 테스트해 볼 수 있습니다. UDP가 제한되거나 서버 외부 회선이 포화 상태이거나 대상 자체에 속도 제한이 있다면 프로토콜 이름만으로 병목을 해결할 수 없습니다. 장기간 사용할 때는 성공률, 지속 처리량, 응답성, 데이터 사용량을 함께 고려해야 하며 지연 시간이 가장 낮았던 한 번의 결과만으로 판단하지 마세요.

• 설정값이 모두 맞는데 핸드셰이크에 실패한다면 대역폭 수치를 높이기 전에 UDP, TLS, 인증을 확인하세요.
• 핸드셰이크는 성공했지만 대상 접속에 문제가 있다면 Global Routing과 Config 규칙을 확인하세요.
• 연결은 되지만 속도가 불안정하다면 작업과 네트워크를 고정해 반복 테스트한 뒤 혼잡 제어 방식이 회선 조건에 맞는지 판단하세요.

Shadowrocket은 클로즈드 소스 상용 앱이며 주로 iPhone과 iPad에서 사용합니다. Mac, Apple TV, Apple Vision과의 호환성은 App Store 제품 페이지에서 확인할 수 있습니다. 시스템 요구 사항, 호환성, 유니버설 구입 여부는 App Store 페이지의 안내를 기준으로 확인하세요. 유일한 구매 경로는 App Store이며 개발자는 Shadow Launch Technology Limited, 앱 ID는 932747118입니다. 앱은 일회성 구매 방식이며 가격은 스토어 표시를 기준으로 합니다.