모바일 프록시 앱 배터리 소모 줄이는 법: 백그라운드 실행 및 절전 설정

먼저 구분하기: 프록시 배터리 소모, 사용량 집계, 백그라운드 연결 끊김

휴대폰에서 프록시를 켠 뒤 배터리 사용량 목록에서 클라이언트 비중이 커져도 프록시 코어가 계속 높은 부하로 작동한다는 뜻은 아닙니다. Android VPN 서비스와 iOS 네트워크 확장은 다른 앱의 연결을 처리합니다. 이 네트워크 활동을 집계하는 방식은 OS 버전과 기기 구현에 따라 달라집니다. 앱 순위만 보지 말고 기기 전체의 배터리 감소량, 실제 데이터 사용량, 발열을 함께 확인한 뒤 프록시 이상 여부를 판단하세요.

또 자주 혼동하는 점은 ‘백그라운드 일시 중지’를 ‘배터리 절약에 성공한 것’으로 여기는 것입니다. 화면을 잠근 뒤 알림이 늦게 오거나 잠금 해제 후 노드에 다시 연결된다면, 배터리 소모가 줄어든 것처럼 보여도 네트워크 서비스가 종료된 것일 수 있습니다. 불필요한 깨우기와 재시도는 줄이되 필요한 연결은 유지해야 합니다.

증상에 따라 첫 조치 정하기

화면을 잠가도 눈에 띄게 뜨거움: 지속적인 업로드·다운로드, 노드 재연결 반복, 속도 측정 작업 또는 오류 로그 급증 여부부터 확인하세요.
모바일 데이터에서만 배터리가 빨리 닳음: 신호 세기와 네트워크 전환 횟수를 먼저 비교하세요. 신호가 약하면 무선 통신에 드는 전력이 프록시 처리 자체보다 클 수 있습니다.
화면을 잠근 뒤 한동안 지나면 인터넷이 끊김: 먼저 Android의 배터리 제한이나 iOS VPN 확장의 연결 해제 기록을 확인하세요. DNS부터 변경하지 마세요.
배터리 사용 비중은 높지만 대기 중 기기 전체 소모는 정상: 현재 설정을 유지하고 같은 조건에서 실제 배터리 감소량을 더 관찰하세요.

배터리 사용 비중만 보고 설정을 바꾸지 말고 60분 비교 테스트하기

휴대폰 모델, OS 버전, 클라이언트 버전, 코어 버전, 네트워크 유형, 현재 노드를 먼저 기록하세요. 버전은 클라이언트의 ‘정보’ 화면에서 확인하고 ‘최신 버전’이라고만 적지 마세요. 테스트 중에는 Wi-Fi, 노드, 화면 상태, 백그라운드 앱을 동일하게 유지하고 시스템 업데이트, 사진 백업, 대용량 다운로드를 일시 중지하세요. 매회 설정 하나만 변경합니다.

구독과 규칙 업데이트를 마친 뒤 5분간 기다려 초기 로딩과 연결 설정이 끝나도록 합니다.
화면을 잠근 채 60분 동안 그대로 둔 다음 시작·종료 배터리 잔량, 프록시 트래픽, 연결 끊김 횟수, 기기 발열을 기록합니다.
자동 속도 측정 간격을 60초에서 600초로 바꾸는 등 변수를 하나 조정한 뒤 같은 조건으로 다시 테스트합니다.
최소 두 차례 반복하세요. 시간당 차이가 1%p에 불과하다면 배터리 잔량 표시의 반올림으로 인한 오판을 피하도록 3시간으로 늘립니다.

예를 들어 시작이 80%, 종료가 77%라면 한 시간 동안 기기 전체 배터리가 3%p 감소한 것입니다. 이를 ‘프록시가 3% 소모했다’고 볼 수는 없습니다. 아래 기록표는 작성 예시이며 특정 기기에서 측정한 결과가 아닙니다.

테스트 조건	관찰 시간	기록 항목
프록시 끔, Wi-Fi 고정	60분	기기 전체 배터리 감소량, 백그라운드 트래픽
프록시 켬, 기존 설정	60분	기기 전체 배터리 감소량, 속도 측정 횟수, 연결 끊김
프록시 켬, 자동 속도 측정 줄임	60분	같은 지표 및 메시지 수신 여부

프록시를 끄면 앱의 연결 가능 상태가 달라집니다. 일부 백그라운드 요청이 중단될 수도 있고 계속 재시도할 수도 있으므로 첫 테스트는 기준선일 뿐, 프록시 소모량만 엄밀히 분리해 측정하는 실험은 아닙니다. 공개 로그에 구독 주소, 노드 비밀번호, 전체 접속 기록을 남기지 마세요.

자동 속도 측정과 중복 규칙 업데이트 줄이기

