Shadowrocket 프로토콜 가이드

01 / Model

프로토콜 계층과 선택 전 확인 사항

프로토콜 이름만으로 연결 방식 전체를 알 수는 없습니다

Add Server에서 Type을 선택하는 것은 클라이언트가 서버와 어떤 형식으로 통신할지를 지정하는 것입니다. 같은 연결의 성능 설정을 바꾸는 것이 아닙니다. 서버가 Shadowsocks를 제공한다면 클라이언트의 Type만 VLESS로 바꿔도 VLESS 기능을 사용할 수 없습니다. 양쪽에서 프로토콜, 포트, 인증 정보, 외부 전송 방식이 일치해야 합니다. 구독을 가져오면 보통 이런 정보도 함께 설정되지만, 가져오기에 성공했다고 해서 원격 설정이 여전히 유효하거나 현재 네트워크에서 해당 포트에 접속할 수 있다는 뜻은 아닙니다.

연결은 목적지 요청, 프록시 프로토콜, 전송 계층, 실제 네트워크 경로로 나누어 이해할 수 있습니다. 목적지 요청은 접속할 도메인과 포트를 지정합니다. 프록시 프로토콜은 요청과 인증 정보를 전달하며, 일부 프로토콜은 암호화도 제공합니다. 전송 계층은 TCP, UDP, TLS 또는 다른 캡슐화를 통해 데이터를 전달합니다. 실제 경로에는 무선 접속, 통신망, 서버 접속 구간, 서버에서 목적지까지의 구간이 포함됩니다. 한 계층에 문제가 생겼다고 해서 곧바로 프로토콜 이름을 원인으로 단정할 수는 없습니다. 문제를 진단할 때는 이 흐름을 따라 범위를 좁혀야 합니다.

인증·암호화·라우팅은 서로 다른 문제입니다

비밀번호, UUID, 키는 모두 신원을 확인하는 데 쓰일 수 있지만 의미는 서로 다릅니다. UUID는 도메인이 아니며 WireGuard의 Public Key도 비밀번호 입력란에 넣는 대체 문자열이 아닙니다. 암호화는 전송 내용을 보호하고 인증은 통신 상대나 사용자를 확인합니다. 두 기능이 하나의 방식으로 처리되기도 하고 서로 다른 계층에 나뉘기도 합니다. TLS 인증서 검증은 서버 신원을 확인하는 절차이므로 계정과 비밀번호가 맞더라도 생략해서는 안 됩니다. 비슷한 이름의 항목이라도 서비스 제공업체의 프로토콜 설명에 따라 정확한 값을 입력해야 합니다.

Global Routing은 별도의 판단 기준입니다. Config는 현재 설정에 따라 트래픽을 분기하고, Proxy는 프록시 정책에 트래픽을 전달하며, Direct는 직접 연결합니다. 이러한 설정은 서버의 프로토콜 유형을 다른 유형으로 바꾸지 않습니다. 올바른 Type을 선택한 뒤에도 요청이 의도한 정책을 따르는지 확인해야 합니다. 그렇지 않으면 접속 성공은 DIRECT가 적용된 결과일 수 있고, 접속 실패는 규칙이 사용할 수 없는 대상을 선택한 탓일 수 있습니다. 용어는 용어집에서 확인해 모드 전환을 프로토콜 튜닝으로 오해하지 않도록 하세요.

실제로 지원되는 범위에서 선택하기

선택은 프로토콜 목록에서 더 최신처럼 보이는 이름이 아니라 서버가 실제로 제공하는 기능에서 시작해야 합니다. 사용 가능한 유형, UDP 지원 여부, 인증 방식, 필요한 전송 방식을 먼저 확인한 다음 클라이언트에서 해당 항목을 설정할 수 있는지 살펴보세요. 같은 프로토콜이라도 기능 조합은 다를 수 있으며, 특정 항목이 없다고 다른 입력란에 임의의 값을 넣어서는 안 됩니다. 구독 정보와 수동 안내가 다르면 서비스 제공업체에 현재 유효한 설정을 문의하세요. 의미를 알 수 없는 확장 항목은 그대로 두고, 한 번에 여러 조건을 바꾸지 않아야 재현 가능한 기준을 유지할 수 있습니다.

Shadowrocket은 Apple 플랫폼용 유료 상용 앱입니다. 이용 가능 여부와 시스템 요구 사항은 App Store 페이지를 확인하세요. 구매 경로는 App Store 정품 확인 안내에서 확인할 수 있습니다. 앱의 일회성 구매는 회선 요금제와 별개입니다. 앱을 구매해도 서버 주소, 인증 정보, 구독이 제공되지는 않습니다. 따라서 여기서 말하는 프로토콜 선택은 이미 보유한 조건에 맞는 연결 방식을 고르고 현재 네트워크에서 적합한지 근거를 들어 판단하는 것입니다. 모든 환경에서 특정 프로토콜이 더 빠르다고 보장하는 의미는 아닙니다.

02 / Shadowsocks

Shadowsocks: 공유 키와 간결한 캡슐화

설계 목적과 적용 범위

Shadowsocks는 비교적 간결한 방식으로 프록시 요청을 전달하도록 설계되었습니다. 일반적인 구성에서는 공유 비밀번호와 지정된 암호화 방식을 사용합니다. 클라이언트가 목적지 주소를 확인한 뒤 프로토콜에 따라 요청을 캡슐화해 서버로 보내면 서버가 이후 연결을 설정합니다. 완전한 가상 네트워크를 중심 개념으로 삼는 방식이 아니므로, 원격 네트워크 인터페이스보다 ‘요청을 어떻게 전달할지’의 관점에서 이해하는 편이 적절합니다. 구현과 암호화 방식에 따라 세부 사항이 다르므로 Shadowsocks라는 이름이 붙은 모든 설정이 동일하다고 볼 수는 없습니다.

