Shadowrocket 프로토콜 가이드

01 / FOUNDATIONS

프로토콜 계층과 iOS 성능 판단

연결을 나누어 확인하기

Add Server에서 유형을 선택해도 연결 동작 중 일부만 정해집니다. 프록시 요청에는 서버 주소, 포트, 인증, 기반 전송 방식, 암호화, 대상 주소 확인, 트래픽 선택이 모두 관여합니다. 프로토콜은 클라이언트와 서버가 합의한 메시지 형식이고, 전송 방식은 메시지를 전달하는 통로라고 볼 수 있습니다. 같은 프로토콜도 전송 방식에 따라 연결 과정, 추가 오버헤드, 장애 지점이 달라질 수 있습니다. 반대로 같은 전송 방식을 사용하더라도 프로토콜이 다르면 인증 필드를 서로 바꿔 쓸 수 없습니다.

예를 들어 VLESS는 TLS, WebSocket 등의 조건과 조합할 수 있지만, VLESS를 선택했다고 해서 이러한 조건이 자동으로 적용되는 것은 아닙니다. 서버가 특정 경로를 요구한다면 클라이언트는 프로토콜 이름만으로 그 경로를 알아낼 수 없습니다. 서버가 일반 TCP만 지원하는 경우, 클라이언트에서 다른 전송 방식을 추가해도 호환되지 않습니다. 입력하기 전에 보유한 정보를 '연결할 곳', '신원을 증명하는 방법', '사용할 통로', '상대 서버 확인 방법'으로 나누세요. 필수 정보가 빠졌다면 원본 설정을 다시 확인해야 합니다.

처리량, 응답 시간, 안정성은 서로 다른 지표입니다

속도는 보통 웹페이지를 처음 열 때까지 걸리는 시간, 다운로드가 계속될 때의 처리량, 통화나 상호작용 중 발생하는 지연 변동 등 세 가지 이상으로 나뉩니다. 핸드셰이크가 많은 조합은 첫 연결이 느릴 수 있지만 장시간 연결에서는 안정적으로 데이터를 전송할 수 있습니다. 대역폭이 넓어도 대기열이 길어지면 상호작용은 느려질 수 있습니다. Connectivity Test는 연결 불가 여부를 확인하는 데 도움이 되지만 테스트 대상, 연결 재사용 여부, DNS 캐시 여부에 따라 결과가 달라집니다. 실제 서비스 테스트를 대신할 수는 없습니다.

iOS에서는 앱 트래픽이 시스템 네트워크 확장을 거치므로 성능이 프로토콜 알고리즘뿐 아니라 무선 신호, 서버와의 거리, 서버 부하, 대상 웹사이트의 영향을 받습니다. Wi-Fi 신호가 약하면 암호화 연산보다 패킷 재전송이 속도에 더 큰 영향을 줄 수 있습니다. 모바일 네트워크가 자주 바뀌면 지속적인 처리량보다 재연결 대기 시간이 더 중요할 수 있습니다. 따라서 '특정 프로토콜이 항상 가장 빠르다'는 말은 재현 가능한 기술적 전제가 없습니다. 같은 기기와 네트워크에서 같은 작업을 테스트한 경우로 결론을 한정해야 합니다.

배터리 사용량은 주로 연결 사용 방식에 좌우됩니다

프로토콜 이름만으로 배터리 사용량을 비교할 수는 없습니다. 셀룰러 무선 모듈의 잦은 활성화, 약한 신호에서의 반복 재시도, 짧은 연결의 과다 사용, 지나치게 잦은 연결 유지, 백그라운드에서의 지속적인 전송은 모두 배터리 소모를 늘릴 수 있습니다. 핸드셰이크 비용이 크더라도 안정적으로 재사용되는 연결이, 자주 실패해 재연결하는 가벼운 연결보다 배터리를 더 많이 소모한다고 단정할 수 없습니다. 기기 발열은 화면 밝기, 앱 부하, 충전 상태도 함께 고려해야 하며, 클라이언트를 켠 뒤 발생했다는 시간적 선후만으로 원인을 정할 수 없습니다.

배터리 사용량을 테스트할 때는 같은 길이의 동영상 재생이나 문서 탐색처럼 대표적인 사용 패턴을 정한 뒤 시스템 배터리 화면에서 사용 시간과 백그라운드 동작을 확인하세요. 한쪽 테스트에서는 Connectivity Test를 계속 실행하고 다른 쪽에서는 대기 상태를 유지하는 식으로 비교하지 마세요. 신호 조건이 다른 두 테스트 결과는 참고하기 어렵습니다. 배터리 소모가 비정상적으로 보이면 백그라운드에서 연결 실패가 반복되는지, 구독 업데이트가 재시도 중인지, On Demand가 계속 연결을 시작하는지 먼저 확인하세요.

프로토콜 기능은 전체 경로를 기준으로 확인해야 합니다

UDP를 지원하는 프로토콜이라고 해서 현재 서버, 전송 조합, 대상까지 UDP를 전달할 수 있다는 뜻은 아닙니다. 클라이언트 설정, 서버 설정, 네트워크에서의 UDP 도달성, 출구 정책이 모두 맞아야 합니다. 반대로 웹페이지가 열린다고 해서 UDP를 사용할 수 있다고 볼 수도 없습니다. 웹페이지는 TCP만 사용할 수 있기 때문입니다. 문제를 기록할 때는 '네트워크 정상'이나 '프로토콜 오류'라고만 쓰지 말고, 해당 서비스가 어떤 전송 방식을 사용했는지 명시하세요.

이 페이지의 iOS 설명은 모바일 기기에서 고려할 동작상의 차이를 다루며, 다른 플랫폼에서 해당 프로토콜을 지원하지 않는다는 뜻은 아닙니다. 구체적인 필드는 현재 Shadowrocket 인터페이스와 서버 설정을 기준으로 확인하세요. 설치 및 다운로드 정보는 전체 플랫폼 다운로드에서 확인할 수 있습니다. 이 페이지에서는 설치 절차를 반복하지 않으며, 기기 모델만으로 확인되지 않은 호환 조건을 추정하지 않습니다.

02 / SHADOWSOCKS

Shadowsocks: 공유 인증 정보와 암호화 방식

설계 배경과 적용 범위

Shadowsocks는 클라이언트와 서버가 미리 합의한 인증 정보와 암호화 방식으로 프록시 데이터를 주고받는 구조이며, 기본 구성은 비교적 간단합니다. 기반 필드를 임의로 바꿔 끼울 수 있는 범용 컨테이너는 아닙니다. 양쪽이 같은 프로토콜 형식을 이해하고 암호화 방식도 일치해야 합니다. 사용자에게 중요한 것은 이름을 외우는 것이 아니라 구독에 표시된 유형, 서버, 포트, 비밀번호, 암호화 방식이 같은 서비스 항목에 속하는지 확인하는 것입니다.

