Shadowrocket 프로토콜 가이드

01 / CONNECTION MODEL

프로토콜 계층과 설정값 점검 순서

프로토콜 유형은 연결 과정의 일부입니다

기기에서 대상 서비스로 전송되는 요청은 보통 로컬 라우팅 판단, 서버 주소 확인, 하위 계층 연결, 프로토콜 인증, 대상 전달 과정을 거칩니다. Shadowsocks, VMess, VLESS 같은 이름은 주로 클라이언트와 서버가 프록시 요청을 주고받는 방식을 나타낼 뿐, 서버와의 거리나 출구 대역폭, 혼잡 정도를 직접 알려주지는 않습니다. 같은 프로토콜이라도 성능은 크게 다를 수 있고, 반대로 서로 다른 프로토콜도 네트워크와 서버 조건이 비슷하면 실제 사용 경험이 비슷할 수 있습니다.

설정값을 이해할 때는 서버 주소, 인증, 전송, 보안, 라우팅을 구분해야 합니다. 서버 주소는 연결 대상 위치를 지정하고, 비밀번호·UUID·키는 연결 주체를 인증합니다. TCP, UDP와 그 위에 추가되는 캡슐화는 데이터 전달 방식을 정하며, TLS는 해당 연결의 암호화와 인증서 검증을 담당합니다. 규칙은 각 요청에 어떤 연결을 사용할지 결정합니다. 한 계층이 통과했다고 다음 계층도 정상이라는 뜻은 아니므로, ‘지연 시간이 측정됨’만으로 전체 접속을 확인할 수는 없습니다.

제공된 정보를 기준으로 입력하고, 추측한 값을 기본값처럼 사용하지 마세요

Add Server에서 유형을 선택하기 전에 보유한 정보에 표시된 프로토콜부터 확인하세요. 포트가 같아도 프로토콜은 다를 수 있으며, TLS를 사용한다고 해서 반드시 Trojan인 것도 아닙니다. 구독을 가져온 뒤에는 유형, 서버, 포트가 타당한지 살펴보고 인증 필드와 전송 옵션도 확인하세요. 필드 이름과 순서는 유형에 따라 다를 수 있으므로 현재 앱에 표시되는 내용을 기준으로 하세요. 전달받지 않은 설정값은 온라인 예시만 보고 임의로 추가하지 마세요.

서버 도메인, TLS의 SNI, WebSocket의 Host는 같을 수도 있고 서버 배포 방식에 따라 다를 수도 있습니다. 도메인은 연결 주소를 찾는 데 사용하고, SNI는 TLS 핸드셰이크에서 서비스를 선택하며 일반적으로 인증서 이름 확인에도 사용됩니다. Host는 애플리케이션 계층의 요청 전달에 사용됩니다. 하나를 바꿔도 나머지 두 항목이 바뀌는 것은 아니므로, 세 항목을 서로 바꿔 쓸 수 있는 서버 주소처럼 취급하면 안 됩니다.

UDP 지원 여부와 특정 앱에서의 사용 가능 여부를 구분하세요

‘UDP 지원’에는 최소한 클라이언트의 프로토콜 구현, 서버의 전달 권한, 중간 네트워크, 대상 서비스라는 네 가지 조건이 관련됩니다. 일부 프로토콜은 UDP 데이터를 스트림 연결에 담고, 일부는 데이터그램을 직접 사용하며, 추가 확장 기능에 따라 달라지는 경우도 있습니다. 음성 통화, 실시간 상호작용, HTTP/3의 작동 여부는 프로토콜 이름만으로 판단할 수 없습니다. 일반 웹페이지가 정상적으로 열리더라도 실제 사용하려는 앱에서 따로 검증하세요. 웹 접속 성공을 모든 연결 기능의 정상 작동으로 오해하지 않도록 주의해야 합니다.

이후 내용에서 ‘선택’은 이미 보유하고 있고 서버가 명확히 지원하는 구성 가운데 하나를 고르는 것을 뜻합니다. 클라이언트 메뉴에서 유형을 바꾼다고 서버 프로토콜이 바뀌는 것은 아닙니다. 가져온 결과가 원본 정보와 다르다면 공유 링크가 온전한지, 파싱 후 필드가 유지되었는지 먼저 확인한 뒤 다시 가져오거나 정보 제공자에게 문의하세요. 잘못된 유형에서 설정을 반복해서 바꾸지 않도록 주의해야 합니다.

02 / SHADOWSOCKS

Shadowsocks: 암호화 방식과 전달 범위

적은 프로토콜 계층으로 프록시 트래픽 전달

Shadowsocks는 클라이언트와 서버 사이에 암호화된 프록시 전달 채널을 만들고, 대상 주소와 앱 데이터를 서버에서 처리하도록 전달하는 방식입니다. 완전한 가상 사설망 프로토콜이 아니며 시스템의 모든 요청에 대한 라우팅을 자동으로 결정하지도 않습니다. Shadowrocket은 기기에서 처리 대상 트래픽을 받아 Global Routing과 현재 구성에 따라 선택한 Shadowsocks 연결로 전달할지 결정합니다. 프로토콜과 로컬 분기는 서로 다른 역할입니다.

