Hysteria2는 QUIC 기반 프록시 프로토콜이지, 모든 네트워크를 빠르게 만드는 만능 설정이 아닙니다. iPhone, iPad 또는 다른 플랫폼에서 Shadowrocket을 사용하고 이미 이용 중인 서비스와 구독 정보가 있는 사용자를 위한 안내입니다. 먼저 UDP 연결 가능 여부를 확인하고 연결 매개변수를 점검한 뒤, 동일한 조건에서 패킷 손실과 대역폭, 규칙이 각각 어떤 영향을 미치는지 살펴봅니다.
Hysteria2, QUIC, UDP의 관계
Hysteria2는 QUIC을 사용해 클라이언트와 서버 사이에 전송 연결을 설정하고, QUIC은 UDP를 기반으로 동작합니다. 여기서 UDP는 양 끝단 사이의 외부 전송 방식을 뜻하며, 웹 요청 자체가 신뢰성 없는 데이터 전송으로 바뀐다는 의미는 아닙니다. QUIC은 스트림에 확인 응답, 재전송, 흐름 제어, 암호화 등의 기능을 제공하고, Hysteria2는 이를 바탕으로 프록시 요청을 전달합니다.
일반적인 웹 접속에는 TCP가 자주 사용됩니다. Hysteria2로 전달할 때는 이러한 애플리케이션 연결이 QUIC 스트림을 통해 전송될 수 있으며, 애플리케이션에서 발생한 UDP 데이터도 프로토콜이 지원하는 방식으로 전달할 수 있습니다. 따라서 “서버가 TCP 연결을 받을 수 있다”는 것과 “Hysteria2 연결에 성공한다”는 것은 별개의 문제입니다. 외부 전송 경로에서 UDP가 통하는지 따로 확인해야 합니다.
이미 사용 중인 서버의 수신 포트가 443이라면 방화벽에서 해당 443/UDP를 허용해야 합니다. 443/TCP만 열어 두는 것으로는 부족합니다. 실제 연결에는 서비스 제공자가 안내한 포트를 사용해야 하며, 웹에서 443을 자주 쓴다는 이유로 구독 정보에 있는 다른 포트를 모두 443으로 바꾸면 안 됩니다.
패킷 손실이 많은 환경에서 더 안정적일 수 있는 이유
패킷이 손실되면 다시 전송해야 하는 데이터가 늘고 복구 대기 시간이 길어져 다운로드가 끊기기 쉽습니다. 기존 TCP의 혼잡 제어는 네트워크 응답에 따라 전송 속도를 조절합니다. 패킷 손실은 실제 혼잡 때문일 수도 있고 무선 간섭 같은 링크 문제에서 비롯될 수도 있습니다. 두 경우 모두 전송 속도를 낮추는 방식이 항상 가용 대역폭을 충분히 활용하는 것은 아닙니다.
Hysteria2의 전송 설계는 혼잡이 아닌 패킷 손실이 발생하고 왕복 지연 시간이 긴 일부 경로에서 비교적 적극적인 전송 흐름을 유지할 수 있습니다. QUIC의 독립 스트림 구조는 신뢰성 있는 전송의 순서 처리 때문에 서로 다른 스트림이 함께 막히는 현상도 줄여 줍니다. 다만 여러 스트림은 여전히 같은 경로와 연결 자원을 공유합니다. 손실 후 재전송, 서버 부하, 출구 용량도 그대로이므로 “패킷 손실이 많을수록 더 빨라진다”고 이해해서는 안 됩니다.
- 무선 간섭으로 간헐적인 패킷 손실 발생: UDP 연결이 가능하고 링크에 여유가 있다면 기존 전송 방식보다 처리량이 더 안정적으로 유지될 수 있습니다.
- 지역 간 경로의 높은 지연 시간: 대역폭 활용률은 개선될 수 있지만, 광섬유 전송 거리와 우회 라우팅으로 생기는 기본 지연 시간은 줄어들지 않습니다.
- 접속 회선이 이미 혼잡한 경우: 전송량을 늘리면 대기열과 패킷 손실이 증가해 웹 응답이나 통화 품질이 오히려 나빠질 수 있습니다.
- 무선 신호가 계속 나빠지는 경우: 재전송에도 무선 자원이 필요하므로 프로토콜을 바꾸는 것만으로 Wi-Fi 음영 지역 문제를 해결할 수는 없습니다.
결론: 패킷 손실과 혼잡을 먼저 구분하세요
다운로드 중 직접 연결한 웹페이지도 눈에 띄게 느려진다면 먼저 동시 연결 수를 줄이고 로컬 네트워크와 대역폭 설정을 확인하세요. 전송 대역폭을 계속 높이는 것을 기본 해결책으로 삼지 마세요.
Hysteria2를 사용하기 어려운 네트워크
사용 가능 여부를 판단할 때 먼저 확인할 것은 속도 측정 결과가 아니라 UDP 패킷이 안정적으로 왕복하는지입니다. 일부 방문자용 네트워크, 회사 네트워크, 공용 핫스팟은 UDP를 제한합니다. 특정 UDP 서비스만 허용하거나 장시간 대량 UDP 트래픽을 제한하는 네트워크도 있습니다. 도메인 이름이 확인되고 HTTPS 웹페이지가 열리거나 ping이 낮게 나와도 대상 포트의 UDP를 사용할 수 있다는 뜻은 아닙니다.
| 관찰되는 현상 | 가능한 원인 | 다음 확인 방법 |
|---|---|---|
| Wi-Fi에서 연결 시간 초과, 셀룰러 네트워크에서는 연결 가능 | Wi-Fi 출구에서 UDP를 제한하거나 두 경로의 라우팅이 다름 | 설정을 그대로 두고 네트워크만 바꿔 다시 연결 |
| 짧은 요청은 되지만 다운로드를 계속하면 속도가 떨어짐 | UDP 속도 제한, 서버 혼잡, 기기 온도 또는 신호 변화 | 속도가 떨어진 시점을 기록하고 같은 시간대의 직접 연결 상태도 확인 |
| 작은 요청은 정상이나 큰 요청은 자주 멈춤 | 경로 MTU, 단편화 처리 또는 패킷 손실 문제 | 먼저 서비스 제공자가 안내한 매개변수를 확인한 뒤 경로와 로그를 점검 |
| TCP 포트 테스트는 성공했지만 Hysteria2는 계속 시간 초과 | 테스트에서 대상 UDP 포트를 확인하지 않음 | 서버의 UDP 수신 설정과 방화벽 규칙 확인 |
한 번 멈췄다고 MTU 문제로 단정하지 마세요. 경로 일부에서 큰 데이터그램을 제대로 처리하지 못하면 특정 요청이 멈출 수 있지만, 인증서 오류나 인증 실패, DNS 문제도 사용자는 “접속이 안 된다”고 표현할 수 있습니다. 먼저 로그를 확인해 핸드셰이크 실패와 전송 중단을 구분한 다음, 서비스 제공자에게 경로 점검을 요청할지 결정하세요.
Shadowrocket에서 매개변수 확인 및 테스트
아래 절차는 iPhone/iPad의 Home, Config, Settings 화면을 기준으로 합니다. Mac, Windows, Android, Linux 사용자도 같은 방식으로 매개변수를 확인하고 네트워크별 결과를 비교할 수 있습니다. 구체적인 컨트롤 위치는 현재 플랫폼 화면을 기준으로 확인하세요. 작업 전에 현재 사용 가능한 설정을 보관하고, 테스트에는 이미 보유하고 사용할 권한이 있는 서버 정보만 사용하세요.
-
기존 구독 업데이트
Home에서 기존 구독을 찾아 업데이트하세요. 새로 추가하려면 Home → “+” → Type → Subscribe로 이동해 본인의 구독 URL을 입력하고 저장합니다. 구독 내용과 접속 정보가 공개 스크린샷이나 게시물에 노출되지 않도록 주의하세요.
-
프로토콜 매개변수 확인
Home에서 대상 항목의 편집 화면을 열고 Type이 Hysteria2인지 확인한 다음 서버 주소, 포트, 인증 정보, TLS 관련 설정을 하나씩 점검하세요. Hysteria와 Hysteria2는 임의로 서로 바꿔 사용할 수 있는 유형이 아닙니다.
-
인증서 이름 확인
연결 주소가 IP이고 인증서가 도메인에 발급된 경우 서비스 제공자가 안내한 SNI를 확인하세요. 혼잡 방지를 위한 obfuscation을 사용하는 경우 양쪽의 유형과 비밀번호가 일치해야 합니다. 인증서 검증을 함부로 끄는 것으로 매개변수 오류를 대신 해결해서는 안 됩니다.
-
규칙의 영향 분리
대상 연결을 선택한 뒤 잠시 Home → Global Routing을 Proxy로 전환하고 연결해 고정된 테스트 리소스에 접속합니다. 이렇게 하면 분할 라우팅 규칙의 영향을 줄일 수 있지만, 설정에서 다른 규칙이 동작을 덮어쓰는지는 확인해야 합니다.
-
평소 설정으로 복원
테스트가 끝나면 Global Routing을 평소 사용하는 Config로 되돌리고 Config에서 기존 설정이 활성화되어 있는지 확인하세요. 문제 해결을 위해 Settings → On Demand에서 자동 연결 동작을 바꿨다면 이 설정도 복원하세요.
구독 업데이트 성공은 클라이언트가 구독 내용을 가져와 해석했다는 뜻일 뿐, 구독에 포함된 모든 서버에 연결할 수 있다는 의미는 아닙니다. 서비스 제공자가 인증 정보나 인증서를 변경한 경우 직접 복사해 둔 이전 항목에는 변경 사항이 반영되지 않을 수도 있습니다. 인증 실패가 발생하면 관련 없는 규칙을 반복해서 수정하지 말고 항목의 출처와 업데이트 결과부터 비교하세요.
프로토콜을 잘못 판단하지 않도록 Global Routing 선택하기
Hysteria2는 연결을 전송하는 방식을 담당하고, Global Routing은 요청에 적용할 라우팅 방식을 정합니다. 두 기능은 서로 다른 계층에 있습니다. Global Routing의 Proxy, Direct, Config, Scene도 네 가지 프록시 프로토콜이 아닙니다. 프로토콜을 테스트할 때 요청이 실제로 Direct로 나갔다면 웹페이지가 빨리 열려도 Hysteria2의 속도 결과로 볼 수 없습니다.
Config: 설정에 따라 라우팅
권장현재 설정의 규칙과 정책에 따라 트래픽을 전달합니다. DIRECT에 일치하는 요청은 직접 연결되고, 프록시 정책에 일치하는 요청은 해당 연결을 사용합니다. 일치하지 않는 요청은 FINAL 등의 설정에 따라 처리되며 반드시 직접 연결되는 것은 아닙니다.
적합한 경우: 규칙 설정이 이미 있고 일상적인 분할 라우팅이 필요한 경우
Proxy: 분할 라우팅의 영향 배제
프록시를 기본 라우팅 방식으로 설정해 선택한 연결이 작동하는지 잠시 확인합니다. 테스트 요청이 실제로 어디로 전달되는지 확인해 정책 선택이나 다른 설정의 덮어쓰기 때문에 결과가 달라지지 않도록 하세요.
적합한 경우: 연결 테스트, “규칙이 예상과 다르게 적용되는” 문제 확인
Direct: 직접 연결 기준 확인
직접 연결 결과를 확인해 로컬 네트워크가 이미 혼잡한지 살펴봅니다. 원래 직접 접속할 수 있는 동일한 리소스끼리만 비교하세요. 직접 연결할 수 없는 대상을 기준으로 로컬 네트워크 전체의 문제를 판단해서는 안 됩니다.
적합한 경우: Wi-Fi 상태 비교, 프록시 경로 문제 여부 확인
Scene은 설정된 조건에 따라 라우팅 방식을 적용하는 기능이므로, 처음 문제를 해결할 때 변수를 늘리는 용도로 사용하지 않는 것이 좋습니다. 규칙에서는 DOMAIN-SUFFIX가 도메인 접미사를, IP-CIDR이 IP 주소 대역을, GEOIP가 IP 지리 데이터베이스를 기준으로 일치 여부를 판단하며 FINAL은 기본 처리 규칙을 담당합니다. 프로토콜만 바꾸기보다 규칙 순서와 대상 정책을 확인하는 편이 “일부 사이트는 되지만 다른 사이트는 안 되는” 원인을 파악하는 데 도움이 됩니다.
순간 최고 속도 대신 속도를 비교하는 방법
Hysteria2의 성능은 혼잡 제어 방식, 가용 대역폭, 서버 측 제한에 함께 영향을 받습니다. 연결 설정에 업로드 및 다운로드 대역폭 항목이 있다면 현재 접속 네트워크와 서비스 제공자의 요구사항에 맞춰 입력하세요. 업로드는 기기에서 서버로 보내는 속도이고 다운로드는 서버에서 기기로 돌아오는 속도입니다. Mbps와 MB/s도 구분해야 합니다. MB/s 값을 8배 하면 Mbps로 환산할 수 있습니다.
가정용 인터넷의 표시 다운로드 속도를 모든 네트워크 환경의 전송 목표로 그대로 입력하지 마세요. 셀룰러 네트워크로 바꾸면 사용 가능한 업로드 대역폭이 달라질 수 있습니다. 목표를 지나치게 높게 설정하면 확인 응답이나 다른 앱이 사용할 대역폭을 잠식할 수 있고, 너무 낮게 설정하면 처리량이 제한될 수 있습니다. 입력 필요 여부와 매개변수 적용 방식은 현재 연결 설정과 서버 요구사항을 확인하세요.
- 조건 고정: 같은 기기, 같은 네트워크, 같은 테스트 리소스를 사용하세요. 서버 위치와 출구가 다른 두 연결의 결과를 프로토콜 이름만으로 설명할 수는 없습니다.
- 반복 측정: 각 조건에서 60초씩 3회 연속 테스트하고, 최고 순간 속도만 기록하지 말고 안정 구간의 처리량과 끊김 횟수를 기록하세요.
- 응답 속도도 함께 확인: 다운로드 중 원래 직접 접속할 수 있는 웹페이지를 열어 대기열이 눈에 띄게 늘어나는지 확인하세요. 다운로드 속도가 높아져도 다른 요청이 계속 멈춘다면 전반적인 개선으로 볼 수 없습니다.
- 네트워크별로 기록: Wi-Fi와 셀룰러 네트워크 결과를 따로 기록하세요. 네트워크를 바꿀 때는 연결을 새로 설정해 기존 연결의 전환 과정이 결과에 섞이지 않도록 합니다.
- 오류 유형을 기록: 시간 초과, 인증 실패, 인증서 검증 실패 등 실제 표시되는 메시지를 기록하세요. 기록을 공유할 때는 서버 인증 정보와 구독 URL을 가리세요.
결론: 최고 속도보다 연결 가능 여부가 우선
같은 설정에서 현재 네트워크를 사용할 때 UDP 핸드셰이크 시간 초과가 반복되지만 네트워크를 바꾸면 안정적으로 연결된다면, 먼저 네트워크 제한을 해결하거나 이미 이용 중인 서비스에서 해당 네트워크에 맞는 다른 연결 방식을 사용하세요. 대역폭 값을 계속 높여 가며 시험하지 마세요.
자주 묻는 질문과 문제 해결 범위
Hysteria2를 쓰면 게임 지연 시간이 반드시 줄어드나요?
아닙니다. 게임 지연 시간은 게임 서버와 프록시 출구의 위치, 우회 경로, 대기열 상태에도 영향을 받습니다. 다운로드가 더 안정적이라고 해서 작은 데이터 패킷의 왕복 속도도 빨라지는 것은 아닙니다. 다운로드 속도로 판단하지 말고 게임을 실제로 실행하면서 지연 시간 변화와 패킷 손실을 확인하세요.
연결에 실패하면 TLS 검증을 꺼야 하나요?
검증을 끄는 것을 일반적인 해결 방법으로 삼지 마세요. 먼저 기기 시간, 서버 주소, SNI, 인증서에 포함된 이름을 확인하고 서버 인증서가 유효한지 점검하세요. 인증서 검증은 서버 신원을 확인하는 기능입니다. 검증을 우회하면 설정 오류를 가리고 연결 보안도 약화할 수 있습니다.
On Demand를 켜면 UDP 제한을 해결할 수 있나요?
아닙니다. Settings → On Demand는 요청 시 연결을 시작하는 조건을 관리할 뿐, 통신사가 UDP를 허용하는 규칙을 바꾸지는 않습니다. 자동 재연결로 연결을 다시 시도할 수는 있지만 차단된 전송 경로를 사용할 수 있게 만들지는 못합니다.
프로토콜은 현재 경로의 연결 가능성, 안정성, 허용 가능한 자원 사용량을 기준으로 선택해야 합니다. Shadowrocket은 클라이언트이며 연결 매개변수는 사용자가 이미 이용 중인 서비스에서 제공됩니다. 이 사이트는 사용자가 이미 보유한 구독의 설정 방법만 안내하며 연결 서비스를 제공하지 않습니다. 매개변수가 부족하다면 기존 서비스 제공자에게 확인하세요. 비밀번호, 구독 토큰, 인증 정보를 추측 가능한 설정값처럼 다루지 마세요.