Hysteria2는 QUIC 기반 프록시 프로토콜이지 속도 향상 스위치가 아닙니다. 기존 서비스 제공업체, 서버 또는 구독을 보유한 iPhone/iPad 사용자를 대상으로 전송 방식과 속도 특성을 구분하고, Shadowrocket의 연결 항목을 확인한 뒤 UDP, TLS, 라우팅 순서로 연결 문제를 점검합니다.
Hysteria2, QUIC, UDP의 관계
Shadowrocket의 Hysteria2는 서버 연결 유형입니다. QUIC은 기반 전송 프로토콜이며 UDP는 QUIC 패킷을 전달합니다. 여기서 ‘UDP 사용’은 클라이언트와 서버 사이의 외부 연결을 뜻합니다. 브라우저의 모든 요청이 신뢰할 수 없는 전송으로 바뀌거나, 앱이 UDP 서비스에만 접속할 수 있다는 의미는 아닙니다.
QUIC은 UDP 위에서 연결 관리, 신뢰성 있는 스트림, 패킷 손실 복구, 혼잡 제어를 구현하며 TLS 1.3으로 핸드셰이크와 암호화를 처리합니다. Hysteria2는 이 전송 계층 위에서 인증과 프록시 전달 기능을 구현합니다. 서버가 Hysteria2를 지원해야 하며, 기존의 다른 프로토콜 서버에서 Type만 바꿔 연결할 수는 없습니다.
포트 번호만으로 프로토콜을 알 수는 없습니다. 443/TCP가 동작한다고 해서 같은 주소의 443/UDP도 동작한다는 뜻은 아닙니다. 서버의 리스닝 설정, 방화벽, 현재 접속 네트워크에 따라 두 전송 방식이 다르게 처리될 수 있습니다. 여기서 example.com은 클릭할 수 없는 설명용 도메인으로, 실제 사용 가능한 서비스와 무관합니다.
속도가 더 빨라질 수 있는 이유: 스트림 격리와 혼잡 제어
먼저 처리량과 지연 시간을 구분해야 합니다. 처리량은 단위 시간에 전송되는 데이터 양이고, 지연 시간은 한 번 상호작용할 때까지 걸리는 시간입니다. 파일 전송 속도가 빠르다고 모든 웹 페이지가 더 빨리 표시되는 것은 아닙니다. DNS 조회, 대상 사이트의 응답, 서버 부하, 무선 신호도 페이지 로딩 시간에 영향을 줍니다.
QUIC의 다중 스트림 방식은 전송 계층의 패킷 손실 때문에 서로 다른 스트림이 함께 대기하는 헤드 오브 라인 블로킹을 줄입니다. 한 스트림에서 누락된 데이터를 복구하는 동안에도 다른 스트림에서 이미 받은 데이터는 전달할 수 있습니다. 다만 같은 신뢰성 스트림 안에서는 순서를 유지해야 하고, 패킷 손실은 재전송 대역폭을 계속 사용합니다. QUIC을 ‘패킷이 손실돼도 기다릴 필요가 없는 방식’으로 이해해서는 안 됩니다.
- 스트림 격리: 주로 서로 다른 스트림이 함께 대기하는 상황을 줄이며, 같은 스트림 안의 데이터 누락까지 없애지는 않습니다.
- 패킷 손실 복구: 전송 계층은 패킷 손실을 감지해 신뢰성 있는 데이터를 다시 보내야 하며, 이로 인해 링크 용량이 늘어나지는 않습니다.
- 혼잡 제어: 전송 측이 가용 대역폭을 어떻게 사용할지 결정하며, 구체적인 방식은 클라이언트와 서버 설정에 따라 다릅니다.
- 공유 병목: 여러 스트림은 여전히 같은 접속 링크를 사용하므로 무선 간섭이나 업링크 혼잡이 동시에 영향을 줄 수 있습니다.
Hysteria2의 성능 특성은 혼잡 제어와도 관련이 있습니다. Brutal 혼잡 제어는 목표 대역폭을 기준으로 동작하므로, 무작위 패킷 손실이 있지만 여유 용량이 남아 있는 링크에서는 패킷 손실 시 전송 속도를 크게 줄이는 방식보다 대역폭을 더 적극적으로 활용할 수 있습니다. 서버는 다른 혼잡 제어 방식을 사용할 수도 있으므로, Hysteria2를 쓴다고 항상 같은 전송 방식이 적용되는 것은 아닙니다.
어떤 네트워크에 적합하며 UDP가 제한되면 어떻게 될까
지역 간 연결, 긴 왕복 시간, 약간의 무작위 패킷 손실이 있는 링크는 Hysteria2의 성능을 확인해 볼 만한 환경입니다. 단, UDP가 안정적으로 통과하고 서버와 접속 네트워크에 충분한 용량이 있어야 합니다. 패킷 손실과 지연 시간이 적은 네트워크에서는 성능 차이가 거의 없을 수 있으므로 프로토콜 이름만으로 어느 연결이 더 빠른지 판단할 수 없습니다.
| 네트워크 상태 | 나타날 수 있는 현상 | 점검할 항목 |
|---|---|---|
| UDP 정상, 무작위 패킷 손실 발생 | 장시간 전송은 비교적 안정적일 수 있지만 재전송이 발생함 | 서버와 대상을 고정하고 처리량 및 상호작용 지연 시간을 반복 측정 |
| UDP 차단 | 핸드셰이크 대기 후 시간 초과, 서버 연결 실패 | UDP 리스닝과 방화벽을 확인한 뒤 다른 네트워크에서 다시 테스트 |
| UDP 속도 제한 | 연결은 되지만 지속 전송 속도가 일정 수준에서 더 이상 증가하지 않음 | Wi-Fi와 셀룰러 네트워크를 비교하고 용량 및 속도 제한 조건 확인 |
| 네트워크 혼잡 또는 무선 신호 불량 | 전송 중 지연 시간이 늘고 페이지 상호작용이 끊김 | 동시 전송을 중단하고 목표 대역폭을 낮춰 다시 테스트 |
UDP가 통하지 않는다고 Hysteria2가 자동으로 TCP 연결로 전환되지는 않습니다. 기존 설정의 혼잡 옵션도 방화벽이 완전히 차단한 UDP 경로를 만들어 주지는 않습니다. 현재 네트워크에서 UDP가 실제로 제한된다면 비밀번호를 반복해서 바꾸거나 인증서 검증을 끄기보다, 이용 중인 서비스 제공업체에 해당 환경에서 사용할 수 있는 다른 기존 연결 설정이 있는지 확인하세요.
결론: 먼저 UDP 경로 확인
같은 설정으로 셀룰러 네트워크에서는 연결되지만 특정 Wi-Fi에서 계속 시간 초과가 발생한다면 먼저 접속 네트워크의 UDP 조건을 확인하세요. 비교가 가능하도록 기존 인증 및 TLS 설정은 유지하고 여러 항목을 한꺼번에 바꾸지 않는 것이 좋습니다.
Shadowrocket에서 가져오기 및 설정 항목 확인
우선 이용 중인 서비스 제공업체가 제공한 기존 구독을 사용하세요. 구독에는 보통 프로토콜, 포트, 인증, TLS 설정이 포함되어 있어 직접 입력하면 항목을 누락하기 쉽습니다. 구독을 업데이트한 뒤에도 서버 유형을 확인해야 합니다. 목록이 갱신됐다고 서버 연결이 검증됐거나 현재 기본 서버로 설정된 것은 아닙니다.
-
구독 가져오기
Home(홈)에서 오른쪽 위 ‘+’ → Type(유형) → Subscribe(구독)를 열고 기존 구독 URL을 입력해 저장합니다. Home으로 돌아와 목록을 아래로 당겨 새로 고침하세요. 구독 URL을 다른 사람에게 공유하지 마세요.
-
유형 확인
Home에서 가져온 서버를 찾아 해당 행의 정보 버튼을 눌러 편집 화면으로 이동한 다음 Type이 Hysteria2인지 확인합니다. 직접 추가하려면 Home → ‘+’ → Type에서 Hysteria2를 선택하고 서비스 제공업체가 안내한 값을 입력합니다.
-
연결 항목 확인
Address(주소), Port(포트), Password(비밀번호)를 각각 확인합니다. 주소에는 서버 도메인이나 IP만 입력하고 구독 URL, 웹 경로, 전체 공유 링크는 넣지 않습니다.
-
암호화 설정 확인
기존 설정에 따라 SNI(서버 이름 표시)와 인증서 요구 사항을 확인합니다. 혼잡 옵션이 있다면 유형과 비밀번호도 확인하세요. 인증 비밀번호와 혼잡 비밀번호를 혼동하지 말고, 설정에 없는 값을 임의로 추가하지 마세요.
-
선택 후 연결
저장한 뒤 Home으로 돌아와 서버 왼쪽의 원형 표시를 눌러 기본 서버로 설정하고 Global Routing(전역 라우팅)을 확인합니다. 연결 스위치를 켜세요. 시스템 VPN 구성 승인이 처음 표시되면 안내에 따라 승인한 뒤 Connectivity Test(연결 테스트)를 실행합니다.
| 항목 또는 매개변수 | 확인할 내용 | 흔히 잘못 입력하는 값 |
|---|---|---|
| Address(주소) | 설명용 예시는 example.com이며, 실제로는 본인의 서버 주소를 입력합니다 | 구독 URL 또는 웹 경로가 포함된 주소 입력 |
| Port(포트) | 설명용 예시는 443이며, 실제 서버의 UDP 리스닝 포트와 일치해야 합니다 | 흔히 쓰이는 포트라고 추측하고 서버 설정은 확인하지 않음 |
| Password(비밀번호) | 서비스 제공업체가 안내한 전체 인증 문자열 입력 | 구분자를 빠뜨리거나 복사할 때 공백이 들어감 |
| SNI(서버 이름 표시) | 기존 설정에 지정된 TLS 이름을 사용하고 인증서 적용 범위를 확인 | IP로 연결하면서 인증서 도메인도 IP로 변경 |
| 혼잡 매개변수 | 서버에서 활성화한 경우에만 입력하고 양쪽의 유형 및 비밀번호를 일치시킴 | 한쪽에서만 혼잡을 활성화하거나 잘못된 비밀번호를 재사용 |
SNI와 Address는 서로 다를 수 있습니다. 전자는 TLS 이름 협상에 사용되고 후자는 연결 대상 주소를 결정합니다. 인증서 검증에 실패하면 먼저 시스템 시간, 인증서 이름, 서비스 제공업체 설정을 확인하세요. Allow Insecure(안전하지 않은 연결 허용)는 일반적인 해결 방법이 아닙니다. 검증을 끄면 서버 신원 확인 조건이 달라지므로 올바른 설정을 대신할 수 없습니다.
프로토콜 연결과 Global Routing 구분
서버에 연결된다는 것은 프록시 통신 경로를 사용할 수 있는 조건이 갖춰졌다는 뜻일 뿐입니다. 특정 웹사이트가 해당 경로를 이용하는지는 Global Routing(전역 라우팅), 현재 Config(구성 파일), 정책 선택에 따라 달라집니다. 문제를 확인할 때는 라우팅 설정을 고정하고 서버를 바꾸는 동시에 규칙과 대역폭 매개변수까지 수정하지 마세요.
Config(구성)
권장현재 구성의 규칙에 따라 라우팅합니다. 평소에는 대상에 적용되는 규칙과 정책을 확인해 해당 정책이 테스트할 Hysteria2 서버를 가리키는지 살펴보세요. 기본 서버가 정책 그룹에서 선택한 서버와 다를 수 있습니다.
적합한 경우: 분명한 라우팅 규칙을 사용하는 일상적인 연결
Proxy(프록시)
프록시 방식으로 가로채는 트래픽을 처리합니다. 기본 서버를 확인한 뒤 규칙의 영향을 배제할 때 임시로 사용할 수 있습니다. 서버 프로토콜을 바꾸는 기능이 아니며 UDP 핸드셰이크 실패를 해결하지도 않습니다.
적합한 경우: 서버 경로를 잠시 확인하고 라우팅 영향을 배제할 때
Direct(직접 연결)
선택한 프록시 서버를 거치지 않고 직접 연결합니다. 이 상태에서 웹사이트가 열려도 Hysteria2 설정이 올바르다는 뜻은 아닙니다.
적합한 경우: 현재 네트워크에서 대상 웹사이트에 직접 연결되는지 확인할 때
Global Routing의 Scene(장면)은 설정된 장면 조건에 따라 라우팅 동작을 선택합니다. 테스트 전에 현재 장면에 어떤 설정이 적용되는지 확인하세요. Settings(설정) → On Demand(요청 시 연결)는 조건이 충족될 때 시스템이 연결을 시작하도록 제어하는 기능입니다. 프로토콜을 가속하거나 서버 인증 및 규칙 적용을 대신하지는 않습니다.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT위 예시 규칙은 도메인이 example.com 또는 그 하위 도메인일 때 PROXY를 사용하고, 나머지 트래픽은 FINAL,DIRECT에 따라 직접 연결합니다. 규칙은 위에서 아래 순서로 적용되며 해당 Config를 사용할 때만 의미가 있습니다. 여기서 PROXY는 프록시 정책이지 Hysteria2의 다른 표기가 아닙니다.
증상에 따라 점검하고 비교 가능한 결과 기록
테스트를 ‘핸드셰이크 성공’, ‘대상 접속 가능’, ‘지속 전송 성능’으로 나눠 확인하세요. Home의 지연 시간 결과는 웹 페이지 및 파일 전송 테스트를 대신할 수 없습니다. Connectivity Test가 성공해도 모든 대상과 모든 시간대에 이용할 수 있다는 뜻은 아닙니다. 아래 내용은 결과를 해석하는 방법이며 특정 연결을 직접 측정한 결론은 아닙니다.
- 핸드셰이크 시간 초과: 먼저 주소와 UDP 포트를 확인한 다음 접속 네트워크와 서버 방화벽을 점검하세요. IP 주소가 조회된다고 포트에 연결할 수 있는 것은 아닙니다.
- 인증 실패: 전체 Password와 서버 계정 상태를 확인하세요. DNS를 반복해서 바꿔도 인증 문자열 오류는 대개 해결되지 않습니다.
- 인증서 오류: SNI, 시스템 시간, 인증서 유효성을 확인하세요. 검증 조건을 완화해 원인을 가리지 마세요.
- 연결됐지만 웹사이트 접속 실패: Global Routing, 현재 Config, 대상 도메인 조회 결과와 적용된 정책을 확인하고 직접 연결과 프록시 연결 중 어느 쪽에서 실패하는지 구분하세요.
- 처음에는 빠르다가 이후 정체: 다른 전송을 중단하고 목표 대역폭과 무선 신호를 확인하세요. 짧은 순간의 최고 속도를 지속 가능한 용량으로 간주하지 마세요.
비교하려면 기기, 서버, 대상 리소스, 라우팅 설정을 고정하고 같은 접속 네트워크에서 세 번 반복한 뒤 다른 네트워크에서도 같은 절차를 진행하세요. 핸드셰이크 성공 여부, 페이지 로딩 완료 여부, 지속 전송의 안정성, 전송 중 상호작용 지연 시간이 크게 늘어나는지를 각각 기록합니다. 한 번에 한 가지 조건만 바꿔야 변화의 원인을 찾을 수 있습니다.