Hysteria2란? QUIC 기반 속도와 적합한 네트워크 환경

Hysteria2와 QUIC: 전송 계층과 프록시 프로토콜 구분하기

Hysteria2는 QUIC 기반 프록시 프로토콜입니다. QUIC은 일반적으로 UDP 위에서 동작하며 TLS 1.3으로 암호화 연결을 설정합니다. UDP는 데이터그램을 전송하지만 전달 여부나 순서를 보장하지 않습니다. QUIC은 그 위에서 연결 관리, 신뢰성 있는 스트림, 손실 감지와 혼잡 제어를 구현합니다. 따라서 ‘UDP를 사용한다’고 해서 모든 데이터가 재전송되지 않는 것도, 대역폭 제한을 우회할 수 있는 것도 아닙니다.

프록시를 통해 전달되는 TCP 연결은 QUIC의 신뢰성 있는 스트림으로 데이터를 전송합니다. UDP 포워딩은 데이터그램 방식을 사용하므로, 신뢰성 있는 스트림의 재전송 특성을 모든 UDP 데이터에 적용해서는 안 됩니다. 패킷 손실을 허용할 수 있는지는 각 애플리케이션의 프로토콜에 따라 달라집니다. 웹 트래픽과 실시간 음성은 같은 서버를 사용해도 서로 다른 문제 양상을 보일 수 있습니다.

서버가 UDP 443을 사용하도록 설정되어 있다면, 네트워크에서 TCP 443만 허용해도 연결되지 않습니다. 포트 번호가 같다고 전송 프로토콜까지 같은 것은 아닙니다. 기존 설정에 지정된 포트를 사용하세요. ‘443이 흔하다’는 이유로 값을 바꾸거나, 다른 프로토콜의 주소·비밀번호·포트를 Hysteria2 설정에 그대로 조합해서는 안 됩니다.

더 빠를 수 있는 이유: 독립 스트림, 혼잡 제어, 패킷 손실 복구

QUIC의 특징 중 하나는 스트림이 서로 독립적이라는 점입니다. 한 스트림에서 데이터가 손실되어도 다른 스트림은 해당 데이터가 복구될 때까지 모두 전송을 멈출 필요가 없습니다. 이 방식은 스트림 간 헤드 오브 라인 블로킹을 줄여 주지만, 같은 신뢰성 있는 스트림 안에서 순서를 기다리는 문제까지 없애지는 않습니다. 여러 스트림은 여전히 링크 용량을 공유하며, 일반적으로 연결 단위의 혼잡 제어도 공유합니다. 따라서 ‘패킷 손실이 속도에 영향을 주지 않는다’고 결론 내릴 수는 없습니다.

Hysteria2의 처리량은 혼잡 제어 방식에도 영향을 받습니다. Brutal 메커니즘은 목표 대역폭과 피드백을 바탕으로 전송 동작을 조정합니다. 무작위 패킷 손실이 있는 링크에서는 보수적으로 속도를 낮추는 방식보다 처리량을 더 잘 유지할 수도 있습니다. 이 메커니즘의 사용 여부와 대역폭 매개변수가 협상에 반영되는 방식은 클라이언트 구현, 서버 정책, 실제 설정에 따라 달라집니다. 모든 효과를 QUIC만의 특징으로 돌릴 수 없으며, 목표 대역폭이 실제로 사용할 수 있는 대역폭을 뜻하는 것도 아닙니다.

화면에 Upload, Download 같은 대역폭 항목이 있다면 기존 설정이나 서비스 제공자가 명시한 값을 우선 사용하고 단위를 확인하세요. Mbps와 MB/s는 서로 다릅니다. 수치로는 8 Mbps가 약 1 MB/s이며, 실제 전송량은 프로토콜 오버헤드만큼 줄어듭니다. 접속 회선의 용량을 훨씬 넘는 값을 입력하면 라우터 큐만 길어져 다운로드 중 통화 지연이 눈에 띄게 커질 수 있습니다.

적합한 네트워크: 무작위 패킷 손실에서는 효과를 볼 수 있지만, UDP 제한은 먼저 연결 가능 여부부터 확인

모바일 네트워크의 무선 간섭, 지역 간 링크의 변동, 액세스 포인트의 부하 변화는 모두 전송에 영향을 줄 수 있습니다. Hysteria2는 이런 환경 중 일부에서 테스트해 볼 만하지만, ‘모바일 네트워크’라는 이유만으로 성능이 보장되지는 않습니다. 서버의 외부 연결, 대상 웹사이트, 무선 신호, 로컬 업링크 사용량 등 프로토콜 선택과 무관한 병목도 결과에 영향을 줍니다.