먼저 어떤 기능이 연결을 능동적으로 시작하는지 확인하기

그룹의 자동 선택, 노드 제공자의 상태 확인, 홈 화면의 지연 시간 갱신이 각각 탐색 요청을 발생시킬 수 있습니다. 상태 확인 한 번에 전송되는 데이터는 보통 적지만, 수백 개 노드를 짧은 간격으로 반복 확인하면 연결이 크게 늘고 모바일 데이터 무선 모듈이 더 자주 활성 상태를 유지합니다. 클라이언트 화면에서 예약 속도 측정을 꺼도 설정에 있는 상태 확인까지 꺼진 것은 아닙니다.

속도 측정 간격: 우선 600초로 설정해 살펴보고, 네트워크가 안정적이면 1800초도 시도해 보세요. 간격이 길수록 장애를 발견하는 시간도 늦어질 수 있습니다.
노드 수: 자동 테스트 범위를 줄이고 실제 사용하는 지역이나 그룹만 남기세요. 구독의 모든 노드를 매번 확인할 필요는 없습니다.
수동 속도 측정: 문제를 진단할 때만 사용하세요. 전체 노드 측정을 연속으로 실행해 테스트 자체가 추가 부하를 만들지 않도록 합니다.

mihomo 노드 제공자의 health-check.interval은 초 단위입니다. health-check.lazy를 사용하면 제공자 노드를 사용하지 않을 때 일반 주기로 계속 확인하는 일을 줄일 수 있지만, 모든 탐색이 꺼지는 것은 아닙니다. 그룹의 url-test에는 별도의 interval이 있으므로 함께 확인하세요. 모바일 클라이언트에 따라 이 항목을 화면에서 편집할 수 없을 수도 있습니다.

구독 업데이트, 규칙 다운로드, 상태 확인 구분하기

구독 업데이트는 노드 설정을 가져오고, 규칙 제공자 업데이트는 트래픽 분류 규칙을 다운로드하며, 상태 확인은 노드 연결 가능 여부를 테스트합니다. 세 작업은 같은 설정으로 제어되지 않습니다. 노드와 규칙을 하루 한 번, 즉 86400초 간격으로 갱신하는 것을 일반적인 시작점으로 삼을 수 있습니다. 서비스 제공자가 더 짧은 주기를 명시한 경우에는 실제 필요에 맞춰 조정하세요.

‘규칙을 최신 상태로 유지’하려고 60초마다 새로고침하지 말고 업데이트를 모두 끄는 것도 피하세요. 앱의 예약 업데이트와 설정 제공자의 예약 업데이트가 함께 켜져 있는지 확인하세요. 구독이 자주 바뀌고 업데이트 때마다 코어가 다시 로드된다면 로그에서 주기적인 재연결이 발생하는지 살펴보는 것이 좋습니다. 오버라이드로 변경 사항을 저장한 뒤 구독을 새로고침하고 최종 적용 설정을 다시 확인하세요.

DNS와 연결 재시도: 캐시보다 오류부터 바로잡기

DNS 조회만으로 지속적인 배터리 소모가 발생하는 경우는 드뭅니다. 파싱 실패 후 요청이 반복되는지, 업스트림 서버에 연결할 수 없는지, 프록시 서버의 도메인을 해석하지 못하는지, DNS 요청이 잘못 프록시 입구로 돌아가 순환하는지를 확인하세요. 같은 도메인이 짧은 시간 안에 반복해서 나타나며 시간 초과, 연결 실패, 노드 전환이 동반되는 경우가 많습니다.

로그를 열고 잠시 info 수준으로 설정한 뒤 2~5분간 살펴보세요. 원인을 찾으면 계속 관찰하지 말고 상세 로그도 장시간 켜 두지 마세요.
Wi-Fi와 모바일 데이터에서 같은 웹사이트를 각각 한 번씩 테스트하세요. 특정 네트워크에서만 실패한다면 먼저 해당 네트워크에서 DNS 업스트림에 연결할 수 있는지 확인하세요.
DNS 업스트림이 직접 연결되는지 프록시를 거치는지, 노드 도메인의 초기 해석 경로는 무엇인지 확인하세요. mihomo의 proxy-server-nameserver는 프록시 노드 도메인 해석에 사용되며 일반 도메인 전체의 DNS 서버를 뜻하지 않습니다.
순환이나 시간 초과를 해결한 뒤 배터리 소모를 비교하세요. 업스트림 변경, 해석 모드 전환, 라우팅 조정을 한꺼번에 하지 마세요.