최근 인증 암호화 방식은 데이터의 기밀성과 무결성을 함께 처리해 인증 없이 암호화만 하는 방식의 문제를 방지합니다. 세대나 확장 방식에 따라 필요한 키 형식이 다를 수 있으므로 일반 비밀번호를 아무 방식에나 붙여 넣어서는 안 됩니다. 클라이언트 목록에 특정 방식이 있다고 해서 현재 서버에서도 그 방식을 사용한다는 뜻은 아닙니다. 서비스 제공업체가 안내한 전체 조합을 우선 사용하고, 이름이 최신이라는 이유만으로 암호화 방식만 바꾸지 마세요.

Server, Port, Password, Method의 관계

Server는 프록시 서버의 주소로 도메인이나 IP를 사용할 수 있습니다. Port는 해당 서버가 수신하는 포트이며 대상 웹사이트의 포트가 아닙니다. Password는 선택한 암호화 방식과 함께 인증 정보나 키 재료를 구성합니다. 대소문자를 구분하며 끝의 공백도 결과를 바꿀 수 있습니다. Method는 서버 설정과 일치해야 합니다. 잘못된 방식을 선택하면 하위 계층 연결은 성립해도 유효한 서비스 응답이 없을 수 있으며, '방식 불일치'라고 명확히 표시되지 않을 수도 있습니다.

가져온 항목이 목록에 있지만 연결되지 않는다면 우선 이 네 가지 값을 원본 정보와 하나씩 대조하세요. 복사 과정에서 전각 기호, 줄바꿈, 잘림이 발생했는지, 관리 페이지 포트를 프록시 포트로 착각하지 않았는지 특히 확인하세요. 특정 인코딩 키가 필요한 설정은 원래 인코딩 형식을 유지하고 임의로 다시 계산하거나 문자를 삭제하지 마세요. 구독에 표시된 이름은 메모일 뿐입니다. 이름에 지역이나 프로토콜이 적혀 있다고 해서 내부 필드가 올바르다는 보장은 없습니다.

추가 매개변수는 기본 필수 항목이 아닙니다

일부 Shadowsocks 항목에는 추가 전송 방식이나 확장 매개변수가 포함됩니다. 이런 매개변수는 스위치가 보인다고 해서 켜야 하는 성능 향상 기능이 아니라 서버 요구 사항의 일부입니다. 원본 구독에 해당 정보가 없다면 다른 설정 항목에서 복사하지 마세요. 특히 경로, 호스트 이름, 추가 인증 정보는 특정 서버 배포 방식에 묶이는 경우가 많습니다. 잘못 입력하면 기본 서버와 비밀번호가 정확해도 연결되지 않을 수 있습니다.

항목을 직접 만들 때는 서버에서 명시한 최소 필드부터 입력하고 연결을 확인한 뒤, 확장이 필요하면 원본 정보를 보며 하나씩 추가하세요. 기존 구독이 정상 작동한다면 '최적화'를 위해 다시 수동 입력할 필요가 없습니다. 구독 업데이트 후 필드가 원래대로 돌아간다면 구독이 해당 항목을 관리하고 있다는 뜻입니다. 같은 자동 업데이트 항목을 반복해서 수정하지 말고 원본 설정을 확인하세요. 테스트 항목을 별도로 만들고 용도를 적어 두면 비교와 복구가 쉽습니다.

iOS에서 적합성을 판단하는 방법

신호가 안정적이고 서버 리소스가 충분한 조건에서는 Shadowsocks의 비교적 단순한 데이터 처리 경로가 오버헤드 관리에 도움이 될 수 있지만, 다운로드 속도를 보장하지는 않습니다. 선택할 때는 기존 서비스의 안정성, UDP 필요 여부, 짧은 연결이 자주 발생하는지, 실제 네트워크의 패킷 손실 여부를 살펴보세요. 암호화 방식마다 연산 비용이 다를 수 있지만 대부분의 일상 작업에서는 네트워크 대기 시간과 서버 부하를 먼저 확인하는 편이 좋습니다.

대기 중 배터리 소모가 늘었다면 암호화 방식을 바로 바꾸기보다 반복 재연결, 앱 백그라운드 동기화, UDP 연결 유지 여부부터 확인하세요. 특정 작업만 실패하고 다른 작업은 정상이라면 대상과 전송 유형에 따라 원인을 좁혀 보세요. 규칙 적용, 대상 주소 확인, 서버 출구 제한이 원인일 수 있으며, 반드시 Shadowsocks 자체의 문제인 것은 아닙니다. 안정적으로 작동하는 기존 설정은 그대로 유지하는 편이 임의로 다른 전송 조합을 만드는 것보다 신뢰할 수 있습니다.

03 / VMESS & VLESS

VMess와 VLESS: 인증과 전송을 구분해서 이해하기

비슷한 필드가 같은 프로토콜을 뜻하지는 않습니다

VMess는 사용자 인증과 프록시 메시지 캡슐화를 결합하고 자체 데이터 보호 방식도 갖추고 있습니다. VLESS는 인증과 전달 구조를 가볍게 구성하는 데 중점을 두며, 전송 보호는 보통 외부 보안 계층에 의존합니다. 두 프로토콜 모두 UUID를 사용할 수 있고 비슷한 전송 방식을 조합할 수도 있지만, 실제 메시지 형식은 다릅니다. VMess 항목의 UUID를 VLESS 항목에 복사해도 서버가 자동으로 호환되지 않습니다. 클라이언트의 Type은 서버에 실제로 설정된 유형과 일치해야 합니다.

이러한 설계의 발전은 중요한 트레이드오프를 보여 줍니다. 인증, 암호화, 통로를 분리하면 일부 중복 작업을 줄일 수 있지만 조합 설정의 책임은 늘어납니다. VLESS의 경량 설계가 임의의 암호화되지 않은 연결에도 기밀성이 있다는 뜻은 아닙니다. VMess에 내부 보호 기능이 있어도 외부 TLS 설정을 확인하지 않아도 된다는 뜻은 아닙니다. 보안 경계를 판단할 때는 '누가 사용자를 검증하는가', '누가 서버를 검증하는가', '어느 계층에서 데이터를 보호하는가'를 각각 확인하세요. 프로토콜 이름 하나만으로 전체 상황을 판단할 수 없습니다.

UUID, Security, 시간 조건