캡슐화 계층이 적으면 일부 핸드셰이크와 처리 비용을 줄일 수 있지만, 이를 근거로 속도가 더 빠르다고 보장할 수는 없습니다. 실제 처리량은 암호화 구현, 기기 부하, 서버 성능, 연결 품질의 영향을 받습니다. 서버 자체가 혼잡하다면 암호화 방식을 바꾸는 것으로 해결되지 않는 경우가 많습니다. 추가 전송 방식이 있다면 그 비용도 함께 고려해야 하며, 유형 이름만으로 실제 경로를 추측해서는 안 됩니다.

Method와 Password를 함께 확인하세요

핵심 정보는 서버, 포트, 암호화 방식, 비밀번호입니다. Method는 임의로 고르는 성능 옵션이 아니라 양쪽에서 같은 알고리즘과 메시지 형식을 사용해야 하는 설정입니다. AEAD 방식은 기밀성뿐 아니라 데이터 무결성도 검증합니다. 방식에 따라 키 길이와 파생 방식이 다를 수 있습니다. Password가 맞아도 Method가 틀리면 인증이나 복호화에 실패할 수 있으며, 명확한 ‘비밀번호 오류’ 대신 연결 후 유효한 응답이 없는 증상으로 나타날 수 있습니다.

고정 길이로 인코딩된 키를 사용하는 프로토콜 변형에서는 일반적인 짧은 비밀번호를 키로 그대로 입력하면 안 됩니다. 원본 정보에 인증 요소가 여러 개 있거나 특수 형식이 지정되어 있다면 구분자를 임의로 삭제하지 말고 전체 내용을 유지하세요. 복사할 때는 끝의 공백과 줄바꿈, 입력기가 바꾼 문장 부호도 확인해야 합니다. 직접 다시 입력한다고 반드시 정확해지는 것은 아니므로 신뢰할 수 있는 원본에서 복사한 뒤 가져온 결과와 항목별로 대조하세요.

TCP가 정상이어도 UDP까지 확인된 것은 아닙니다

Shadowsocks는 여러 유형의 앱 트래픽을 전달할 수 있지만 UDP 사용 가능 여부는 양쪽 지원과 네트워크 조건에 달려 있습니다. 웹페이지가 열린다고 해서 경로 전체가 확인된 것은 아닙니다. 음성 연결이 실패하거나 실시간 앱이 특정 네트워크에서만 이상하다면 먼저 서버에서 UDP 전달을 허용하는지, 클라이언트 관련 옵션이 제공된 정보와 일치하는지, 현재 Wi-Fi나 셀룰러 네트워크에서 해당 데이터를 전달할 수 있는지 확인하세요. 비밀번호와 암호화 방식부터 바꾸지 마세요.

UDP 데이터그램은 일반적으로 TCP와 같은 신뢰성 있는 전달 방식을 제공하지 않으며, 손실된 패킷을 재전송할지는 상위 계층 앱에 따라 달라집니다. 따라서 테스트에서 지연 시간이 낮게 나왔는데 통화가 끊기는 상황은 모순이 아닙니다. 지연 시간은 응답을 받은 요청만 반영하며 모든 데이터그램이 제때 도착했는지는 보여주지 않습니다. 문제를 진단할 때는 최저 지연 시간만 보지 말고 손실, 지터, 장시간 연결 상태도 함께 살펴보세요.

iPhone과 iPad에서 성능을 평가하는 방법

보유한 구성이 모두 정상 작동한다면 Shadowsocks를 비교적 단순한 기준점으로 삼을 수 있습니다. 짧은 웹 요청에서는 첫 응답과 반복 접속을, 대용량 파일에서는 안정적인 처리량을, 실시간 앱에서는 장시간 지터를 살펴보세요. 지역과 출구가 다른 구성을 비교한 뒤 차이를 모두 프로토콜 탓으로 돌리지 마세요. 서버 위치와 부하가 캡슐화 계층 수보다 더 큰 영향을 주는 경우가 많습니다.

기기 배터리 소모를 줄이고 싶다면 불필요한 상시 전송과 반복적인 연결 실패부터 줄이고, 그다음 암호화 처리의 영향을 살펴보세요. 연결은 오래 유지하지만 트래픽이 거의 없는 경우와 대용량을 계속 다운로드하는 경우의 배터리 소모 원인은 다릅니다. 전자는 백그라운드 깨우기와 네트워크 연결 유지의 영향을 더 받고, 후자는 무선 전송, 암호화 연산, 기기 온도 변화까지 관련됩니다. 배터리 설정의 비율 하나만으로 프로토콜 문제를 진단할 수는 없습니다.

03 / VMESS & VLESS

VMess와 VLESS: 인증, 전송, TLS

이름은 비슷해도 서로 바꿔 쓸 수 있는 유형은 아닙니다

VMess는 프록시 요청 인증과 데이터 처리를 자체 프로토콜에 결합합니다. VLESS는 요청과 신원 정보를 더 간결하게 다루며, 연결 보안은 함께 사용하는 보안 전송 계층에 더 많이 맡깁니다. 둘 다 여러 전송 방식과 조합할 수 있으므로 정보에 TCP, WebSocket, TLS가 표시되어 있다면 구체적인 조합을 확인해야 합니다. VMess 항목을 VLESS로 바꾼다고 인증 방식, 메시지 형식, 서버 설정이 자동 변환되는 것은 아닙니다.