최근 구성에서는 기밀성과 무결성 검증을 함께 처리하는 AEAD 암호화 방식이 흔히 사용됩니다. 최신 변형 프로토콜은 키 형식, 세션 구성, 재전송 공격 방지에 추가 제약을 둘 수도 있습니다. 중요한 것은 이름이 더 복잡한 방식을 외우는 것이 아니라 클라이언트에서 선택한 방식이 서버 설정과 정확히 일치하는지 확인하는 것입니다. 공유 비밀번호가 항상 자유롭게 정할 수 있는 짧은 문구인 것도 아닙니다. 일부 방식은 정해진 길이와 인코딩을 갖춘 키를 요구합니다. 이전 설정의 비밀번호를 다른 방식에 그대로 옮겨도 서버가 자동으로 호환되지는 않습니다.

추측하지 말고 항목별로 확인하기

Add Server에서 먼저 Address와 Port가 실제 서버 수신 주소 및 포트를 가리키는지 확인한 다음 Method와 Password를 점검하세요. Address에는 도메인이나 주소를 입력할 수 있지만, 해석된 주소가 올바른 서버에 연결되어야 합니다. Port는 서버가 요청을 받는 포트이지 웹사이트의 기본 포트가 아닙니다. Method는 기기에서 조절하는 보안 수준이 아니라 양쪽이 공유해야 하는 프로토콜 설정입니다. Password의 대소문자, 뒤에 붙은 공백, 복사할 때 들어간 줄바꿈도 인증 실패를 일으킬 수 있습니다. 수정 전에는 기존 값을 보관하고 출처와 항목별로 대조하세요.

기존 설정에 추가 전송 항목이 있다면 연결 구성의 일부로 취급해야 합니다. 프로토콜 자체와 추가 캡슐화는 별개입니다. 외부 계층을 더하면 핸드셰이크 과정, 도메인 요구 사항, 네트워크 적응 방식이 바뀌고 문제 진단 단계도 늘어날 수 있습니다. 서버가 명확히 요구하고 현재 클라이언트가 해당 옵션을 지원하는 경우에만 설정하세요. 직접 만든 설정은 연결되지 않지만 같은 출처에서 가져온 설정은 작동한다면, 먼저 두 설정의 항목 차이를 비교하세요. 암호화 방식을 바꾸거나 의미를 모르는 옵션을 삭제하는 것은 우선순위가 아닙니다.

속도·배터리 사용량·일반적인 실패 원인

iPhone에서는 캡슐화 계층이 적으면 문제를 찾기 쉬울 수 있지만, 그렇다고 배터리 사용량이 반드시 줄어드는 것은 아닙니다. 암호화 연산은 전력 소비의 일부일 뿐이며 화면, 무선 신호, 재전송, 백그라운드 활동이 더 큰 비중을 차지할 수 있습니다. 최신 기기는 일부 암호화 알고리즘을 효율적으로 처리하지만, 최종 전송 속도는 서버 부하와 네트워크 혼잡에도 영향을 받습니다. 웹 탐색과 짧은 연결이 주된 용도라면 첫 요청이 제때 완료되는지 확인하세요. 지속 전송이 주된 용도라면 안정화 이후의 처리량과 기기 온도를 살펴보세요.

TCP 요청은 되지만 UDP를 사용하는 기능에 문제가 있다면 클라이언트 설정, 서버 지원 여부, 현재 네트워크에서 UDP에 접속할 수 있는지를 각각 확인해야 합니다. 웹페이지가 열린다고 모든 전송 방식이 정상이라는 뜻은 아닙니다. 도메인으로는 접속이 안 되지만 목적지 주소를 직접 사용하면 응답하는 경우에는 DNS가 어디에서 처리되는지와 해석 결과 차이도 확인해야 합니다. 연결을 시작한 뒤 멈춘다면 요청 전송, 응답 수신, 지속 전송 중 어느 단계에서 실패하는지 기록하고 같은 네트워크에서 다시 테스트하세요. 증상을 분리해 살펴보는 것이 Method를 계속 바꾸는 것보다 진단에 도움이 됩니다.

03 / VMess · VLESS

VMess와 VLESS: 인증과 전송을 따로 확인하기

두 프로토콜의 역할 차이

VMess는 사용자 식별, 요청 캡슐화, 관련 보안 기능을 프로토콜 안에 구성하며, 일반적인 설정에서는 사용자 식별자로 UUID를 사용합니다. 초기 프록시 프로토콜의 발전 과정에서 식별 가능한 사용자와 연결 처리 방식을 강조했고, 이후에는 인증 형식도 달라졌습니다. 사용자는 오래된 안내에 따라 호환 설정을 추측하기보다 서버에서 실제로 사용하는 조합을 확인해야 합니다. 구독 설정의 추가 항목은 이전 버전 호환이나 특정 구현 동작에 필요한 값일 수 있으므로 출처에서 제공한 값을 우선 유지하세요.

VLESS는 프로토콜 역할을 더 간결하게 구성합니다. 기본 프로토콜 자체는 데이터를 암호화하지 않으므로 적절한 보안 전송과 함께 사용해야 합니다. 인증 정보는 여전히 필요하지만 UUID가 있다고 해서 내용까지 암호화되는 것은 아닙니다. 어떤 계층이 보호를 제공하는지 판단하려면 외부 계층에서 TLS나 서버가 지정한 다른 보안 방식을 사용하는지 확인하세요. 화면에 같은 이름의 인증 입력란이 있다고 VMess와 VLESS를 서로 바꿔 쓸 수 있는 것은 아닙니다. 핸드셰이크와 캡슐화 방식이 다르므로 서버가 선택한 유형을 지원해야 합니다.