UUID는 신원 식별자이므로 전체 값이 일치해야 합니다. 모양이 비슷해도 서로 바꿔 쓸 수 없습니다. 복사할 때 원래 문자와 구분 기호를 그대로 유지하세요. VMess의 Security 등의 필드는 서버에서 제공한 정보를 기준으로 선택합니다. 일부 구형 설정에는 과거 호환용 필드가 있을 수 있으므로 경험만으로 모든 항목에 같은 값을 입력하지 마세요. VLESS의 데이터 암호화 옵션에 VMess의 의미를 그대로 적용해서도 안 됩니다. 같은 영어 단어라도 프로토콜에 따라 다른 처리 계층을 가리킬 수 있습니다.

VMess의 일부 인증 과정은 클라이언트와 서버 사이의 시간 차이에 민감합니다. 설정값이 맞아 보이는데 인증에 실패한다면 기기의 자동 날짜 및 시간 설정을 확인하고 서비스 제공업체에 서버 시계를 확인해 달라고 요청하세요. 시간대 표시를 바꾸는 것은 실제 시계를 맞추는 것과 다르며, 연결을 위해 기기 지역을 변경할 필요도 없습니다. 시간이 정확한데도 실패한다면 시간을 계속 조정하지 말고 프로토콜, 인증 정보, 전송 방식을 확인하세요.

WebSocket, gRPC, TCP의 차이

TCP는 신뢰성 있는 바이트 스트림을 제공하며 프로토콜 메시지를 그 위로 직접 전달할 수 있습니다. WebSocket은 HTTP 핸드셰이크를 통해 설정하는 메시지 통로를 추가합니다. gRPC는 일반적으로 HTTP/2 기반이며 이에 맞는 서비스 및 스트림 처리 의미를 갖습니다. 어떤 방식을 쓸지는 클라이언트의 성능 선호만으로 정할 수 없으며 서버의 수신 방식과 중간 전달 조건에 따라 결정됩니다. 서버가 WebSocket만 받는다면 클라이언트를 TCP로 바꿔 오버헤드를 줄이면서 계속 사용할 수는 없습니다.

WebSocket의 Path와 Host는 제공된 정보에 맞게 입력하세요. Path는 통로의 경로이지 서버 주소나 구독 링크가 아닙니다. 대소문자, 슬래시, 뒤에 붙는 부분이 일치 여부에 영향을 줄 수 있습니다. gRPC 서비스 이름도 정확히 일치해야 하며 웹사이트 홈 경로로 대체할 수 없습니다. 중간 전달 과정이 있다면 서버 주소, HTTP Host, TLS Server Name이 서로 다른 역할을 할 수 있습니다. 세 필드를 억지로 같은 값으로 맞추지 말고 각각의 용도를 확인하세요.

TLS와 특수 스트림 매개변수 설정

TLS의 Server Name은 예상하는 서버 신원을 알리는 데 사용되며 서버의 인증서 선택에도 영향을 줄 수 있습니다. 인증서 검증은 연결된 상대가 그 신원과 일치하는지 확인합니다. 이는 HTTP Host와 같은 단계에서 쓰이는 필드가 아닙니다. 서비스 제공업체가 별도의 Server Name을 안내했다면 해당 값을 유지하세요. Server에 IP를 입력했다는 이유로 비워 두면 안 됩니다. ALPN은 애플리케이션 계층 프로토콜 협상과 관련되므로 현재 전송 방식과 서버 요구 사항이 명확할 때만 조정해야 합니다.

일부 VLESS 조합은 특정 스트림 매개변수나 추가 핸드셰이크 자료를 요구합니다. 이런 항목은 범용 가속 스위치가 아닙니다. 현재 클라이언트 인터페이스가 해당 조합을 지원하는지, 원본 설정에 관련 필드가 모두 있는지 확인하세요. 필수 자료가 없다고 다른 서비스 항목의 값을 가져다 쓰면 안 됩니다. 가져오기에 성공했다는 것은 텍스트를 인식했다는 뜻일 뿐, 전체 조합이 서버 인증을 통과했거나 실제 트래픽이 기대한 경로를 사용한다는 뜻은 아닙니다.

iOS 연결 재사용과 배터리 사용량

추가 HTTP 통로와 TLS 핸드셰이크는 연결을 시작할 때 더 많은 작업을 요구하지만, 연결을 재사용하면 그 비용을 여러 요청에 나눌 수 있습니다. 모바일 네트워크가 바뀌면 기존 연결이 끊겨 다시 연결해야 할 수 있습니다. 이 일이 잦으면 계속 다운로드가 느린 것이 아니라 웹페이지를 열 때 가끔 오래 기다리는 형태로 나타날 수 있습니다. 테스트에서는 새 연결과 장시간 유지되는 연결을 나누어 관찰하고 두 경험을 하나의 속도 점수로 합치지 마세요.

다중화가 항상 유리한 것은 아닙니다. 외부 연결을 공유하면 반복 핸드셰이크를 줄일 수 있지만 외부 경로에서 패킷 손실, 대기열, 연결 재설정이 발생하면 여러 작업이 한꺼번에 영향을 받을 수 있습니다. 서버에서 명확한 안내가 없다면 가져온 설정을 유지하고 같은 작업으로 연결 안정성을 비교한 뒤 변경 여부를 결정하세요. UUID나 전송 필드에 관한 기본 질문은 용어 설명을 함께 참고하세요. 인터페이스 이름이 비슷하다는 이유만으로 호환성을 추정하지 마세요.

04 / TLS & GENERAL PROXIES

Trojan, HTTP, SOCKS5의 차이

Trojan: 비밀번호 인증과 TLS 통로

Trojan의 일반적인 설계에서는 프록시 인증과 전달을 TLS 연결에 포함해 성숙한 TLS 메커니즘으로 전송을 보호하고 서버 신원을 확인합니다. 클라이언트에서 중요한 설정값은 보통 서버, 포트, 비밀번호, TLS 정보입니다. 비밀번호는 사용자가 서비스를 이용할 권한이 있는지 확인하고, 인증서는 클라이언트가 예상한 서버에 연결했는지 확인합니다. 두 기능은 다르므로 비밀번호가 맞아도 인증서 신원 오류를 무시할 수 없습니다.

Server에 IP를 입력했지만 인증서는 도메인에 발급된 경우, 원본 정보에 따라 올바른 Server Name을 입력해야 할 수 있습니다. 주소에 연결할 수 있다고 해서 신원 검증도 통과해야 한다는 뜻은 아닙니다. 인증서 만료, 인증서 체인 누락, 기기 시간 오류, 다른 사이트의 인증서 반환 등이 연결 실패 원인일 수 있습니다. 포트를 연달아 바꿔 보기보다 먼저 오류가 인증, TLS, 네트워크 시간 초과 중 어느 단계에서 발생하는지 확인하고 서비스 제공업체에 문의하세요.