• 무작위 패킷 손실이 있지만 UDP 연결이 가능한 경우: 다운로드 속도가 자주 떨어지는지, 요청에 꾸준히 응답하는지 살펴보세요. 최고 속도만 보지 말고 유휴 상태와 부하가 걸린 상태의 지연 시간도 함께 기록하세요.
• 지연 시간이 길고 링크 용량이 큰 경우: 전송 제어와 손실 복구가 대역폭 활용률에 영향을 주지만, 서버에서 대상 사이트로 가는 구간의 속도가 느리면 결과가 제한될 수 있습니다.
• 지연 시간이 짧고 패킷 손실이 적은 경우: 체감할 만한 차이가 없을 수도 있습니다. 특정 프로토콜 이름에 집착하기보다 설정을 단순하게 유지하고 인증서를 올바르게 검증하는 것이 중요합니다.
• UDP가 차단되었거나 지속적으로 속도 제한을 받는 경우: 핸드셰이크 시간 초과나 연결 직후 멈춤이 발생할 수 있습니다. 이때는 네트워크 정책을 먼저 확인하고 대역폭 값을 반복해서 높이지 마세요.
• Wi-Fi와 셀룰러 네트워크를 전환하는 경우: 전환 후 연결 상태를 다시 확인해야 합니다. QUIC에는 연결 마이그레이션 관련 기능이 있지만, 실제 연결 유지 여부는 구현과 네트워크 조건에 따라 달라집니다. 네트워크 전환 중에도 서비스가 끊기지 않는다고 보장할 수는 없습니다.

Shadowrocket 설정 방법: 기존 Hysteria2 서버 정보 사용하기

아래는 Home에서 서버를 직접 추가하는 절차입니다. 서버 주소, 포트, 인증 비밀번호, TLS에 필요한 SNI, 서버에서 명시한 기타 매개변수를 준비하세요. 주소와 SNI는 서로 다를 수 있습니다. Address는 연결 대상이고, SNI는 TLS 핸드셰이크에서 서버 이름을 전달하는 데 사용됩니다. 인증서 이름도 설정에 맞게 검증해야 합니다.

1. 설정 출처 확인

   기존 서버 설정 안내를 열어 프로토콜이 Hysteria2로 지정되어 있는지 확인하세요. Hysteria와 Hysteria2를 서로 바꿔 쓸 수 있는 Type으로 간주하지 말고, 다른 프로토콜의 인증 정보를 섞어 쓰지 마세요.

2. Type 선택

   Home → 오른쪽 위 ‘+’ → Type에서 Hysteria2를 선택한 다음 추가 화면으로 돌아오세요. 실제 화면에 해당 항목이 없다면 비슷한 이름을 대신 선택하지 말고, 사이트의 다운로드 페이지에서 현재 플랫폼의 클라이언트 설치 경로를 확인하세요.

3. 연결 정보 입력

   기존 설정에 따라 Address, Port, Password를 입력하세요. Address에는 해당 항목이 요구하는 서버 주소만 입력하고, Port에는 지정된 숫자를 사용하세요. 전체 공유 문자열을 주소 입력란에 붙여 넣거나 공백을 추가하지 마세요.

4. 보안 설정 확인

   설정에 따라 SNI를 입력하고 인증서 검증을 유지하세요. 기존 정보에 혼잡 방지나 대역폭 설정이 있다면 클라이언트의 해당 항목을 하나씩 확인한 다음 입력하세요. 요구되지 않은 선택 항목의 값은 임의로 추측하지 마세요.

5. 저장 후 테스트

   저장한 뒤 Home으로 돌아가 방금 추가한 서버를 선택하고, 현재 Global Routing 모드를 확인하세요. 연결을 활성화하고 시스템 안내에 따라 권한을 허용한 다음, 접속 가능한 것으로 확인된 대상을 먼저 열어 보세요. 이후 지속 전송을 테스트합니다.

기존 구독이 있다면 Home → ‘+’ → Type → Subscribe에서 본인의 구독 주소를 가져올 수 있습니다. 저장 후 구독 내용을 업데이트하고 가져온 항목의 프로토콜 유형을 확인하세요. 구독 업데이트 과정에서 관리 대상 항목의 포트, 인증 정보 또는 기타 매개변수가 바뀔 수 있습니다. 수정 사항을 계속 유지해야 한다면 먼저 해당 항목이 구독에서 관리되는지 확인해, 임시 로컬 변경을 영구 설정으로 오해하지 않도록 하세요.

