Shadowrocket Hysteria2 설명: QUIC 전송이 빠른 이유와 적합한 네트워크

핵심 내용 미리보기

UDP 연결이 가능하고 왕복 지연 시간이 길거나 무작위 패킷 손실이 있는 네트워크에서는 Hysteria2를 시험해 볼 만합니다. 다만 프로토콜 이름만으로 속도를 판단할 수는 없습니다. 이미 이용 중인 서비스 제공업체의 설정과 구독이 있는 사용자를 위해 QUIC 전송 방식부터 설명하고, Shadowrocket에서 설정을 가져온 뒤 라우팅을 확인하고 다시 테스트하는 절차를 소개합니다. 이를 통해 설정 오류, UDP 제한, 규칙 미일치 문제를 구분할 수 있습니다.

1. Hysteria2와 QUIC: 어떤 점이 유리할까

Shadowrocket의 Hysteria2는 선택할 수 있는 프록시 프로토콜 중 하나입니다. QUIC를 전송 기반으로 사용하며, QUIC는 UDP를 통해 데이터를 전달하고 TLS 1.3으로 보안 연결을 설정합니다. 두 가지를 구분해야 합니다. 하위 전송 계층이 UDP라고 해서 애플리케이션 데이터가 모두 신뢰성 없는 방식으로 전송되는 것은 아닙니다. QUIC는 UDP 위에서 스트림의 순서 보장 전달, 손실 복구, 흐름 제어를 제공할 수 있습니다.

기존 TCP 연결에서 여러 애플리케이션 요청이 하나의 순서 있는 바이트 스트림을 공유하면 패킷 손실 한 번으로 뒤따르는 데이터 전달까지 막힐 수 있습니다. QUIC는 스트림별로 전달을 관리하므로 특정 스트림에서 누락된 데이터를 기다리는 동안 다른 스트림까지 같은 이유로 기다릴 필요는 없습니다. 다만 각 스트림은 혼잡 제어와 링크 용량을 공유할 수 있습니다. 따라서 “스트림 간 전달 지연을 줄인다”는 말이 “패킷 손실의 영향이 전혀 없다”는 뜻은 아닙니다.

UDP: 데이터그램을 전달하지만 자체적으로 안정적인 전달을 보장하지 않으며, 네트워크 속도 제한을 자동으로 우회하지도 않습니다.
QUIC: 전송 계층에서 연결 관리, 보안 핸드셰이크, 다중 스트림 기능을 구현합니다. 각 스트림 내부에서는 여전히 순서 있는 전달이 필요합니다.
Hysteria2: QUIC 위에서 프록시 통신을 구성하며, 처리량에 초점을 둔 혼잡 제어와 대역폭 설정 기능을 갖추고 있습니다.
실제 사용 경험: 무선 신호, 링크 혼잡, 서버 부하, 대상 사이트, 설정값의 영향을 함께 받습니다.

일부 무작위 패킷 손실 링크에서 Hysteria2의 처리량이 유리한 이유는 대역폭을 기반으로 한 혼잡 제어 방식과도 관련이 있습니다. QUIC 기반 연결이라도 모두 같은 결과를 얻는 것은 아닙니다. 클라이언트의 대역폭 설정, 서버 제한, 협상 결과가 동작에 영향을 줍니다. “QUIC 사용”을 일정한 속도 향상률로 환산할 수는 없습니다.

2. 높은 지연과 패킷 손실: 먼저 병목을 구분하세요

지연 시간이 높으면 요청을 보낸 뒤 응답을 받기까지 더 오래 걸립니다. Hysteria2가 물리적 거리로 인한 왕복 시간을 없앨 수는 없지만, 적합한 링크에서는 더 높은 처리량을 유지할 수 있습니다. 패킷 손실이 많다면 무선 간섭으로 인한 무작위 손실과 대기열의 지속적인 혼잡으로 인한 손실을 구분해야 합니다. 두 상황은 같은 방식으로 해결할 수 없습니다. 네트워크가 이미 혼잡한 상태에서 전송량만 늘리면 통화, 웹페이지, 다른 기기의 연결까지 악화될 수 있습니다.