설정 항목 간 대응 관계 확인

UUID는 따옴표, 설명 문구, 불필요한 구분 기호를 추가하지 말고 그대로 복사하세요. 서버 주소와 TLS의 Server Name은 서로 다를 수 있습니다. 앞의 값은 연결할 대상을 지정하고, 뒤의 값은 TLS 핸드셰이크의 이름과 인증서 검증에 사용됩니다. 출처에서 서로 다른 값을 안내했다면 각각 해당 항목에 입력하세요. 별도 안내가 없다면 접속 가능한 다른 도메인으로 임의 대체하지 마세요. 기기의 시스템 시간도 확인할 필요가 있습니다. 시간이 잘못되면 인증서 유효 기간 판단에 영향을 주고 시간 조건을 사용하는 인증도 방해할 수 있습니다.

전송 옵션은 프로토콜 요청을 어떻게 전달할지 결정합니다. WebSocket을 사용할 때 Path는 서버가 진입점을 구분하는 경로이고 Host는 외부 요청을 라우팅하는 데 사용될 수 있습니다. 메모란이 아니므로 슬래시, 대소문자, 경로 접두사가 결과에 영향을 줄 수 있습니다. 일부 구성에서는 리버스 프록시로 하나의 주소에 있는 여러 서비스를 분리합니다. 포트에는 연결되지만 경로가 맞지 않으면 서버가 프로토콜 핸드셰이크 대신 웹페이지 응답을 반환할 수 있습니다. 이때 UUID를 계속 바꾸기보다 전송 방식과 진입점 설정을 먼저 확인하세요.

확장 설정은 단독으로 옮길 수 없습니다

일부 VLESS 설정에는 Flow나 기타 보안 핸드셰이크 항목이 포함됩니다. 이는 특정 연결 구성에 필요한 값이지 범용 가속 옵션이 아닙니다. 서버에서 작동하는 조합이라고 해서 현재 클라이언트가 필요한 기능을 모두 지원하는 것은 아닙니다. Add Server에서 실제로 설정할 수 있는 항목과 출처의 설명을 확인하세요. 필수 옵션이 없다면 호환성을 먼저 확인하고, 비슷해 보이는 다른 입력란이나 메모에 값을 넣지 마세요. 가져온 뒤에도 설정을 열어 주요 항목이 인식되었는지 확인하세요. 이름만 저장되고 핵심 설정은 누락될 수 있습니다.

속도 측면에서 추가 핸드셰이크와 전송 캡슐화는 첫 요청을 지연시킬 수 있지만, 연결이 안정된 뒤에는 네트워크나 서버가 병목이 될 수 있습니다. WebSocket이 다른 전송 방식보다 본질적으로 빠른 것은 아니며 VLESS가 더 간결하다고 VMess보다 배터리를 덜 쓰는 것도 아닙니다. 신호가 약할 때 반복해서 재연결하면 프로토콜 간 연산 차이보다 배터리에 더 큰 영향을 줄 수 있습니다. 비교할 때는 같은 네트워크와 비슷한 목적지, 동일한 작업을 유지하고 새 연결과 지속 사용을 각각 기록하세요. 한 번의 Connectivity Test 결과만으로 순위를 매기지 마세요.

문제 해결은 주소와 포트, 외부 핸드셰이크, 전송 진입점, 인증, 목적지 접속 순으로 진행할 수 있습니다. 외부 인증서 오류는 시간과 Server Name부터 확인하세요. 일반 웹페이지는 반환되지만 프록시가 작동하지 않으면 진입 경로를 확인하세요. 연결은 되지만 특정 기능이 실패하면 UDP 지원 여부와 라우팅을 확인하세요. 장시간 유휴 상태 후 첫 요청만 느리다면 연결이 다시 설정되었는지도 기록하세요. 설정 항목 외의 일반적인 증상은 문제 해결 가이드에서 확인할 수 있습니다. 앞 단계의 오류를 가리기 위해 인증서 검증을 끄지 마세요.

04 / TLS · Proxy

Trojan, HTTP, SOCKS5

Trojan은 TLS를 통해 보안 전송을 제공합니다

일반적인 Trojan 구성은 먼저 TLS 연결을 설정한 뒤 보호된 채널에서 프로토콜 인증과 요청 전달을 수행합니다. 설정 항목이 여러 계층으로 구성된 방식보다 간단해 보여도 TLS의 신원 검증은 반드시 이루어져야 합니다. 서버 인증서, 연결 주소, Server Name이 서로 일치해야 합니다. 비밀번호가 맞더라도 인증서 이름이 틀리면 문제가 해결되지 않습니다. 실패 원인을 찾을 때는 ‘TLS 연결에 성공했는지’와 ‘프로토콜 인증에 성공했는지’를 나누어 확인하면 모든 오류를 비밀번호 문제로 뭉뚱그리는 것보다 수월합니다.

Address는 서버 주소를 가리키며 Server Name은 서버 요구 사항 및 인증서와 일치해야 합니다. 주소를 직접 입력해 연결하더라도 TLS 검증을 위해 도메인을 지정해야 할 수 있습니다. 인증서 만료, 인증서 체인 누락, 기기 시간 오류, 이름 불일치 등은 핸드셰이크를 방해할 수 있습니다. 검증을 건너뛰면 통신 상대를 확인하는 수준이 낮아지므로 일반적인 해결 방법으로 사용해서는 안 됩니다. 서버에서 별도의 신뢰 설정을 사용하는 경우 명확한 관리 안내를 따르세요. 공용 네트워크에서 한 번 연결하려고 검사를 임의로 끄지 마세요.

