이 글은 사용할 서비스의 설정이나 구독 정보를 이미 보유하고 있으며, Shadowrocket에서 Hysteria2 매개변수를 확인하려는 사용자를 위한 안내입니다. 먼저 QUIC과 UDP의 역할을 구분한 뒤 서버, 포트, 인증, TLS, SNI를 차례로 점검하고, 같은 네트워크와 요청을 기준으로 문제가 전송, 인증, 라우팅 중 어디서 발생하는지 확인합니다. 노드나 구독을 제공·판매·추천하지 않습니다.
Hysteria2, QUIC, UDP의 관계
Shadowrocket의 Hysteria2는 프록시 프로토콜 유형입니다. Global Routing의 모드가 아니며, 활성화만 하면 모든 연결에 적용되는 가속 기능도 아닙니다. 해당 항목을 실제로 선택하고 요청이 그 항목이나 해당 항목을 포함한 정책으로 라우팅되어야 그 연결을 통해 요청이 전송됩니다.
Hysteria2는 QUIC을 전송 기반으로 사용하며, QUIC은 UDP를 기반으로 작동합니다. UDP 자체에는 재전송이나 순서 보장 기능이 없습니다. QUIC은 UDP 위에서 암호화, 스트림 관리, 안정적인 전송 등의 기능을 제공합니다. 따라서 UDP 기반이라고 해서 웹 데이터가 손실되어도 괜찮다는 뜻은 아니며, 앱에서 발생한 기존 TCP 요청의 신뢰성이 사라지는 것도 아닙니다.
내부와 외부 전송을 구분해야 합니다. 앱이 웹사이트에 접속할 때 TCP를 사용할 수 있지만, Shadowrocket이 해당 요청을 Hysteria2로 전달하면 기기와 프록시 서버 사이에는 UDP 기반 QUIC 연결이 사용됩니다. 대상 웹사이트가 QUIC을 지원할 필요는 없습니다. 프록시 서버와 대상 웹사이트 사이의 연결은 기기와 프록시 서버 사이의 외부 전송과 별개의 구간입니다.
- UDP: 데이터그램 전송을 담당합니다. 현재 네트워크에서 기기와 서버의 해당 UDP 포트 간 통신이 가능해야 합니다.
- QUIC: 연결, 암호화, 스트림 전송을 담당합니다. 여러 스트림을 사용할 경우 기존 단일 TCP 연결에서 발생하는 패킷 손실의 스트림 간 블로킹을 줄일 수 있지만, 하나의 신뢰성 있는 스트림은 여전히 패킷 손실 복구의 영향을 받습니다.
- Hysteria2: 위 전송 기반에서 인증, 프록시 요청, 데이터 전달 방식을 정의합니다. 클라이언트와 서버의 설정값이 서로 일치해야 합니다.
패킷 손실이 많은 네트워크에서의 특성과 사용 한계
Hysteria2는 지연 시간이 길고 손실이 발생하는 링크를 고려한 혼잡 제어 방식을 포함하며, Brutal 메커니즘은 설정된 대역폭 값과 관련이 있습니다. 안정적인 처리량을 확보할 수 있는지는 링크 용량, 패킷 손실 원인, 서버 부하, 실제 혼잡 제어 방식에 따라 달라집니다. 프로토콜 이름만으로 일정한 속도를 예상할 수 없으며, 패킷 손실이 많을수록 더 큰 효과를 얻는 것도 아닙니다.
특히 무작위 패킷 손실과 혼잡으로 인한 패킷 손실을 구분해야 합니다. 무선 신호 변동으로 일부 패킷이 무작위로 손실되는 경우, 적절한 전송 방식이 네트워크 활용도를 개선할 수 있습니다. 반면 출구 구간이 이미 혼잡하다면 전송량을 계속 높일수록 대기열, 지연 시간, 패킷 손실이 늘어날 수 있습니다. 대역폭 값을 사용 가능한 업로드 용량보다 훨씬 크게 설정해도 용량이 늘어나지는 않습니다.
점검 순서: UDP 연결 가능 여부를 먼저 확인한 뒤 대역폭을 조정하세요
같은 설정이 셀룰러 네트워크에서는 작동하지만 특정 Wi-Fi에서 계속 핸드셰이크 시간 초과가 발생한다면, 먼저 해당 Wi-Fi에서 서버 UDP 포트까지의 경로를 점검하세요. 대역폭을 높이거나 인증서 검증을 끄는 방법으로 전송 불가 문제를 해결하려고 하지 마세요.
- 검토해 볼 수 있는 환경: UDP 통신이 가능하고 서버 설정이 명확하며, 현재 링크의 지연 시간이 길거나 무작위 패킷 손실이 발생하는 경우입니다.
- 주의가 필요한 환경: UDP가 엄격하게 제한되거나 출구 구간이 장시간 포화 상태인 경우, 또는 데이터 사용량과 기기 배터리 소모를 관리해야 하는 경우입니다.
- 직접 해결할 수 없는 문제: 잘못된 인증 정보, 만료된 인증서, 잘못된 규칙, 대상 웹사이트 자체의 장애입니다.
Shadowrocket에서 Hysteria2 항목 확인하기
기존 구독에는 보통 서버 설정이 포함되어 있으므로, 먼저 가져온 설정을 확인하세요. 서로 다른 항목의 설정값을 조합해서 사용하지 마세요. 직접 추가하려면 Home에서 추가 버튼을 누르고 Type에서 Hysteria2를 선택한 다음 보유한 설정에 따라 입력합니다. 항목 순서와 표시되는 옵션은 앱 인터페이스에 따라 달라질 수 있습니다. 표시되지 않는 고급 매개변수를 다른 옵션으로 대신 설정하지 마세요.
| 항목 또는 매개변수 | 입력 기준 | 자주 하는 실수 |
|---|---|---|
| Type | 서버 프로토콜과 일치하도록 Hysteria2를 선택합니다. | Hysteria와 Hysteria2를 서로 바꿔 쓸 수 있는 유형으로 간주합니다. |
| 서버 주소 | 보유한 설정에 기재된 호스트 이름 또는 IP 주소를 입력합니다. | 경로 또는 쿼리 매개변수가 포함된 구독 URL 전체를 주소 입력란에 넣습니다. |
| 포트 | 서버가 실제로 수신 대기하는 UDP 포트를 입력합니다. 예를 들어 설정에 443으로 명시되어 있을 수 있습니다. | 모든 서버가 443을 사용한다고 가정하거나 TCP 443 연결만 확인합니다. |
| 인증 정보 | 기존 설정에 지정된 인증값을 그대로 입력합니다. | 복사할 때 공백을 함께 넣거나 구독 token을 연결 비밀번호로 사용합니다. |
| TLS / SNI | 인증서 검증을 유지하고, SNI에는 설정에서 요구하는 서버 이름을 입력합니다. | 연결 주소가 IP라는 이유로 해당 IP를 인증서 이름으로 잘못 입력합니다. |
| obfs | 서버에서 해당 기능을 활성화하고 관련 매개변수를 제공한 경우에만 설정합니다. | 혼란 방지용 비밀번호를 인증 정보와 혼용하거나 클라이언트에서만 활성화합니다. |
| 대역폭 매개변수 | 인터페이스에서 제공하는 경우 실제 업로드·다운로드 성능과 기존 설정에 맞춰 입력하고 단위를 확인합니다. | Mbps와 MB/s를 혼동하거나, 지속 가능한 용량 대신 이론상 최고 속도를 기준으로 입력합니다. |
SNI는 TLS 핸드셰이크 중 서버 이름을 전달하는 데 사용됩니다. 인증서 검증에서는 서버의 신원이 예상한 이름과 일치하는지도 확인해야 합니다. 서버 주소는 연결 대상 위치를 지정하고, SNI와 인증서 이름은 검증 대상을 지정하므로 둘은 다를 수 있지만 명확한 설정 근거가 있어야 합니다. 인증서 오류가 발생하면 검증을 건너뛰는 것을 일반 설정으로 삼지 말고 이름, 기기 시간, 서버 인증서를 확인하세요.
Hysteria2와 이전 버전 Hysteria의 프로토콜 및 매개변수는 서로 바로 호환되지 않습니다. 구독을 업데이트한 뒤 유형이 잘못 인식되면 원래 항목에 Hysteria2가 명시되어 있는지, 앱이 해당 구독 형식을 인식할 수 있는지 확인하세요. 항목 이름만 바꿔도 실제 프로토콜은 바뀌지 않습니다.
기존 구독 가져오기·업데이트 및 최초 연결 확인
구독 URL은 설정을 가져오는 경로이지 프록시 서버 주소가 아닙니다. 설정을 불러오는 데 필요한 인증 정보가 포함될 수 있으므로 민감한 정보로 취급해야 합니다. 아래 주소는 구조를 확인하기 위한 예시이며 실제 연결에는 사용할 수 없습니다: https://example.com/sub?token=xxxx. 실제 구독 링크를 공개 스크린샷이나 문제 해결 기록에 포함하지 마세요.
- 기존 구독 가져오기: Home에서 추가 버튼을 누르고 Type에서 Subscribe를 선택한 다음, 본인의 구독 URL을 URL 입력란에 넣고 저장합니다. Home으로 돌아가 해당 그룹이 나타났는지, Hysteria2 항목을 확인할 수 있는지 살펴보세요.
- 업데이트 결과 확인: 새로고침이 필요하면 해당 구독에서 Update를 실행하고 완료될 때까지 기다린 뒤 항목 유형, 서버, 포트를 확인합니다. 가져오기에 실패하면 구독 주소에 연결할 수 없는 문제와 프록시 서버에 연결할 수 없는 문제를 구분하세요.
- 테스트 항목 선택: Home에서 확인하려는 Hysteria2 항목을 선택하고 이름과 포트를 기록합니다. 정책 그룹을 통해 출구를 선택하는 경우에는 해당 그룹에서 실제로 그 항목이 선택되어 있는지도 확인하세요.
- 라우팅 변수 통제: 선택한 출구를 확인하려면 Global Routing에서 일시적으로 Proxy를 사용하세요. 테스트를 마치면 기존 라우팅 모드로 되돌립니다. Direct로는 프록시 경로를 확인할 수 없으며, Config에서는 현재 설정의 규칙을 함께 살펴봐야 합니다.
- 연결한 뒤 요청 보내기: 연결 스위치를 켭니다. 처음 사용하는 경우 시스템 안내에 따라 VPN 구성을 허용하세요. 이후 정상적으로 접속되는 것으로 확인된 페이지를 열어 핸드셰이크, 인증, 인증서, 이름 확인 오류가 발생하는지 살펴봅니다.
- 일상 설정으로 복원: Global Routing에서 Config로 돌아간 뒤 동일한 요청에 적용되는 규칙과 정책을 확인합니다. Proxy에서는 연결되지만 규칙을 복원한 뒤 다른 출구로 라우팅되는 상황은 아닌지 살펴보세요.
핸드셰이크 시간 초과, 인증서 오류, 라우팅 문제 구분하기
문제 해결 시 모든 필드를 반복해서 바꾸기보다 연결 단계별로 나누어 확인하면 원인을 찾기 쉽습니다. 현재 네트워크, 선택한 항목, Global Routing 모드, 오류 문구를 기록한 뒤 한 번에 한 항목만 바꾸세요. 지연 시간 테스트에 결과가 나왔다는 것은 해당 테스트가 확인한 단계에서 응답이 있었다는 뜻일 뿐, 실제 웹 요청을 대신하거나 모든 UDP 전달이 정상임을 증명하지는 않습니다.
같은 항목이 Wi-Fi에서는 시간 초과되지만 셀룰러 네트워크에서는 작동하나요?
서버, 포트, 인증값은 그대로 두고 네트워크만 바꿔 다시 테스트하세요. 차이가 반복해서 나타난다면 Wi-Fi의 UDP 외부 연결 제한, 라우팅, 방화벽을 먼저 확인합니다. TCP 443에 연결할 수 있다고 해서 UDP 443도 사용 가능하다는 뜻은 아닙니다. UDP가 차단되더라도 Hysteria2가 자동으로 TCP 연결로 전환되지는 않습니다.
인증서 이름이 일치하지 않는다는 메시지가 표시되면 어디를 수정해야 하나요?
Home으로 돌아가 해당 항목을 편집하고, 보유한 설정에 따라 서버 주소와 SNI를 확인한 뒤 기기의 날짜와 시간이 올바른지 점검하세요. 주소가 IP이고 인증서가 도메인용으로 발급된 경우, 설정에 지정된 이름으로 검증해야 합니다. 계속 오류가 발생하면 검증을 끄는 대신 서버 측 인증서를 확인해야 합니다.
Proxy에서는 열리지만 Config에서는 연결되지 않나요?
Config에서 현재 사용 중인 설정을 확인한 뒤 규칙 순서와 대상 정책을 점검하세요. 규칙은 일반적으로 위에서 아래로 매칭됩니다. DOMAIN-SUFFIX, IP-CIDR, GEOIP, FINAL 규칙에 따라 같은 요청도 서로 다른 정책으로 라우팅될 수 있습니다. 실제 매칭 결과를 먼저 확인하고, 이를 근거로 Hysteria2 핸드셰이크가 실패했다고 단정하지 마세요.
연결 직후에는 괜찮지만 전송이 계속되면 지연 시간이 크게 늘어나나요?
먼저 업로드를 사용하는 다른 작업을 중지하고, 기존 설정의 대역폭 매개변수와 단위를 확인한 뒤 같은 요청으로 다시 테스트하세요. 인터페이스에서 조정 가능한 매개변수를 제공한다면 값을 단계적으로 낮추면서 대기열 지연을 살펴봅니다. 원인을 확인할 수 없게 되므로 포트, SNI, 인증값을 동시에 변경하지 마세요.
일부 웹사이트에서만 문제가 발생한다면 DNS 확인, 규칙 매칭, 대상 서비스의 제한을 추가로 구분해야 합니다. 연결 스위치가 켜져 있다는 사실은 시스템 VPN이 해당 상태라는 뜻일 뿐, 모든 도메인이 동일한 출구를 사용한다는 의미는 아닙니다. 자동 연결이 필요할 때 Settings → On Demand는 연결을 시작하는 설정이며, 잘못된 Hysteria2 인증 정보나 포트를 고쳐 주지는 않습니다.
일정한 조건에서 현재 네트워크에 적합한지 평가하기
평가는 한 번 측정한 최고 속도가 아니라 평소 사용하는 네트워크를 기준으로 해야 합니다. 기기, 서버, 대상 리소스, Global Routing 모드를 동일하게 유지하고 비슷한 시간대에 반복해서 테스트하며, Wi-Fi와 셀룰러 네트워크 결과를 따로 기록하세요. 동일한 조건의 데이터가 없다면 ‘몇 퍼센트 향상된다’고 판단해서는 안 됩니다.
- 연결 성공률 기록: 예를 들어 연결을 끊은 뒤 다시 시도하는 방식으로 5회 연속 테스트하고, 성공 횟수와 실패 단계를 기록합니다. 이는 테스트 방법이지 프로토콜 성능 데이터가 아닙니다.
- 응답 지연 기록: 페이지의 첫 응답과 지속 전송 중의 반응을 살펴보세요. 평균 처리량이 높아도 웹페이지가 처음 열리는 속도가 반드시 더 빠른 것은 아닙니다.
- 네트워크 전환 영향 기록: Wi-Fi에서 셀룰러 네트워크로 전환한 뒤 요청을 다시 보냅니다. 기존 세션이 유지되는지는 네트워크와 구현 방식에 따라 달라지므로 QUIC이라는 이름만으로 보장할 수 없습니다.
- 리소스 사용량 기록: 데이터 사용량과 기기 배터리 소모를 확인하세요. 재전송과 추가 전송 때문에 측정값이 앱 콘텐츠 크기보다 커질 수 있으므로 실제 사용 상황을 함께 고려해야 합니다.
안정적으로 재현할 수 있는 설정을 유지한 뒤 일상적인 Config 라우팅으로 복원하세요. 특정 네트워크에서만 실패한다면 해당 경로를 우선 조사해야 합니다. Hysteria2를 선택할 때는 UDP 연결 가능 여부, 설정값의 정확성, 반복 테스트 결과를 기준으로 삼으세요. 프로토콜 유형 하나로 모든 연결 문제를 해결할 수는 없습니다.