Hysteria2의 잠재적 장점은 QUIC의 전송 방식과 대역폭을 고려한 혼잡 제어에서 비롯되며, UDP 자체가 속도를 보장하는 것은 아닙니다. 이미 서버 설정값이나 구독 정보를 보유한 사용자를 위해 네트워크 조건, 인증 및 TLS 매개변수, Shadowrocket 설정 절차와 UDP 연결 불가·인증서 오류·규칙 라우팅 문제를 구분하는 방법을 차례로 설명합니다. 먼저 연결이 성립하는지 확인한 뒤 처리량을 살펴보세요.
Hysteria2, QUIC, UDP는 각각 어떤 역할을 하나요?
Shadowrocket의 Hysteria2는 프록시 프로토콜 옵션 중 하나입니다. QUIC를 기반으로 하며, QUIC 패킷은 UDP를 통해 전달됩니다. 세 이름은 같은 뜻이 아닙니다. UDP는 데이터그램 전송을 제공하고, QUIC는 그 위에서 암호화와 연결 관리, 신뢰성 있는 스트림을 구현합니다. Hysteria2는 여기에 프록시 인증, 요청 전달 및 관련 전송 동작을 정의합니다. 서버가 해당 프로토콜을 지원해야 하며, 기존 항목의 Type만 Hysteria2로 바꾼다고 변환되는 것은 아닙니다.
UDP 자체는 데이터의 도착이나 순서를 보장하지 않지만, Hysteria2로 웹을 이용할 때 페이지 내용이 손실된다는 뜻은 아닙니다. 신뢰성 있는 전송이 필요한 데이터는 QUIC의 스트림 기능이 확인과 재전송을 담당합니다. 프록시의 UDP 트래픽은 데이터그램 방식으로 전달할 수 있으며, 이는 신뢰성 있는 바이트 스트림과 의미가 다릅니다. 프로토콜 성능을 판단할 때는 외부 전송 방식과 내부 애플리케이션이 실제로 사용하는 연결을 구분해야 합니다.
포트는 사용 중인 서비스 설정값을 기준으로 해야 합니다. 숫자가 같아도 TCP 포트와 UDP 포트는 서로 다른 전송 프로토콜에 속합니다. 서버의 TCP 443에 접속할 수 있다고 해서 UDP 443도 사용 가능하다는 뜻은 아닙니다. 일반 웹페이지가 열린다는 사실은 해당 웹페이지가 사용한 경로가 작동한다는 것만 보여 줄 뿐, Hysteria2 핸드셰이크를 확인해 주지는 않습니다.
고지연·패킷 손실이 있는 네트워크에서 효과를 볼 수 있는 이유
네트워크 처리량은 표시된 대역폭뿐 아니라 왕복 지연 시간, 패킷 손실, 전송 윈도우와 혼잡 제어의 영향을 받습니다. 패킷 손실을 기준으로 동작하는 기존 제어 방식은 무선 간섭으로 발생한 일시적 손실도 혼잡으로 판단해 전송 속도를 낮출 수 있습니다. Hysteria2의 자체 혼잡 제어는 이런 조건에서 네트워크 용량을 더 적극적으로 활용하려는 방식입니다. 실제로 이 기능이 적용되는지와 효과는 클라이언트, 서버, 대역폭 협상 설정에 따라 달라집니다.
QUIC의 멀티스트림 기능은 스트림 간 전송 계층의 HOL 블로킹을 줄입니다. 한 스트림에서 손실된 데이터의 재전송을 기다리더라도 같은 순서형 바이트 스트림의 누락 때문에 다른 모든 스트림이 바로 막히지는 않습니다. 하지만 패킷 손실 자체가 사라지는 것은 아닙니다. 신뢰성 있는 스트림 하나는 누락된 데이터가 복구될 때까지 기다려야 하며, 여러 스트림은 여전히 네트워크 용량과 혼잡 상태를 공유합니다. 따라서 “QUIC를 사용하면 어떤 네트워크에서나 더 빠르다”고 단정할 수 없습니다.
- 지연 시간이 길고 일시적 패킷 손실이 있는 경우: UDP에 연결할 수 있고 서버 리소스가 충분하다면, 더 적극적인 전송 방식이 지속적인 데이터 전송의 처리량을 개선할 수 있습니다.
- 지연 시간이 짧고 패킷 손실이 적은 경우: 병목이 이미 접속 대역폭, 서버의 외부 회선 또는 대상 사이트에 있다면 프로토콜을 바꿔도 체감할 만한 차이가 없을 수 있습니다.
- 실제 네트워크 혼잡이 발생한 경우: 전송량을 더 늘리면 대기열, 지터와 패킷 손실이 증가할 수 있습니다. 모든 손실을 무선 간섭 탓으로 돌려서는 안 됩니다.
- UDP가 차단되거나 속도 제한을 받는 경우: 핸드셰이크 시간 초과가 발생하거나 연결 후에도 전송이 제한될 수 있습니다. 프로토콜 기능으로 네트워크 경로의 제한을 없앨 수는 없습니다.
결론: 대역폭을 조정하기 전에 UDP 연결부터 확인하세요
연결이 계속 핸드셰이크 단계에서 멈춘다면 서버 주소, UDP 포트와 사용 중인 네트워크부터 확인하세요. 연결 가능성 문제를 대역폭 수치를 높여 해결하려고 하지 마세요. 연결이 안정적으로 성립한 뒤에야 처리량과 지연 시간을 비교할 수 있습니다.
매개변수를 입력하기 전에 주소, 인증, TLS를 구분하세요
Hysteria2 항목에는 올바른 서버 주소, 포트와 인증 정보가 필요합니다. TLS 신원 확인, 위장 설정과 대역폭 옵션은 기존 서비스 설정과 일치해야 합니다. 구독에 포함된 매개변수는 확인의 기준으로 삼고, 경험만으로 전부 덮어쓰지 마세요. 특히 서버 연결 주소, 인증서 이름과 인증 비밀번호는 서로 바꿔 쓸 수 있는 항목이 아닙니다.
| 매개변수 | 입력 및 확인 방법 | 흔히 하는 오해 |
|---|---|---|
| 서버 주소 및 Port | 기존 설정에 따라 도메인 또는 IP 주소와 해당 UDP 포트를 입력합니다. 포트 번호 범위는 1–65535입니다. | 모든 서비스가 443을 사용한다고 여기거나, TCP 연결 가능 여부를 UDP 연결 가능 여부와 같다고 판단합니다. |
| 인증 정보 | 대소문자와 모든 문자를 그대로 입력합니다. 서비스에서 조합 형식을 요구하면 원래 형식에 맞춰 입력하세요. | 조합 인증의 일부만 입력하거나 복사하는 과정에서 공백이나 줄바꿈이 포함됩니다. |
| SNI 및 인증서 | 서비스 설정에 따라 TLS 이름을 입력하고 인증서 및 연결 대상과의 관계를 확인합니다. | IP 주소를 직접 입력한 뒤 이름 불일치가 발생하자 인증서 검증을 끕니다. |
| 위장 설정 | 서버에서 요구하는 경우에만 설정합니다. 예를 들어 Salamander를 사용한다면 양쪽의 유형과 비밀번호가 일치해야 합니다. | 위장 설정을 임의로 추가하거나 위장 비밀번호를 인증 비밀번호로 착각합니다. |
| 대역폭 | 실제로 사용할 수 있는 업로드·다운로드 대역폭과 서비스 설정을 기준으로 입력하고, 화면에 표시된 단위를 확인합니다. | 수치를 속도 향상 배수로 여기거나 Mbps와 MB/s를 혼동합니다. |
예를 들어 기존 설정에서 연결 주소는 IP, TLS 신원은 도메인으로 되어 있다면 주소 입력란과 SNI가 서로 다른 것이 정상일 수 있습니다. 이 경우 원래 매개변수를 확인하고 억지로 일치시키지 마세요. 인증서 오류가 발생하면 시스템 시간, SNI, 인증서 유효 기간과 서비스 설정을 먼저 확인하세요. 인증서 검증은 켜 둔 상태로 유지하고, 검증을 건너뛰어 오류를 가리지 마세요.
Shadowrocket에 항목을 추가하고 처음으로 설정을 확인하기
아래 절차는 본인의 Hysteria2 설정값을 이미 확보한 경우를 전제로 합니다. 기존 구독을 사용한다면 Home 오른쪽 위의 “+”를 누르고 Type을 Subscribe로 설정한 다음 본인의 구독 링크를 입력해 저장하세요. 업데이트 후 생성된 항목의 Type과 매개변수를 확인합니다. 구독을 가져오지 못하는 문제와 Hysteria2 핸드셰이크 실패는 서로 다른 문제입니다. 전자는 설정을 가져오는 단계에서, 후자는 항목을 선택해 연결하는 단계에서 발생합니다.
-
기존 설정값 확인
주소, UDP 포트, 인증 정보와 서비스에서 요구하는 SNI, 위장 설정 및 대역폭 값을 미리 준비하세요. 기존 Hysteria 설정값을 Hysteria2에도 그대로 적용할 수 있다고 가정하지 마세요.
-
항목 추가
Home에서 오른쪽 위의 “+”를 누르고 Type으로 이동해 Hysteria2를 선택합니다. 기존 서버 주소와 Port를 입력한 다음 숫자가 빠지거나 한 자리 더 입력되지 않았는지 확인하세요.
-
인증 정보 입력
인증 정보를 빠짐없이 복사하고 원래 설정에 따라 위장 옵션을 입력합니다. 인증 비밀번호와 위장 비밀번호를 따로 확인하세요. 두 항목 모두 비밀번호를 요구한다고 같은 값을 입력하면 안 됩니다.
-
TLS 확인
SNI와 인증서 검증 설정을 확인하고, 대역폭 옵션은 화면에 표시된 단위에 맞춰 입력합니다. 기존 구독에 이미 해당 매개변수가 설정되어 있다면 처음 테스트할 때 여러 변수를 동시에 바꾸지 않도록 원래 값을 유지하세요.
-
저장하고 테스트
저장한 뒤 Home으로 돌아가 해당 항목을 선택하고 Global Routing을 확인한 다음 연결을 켭니다. 처음 연결할 때는 시스템 안내에 따라 VPN 구성을 추가하도록 허용하세요. 이후 지연 시간 수치만 보지 말고 실제 웹 요청으로 연결을 확인합니다.
구독을 업데이트하면 구독에서 생성된 항목이 달라질 수 있습니다. 혼동을 줄이려면 테스트 전에 현재 매개변수와 구독 업데이트 시점에 관한 안내를 기록해 두세요. 수동으로 조정했다면 업데이트 후 다시 확인합니다. 문제 해결 정보를 공유할 때는 인증 정보와 구독 token을 숨기고 오류 유형, 네트워크 종류와 포트만 남기세요. 전체 자격 증명을 공개 게시물에 올려서는 안 됩니다.
문제 해결 시 Global Routing 선택 방법
프로토콜 연결, 라우팅 모드와 규칙 일치는 서로 다른 단계의 문제입니다. Home에서 Hysteria2 항목을 선택해도 모든 요청이 그 항목을 사용하는 것은 아닙니다. Global Routing과 Config의 정책에 따라 요청이 DIRECT로 나가거나 다른 정책을 사용할 수 있습니다. 특정 항목을 점검할 때는 먼저 규칙의 영향을 줄인 뒤 일상적으로 사용하는 설정으로 되돌리세요.
Proxy: 규칙 변수 분리
권장짧게 문제를 점검할 때는 Proxy를 사용하고, 테스트할 Hysteria2 항목이 현재 선택되어 있는지 확인하세요. 클라이언트가 처리하는 연결을 프록시 모드로 전달하므로 Config 규칙의 영향을 줄이는 데 도움이 됩니다. 단, LAN 제외와 같은 별도 설정도 확인해야 합니다.
적합한 경우: 처음 설정을 검증하거나 프로토콜과 규칙 문제를 구분할 때
Config: 일상적인 라우팅 확인
연결이 정상임을 확인한 뒤 Config로 전환해 실제 요청에 적용된 규칙과 정책을 확인합니다. DOMAIN-SUFFIX, IP-CIDR, GEOIP 등의 규칙이 연결 경로를 결정하며, FINAL은 앞선 규칙에 일치하지 않았을 때 적용되는 최종 정책입니다.
적합한 경우: 규칙을 이미 설정했거나 대상별 라우팅이 필요할 때
Direct: 직접 연결 기준 확인
Direct는 직접 연결이 정상인지 확인하는 모드이며 Hysteria2 항목이 작동한다는 증거로 사용할 수 없습니다. 이 모드에서 웹페이지가 열린다면 해당 직접 연결 요청이 성공했다는 뜻일 뿐, 프록시 핸드셰이크가 완료됐다고 판단할 수는 없습니다.
적합한 경우: 로컬 접속 네트워크와 대상 사이트의 직접 연결 상태를 비교할 때
Proxy에서는 접속되지만 Config로 돌아온 뒤 특정 요청이 실패한다면 Hysteria2 비밀번호부터 바꾸지 말고 Config의 규칙 순서와 대상 정책을 확인하세요. 규칙은 위에서 아래 순서로 적용되므로 앞쪽의 포괄적인 규칙이 뒤쪽의 세부 규칙보다 먼저 일치할 수 있습니다. FINAL은 규칙 목록의 마지막에 있어야 합니다. PROXY가 테스트 당시와 동일한 항목이나 정책 그룹을 실제로 사용하는지도 확인하세요.
자주 발생하는 문제: 먼저 단계를 파악하고 한 번에 변수 하나만 변경하세요
“연결 스위치가 켜짐”, “지연 시간 테스트에 값이 표시됨”, “대상 웹페이지가 열림”은 각각 다른 상태를 나타냅니다. 시스템의 VPN 연결 상태가 모든 원격 연결의 성공을 뜻하지 않으며, 한 번의 지연 시간 테스트로 지속적인 전송 성능을 알 수도 없습니다. 아래 안내는 관찰 가능한 증상을 기준으로 하며, 원인이 반드시 프로토콜에 있다고 가정하지 않습니다.
Wi-Fi에서는 계속 시간 초과가 발생하지만 셀룰러 네트워크에서는 작동하나요?
같은 항목, 같은 포트, 같은 대상 요청을 유지한 채 접속 네트워크만 바꿔 테스트하세요. 차이가 반복해서 나타난다면 Wi-Fi 경로의 UDP 연결 가능 여부, 속도 제한 또는 방화벽 정책을 우선 확인하세요. 같은 설정이 다른 네트워크 경로에서는 이미 연결되었으므로 비밀번호부터 바꾸지 마세요. 셀룰러 데이터 사용량에도 유의하세요.
인증서 또는 TLS 오류가 표시되면 검증을 꺼야 하나요?
먼저 기기 시간, 항목의 SNI와 기존 서비스 설정을 확인한 다음 도메인이 예상한 주소로 해석되는지 확인하세요. 이름 불일치나 인증서 만료는 해당 설정을 수정해야 합니다. 인증서 검증을 끄는 것을 일반적인 문제 해결 절차로 삼지 말고, 핸드셰이크 시간 초과를 모두 인증서 오류로 간주하지 마세요.
작은 웹페이지는 잘 열리는데 대용량 파일 전송은 자주 멈추나요?
먼저 지나치게 높게 설정된 대역폭 값을 낮춘 다음 같은 네트워크에서 동일한 요청을 다시 테스트하세요. 문제가 계속 재현되면 발생 시점을 기록하고 경로 MTU, UDP 조각화 및 속도 제한 조건을 확인하세요. 이 증상만으로 MTU를 바로 변경하지 마세요. 서버의 외부 회선과 대상 사이트 자체의 제한도 배제해야 합니다.
수동 연결은 정상인데 자동 연결이 예상대로 작동하지 않나요?
Settings → On Demand에서 스위치와 설정된 네트워크 트리거 조건을 확인하고 현재 Wi-Fi 또는 셀룰러 환경이 조건에 맞는지 점검하세요. 프로토콜을 테스트할 때는 자동 연결 해제나 재연결이 관찰을 방해하지 않도록 먼저 수동으로 연결합니다. 프로토콜과 라우팅이 정상임을 확인한 후 On Demand를 따로 테스트하세요.
성능을 비교할 때는 기기, 접속 네트워크, 항목, 대상 리소스와 테스트 시간을 동일하게 유지하고 매 회차 한 가지 매개변수만 변경하세요. 핸드셰이크 완료 여부, 웹페이지의 첫 응답이 나타나는 시점, 지속 전송의 안정성, 부하에 따라 지연 시간이 크게 늘어나는지를 각각 기록합니다. 대상 사이트가 서로 다른 다운로드 두 건만으로 특정 프로토콜이 항상 얼마나 더 빠른지 결론 내리지 마세요.
- 먼저 확인: 주소, UDP 포트, 인증, TLS와 위장 설정이 기존 설정과 일치하는지 확인합니다.
- 그다음 분리: 수동 연결과 명확한 Global Routing 모드를 사용해 자동화 및 규칙의 영향을 배제합니다.
- 마지막으로 비교: 반복 가능한 조건에서 처리량과 지터를 살펴보고 설정 변경이 실제로 사용 경험을 개선했는지 확인합니다.