이 글은 이미 서비스 제공업체와 설정 정보를 보유하고 있으며 Shadowrocket에서 Hysteria2를 사용하려는 분을 위한 안내입니다. QUIC, UDP, 실제 앱 트래픽의 차이를 구분하고 인증, 인증서, obfs 설정을 확인한 뒤 동일한 조건에서 연결을 테스트합니다. 한 번의 지연 시간 측정만으로 프로토콜을 바꾸기보다 문제가 네트워크 연결, TLS, 인증, 규칙에 따른 라우팅 중 어디에서 발생하는지 파악할 수 있습니다.
Hysteria2와 QUIC·UDP의 관계
Hysteria2는 QUIC 기반 프록시 프로토콜입니다. QUIC은 UDP를 통해 데이터를 전송하며 암호화, 신뢰성 있는 전송, 혼잡 제어, 다중화 등의 기능을 제공합니다. 여기서 ‘UDP 기반’이란 클라이언트와 서버 사이의 외부 전송 방식을 뜻합니다. 웹 요청 자체가 신뢰할 수 없는 데이터로 바뀌거나 UDP를 사용하는 서비스만 이용할 수 있다는 의미는 아닙니다.
Shadowrocket에서 Hysteria2를 선택하면 해당 연결로 라우팅된 TCP 트래픽은 QUIC stream을 통해 전달되고, UDP 트래픽은 이에 맞는 데이터그램 전달 방식으로 처리됩니다. 웹은 기존 애플리케이션 프로토콜을 그대로 사용하므로 브라우저를 HTTP/3으로 바꿀 필요가 없습니다. 서버가 Hysteria2를 지원해야 합니다. 주소와 비밀번호가 같다는 이유만으로 다른 프로토콜의 설정을 Hysteria2로 바꿔 쓸 수는 없습니다.
포트 번호가 같아도 전송 방식까지 같은 것은 아닙니다. 예를 들어 서버가 443/UDP를 수신 대기하는데 네트워크에서 443/TCP만 허용하면 연결을 설정할 수 없습니다. 443은 Hysteria2의 필수 포트가 아닙니다. 8443이나 다른 포트를 사용하는 경우 클라이언트 설정, 서버 수신 포트, 방화벽 허용 항목이 모두 일치해야 합니다.
불안정한 네트워크에서의 동작과 혼잡 제어의 한계
QUIC의 다중화는 신뢰성 있는 전송의 순서 보장으로 인해 stream 사이에 발생하는 헤드 오브 라인 블로킹을 줄입니다. 한 stream의 데이터를 재전송하는 동안에도 다른 stream에서 이미 받은 데이터는 동일한 TCP 바이트 스트림이 채워질 때까지 기다릴 필요가 없습니다. 다만 모든 stream이 경로의 대역폭과 혼잡 제어를 공유하므로 지속적인 패킷 손실, 약한 무선 신호, 업로드 혼잡은 전체 트래픽에 영향을 줄 수 있습니다.
Hysteria2는 대역폭 추정 기반의 Brutal과 협상 가능한 BBR 등의 혼잡 제어 방식을 사용합니다. 실제 적용 방식은 클라이언트 구현, 설정, 서버와의 협상에 따라 달라집니다. Brutal은 적절한 대역폭 설정과 패킷 손실 피드백을 바탕으로 전송량을 제어합니다. 추가 대역폭을 만들어 내거나 네트워크의 UDP 제한을 우회하는 기능은 아닙니다.
- 무작위 패킷 손실 또는 지연 변동: 기존 Hysteria2 설정으로 비교 테스트를 진행하고 웹 페이지 로딩 시간과 장시간 연결의 안정성을 확인하세요. 무조건 더 빠르다고 미리 단정하지 마세요.
- UDP 패킷이 차단되거나 엄격하게 제한됨: 핸드셰이크 시간 초과가 계속되거나 전송을 시작한 뒤 처리량이 매우 낮은 경우가 흔합니다. 이때 대역폭 설정을 높여도 근본 원인은 해결되지 않는 경우가 많습니다.
- 업로드 대역폭이 이미 포화됨: 업로드 트래픽이 확인 및 제어 패킷을 보낼 여유를 잠식해 다운로드 속도까지 느려질 수 있습니다. 다른 업로드를 일시 중지한 뒤 테스트하세요.
- 서버의 외부 연결이 제한됨: 로컬 네트워크 상태가 양호해도 대상 웹사이트의 응답, 원격 서버 부하, 외부 연결 대역폭이 병목이 될 수 있습니다.
요약: 먼저 UDP 연결 가능 여부 확인
핸드셰이크 시간 초과가 반복되면 기존 설정의 주소와 UDP 포트, 현재 네트워크의 제한부터 확인하세요. 연결이 성립하고 데이터가 지속적으로 전송되는 것을 확인한 뒤에야 대역폭 설정을 조정하는 것이 진단에 도움이 됩니다.
password, sni, obfs의 역할
각 설정은 서로 다른 계층에 적용되므로 서로 대체할 수 없습니다. 추가하기 전에 사용 중인 설정의 제공업체에 전체 매개변수를 확인하세요. 항목이 빠져 있다고 다른 비밀번호를 대신 입력하면 안 됩니다. 아래 영문은 설정 필드 이름이며 Shadowrocket에서는 이에 해당하는 레이블로 표시될 수 있습니다. 실제로 표시되는 필드는 선택한 Type과 앱 화면에 따라 달라집니다.
| 항목 | 역할 | 확인 사항 |
|---|---|---|
server | 연결할 서버의 도메인 또는 IP 주소입니다. | 전체 공유 링크나 경로가 포함된 웹 주소를 주소 입력란에 붙여 넣지 마세요. |
port | 서버가 UDP 연결을 수신하는 포트입니다. | 예: 443. 기존 설정과 일치해야 합니다. 웹사이트가 HTTPS를 사용한다는 이유만으로 443으로 바꾸지 마세요. |
password | Hysteria2 서버 인증 정보입니다. | 대소문자와 기호를 그대로 유지하고 복사할 때 앞뒤에 공백이 포함되지 않았는지 확인하세요. |
sni | TLS 핸드셰이크에 사용하는 서버 이름으로, 인증서 이름과 대조할 때 사용됩니다. | 일반적으로 도메인을 입력합니다. 프로토콜 접두사, 포트, 경로는 포함하지 말고 기존 설정을 따르세요. |
obfs | 선택 사항인 전송 난독화 방식입니다. 예: Salamander. | 서버에서 사용 중이라면 양쪽 설정이 일치해야 합니다. 서버에서 사용하지 않는다면 클라이언트에서 임의로 활성화하지 마세요. |
obfs-password | 난독화에 사용하는 키입니다. | 인증용 password와 별개의 설정입니다. 난독화 키가 잘못되면 핸드셰이크 단계에서 연결이 실패할 수 있습니다. |
up / down | 일부 설정 형식에서 지정하는 업로드·다운로드 대역폭 정보입니다. | 단위와 업로드·다운로드 방향을 먼저 확인하세요. 속도 측정 결과의 MB/s를 Mbps로 그대로 간주하면 안 됩니다. |
연결 주소와 sni는 서로 다를 수 있습니다. 예를 들어 기존 설정에서 IP 주소로 연결하면서 TLS 이름 확인에는 인증서에 포함된 도메인을 사용할 수 있습니다. 그렇다고 유명 웹사이트의 도메인을 임의로 입력해도 된다는 뜻은 아닙니다. 인증서 체인, 인증서 이름, 서버 설정이 서로 일치해야 합니다. 인증서 오류가 발생하면 인증서 검증을 끄기보다 sni, 기기 시간, 서버 인증서 상태를 확인하세요.
Shadowrocket에서 연결 추가 및 확인
아래 안내는 iPhone 또는 iPad의 Home 화면에서 시작하며, 사용 가능한 Hysteria2 설정을 이미 보유하고 있다는 전제입니다. Subscribe 항목이 있다면 먼저 업데이트하고 가져온 내용을 확인하세요. 수동 추가는 연결 하나를 확인할 때 적합하며, 구독으로 관리하는 항목을 수동 항목으로 반복해서 덮어쓰지 않도록 주의하세요.
-
설정 확인
서버 주소, UDP 포트, password, sni, 서버에서 요구하는 obfs 정보를 준비하세요. 설정이 이름만 비슷한 다른 프로토콜이 아니라 Hysteria2용인지 확인합니다.
-
Type 선택
Home → 오른쪽 위 “+” → Type으로 이동한 다음 Hysteria2를 선택합니다. 기존 설정을 공유 정보로 가져온 경우에도 메모 이름만 확인하지 말고 항목을 열어 Type을 확인하세요.
-
설정 입력
기존 설정을 기준으로 주소, 포트, 인증 정보를 입력합니다. 해당 TLS 및 난독화 옵션에서 sni, 인증서 검증, obfs를 확인하세요. 처음 테스트할 때는 기존 대역폭 값을 유지하고 여러 설정을 동시에 바꾸지 마세요.
-
저장 후 선택
저장한 뒤 Home으로 돌아가 방금 추가한 항목을 선택합니다. Config에서 정책 그룹을 사용한다면 실제 정책이 해당 항목을 선택하고 있는지도 확인하세요. 다른 연결을 테스트하는 상황을 방지할 수 있습니다.
-
권한 허용 및 테스트
Home의 연결 스위치를 켜고 시스템 안내에 따라 VPN 구성 권한을 승인합니다. 먼저 정상 작동이 확인된 HTTPS 페이지에 접속한 뒤 실제 트래픽에 적용된 정책과 연결 기록을 확인하세요.
Settings → On Demand에서는 조건에 따라 연결을 시작하는 동작을 관리하며 Hysteria2 설정 문제를 해결하지는 않습니다. 문제를 확인하는 동안 이 기능의 활성화 여부를 기록해 자동 연결로 인해 ‘껐는데 다시 연결됐다’고 오해하지 않도록 하세요. Home에 연결됨으로 표시되어도 로컬 VPN 세션이 설정되었다는 뜻일 뿐, 서버 인증과 대상 웹사이트 접속, 모든 규칙 경로가 정상이라는 의미는 아닙니다.
Global Routing으로 프로토콜 문제와 라우팅 문제 구분
연결을 켰는데 특정 웹사이트에 접속할 수 없다면 먼저 연결 자체가 실패한 것인지, 요청이 해당 연결을 거치지 않은 것인지 구분하세요. Global Routing의 Config, Proxy, Direct는 라우팅 방식이지 Hysteria2 설정 세 가지가 아닙니다. Scene은 설정된 시나리오에 따라 작동하므로 문제를 확인하기 전에 현재 Scene에서 실제로 무엇이 선택되어 있는지 살펴보세요. Scene 전환을 프로토콜의 불안정으로 오해하지 않도록 주의해야 합니다.
Config
권장확인된 Config를 일상적으로 사용하고 규칙에 따라 DIRECT 또는 프록시 정책을 선택하세요. 적용된 DOMAIN-SUFFIX, IP-CIDR, GEOIP, FINAL 규칙을 확인해 최종 정책이 예상한 Hysteria2 연결을 가리키는지 살펴봅니다.
적합한 경우: 분명한 라우팅 요구가 있고 규칙 및 정책 그룹을 확인한 뒤 일상적으로 사용할 때
Proxy
클라이언트가 처리하는 트래픽을 일시적으로 선택한 프록시 경로로 보내 Config 라우팅으로 인한 변수를 줄입니다. 이 방식도 시스템이 처리하는 트래픽 범위와 프로토콜 지원의 제약을 받으며, 기기의 모든 트래픽이 반드시 같은 경로를 지난다는 뜻은 아닙니다.
적합한 경우: 규칙 적용 문제를 분리해 연결이 작동하는지 잠깐 확인할 때
Direct
직접 연결 경로를 기준으로 비교합니다. 테스트 요청이 프록시 연결을 거치지 않으므로 이 방식으로 Hysteria2가 정상 작동한다고 확인할 수는 없습니다.
적합한 경우: 로컬 네트워크와 대상 웹사이트의 직접 연결 상태를 확인할 때
요약: Proxy 연결을 확인한 뒤 규칙 점검
같은 대상이 Proxy에서는 접속되지만 Config에서는 실패한다면 연결 설정은 그대로 두고 적용 규칙, 정책 그룹, DNS 결과를 먼저 확인하세요. sni, obfs, 포트를 한꺼번에 바꾸지 마세요.
실패 단계별로 확인하고 한 번의 지연 시간으로 결론 내리지 않기
지연 시간 테스트 결과는 테스트 방식과 대상에 따라 달라지며 모든 트래픽의 상태를 나타내지 않습니다. 측정값이 낮은 연결도 대량 트래픽에서는 UDP 제한을 받을 수 있습니다. 테스트가 시간 초과된 항목도 실제 웹 요청과 연결 기록을 함께 살펴봐야 합니다. 아래 표는 관찰할 수 있는 증상을 정리한 것으로 특정 경로의 실측 성능을 보장하지 않습니다.
| 증상 | 먼저 확인할 항목 | 다음 단계 |
|---|---|---|
| 핸드셰이크 시간 초과가 계속됨 | 도메인 확인, UDP 포트, 현재 네트워크 제한, obfs 설정 일치 여부 | 설정을 바꾸지 말고 사용이 허용된 다른 네트워크에서 같은 요청을 반복해 접속 네트워크의 영향인지 확인하세요. |
| 인증서 관련 오류 발생 | sni, 인증서 유효 기간, 기기 시간, 인증서 신뢰 체인 | 설정 제공업체에 인증서가 적용되는 도메인을 확인하고 인증서 검증은 유지하세요. |
| 인증 실패 발생 | password가 온전히 입력되었는지, 인증 정보가 아직 유효한지 확인하세요. | 원래 인증 정보를 다시 복사하세요. obfs-password로 대체하면 안 됩니다. |
| 간단한 페이지는 열리지만 대용량 전송이 멈춤 | UDP 제한, 경로 MTU, 패킷 손실, 서버 부하, 대역폭 설정 | 먼저 원래 대역폭 설정으로 되돌리고 동시 전송을 중지한 뒤 같은 대상을 다시 테스트하세요. |
| 일부 웹사이트만 접속 실패 | 적용 규칙, 정책 그룹 선택, DNS 결과, 대상 사이트 상태 | 일시적으로 Proxy에서 비교해 라우팅 문제인지 연결 문제인지 확인하세요. |
QUIC 경로는 최소 1200바이트의 UDP 페이로드를 지원해야 합니다. 터널을 여러 겹으로 거치거나 경로에 이상이 있으면 패킷 크기와 관련된 문제가 생길 수 있습니다. 그러나 ‘페이지가 열리지 않는다’는 사실만으로 MTU 문제라고 진단할 수는 없습니다. 경로에 문제가 있다는 명확한 근거가 없다면 시스템 네트워크 설정을 임의로 바꾸거나 Hysteria2를 WireGuard의 MTU 설정처럼 다루지 마세요.
재검토할 수 있도록 테스트 기록 남기기
- 네트워크 종류, 선택한 항목, Global Routing 방식, 테스트 대상을 기록해 서로 다른 조건의 결과가 뒤섞이지 않게 하세요.
- 같은 네트워크에서 동일한 페이지 요청을 세 번 반복하고 핸드셰이크 성공 여부, 페이지 로딩 완료 여부, 연결 중단 여부를 각각 기록하세요. 이는 결과를 기록하는 방법이지 성능 지표가 아닙니다.
- 각 테스트에서는 설정 하나만 변경하세요. 대역폭을 조정한 뒤 상태가 나빠지면 원래 값으로 되돌려 확인해야 여러 변경이 겹쳐 원인을 찾기 어려워지는 일을 막을 수 있습니다.
- Wi-Fi와 셀룰러 네트워크를 비교할 때는 설정과 대상을 동일하게 유지하세요. 결과가 다르면 네트워크 경로의 영향일 수 있지만 추가 확인 없이 특정 기기의 고장이라고 단정할 수는 없습니다.
- 문제 해결 기록을 공유하기 전에 password, obfs-password, 전체 공유 정보와 구독 인증 정보를 삭제하세요. 필요한 오류 유형과 민감 정보를 가린 설정 관계만 남기세요.
Hysteria2를 사용하려면 서버가 명시적으로 지원하고 UDP 경로를 사용할 수 있어야 하며 인증 및 TLS 설정이 정확해야 합니다. 불안정한 네트워크에 더 적합한지는 반복 가능한 접속 결과를 바탕으로 판단하세요. 현재 경로에서 UDP가 제한된다면 대역폭 값을 계속 높이는 것은 효과적인 최적화 방법이 아닙니다. 먼저 네트워크 연결 문제를 확인하고 해당 환경에 맞는 기존 설정을 사용하세요.