VLESS 자체는 TLS와 동등한 데이터 암호화를 제공하지 않습니다. VLESS를 사용한다고 UUID만 확인하고 보안 계층까지 갖춰졌다고 판단하면 안 됩니다. 원본 정보에서 요구하는 보안 방식과 설정이 실제로 적용되어 있는지 확인하세요. 정보가 없다면 임의로 인증서 검증을 끄지 말고 먼저 배포 설정을 확인해야 합니다. 관련 확장 기능의 지원 여부도 현재 클라이언트와 서버의 실제 기능을 기준으로 판단해야 합니다.

UUID, 시간, 인증 정보

UUID는 이런 유형의 구성에서 자주 사용하는 신원 필드이므로 민감 정보로 취급해야 합니다. 서버 도메인이 아니며 메모 이름과 혼동해서도 안 됩니다. VMess 인증 방식에는 시간 조건이 관련되므로 기기 시간이 크게 어긋나면 인증에 영향을 줄 수 있습니다. 같은 정보가 다른 기기에서는 작동하는데 이 기기에서 실패한다면 앱을 재설치하기보다 자동 시간 설정이 정상인지도 확인하세요. VLESS의 인증 방식은 다르므로 VMess의 문제 해결 방법을 그대로 적용하면 안 됩니다.

가져온 정보에 추가 인증이나 흐름 제어 설정이 포함되어 있다면 UUID만 입력해서는 연결되지 않을 수 있습니다. 오래된 정보의 일부 필드는 현재 조합에서 유효하지 않을 수도 있습니다. 입력란을 모두 채워 보이게 하려고 임의의 값을 넣지 마세요. 서버의 연결 안내를 확인해 해당 필드가 현재 프로토콜에 필요한지 점검해야 합니다. 다른 전송 또는 보안 조합에만 해당하는 설정이라면 적용하지 마세요.

WebSocket에서 추가로 확인할 항목

WebSocket은 해당 애플리케이션 계층 세션에 연결을 실을 수 있으며, 기존 HTTP 서비스의 전달 구조에 자주 사용됩니다. 이 방식에는 경로, Host, 중간 전달 동작 등 추가 조건이 있습니다. 경로는 보통 정확히 일치해야 합니다. 대소문자, 마지막 슬래시, 빠진 접두 경로 때문에 서버가 요청을 올바른 처리기로 전달하지 못할 수 있습니다. HTTP 응답을 받았다고 프록시 인증까지 성공한 것은 아닙니다. 일반 사이트에 도달했을 수도 있습니다.

외부 계층에서 TLS를 사용한다면 먼저 보안 핸드셰이크가 이뤄지고, 그다음 WebSocket 연결 및 프록시 프로토콜 교환이 진행됩니다. 인증서 오류, 경로 오류, UUID 오류는 발생 단계가 서로 다르므로 증상을 계층별로 판단해야 합니다. 중간 전달 장치에 장시간 연결의 유휴 시간 제한이 있다면 일정 시간 사용하지 않은 뒤 연결이 끊길 수 있습니다. 이는 처음부터 인증에 실패하는 경우와 다르며 비밀번호를 더 길게 만든다고 해결되지 않습니다.

속도 선택과 문제 해결 순서

전송 계층이 추가되면 핸드셰이크 횟수, 메시지 오버헤드, 중간 장치의 처리 부담이 늘 수 있습니다. 하지만 해당 계층이 서버 배포에 필수일 수도 있으므로 클라이언트에서만 임의로 끄면 안 됩니다. 성능을 비교할 때는 올바른 설정 조합 전체를 사용하세요. 짧은 연결이 많은 환경에서는 연결 설정 비용이 더 두드러지고, 장시간 연결에서는 대역폭, 패킷 손실, 다중화 동작의 영향을 더 받을 수 있습니다. 한 번의 지연 시간 테스트만으로 두 상황을 모두 설명할 수는 없습니다.

주소 확인, 포트, TLS, 전송 경로, 인증, 실제 대상 접속 순으로 점검하는 것이 좋습니다. 모든 대상에서 실패한다면 공통 연결 계층부터 확인하고, 특정 도메인만 실패한다면 규칙, 이름 확인, 대상 상태를 살펴보세요. 구독 업데이트 후 기존 구성이 갑자기 작동하지 않는다면 해당 항목의 전송 옵션이 바뀌었는지, 수동 수정이 업데이트로 덮어쓰였는지도 확인하세요. 업데이트 전 기억에만 의존해 설정을 비교하지 마세요.

04 / TROJAN · HTTP · SOCKS5

Trojan, HTTP, SOCKS5: 보안 계층과 프록시 동작

Trojan은 올바른 TLS 연결이 필요합니다

Trojan은 TLS 연결 안에 프록시 프로토콜을 두고, 해당 인증 정보로 서버가 프록시 요청을 식별하도록 설계되었습니다. 외부 TLS와 내부 인증을 구분하는 것이 중요합니다. 서버 주소로 TCP 연결이 된 것은 포트에 접근할 수 있다는 뜻일 뿐입니다. TLS 핸드셰이크에 성공한 뒤에도 인증과 대상 전달이 정상적으로 이뤄져야 합니다. Password, SNI, 포트, 서버 배포 방식이 모두 맞아야 하며 비밀번호 하나만 입력하면 연결될 것이라고 기대해서는 안 됩니다.

인증서 검증은 연결 상대의 신원을 확인하는 절차입니다. 이름이 일치하지 않는다면 제공된 SNI, 서버 도메인, 인증서가 적용되는 범위를 점검하세요. 인증서 유효 기간 오류가 표시되면 기기 시간과 서버 인증서를 확인해야 합니다. 검증을 건너뛰도록 기본 설정하면 신원 확인이라는 보호 계층을 잃고 실제 설정 문제를 숨길 수 있습니다. 오류 메시지만 없애려 하지 말고 이름, 인증서 체인, 시간을 바로잡으세요.