네트워크 증상	해석	확인 방법
작은 웹페이지는 정상인데 대용량 파일 전송 속도가 느림	패킷 손실, 혼잡 또는 원격 서버의 대역폭 문제일 수 있습니다. 지연 시간만으로 판단하지 마세요.	같은 네트워크에서 같은 서버의 동일한 파일을 반복 전송하고 소요 시간을 기록합니다.
유휴 상태에서는 정상인데 다운로드 중 지연 시간이 크게 늘어남	링크 대기열이 쌓인 상태일 수 있습니다. 전송량을 과도하게 설정하면 증상이 심해질 수 있습니다.	다른 대용량 작업을 중지하고 대역폭 설정을 낮춘 뒤 다시 비교합니다.
Wi-Fi에서는 연결되지 않지만 셀룰러 네트워크에서는 정상	현재 Wi-Fi에서 UDP를 제한하거나 DNS 또는 출구 정책을 다르게 적용할 수 있습니다.	설정은 그대로 두고 네트워크만 전환한 뒤 DNS 확인 결과와 핸드셰이크 결과를 각각 비교합니다.
첫 요청은 느리지만 이후 전송은 정상	DNS, 연결 설정, 대상 사이트 응답을 각각 확인해야 합니다.	첫 페이지를 여는 데 걸린 시간과 이후 전송 성능을 따로 기록합니다.

결론: 한 번에 한 가지씩 바꿔 다시 테스트하세요

서버, 대상 리소스, 라우팅 경로를 고정한 상태에서 네트워크를 바꾸거나 설정 하나를 조정해야 결과를 판단할 수 있습니다. 구독, DNS, Global Routing을 동시에 바꾼 뒤 개선된 원인을 Hysteria2로 단정하지 마세요.

명확한 기록 방법을 정해 테스트할 수 있습니다. 각 네트워크에서 같은 리소스를 3회 전송하고, 매회 약 60초간 진행해 전송한 바이트 수, 소요 시간, 중단 여부, 테스트 시간대를 기록합니다. 이는 재테스트 방법일 뿐 제품 성능 데이터가 아닙니다. 한 번의 최고 속도나 단일 지연 시간 측정만으로 현재 네트워크에 더 적합한 프로토콜이라고 입증할 수 없습니다.

3. Shadowrocket에서 Hysteria2 설정을 가져와 확인하기

이미 보유한 구독 또는 전체 설정을 기준으로 진행합니다. Hysteria2는 서버 측 지원이 필요하므로 기존 서버의 Type만 Hysteria2로 바꿔서는 사용할 수 없습니다. 가져온 뒤 Address, Port, 인증 정보, TLS 매개변수를 확인하세요. 구독에 설정이 모두 포함되어 있다면 경험에 의존해 값을 추가하기보다 기존 필드를 그대로 유지하는 편이 일반적으로 더 안전합니다.

기존 구독 가져오기

Home을 열고 오른쪽 상단의 “+” → Type → Subscribe를 선택한 뒤, 이미 보유한 구독 링크를 붙여넣고 저장합니다. 구독 주소에는 접근 정보가 포함되어 있으므로 스크린샷이나 문제 해결 기록에 공개적으로 붙여넣지 마세요.
프로토콜 유형 확인

Home으로 돌아가 가져온 서버의 편집 화면을 열고 Type이 Hysteria2인지 확인합니다. 구독에 해당 유형이 없다면 직접 유형을 바꾸지 말고 기존 설정 제공업체에 문의하세요.
연결 필드 확인

Address, Port, 인증 정보, SNI를 각각 확인합니다. Port는 원격 서버가 수신 대기 중인 포트와 일치해야 합니다. 예를 들어 원격 서버에서 443을 명시한 경우에만 443을 입력하세요. 이를 공통 기본값으로 간주하면 안 됩니다.
테스트 경로 고정

Home에서 테스트할 서버를 선택하고 Global Routing → Proxy를 연 다음 연결을 설정해 같은 대상 리소스를 테스트합니다. 정책 그룹을 사용한다면 실제로 선택된 구성원도 확인해 다른 서버를 테스트하는 일이 없도록 하세요.
평소 설정으로 복원

확인이 끝나면 Global Routing을 원래 사용하던 Config로 되돌리고 대상 리소스에 다시 접속합니다. Proxy에서는 정상인데 Config에서 문제가 생긴다면 전송 매개변수부터 수정하지 말고 규칙과 정책 그룹을 확인하세요.

