Hysteria2 사용법: QUIC 기반 속도 원리와 적합한 환경

1. Hysteria2와 QUIC: 속도를 내는 원리

Hysteria2는 프록시 프로토콜이지, 회선 요금제나 대역폭 가속 기능이 아닙니다. 클라이언트인 Shadowrocket은 사용자가 보유한 서버 주소, 인증 정보, 전송 매개변수를 이용해 연결합니다. 연결 품질은 로컬 네트워크, 통신사 경로, 서버 부하, 외부 연결 대역폭의 영향을 함께 받습니다.

QUIC은 UDP 위에서 암호화, 신뢰성 있는 전송, 흐름 제어, 혼잡 제어를 구현합니다. UDP를 사용한다고 해서 모든 데이터가 재전송되지 않는 것은 아닙니다. Hysteria2가 TCP 연결을 프록시할 때는 QUIC stream이 신뢰성 있는 전송을 제공하고, UDP 데이터그램을 프록시할 때는 다른 전송 방식을 사용하므로 둘을 혼동해서는 안 됩니다.

기존 TCP 연결 하나에서는 데이터가 순서대로 전달되므로 손실된 데이터를 보충할 때까지 뒤의 데이터가 기다립니다. QUIC은 stream마다 전달 과정을 분리해 한 stream의 패킷 손실이 다른 stream의 순서 있는 전달을 반드시 막지는 않습니다. 다만 같은 stream에서는 누락된 데이터를 기다려야 하며, 서로 다른 stream도 링크 용량과 혼잡 상태를 공유합니다. 따라서 “QUIC을 사용하면 HOL blocking이 완전히 사라진다”는 설명은 정확하지 않습니다.

QUIC의 핸드셰이크 설계는 연결 설정에 드는 시간을 일부 줄일 수 있지만, 최초 연결, 세션 재개, 실제 네트워크 경로의 조건은 서로 다릅니다. 이론적인 핸드셰이크 이점을 일정한 웹 페이지 속도 향상률로 환산해서는 안 되며, 한 번의 연결 지연 시간을 지속적인 다운로드 속도로 간주해서도 안 됩니다.

2. 혼잡 제어와 대역폭 설정: 값이 클수록 빠른 것은 아닙니다

패킷 손실은 무선 간섭이나 대기열 혼잡으로 발생할 수 있습니다. 클라이언트에서는 두 경우 모두 데이터 손실로 보일 수 있지만, 적절한 전송 방식은 다릅니다. Hysteria2의 주요 특징 중 하나는 목표 대역폭을 기준으로 동작하는 Brutal 혼잡 제어를 사용할 수 있다는 점입니다. 프로토콜에는 대역폭 협상 및 다른 혼잡 제어 방식도 있으므로, 모든 연결이 같은 방식으로 전송되는 것은 아닙니다.

해당 대역폭 설정을 사용하는 연결에서는 송신 측이 목표 속도와 패킷 손실을 고려해 전송을 조정합니다. 간헐적인 패킷 손실이 있는 링크에서는 손실을 매번 혼잡 신호로 간주하는 방식보다 가용 대역폭을 충분히 활용할 수도 있습니다. 반면 링크가 이미 혼잡하다면 목표값을 지나치게 높게 설정할 경우 대기열, 재전송, 다른 서비스의 지연이 늘어날 수 있습니다.

• Upload: 클라이언트에서 서버로 보내는 방향을 기준으로, 보유한 설정 정보에 지정된 업로드 대역폭을 입력합니다. 인터넷 요금제의 다운로드 속도를 그대로 입력하지 마세요.
• Download: 클라이언트가 받는 방향을 기준으로, 순간 최고 속도가 아니라 현재 네트워크에서 지속적으로 사용할 수 있는 다운로드 속도에 맞춥니다.
• 단위: 항목에 표시된 단위를 정확히 따릅니다. 십진법 기준으로 20 Mbps는 약 2.5 MB/s이며, 실제 전송량은 프로토콜 오버헤드만큼 줄어듭니다.
• 서버 측 제한: 서버에서 대역폭을 제한하거나 협상 방식을 조정할 수 있습니다. 클라이언트에 더 큰 값을 입력해도 서버의 외부 연결 속도 제한이 해제되지는 않습니다.

3. 모바일 네트워크, 패킷 손실 환경과 배터리 소모

모바일 네트워크는 신호 변화, 기지국 부하, 무선 재전송으로 사용 가능한 대역폭이 계속 달라집니다. UDP를 사용할 수 있고 간헐적인 패킷 손실이 있어도 여유 용량이 남아 있는 환경이라면 Hysteria2를 테스트해 볼 만합니다. UDP가 차단되거나 엄격하게 제한되어 있거나 네트워크 로그인이 필요한 경우, 프로토콜 자체로는 이러한 연결 조건을 우회할 수 없습니다.