HTTP 프록시는 대상 웹사이트가 HTTP라는 뜻이 아닙니다

HTTP 프록시는 클라이언트와 프록시 서버가 상호작용하는 방식을 나타냅니다. 일반 HTTP 대상에 접속할 때 프록시가 해당 요청을 처리할 수 있습니다. HTTPS 대상에 접속할 때는 보통 CONNECT 메서드로 대상까지 연결 통로를 만들고, 그 통로를 통해 대상 웹사이트와 TLS 세션을 맺습니다. 따라서 ‘HTTP 프록시’라고 해서 브라우저가 일반 HTTP 웹사이트만 열 수 있는 것은 아니며, 클라이언트와 프록시 서버 사이의 연결이 반드시 TLS로 보호된다는 뜻도 아닙니다.

정보에 HTTPS 프록시가 명시되어 있다면 클라이언트와 프록시 사이에도 TLS 연결이 있으므로 인증서와 이름을 확인해야 합니다. 사용자 이름과 비밀번호는 대개 프록시 인증에 사용되지만, 인증 자체가 완전한 암호화 방식은 아닙니다. 보안 범위를 파악하려면 ‘기기와 프록시 사이가 암호화되는가’와 ‘앱과 대상 사이가 암호화되는가’를 따로 확인해야 합니다. 웹페이지에 보안 연결 표시가 있다고 중간의 모든 계층도 같다고 단정할 수 없습니다.

SOCKS5는 범용 대상 전달 방식을 제공합니다

SOCKS5는 협상을 통해 프록시 서버에 대상 주소, 포트, 필요한 작업을 전달하며 도메인이나 IP 주소를 대상으로 지정할 수 있습니다. 기본 SOCKS5에는 TLS 수준의 전송 암호화가 포함되지 않습니다. 사용자 이름과 비밀번호 인증도 보안 채널을 대신하지 못합니다. 서버에서 이런 인터페이스를 제공한다고 명확히 확인된 경우에 사용하세요. 설정 항목이 적다는 이유만으로 모바일 기기에 더 적합하다고 판단하지 말고, 연결 네트워크와 추가 보호 조건을 먼저 확인해야 합니다.

SOCKS5의 UDP 전달에는 별도 협상과 데이터그램 경로가 관련되며, 실제 사용 가능 여부는 서버 구현, 클라이언트 설정, 네트워크 접근성에 달려 있습니다. TCP 요청이 정상이라고 UDP 연결까지 성립한 것은 아닙니다. 대상 도메인을 어디서 확인하는지도 결과에 영향을 줍니다. 로컬에서 먼저 IP 주소로 변환하면 프록시 서버에는 원래 도메인 대신 IP가 전달될 수 있습니다. 이름 확인 차이와 도메인 규칙 일치는 실제 전달 과정을 함께 살펴봐야 합니다.

기존 환경에 맞게 선택하는 방법

조직이나 직접 관리하는 서버에서 고정 프록시 인터페이스를 제공한다면 익숙한 이름의 유형으로 임의 변경하지 말고 해당 프로토콜에 맞춰 입력하세요. 서버에서 같은 포트를 수신하더라도 핸드셰이크 형식은 다를 수 있습니다. 인증서와 도메인이 명확히 설정된 Trojan 구성이라면 TLS 항목을 빠짐없이 확인하세요. HTTP 또는 SOCKS5는 인터페이스의 신뢰 범위, 인증 요구 사항, 허용되는 대상 범위를 확인해야 합니다.

실제 문제를 해결할 때 CONNECT가 거부되거나 일부 포트만 실패하거나 인증이 계속 통과하지 못한다면 서버 접근 정책도 고려해야 합니다. 대상 권한 제한은 무선 신호가 약한 문제도 아니고 모든 프로토콜에 공통으로 나타나는 문제도 아닙니다. 오류가 발생한 대상 유형과 단계가 기록되어 있으면 인증 실패, 대상 접근 불가, 서버 정책에 따른 요청 거부를 구분하기 쉽습니다. 근거 없이 모든 필드를 한꺼번에 바꾸지 마세요.

05 / WIREGUARD

WireGuard: 키, 터널 주소, IP 라우팅

대상 프록시에서 IP 터널로

WireGuard의 작동 방식은 앞서 다룬 대상 프록시 유형과 다릅니다. 암호화된 터널로 IP 패킷을 전달하고, 양쪽이 키와 피어 정보를 바탕으로 통신 관계를 설정합니다. 이 프로토콜은 간결한 설계와 고정된 암호화 조합을 강조하며 사용자가 선택 가능한 알고리즘을 길게 협상하는 방식이 아닙니다. Shadowrocket에서 설정할 때는 프록시 계정과 대상 주소 형식보다 키, Endpoint, 터널 주소, 접근 가능한 네트워크 대역을 중점적으로 확인해야 합니다.

이 프로토콜은 UDP를 하위 전송 방식으로 사용하므로 외부 UDP 경로를 사용할 수 있어야 합니다. 터널 안에는 여러 앱의 IP 트래픽을 실을 수 있지만, 외부 네트워크에서 모든 UDP 통신을 허용한다는 뜻은 아닙니다. 같은 구성이 특정 Wi-Fi에서는 작동하고 셀룰러 네트워크에서는 실패한다면 터널 내부의 대상 규칙보다 외부 경로와 주소 확인을 먼저 살펴보세요. 내부 앱의 TCP가 정상인 것과 외부 UDP에 접근할 수 있는 것은 별개의 문제입니다.

