Hysteria2는 QUIC 기반 프록시 프로토콜입니다. UDP를 사용할 수 있고 왕복 지연 시간이 길거나 간헐적인 패킷 손실이 있는 연결에서 시험해 볼 만하지만, 다른 전송 방식보다 항상 빠른 것은 아닙니다. 이 글에서는 자체 서버와 설정을 보유한 iPhone·iPad 사용자를 대상으로 전송 원리, 매개변수 확인, 규칙 분기 점검, 비교 테스트 방법을 설명합니다. 다른 플랫폼에서도 원리를 참고할 수 있지만, 구체적인 화면은 사용하는 클라이언트에 따라 다를 수 있습니다.
1. Hysteria2, QUIC, UDP의 관계
Shadowrocket의 Hysteria2는 연결 프로토콜 옵션이지, 속도 향상 스위치나 회선 요금제가 아닙니다. 연결하려면 서버에서 해당 프로토콜을 지원해야 하며, 올바른 주소, 포트, 인증 정보와 인증서 설정이 필요합니다. 기존의 다른 프로토콜 연결은 Type만 바꾼다고 Hysteria2로 전환되지 않습니다.
전송 계층을 보면 Hysteria2는 QUIC을 사용하고, QUIC은 UDP를 통해 데이터를 전송합니다. UDP 자체는 순서가 보장된 전달이나 손실된 데이터의 재전송을 처리하지 않습니다. QUIC은 이를 바탕으로 암호화, 확인 응답, 손실 감지, 신뢰성 있는 스트림, 혼잡 제어를 구현합니다. 따라서 ‘기반 전송이 UDP’라는 말은 웹 콘텐츠가 손실되어도 재전송되지 않는다는 뜻이 아니며, 앱의 모든 요청이 신뢰성 없는 전송으로 바뀐다는 뜻도 아닙니다.
Hysteria2는 TCP와 UDP 프록시 요청을 전달할 수 있지만, 두 방식의 애플리케이션 동작은 다릅니다. 웹 트래픽 같은 신뢰성 있는 바이트 스트림은 QUIC stream으로 전송되고, UDP 포워딩은 보통 QUIC DATAGRAM을 사용하므로 신뢰성 있는 스트림과 동일한 재전송을 보장하지 않습니다. 따라서 신뢰성은 연결 이름에 UDP가 포함됐는지가 아니라 전달되는 트래픽의 특성에 따라 판단해야 합니다.
2. 더 빨라질 수 있는 이유: 독립 스트림과 혼잡 제어
속도는 핸드셰이크 시간, 첫 바이트까지 걸리는 시간, 지속 전송량을 나누어 살펴봐야 합니다. QUIC은 전송과 암호화 핸드셰이크를 결합해 일부 연결 왕복 시간을 줄일 수 있지만, 도메인 조회, 인증서 검증, 서버 처리, 대상 웹사이트의 응답에는 여전히 시간이 걸립니다. 연결이 빨리 설정된다고 해서 대용량 파일 다운로드 속도까지 반드시 높아지는 것은 아닙니다.
- 스트림 간 상호 차단 감소: 하나의 TCP 연결을 공유하는 다중화 환경에서는 특정 지점의 패킷 손실이 이후 바이트 전달을 막을 수 있습니다. QUIC에서는 각 stream이 독립적으로 진행되므로 한 스트림이 재전송을 기다리는 동안 다른 스트림은 동일한 순서 전달 조건 때문에 함께 기다릴 필요가 없습니다.
- 같은 스트림 안에서는 여전히 대기: 다운로드 작업에서 누락된 데이터는 여전히 보충해야 합니다. QUIC이 신뢰성 있는 전송의 순서 요구를 없애거나 손실된 데이터를 저절로 복구하는 것은 아닙니다.
- 전송 정책이 처리량에 영향: Hysteria2의 대역폭 설정은 적용되는 혼잡 제어 동작에 영향을 줄 수 있습니다. Brutal은 목표 대역폭에 맞춰 전송하고 패킷 손실을 보정하므로, 간헐적인 패킷 손실이 있는 연결에서 높은 처리량을 유지할 수 있지만 트래픽 사용량과 큐 대기 부담이 늘어날 수도 있습니다.
- 회선 용량은 여전히 한계: 가정용 인터넷의 업로드 속도, 무선 신호, 서버의 외부 회선, 대상 사이트의 속도 제한 등이 병목이 될 수 있습니다. 전송 프로토콜로 물리적 한계나 정책상의 제한을 넘어설 수는 없습니다.
대역폭 값은 단순히 ‘높을수록 빠르다’고 볼 수 없습니다. 예를 들어 실제로 안정적인 다운로드 속도가 약 50 Mbps인데 전송 목표를 500 Mbps로 설정하면 큐 대기, 추가 패킷 손실, 지연 시간 증가가 발생할 수 있습니다. 여기의 숫자는 매개변수 간 관계를 설명하기 위한 예시이며, 이 사이트의 테스트 결과가 아닙니다. 구체적인 항목, 단위, 자동 협상 동작은 현재 사용하는 클라이언트와 서버의 안내를 확인하세요.
결론: 처리량과 지연 시간을 함께 확인
대역폭 설정을 높여도 다운로드 속도는 거의 달라지지 않는데 웹페이지 대기 시간, 음성 지연 또는 다른 기기의 네트워크 응답이 눈에 띄게 나빠진다면 설정을 되돌리고 회선에서 안정적으로 사용할 수 있는 대역폭을 다시 측정하세요.
3. 적합한 네트워크와 먼저 점검할 증상
지연 시간이 길면 피드백 주기가 늘어나고, 간헐적인 패킷 손실은 일부 혼잡 제어 정책의 전송 속도를 낮출 수 있습니다. 따라서 장거리 연결에서 패킷 손실이 어느 정도 발생하더라도 UDP가 원활한 네트워크라면 Hysteria2를 시험해 볼 만합니다. 다만 손실 원인이 중요합니다. 무선 간섭으로 인한 손실과 외부 회선 혼잡으로 인한 손실은 같은 방식으로 판단하면 안 됩니다.
| 네트워크 조건 | 나타날 수 있는 증상 | 먼저 할 일 |
|---|---|---|
| 장거리 연결, 간헐적 패킷 손실 | 지속 전송은 더 안정적일 수 있지만, 짧은 요청은 여전히 왕복 지연 시간의 영향을 받습니다 | 같은 네트워크와 시간대에 첫 바이트 시간 및 지속 처리량 비교 |
| 낮은 지연 시간, 패킷 손실 적음 | 차이가 작을 수 있으며, 서버 외부 회선이 병목일 수도 있습니다 | 안정적인 설정을 유지하고 프로토콜 이름만으로 속도를 추측하지 마세요 |
| UDP 차단 | 핸드셰이크 시간 초과. TCP 웹 연결은 되지만 Hysteria2에 연결되지 않음 | 서버에서 UDP가 허용되는지 확인한 뒤 다른 네트워크에서도 다시 테스트 |
| UDP 속도 제한 | 연결은 되지만 지속 전송이 매우 느리거나 시간이 지나면서 속도가 떨어짐 | 통신사 네트워크 정책, 서버 제한, 무선 혼잡을 구분해 점검 |
| 경로 MTU 이상 | 작은 요청은 성공하지만 대용량 전송이 멈추거나 시간 초과가 자주 발생 | 네트워크 관리자에게 UDP 대용량 패킷과 경로 MTU를 확인하고, 여러 매개변수를 무작정 바꾸지 마세요 |
QUIC 초기 데이터그램은 최소 1200바이트여야 합니다. 경로에서 해당 크기의 UDP 데이터그램을 전달할 수 없으면 핸드셰이크에 문제가 생길 수 있습니다. ‘Ping이 된다’는 사실만으로 이 문제를 배제할 수는 없습니다. Ping에 사용되는 프로토콜, 패킷 크기, 경로 정책은 실제 QUIC 연결과 같지 않습니다.
UDP 443과 TCP 443은 서로 다른 허용 대상입니다. 서버 웹페이지가 HTTPS로 열린다는 사실은 관련 TCP 서비스에 접근할 수 있다는 점만 보여 줄 뿐, UDP 443이 열려 있음을 증명하지는 않습니다. 서버가 실제로 UDP 8443을 사용한다면 클라이언트에도 8443을 입력해야 합니다. 포트만 443으로 바꾼다고 연결이 저절로 되지는 않습니다.
4. Shadowrocket에서 기존 설정 확인 및 테스트
아래는 iPhone·iPad의 Home 화면을 기준으로 설명합니다. 먼저 현재 작동하는 설정을 저장한 다음, 이미 보유한 Hysteria2 매개변수를 추가하세요. 기존 구독으로 설정을 관리하는 경우에는 업데이트 후 임시로 직접 수정한 내용이 계속 적용될 것이라고 오해하지 않도록, 먼저 구독을 가져온 결과를 확인하세요. 이 글에서는 연결 서비스나 구독을 제공·판매·추천하지 않습니다.
-
매개변수 확인
서버 주소, UDP 포트, 인증 비밀번호와 서버에서 요구하는 SNI 및 선택적 혼합 매개변수를 준비하세요. 포트는 실제 배포 설정을 따르세요. 인증서 도메인과 연결 주소는 다를 수 있지만 인증서 검증 조건을 충족해야 합니다.
-
연결 추가
Home → 오른쪽 위 ‘+’ → Type으로 이동해 Hysteria2를 선택하고, 보유한 매개변수를 입력한 뒤 저장하세요. 기존 구독을 사용하는 경우 Home → ‘+’ → Type → Subscribe에서 본인의 구독을 가져온 다음 생성된 항목의 프로토콜과 포트를 확인할 수 있습니다.
-
인증서 확인
서버에서 제공한 값에 따라 SNI와 인증서 도메인을 확인하고 기기 시간이 정확한지도 점검하세요. 인증서 검증 오류가 발생하면 먼저 도메인, 유효 기간, 인증서 체인을 확인하세요. 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요.
-
규칙 분기 분리
Home에서 테스트할 연결을 선택하고, Global Routing을 일시적으로 Proxy로 설정한 뒤 상단 연결 스위치를 켜세요. 테스트가 허용된 고정 대상으로 요청을 보내세요. 테스트가 끝나면 Global Routing을 원래 설정으로 복원하세요.
-
조건 고정
현재 Wi-Fi 또는 셀룰러 네트워크, 테스트 시간대, 증상을 기록하세요. Settings → On Demand가 켜져 있다면 자동 연결이 수동 연결 해제나 전환을 방해하지 않는지 먼저 확인하고, 테스트 후 원래 설정으로 되돌리세요.
Home의 Connectivity Test로 연결 가능 여부와 지연 시간을 대략 확인할 수 있지만, 지속 다운로드, 웹페이지 첫 바이트 시간, 실시간 서비스 테스트를 대신할 수는 없습니다. 낮은 지연 시간 값은 해당 테스트 경로의 응답 상태만 보여 줍니다. 모든 웹사이트가 같은 연결을 사용한다거나 처리량이 더 높다는 근거로 볼 수 없습니다.
5. Global Routing과 규칙이 테스트에 미치는 영향
Hysteria2는 선택한 프록시 연결의 전송 방식을 결정하고, Global Routing은 요청이 사용할 경로를 결정합니다. 테스트 요청이 규칙에 따라 DIRECT로 분기되면 Home에서 Hysteria2 항목을 선택했더라도 해당 요청의 속도로 Hysteria2를 평가할 수 없습니다. 먼저 요청이 어떤 경로를 사용했는지 확인한 다음 프로토콜 동작을 비교하세요.
Config
권장현재 설정의 규칙에 따라 요청 경로를 결정합니다. 설정 내용을 확인한 뒤 일상 연결에 사용하고, 규칙 매칭 결과를 확인해 테스트 요청이 PROXY를 사용하는지 검증하세요.
적합한 용도: 일상적인 규칙 분기 및 명확한 규칙 매칭 여부 확인
Proxy
클라이언트가 처리하는 요청을 프록시 경로로 보내 규칙 분기가 테스트에 미치는 영향을 일시적으로 줄입니다. 연결에 실패하면 프로토콜 매개변수와 네트워크 접근 가능성을 계속 점검해야 합니다.
적합한 용도: 잠시 규칙 영향을 분리하고 선택한 연결 확인
Direct
직접 연결 경로를 사용하며 선택한 프록시 연결을 거치지 않습니다. 대상에 직접 연결할 수 있다면 기준값을 확인하는 데 유용하지만, 직접 연결 결과가 프록시 서버에서 대상까지의 경로 품질을 나타내지는 않습니다.
적합한 용도: 로컬 네트워크에서 대상까지 직접 연결하는 기준 상태 확인
예를 들어 Config의 현재 설정에서 아래 Rule 조각을 사용하면 example.com과 그 하위 도메인은 PROXY를 선택하고, 지정된 사설 주소 범위는 DIRECT를 선택하며, 나머지 요청은 FINAL로 처리됩니다. 이는 규칙 문법의 예시일 뿐 사용 가능한 서버 정보를 포함하지 않습니다. PROXY의 실제 출구는 현재 선택한 연결과 함께 확인해야 합니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT규칙은 위에서부터 순서대로 적용하며 FINAL은 마지막에 두어야 합니다. 예시에서는 접미사 매칭을 설명하기 위해 example.com을 사용했으며 속도 테스트 대상으로 쓰면 안 됩니다. 본인 업무용 도메인을 확인하려면 기존 규칙을 이해한 뒤 해당 조건을 수정하고, 올바른 설정을 저장해 활성화하세요. 설정이 활성화되지 않았거나 Global Routing이 Direct로 설정된 상태에서는 규칙을 수정해도 기대한 결과가 나오지 않습니다.
6. 반복 가능한 비교 테스트 방법
신뢰할 수 있는 비교를 위해서는 변수 하나만 바꾸는 것이 좋습니다. 서버마다 지역, 외부 회선, 부하, 네트워크 경로가 완전히 다를 수 있으므로 서로 다른 서버의 다운로드 결과를 프로토콜 차이로만 설명할 수는 없습니다. 가능하면 같은 서버, 비슷한 시간대, 같은 대상, 같은 기기에서 비교하세요. 이런 조건을 통제할 수 없다면 결론은 ‘현재 두 연결의 성능 비교’로 한정해야 합니다.
- 테스트 파일 고정: 접근 권한이 있는 동일한 다운로드 자료를 사용하고 웹페이지 첫 바이트 시간, 지속 처리량, 실패 횟수를 각각 확인하세요. 출처를 알 수 없는 속도 테스트 링크는 사용하지 마세요.
- 반복 측정 및 기록: 각 조건에서 약 30초 동안 3회 전송하고, 최고값만 남기지 말고 매회 결과를 기록하세요. 이는 테스트 절차에 대한 권장 사항이지 성능 보장이 아닙니다.
- 동시 사용 영향 확인: 다운로드 중 가벼운 웹페이지나 실시간 서비스를 함께 확인해 처리량 증가와 함께 큐 대기 및 상호작용 지연이 눈에 띄게 늘어나는지 살펴보세요.
- 실패 정보 보관: 핸드셰이크 시간 초과, 인증 실패, 인증서 오류, 연결 후 중단을 구분하세요. 오류 유형을 기록하되, 내용을 공유하기 전에 비밀번호, 구독 주소, 인증 정보를 삭제하세요.
- 다른 네트워크에서도 확인: Wi-Fi에서는 실패하고 셀룰러 네트워크에서는 성공한다면 먼저 Wi-Fi 네트워크의 UDP 정책을 확인하세요. 두 네트워크 모두 실패하면 서버 리스닝 상태, 방화벽, 인증 매개변수를 추가로 점검하세요.
결론: 먼저 연결을 확인한 뒤 속도를 비교
핸드셰이크 시간 초과는 먼저 UDP 연결 가능성을 확인하고, 인증서 오류는 SNI와 인증서를 점검하세요. 연결이 성공한 뒤 지속 처리량과 지연 시간을 확인하면 됩니다. 반복 테스트에서 실제 사용 환경이 안정적으로 개선된 경우에만 현재 Hysteria2 설정을 유지할 이유가 있습니다.
Hysteria2를 사용하려면 서버 설정이 올바르고 UDP 경로를 사용할 수 있으며 전송 정책이 회선 용량에 맞아야 합니다. 패킷 손실과 지연 시간의 영향을 받는 일부 전송 환경을 개선할 수는 있지만, 잘못된 비밀번호, 만료된 인증서, 차단된 네트워크 경로를 해결해 주지는 않습니다. 설정 문법은 규칙 참고 자료에서 확인할 수 있으며, 최초 연결과 VPN 설정 권한은 빠른 시작 가이드에 따라 항목별로 점검하세요.