자신이 이용 중인 서비스와 구독 정보가 있고 Hysteria2를 사용하려는 분을 위한 안내입니다. 먼저 QUIC 전송과 혼잡 제어의 차이를 살펴본 뒤, Shadowrocket의 연결 매개변수를 확인하고 일정한 조건에서 네트워크 적합성을 테스트합니다. 필수 설정 항목과 연결 시간 초과, 인증서 오류, 불안정한 전송 속도를 각각 어느 단계에서 점검해야 하는지 알 수 있습니다.
먼저 클라이언트, 프로토콜, 네트워크 경로의 범위를 확인하세요
Shadowrocket은 iPhone과 iPad를 중심으로 제공되는 Apple 플랫폼용 유료 클라이언트이며, App Store에서만 받을 수 있습니다. App Store 페이지에서 개발자 Shadow Launch Technology Limited와 앱 ID 932747118을 확인할 수 있습니다. 앱은 일회성 구매 방식이며, 시스템 요구 사항과 호환 기기, 통합 구매 여부는 App Store 페이지의 안내를 기준으로 확인하세요.
클라이언트 구매와 네트워크 서비스 요금제는 별개입니다. 이 안내는 사용자가 이미 이용 중인 서비스와 구독 정보가 있다는 전제에서 설명합니다. Hysteria2는 연결 프로토콜이지 구독 자체가 아닙니다. 같은 구독에 여러 프로토콜의 연결 정보가 포함될 수 있으며, 구독이 갱신되더라도 모든 연결 정보가 현재 네트워크에서 작동한다는 뜻은 아닙니다. Shadowrocket은 소스가 공개되지 않은 상용 앱이며, 앱 설치, 구독 갱신, 서버 관리는 서로 다른 과정입니다.
- 클라이언트: 설정값을 읽고 연결을 구성하며, 라우팅 설정에 따라 요청을 처리합니다.
- Hysteria2: 클라이언트와 서버 간 통신 방식을 정합니다. 양쪽에서 호환되는 프로토콜과 매개변수를 사용해야 합니다.
- 네트워크 경로: 로컬 네트워크 연결, 통신사 경로, 서버 용량, 서버에서 목적지 사이트까지의 경로를 포함합니다.
- 설정 규칙: 요청을 해당 연결로 보낼지 결정합니다. 프로토콜만 바꿔서는 잘못된 라우팅 규칙을 바로잡을 수 없습니다.
QUIC은 왜 더 빠를 수 있을까? 연결 재사용과 패킷 손실 복구
Hysteria2는 QUIC을 기반으로 합니다. QUIC은 UDP를 사용하며 TLS 1.3 보안 핸드셰이크를 통합합니다. UDP를 쓴다고 웹 데이터가 아무런 관리 없이 전송되는 것은 아닙니다. QUIC은 스트림에서 확인 응답, 재전송, 흐름 제어를 포함한 안정적이고 순서가 보장된 전송을 구현할 수 있습니다. 앱에서 발생하는 TCP 요청과 UDP 요청은 Hysteria2를 통해 각각 전달할 수 있습니다.
QUIC을 이해할 때 중요한 점은 스트림 간 격리입니다. 기존 TCP 연결에서 데이터 일부가 손실되면 이후 바이트를 받기 전에 해당 데이터를 보충해야 합니다. 여러 요청이 하나의 바이트 스트림을 공유하면 모두 대기할 수 있습니다. QUIC에서는 각 스트림이 독립적으로 데이터를 전달하므로, 한 스트림에 누락된 데이터가 있어도 이미 수신을 마친 다른 스트림은 그 누락을 기다릴 필요가 없습니다. 다만 같은 스트림 안에서는 여전히 순서대로 전달되며, 스트림끼리 네트워크 용량과 혼잡 상태를 공유합니다.
연결을 재사용하면 반복해서 연결을 설정하는 데 드는 비용을 줄일 수 있지만, 언제나 대기 시간이 전혀 없다는 뜻은 아닙니다. 첫 접속, 인증서 확인, 도메인 이름 조회, 목적지 사이트의 응답에는 여전히 시간이 걸립니다. 기존 연결을 재사용할 수 있는지는 연결 상태와 구현 방식에 따라서도 달라집니다. 웹 페이지가 느리게 열리는 원인이 반드시 전송 프로토콜인 것은 아닙니다.
판단 기준: 먼저 UDP 연결 여부를 확인한 뒤 전송 속도를 살펴보세요
현재 네트워크에서 서버의 UDP 수신 대기 포트에 접근할 수 없다면 대역폭 설정을 바꿔도 소용이 없습니다. 먼저 서버에서 실제 사용하는 포트를 확인해 연결을 테스트하고, 그다음 지속 전송이 개선되는지 살펴보세요.
혼잡 제어로 해결할 수 있는 문제와 해결할 수 없는 문제
지연 시간이 길면 응답을 받는 데 더 오래 걸립니다. 패킷 손실은 무선 간섭, 혼잡, 장비 큐 오버플로 등 여러 원인으로 발생할 수 있습니다. 기존 혼잡 제어 방식 중 다수는 패킷 손실을 전송 속도를 낮춰야 한다는 신호로 봅니다. 무작위 패킷 손실이 뚜렷하지만 사용 가능한 대역폭이 남아 있는 경로에서는 전송 윈도우가 계속 줄어 대역폭을 충분히 활용하지 못할 수 있습니다.
Hysteria2의 성능 특성은 QUIC뿐 아니라 혼잡 제어 방식에도 영향을 받습니다. Brutal은 목표 대역폭과 패킷 손실 보상 방식을 사용해 목표 전송 속도를 유지하려고 합니다. 네트워크 용량을 새로 만들어내는 것은 아닙니다. 목표를 지나치게 높게 설정하면 큐 대기, 패킷 손실, 추가 트래픽이 늘어 같은 네트워크를 사용하는 다른 서비스에 영향을 줄 수 있습니다. 실제로 어떤 방식을 사용하고 대역폭 협상을 적용하는지는 클라이언트 기능과 서버 설정에 따라 다르므로 연결 정보의 이름만으로 판단할 수 없습니다.
| 네트워크 상태 | 기대할 수 있는 효과 | 추가로 확인할 사항 |
|---|---|---|
| 지연 시간이 길고 무작위 패킷 손실이 발생함 | 적절한 혼잡 제어로 지속 전송 속도가 개선될 수 있음 | 패킷 손실이 혼잡 때문에 발생하는지, 사용 가능한 대역폭이 안정적인지 |
| 지연 시간이 짧고 패킷 손실이 적음 | 정상 작동할 수 있지만 눈에 띄는 성능 차이는 없을 수 있음 | 서버 부하, 목적지 사이트의 속도 제한 |
| UDP가 제한됨 | 연결 시간 초과 또는 잦은 연결 끊김이 발생할 수 있음 | 접속 네트워크 정책과 서버 방화벽 |
| 업로드가 장시간 최대치에 도달함 | 큐 대기로 다운로드와 상호작용 속도도 느려질 수 있음 | 업로드 사용량, 장비 큐, 대역폭 목표 |
화면에 업로드 및 다운로드 대역폭 항목이 있다면 필드에 표시된 단위로 입력하세요. Mbps와 MB/s를 혼동하지 마세요. 이론상 80 Mbps는 10 MB/s이며, 실제 앱의 전송 속도는 프로토콜 오버헤드만큼 낮아집니다. 이는 단위 환산일 뿐 속도를 보장하는 수치가 아닙니다. 대역폭 값은 인터넷 요금제에 표시된 최대 속도가 아니라 현재 경로에서 안정적으로 사용할 수 있는 수준을 기준으로 설정하세요.
Shadowrocket에서 Hysteria2 추가하기: 설정 항목 확인
가능하면 이미 이용 중인 구독에 포함된 연결 정보를 그대로 사용해 수동 입력 중 누락을 방지하세요. 직접 추가해야 한다면 기존 서비스 정보를 바탕으로 프로토콜 종류, 서버 주소, 포트, 인증 비밀번호, TLS 설정을 확인하세요. 이름이 비슷하다고 Hysteria와 Hysteria2를 서로 바꿔 쓸 수 있는 것은 아닙니다. 다른 프로토콜의 비밀번호와 포트도 그대로 적용할 수 없습니다.
-
연결 정보 가져오기
Home → 오른쪽 위 ‘+’ → Type → Subscribe로 이동해 본인의 구독 주소를 입력하고 저장하세요. 업데이트가 완료되면 연결 정보가 나타나는지 확인합니다. 직접 추가하려면 Home → ‘+’ → Type에서 Hysteria2를 선택하세요.
-
주소 확인
서버 주소와 Port를 확인하세요. 주소에는 서버에서 제공한 호스트 이름이나 IP만 입력하고 웹 경로는 추가하지 마세요. 예를 들어 서버가
443/UDP에서 수신 대기한다고 명시한 경우에만 Port에443을 입력합니다. 흔히 쓰이는 값이라는 이유만으로 포트를 추측하지 마세요. -
인증 정보 확인
서버에서 제공한 인증 정보를 Password에 입력하세요. 구독 접속 정보와 연결 인증 비밀번호는 용도가 다르므로 서로 바꿔 쓰지 마세요. 복사할 때 끝의 공백, 대소문자, 특수 문자를 확인하세요.
-
TLS 설정 확인
서버 요구 사항에 맞춰 SNI를 입력하고 인증서 검증을 유지하세요. 연결 주소가 IP여도 인증서에 해당하는 도메인을 SNI에 입력해야 할 수 있습니다. 도메인 불일치나 인증서 만료를 감추기 위해 Allow Insecure를 켜지 마세요.
-
선택 항목 확인
서버에서 난독화를 사용한다면 같은 유형과 난독화 비밀번호를 설정해야 합니다. 난독화를 사용하지 않는 경우에는 임의로 입력하지 마세요. 업로드·다운로드 대역폭 및 기타 확장 항목은 실제 화면과 서버 안내를 따르고, 가져온 뒤 설정이 모두 유지되었는지도 확인하세요.
-
연결 테스트
저장한 뒤 Home으로 돌아가 해당 연결 정보를 선택하고 Global Routing을 확인하세요. 테스트할 요청이 어떤 경로를 사용해야 하는지 정한 뒤 연결을 활성화하고 정해 둔 목적지에 접속합니다. 목록에 표시된 지연 시간만으로 실제 다운로드 속도를 판단하지 마세요.
라우팅 확인: 프로토콜 문제와 규칙 문제 구분하기
연결 정보를 선택했다고 모든 요청이 해당 연결을 거치는 것은 아닙니다. Home → Global Routing의 Proxy, Direct, Config, Scene은 서로 다른 라우팅 방식을 선택하는 항목입니다. 문제를 확인할 때는 기존 설정을 기록하고 한 번에 하나만 잠시 바꾼 뒤 테스트가 끝나면 원래대로 되돌리세요. 프로토콜, 규칙, DNS를 동시에 변경하면 무엇이 개선에 영향을 주었는지 알 수 없습니다.
Config
권장현재 활성화된 설정의 규칙에 따라 요청을 처리합니다. Hysteria2를 사용했는지 판단하려면 대상 요청에 실제로 적용된 규칙과 정책을 확인해야 합니다. Config를 선택했다고 특정 도메인이 반드시 프록시를 거치는 것은 아닙니다.
적합한 경우: 기존 규칙을 유지하면서 일상적으로 사용하고, 특정 요청의 경로를 확인할 때.
Proxy
프록시 경로를 기준으로 삼아 일반 라우팅 규칙이 테스트 결과에 미치는 영향을 줄입니다. 현재 선택된 연결 정보도 확인해야 하며, 시스템 수준에서 제외되는 트래픽은 별도로 고려해야 합니다.
적합한 경우: 연결 자체를 짧게 테스트해 문제가 라우팅 규칙과 관련 있는지 확인할 때.
Direct
직접 연결 경로를 사용하므로 Hysteria2의 프록시 전송 속도를 검증하는 데는 적합하지 않습니다. 로컬 네트워크에서 목적지까지 직접 연결되는 상태를 확인할 수 있지만, 같은 서버 경로의 성능을 비교하는 테스트는 아닙니다.
적합한 경우: 기본 네트워크가 작동하는지 확인하거나 직접 연결 문제를 점검할 때.
Scene은 설정된 시나리오 조건에 따라 라우팅 방식을 선택합니다. Proxy와 항상 같은 기능을 하는 스위치로 간주하면 안 됩니다. Settings → On Demand가 활성화되어 있다면 현재 상태도 기록해 조건에 따라 연결이 시작되는 동작이 테스트 결과에 영향을 주지 않도록 하세요. On Demand는 연결 시작 조건을 제어할 뿐 Hysteria2의 전송 속도를 직접 높이지 않습니다.
DOMAIN-SUFFIX: 도메인 접미사를 기준으로 일치시킵니다. 테스트 도메인이 지정한 정책에 포함되는지 확인할 때 유용합니다.IP-CIDR: IP 대역을 기준으로 일치시킵니다. DNS 조회가 관련되는지는 규칙 옵션과 요청 상황을 함께 확인해야 합니다.GEOIP: IP 지리 데이터베이스를 기준으로 일치시키며, 결과는 데이터베이스 내용에 따라 달라집니다.FINAL: 앞선 규칙과 일치하지 않은 요청을 처리합니다. 최종적으로 어떤 정책을 가리키는지 확인해야 합니다.
시간 초과, 저속, 연결 끊김: 증상별 점검 방법
기기, 대상 리소스, 테스트 시간을 동일하게 유지하고 매번 조건 하나만 바꾸세요. Wi-Fi와 셀룰러 네트워크에서 같은 리소스를 각각 세 번 전송하고, 연결 성공 여부, 지속 전송 속도 범위, 연결 끊김 여부, 당시 라우팅 방식을 기록하는 것이 좋습니다. 이는 테스트 절차일 뿐 미리 정해진 성능 결론이 아닙니다. 한 번의 최고 속도를 하루 전체의 성능으로 여기지 마세요.
| 관찰된 증상 | 먼저 확인할 항목 | 다음 단계 |
|---|---|---|
| 계속 연결 시간 초과 | 주소, UDP 포트, 서버 수신 대기 상태, 네트워크 제한 | 연결 정보는 그대로 두고 접속 네트워크를 바꿔 연결이 완료되는지 비교하세요 |
| 인증 실패 메시지 표시 | Password와 서버 인증 요구 사항 | 기존 정보를 다시 확인하고 구독을 갱신한 뒤 연결 정보를 재확인하세요 |
| 인증서 오류 메시지 표시 | SNI, 기기 시간, 인증서 도메인과 유효성 | 해당 설정을 수정하거나 서버 관리자가 인증서를 갱신하도록 요청하세요 |
| 소량 전송은 정상이나 대량 전송 중 멈춤 | 패킷 손실, 경로 MTU, 대역폭 목표, 네트워크 혼잡 | 먼저 부적절하게 높은 대역폭 목표를 낮추고 증상을 기록한 뒤 경로를 추가로 점검하세요 |
| 연결은 정상이지만 특정 사이트가 느림 | 적용된 규칙, DNS, 목적지 사이트, 서버의 외부 연결 경로 | 고정된 다른 목적지로 다시 테스트해 특정 사이트 문제인지 전체 연결 문제인지 구분하세요 |
| Wi-Fi에서는 실패하지만 셀룰러에서는 정상 | 로컬 라우터, 접속 네트워크의 UDP 정책 | 네트워크 정책을 확인하고 모든 인증 정보를 곧바로 다시 입력하지 마세요 |
경로 MTU 문제는 점검을 위한 단서일 뿐, ‘대용량 파일 전송이 느리다’는 이유만으로 결론을 내릴 수 없습니다. 부하가 낮을 때는 연결되지만 지속 전송 후 지연이 크게 늘어난다면 업로드 대역폭이 가득 찼는지, 대역폭 목표를 지나치게 높게 설정했는지도 확인하세요. 값을 변경할 때는 원래 값을 기록하고 한 번에 하나만 바꾼 뒤 같은 리소스로 다시 테스트하세요.
정리: 프로토콜 이름이 아니라 안정성을 기준으로 선택하세요
UDP에 연결할 수 있고 설정이 올바른 상태에서 여러 차례 테스트한 결과 지속 전송 속도가 더 안정적이고 연결 끊김이 적다면 기존 Hysteria2 연결 정보를 계속 사용할 수 있습니다. 현재 접속 네트워크에서 UDP가 계속 제한된다면 먼저 네트워크 환경을 해결하거나 본인이 이미 보유한 다른 사용 가능한 연결 정보를 이용하세요.
문제 해결 기록에는 오류 유형, 테스트 조건, 민감 정보를 가린 설정 설명만 남기세요. 구독 주소, Password, 난독화 비밀번호는 연결 인증 정보이므로 공개 스크린샷이나 로그에 포함하면 안 됩니다. 기본 설정을 다시 확인해야 한다면 먼저 사이트의 시작하기 안내를 읽고 Home으로 돌아가 연결 정보와 Global Routing을 확인하세요.