DoH와 DoT는 암호화된 DNS 조회를 제공하지만 모든 방식보다 전력을 덜 쓰는 것은 아닙니다. 연결 재사용, 업스트림 응답 시간, 실패 후 재시도가 결과에 영향을 줍니다. ‘업스트림이 많을수록 안정적’이라는 원칙도 적용되지 않습니다. 동시에 여러 서버에 질의하는 구현에서는 업스트림을 추가할수록 요청이 늘어날 수 있습니다.

Android 백그라운드 실행: 필요한 서비스만 제한 해제하기

Android 프록시는 보통 VpnService로 로컬 VPN 인터페이스를 만듭니다. 계속 실행 중이면 일반적으로 포그라운드 서비스 알림이 표시되지만, 이것이 고강도 데이터 전송을 뜻하지는 않습니다. Doze, 앱 대기 제한, 제조사별 백그라운드 관리가 연결에 영향을 줄 수 있으며 실제 동작은 Android 버전, 클라이언트 구현, 제조사 정책에 따라 다릅니다.

Android 14·15 설정 참고

기본 Android에 가까운 시스템을 기준으로 「설정」→「앱」→「모든 앱 보기」→ 프록시 클라이언트 →「앱 배터리 사용량」으로 이동해 ‘백그라운드 사용 허용’과 ‘제한 없음/최적화/제한됨’ 항목을 확인하세요. 메뉴 이름과 위치는 OS 버전에 따라 달라질 수 있습니다. 앱 아이콘을 길게 눌러 「앱 정보」를 연 뒤 화면에서 ‘배터리’를 검색해도 됩니다.

연결이 안정적임: 우선 ‘최적화됨’을 유지하고 백그라운드 실행을 위해 미리 모든 권한을 허용하지 마세요.
화면을 잠근 뒤 연결 끊김이 재현됨: 프록시 클라이언트만 ‘제한 없음’으로 바꾸고 화면 잠금 테스트를 반복해 실제로 개선되는지 확인하세요.
재부팅 후 자동으로 실행되지 않음: 클라이언트의 자동 시작 옵션과 제조사 시스템의 자동 시작 또는 백그라운드 활동 허용 여부를 확인하세요.
절전 모드에서 이상 발생: 절전 모드를 켜고 끈 상태를 각각 테스트해 차이를 기록하세요. 시스템 절전 기능을 한꺼번에 모두 끄지는 마세요.

배터리 최적화 예외 등록은 일부 백그라운드 제한을 줄일 뿐, 코어가 트래픽을 처리하는 데 필요한 연산량을 낮추지는 않습니다. 모든 앱을 예외로 등록하지도 마세요. 다른 백그라운드 작업이 늘어 기기 전체 대기 소모가 오히려 커질 수 있습니다. 최근 앱 화면에서 앱을 잠그는 기능은 일부 제조사에서 제공하는 보조 기능이며 서비스 상태 확인을 대신하지 않습니다.

‘VPN 항상 사용’과 연결 차단 기능의 범위

일부 기기에서는 「설정」→「네트워크 및 인터넷」→「VPN」→ 해당 VPN 설정에서 ‘VPN 항상 사용’을 켤 수 있습니다. 클라이언트가 지원하는 경우에만 사용할 수 있습니다. ‘VPN을 사용하지 않는 연결 차단’은 킬 스위치 기능으로, VPN 서비스에 문제가 생기면 기기 전체의 인터넷 연결이 막힐 수 있으며 절전 옵션이 아닙니다. 켜기 전에 연결이 끊겼을 때 복구하는 방법을 확인하세요.

디버깅 환경이 있다면 Android 플랫폼 도구로 상태를 확인할 수 있습니다. 아래 명령은 정보를 조회할 뿐 배터리 정책을 변경하지 않습니다.

adb shell dumpsys deviceidle
adb shell dumpsys battery

첫 번째 명령은 기기의 유휴 상태 관련 정보를 확인하고, 두 번째 명령은 배터리 상태 스냅샷을 보여 줍니다. 어느 명령도 특정 프록시 코어의 정확한 전력 소비량을 알려 주지는 않습니다. USB를 연결하면 충전 및 유휴 조건이 달라질 수 있으므로 케이블을 연결한 상태의 디버깅 결과를 일반 대기 상태의 결과로 간주하지 마세요.

iOS 백그라운드 정책: VPN 확장 및 주문형 연결 확인

iOS 프록시 클라이언트는 보통 기본 앱에서 설정을 관리하고 Network Extension의 VPN 확장으로 네트워크 트래픽을 처리합니다. 기본 앱이 화면에 표시되지 않아도 VPN 확장은 계속 실행될 수 있습니다. 기본 앱을 화면에 계속 띄워 두는 것은 연결을 유지하는 데 필요하지 않습니다. 확장 충돌, 설정 다시 불러오기, 시스템 리소스 제한으로 서비스가 중단될 수 있으니 클라이언트 로그를 함께 확인하세요.