SNI는 TLS 핸드셰이크에서 서버 이름을 표시하는 데 사용하므로 기존 설정에 지정된 값을 입력해야 합니다. 연결 주소가 IP인 경우에도 인증서에 해당하는 도메인을 별도로 지정해야 할 수 있습니다. 인증서 오류가 발생하면 인증서 검증을 느슨하게 해 문제를 덮지 말고 서버 이름, 인증서 유효성, 기기 시간을 확인하세요. 설정에 난독화 매개변수가 포함된 경우 클라이언트와 서버의 설정도 일치해야 합니다. 한쪽에서만 활성화해도 UDP 연결 문제는 해결되지 않습니다.

4. Global Routing: 전송 문제와 라우팅 문제 구분하기

Global Routing은 요청이 어떤 출구 경로를 사용할지 결정할 뿐, 특정 프로토콜의 속도를 높이지는 않습니다. 문제 해결 과정에서 가장 흔한 오판은 Hysteria2 서버를 선택해 놓고 대상 요청이 실제로 그 서버를 사용하는지 확인하지 않는 것입니다. 아래에서는 Shadowrocket의 라우팅 모드만 비교합니다. 권장 항목은 일상적인 사용을 위한 것이며, 문제 해결 시 반드시 해당 모드만 써야 한다는 뜻은 아닙니다.

Config: 설정에 따른 라우팅

권장

현재 활성화된 설정의 규칙에 따라 요청을 처리합니다. 대상 요청은 DIRECT로 연결되거나 프록시 또는 정책 그룹으로 전달될 수 있습니다. 서버를 선택했다고 모든 요청이 해당 서버를 사용하는 것은 아닙니다.

적합한 경우: 규칙 확인을 마친 뒤 일상적으로 연결할 때

Proxy: 프록시 경로 확인

이 모드의 영향을 받는 요청을 프록시 경로로 보내 규칙 매칭에 따른 변수를 일시적으로 줄일 수 있습니다. 현재 선택된 서버 또는 정책 그룹이 실제로 무엇인지 확인해야 합니다.

적합한 경우: 서버 연결 여부를 확인하고 규칙 오매칭을 배제할 때

Direct: 직접 연결 기준선 확인

선택한 프록시 서버를 거치지 않고 직접 연결합니다. 이를 통해 로컬 네트워크 자체에 문제가 있는지 확인할 수 있지만, 직접 연결 결과만으로 Hysteria2의 UDP 핸드셰이크가 정상이라고 입증할 수는 없습니다.

적합한 경우: 로컬 네트워크와 프록시 경로의 차이를 비교할 때

Config에서 문제를 확인할 때는 먼저 어떤 설정이 활성화되어 있는지 확인한 다음 규칙 순서를 살펴보세요. DOMAIN-SUFFIX는 도메인 접미사로 매칭하고, IP-CIDR는 IP 대역으로 매칭하며, GEOIP는 IP 지리 정보 데이터에 의존합니다. FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 마지막에 프록시 정책이 보인다고 해서 앞에서 이미 매칭된 DIRECT 규칙을 간과하지 마세요.

Proxy에서는 정상이고 Config에서는 문제가 발생함: 먼저 일치한 규칙, 정책 이름, 정책 그룹 구성원을 확인하세요.
두 모드 모두 연결되지 않음: 먼저 주소 확인, UDP 연결 가능 여부, 인증 정보, TLS 매개변수를 확인하세요.
연결이 자주 자동으로 다시 설정됨: Settings → On Demand에서 설정한 온디맨드 연결 조건을 확인해 연결 관리 동작과 전송 장애를 구분하세요.

5. UDP가 제한된 경우: 포트, 핸드셰이크, MTU의 한계

Hysteria2의 외부 전송은 UDP에 의존합니다. 어떤 네트워크에서 TCP 443에 접속할 수 있다고 해서 UDP 443도 허용되는 것은 아닙니다. 웹페이지가 열린다고 QUIC를 사용할 수 있다는 뜻도 아닙니다. 포트 번호가 같다는 것은 숫자만 같다는 의미이며, 전송 프로토콜이 다르면 방화벽과 트래픽 정책도 다르게 적용될 수 있습니다.