HTTP와 SOCKS5의 기본 역할

HTTP 프록시는 애플리케이션 계층 프록시 요구에서 비롯되었으며, CONNECT 방식은 프록시가 목적지까지 터널을 만들도록 요청할 때 흔히 사용됩니다. 이름에 HTTP가 포함되어도 클라이언트와 프록시 사이에서 TLS를 사용한다는 뜻은 아닙니다. HTTPS 목적지에 접속할 때 목적지 TLS와 프록시 연결 보호는 서로 별개입니다. 목적지 데이터가 암호화되어도 모든 설정에서 프록시 인증 정보까지 같은 수준으로 보호되는 것은 아닙니다. 일반 HTTP 프록시와 TLS로 프록시에 연결하는 방식을 구분하고 서버에서 실제로 지원하는 설정을 사용하세요.

SOCKS5는 목적지 주소와 포트를 포함한 다양한 요청을 전달할 수 있으며 인증과 UDP 연결 등의 방식을 정의합니다. 자체적으로 일반적인 콘텐츠 암호화를 보장하지 않으며, 사용자 이름과 비밀번호를 사용한 인증도 전송 암호화와는 다릅니다. 신뢰할 수 있는 기존 네트워크나 별도의 보호 방식이 명확히 마련된 환경에 적합합니다. 사용 전에는 클라이언트와 서버 사이의 데이터를 어느 계층에서 보호하는지 확인해야 합니다. UDP 지원 여부도 규격상 가능한 기능만으로 판단하지 마세요. 서버 구현, 인증 방식, 현재 클라이언트가 실제로 지원하는 조합을 하나씩 확인해야 합니다.

프록시 인증과 목적지 인증을 혼동하지 마세요

프록시 사용자 이름과 비밀번호는 프록시 서비스에 접속할 때 사용하며 목적지 웹사이트 계정과는 다릅니다. 서버가 인증을 요구하면 값을 비워 두었을 때 거부될 수 있고, 서버에서 인증을 사용하지 않으면 임의의 계정을 입력해도 보호가 강화되지 않습니다. 인증 관련 오류가 나타나면 응답이 프록시에서 왔는지 목적지 웹사이트에서 왔는지 먼저 확인하세요. 일반 웹페이지는 열리지만 특정 앱이 실패한다면 앱의 요청 방식, 목적지 포트, UDP 요구 사항, 규칙이 원인일 수도 있습니다. 사용자 이름과 비밀번호가 일부 사이트에서만 작동한다고 단정할 수는 없습니다.

iPhone에서 이들 프로토콜의 실제 전력 소비는 핸드셰이크 횟수, 연결 재사용, 무선 활동에 따라 달라집니다. TLS 연결을 설정할 때는 추가 연산과 왕복이 필요하지만, 연결을 맺은 뒤에는 후속 요청을 처리할 수 있습니다. 연결을 계속 끊었다가 다시 설정하면 적절한 기존 연결을 유지하는 것보다 자원을 더 쓸 수 있습니다. 반대로 연결을 유지하려고 무선 통신을 자주 깨우는 데에도 비용이 듭니다. 따라서 TLS를 쓴다는 이유만으로 전력 소비가 높다고 판단하거나 암호화가 없는 유형이 무조건 나은 선택이라고 볼 수 없습니다. 보안과 호환성을 먼저 충족해야 합니다.

문제를 진단할 때는 서버가 어떤 유형의 프록시를 제공하는지 확인한 뒤 TLS, 인증, UDP가 필요한지 살펴보세요. Trojan의 인증서 오류는 TLS 관련 항목을 점검하고, HTTP 프록시의 거부 응답은 인증 또는 CONNECT 권한을 확인하세요. SOCKS5 세션은 만들어지지만 특정 기능이 실패한다면 요청 명령 지원 여부와 데이터그램 경로를 확인해야 합니다. 회사나 기관에서 제공한 프록시는 네트워크 관리 요구 사항을 준수하고 인증 방식이나 목적지 포트 제한을 임의로 변경하지 마세요. 성능 테스트는 허용된 범위에서 진행해야 하며, 권한 제한을 프로토콜 속도 문제로 오해하지 않도록 주의하세요.

05 / WireGuard

WireGuard: 키·주소·터널 라우팅

단일 요청이 아닌 가상 네트워크로 이해하기

WireGuard는 암호화된 3계층 터널을 중심으로 설계되어, 목적지 요청에 따라 프록시 세션을 만드는 앞서 다룬 유형과 다릅니다. 공개 키와 비공개 키로 통신 상대를 식별하고 UDP를 통해 캡슐화된 네트워크 패킷을 전달합니다. 프로토콜 범위를 작게 유지하고 암호화 조합을 명확히 하여 사용자가 여러 암호화 알고리즘 중 하나씩 선택하지 않아도 됩니다. 대신 클라이언트 사용자는 키의 소유 관계, 터널 주소, 상대 Endpoint, 라우팅 범위를 확인해야 합니다. 항목 하나만 잘못되어도 최종 접속에 영향을 줄 수 있습니다.