HTTP 프록시와 HTTPS 대상은 다릅니다

HTTP 프록시는 원래 HTTP 요청 전달을 중심으로 만들어졌습니다. HTTPS 대상에 접속할 때는 일반적으로 CONNECT로 대상까지 터널을 만든 뒤 앱과 대상 웹사이트가 TLS 통신을 합니다. '대상 웹사이트가 HTTPS다'와 '클라이언트에서 프록시까지의 통로가 TLS를 사용한다'는 서로 다른 이야기입니다. 프록시 진입점이 일반 HTTP라면 대상 웹사이트가 HTTPS여도 진입 구간에서 프록시 인증 정보와 모든 메타데이터가 같은 수준으로 보호된다고 단정할 수 없습니다.

현재 인터페이스와 서버에서 HTTPS 프록시 진입점을 제공한다면 해당 유형에 맞게 외부 TLS를 설정하세요. 일반 HTTP의 포트만 흔히 쓰는 TLS 포트로 바꾸면 안 됩니다. 사용자 이름, 비밀번호, 인증 방식, 서버 수신 설정이 일치해야 하며 일부 서비스는 CONNECT 대상 포트를 제한합니다. 일부 웹사이트만 열리고 특정 포트는 사용할 수 없다면 먼저 서버에서 허용하는 범위를 확인하세요. DNS나 규칙을 원인으로 단정할 필요는 없습니다. 앱 계층의 거부 응답과 하위 계층 연결 시간 초과도 구분해 기록하세요.

SOCKS5: 범용 프록시 협상, 자체 암호화 없음

SOCKS5는 대상 주소를 지정할 수 있는 범용 프록시 협상 방식이며, 서버 설정에 따라 사용자 이름과 비밀번호 인증을 사용할 수 있습니다. 프로토콜 자체는 TLS와 같은 전송 암호화를 제공하지 않습니다. 사용자 이름과 비밀번호 인증은 사용 권한을 확인할 뿐, 자동으로 암호화 통로를 만들지는 않습니다. 현재 환경에 적합한지 판단하려면 네트워크, 외부 보호 계층, 서버 구성을 함께 고려해야 합니다. 필드가 적다는 이유만으로 보안 경계도 단순하다고 볼 수 없습니다.

SOCKS5 프로토콜은 UDP 연결 기능을 정의하지만 실제 사용 가능 여부는 클라이언트 지원, 서버 활성화 여부, 네트워크 경로에 달려 있습니다. SOCKS5로 웹페이지가 열렸다는 것은 주로 일부 TCP 요청이 성공했다는 뜻이며 게임, 음성 통화, 기타 UDP 작업도 된다고 볼 수는 없습니다. 서버가 TCP 전달만 지원한다면 이를 서버의 제약으로 받아들여야 합니다. 클라이언트에서 UDP 옵션을 계속 바꿔도 서버가 제공하지 않는 기능이 생기지는 않습니다.

주소 확인이 어디서 이루어지는지 따로 확인하세요

HTTP CONNECT와 SOCKS5 모두 도메인으로 대상을 지정할 수 있지만 최종적으로 어느 쪽에서 주소를 확인하는지는 클라이언트 처리 방식, 규칙 요구 사항, 서버 구현에 따라 달라집니다. 클라이언트가 IP 규칙을 적용하려고 먼저 로컬에서 주소를 확인했다면 이후 도메인을 프록시에 전달하더라도 모든 주소 확인이 원격에서 이루어진다고 할 수 없습니다. 서버 주소 확인, 대상 주소 확인, 규칙 매칭에 필요한 주소 확인을 구분하세요. '원격 DNS'라는 하나의 표현으로 전체 과정을 뭉뚱그리지 마세요.

iOS에서 이들 프로토콜의 체감 차이는 TLS 핸드셰이크 추가 여부, 연결 재사용 여부, 서버 거리, 실제 부하에 따라 달라지는 경우가 많습니다. 일반 HTTP나 SOCKS5의 설정 필드가 적다고 배터리를 반드시 덜 쓰는 것은 아닙니다. Trojan이 TLS를 사용한다고 해서 배터리 소모가 반드시 눈에 띄게 늘어나는 것도 아닙니다. 연결이 안정적이라면 프로토콜 차이보다 실제 작업 패턴의 영향이 클 수 있습니다. 테스트할 때는 신원 확인이 올바른지도 살펴보고 핸드셰이크 횟수를 줄이려고 필요한 보호 범위를 바꾸지 마세요.

사용 중인 서비스의 실제 유형에 맞춰 선택하세요. 서비스 제공업체가 Trojan을 제공한다면 해당 인증과 TLS 조건을 유지하세요. 신뢰할 수 있는 네트워크에서 HTTP나 SOCKS5 진입점을 제공한다면 그 진입점의 신뢰 범위와 용도를 먼저 확인하세요. 세 프로토콜을 같은 서버 기록에서 서로 바꿔 쓸 수 있는 메뉴처럼 취급하면 안 됩니다. 기본 사용법은 자주 묻는 질문에서 확인할 수 있습니다. 인증서나 인증 관련 오류를 문의할 때는 자격 증명을 삭제한 오류 정보만 제공하세요.

05 / WIREGUARD

WireGuard: 키 기반 신원 확인과 IP 터널

앱 프록시와 다른 작동 방식

WireGuard는 암호화된 IP 터널을 중심으로 설계되며 공개 키 체계로 신원을 표시하고 주로 UDP를 통해 데이터를 전송합니다. 범용 앱 프록시처럼 특정 대상 연결만 협상하는 것이 아니라 터널 내부의 IP 패킷을 처리합니다. 따라서 주소, 라우팅 범위, 상대 키가 중요한 설정 항목입니다. 프록시 프로토콜의 '비밀번호, 서버, 포트' 방식만 그대로 적용하면 로컬 터널 주소와 상대를 거칠 대상 범위를 놓치기 쉽습니다.

Shadowrocket에서 WireGuard 항목을 사용할 때는 클라이언트의 트래픽 선택과 WireGuard 상대 자체의 라우팅 제약을 구분해야 합니다. 전자는 어떤 트래픽이 해당 항목을 사용할지 정하고, 후자는 터널에 전달된 패킷이 상대가 허용한 범위에 속하는지 정합니다. 두 계층이 모두 맞아야 작업이 완료될 수 있습니다. 핸드셰이크에 성공한 WireGuard 항목을 선택했다고 해서 모든 대상 주소에 도달할 수 있는 것은 아닙니다. 기존 트래픽 분할 규칙이 자동으로 바뀌는 것도 아닙니다.