먼저 시스템 배터리 기록 확인하기

iOS 18을 기준으로 「설정」→「배터리」에서 ‘지난 24시간’과 ‘지난 10일’을 비교하고, 이상이 나타난 시간대를 탭해 화면 사용과 백그라운드 활동을 확인하세요. 이상이 핫스팟 공유, 이동 중 약한 신호, 대량 영상 전송과 겹친다면 프록시를 조정하기 전에 해당 변수를 먼저 통제하세요.

백그라운드 앱 새로고침: VPN 확장의 실행 허용 여부와는 별개입니다. 이 전체 설정을 켜도 확장이 항상 실행되는 것은 아닙니다.
저전력 모드: 여러 시스템 백그라운드 동작을 조정합니다. VPN을 반드시 종료한다고 단정하지 말고 실제 기기에서 연결이 달라지는지 확인하세요.
주문형 연결: 클라이언트의 주문형 규칙이 Wi-Fi와 모바일 데이터 사이를 오갈 때 연결과 해제를 반복해서 실행하는지 확인하세요.
다른 VPN 설정: 「설정」→「일반」→「VPN 및 기기 관리」에서 확인할 수 있습니다. 관리되는 기기는 조직 정책을 따르고 관리 설정을 임의로 삭제하지 마세요.

iOS에는 Android의 ‘앱 배터리 제한 없음’에 완전히 대응하는 범용 허용 목록이 없습니다. 특정 클라이언트의 확장이 큰 규칙 집합에서 자주 재시작된다면 불필요한 규칙 제공자를 줄이고 상세 로그를 끈 뒤 유지보수 버전으로 업데이트해 재시작 기록을 살펴보세요. 메모리 사용량만으로 배터리 소모 원인을 단정할 수는 없습니다.

TUN, 트래픽 분할, 최종 점검 순서

모바일의 로컬 VPN 트래픽 처리와 데스크톱 클라이언트의 TUN 스위치는 기계적으로 대응되는 버튼이 아닙니다. Android와 iOS 클라이언트는 보통 가상 네트워크 인터페이스로 데이터를 주고받습니다. 데스크톱 안내를 그대로 따라 별도의 VPN 서비스를 추가하지 마세요. 일반적인 개인 사용 환경에서는 시스템이 서로 다른 VPN 두 개에 같은 사용자 트래픽을 동시에 맡기도록 허용하지 않는 경우가 많습니다.

규칙 모드는 어떤 연결을 직접 연결하고 어떤 연결을 프록시로 보낼지 결정하지만, 직접 연결되는 트래픽도 클라이언트의 VPN 데이터 경로를 통과할 수 있습니다. 따라서 ‘DIRECT에 매칭됨’이 처리 비용이 전혀 없다는 뜻은 아닙니다. 일부 Android 클라이언트는 앱별 VPN 우회를 지원하며 이는 규칙의 직접 연결과 다릅니다. 사용 전에 우회할 앱에 프록시가 필요하지 않은지, 해당 앱의 네트워크 접근 요구사항에 맞는지 확인하세요.

다음 순서로 마무리하기

정상적인 트래픽 확인: 동기화, 다운로드, 약한 신호, 잦은 네트워크 전환부터 배제하세요.
주기 작업 줄이기: 속도 측정 간격을 우선 600초로 늘리고, 규칙과 구독 업데이트는 필요에 맞게 설정하세요. 예를 들어 하루 한 번이면 충분할 수 있습니다.
반복되는 실패 해결: DNS, 노드 연결 가능 여부, 오류 로그를 확인하고 자동 전환으로 지속적인 시간 초과를 가리지 마세요.
실제로 확인된 백그라운드 제한만 조정: Android에서는 필요한 경우에만 배터리 제한을 해제하고, iOS에서는 확장 로그와 주문형 연결 조건을 확인하세요.
연결 상태 재테스트: 화면을 30분 이상 잠근 상태에서 메시지 수신, 웹페이지 접속, Wi-Fi·모바일 데이터 전환이 모두 정상인지 확인한 뒤 장시간 배터리 비교 테스트를 진행하세요.

효과적인 절전 조정은 두 조건을 모두 충족해야 합니다. 같은 사용 조건에서 기기 전체 배터리 감소량이 줄고 필요한 네트워크 연결은 정상이어야 합니다. 배터리가 덜 닳은 이유가 서비스 종료나 앱 요청 실패라면 먼저 연결을 복구하세요. ‘절전 설정’을 한꺼번에 적용하기보다 변경 전후 설정을 기록하면 실제 영향을 준 변수를 찾기 쉽습니다. 규칙과 오버라이드 항목은 설정 참고에서 확인할 수 있습니다. 연결에 문제가 생기면 문제 해결 안내에 따라 하나씩 점검하세요.