Private Key는 이 기기의 신원 정보이므로 비밀로 보관해야 합니다. Public Key는 연결 상대를 식별하는 데 사용됩니다. 설정에 적힌 ‘로컬’과 ‘상대’가 각각 누구를 가리키는지 확인하고 서버의 공개 키를 로컬 비공개 키로 입력하지 마세요. 선택 항목인 Preshared Key는 추가 공유 키이며 공개 키와 비공개 키를 대체하는 일반 비밀번호가 아닙니다. 구독이나 설정에서 해당 값이 제공되었다면 그대로 사용하세요. 문제 해결을 위해 설정을 공유할 때는 비공개 키와 다른 인증 정보도 제거해야 합니다. 서버 이름만 가린 것으로는 충분하지 않습니다.

Endpoint·Address·Allowed IPs

Endpoint는 상대 장치에 도달하기 위한 실제 주소와 UDP 포트입니다. 터널 Address는 기기가 터널 내부에서 사용하는 주소로, 두 항목은 서로 다른 네트워크 계층에 속합니다. 공용 서버 주소를 터널 주소에 입력하거나 터널 내부 주소를 Endpoint로 사용하면 연결이 설정되지 않을 수 있습니다. Endpoint에 도메인을 사용한다면 터널이 시작되기 전에 사용할 수 있는 이름 해석 경로도 필요합니다. 터널을 켜자마자 Endpoint를 해석하지 못한다면 먼저 키를 바꾸기보다 이름 해석의 순환 의존성을 확인하세요.

Allowed IPs는 상대와 관련된 주소 범위를 지정하며 WireGuard에서는 라우팅 선택 및 수신 출발지 주소 검증에도 사용됩니다. 웹사이트 허용 목록이 아니며 범위를 임의로 넓힌다고 접속 성공률이 높아지는 것도 아닙니다. 클라이언트가 이 범위를 자체 정책과 어떻게 결합하는지 현재 설정에서 확인하세요. 범위가 너무 좁으면 필요한 트래픽이 빠질 수 있고, 너무 넓으면 관련 없는 트래픽이 터널로 들어갈 수 있습니다. 터널 핸드셰이크에 성공하더라도 서버에서 해당 트래픽을 전달하지 않으면 목적지에 접속할 수 없습니다.

모바일 네트워크 전환과 연결 유지의 균형

기기가 Wi-Fi와 셀룰러 네트워크 사이를 전환하면 외부 주소와 NAT 매핑이 달라질 수 있습니다. WireGuard는 인증된 패킷을 받으면 상대 Endpoint 정보를 갱신할 수 있지만, 모든 네트워크 전환이 즉시 완료된다는 뜻은 아닙니다. 새 네트워크에서 UDP를 허용해야 하며 서버도 유효한 트래픽을 받아야 합니다. 오랫동안 유휴 상태였던 연결에서 첫 요청이 느리다면 NAT 매핑이 만료되었거나 통신이 다시 설정되는 중일 수 있습니다. 지속 사용, 유휴 상태에서 복귀, 네트워크 전환 후 복구를 각각 기록하고 하나의 안정성 점수로 합치지 마세요.

Persistent Keepalive는 필요한 경우 네트워크 매핑을 유지하기 위해 주기적으로 데이터를 전송합니다. 자주 보낼수록 좋은 것은 아니며 모든 설정에 동일한 값을 적용해서도 안 됩니다. 셀룰러 신호가 약하면 작은 패킷도 무선 통신을 깨워 대기 중 전력 소비에 영향을 줄 수 있습니다. 외부에서 기기로 연결될 필요가 없다면 추가 연결 유지가 도움이 되지 않을 수도 있습니다. 서버 요구 사항과 실제 네트워크 조건에 맞게 설정하고, 같은 유휴 시간 후 복구 상태를 비교하세요. 옵션을 켠 직후의 순간적인 배터리 소모만 살펴봐서는 안 됩니다.

핸드셰이크는 정상이지만 일부 페이지가 멈춘다면 라우팅, DNS, MTU를 확인하세요. 터널 캡슐화에는 추가 바이트가 필요합니다. 경로에서 큰 패킷을 제대로 처리하지 못하면 작은 요청은 성공하지만 응답이 큰 요청은 멈출 수 있습니다. MTU를 조정할 때는 기존 설정을 보관하고 조금씩 변경해 확인하세요. 경험에 따라 극단적인 값을 입력하면 처리량이 떨어질 수 있습니다. WireGuard는 완전한 터널 설정을 보유하고 주소 계층 연결이 필요한 경우에 적합합니다. 다른 프로토콜의 서버 정보만 있다면 키 쌍을 직접 만든 것만으로 WireGuard 서버로 바꿀 수는 없습니다.

06 / Hysteria2

Hysteria2: QUIC과 패킷 손실이 있는 네트워크

QUIC은 어느 계층을 바꾸나요?

Hysteria2는 QUIC 기반의 프록시 전송을 사용합니다. QUIC은 일반적으로 UDP 위에서 실행되며 보안 핸드셰이크, 스트림 관리, 혼잡 제어를 함께 처리합니다. 그 가치를 이해하려면 네트워크 조건을 살펴봐야 합니다. 왕복 지연이 크거나 패킷 손실이 발생하거나 사용 가능한 대역폭이 변할 때 전송 계층의 복구 및 전송 속도 조절이 체감 성능에 큰 영향을 줄 수 있습니다. TCP 데이터를 UDP에 담는다고 자동으로 빨라지는 것은 아니며 물리적 대역폭 제한을 우회하지도 않습니다. 서버 접속 구간, 무선 품질, 목적지 응답 속도에도 한계가 있습니다.