Private Key, Public Key, 사전 공유 키

Private Key는 로컬 신원을 증명하는 비밀 키이며 Public Key는 상대를 식별하는 데 쓰입니다. 클라이언트에서 입력하는 상대의 Public Key는 서버에서 받아야 하며 로컬에서 생성한 Public Key로 대신할 수 없습니다. 서버에도 클라이언트의 공개 키가 등록되어 있어야 합니다. 설정에 사전 공유 키가 있다면 양쪽이 추가로 합의한 값이며 Private Key와 혼용할 수 없습니다. 키 문자열 모양이 비슷해도 역할은 다릅니다. 길이가 아니라 원본 필드 이름을 기준으로 복사하세요.

Private Key가 포함된 전체 설정을 스크린샷, 로그, 공개 게시물에 올리지 마세요. 문제를 확인할 때는 '같은 설정 파일에서 키를 가져왔는지', '상대 서버에 클라이언트 공개 키가 등록되어 있는지'만 설명하면 됩니다. 실제 값을 보여 줄 필요는 없습니다. 로컬 키를 다시 생성하면 클라이언트 신원이 바뀝니다. 서버에 새 공개 키를 등록하지 않으면 접근 권한이 자동으로 생기지 않습니다. 따라서 실패할 때는 먼저 키 대응 관계를 확인하고, 키를 반복 생성하는 방법을 만능 해결책으로 삼지 마세요.

Endpoint, Address, Allowed IPs

Endpoint는 외부에서 도달할 수 있는 상대 주소와 포트이며 Address는 터널 내부에서 로컬에 할당된 주소입니다. 둘은 서로 바꿔 쓸 수 없습니다. Allowed IPs는 해당 상대를 통해 처리할 주소 범위를 나타내며 일반적인 구현에서는 상대 선택과 수신 주소 제한에도 관여합니다. 범위가 너무 좁으면 내부 리소스 일부만 접근할 수 있고, 너무 넓다고 서버가 모든 대상으로 트래픽을 전달할 수 있는 것은 아닙니다. 제공된 설정을 유지하고 '전체 연결'이라는 직관만으로 범위를 넓히지 마세요.

핸드셰이크는 성공했지만 작업이 되지 않는다면 터널 주소 충돌, 대상이 허용 범위에 포함되는지, 서버에 전달 및 응답 경로가 있는지부터 확인하세요. 내부 IP에는 접근할 수 있지만 도메인에는 실패한다면 DNS를 확인해야 할 수 있습니다. 특정 서브넷만 실패한다면 라우팅이나 대상 측 권한 문제일 수 있습니다. 클라이언트에 연결 완료로 표시되는 것은 특정 계층의 상태만 알려 줍니다. 주소와 서버 출구 확인을 생략하지 마세요. 계층을 나누어 살펴보는 편이 스위치가 켜졌는지만 보는 것보다 효과적입니다.

MTU, 연결 유지, 모바일 네트워크 전환

MTU는 터널에서 전송하는 패킷 크기의 한계를 정합니다. 캡슐화로 바이트가 추가되며 실제 경로가 해당 크기를 처리하지 못하고 경로 정보를 올바르게 전달하지도 못하면 작은 요청은 성공하지만 큰 페이지나 전송이 멈출 수 있습니다. 아무 작은 값이나 보편적인 최적값으로 취급하지 마세요. 서버 권장값과 테스트 양상을 기준으로 조정하고 원래 값도 기록하세요. MTU를 낮춘 뒤 특정 문제만 개선되더라도 원인을 더 확인해야 합니다. 모든 연결에 같은 설정이 맞는다고 추정하지 마세요.

Persistent Keepalive 같은 연결 유지 기능은 일부 NAT 매핑을 유지하는 데 도움을 주며 대역폭을 높이는 기능은 아닙니다. 모바일 네트워크에서는 유휴 매핑이 빨리 정리될 수 있지만, 연결 유지 빈도를 높이면 전송 횟수와 무선 모듈 활성 시간도 늘어납니다. 필요한지는 서버 접근 방식, 유휴 후 복구 양상, 원본 설정을 기준으로 판단하세요. 유휴 연결 끊김이 없다면 '온라인 유지'를 위해 간격을 일부러 줄일 필요가 없습니다. 절전을 위해 연결 확인을 계속 실행해서도 안 됩니다.

WireGuard는 주소가 바뀌는 일부 모바일 상황에 잘 대응하도록 설계됐지만 모든 Wi-Fi와 셀룰러 전환에서 중단이 없다고 보장하지는 않습니다. 전환 후 UDP 경로, 시스템 네트워크 확장 상태, 대상 세션이 달라질 수 있습니다. 테스트할 때는 새 요청이 복구되는지와 기존 작업을 다시 연결해야 하는지 따로 살펴보세요. 기존 통화만 끊기고 새 웹페이지는 열린다면 전체 터널 장애라고 단정하지 말고 세션 연속성 문제로 기록하세요.

06 / HYSTERIA2

Hysteria2: UDP 경로와 혼잡 제어

QUIC 기반 전송을 사용하는 이유

Hysteria2는 QUIC 기반 전송을 사용합니다. QUIC은 일반적으로 UDP 위에서 동작하며 신뢰성 있는 스트림, 암호화 핸드셰이크, 연결 관리 등의 기능을 통합합니다. 설계 목적 중 하나는 품질이 서로 다른 네트워크에서 전송을 관리하는 것입니다. TCP 패킷을 UDP로 바꿨다고 자동으로 속도가 빨라지는 것은 아닙니다. UDP는 전송 기반일 뿐이며 신뢰성, 혼잡 제어, 서비스 매핑은 상위 계층에서 담당합니다. 따라서 UDP를 사용해도 재전송이 필요하고 패킷 손실의 영향을 받습니다.

단일 TCP 연결을 기반으로 다중화하는 방식과 비교할 때 QUIC은 전송 계층에서 각 스트림의 전달 상태를 비교적 독립적으로 관리할 수 있어 한 스트림의 패킷 손실이 다른 스트림의 전달을 직접 막는 상황을 줄일 수 있습니다. 다만 공유 링크의 대역폭, 혼잡 상태, 기기 리소스는 여전히 한정되어 있습니다. 한 연결에서 대량으로 전송하면 다른 작업에 영향을 줄 수 있습니다. 실제 효과는 네트워크 상태, 서버 설정, 작업 유형에 따라 다르며 모든 웹페이지, 다운로드, 실시간 상호작용이 똑같이 개선되는 것은 아닙니다.

Server, 인증, TLS 신원