Private Key와 Public Key의 역할을 바꾸지 마세요

Private Key는 본인 기기의 신원 정보이므로 비밀로 유지해야 합니다. Public Key는 상대가 본인을 식별할 때 사용합니다. 클라이언트 구성에 입력하는 상대 피어의 공개 키는 서버의 신원에 대응해야 하며, 본인의 공개 키를 그대로 복사하면 안 됩니다. 정보에 Preshared Key가 있다면 양쪽에서 같은 값을 사용해야 합니다. 키는 대개 정해진 인코딩 형식을 따릅니다. 문자가 누락되거나 공백이 섞이면 연결에 문제가 생길 수 있고, 개인 키가 공개된 스크린샷에 노출되면 보안 문제가 발생합니다.

Endpoint는 통신을 시작할 때 사용하는 외부 주소와 포트이며 터널 내부 주소가 아닙니다. Address 계열 설정은 터널 안에서 본 기기에 할당되는 주소를 나타내며 배포 계획과 일치해야 합니다. Endpoint의 공인 주소를 터널 주소 칸에 입력하거나 양쪽에 충돌하는 내부 주소를 설정하면 핸드셰이크 후에도 데이터가 제대로 전달되지 않을 수 있습니다. 입력할 때는 모두 IP 주소처럼 보인다는 점에만 주목하지 말고 각 필드의 역할을 확인하세요.

Allowed IPs와 로컬 분기는 같은 규칙 표가 아닙니다

WireGuard에서 Allowed IPs는 피어가 담당하는 주소 범위와 송신 대상 선택에 함께 관여합니다. 원격 사이트 목록이 아니며 Shadowrocket의 Rule을 그대로 대체할 수도 없습니다. 로컬 규칙이 요청을 해당 연결로 보낼지 먼저 결정하고, WireGuard에 들어간 뒤에는 터널 주소 범위와 서버 전달 설정에 따라 대상 도달 여부가 정해집니다. 한쪽에서 넓은 범위를 지정했다고 다른 쪽도 자동으로 같은 범위를 허용하는 것은 아닙니다.

이미 보유한 원격 내부 네트워크에 접속하려면 대상 네트워크 대역, 반환 경로, 서버의 전달 허용 여부를 확인하세요. 로컬 Wi-Fi와 원격 네트워크에서 같은 사설 IP 대역을 사용하면 주소가 겹칠 수도 있습니다. 같은 대상이 로컬 기기이면서 원격 기기처럼 보이는 상황이 생길 수 있습니다. 이때는 네트워크 설계와 규칙을 함께 검토해야 하며 DNS 변경만으로 모든 충돌을 해결할 수는 없습니다. 구체적으로 수정하기 전 어느 쪽에서 해당 주소를 사용하는지 확인하세요.

Keepalive, MTU, 모바일 네트워크

Keepalive는 네트워크 장비의 매핑 상태를 유지하는 데 도움이 될 수 있으며, 외부에서 먼저 연결을 시작해야 하거나 매핑 유지가 필요한 배포 환경에 적합합니다. 다만 주기를 너무 짧게 설정하면 백그라운드 네트워크 활동이 증가합니다. 무조건 짧은 값을 일반적인 최적화 방법으로 사용하지 마세요. 모바일 네트워크를 전환하면 외부 주소와 매핑이 달라질 수 있습니다. 프로토콜에 피어 업데이트 기능이 있더라도 현재 네트워크에서 유효한 데이터가 전달되어야 하며, 시스템이 경로를 복구할 시간도 필요합니다.

MTU는 전달할 수 있는 패킷 크기를 나타냅니다. 캡슐화에는 추가 공간이 필요하므로 경로에서 허용하는 크기가 부족하면 작은 요청은 정상인데 큰 응답은 멈출 수 있습니다. 서버와 대상 문제부터 제외한 뒤 실제 경로를 고려해 신중하게 조정하고 기존 값을 보관하세요. 모든 시간 초과가 MTU 때문인 것은 아닙니다. 무작정 값을 낮추면 패킷 수와 처리 부담이 늘 수 있고 속도가 개선된다는 보장도 없습니다. 재현 가능한 대상으로 변경 결과를 확인하세요.

06 / HYSTERIA2

Hysteria2: QUIC, 대역폭 설정, 패킷 손실 환경

QUIC 기반 연결 방식

Hysteria2는 QUIC 기반 전송 설계를 사용합니다. QUIC은 UDP 위에서 보안 연결, 스트림 관리, 신뢰성 있는 전달 등의 기능을 제공합니다. 여러 스트림을 하나의 연결 체계 안에서 관리할 수 있습니다. 모든 데이터를 하나의 순서가 보장되는 바이트 스트림에 넣는 방식과 비교하면 전송 계층에서 각 스트림의 전달이 더 독립적일 수 있습니다. 하지만 스트림은 여전히 대역폭, 혼잡 피드백, 기기 자원을 공유하므로 각 스트림이 독립된 네트워크 용량을 가진다고 이해하면 안 됩니다.