하나의 TCP 연결로 여러 작업을 처리하는 구조에서는 하위 계층의 패킷 손실이 이후 데이터 전달에 영향을 줄 수 있습니다. QUIC의 스트림 구조는 신뢰성 있는 전송 순서 때문에 서로 다른 스트림이 함께 막히는 현상을 줄일 수 있습니다. 하지만 각 신뢰성 스트림 안의 데이터는 여전히 순서에 따라 복구해야 하며 혼잡 제어도 공유 연결에 영향을 줍니다. 애플리케이션이 자체적으로 신뢰성 있는 전송을 사용하면 캡슐화 후 여러 계층에서 피드백이 발생할 수도 있습니다. 따라서 QUIC 기반이라고 패킷 손실 비용이 없어지는 것은 아니며 프로토콜 설명만으로 특정 웹페이지의 로딩 시간을 예측할 수도 없습니다.

인증·인증서·대역폭 설정

수동으로 설정을 확인할 때는 Address, Port, 인증 문자열, TLS의 Server Name을 먼저 점검하세요. Hysteria2 서버는 해당 프로토콜을 실제로 제공해야 하며 이름이 비슷한 다른 설정을 대신 사용할 수 없습니다. 인증서 검증은 여전히 중요합니다. 이름 불일치, 만료된 인증서, 기기 시간 오류는 연결을 방해할 수 있습니다. 출처에서 난독화 등의 추가 항목을 제공했다면 양쪽에서 해당 기능을 켰는지, 값이 일치하는지 확인하세요. 이 항목은 비밀번호를 대신하는 입력란이 아니며 누락되거나 잘못 설정되면 인증 전에 통신이 예상과 다르게 동작할 수 있습니다.

일부 설정에서는 혼잡 제어 동작을 위해 업로드 및 다운로드 대역폭을 지정할 수 있습니다. 이 값은 전송 조절에 사용하는 입력값이지 제한이 해제된 뒤의 속도를 보장하는 수치가 아닙니다. 실제 네트워크보다 훨씬 큰 값을 넣으면 지속적인 혼잡, 패킷 손실, 재전송이 발생하고 다른 앱의 사용 경험이 나빠질 수도 있습니다. 혼잡 제어 방식에 따라 값의 활용 방법도 다릅니다. 출처의 안내와 클라이언트에서 실제로 제공하는 옵션을 기준으로 이해하세요. 처음에는 보수적이고 이유를 설명할 수 있는 설정으로 테스트한 다음, 지속적으로 관찰한 결과를 바탕으로 조정 여부를 결정하세요.

UDP 연결 가능성은 전제 조건이지 성공을 보장하지 않습니다

일부 네트워크는 UDP를 제한하거나 품질이 불안정하며 TCP와 다르게 처리하기도 합니다. 같은 장소에서 일반 웹페이지에 직접 접속할 수 있어도 QUIC 경로까지 작동한다고 볼 수 없습니다. 포트에서 뚜렷한 오류가 나타나지 않아도 프로토콜 핸드셰이크가 완료된 것은 아닙니다. Hysteria2가 특정 Wi-Fi에서만 실패한다면 먼저 이미 사용 가능한 다른 유형과 경로를 비교한 뒤 서버에 요청이 도착했는지 확인하세요. 인증, Server Name, 대역폭을 동시에 바꾸면 네트워크 제한과 설정 오류를 구분할 수 없습니다.

iPhone에서 높은 처리량을 내면 무선 통신과 프로세서가 활발히 작동해 전력 소비가 늘 수 있습니다. 하지만 같은 작업을 더 빨리 끝내면 활성 상태로 머무는 시간이 줄어들 수도 있습니다. 따라서 전송 중 기기 온도뿐 아니라 작업을 마친 뒤의 총 배터리 소모와 유휴 상태로 돌아가는 시간도 비교하세요. 패킷 손실이 많은 환경에서는 더 적극적인 전송 방식이 처리량을 높이는 대신 전력을 더 쓸 수 있습니다. 결론은 테스트한 기기, 네트워크, 작업에 한정해야 합니다. ‘Hysteria2는 항상 배터리를 더 많이 쓴다’ 또는 ‘QUIC은 언제나 배터리를 아낀다’고 일반화할 수 없습니다.

Hysteria2를 시험하려면 먼저 사용할 수 있는 Hysteria2 서버가 있어야 하고 현재 네트워크의 UDP 품질이 충분하며, 작업이 실제로 높은 지연이나 패킷 손실의 영향을 받아야 합니다. 네트워크가 안정적이고 짧은 요청이 대부분이라면 지속 전송만큼 효과가 뚜렷하지 않을 수 있습니다. 자세한 원리는 Hysteria2와 QUIC 기술 노트에서 확인하세요. 테스트 중 간헐적으로 멈추면 당시 네트워크 유형, 네트워크 전환 여부, 유휴 상태에서 막 복귀했는지를 기록한 뒤 패킷 손실, 혼잡, 서버 부하를 확인하세요. 대역폭 설정 부족만을 원인으로 단정하지 마세요.

07 / Measurement

iOS에서 속도 및 배터리 사용량 테스트

먼저 완료할 작업을 정하세요

‘빠르다’는 첫 응답 시간, 지속 처리량, 상호작용 안정성 등 여러 기준을 포함합니다. 첫 응답 시간은 새 페이지를 열 때까지의 대기 시간에 영향을 주고 지속 처리량은 큰 파일 전송에 영향을 줍니다. 상호작용 안정성은 실시간 기능이나 짧은 요청이 반복해서 멈추는지와 관련됩니다. Connectivity Test 결과는 해당 테스트 방식에서 측정한 일부 경로만 보여 주며 모든 목적지, UDP 기능, 장시간 사용을 나타내지는 않습니다. 비교를 시작하기 전에 같은 페이지 묶음을 연속으로 둘러보거나 같은 테스트 자료를 전송하는 등 작업을 구체적으로 정하세요. 매번 다른 작업을 하면서 체감만 비교하지 마세요.