Hysteria2의 서버 주소, 포트, 인증 정보, TLS 설정은 하나의 원본 설정에서 가져와야 합니다. 인증 문자열은 사용자 권한을 증명하고 TLS 신원 확인은 상대 서버를 확인하므로 서로 대체할 수 없습니다. Server가 IP이고 Server Name이 도메인이라면 원본 정보에 따라 두 역할을 유지하세요. 인증서 오류가 발생하면 도메인, 유효기간, 기기 시간을 확인하세요. 처리량을 살펴보려고 검증을 장기간 꺼 두면 서로 다른 보안 조건을 비교하게 됩니다.

일부 배포 환경은 추가 전송 매개변수나 난독화 관련 필드를 요구합니다. 이러한 값은 양쪽이 일치해야 하며, 필드가 비어 있는 것과 누락된 것이 같은 의미가 아닐 수도 있습니다. 이름이 비슷한 다른 세대의 프로토콜에 필드가 비슷하다고 해서 Hysteria2 설정을 서로 바꿔 쓸 수는 없습니다. 가져올 때 서버에서 실제 사용하는 프로토콜 유형으로 인식됐는지 확인하세요. 수동 입력 후 응답이 전혀 없다면 비밀번호뿐 아니라 현재 네트워크에서 필요한 UDP 포트에 도달할 수 있는지도 먼저 확인하세요.

대역폭 매개변수가 속도를 보장하지는 않습니다

일부 설정에는 특정 혼잡 제어 모드에서 추정값이나 제한값으로 사용하는 업로드 및 다운로드 대역폭 매개변수가 있습니다. 값을 크게 입력할수록 좋은 것도 아니며 서버가 사용자에게 해당 속도를 보장한다는 뜻도 아닙니다. 실제 네트워크 용량보다 훨씬 큰 값을 입력하면 대기열, 패킷 손실, 경합이 발생할 수 있습니다. 다운로드 속도가 잠시 높아 보여도 상호작용 품질은 나빠질 수 있습니다. 현재 모드가 이 값을 어떻게 사용하는지 이해하고 다른 사람의 고속 네트워크 설정을 복사하기보다 서버 권장값을 우선하세요.

단위도 정확히 확인해야 합니다. 대역폭과 초당 전송 바이트는 같은 개념이 아닙니다. 다운로드 앱의 표시 방식만 보고 인터페이스나 설정에서 요구하는 단위를 추측하지 마세요. 업로드 혼잡도 다운로드 품질에 영향을 줍니다. 요청, 확인 응답, 제어 정보도 전송되어야 하기 때문입니다. 다운로드가 처음에는 빠르다가 지연 시간이 크게 늘어난다면 서버 부하뿐 아니라 로컬 연결이 지속적인 대기열 상태에 놓였는지도 확인하세요. 다운로드 대역폭 설정만 계속 높이지 마세요.

iOS에서 속도와 배터리 사용량을 함께 고려하기

패킷 손실이나 지연 변동이 있는 경로에서는 적절한 혼잡 제어가 지속 전송을 개선할 수 있지만, 품질이 좋은 저지연 네트워크에서는 효과가 크지 않을 수 있습니다. 링크를 적극적으로 사용하는 전송 방식은 데이터 처리와 무선 모듈 활성도 늘릴 수 있으므로 처리량이 높다고 에너지 효율도 높다고 볼 수 없습니다. 배터리가 중요하다면 순간 최고 속도보다 같은 작업을 완료하는 데 걸리는 총시간, 백그라운드 전송, 기기 온도를 비교하세요.

음성 통화, 상호작용, 원격 조작이 목적이라면 다운로드 속도만 보지 말고 지연 변동, 연결 끊김, 대기열을 우선 확인하세요. 이런 동시 사용 자체를 평가하는 것이 아니라면 대용량 파일 전송과 상호작용 테스트가 서로 영향을 주지 않게 하세요. Wi-Fi와 셀룰러를 전환한 뒤에는 UDP 경로도 다시 확인해야 합니다. 한 네트워크에서 잘 작동해도 다른 네트워크의 패킷 크기 제한, NAT 동작, 유휴 연결 유지 시간이 같다는 보장은 없습니다.

기존 환경에 맞는 선택이지 모든 유형의 대체재는 아닙니다

서버가 Hysteria2를 명확히 제공하고 현재 경로에서 UDP를 사용할 수 있으며 실제 문제가 링크 품질이나 혼잡과 관련된 경우 비교 옵션으로 검토할 만합니다. 기존 TCP 기반 연결이 안정적이라면 반드시 전환할 필요는 없습니다. 규칙이 대상을 잘못된 정책으로 보내거나 DNS에서 도달할 수 없는 주소를 반환해 문제가 생긴다면 Hysteria2로 바꿔도 규칙은 자동 수정되지 않습니다. 먼저 문제가 전송 계층에 있는지 확인한 다음 프로토콜의 실제 효과를 평가하세요.

테스트 결과를 저장할 때는 네트워크, 작업, 대역폭 설정을 원래대로 사용했는지, 재연결이나 백그라운드 활동이 있었는지 적으세요. '빠름'이나 '느림'만 기록하면 조건이 바뀌었을 때 재현할 수 없습니다. 기존 항목은 유지하고 테스트 항목에는 별도의 이름을 지정하세요. 구독 업데이트 후 설정 차이를 확인해 업데이트로 인한 매개변수 변경을 같은 프로토콜의 성능 변화로 오해하지 않도록 하세요.

07 / ROUTING & DNS

Global Routing, DNS, 프로토콜의 관계

트래픽이 실제로 선택한 프로토콜을 사용하는지 먼저 확인하세요

Global Routing은 전체 트래픽이 어느 경로를 사용할지 정할 뿐, 한 프로토콜을 다른 프로토콜로 바꾸지 않습니다. Config 모드는 현재 설정에 따라 규칙을 적용합니다. Proxy 모드는 해당 트래픽을 프록시 경로로 보냅니다. Direct 모드는 직접 연결합니다. 인터페이스 용어와 규칙 정책을 구분하세요. Proxy는 인터페이스 모드이고 PROXY는 규칙에서 사용할 수 있는 정책 이름입니다. 서로 관련은 있지만 같은 필드는 아니므로 글자가 비슷하다는 이유만으로 요청이 실제로 어떤 경로를 사용하는지 판단하면 안 됩니다.

프로토콜을 테스트하기 전에 현재 항목이 선택되어 있는지 확인하고 관련 요청에 어떤 규칙과 최종 정책이 적용됐는지 살펴보세요. Config 모드에서 웹사이트가 직접 연결되어도 선택한 프록시 항목이 작동한다는 뜻은 아닙니다. Proxy 모드에서 실패해도 곧바로 프로토콜 설정 오류라고 단정할 수 없습니다. 서버 출구나 대상 응답이 원인일 수 있습니다. Direct 모드는 현재 네트워크에서 대상에 직접 접근할 수 있는지 확인하는 데 도움이 되지만 그 결과가 모든 연결에 영구적으로 적용되는 것은 아닙니다.