이 설계는 왕복 지연 시간이 길거나 패킷 손실이 있는 경로를 논할 때 자주 언급되지만, ‘패킷 손실이 있으면 반드시 더 빠르다’는 뜻은 아닙니다. 손실은 혼잡, 무선 신호, 네트워크 장비 제한, 경로 변화 등에서 발생할 수 있으며 전송 방식은 이런 조건에 맞춰야 합니다. 외부 UDP가 안정적으로 전달되지 않으면 그 위에서 작동하는 프로토콜도 접근성을 저절로 복구할 수 없습니다. 프로토콜 기능과 현재 네트워크의 통신 조건을 모두 충족해야 합니다.

인증, TLS, 서비스 이름도 확인해야 합니다

Hysteria2 연결 정보에는 대개 서버, 포트, 인증 정보, TLS 관련 설정이 포함됩니다. 인증과 인증서 검증은 서로 다른 작업입니다. 전자는 서버가 클라이언트의 권한을 확인하고, 후자는 클라이언트가 서버의 신원을 확인합니다. Server, SNI, 인증서 이름이 일치하는지 배포 정보를 기준으로 점검하세요. 기반 전송 방식이 QUIC이라고 인증서 검사를 생략하거나 임의의 이름을 유효한 값으로 사용해도 되는 것은 아닙니다.

배포 설정에 추가 난독화 옵션이 있다면 양쪽 유형과 관련 설정을 확인하세요. 난독화는 인증 비밀번호와 같은 의미가 아니며, 임의의 문자열을 입력한다고 작동하는 성능 스위치도 아닙니다. 이름이 비슷하다는 이유만으로 Hysteria2와 다른 프로토콜 또는 다른 세대 프로토콜의 설정을 섞어 사용하지 마세요. 가져온 뒤 이해하기 어려운 빈 필드가 있다면 원본 정보로 돌아가 의미를 확인하세요. 다른 유형의 필드를 하나씩 복사하지 마세요.

대역폭 설정값이 실제 속도를 보장하지는 않습니다

일부 구성에는 업로드·다운로드 대역폭 설정이 있으며, 전송 제어나 대역폭 협상에 사용될 수 있습니다. 이 값은 작동 조건이나 제어 입력을 나타내며 구매 권리나 기기가 확보할 수 있는 처리량을 보장하지 않습니다. 단위에 특히 주의하세요. 비트 속도와 바이트 속도는 다릅니다. 앱 표시 단위와 제공된 정보의 단위가 다르면 먼저 변환한 뒤 필드에서 요구하는 형식으로 입력해야 합니다. 단위 차이로 값의 규모를 잘못 입력하지 않도록 확인하세요.

대역폭을 실제 사용 가능한 용량보다 훨씬 높게 설정해도 물리적인 연결 용량이 늘어나지는 않습니다. 오히려 지나치게 적극적인 전송으로 대기열이 쌓여 다른 앱의 응답이 늦어지고 패킷 손실이나 속도 변동이 생길 수 있습니다. 너무 낮게 설정하면 사용 가능한 처리량이 제한될 수 있습니다. 현재 조합에서 설정을 명시해야 하는지, 값이 어떻게 적용되는지는 양쪽 구현과 배포 안내를 기준으로 확인하세요. 다른 사람의 값을 고정 권장값처럼 사용하지 않는 것이 좋습니다.

모바일 기기의 추가 부담 평가

QUIC의 암호화, 패킷 관리, 복구 기능은 기기 자원을 사용합니다. 신호가 약하거나 제한된 네트워크에서 외부 UDP 재시도가 반복되면 무선 활동과 배터리 소모가 늘 수 있습니다. 고속 전송 중 발열이 커지더라도 프로토콜 이름 하나만 원인으로 단정할 수 없습니다. 화면, 대상 앱, 지속적인 데이터 전송도 원인일 수 있습니다. 비교할 때는 작업, 화면 밝기, 기기 온도, 테스트 시간을 비슷하게 유지해 환경 차이를 프로토콜 차이로 오해하지 않도록 하세요.

보유한 Hysteria2 구성이 한 네트워크에서 계속 실패하고 다른 네트워크에서는 안정적으로 작동한다면 네트워크를 바꿔 비교하고 핸드셰이크조차 완료되지 않는지 기록하세요. 핸드셰이크는 정상인데 장시간 부하에서 불안정하다면 대역폭 설정, 서버 자원, 경로 패킷 손실을 확인합니다. 특정 앱만 이상하다면 먼저 해당 요청이 실제로 그 연결을 통과하는지, 대상 서비스가 정상인지 확인하세요. 한 가지 증상만으로 프로토콜 전체가 작동하지 않는다고 결론 내리지 마세요.

07 / IOS & IPADOS

iPhone·iPad: 속도, 배터리, 네트워크 전환

속도를 관찰 가능한 세 부분으로 나누기

첫째는 주소 확인, 하위 서버 연결, 보안 핸드셰이크를 포함한 연결 설정 시간입니다. 둘째는 서버에서 대상에 접속하는 시간까지 포함한 대상의 첫 응답입니다. 셋째는 대역폭, 패킷 손실, 혼잡 제어, 양쪽의 처리 능력에 좌우되는 지속적인 처리량입니다. 일상적인 웹 사용은 앞의 두 항목에, 대용량 파일 전송은 세 번째 항목에 더 큰 영향을 받을 수 있습니다. 지연 시간 수치 하나로 세 항목을 모두 나타내거나 영상, 통화, 상호작용 경험을 직접 환산할 수는 없습니다.

