Shadowrocket의 배터리 사용량 비중이 높다고 해서 기기 전체 배터리의 같은 비율을 소모했다는 뜻은 아닙니다. 트래픽 처리, 백그라운드 연결, 비정상적인 재시도를 구분한 뒤 연결 유지와 On Demand 중 적합한 방식을 선택하세요. 본인 서비스 제공업체와 구독을 이용하면서 iPhone 또는 iPad의 대기 중 배터리 소모를 확인하려는 사용자를 위한 안내입니다. 단계별로 비교 기록을 남기고 현재 네트워크에 On Demand가 적합한지 판단할 수 있습니다.
1. 배터리 변화부터 확인하고 앱 비중은 다음에 살펴보기
시스템의 ‘설정 → 배터리’에서 먼저 동일한 통계 기간을 선택한 다음 배터리 그래프, 화면 사용 시간, Shadowrocket 활동 기록을 확인하세요. 앱 목록의 백분율은 해당 통계 기간에 앱에 귀속된 배터리 사용량의 비중이지, 앱이 배터리 전체에서 그만큼을 직접 소모했다는 뜻이 아닙니다. 기기 전체의 배터리 소모량이 적다면 네트워크 처리가 계속되는 앱의 비중이 높게 표시될 수도 있습니다.
예를 들어 배터리가 80%에서 70%로 줄고 앱 목록에서 Shadowrocket이 30%로 표시되더라도, Shadowrocket이 배터리를 30%포인트 소모했다고 볼 수는 없습니다. 배터리 화면은 시스템이 추정한 앱별 사용량이므로 이 두 수치로 앱의 정확한 소모량을 계산하는 것도 적절하지 않습니다. 비슷한 조건에서 기기 전체의 배터리가 계속 더 빨리 줄어드는지, 발열이나 연결 실패가 동반되는지를 확인하는 편이 유용합니다.
아래 숫자는 기록 방법의 예시일 뿐, 실제 측정 결과나 배터리 사용 시간을 보장하지 않습니다. 특정 시간대에 사진 동기화, 동영상 재생 또는 대용량 파일 다운로드가 진행 중이었다면 그 활동을 따로 표시하세요. 트래픽이 거의 없는 대기 시간대와 직접 비교하지 않는 것이 좋습니다.
2. 백그라운드 연결에서 배터리가 소모되는 요인
Shadowrocket이 화면에 표시되지 않을 때도 시스템은 연결된 VPN 네트워크 확장을 실행할 수 있습니다. 네트워크 확장은 설정에 따라 터널로 들어오는 트래픽을 처리하며, 여기에는 다른 앱의 백그라운드 요청도 포함될 수 있습니다. 앱 화면을 닫았다고 네트워크 확장이 중단되는 것은 아니므로 앱을 쓸어 올려 종료했는지를 연결 중단의 기준으로 삼지 마세요.
- 트래픽 처리: 동영상 재생, 파일 전송, 백그라운드 동기화는 패킷 처리와 암복호화, 네트워크 송수신을 늘립니다. 실제 트래픽 양과 배터리 변화를 함께 기록하세요.
- 연결 유지: 일부 연결은 연결 유지를 위한 신호를 주고받습니다. 실제 빈도는 프로토콜, 설정, 원격 서버의 요구에 따라 달라지므로 모든 프로토콜의 백그라운드 동작이 같다고 볼 수 없습니다.
- 불안정한 네트워크: 신호가 약하거나 Wi-Fi와 셀룰러 네트워크가 전환되는 경우, 원격 서버에 연결할 수 없는 경우 연결을 다시 설정하거나 앱이 재시도할 수 있습니다. 셀룰러 무선 모듈 자체의 전력 소모도 기기 전체의 결과에 영향을 줍니다.
- 진단 및 테스트: 연결 테스트를 계속 실행하거나 속도 측정을 반복하고 상세 로그를 장시간 확인하면 추가 활동이 발생합니다. 문제 확인이 끝나면 수동으로 반복하던 테스트를 중단하세요.
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 전송 방식과 연결 메커니즘이 서로 다르지만 프로토콜 이름만으로 배터리 소모 순위를 정할 수는 없습니다. 본인 서비스 제공업체가 지원하는 범위에서 실제 네트워크 품질과 연결 성공률, 재시도 여부를 비교하세요. 배터리를 아끼려는 목적으로 서비스 제공업체가 요구하는 매개변수를 임의로 삭제하지 마세요.
3. 상시 연결과 On Demand의 차이
연결 유지는 VPN 연결을 계속 사용할 수 있도록 하는 방식입니다. On Demand는 시스템이 주문형 규칙과 네트워크 이벤트를 바탕으로 연결 여부를 결정합니다. Shadowrocket 화면을 열었을 때만 연결되는 기능도 아니고, 화면을 잠그면 자동으로 연결이 끊긴다는 뜻도 아닙니다. 다른 앱의 요청도 규칙이 허용하면 연결을 시작할 수 있습니다.
| 설정 또는 방식 | 주요 기능 | 배터리 소모 확인 사항 |
|---|---|---|
| 연결 유지 | 현재 VPN 연결을 계속 사용할 수 있도록 유지 | 지속적인 트래픽, 연결 유지 신호, 비정상적인 재연결 여부 확인 |
| On Demand | 시스템 규칙과 네트워크 조건에 따라 연결 시작 | 규칙 범위가 너무 넓어 연결이 자주 또는 계속 시작되는지 확인 |
| Global Routing → Config | 현재 Config의 규칙에 따라 정책 선택 | 모드 이름뿐 아니라 실제로 적용된 규칙 확인 |
| Global Routing → Proxy | 전역 프록시 방식으로 트래픽 처리 | 프록시를 통해 처리되는 트래픽 범위가 넓어질 수 있음 |
| Global Routing → Direct | 전역 직접 연결 방식으로 트래픽 처리 | VPN 네트워크 확장이 꺼진다는 뜻은 아님 |
| Global Routing → Scene | 설정된 Scene에 따라 라우팅 동작 선택 | 먼저 Scene 조건과 실제 적용 결과 확인 |
정리: 연결 시작 조건과 트래픽 분기를 구분하세요
연결이 시작되는 시점을 조정하려면 On Demand를 확인하고, 요청이 어떤 정책을 따를지 조정하려면 Global Routing과 Config를 확인하세요. Proxy를 Direct로 바꾸는 것만으로 연결이 끊기는 것은 아니며, 백그라운드 네트워크 확장이 중단됐다고 판단할 수도 없습니다.
4. 순서대로 On Demand 비교 테스트하기
테스트 전에 현재 설정으로 정상적으로 사용할 수 있는지 확인하고 기존 설정을 기록해 두세요. 한 번에 변수 하나만 바꾸세요. 먼저 연결 방식을 비교하고, 그다음 라우팅이나 프로토콜을 살펴보세요. 네트워크, 원격 서버, 규칙을 동시에 바꾸면 배터리 사용량이 줄어도 어떤 변경이 효과를 냈는지 확인하기 어렵습니다.
-
기준 기록하기
시스템의 ‘설정 → 배터리’에서 시작 및 종료 시 배터리 잔량, 시간, 화면 활동을 기록하세요. Shadowrocket의 Home에서는 연결 상태와 Global Routing을 기록합니다. 관찰 시간을 60분으로 정하고 그동안 비슷한 방식으로 기기를 사용해도 좋습니다.
-
주문형 규칙 확인하기
Shadowrocket에서 Settings → On Demand로 이동해 기능이 활성화되어 있는지, 현재 조건은 무엇인지 확인하세요. 메뉴에 표시되는 규칙 옵션은 현재 인터페이스를 기준으로 하세요. 먼저 기존 상태를 기록하고 출처를 알 수 없는 규칙으로 바로 바꾸지 마세요.
-
시스템 상태 확인하기
시스템의 ‘설정 → 일반 → VPN 및 기기 관리 → VPN’에서 Shadowrocket 설정과 연결 상태를 확인하세요. 시스템에 ‘주문형 연결’ 스위치가 있다면 그 상태도 기록합니다. 시스템 버전에 따라 표시 위치가 조금 다를 수 있습니다.
-
실제 연결 시작 여부 확인하기
Home으로 돌아가 연결 상태를 확인한 뒤 평소 사용하는 요청을 한 번 실행하세요. 화면 잠금 및 잠금 해제, Wi-Fi 전환 후의 결과를 각각 기록합니다. 연결을 끊은 직후 다시 연결된다면 연결 스위치의 오류라고 단정하지 말고 먼저 On Demand 조건과 백그라운드 요청을 확인하세요.
-
변수 하나씩 비교하기
현재 상태를 기록한 뒤 On Demand를 끄고 Home에서 연결을 해제해 시스템 VPN 상태가 바뀌는지 확인하세요. 시간과 부하가 비슷한 구간을 선택해 관찰합니다. 테스트를 마치면 필요한 연결을 복구해 이후 네트워크 사용에 지장이 없도록 하세요.
짧은 시간의 테스트는 뚜렷한 이상을 찾는 데 도움이 될 뿐, 하루 전체의 배터리 사용 시간을 나타내지는 않습니다. 두 테스트의 신호 세기, 화면 켜짐 시간 또는 백그라운드 동기화가 크게 달랐다면 다시 테스트하세요. 연결을 끊어 일부 요청이 완료되지 않아 트래픽이 자연히 줄어든 결과를 앱의 효율이 좋아졌다고 설명하지 마세요.
5. 자주 다시 연결된다면 먼저 실패 원인 확인하기
배터리 소모가 많고 접속이 느리다면 먼저 연결 안정성을 확인하세요. 로그에 한 번 실패가 기록됐다고 반드시 문제가 있는 것은 아닙니다. 같은 대상에 짧은 시간 동안 반복적으로 연결이 실패하고 요청 재시도나 상태 변화가 되풀이될 때 문제를 확인할 단서로 삼을 수 있습니다. 아래는 발생 가능한 하위 수준의 오류 문구이며, 모든 연결에서 똑같은 문구가 표시되는 것은 아닙니다.
오류: Operation timed out
원인: 제한 시간 안에 연결이 완료되지 않았습니다. 패킷 손실, 대상에 연결할 수 없는 상태 또는 원격 서버의 응답 문제일 수 있습니다.
해결 방법: 먼저 안정적인 네트워크에서 한 번 다시 시도한 다음, 본인 서비스 제공업체에 현재 주소와 포트를 확인하세요. 연속으로 속도를 측정하는 것으로 원인을 확인하려 하지 마세요.
오류: Connection refused
원인: 대상 주소에 연결할 수 있지만 연결이 거부됐습니다. 포트에서 서비스가 대기 중이지 않거나, 서비스 상태가 바뀌었거나, 접근 정책에 제한이 있을 수 있습니다.
해결 방법: 기존 설정의 서버와 포트를 확인하고 본인 서비스 제공업체가 안내한 유효한 매개변수로 수정하세요. 포트를 임의로 추측해 하나씩 시도하지 마세요.
본인 서비스 제공업체에서 설정이 변경됐다고 확인해 준 경우 Home에서 기존 Subscribe 항목을 업데이트한 다음 현재 선택된 설정을 확인하세요. 구독 업데이트는 최신 설정을 가져오는 방법이지 모든 연결 오류를 해결하는 만능 방법이 아닙니다. 배터리 문제를 확인하려고 업데이트를 반복하지 마세요.
- 셀룰러 네트워크에서만 문제 발생: 신호와 네트워크 커버리지를 먼저 비교하세요. 같은 설정을 유지한 채 안정적인 Wi-Fi에서도 같은 실패가 반복되는지 확인합니다.
- 네트워크 전환 후 문제 발생: 연결이 일시적으로 다시 설정되는 중인지 확인하세요. 오랫동안 복구되지 않으면 해당 시간대의 로그를 살펴보세요.
- 특정 원격 서버에서만 문제 발생: 해당 항목의 매개변수와 서비스 상태를 확인하세요. 기존 설정을 한꺼번에 모두 변경하지 마세요.
- 문제 확인을 위해 정보 전달: 오류 원문, 발생 시간, 네트워크 종류를 기록하세요. 정보를 공유하기 전에 구독 링크, 인증 정보, 서버 주소, 개인 요청 기록을 가리세요.
6. 기본적으로 전부 켜거나 끄지 말고 사용 환경에 맞게 선택하기
업무 중 같은 연결을 계속 사용해야 한다면 연결을 안정적으로 유지하는 편이 반복해서 수동 전환하는 것보다 문제 확인에 유리할 수 있습니다. 특정 네트워크 조건에서만 연결이 필요하다면 On Demand를 고려하되, 조건이 실제로 연결 시작 범위를 제한하는지 확인하세요. 모든 네트워크에서 연결되도록 규칙을 설정한다고 연결 시간이 반드시 줄어드는 것은 아닙니다.
| 사용 환경 | 우선 확인할 항목 | 판단 기준 |
|---|---|---|
| 장시간 연속 사용 | 연결 안정성, Global Routing, 실제 트래픽 | 스위치를 반복해서 바꾸기보다 연결 실패와 재시도를 줄이는 데 집중 |
| 특정 조건에서만 사용 | Settings → On Demand의 조건 | 조건 밖에서도 계속 연결되는지, 조건 안에서 제대로 연결되는지 |
| 밤사이 대기 중 배터리 소모가 큼 | 백그라운드 동기화, 신호 환경, 주문형 연결 시작 여부 | 비슷한 대기 시간대에 기기 전체 배터리 변화가 반복해서 나타나는지 |
| 연결을 끊자마자 다시 연결됨 | 앱과 시스템의 주문형 연결 상태 | 먼저 주문형 연결 시작을 끈 다음 수동으로 연결을 해제한 결과 확인 |
Config에서 DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 IP 주소 대역으로, GEOIP는 IP의 지리적 위치로 일치 항목을 찾습니다. 앞선 규칙과 일치하지 않는 요청은 FINAL이 처리합니다. 규칙 순서와 대상 정책이 실제 경로를 결정하므로 규칙이 설정되어 있다고 모든 요청이 직접 연결되는 것은 아닙니다. 배터리 목록의 앱 비중을 낮추려고 FINAL이나 프록시가 필요한 요청을 모두 DIRECT로 바꾸지 마세요.
정리: 반복해서 확인되는 배터리 변화를 기준으로 판단하세요
접속에 필요한 조건을 충족하고 연결이 안정적이며 비교 결과도 정상인 설정을 유지하세요. 앱의 배터리 사용 비중만 높고 기기 전체의 대기 중 배터리 소모, 온도, 접속 상태에 뚜렷한 변화가 없다면 해당 비율을 낮추려고 설정을 반복해서 바꿀 필요는 없습니다.