세 가지 주소 확인 과정을 구분하세요

첫 번째는 프록시 서버 주소 확인입니다. Server에 도메인을 입력했다면 클라이언트는 먼저 해당 주소를 찾는 방법을 알아야 합니다. 이는 프록시 연결을 시작하기 위한 조건입니다. 두 번째는 대상 도메인 확인입니다. 프로토콜과 설정에 따라 로컬에서 주소를 확인하거나 도메인을 원격 서버에 전달할 수 있습니다. 세 번째는 규칙 매칭에 필요한 주소 확인입니다. IP 기반 규칙은 주소를 먼저 알아야 할 수 있습니다. 세 과정은 서로 다른 시점에 일어나며 완전히 같은 경로를 사용하지 않을 수도 있습니다.

따라서 'DNS가 정상이다'라고 말하려면 어떤 주소 확인이 정상인지 밝혀야 합니다. 서버 도메인을 확인할 수 있다고 해서 대상 웹사이트의 도메인도 확인된 것은 아닙니다. 대상 주소를 확인해도 현재 출구에서 해당 주소에 도달할 수 있다는 뜻은 아닙니다. IPv6 대상만 실패한다면 DNS 기능을 전부 끄기보다 현재 네트워크와 출구에서 IPv6를 지원하는지 확인하세요. IP로는 접속되지만 도메인으로 실패한다면 주소 확인과 신원 필드를 먼저 살펴보세요. 단, HTTPS 대상은 도메인 신원에 의존할 수 있으므로 IP를 직접 입력하는 테스트를 완전히 같은 작업으로 볼 수 없습니다.

규칙 순서에 따라 테스트 결과가 달라집니다

규칙은 보통 위에서 아래 순서로 처리되며 먼저 일치한 규칙이 정책을 결정합니다. DOMAIN-SUFFIX는 도메인 접미사를, GEOIP는 주소 위치 데이터베이스를 기준으로 일치 여부를 판단합니다. FINAL은 다른 규칙에 일치하지 않은 요청의 기본 처리에 사용됩니다. 아래는 규칙 순서를 설명하기 위한 일부 예시이며 기존 설정을 그대로 대체하라는 뜻은 아닙니다. PROXY가 실제 설정에서 유효한 정책인지 확인해야 하며, 예시 도메인은 설명용으로 실제 접속 대상이 아닙니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시는 먼저 도메인 접미사를 확인하고 다음으로 주소 위치를 확인한 뒤 기본 정책을 적용합니다. FINAL을 앞에 두면 뒤에 나오는 규칙이 의도대로 적용되지 않습니다. 프록시를 사용해야 할 대상을 먼저 DIRECT에 일치시키면 프로토콜 테스트가 프록시를 우회하게 됩니다. DOMAIN과 DOMAIN-SUFFIX도 임의로 바꿔 쓸 수 없습니다. 전자는 정확한 도메인, 후자는 접미사 범위를 나타냅니다. 더 자세한 규칙 작성법과 순서는 사용자 지정 규칙 매칭 순서와 FINAL에서 확인하세요.

설정 파일과 구독 항목은 다릅니다

구독은 주로 서버 항목과 관련 매개변수를 제공하고, 설정 파일은 규칙, DNS, 기타 처리를 바꿀 수 있습니다. 새 항목을 가져와도 이전 설정을 계속 사용한다면 프로토콜 이름이 바뀌었다고 규칙이 자동으로 수정되지는 않습니다. 반대로 서버를 바꾸지 않고 설정 파일만 교체해도 연결 경로가 바뀔 수 있습니다. 장애를 기록하기 전에 이 두 부분이 각각 업데이트됐는지 확인하세요. 같은 날 발생한 규칙 변경을 프로토콜 탓으로 잘못 돌리지 않도록 주의해야 합니다.

.conf 파일을 편집한 뒤에는 저장했는지, 올바른 설정을 선택했는지 확인하고 인터페이스 안내에 따라 관련 상태를 다시 적용하세요. 테스트할 때는 원래 설정을 보존하고 실제 사용 설정과 실험 변경을 섞지 마세요. 구조 설명은 General, Rule, Host, URL Rewrite 섹션별 해설에서 확인할 수 있습니다. 구독 가져오기 위치는 Subscribe 및 기타 가져오기 방법을 참고하세요.

On Demand와 프로토콜 연결 상태를 따로 확인하세요

On Demand는 시스템 조건에 따라 연결 시점을 결정하지만 인증, 인증서, 서버 도달 문제를 해결하지는 않습니다. 네트워크를 전환할 때 연결 시도가 반복된다면 트리거 조건과 프로토콜의 재연결 결과를 따로 확인하세요. 트리거 조건을 끄고 수동으로 테스트하면 시스템이 연결을 반복해서 시작하는 문제와 개별 연결 자체의 실패를 구분하는 데 도움이 됩니다. 테스트가 끝난 뒤에는 원래 설정을 복원하고 필요한 연결 조건을 잊지 마세요.

최종 기록에는 현재 Global Routing 모드, 설정 이름, 선택한 항목, 대상, 적용된 정책, DNS 또는 UDP 사용 여부를 포함하세요. 그래야 같은 항목이 두 사용자 기기에서 다르게 작동하는 이유를 설명할 수 있습니다. 클라이언트 스위치가 켜져 있다는 표시는 네트워크 확장이 어떤 상태로 실행 중인지만 알려 줍니다. 요청 경로, 주소 확인 위치, 사용 프로토콜은 현재 설정과 구체적인 연결을 함께 확인해야 합니다.

08 / SELECTION & DIAGNOSIS

사용 상황에 맞는 선택과 단계별 문제 해결

선택 순서: 성능 선호보다 호환 조건을 먼저 확인하세요

첫째, 빠르게 들리는 이름을 먼저 고르지 말고 현재 서비스에서 실제로 제공하는 프로토콜과 전체 설정을 확인하세요. 둘째, UDP 경로 등 필요한 전송 방식을 현재 네트워크에서 사용할 수 있는지 확인합니다. 셋째, 작업 유형을 살펴봅니다. 짧은 웹 탐색은 첫 응답 시간, 지속 다운로드는 안정적인 처리량, 통화와 상호작용은 지연 변동과 끊김, 내부 리소스 접근은 주소와 라우팅 범위가 중요합니다. 앞의 두 조건이 충족되어야 세 번째 단계의 비교가 의미 있습니다.