프로토콜 차이만 따로 비교하려면 서버 위치, 리소스, 이후 연결 경로가 비슷해야 합니다. 두 설정이 서로 다른 서버를 사용한다면 관찰한 차이는 두 연결 구성의 차이일 뿐 프로토콜만의 영향이라고 단정할 수 없습니다. 주소가 같아도 서버가 서로 다른 진입점에 다른 리소스를 할당할 수 있습니다. 이런 조건을 통제할 수 없어도 실제 사용에 적합한 방식을 선택할 수는 있습니다. 다만 결론은 ‘현재 네트워크에서는 이 설정이 더 적합하다’로 표현해야 하며 특정 프로토콜이 전반적으로 더 빠르다고 단정해서는 안 됩니다.

반복 가능한 측정 순서 만들기

같은 기기, 네트워크, 위치, 비슷한 시간대를 유지하고 결과에 뚜렷한 영향을 줄 수 있는 백그라운드 전송은 일시 정지하세요. 먼저 기본 네트워크가 정상인지 확인하고 설정 하나를 켜서 작업을 수행한 다음 다른 설정으로 바꿔 같은 작업을 반복합니다. 네트워크가 시간에 따라 변하는 영향을 줄이려면 테스트 순서를 번갈아 진행할 수 있습니다. 각 조건에서 여러 번 반복해 범위를 기록하고 가장 빨랐던 결과 하나만 남기지 마세요. 새 연결과 이미 연결된 상태는 따로 측정해야 합니다. 새 연결에는 이름 해석과 핸드셰이크가 포함되고 기존 연결은 연결 재사용과 캐시의 영향을 받을 수 있으므로 두 결과를 같은 평균에 넣지 마세요.

Wi-Fi와 셀룰러 네트워크는 따로 기록해야 합니다. 이동 중 신호가 변하면 결과를 판단하기가 특히 어렵습니다. 테스트하면서 위치를 옮기거나 설정을 바꾸지 마세요. 네트워크 전환 후 복구를 확인해야 한다면 이를 별도 작업으로 두고 전환 전후 요청 복구에 걸린 시간과 수동 재연결 여부를 기록하세요. 간헐적인 실패가 발생하면 원래 조건을 유지한 채 다시 테스트하고 즉시 여러 설정을 바꾸지 마세요. 가끔 높은 최고 속도가 나오지만 자주 멈추는 방식보다 여러 번 안정적으로 작업을 완료하는 구성이 일상적인 사용에 더 적합한 경우가 많습니다.

사용 중과 대기 중 전력 소비를 구분하세요

배터리 잔량은 대략적인 수치입니다. 몇 분 동안의 작은 변화만으로 프로토콜 차이를 입증하기는 어렵습니다. 화면 밝기, 기기 온도, 신호 세기, 백그라운드 앱이 프로토콜 오버헤드보다 더 큰 영향을 줄 수 있습니다. 사용 중 전력 소비를 비교하려면 화면과 작업을 동일하게 유지하고 같은 양의 작업을 완료하는 데 드는 전체 비용을 살펴보세요. 대기 중 소비를 비교할 때는 유휴 시간과 네트워크 환경을 같게 하고 지속적인 트래픽이나 잦은 재연결이 있는지 확인하세요. 한쪽은 장시간 동영상을 재생하고 다른 쪽은 대기 상태였던 결과를 비교해 어느 쪽이 전력을 덜 쓰는지 판단하지 마세요.

시스템의 배터리 사용량 통계와 Shadowrocket의 Data는 참고 자료가 될 수 있지만 집계 기준은 서로 다릅니다. 전송 바이트 수를 배터리 사용량으로 바로 환산할 수 없으며 시스템에서 네트워크 확장 기능과 앱 활동을 분류하는 방식도 특정 프로토콜만의 비용을 정확히 보여 주지 않을 수 있습니다. 사용량이 비정상적으로 높다면 우선 재시도, 주기적인 요청, 연결 유지, 잦은 연결 해제가 있는지 살펴보고 On Demand의 작동 조건을 확인하세요. 적절한 자동 연결 설정은 사용 목적에 도움이 될 수 있지만 규칙이 복잡할수록 배터리를 아끼는 것은 아닙니다. 실제로 어떤 설정이 적용되는지 검증해야 합니다.

문제 해결 기록에는 네트워크 유형, 프로토콜 유형, 실패 시간대, 요청 단계, 처리 결과 등 필요한 정보만 남기세요. 로그를 외부에 공유하기 전에 구독 주소, 인증 정보, 접속한 도메인, 개인 네트워크 정보가 포함되어 있는지 확인하세요. 구독 링크에는 접속 자격 증명이 들어 있을 수 있으므로 전체를 게시해서는 안 됩니다. 여러 출처의 설정을 정리할 때는 여러 구독을 분류하고 정리하는 방법을 참고하세요. 성능을 비교하기 전에 테스트 기록이 어느 서버에 해당하는지 명확히 해야 합니다. 그렇지 않으면 이름이 중복되어 비교 대상이 어느새 바뀔 수 있습니다.

08 / Decision

사용 환경에 맞게 선택하고 최종 검증하기

먼저 조건에 맞지 않는 조합을 제외하세요