인증서 오류가 발생하면 SNI, 서버 인증서 유효 기간, 인증서 체인, 기기 시간을 확인하세요. 검증을 끄면 신원 확인 보호 수준이 달라지므로 일반적인 해결 방법으로 사용해서는 안 됩니다. 인증에 실패하면 먼저 Password가 빠짐없이 복사되었는지, 서버가 해당 인증 정보를 계속 허용하는지 확인하세요. 인증 문제를 QUIC 패킷 손실 탓으로 돌리지 마세요.

Global Routing 확인: 프로토콜 문제와 규칙 미일치 구분하기

서버 정보가 올바르더라도 모든 요청이 해당 서버를 이용하는 것은 아닙니다. Shadowrocket의 Global Routing은 라우팅 동작을 결정합니다. Config는 현재 설정의 규칙을 사용하고, Proxy는 문제 범위를 일시적으로 좁혀 확인할 때 쓸 수 있습니다. 모드는 클라이언트가 처리하는 트래픽에만 영향을 주므로, 기기의 모든 시스템 트래픽이 같은 경로를 거친다고 증명하지는 않습니다.

Global Routing의 Scene은 상황별 라우팅 설정을 위한 기능으로, Config, Proxy, Direct 중 하나의 고정 결과와 같지 않습니다. 문제를 진단할 때는 실제 적용 중인 설정부터 확인하세요. Settings → On Demand 상태도 기록해 두세요. 테스트 중 필요에 따라 연결이 다시 시작되면 ‘연결을 껐는데 다시 켜졌다’고 잘못 판단할 수 있습니다.

Config에서는 일반적으로 규칙을 순서대로 확인하며 먼저 일치하는 규칙이 정책을 결정합니다. 아래는 DOMAIN-SUFFIX와 FINAL 문법의 예시일 뿐이며, 가져와서 사용할 수 있는 완전한 설정은 아닙니다. example.com은 문서용 예시 도메인이며 이 글에서 제공하는 서버가 아닙니다. 실제 설정에서 사용하는 정책 이름은 정의되어 있어야 합니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

대상 도메인이 첫 번째 규칙과 일치하지 않으면 FINAL,DIRECT가 적용됩니다. 이 경우 접속 성공 여부만으로 Hysteria2의 상태를 판단할 수 없습니다. 다른 설정에서는 IP 매칭에 GEOIP나 IP-CIDR을 사용할 수도 있으며, 도메인 해석이 관련된 경우 DNS 결과도 이후 판단에 영향을 줄 수 있습니다. 자세한 값은 설정 참고에서, 라우팅 동작은 프록시 모드 설명에서 확인하세요.

문제 해결과 비교 기록: 한 번에 조건 하나만 바꾸기

테스트 전에 네트워크 종류, 선택한 서버, Global Routing, 대상 사이트, 테스트 시간을 기록하세요. 대상과 서버를 그대로 유지한 채 Wi-Fi와 셀룰러 네트워크에서 각각 확인하세요. 프로토콜을 비교해야 한다면 사용자가 이미 보유하고 서버 조건을 비교할 수 있는 설정만 사용하세요. 서버가 서로 다르면 속도 차이를 프로토콜 탓으로 단정할 수 없습니다.

• 반복 가능한 테스트: 각 조건에서 연속으로 3회 테스트하고, 연결 성공 여부와 응답이 시작되기까지 걸린 시간, 지속 전송 중단 여부를 각각 기록하세요. 가장 빠른 결과만 고르지 말고 중간 수준의 결과를 기준으로 삼으세요.
• 부하 조건 통일: 비교 테스트 중에는 시스템 업데이트와 다른 대용량 작업을 중지하세요. 속도 측정 결과는 대상 서버의 속도 제한에도 영향을 받으므로 회선 용량의 유일한 증거로 볼 수 없습니다.
• 문제 발생 계층 구분: 핸드셰이크 실패, 인증 실패, 규칙 미일치, 대상 사이트 오류는 서로 다른 문제입니다. 각각 따로 기록하고 모두 ‘프로토콜이 느림’으로 분류하지 마세요.
• 설정 정보 보호: 기존 서비스 제공자에게 문제를 알릴 때 오류 유형과 네트워크 조건을 설명할 수 있습니다. 공개 기록에는 비밀번호, 구독 주소, 서버를 식별할 수 있는 정보를 노출하지 마세요.