Wi-Fi에서 셀룰러 네트워크로 전환할 때 QUIC의 연결 ID와 경로 검증 기능이 주소 변경을 처리하는 데 도움이 될 수 있습니다. 다만 세션을 유지할 수 있는지는 구현, 시스템 네트워크 상태, 서버 지원 여부에 따라 달라집니다. 실제 사용 중에는 연결이 다시 설정될 수도 있으므로 “QUIC 지원”을 모든 앱 세션이 끊기지 않는다는 뜻으로 이해해서는 안 됩니다.

• 원격 파일 전송: 지속적인 전송 속도와 실패 후 재시도 여부를 확인하세요. 순간 최고 속도가 높아도 전송이 자주 끊긴다면 해당 작업에 더 적합하다고 볼 수 없습니다.
• 음성 통화와 상호작용: 지연 시간의 변동과 패킷 손실을 확인하세요. 대용량 다운로드가 업로드 대역폭을 모두 사용하면 상호작용 품질이 떨어질 수 있습니다.
• 패킷 손실이 적은 유선 네트워크: 기존 연결이 이미 안정적이라면 프로토콜을 바꿔도 뚜렷한 이점이 없을 수 있습니다. 같은 시간대와 같은 대상에서 결과를 비교하세요.
• 제한된 Wi-Fi: 먼저 네트워크 인증을 완료한 다음 서버의 UDP 포트에 연결할 수 있는지 확인하세요. TCP 443을 사용할 수 있다고 해서 UDP 443도 사용할 수 있는 것은 아닙니다.

배터리 소모는 작업 환경에 따라 달라집니다. 암호화 처리, 사용자 공간 전송 처리, 패킷 손실에 따른 재전송, 지속적인 무선 송신은 프로세서와 무선 모듈의 작업량을 늘릴 수 있습니다. 반대로 작업을 더 빨리 끝내면 기기가 활성 상태로 유지되는 시간이 줄어들 수도 있습니다. 따라서 Hysteria2가 항상 배터리를 더 많이 소모하거나 덜 소모한다고 단정할 수 없습니다. 같은 네트워크, 비슷한 화면 밝기, 같은 파일 크기로 완료 시간과 발열, 시스템 배터리 기록을 비교해 보세요.

4. Shadowrocket 설정 항목과 입력 기준

Shadowrocket에서 Home은 연결 선택 및 상태 확인, Config는 규칙 설정 관리, Settings는 앱 설정 관리에 사용됩니다. 수동으로 입력하기 전에 보유한 설정 정보가 실제로 Hysteria2용인지 확인하세요. 기존 Hysteria 설정을 그대로 호환되는 설정으로 간주해서는 안 됩니다. 표시되는 항목과 그룹 구성은 플랫폼마다 다를 수 있습니다. 아래에서 확인해야 할 매개변수의 의미를 살펴봅니다.

TLS 검증은 연결된 서버의 신원을 확인합니다. IP 주소로 연결하지만 인증서가 도메인용으로 발급된 경우, 인증서 검증을 끄는 것을 일반적인 해결책으로 삼지 말고 올바른 SNI와 인증서 체인을 먼저 확인하세요. 인증 실패, 인증서 오류, UDP 연결 불가는 서로 다른 문제입니다. 비밀번호를 바꿔도 차단된 포트 문제는 해결되지 않습니다.

5. 기존 설정 정보를 가져와 첫 연결 확인하기

용도를 알고 있는 기존 설정 정보를 우선 사용하세요. 이 사이트는 서버나 구독을 제공하거나 판매 또는 추천하지 않습니다. 구독 URL은 설정을 업데이트하는 경로이지 서버 주소가 아닙니다. 예를 들어 https://example.com/sub?token=xxxx는 형식을 설명하기 위한 가짜 값이며 연결에 사용할 수 없습니다. 링크에 포함된 인증 정보는 자격 증명으로 취급하고, 공개 게시물에 화면을 캡처하거나 붙여 넣지 마세요.

1. 설정 정보 확인

   프로토콜이 Hysteria2인지 확인하고 Server, Port, 인증값, SNI, Obfs 사용 여부를 기록합니다. 대역폭 단위가 안내되어 있지 않다면 기존 서비스 제공업체에 먼저 문의하세요.

2. 연결 추가

   수동으로 추가하려면 Home → 오른쪽 위의 “+” → Add Server로 이동합니다. Type에서 Hysteria2를 선택하고 항목을 하나씩 입력하세요. 기존 구독을 사용하는 경우 안내에 따라 Subscribe를 선택하고, 구독 URL을 Server에 입력하지 마세요.