연결 시간이 초과되면 먼저 원격 서버의 UDP 수신 여부와 네트워크에서 UDP를 허용하는지 확인하세요. Port를 443으로 바꾸는 것은 서버가 실제로 UDP 443을 수신할 때만 의미가 있습니다. 임의로 포트를 바꾸면 설정 오류만 늘어나기 쉽습니다. 포트 호핑도 서버의 포트 범위와 클라이언트 설정이 함께 맞아야 합니다. UDP가 전면 차단된 환경의 해결책으로 쓸 수는 없습니다.

인증 오류가 즉시 반환됨: 먼저 인증 문자열, 구독 업데이트 여부, 올바른 항목을 선택했는지 확인하세요.
인증서 오류가 명확히 반환됨: 먼저 SNI, 인증서 이름, 기기 시간을 확인하세요. 이를 대역폭 부족 문제로 분류하지 마세요.
오래 기다린 뒤 연결 시간이 초과됨: Address, Port, DNS 조회 결과, UDP 경로를 확인하세요. 시간 초과만으로 패킷 손실 위치를 단정할 수는 없습니다.
핸드셰이크는 성공했지만 전송이 멈춤: 이후에는 링크 혼잡, 경로 MTU, 원격 서버 부하, 대상 사이트 응답을 확인하세요.

QUIC 초기 데이터그램에는 UDP 페이로드가 최소 1,200바이트여야 하는 요구 사항이 있습니다. 경로에서 관련 패킷을 제대로 전달하지 못하면 핸드셰이크나 이후 전송에 문제가 생길 수 있습니다. 하지만 멈춤 현상이 보인다고 MTU를 바꾸는 것이 만능 해결책은 아닙니다. 경로 MTU, 터널 오버헤드, 앱 화면에서 조정할 수 있는 매개변수는 서로 같은 개념이 아닙니다. WireGuard 설정의 MTU 값을 Hysteria2에 그대로 적용하지 마세요. 기본값과 기존 설정을 유지하고, 명확한 진단 근거가 있을 때만 조정하세요.

6. 자주 묻는 질문과 최종 선택

지연 시간이 더 낮으면 무조건 더 빠른가요?

그렇지 않습니다. 먼저 Home에서 서버와 Global Routing 모드를 고정한 다음 웹페이지의 첫 응답과 지속 전송을 따로 측정하세요. 지연 시간은 특정 방식으로 측정한 결과일 뿐, 처리량이나 안정성, 실제 사용 성능을 대신하지 못합니다.

셀룰러 네트워크로 바꾸면 왜 연결되나요?

같은 서버, 포트, 인증 정보를 유지한 채 Wi-Fi와 셀룰러 네트워크를 비교하세요. Wi-Fi에서만 실패한다면 해당 네트워크의 UDP 정책, DNS, 출구 조건을 먼저 확인하세요. 하나의 네트워크에 맞추려고 올바른 인증 정보를 반복해서 바꾸지 마세요.

구독은 업데이트되는데 서버에는 왜 연결할 수 없나요?

구독 가져오기와 Hysteria2 전송은 서로 다른 경로로 확인해야 합니다. 업데이트에 성공했다는 것은 설정을 가져왔다는 뜻일 뿐입니다. Home으로 돌아가 가져온 항목의 Type, Address, Port를 확인한 다음 Global Routing → Proxy에서 연결을 따로 테스트하세요.

모든 네트워크에서 Hysteria2로 바꿔야 하나요?

그럴 필요는 없습니다. UDP가 제한되거나 현재 연결이 안정적인 네트워크에서는 작동 중인 설정을 유지하는 편이 합리적입니다. 기존 설정에 다른 전송 방식이 있다면 같은 대상과 시간대에 비교할 수 있습니다. 프로토콜 이름이 새롭다는 이유만으로 이미 검증된 경로를 바꾸지 마세요.

최종 선택은 반복해도 일관된 연결 결과를 기준으로 하세요. UDP 연결이 가능하고 매개변수가 올바르며 지속 전송이 안정적일 때 Hysteria2를 일상 설정에 포함할 만합니다. 높은 지연 시간과 무작위 패킷 손실은 Hysteria2를 시험해 볼 이유이지 성능을 보장하는 조건은 아닙니다. 확인해야 할 것은 테스트 조건과 무관한 속도 순위가 아니라 “현재 네트워크에서 더 안정적인가, 대상 작업이 더 원활한가”입니다.