Connectivity Test 결과는 현재 테스트 방식과 함께 해석해야 합니다. 방식에 따라 서버 접근성만 확인할 수도 있고 프록시를 통해 대상에 접속할 수도 있습니다. 측정 대상을 모른 채 수치를 전체 서비스의 왕복 시간으로 간주하지 마세요. 지역 이름도 참고용 정보일 뿐 실제 경로 측정을 대신하지 못합니다. 테스트 의미와 지역 판단은 지연 시간, 지역, 프로토콜 유형의 관계에서 확인할 수 있습니다.

배터리 소모는 전체 작동 과정에서 발생합니다

연결 작동에는 앱의 트래픽 생성, 시스템 네트워크 처리, 프로토콜 암호화, 무선 송수신, 필요한 백그라운드 유지 작업이 관련됩니다. 처리량이 높으면 연산과 무선 전송 부담이 함께 늘어납니다. 유휴 상태라면 연결 유지, 자동 확인, 실패 후 재연결을 살펴볼 필요가 있습니다. 배터리 통계의 비율은 다른 앱의 사용량에도 영향을 받으므로 사용량이 다른 두 날짜의 비율만 비교해 프로토콜 효율을 판단하면 안 됩니다.

타당한 비교를 하려면 기기 온도가 비슷해질 때까지 기다린 뒤 네트워크, 화면 밝기, 작업을 동일하게 유지하고 비슷한 시간 동안 실행하세요. 이후 배터리 변화, 전송량, 연결 실패를 기록합니다. 한 번은 충전 중이고 다른 한 번은 저전력 모드이거나 백그라운드에서 많은 데이터가 동기화되고 있다면 결과를 해석하기 어렵습니다. 몇 분 사이의 아주 작은 배터리 차이를 추구하기보다 지속적으로 비정상적인 활동이 있는지 살펴보세요.

Global Routing은 테스트 조건을 바꿉니다

Global Routing의 Config, Proxy, Direct는 각각 구성, 프록시, 직접 연결 모드에 해당합니다. Config에서는 규칙에 따라 특정 대상이 직접 연결될 수 있습니다. Proxy로 비교할 때도 시스템 트래픽과 특수 트래픽을 클라이언트가 처리하는 범위를 고려해야 합니다. Direct에서는 원격 프록시의 작동 여부를 확인할 수 없습니다. 비교하기 전에 같은 대상이 같은 유형의 경로를 거치는지 확인하세요. 그렇지 않으면 프로토콜 차이가 아닌 라우팅 차이를 측정하게 됩니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

위는 규칙 순서 예시입니다. 대상 도메인이 example.com에 속하면 PROXY를 사용하고, 지정된 사설 네트워크 대역은 DIRECT로 연결하며, 나머지는 FINAL로 처리합니다. 이 예시에는 연결 서버가 포함되어 있지 않으므로 단독으로 연결을 완료할 수 없습니다. 규칙은 순서대로 일치 여부를 확인하므로 앞선 조건이 뒤의 규칙에 영향을 줍니다. 수정 전에 현재 활성화된 Config를 확인하고 필요한 경우 구성 파일 섹션 안내를 참고하세요.

네트워크를 바꾼 뒤 다시 확인해야 하는 이유

Wi-Fi에서 셀룰러 네트워크로 바꾸면 로컬 주소, 기본 경로, DNS, 네트워크 장비의 매핑이 달라질 수 있습니다. 연결이 켜져 있다고 표시되더라도 기존 연결에 새 전송 경로를 다시 설정해야 할 수 있습니다. QUIC이나 WireGuard의 관련 기능이 일부 경로 변화를 처리할 수 있지만, 원활한 복구 여부는 양쪽 구현과 현재 네트워크에 따라 달라집니다. 모든 세션이 끊김 없이 유지된다고 보장할 수는 없습니다. 경로가 안정될 때까지 기다린 뒤 새 요청으로 확인하면 빠르게 네트워크를 반복 전환하는 것보다 원인을 파악하기 쉽습니다.

On Demand는 조건을 충족할 때 연결을 시작하는 동작을 처리하며 잘못된 비밀번호, 유효하지 않은 인증서, 접근할 수 없는 서버를 고쳐 주지 않습니다. 네트워크를 바꾼 뒤 연결이 반복된다면 자동 연결과 프로토콜 재시도를 구분해 살펴보고 규칙이 함께 바뀌었는지, 네트워크 연결이 아직 완료되지 않았는지 확인하세요. Settings 관련 설정은 기능 및 설정에서 확인할 수 있습니다. 일시적인 연결 끊김을 해결하려고 모든 자동 연결 조건을 바꾸지 마세요.

마지막으로 IPv4와 IPv6 경로를 구분해야 합니다. 도메인이 주소 계열별로 서로 다른 주소를 반환할 수 있으며 네트워크 전환 후 사용되는 주소도 바뀔 수 있습니다. 일부 대상만 실패한다면 한 주소 계열을 바로 끄기보다 확인 결과, 서버 출구, 해당 경로 조건을 점검하세요. DNS는 이름 확인 단계만 바꿀 수 있으며 인증서, 프로토콜 인증, 서버 권한, 대상 서비스 자체의 문제를 자동으로 해결하지는 않습니다.

08 / SELECTION & DIAGNOSTICS

사용 상황별 선택과 계층별 문제 해결

사용 가능한 조건부터 확인한 뒤 성능을 비교하세요

