Shadowrocket의 On Demand는 조건에 따라 VPN 연결을 자동으로 설정하는 기능이며, 배터리 소모를 일괄적으로 줄여 주는 스위치는 아닙니다. 잠금 화면에서 배터리가 빨리 줄거나 연결을 끊은 뒤 자동으로 다시 연결되는 경우, 또는 네트워크를 바꿀 때 연결이 반복되는 경우에 유용합니다. 먼저 iPhone 배터리 기록을 확인하고, 사용 상황에 맞게 조건을 설정한 뒤 같은 조건에서 비교해 연결 유지, 실제 트래픽, 실패 후 재시도가 미치는 영향을 구분하세요. 연결 테스트에는 이미 보유한 서버 설정이나 구독이 필요합니다.
1. 백그라운드 연결, 트래픽, 자동 연결 조건 구분하기
Shadowrocket 화면을 닫아도 시스템 VPN 터널이 중지되는 것은 아닙니다. 시스템 네트워크 확장이 트래픽을 계속 처리할 수 있으므로 앱이 화면에 보이지 않는다는 이유만으로 작동 여부를 판단할 수 없습니다. 반대로 상태 막대에 VPN 표시가 있어도 기기가 계속 많은 데이터를 전송하는 것은 아닙니다. 유휴 연결과 지속적인 다운로드의 전력 소모는 따로 비교해야 합니다.
On Demand는 설정된 조건에 따라 시스템이 연결을 자동으로 설정하도록 합니다. 특정 앱을 열 때만 연결된다는 뜻도 아니고, 화면을 잠글 때마다 연결이 끊긴다는 보장도 없습니다. 백그라운드 동기화, 네트워크 변경, 조건에 맞는 네트워크 요청이 연결 활동과 동시에 발생할 수 있으며, 실제 동작은 현재 규칙과 시스템 동작에 따라 달라집니다.
상시 연결은 세션을 유지해야 할 수 있고, 재연결에는 DNS 조회, 전송 연결, 암호화 핸드셰이크가 필요할 수 있습니다. On Demand로 짧은 시간에 연결이 반복되면 유휴 상태에서 절약한 유지 비용보다 재연결 비용이 커질 수 있습니다. 따라서 자동 연결이 필요한지 판단하기 전에 연결이 안정적인지부터 확인하세요.
2. iPhone 배터리 기록으로 점검 기준 세우기
iPhone에서 설정 → 배터리를 열어 시스템이 제공하는 시간 범위와 활동 세부 정보를 확인하고, 배터리가 비정상적으로 줄어든 시간대를 선택하세요. 그래프와 필터 메뉴는 iOS 버전에 따라 다를 수 있으므로 기기에 표시되는 내용을 기준으로 확인합니다. 배터리 감소가 화면 사용, 백그라운드 활동, 다른 앱의 대량 네트워크 요청과 함께 발생했는지 살펴보세요. 앱 목록의 비율 하나만으로 판단하지 마세요.
- 시작 상태 기록. 시간, 배터리 잔량, Wi-Fi 또는 셀룰러 네트워크, 신호 상태, 충전 여부를 기록하세요. 테스트 중에는 충전이나 시스템 업데이트처럼 부하가 큰 작업을 피합니다.
- 사용 방식 고정. 잠금 화면에서 테스트한다면 계속 잠금 상태를 유지하고, 웹페이지를 확인한다면 비슷한 내용을 탐색하세요. 동영상을 재생한 결과와 대기 상태의 결과를 비교하지 마세요.
- 선택한 시간대 확인. 배터리 그래프에서 활동이 발생한 시간을 확인하고, 화면이 켜져 있던 활동과 백그라운드 활동을 구분하세요. 앱 사용량 비율은 일반적으로 선택한 시간대의 배터리 소모 비중을 나타내며, 배터리가 몇 퍼센트포인트 줄었는지를 직접 보여 주는 값은 아닙니다.
- 반복해서 관찰. 짧은 시간 동안 표시되는 배터리 잔량에는 측정 단위의 한계가 있습니다. 한두 퍼센트 차이가 한 번 나타난 것만으로 설정 효과를 입증할 수는 없습니다. 비슷한 조건에서 테스트를 반복하고 연결 기록과 함께 판단하세요.
결론: 시간대를 맞춘 뒤 원인을 판단하세요
배터리 이상 시간대와 연결 반복, 요청 실패 또는 지속적인 전송 시간이 서로 맞아떨어질 때 해당 원인을 더 살펴볼 필요가 있습니다. 백그라운드 사용량 순위만으로 On Demand가 배터리 소모 원인이라고 단정할 수는 없습니다.
3. Settings → On Demand 설정 및 확인 절차
설정을 바꾸기 전에 Home에서 현재 사용하는 서버를 확인하고, Config에서 활성화된 설정을 기록하세요. 그래야 점검 중 서버, 라우팅 모드, 자동 연결 조건을 동시에 바꿔 어느 변경이 결과에 영향을 주었는지 알 수 없는 상황을 피할 수 있습니다. 구독 내용이나 연결 매개변수가 궁금하다면 이용 중인 서비스 제공업체에 확인하세요.
- 설정으로 이동. Shadowrocket을 열고
Settings → On Demand로 이동해 기능이 활성화되어 있는지와 기존 조건을 확인하세요. 나중에 복원할 수 있도록 현재 상태를 기록합니다. - 먼저 끈 상태로 비교. On Demand를 잠시 끈 다음 Home으로 돌아가 연결을 수동으로 끊으세요. 터널을 통해 네트워크에 접속할 필요가 없는 시간대에 자동 연결이 여전히 발생하는지 확인합니다.
- 대상 네트워크 지정. 네트워크 환경에 따라 자동 연결하려면 On Demand를 활성화한 뒤 화면에서 실제로 제공하는 네트워크 종류나 네트워크 일치 조건을 설정하세요. 현재 화면에 SSID 조건이 있다면 기기가 실제로 연결된 Wi-Fi 이름을 입력하고 공백과 대소문자를 확인합니다.
- 조건 하나부터 시작. 먼저 조건 하나만 확인하고, 서로 겹칠 수 있는 조건을 한꺼번에 추가하지 마세요. 제한 조건을 입력하지 않았다고 해서 자동 연결이 발생하지 않는다고 단정하지 말고, 화면 안내와 실제 연결 결과를 확인하세요.
- 네트워크 진입과 이탈 확인. 대상 네트워크에 연결할 때, 네트워크를 벗어날 때, 화면을 잠근 뒤 다시 사용할 때를 각각 테스트하세요. 매번 Home에서 연결 상태를 확인합니다. iPhone의 설정 → 일반 → VPN 및 기기 관리 → VPN에서 시스템 설정을 확인할 경우, 다른 용도의 설정을 실수로 변경하지 않도록 주의하세요.
- 연결을 끊는 방법 확인. 연결을 끊은 상태로 유지하려면 먼저 On Demand를 끈 다음 Home에서 연결을 끊으세요. Home의 연결 스위치만 조작하면 다음에 조건이 충족될 때 다시 연결될 수 있습니다.
4. 사용 상황에 따라 상시 연결, On Demand, 수동 연결 선택하기
불필요한 연결 변화를 줄이면서 실제 접속 요구를 충족하도록 설정하세요. 하루 중 오랜 시간 터널이 필요한 사용자는 연결을 계속 재설정하기보다 안정적으로 유지하는 편이 나을 수 있습니다. 가끔 사용하는 경우에는 수동 연결이 관리하기 쉽습니다. On Demand는 연결 조건이 분명한 상황에 적합하며, 연결 목적을 판단하는 과정을 대신하지 않습니다.
| 사용 상황 | 테스트할 설정 | 우선 확인할 항목 |
|---|---|---|
| 하루 종일 터널이 필요한 리소스에 접속 | 안정적인 연결을 유지하고 현재 On Demand 설정과 비교 | 지속적인 트래픽, 실패 후 재시도 또는 잦은 재연결 여부 |
| 하루 중 잠깐만 사용 | On Demand를 끄고 필요할 때 Home에서 수동으로 연결 | 사용 후 연결을 끊었을 때 연결이 계속 끊긴 상태로 유지되는지 |
| 특정 네트워크 환경에서만 사용 | On Demand에서 실제로 지원하는 네트워크 조건 사용 | 해당 환경에 들어가거나 벗어날 때 예상대로 동작하는지 |
| Wi-Fi와 셀룰러 네트워크를 자주 전환 | 먼저 조건이 겹치지 않도록 정리하고 서버는 그대로 유지 | 네트워크 전환 시간과 연결 실패가 겹치는지 |
신호가 약하거나 포털 인증이 끝나지 않은 Wi-Fi, 네트워크 전환은 연결 설정 실패의 원인이 될 수 있습니다. 예를 들어 공용 Wi-Fi에 막 연결했다면 해당 네트워크의 인증 절차를 먼저 마친 뒤 터널을 확인하세요. 기본 네트워크를 사용할 수 없는 문제를 연결 스위치를 계속 조작해 해결하려고 하지 마세요. 셀룰러 신호가 약할 때의 배터리 소모는 무선 통신 자체에서 비롯될 수도 있으며, Shadowrocket만의 영향이라고 볼 수 없습니다.
5. 연결이 반복되면 설정을 바꾸기 전에 오류부터 확인
연결 기록에 실패가 반복된다면 오류가 발생한 시간, 사용한 네트워크, 대상 서버를 기록한 뒤 배터리 그래프와 비교하세요. 아래는 네트워크 진단에서 자주 보이는 영문 오류입니다. 실제 표기에는 대소문자, 접두어, 추가 정보가 다를 수 있으므로 기기에 표시된 원문 전체를 보존하세요. 오류는 원인을 찾기 위한 단서일 뿐, 기록 하나만으로 결론을 내릴 수는 없습니다.
오류: Connection refused
원인: 일반적으로 대상 주소의 포트가 연결을 거부했다는 뜻입니다. 서비스가 수신 대기 중이 아니거나 포트가 잘못 입력되었거나 네트워크 장비가 연결을 차단했을 수 있습니다.
해결 방법: 기존 설정에서 서버 주소, 포트, 프로토콜을 확인한 뒤 이용 중인 서비스 제공업체에 서비스 상태를 문의하세요. 오류를 없애려고 포트를 임의로 443으로 바꾸지 마세요.
오류: Operation timed out
원인: 제한 시간 안에 작업이 완료되지 않았다는 뜻입니다. 네트워크에 연결할 수 없거나 패킷이 손실되었거나 대상이 응답하지 않거나 연결 경로가 제한된 경우일 수 있습니다.
해결 방법: 설정을 그대로 둔 채 이용 가능한 다른 네트워크에서 다시 테스트하세요. 특정 네트워크에서만 실패한다면 서버보다 해당 네트워크를 먼저 확인합니다.
오류: Network is unreachable
원인: 현재 연결 경로를 사용할 수 없다는 뜻입니다. 네트워크 인터페이스를 전환했거나 기본 네트워크가 아직 복구되지 않은 상황에서 흔히 발생합니다.
해결 방법: 기기의 기본 인터넷 연결이 정상인지 확인하고 네트워크가 안정될 때까지 기다린 뒤 다시 시도하세요. 네트워크 전환 중 On Demand가 반복해서 작동하는지도 확인합니다.
실패 후 한 번 복구되는 것은 이상 현상이 아닐 수 있습니다. 실패와 재연결이 짧은 간격으로 반복되고 유효한 데이터 전송이 없는데도 계속되는지 확인하세요. DNS, 서버, 프로토콜, On Demand를 동시에 변경하지 마세요. 현상이 사라져도 원인을 알 수 없게 됩니다. 인증 정보나 구독 링크가 포함된 기록을 공유할 때는 민감한 정보를 가리세요.
6. Global Routing과 규칙은 트래픽 경로를 바꾸지만 연결을 끊지는 않습니다
Home에서 Global Routing을 확인할 때는 라우팅 정책과 터널 스위치를 구분하세요. Direct를 선택하면 요청의 아웃바운드 방식이 바뀌지만 시스템 VPN이 꺼지는 것은 아닙니다. Config를 선택하면 현재 설정에 따라 요청을 처리합니다. On Demand는 자동 연결 조건을 관리하는 기능으로, 두 설정은 서로 다른 영역입니다. Direct가 선택되어 있다는 이유만으로 백그라운드 터널이 중지되었다고 볼 수 없습니다.
명확하게 지정한 웹사이트만 프록시를 통과하게 하려면 백업한 뒤 Config에서 규칙과 순서를 확인하세요. 아래 내용은 문법 설명에 한정됩니다. example.com은 예시 도메인이며, PROXY는 실제 설정에서 사용할 수 있는 정책이어야 합니다. 이 예시는 모든 상황에 적용되는 절전 설정이 아니므로 사용 중인 전체 설정을 그대로 덮어쓰지 마세요.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 일치시킵니다. 더 구체적인 조건은 기본 규칙보다 앞에 배치해야 합니다.FINAL,DIRECT는 앞선 규칙에 일치하지 않은 요청에 DIRECT를 지정합니다. 터널을 끄는 기능은 아닙니다.- 규칙을 간소화한 뒤에도 실제 요청이 예상한 정책에 일치하는지 확인해야 합니다. 필요한 프록시 트래픽, DNS 조회, 실패 후 재시도는 FINAL 규칙이 있다고 해서 자동으로 사라지지 않습니다.
마찬가지로 배터리를 아끼려고 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard를 무작정 바꾸지 마세요. 프로토콜, 전송 방식, 서버 품질, 현재 네트워크가 모두 결과에 영향을 주며, 해당 설정을 서버 측에서도 지원해야 합니다. 프로토콜 이름만으로 특정 네트워크에서 iPhone의 배터리 소모를 예측할 수는 없습니다.
7. 재현 가능한 비교 결과로 점검 마무리하기
점검은 완전 연결 해제, 수동으로 안정적으로 연결, 조건을 명확히 설정한 On Demand의 세 단계로 진행하는 것이 좋습니다. 각 단계는 비슷한 시간과 사용 방식으로 테스트하고 네트워크, 서버, 라우팅 설정은 동일하게 유지하세요. 이 단계는 테스트 방법일 뿐, 일상적으로 연결 방식을 계속 전환하라는 뜻은 아닙니다.
- 완전 연결 해제 단계. On Demand를 끄고 연결을 해제한 뒤 해당 상황에서의 기본 배터리 소모를 기록하세요. 이 상태에서도 이상이 뚜렷하다면 화면 활동, 다른 앱, 신호 상태, 시스템 작업을 추가로 확인합니다.
- 안정적인 연결 단계. On Demand를 끈 상태로 두고 수동으로 연결하세요. 같은 양의 트래픽을 처리할 때 비정상적인 발열, 반복 오류, 대량의 백그라운드 요청이 발생하는지 관찰합니다.
- 자동 연결 단계. 확인을 마친 조건 하나를 활성화하고 연결 횟수가 크게 늘었는지, 그 변화가 배터리 감소가 집중된 시간대와 겹치는지 확인하세요.
- 기록 보관. 각 단계의 시작·종료 배터리 잔량과 시간, 연결 상태, 오류 원문을 저장하세요. 추가 점검이 필요할 때는 이 정보가 “백그라운드에서 배터리를 많이 소모한다”는 설명보다 유용합니다.
결론: 실제 사용에 필요한 자동 연결 조건만 유지하세요
자동 연결 단계에서 재연결이 잦지만 수동으로 안정적으로 연결했을 때는 정상이라면 On Demand 조건부터 수정하세요. 두 연결 단계 모두 문제가 있다면 네트워크, 서버, 지속적인 요청을 우선 점검합니다. 배터리 변화가 생길 때마다 같은 스위치만 원인으로 지목하지 마세요.
최종 설정은 사용 가능성과 검증 가능성을 모두 충족해야 합니다. 연결이 필요할 때 연결되고, 필요하지 않을 때는 연결이 끊긴 상태를 유지하며, 네트워크 전환 후 실패가 계속되지 않아야 합니다. 이 과정을 마친 뒤 한 번의 배터리 비율만으로 판단하지 말고 상시 연결, On Demand, 수동 연결 중 실제 사용에 맞는 방식을 선택하세요.