UDP 연결이 가능한 환경에서 Hysteria2를 사용해 지연 시간이 길고 패킷 손실이 발생하는 네트워크를 실제로 비교해 볼 수 있습니다. 모든 네트워크에서 더 빠른 것은 아닙니다. 이미 자체 서비스 제공업체 정보나 구독을 보유한 사용자를 대상으로 QUIC, 혼잡 제어, 대역폭 설정의 관계를 설명합니다. 이어서 Shadowrocket에서 서버를 추가할 때 주소, 인증 정보, TLS, 선택적 난독화 설정을 확인하고, 단계별 점검으로 전송 오류와 규칙 문제를 구분합니다.
Hysteria2와 QUIC·UDP의 관계
Shadowrocket의 Hysteria2는 프록시 프로토콜 유형 중 하나입니다. 클라이언트와 서버는 UDP 기반 QUIC 연결로 데이터를 주고받으며, 서버가 목적지 주소에 연결합니다. 여기서 UDP는 클라이언트와 서버 사이의 외부 전송 방식을 뜻합니다. 브라우저로 접속하는 모든 웹사이트가 UDP를 사용한다는 의미도 아니고, 앱에서 발생한 TCP 데이터를 신뢰성 있는 전송 과정 없이 버려도 된다는 뜻도 아닙니다.
QUIC은 신뢰성 있는 전송, 스트림 관리, TLS 핸드셰이크를 결합합니다. 신뢰성 있는 전달이 필요한 데이터는 손실된 경우 복구해야 합니다. UDP 자체에는 재전송 기능이 없으며, 관련 기능은 QUIC이 구현합니다. Hysteria2는 TCP 연결과 UDP 데이터를 모두 전달할 수 있지만 방식은 서로 다릅니다. 따라서 ‘외부 전송에 UDP를 사용한다’는 사실을 ‘모든 업무 데이터가 반드시 전달된다’는 뜻으로 해석해서는 안 됩니다.
QUIC 멀티플렉싱은 한 스트림의 데이터 손실이 다른 스트림의 순서 있는 전달을 직접 막지 않도록 합니다. 다만 각 스트림은 연결의 혼잡 상태와 대역폭을 공유하므로 네트워크가 심하게 혼잡하면 모든 트래픽에 영향을 줄 수 있습니다. QUIC이 곧 HTTP/3을 뜻하는 것도 아닙니다. HTTP/3은 QUIC 기반의 애플리케이션 프로토콜이므로, 둘 다 QUIC을 사용한다는 이유만으로 용도가 같다고 볼 수 없습니다.
더 빠를 수 있는 이유: 혼잡 제어와 대역폭 추정
장거리 네트워크는 왕복 시간이 길기 때문에 가용 대역폭을 활용하려면 송신 측이 충분한 양의 데이터를 전송 중인 상태로 유지해야 합니다. 패킷 손실이 발생하면 신뢰성 있는 전송의 복구 절차가 작동하며, 일부 혼잡 제어 알고리즘은 이에 따라 전송 속도를 낮춥니다. 손실의 주된 원인이 네트워크 혼잡이 아니라 무선 간섭이라면 지나치게 속도를 낮춰 처리량이 떨어질 수 있습니다. Hysteria2는 이러한 환경에서 전송 방식을 조정하는 데 중점을 둡니다.
Hysteria2의 Brutal 혼잡 제어는 대역폭 목표를 주요 입력값으로 삼고 피드백에 따라 전송을 조정해 패킷 손실의 영향을 보완하려고 합니다. 실제로 어떤 제어 방식이 사용되는지는 양측 구현, 협상 결과, 대역폭 설정 등에 따라 달라집니다. Type이 Hysteria2라는 이유만으로 특정 제어 방식이 반드시 활성화된다고 단정할 수 없으며, QUIC 자체가 일정한 속도 향상을 보장하는 것도 아닙니다.
- 대역폭 목표가 너무 낮음: 네트워크에 여유가 있어도 설정에 따라 전송 속도가 제한될 수 있으며, 다운로드를 계속하면 비교적 일찍 속도 한계에 도달할 수 있습니다.
- 대역폭 목표가 너무 높음: 실제 네트워크 처리 능력을 넘어서는 양을 전송하면 대기열이 생기고 지연 시간과 패킷 손실이 늘어 웹 응답이나 실시간 서비스가 오히려 나빠질 수 있습니다.
- 업로드와 다운로드 속도 차이: 가정용 네트워크는 업로드 속도가 다운로드보다 크게 낮을 수 있습니다. 다운로드 속도 측정값을 업로드 목표에 그대로 입력하지 마세요.
- 단위 차이:
Mbps는 초당 메가비트,MB/s는 초당 메가바이트입니다. 예를 들어 오버헤드를 제외하면80 Mbps는 약10 MB/s입니다. 이는 단위 환산일 뿐 속도를 보장하는 수치가 아닙니다.
결론: 실제 측정한 네트워크에 맞춰 대역폭 설정
현재 설정에서 대역폭 입력을 지원하고 서비스 제공자가 해당 설정의 의미를 명확히 안내한 경우에만 조정하세요. 같은 네트워크에서 지속 전송한 결과를 기준으로 삼고, 인터넷 요금제의 최고 속도나 임의의 큰 값을 입력하지 마세요.
‘빠르다’는 말을 구체적으로 나눠 봐야 합니다. 웹페이지를 처음 열 때의 대기 시간, 지속 다운로드 처리량, 실시간 서비스의 지연 변동은 서로 다른 지표입니다. 지속 처리량이 늘어도 DNS 조회 시간이 짧아지는 것은 아니며, 목적지 서버의 응답 시간도 반드시 개선되는 것은 아닙니다. 지역 간 우회 경로, 서버 부하, 목적지 사이트의 속도 제한도 병목이 될 수 있습니다.
어떤 네트워크에 적합할까: 먼저 UDP 연결을 확인하고 실제 성능 비교
지연 시간이 길고 간헐적인 패킷 손실이 발생하면서 UDP 통신은 안정적으로 가능한 네트워크라면 Hysteria2를 테스트해 볼 만합니다. 셀룰러 신호 변동이나 혼잡한 Wi-Fi에서 패킷 손실이 생길 수 있지만, 셀룰러 네트워크라는 이유만으로 특정 프로토콜을 추천할 수는 없습니다. 장소와 시간대, 접속 네트워크에 따라 UDP 처리 방식이 다를 수 있으므로 실제 사용 장소에서 반복해서 테스트하세요.
| 네트워크 조건 | 예상되는 현상 | 확인 방법 |
|---|---|---|
| 지연 시간이 길고 간헐적인 패킷 손실 발생 | 지속 처리량이 비교적 잘 유지될 수 있지만 대역폭과 부하의 영향을 받습니다. | 같은 목적지를 지정하고 로딩 시간, 처리량, 끊김 횟수를 기록합니다. |
| UDP 차단 | 핸드셰이크가 시간 초과되거나 사용할 수 있는 연결이 설정되지 않습니다. | 서버의 UDP 수신 대기 상태, 방화벽, 현재 접속 네트워크를 확인합니다. |
| UDP 속도 제한 | 연결은 되지만 지속 전송 속도가 금방 제한에 도달합니다. | 직접 사용하는 Wi-Fi와 셀룰러 네트워크를 한 번에 하나씩 비교합니다. |
| 지연 시간과 패킷 손실이 적음 | 체감할 만한 이점이 없을 수도 있습니다. | 안정성, 서비스 응답, 기기 배터리 사용량 변화를 우선 비교합니다. |
각 테스트에서 같은 관찰 시간을 정할 수 있습니다. 예를 들어 60초 동안 전송하고 3회 반복하면서 네트워크 유형과 연결 중단 여부를 기록합니다. 이는 테스트 방법에 대한 제안이며 이 글에서 직접 측정한 결과가 아닙니다. 서버를 바꾸고 DNS와 규칙까지 동시에 수정하면 결과가 달라진 원인을 구분할 수 없으므로 한 번에 하나씩만 바꾸세요.
Shadowrocket 서버 추가 및 설정 항목 확인
다음 절차는 자체 서비스 제공업체와 구독 정보를 이미 보유한 경우를 전제로 합니다. 구독을 가져오면 직접 입력할 때 생길 수 있는 오류를 줄일 수 있지만, 가져온 뒤에도 프로토콜 유형과 각 항목이 빠짐없이 입력됐는지 확인해야 합니다. 앱의 항목 표시는 현재 화면에 따라 다를 수 있으므로 서비스에서 제공한 연결 정보를 항목별로 대응해 입력하세요. 다른 프로토콜의 설정을 대신 사용하지 마세요.
-
유형 확인
Home → 오른쪽 상단 ‘+’ → Type으로 이동한 다음 직접 설정할 경우 Hysteria2를 선택합니다. 기존 구독을 이용하려면 Type에서 Subscribe를 선택하고 본인의 구독 주소를 입력해 저장한 뒤, Home으로 돌아가 구독을 업데이트합니다. 가져온 항목을 열어 유형도 확인하세요.
-
주소 입력
보유한 정보를 바탕으로 Address와 Port를 입력합니다. Address는 서버의 호스트 이름 또는 IP이며 구독 주소가 아닙니다. Port에는 서버가 실제로 UDP 연결을 수신하는 포트를 입력하세요. 예를 들어 서버 포트가 443이면 443을 입력합니다. 웹에서 흔히 사용하는 포트라는 이유만으로 값을 임의로 변경해서는 안 됩니다.
-
인증 정보 확인
Password를 입력한 뒤 대소문자, 앞뒤 공백, 복사된 내용이 완전한지 확인합니다. Hysteria2 인증 정보는 해당 서버에서 제공한 값이어야 합니다. 구독 링크의 token을 연결 비밀번호로 사용하거나 다른 프로토콜의 인증 항목을 그대로 가져오지 마세요.
-
TLS 확인
현재 항목의 TLS 관련 설정을 펼쳐 SNI와 인증서 검증에 사용하는 이름을 보유한 정보와 대조합니다. Address에 IP를 입력했는데 인증서는 도메인 이름으로 발급된 경우 이름 설정을 특히 확인하세요. 검증 오류가 발생하면 인증서와 이름, 유효 기간을 점검합니다.
-
저장 후 테스트
항목을 저장하고 Home으로 돌아가 해당 항목을 선택한 다음 Global Routing의 현재 모드를 확인하고 연결합니다. 먼저 확실한 테스트 목적지를 열어 페이지가 완전히 로드되는지 확인한 뒤 지속 전송을 테스트하세요. 여러 설정값을 동시에 바꾸지 않도록 수정 전에 기존 값을 기록해 두세요.
서버에서 Salamander와 같은 선택적 난독화를 활성화한 경우 클라이언트 설정도 서버와 일치해야 합니다. 난독화 비밀번호와 연결 인증 비밀번호는 용도가 서로 다릅니다. 서버에서 활성화하지 않았다면 임의로 추가하지 마세요. 난독화를 설정해도 완전히 차단된 UDP 연결이 자동으로 복구되지는 않습니다.
- Address: 먼저 연결할 서버를 지정합니다. 도메인을 입력했다면 기기에서 해당 도메인을 조회할 수 있어야 합니다.
- SNI: TLS 핸드셰이크에 사용하는 서버 이름 표시 정보입니다. 기존 서버 설정과 일치해야 하며, 서버 주소를 대체하는 범용 설정이 아닙니다.
- 인증서 검증: 상대 서버의 신원이 예상한 대상과 일치하는지 확인합니다. 이름이 맞지 않으면 설정값이나 인증서를 수정해야 하며, 검증을 건너뛰는 것을 일반적인 해결 방법으로 삼아서는 안 됩니다.
- 선택 설정: 대역폭, 난독화, 포트 범위 등의 항목은 서비스에서 명확히 안내했고 현재 화면에서도 지원하는 경우에만 입력합니다. 기본값을 추측하거나 여러 포트를 무작정 시도하지 마세요.
연결 후 프로토콜 문제와 라우팅 문제 구분하기
항목을 저장했다고 인증까지 성공한 것은 아니며, 연결이 성공해도 특정 웹사이트가 해당 연결을 이용한다는 뜻은 아닙니다. Shadowrocket의 Global Routing에서 트래픽이 어떤 경로를 선택할지 결정합니다. 문제를 확인할 때는 먼저 Config, Proxy, Direct, Scene 중 현재 모드를 확인한 다음 테스트 요청에 실제로 적용된 규칙이나 Scene 설정을 확인하세요.
Config
권장현재 설정의 규칙에 따라 일상적으로 사용할 경로를 선택합니다. 테스트 전 목적지에 DIRECT 또는 프록시 정책 중 무엇이 적용되는지 확인하세요. Hysteria2를 거치지 않은 접속 결과를 프로토콜 성능으로 오해하지 않도록 주의합니다.
적합한 용도: 기존 규칙 설정을 이용한 일상적인 사용과 장기적인 관찰
Proxy
앱에서 처리하는 트래픽에 프록시 경로를 적용하면 규칙의 영향을 줄여 확인할 때 유용합니다. 그래도 선택한 항목과 목적지 연결 가능 여부를 확인해야 합니다. 이 방법만으로 DNS, 네트워크, 서버 문제까지 해결됐다고 판단해서는 안 됩니다.
적합한 용도: 선택한 연결로 목적지에 접속할 수 있는지 짧게 확인
Direct
앱에서 처리하는 트래픽에 직접 연결 경로를 적용하면 로컬 네트워크에서 원래 직접 접속할 수 있는 목적지에 연결되는지 확인하는 데 도움이 됩니다. 이 상태에서 접속에 성공해도 Hysteria2가 정상이라는 의미는 아닙니다.
적합한 용도: 로컬 네트워크와 목적지에 대한 기본 직접 연결을 비교
Scene을 사용한다면 현재 적용 중인 Scene의 설정을 확인하세요. Scene 이름만으로 프록시 동작을 단정해서는 안 됩니다. Config를 사용하는 경우 규칙은 위에서부터 순서대로 적용되므로 구체적인 조건을 앞에 두고 규칙 부분의 마지막에 FINAL을 배치합니다. 다음 예시는 문법 관계만 보여 주며, 그대로 덮어쓸 수 있는 완전한 설정이 아닙니다. 또한 현재 네트워크에서 해당 목적지에 접속할 수 있음을 의미하지 않습니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 주소 범위로, GEOIP는 IP 지리 데이터베이스를 기준으로 일치 항목을 찾습니다. 목적지 도메인이 앞쪽 규칙에서 DIRECT에 먼저 일치하면 Hysteria2 항목을 바꿔도 해당 요청은 직접 연결됩니다. 프로토콜 속도를 비교하기 전에 요청에 실제로 적용되는 정책을 확인하세요.
증상별 문제 해결: 시간 초과, 인증 오류, 끊김, 업데이트 후 연결 실패
지연 시간 테스트에서 숫자가 표시되더라도 해당 시점의 테스트 요청이 응답했다는 뜻일 뿐, 실제 서비스가 정상 작동한다는 보장은 아닙니다. 특히 TCP 포트 검사로는 Hysteria2에 필요한 UDP 핸드셰이크를 확인할 수 없습니다. 문제가 생기면 대역폭 값을 계속 바꾸기보다 실패한 단계를 따라 점검하는 편이 효과적입니다.
- 계속 연결 시간 초과: 먼저 Address와 Port를 확인한 뒤 서버에서 UDP를 수신하는지, 방화벽 규칙이 올바른지 점검합니다. 도메인을 사용한다면 서버 도메인이 조회되는지 확인하고, 본인이 사용할 수 있는 다른 접속 네트워크에서도 비교해 봅니다.
- TLS 오류 발생: 기기 시간, SNI, 인증서 이름과 유효 기간을 확인합니다. Address에 IP를 입력했다면 특히 검증에 사용하는 이름이 인증서에 포함되어 있는지 살펴보세요.
- 인증 실패: Password가 해당 Hysteria2 항목의 값인지 확인하고, 복사 과정에서 공백이 들어가지 않았는지, 인증 정보가 변경되었는지, 선택한 난독화 설정이 서버와 일치하는지 점검합니다.
- 연결됐지만 웹페이지가 열리지 않음: Global Routing, 규칙 적용 결과, DNS를 확인합니다. 일부 도메인만 실패한다면 프로토콜 전체가 작동하지 않는다고 판단하기 전에 도메인 조회나 목적지 연결 가능 여부를 먼저 확인하세요.
- 전송 중간에 멈춤: UDP 속도 제한, 무선 신호, 서버 부하, 경로 MTU 등을 확인합니다. 대역폭 목표를 설정했다면 기존 값을 기록한 다음 목표를 낮춰 한 번에 하나씩 테스트합니다.
- 구독 업데이트 후 설정 변경: 가져온 항목의 유형, 포트, 인증 정보, TLS 설정을 다시 확인합니다. 직접 수정한 값이 업데이트 내용으로 바뀌었을 수 있습니다. 항목 이름만 보지 말고 현재 저장된 설정을 기준으로 확인하세요.
On Demand는 조건에 따라 연결을 설정하는 동작을 제어하며 Hysteria2의 혼잡 제어 기능을 켜고 끄는 설정이 아닙니다. 자동 연결 문제를 확인하려면 Settings → On Demand에서 관련 조건을 살펴보세요. 전송 속도 문제를 점검할 때는 연결 상태와 접속 네트워크를 안정적으로 유지해 자동 재연결에 따른 대기 시간을 처리량 저하로 오해하지 않도록 합니다.
최종 판단은 실제 사용 경험을 기준으로 해야 합니다. UDP 연결이 가능하고 설정값이 일치하며 규칙이 올바르게 적용되는지 확인한 뒤 반복 테스트 결과를 비교하세요. 현재 네트워크에서 UDP가 계속 차단되거나 심하게 제한된다면 대역폭 값을 조정해도 근본적인 문제를 해결할 수 없습니다. 연결이 안정적이고 서비스 사용에 문제가 없다면 한 번의 속도 측정에서 최고 수치를 얻으려고 설정을 계속 바꿀 필요도 없습니다.