프로토콜 순위를 정하는 것이 아니라 현재 서버가 무엇을 지원하는지 확인하는 것이 첫 단계입니다. 유효한 구성이 하나뿐이라면 먼저 올바르게 설정하세요. 여러 구성이 있다면 인증 정보가 불완전하거나 보안 계층이 명확하지 않거나 네트워크 조건을 충족하지 못하는 항목을 제외합니다. 남은 구성을 실제 사용 작업에 맞춰 비교하세요. 프로토콜 이름으로 서버 접근 불가, 출구 혼잡, 잘못된 라우팅을 해결할 수는 없습니다. 클라이언트도 서버에 배포되지 않은 프로토콜을 새로 만들어 낼 수 없습니다.

고정된 작업으로 반복 가능한 비교 수행

실제로 사용하는 대상 두세 개를 골라 짧은 요청, 지속적인 전송, 필요한 경우 실시간 작업을 각각 테스트하세요. 매회 같은 네트워크와 기기를 사용하고 비슷한 시간대에 진행하며 대상이 동일한 경로를 거치는지 확인한 뒤 보유한 구성을 바꾸세요. 가장 좋았던 결과만 저장하지 말고 일반적인 성능과 실패 횟수를 기록하세요. 구성별로 지역과 서버가 다르다면 이는 전체 연결 경험을 비교하는 것이며 프로토콜 성능만을 입증하는 테스트는 아닙니다.

배터리 사용량이 중요하다면 안정적으로 작동하는 구성 가운데 유휴 상태의 유지 동작과 실제 데이터 전송 상태를 비교하세요. 자주 재연결에 실패하는 구성은 가끔 빠르더라도 장시간 연결에 적합하지 않을 수 있습니다. 반응성이 중요하다면 부하가 걸린 동안 응답이 어떻게 달라지는지 살펴보세요. 원격 네트워크 대역 접속이 목적이라면 주소 계획과 권한을 먼저 확인하세요. 작업마다 중요하게 볼 항목이 다르므로 모든 네트워크, 기기, 대상에 적용되는 고정 프로토콜 순위는 없습니다.

문제 발생 시 네 계층을 따라 범위 좁히기

첫째, 로컬 네트워크를 확인합니다. 기기가 Wi-Fi에 연결되었는지, 직접 연결하는 일반 대상이 정상인지, 네트워크 전환이 끝났는지 살펴보세요. 둘째, 서버 연결을 확인합니다. Server 주소 확인 결과, Port, 필요한 TCP 또는 UDP 경로에 접근할 수 있는지 점검하세요. 이 단계에서 UUID부터 바꾸지 마세요. 인증 정보는 주소 오류를 해결하지 못합니다. 특정 네트워크에서만 실패한다면 구성을 그대로 둔 채 다른 네트워크에서 비교하세요.

셋째, 보안 및 인증을 확인합니다. TLS 이름, 인증서, 기기 시간, Password, UUID, 키가 온전한지 살펴보세요. 로그에서 핸드셰이크 단계와 인증 단계를 구분할 수 있다면 오류가 발생한 위치에 맞춰 대응하세요. 모든 오류를 ‘연결 시간 초과’로 취급하지 마세요. 넷째, 실제 전달 과정을 확인합니다. Global Routing, 현재 Config, 대상 DNS, 서버 권한, UDP 조건, 반환 경로를 점검하세요. 핸드셰이크는 성공했지만 대상에 접속할 수 없다면 대개 첫 단계의 서버 포트가 문제의 핵심은 아닙니다.

업데이트, 되돌리기, 문제 기록

Subscribe 업데이트로 서버 필드나 항목 내용이 바뀔 수 있으며 수동 수정이 계속 유지된다고 보장할 수 없습니다. 업데이트 전후에 차이가 있다면 메모 이름만 보지 말고 실제 필드를 비교하세요. 접근 자격 정보가 포함될 수 있으므로 구독 주소를 공개된 게시물에 그대로 붙여 넣지 마세요. 문제 해결 기록에는 프로토콜 유형, 네트워크, 실패 단계, 대상 유형, 민감 정보를 가린 오류 내용만 남기면 됩니다. 개인 키와 전체 인증 정보는 공개 진단에 필요한 자료가 아닙니다.

한 번 수정했는데 나아지지 않는다면 원래 값으로 되돌린 뒤 다른 가설을 확인하세요. 추가로 도움을 요청할 때는 정리되지 않은 스크린샷을 많이 보내기보다 ‘어떤 네트워크에서, 어떤 대상을 이용할 때, 언제 실패했으며, 무엇을 확인했는지’를 설명하는 편이 유용합니다. 처음 가져오는 과정에서 문제가 생겼다면 시작하기의 전체 설정 절차로 돌아가세요. 구매, 재설치, 이전 구매 복원 문제는 구매와 설치 안내를 참고하세요. App Store에서 앱을 받는 문제와 프로토콜 연결 문제를 한 번에 해결하려 하지 마세요.

검증을 마친 기준 구성을 하나 보관하고 프로토콜, 인증 방식, 보안 계층, 라우팅 모드를 명확히 파악해 두세요. 설정 조합 하나를 외우는 것보다 각 조건의 범위를 이해하는 편이 환경 변화에 대응하는 데 도움이 됩니다. 구성은 서버와 일치해야 하고, 테스트는 실제 사용 작업을 반영해야 하며, 결론은 실제로 확인한 네트워크 조건 안에서 내려야 합니다.