서비스 제공업체가 한 가지 프로토콜만 제공한다면 클라이언트에서 다른 프로토콜로 임의 변경할 수 없습니다. 여러 항목을 제공하더라도 서버 위치와 부하가 다를 수 있으므로 테스트 차이를 모두 프로토콜 탓으로 돌릴 수 없습니다. 비교를 신중하게 하려면 서버 위치와 네트워크 조건을 최대한 맞추고 통제할 수 없었던 변수도 기록하세요. 대부분의 사용자에게는 익숙하지 않은 전송 조합을 추가하는 것보다 필요한 작업에 맞고 완전하며 안정적인 기존 설정을 유지하는 편이 관리하기 쉽습니다.

도달 불가 단계부터 서비스 계층까지 순서대로 확인하세요

연결을 전혀 설정할 수 없다면 먼저 Server와 Port, 현재 네트워크, 서버 수신 상태를 확인하세요. 도메인 확인 실패는 진입점 문제일 수 있습니다. 하위 계층 시간 초과는 경로나 서버 수신 여부를 확인해야 합니다. UUID를 즉시 다시 입력해도 대개 도움이 되지 않습니다. 네트워크 연결은 됐지만 명확한 인증 오류가 나타난다면 비밀번호, UUID, 키 대응 관계, 시간 조건을 확인하세요. TLS 오류라면 Server Name, 인증서, 기기 시간에 집중하세요. 문제를 가리기 위해 DNS와 라우팅을 동시에 바꾸지 마세요.

인증은 통과했지만 서비스가 작동하지 않는다면 다음으로 전송 매개변수, 대상 주소, 서버 전달 설정을 확인하세요. WebSocket Path, gRPC 서비스 이름, 특수 스트림 매개변수, WireGuard 라우팅 범위 때문에 기본 연결은 성립해도 작업이 차단될 수 있습니다. 일부 대상만 실패한다면 규칙 적용, 대상 주소 확인, 서버 출구를 살펴보세요. UDP 작업만 실패한다면 웹페이지 테스트로 '모든 것이 정상'이라고 판단하지 말고 클라이언트, 서버, 네트워크 경로를 따라 UDP를 하나씩 확인하세요.

잠시 작동한 뒤 끊길 때는 상태 변화를 확인하세요

유휴 상태가 한동안 이어진 뒤 연결이 끊긴다면 NAT 매핑, 연결 유지, 서버 유휴 정책이 원인일 수 있습니다. Wi-Fi에서 셀룰러로 전환한 뒤 끊긴다면 기존 연결의 재설정 여부, UDP 경로 변화, On Demand 작동 여부를 살펴보세요. 큰 요청만 멈추고 작은 요청은 정상이라면 MTU와 경로 정보 전달을 확인할 수 있습니다. 부하가 높을 때만 실패한다면 대기열, 대역폭 추정, 기기 리소스, 서버 부하를 점검하세요. 각 현상을 구체적으로 기록하면 '항상 끊긴다'는 메모보다 원인을 찾기 쉽습니다.

연결 유지, MTU, 다중화, 대역폭 매개변수를 한꺼번에 바꾸지 마세요. 원래 값을 기록하고 현재 현상과 가장 관련 있는 항목 하나만 바꾼 뒤 같은 작업을 반복하세요. 개선이 없다면 변경을 되돌리세요. 실험값을 계속 쌓아 두지 마세요. 구독으로 관리되는 항목은 자동 업데이트로 변경이 덮어써질 수 있습니다. 테스트 항목을 따로 복사하고 용도를 명확히 적어 두면 다음 업데이트 후에도 설정 변경이 수동 수정 때문인지 원본 변경 때문인지 파악하기 쉽습니다.

배터리 문제는 이름이 아니라 같은 작업으로 비교하세요

배터리 소모를 줄이려면 프로토콜을 비교하기 전에 백그라운드 활동 지속 여부, 실패 재시도, 연결 유지 빈도, 무선 신호부터 확인하세요. 테스트 중에는 화면 상태, 작업 시간, 네트워크 조건을 최대한 맞추고 한쪽만 충전 중이거나 배터리가 부족한 상태가 되지 않도록 하세요. 시스템 배터리 통계는 단서로 활용할 수 있지만 짧은 시간 동안의 백분율 변화는 온도와 추정치의 영향을 받습니다. 여러 작업 결과를 함께 살펴보세요. 한 번의 빠른 다운로드가 오래 걸리는 저속 재시도보다 전체 활동 시간이 짧아 배터리를 덜 쓸 수도 있습니다.

대기 중 배터리 사용량을 테스트하려고 탐색 요청을 계속 보낼 필요는 없습니다. 그러면 관찰하려는 상태가 바뀝니다. 클라이언트와 관련된 백그라운드 활동이 늘었다면 다른 앱이 연결을 통해 계속 데이터를 전송하는지, 규칙 때문에 직접 접속할 수 있는 빈번한 작업이 더 긴 경로를 이용하는지 확인하세요. 이 경우 프로토콜을 바꾸는 것보다 작업 경로를 바로잡는 편이 효과적일 수 있습니다. 다만 규칙은 실제 사용 목적에 맞게 조정해야 하며 배터리 통계를 낮추려고 필요한 연결을 차단해서는 안 됩니다.

테스트를 마친 뒤에는 설명 가능한 설정을 유지하세요

최종 선택은 세 가지 질문에 답할 수 있어야 합니다. 서버와 호환되는 이유는 무엇인지, 현재 작업에 적합한 이유는 무엇인지, 문제가 생기면 어떻게 복구할 수 있는지입니다. 검증된 설정을 보관하고 필수 매개변수의 출처와 적용 가능한 네트워크를 기록하세요. 효과가 없다고 확인된 실험 변경은 삭제하세요. 검증을 끄거나 범위를 임시로 넓히거나 극단적인 대역폭 값을 일상 설정으로 남겨 두지 마세요. 원본 설정과 다른 값이 꼭 필요하다면 이유를 설명하고 서비스 제공업체에 적용 범위를 확인하세요.

기본 사용 흐름을 이어가려면 Shadowrocket 빠른 시작을 읽고, 다운로드 방법은 전체 플랫폼 다운로드 페이지에서 확인하세요. Mac은 Apple 실리콘과 Intel 버전을 제공합니다. Windows, Android 및 Linux 설치 관련 시스템 안내도 다운로드 페이지에 모아 두었습니다. 이 페이지의 결론은 항상 특정 프로토콜을 우선하라는 것이 아닙니다. 선택할 때마다 확인할 조건을 명확히 하고, 실패할 때마다 다음 단계를 알 수 있도록 돕는 것입니다.