3. 선택 후 연결

   저장한 뒤 Home으로 돌아가 방금 추가한 항목을 선택하고 연결을 켭니다. 시스템에서 VPN 구성 허용을 요청하면 앱 이름을 확인한 다음 승인하고 연결이 성공적으로 설정되는지 살펴보세요.

4. 라우팅 확인

   Global Routing에서 현재 설정이 Config, Proxy, Direct, Scene 중 무엇인지 확인합니다. 처음 문제를 확인할 때는 Proxy를 임시로 사용해 테스트한 뒤 평소 설정으로 복원하세요. 요청이 실제로는 Direct로 처리되는데 프로토콜 문제로 오해하는 일을 방지할 수 있습니다.

5. 재테스트 및 복원

   웹 페이지 열기, 지속적인 데이터 전송, 짧은 상호작용을 각각 확인합니다. 테스트 시간을 직접 제어하려면 Settings → On Demand에서 트리거 조건을 확인해 자동 연결이 관찰 결과에 영향을 주지 않도록 하세요. 테스트 후에는 기존 설정을 복원합니다.

구독으로 가져온 항목은 업데이트 후 출처에 따라 설정값이 달라질 수 있습니다. 수동으로 수정하기 전에 기존 값을 기록하고, 업데이트 후에는 SNI, 포트, 대역폭 매개변수를 다시 확인하세요. 목록에 같은 이름의 항목이 남아 있다는 이유만으로 설정 내용이 바뀌지 않았다고 판단하지 마세요.

6. Global Routing 비교: 프로토콜 문제와 규칙 문제 구분하기

프로토콜은 “서버와 어떻게 데이터를 주고받는지”를 정하고, 라우팅 모드는 “요청을 어디로 보낼지”를 정합니다. Hysteria2에 연결되었다고 해서 모든 요청이 이 연결을 사용하는 것은 아닙니다. 아래 내용은 Shadowrocket 자체 설정을 설명하기 위한 비교입니다. 일상적으로 사용할 모드는 기존 설정의 규칙과 정책이 올바른지에 따라 달라집니다.

Config에서 DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 IP 주소 대역을, GEOIP는 IP 지리 데이터베이스를 기준으로 일치 항목을 찾습니다. FINAL은 앞선 규칙에 일치하지 않은 요청에 최종 정책을 지정합니다. 규칙 순서에 따라 일치 결과가 달라집니다. 속도가 예상과 다르면 Hysteria2 매개변수를 바꾸기 전에 실제로 어떤 정책이 적용되었는지 먼저 확인하세요.

7. 연결 시간 초과, 인증 실패, 속도 변동 점검 순서

문제를 점검할 때는 먼저 연결 설정 문제를 확인하고, 다음으로 요청 라우팅을 살펴본 뒤 마지막으로 속도를 조정하세요. 포트, SNI, 비밀번호, 대역폭을 한꺼번에 바꾸면 비교 기준을 잃게 됩니다. 아래의 현상과 확인 방향은 진단에 참고할 단서일 뿐, 실측 결과를 꾸며낸 것이 아니며 하나의 현상만으로 원인을 확정할 수도 없습니다.

• 연결을 기다리다 시간 초과: Server와 UDP Port를 확인하고 Wi-Fi 인증이 완료되었는지 살펴보세요. 같은 설정으로 다른 사용 가능한 네트워크에 연결해 비교해 보세요. TCP 포트 테스트 결과만으로 UDP에 연결할 수 있다고 판단하지 마세요.
• 인증서 관련 오류: 기기 시간, SNI, 서버 인증서 체인을 확인하세요. 도메인이 정상적으로 확인되더라도 인증서 검증에 성공했다는 뜻은 아닙니다.
• 인증 실패 메시지가 표시됨: 인증값 전체와 공백, 구독 업데이트 결과를 확인하세요. Obfs를 사용한다면 양쪽 설정값도 일치하는지 확인해야 합니다.
• 연결은 성공했지만 특정 사이트에 접속할 수 없음: 먼저 Global Routing과 규칙 일치 여부를 확인한 다음 대상의 이름 확인과 서버의 외부 접속 가능 여부를 점검하세요. 프로토콜 연결 성공은 경로의 일부가 연결되었다는 뜻일 뿐입니다.
• 다운로드는 빠르지만 상호작용이 끊김: 다른 대용량 작업을 중지하고 대역폭 목표를 낮춘 뒤 같은 테스트를 반복해 지연 변동이 줄어드는지 확인하세요.
• Wi-Fi에서는 정상이고 셀룰러에서는 문제가 발생함: UDP 연결 가능 여부, 신호, 네트워크 경로의 차이를 비교하세요. 한 네트워크에서 발생한 문제를 바로 비밀번호 오류로 단정하지 마세요.