선택 순서는 사용 가능 여부, 보안 경계, 작업 호환성, 성능과 배터리 사용량이어야 합니다. 현재 보유한 서버가 실제로 지원하는 유형을 나열하고 현재 네트워크에서 사용할 수 없거나 클라이언트에서 필요한 항목을 설정할 수 없는 조합은 제외하세요. 그런 다음 인증과 인증서 검증이 올바른지 확인하고, 필요한 작업에 UDP나 터널 내부 주소가 사용되는지 살펴보세요. 이런 조건이 충족되어야 속도를 비교할 수 있습니다. 설정 항목이 적다고 자동으로 더 안정적인 것도 아니며 구성이 복잡하다고 더 안전한 것도 아닙니다. 각 계층의 역할을 설명하고 정확히 검증할 수 있어야 합니다.

일반적인 웹 탐색과 앱 사용에는 이미 안정적으로 작동하고 설정 출처가 명확한 구성을 유지하는 것이 좋습니다. 프로토콜 이름이 달라졌다는 이유만으로 모든 설정을 다시 만들 필요는 없습니다. 주소 계층 터널과 특정 내부 네트워크 대역이 필요하다면 완전한 WireGuard 설정이 적합합니다. 패킷 손실이 많거나 지연이 큰 환경에서는 사용할 수 있는 Hysteria2 서버를 테스트 후보로 삼을 수 있습니다. HTTP 또는 SOCKS5 설정만 있다면 연결 보호 방식과 지원 범위를 먼저 이해해야 합니다. 이름이 간단하다고 모든 민감한 접속에 사용할 수 있다고 가정하지 마세요.

프로토콜과 규칙을 함께 검증하기

가져오기를 마친 뒤 Home에서 선택된 서버를 확인하고 Global Routing도 살펴보세요. 일시적으로 Proxy를 사용하면 일부 문제가 트래픽 분기에서 비롯되는지 확인하는 데 도움이 되지만, 최종 Config 검증을 생략해서는 안 됩니다. Config로 돌아가 예상한 파일이 활성화되어 있는지 확인하고 대상 요청에 최종적으로 어떤 정책이 적용되는지 살펴보세요. 규칙은 위에서 아래로 검사하며 처음 일치한 규칙이 처리 방식을 결정합니다. 위쪽의 범위가 넓은 규칙이 먼저 일치하면 아래쪽의 구체적인 규칙은 적용되지 않습니다. 프로토콜이 작동하는지와 규칙이 올바른지는 별도로 확인해야 합니다.

아래 내용은 Shadowrocket 텍스트 설정의 규칙 예시입니다. 규칙의 역할을 설명하기 위한 것이며 서버 설정이 아니므로 기존 전체 설정 파일을 덮어쓰는 데 사용해서는 안 됩니다. 예시에 나온 도메인은 설명용이며 PROXY, DIRECT, REJECT는 서로 다른 처리 정책을 뜻합니다. IP-CIDR은 로컬 네트워크 주소 범위를 지정할 수 있고 FINAL은 앞선 규칙과 일치하지 않은 연결을 처리합니다. 이 규칙을 사용하기 전에 기존 설정의 정책 의미가 실제 작업에 맞는지 확인하세요. 프록시 접속 실패를 숨기려고 DIRECT 범위를 무작정 넓히거나 모든 로컬 요청을 원격으로 보내지 마세요.

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

최종 검증에는 DNS도 포함해야 합니다. 도메인 규칙과 주소 규칙은 서로 다른 정보에 의존합니다. 해석 결과, 캐시, IPv4 / IPv6 연결 가능 여부가 규칙 일치 결과를 바꿀 수 있습니다. 어떤 도메인이 때때로 다른 주소로 연결되더라도 프로토콜 설정이 달라졌다는 뜻은 아닙니다. 로그에서 요청된 도메인이나 주소, 실제로 일치한 항목, 적용된 정책을 먼저 확인한 뒤 규칙을 바꿀지 판단하세요. 자세한 순서는 규칙 우선순위와 FINAL 대체 정책에서 확인할 수 있습니다. 이 프로토콜 가이드의 연결 테스트를 트래픽 분기 설정 안내로 오해하지 마세요.

되돌릴 수 있는 일상 설정 유지하기

최종적으로 검증된 기준 설정을 유지하세요. 프로토콜 유형과 주요 항목의 출처가 명확하고, 일상적으로 사용하는 목적지에 접속할 수 있으며, 유휴 상태나 네트워크 전환 후에도 예상대로 복구되어야 합니다. 새 구성을 시험할 때는 기존 설정을 복사해 이름을 명확히 지정하고 유일하게 사용할 수 있는 설정을 덮어쓰지 마세요. 구독이 갱신되면 서버 주소나 항목이 바뀌었을 수 있으므로 선택된 설정을 다시 확인하세요. 이름이 중복되면 잘못 선택할 수도 있습니다. 기기를 바꾸기 전에는 필요한 설정을 백업하고 복원 후에는 이용 권한, 현재 Config, 실제 적용 정책을 다시 검증하세요. 앱 구매 내역만으로 모든 로컬 설정이 복원된다고 가정해서는 안 됩니다.

원인을 찾지 못했다면 기본 네트워크가 정상인지, Endpoint에 접속할 수 있는지, TLS가 성공했는지, 인증을 통과했는지, 목적지에 예상한 정책이 적용됐는지 순서대로 정리한 다음 문제 해결 가이드를 확인하세요. 가져오기와 첫 연결 절차를 다시 진행해야 한다면 사용법 안내로 돌아가세요. 최종적으로 갖춰야 할 것은 설명하고 재현하며 되돌릴 수 있는 설정이지 네트워크 조건과 무관한 프로토콜 순위표가 아닙니다. 클라이언트 및 시스템 요구 사항은 App Store 페이지에서 확인하고 서버 설정은 서비스 제공업체에 문의하세요. 이 두 종류의 정보를 혼동하지 마세요.