안드로이드 프록시 앱 배터리 소모 해결: 배터리 최적화 예외·백그라운드 실행·TUN 설정

먼저 구분할 것: 배터리 소모 증가, 사용량 집계, 백그라운드 연결 끊김

안드로이드 프록시 앱의 배터리 소모가 빠르다고 해서 배터리 사용량 목록의 순위만으로 원인을 판단해서는 안 됩니다. 클라이언트가 Android의 VpnService를 통해 연결을 처리하면 시스템이 일부 네트워크 활동과 관련 배터리 소모를 VPN 앱 사용량으로 집계할 수 있습니다. 집계 방식은 Android 버전과 제조사별 시스템에 따라 다를 수 있습니다. 앱이 목록 상위에 있다고 해서 기기 전체 배터리의 해당 비율을 앱이 단독으로 소모한다는 뜻은 아닙니다.

먼저 같은 조건에서 기기 전체 배터리 소모량을 비교하고, 연결 안정성을 확인한 다음 백그라운드 권한과 설정을 조정하세요. 화면이 꺼진 뒤에만 연결이 끊긴다면 백그라운드 제한부터 확인하고, 대기 중 배터리 소모가 눈에 띄게 늘었다면 상태 확인, 재연결, 실제 백그라운드 트래픽, 모바일 신호를 점검하세요. 두 문제가 함께 나타날 수 있지만 해결 방향은 서로 다릅니다.

비교 가능한 대기 기록 만들기

매 회 최소 60분, 한 번에 변수 하나만 변경

같은 장소와 네트워크를 선택하고 배터리 잔량도 비슷한 수준으로 맞추세요. 예를 들어 모두 80% 안팎에서 시작합니다. 시스템 업데이트, 사진 백업, 대용량 다운로드를 중지하고 클라이언트의 실시간 연결 화면을 닫은 뒤 화면을 끄세요. 첫 번째 회차는 프록시 서비스를 중지하고, 두 번째 회차는 같은 구독으로 서비스를 켭니다. 세 번째 회차에서는 의심되는 설정 하나만 변경합니다. 회차마다 최소 60분 관찰하고, 사용량이 적은 환경에서는 2~3시간으로 늘릴 수 있습니다.

• 기기 전체 변화 기록: 시작 및 종료 배터리 잔량, 경과 시간, 화면 켜짐 시간, 충전 여부를 기록합니다.
• 네트워크 환경 기록: Wi-Fi 또는 모바일 데이터, 신호 변동 여부, 두 네트워크 간 전환 여부를 기록합니다.
• 클라이언트 상태 기록: 제품명과 버전, 커널 버전, 설정 이름, 앱별 라우팅 사용 여부를 기록합니다.
• 사용 작업 기록: 오디오 재생, 메시지 수신, 사진 백업, 핫스팟 사용 여부를 기록합니다.

예를 들어 2시간 동안 배터리가 80%에서 76%로 줄어든 회차와 80%에서 73%로 줄어든 회차가 있다면, 시간당 평균 소모량은 각각 2%p와 3.5%p입니다. 이는 계산 방법을 보여 주기 위한 예시일 뿐, 제품 실측 결과나 합격 기준이 아닙니다. 배터리 잔량 표시는 반올림 오차가 있으므로 한 번의 테스트에서 1%p 차이가 났다고 판단하기 어렵습니다. 여러 번 반복하고 온도, 신호, 백그라운드 작업의 차이도 배제하세요.

배터리 최적화 예외: 안정성이 필요할 때만 허용

Android의 Doze, 앱 대기 제한, 제조사별 백그라운드 관리 기능은 백그라운드 네트워크와 작업 실행에 영향을 줄 수 있습니다. 클라이언트를 ‘제한 없음’으로 설정하면 일부 배터리 정책의 개입을 줄일 수 있지만, 노드 시간 초과나 DNS 반복 요청, 잘못된 규칙이 해결되는 것은 아니며 프로세스가 절대 종료되지 않는다는 보장도 없습니다. 화면이 꺼진 뒤 연결이 끊기거나 서비스가 반복해서 사라지는 경우에만 백그라운드 권한을 우선 점검하세요.

Android 버전에 맞는 앱 배터리 설정 찾기

1. 클라이언트 아이콘을 길게 누른 뒤 ‘앱 정보’로 이동해 ‘배터리’ 또는 ‘앱 배터리 사용량’을 확인하세요.
2. 일부 기본 Android 13 화면을 기준으로 하면 ‘설정’ → ‘앱’ → ‘모든 앱 보기’ → 클라이언트 → ‘앱 배터리 사용량’에서 ‘제한 없음’을 선택할 수 있습니다. 다른 버전에서는 ‘백그라운드 사용 허용’ 등으로 표시될 수 있으니 기기에 표시되는 옵션을 따르세요.
3. 일부 HyperOS 기기에서는 ‘설정’ → ‘앱 설정’ → ‘앱 관리’ → 클라이언트 → ‘배터리 절약 정책’에서 ‘제한 없음’을 찾을 수 있습니다. 해당 경로가 없는 버전이라면 설정에서 ‘배터리 절약 정책’을 검색하세요.
4. 삼성 기기에서는 ‘설정’ → ‘배터리’ → ‘백그라운드 사용 제한’에서 클라이언트가 절전 또는 초절전 앱 목록에 있는지 확인하세요. 상위 메뉴 경로는 One UI 버전에 따라 다를 수 있습니다.
5. 한 번에 설정 하나만 변경하고 화면을 끈 상태로 30~60분 테스트한 뒤, 알림 창의 서비스 표시와 네트워크 연결, 로그가 끊기지 않는지 확인하세요.

‘자동 시작 허용’, ‘최근 앱에서 잠금’, ‘배터리 최적화 예외’는 서로 다른 제어 기능입니다. 최근 앱에서 잠그는 것은 전체 정리 시 앱이 제거될 가능성을 낮출 뿐, Android가 앱 실행을 계속 보장한다는 뜻은 아닙니다. 재부팅 후 자동 연결이 필요하다면 클라이언트의 부팅 시 시작 설정과 시스템의 자동 시작 권한도 함께 확인하세요. 자동 연결이 필요하지 않다면 대기 테스트를 위해 굳이 켤 필요는 없습니다.

예외를 허용한 뒤 기기 전체 배터리 소모가 오히려 늘었다면 연결 상태와 로그를 다시 살펴보세요. 이전에는 제한되던 잦은 작업이 계속 실행되기 시작했을 수 있습니다. 배터리 최적화 예외는 작업을 실행할 기회를 주는 것이지, 작업 자체의 효율을 높이는 설정은 아닙니다.

VPN 상시 연결과 TUN: 실제 트래픽 처리 방식을 먼저 확인

Android용 Clash 계열 클라이언트는 보통 VpnService로 가상 네트워크 인터페이스를 만든 다음 커널이나 별도 전달 구성 요소로 연결을 처리합니다. 데스크톱 안내의 ‘TUN을 끄고 시스템 프록시만 사용’하는 방법을 휴대폰에 그대로 적용할 수는 없습니다. Android의 Wi-Fi 프록시는 네트워크별로 설정하는 방식이며 모든 앱이 따르는 것도 아니고, 기기 전체에 적용되는 범용 시스템 프록시도 아닙니다.

클라이언트 화면의 ‘TUN’, ‘VPN 모드’, ‘네트워크 스택’은 서로 다른 구현 계층을 가리킬 수 있습니다. 일부 제품에는 따로 끌 수 있는 TUN 옵션이 없으며 VPN 서비스를 종료하면 트래픽 처리도 중단됩니다. 네트워크 스택 옵션은 클라이언트와 커널 버전에 따라 달라지므로 특정 스택으로 바꾸면 언제나 배터리가 절약된다고 볼 수 없습니다.

사용 목적에 맞게 트래픽 처리 범위 선택

• 일부 앱만 프록시를 사용하면 되는 경우: 클라이언트가 ‘선택한 앱만 허용’을 지원한다면 실제로 필요한 앱만 포함하세요. 먼저 화면의 모드 설명을 읽고 선택한 앱이 ‘VPN을 통과하는지’ 또는 ‘VPN을 우회하는지’ 확인하세요.
• 규칙 기반 라우팅이 필요한 경우: 규칙 모드를 유지하고 중국 본토 서비스나 로컬 네트워크 대상이 예상한 직접 연결 규칙에 일치하는지 확인하세요. VPN으로 트래픽을 전달한 뒤 DIRECT 규칙이 적용되더라도 VPN 처리 경로를 전혀 거치지 않는다는 뜻은 아닙니다.
• 연결을 계속 유지해야 하는 경우: 시스템의 ‘항상 켜진 VPN’을 사용할 수 있습니다. 일부 기본 Android 시스템에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’ → 해당 연결의 설정 버튼에서 찾을 수 있습니다.
• VPN 우회를 차단해야 하는 경우: ‘VPN을 사용하지 않는 연결 차단’을 고려하세요. 이는 연결 정책이지 배터리 절약 옵션이 아닙니다. 앱 우회나 로컬 네트워크 접근과 함께 사용하기 전에 반드시 실제로 테스트하세요.

구독, 상태 확인, 재연결: 주기적으로 깨어나는 작업 확인

클라이언트가 유휴 상태여도 설정에 예약 작업이 있을 수 있습니다. 구독 자동 업데이트, 프록시 제공자의 상태 확인, url-test 정책 그룹 테스트, 사용 중인 앱의 연결 확인 작업 등이 백그라운드 요청을 발생시킬 수 있습니다. 여러 기능이 같은 노드를 반복해서 검사할 수도 있으므로 클라이언트 설정과 실제 적용 중인 설정을 함께 살펴보세요.

먼저 다음 네 가지를 확인하세요

1. 상태 확인 간격: mihomo 설정에서 프록시 그룹과 프록시 제공자의 상태 확인에 쓰이는 interval은 보통 초 단위입니다. 30초 간격이면 시간당 120회, 300초 간격이면 12회의 실행 시점이 생깁니다. 실제 요청 수는 노드 수, 지연 검사 여부, 구현 방식에 따라 달라지므로 배터리 소모 비율과 직접 연결할 수는 없습니다.
2. 지연 검사: 지원되는 경우 lazy: true를 사용해 사용하지 않는 그룹이나 제공자의 불필요한 검사를 줄일 수 있는지 살펴보세요. 필드는 해당 설정 계층에 넣어야 하며 클라이언트의 재정의 설정에 따라 최종 결과가 달라질 수도 있습니다.
3. 구독 업데이트: 일반적인 사용에서 구독을 매분 갱신할 필요는 없습니다. 서비스 제공자의 업데이트 주기에 맞춰 몇 시간 단위로 설정하거나 수동 갱신을 선택해 설정을 반복해서 내려받고 파싱한 뒤 다시 불러오는 일을 줄이세요.
4. 실패 재시도: 로그에 시간 초과가 계속 나타나면 먼저 안정적으로 연결되는 노드를 선택한 뒤 반복 접속이 계속되는지 확인하세요. 속도 측정 간격을 늘려도 사용 중인 노드가 계속 실패하는 문제는 해결되지 않습니다.

탐지 횟수를 줄이려고 자동 정책을 한꺼번에 모두 삭제하지 마세요. 우선 지나치게 짧은 검사 간격을 예를 들어 300초로 늘리고 노드 전환 경험과 대기 중 데이터 사용량을 확인하세요. 이는 문제를 조사하기 위한 시작점이지 모든 구독에 적용되는 일괄 권장값은 아닙니다. 구독 관리자가 업데이트 중 설정을 덮어쓸 수 있으므로 클라이언트가 지원하는 지속형 재정의 기능을 우선 사용하고 업데이트 뒤 실제 적용된 설정을 확인하세요.

DNS, 로그, 백그라운드 작업: 지속적인 활동 원인 찾기

DNS 오류는 연결 경로를 해결해야 하며 모드만 바꿔서는 안 됩니다

로그에 이름 확인 시간 초과가 반복해서 나타난다면 DNS 상위 서버에 연결할 수 있는지, 프록시 서버 도메인을 확인할 수 있는지, DNS 연결이 아직 수립되지 않은 프록시에 다시 의존하는지부터 살펴보세요. mihomo의 proxy-server-nameserver는 프록시 노드 도메인 확인에 사용할 수 있지만 기존 DNS 라우팅 설계와 일관되게 설정해야 합니다. 필드 하나를 복사하는 것만으로 문제가 해결됐다고 단정할 수는 없습니다.

Fake-IP는 가상 주소로 도메인과 연결의 매핑을 유지하는 기능이지, 배터리 이상 소모의 충분한 원인은 아닙니다. 특정 앱에서 실제 호환성 문제가 발생한 경우에만 관련 필터나 이름 확인 정책을 조정하세요. Android의 ‘비공개 DNS’를 사용하면 앱의 DNS 경로가 클라이언트 설정과 달라질 수도 있습니다. 변경 전 기존 설정을 기록해 두고 DNS 계층 두 곳을 동시에 바꿔 원인을 파악하기 어려워지는 일을 피하세요.

진단 로그는 필요한 시간만 켜고 실제 트래픽 발생 앱 확인

• 평소에는 클라이언트 기본 로그 수준을 유지하세요. debug를 임시로 켤 때는 문제 상황을 포착할 수 있도록 5~10분만 기록한 뒤 원래 설정으로 되돌리세요.
• 연결 목록이나 실시간 속도 화면을 계속 새로고침하며 화면을 켜 둔 시간을 화면이 꺼진 대기 테스트 결과로 간주하지 마세요.
• 사진 업로드, 클라우드 동기화, 동영상 사전 로딩처럼 연결을 오래 유지하는 작업이 있는지 확인하세요. 프록시 클라이언트는 이런 앱의 실제 트래픽을 전달하고 있을 뿐일 수 있습니다.
• Wi-Fi와 모바일 데이터를 비교하세요. 신호가 약하거나 연결이 자주 끊겼다 다시 잡히면 프록시 설정이 그대로여도 무선 통신 자체의 배터리 소모가 늘 수 있습니다.

고급 기록: ADB로 배터리 및 유휴 상태 확인

디버깅 경험이 있는 사용자는 컴퓨터에서 ADB를 사용해 시스템 기록을 확인할 수 있습니다. 아래 명령을 실행하는 데 root 권한은 필요하지 않지만 USB 디버깅을 켜고 컴퓨터를 승인해야 합니다. 출력 필드와 표시되는 정보는 Android 버전에 따라 다르며, 단일 수치를 클라이언트의 배터리 소모량으로 환산할 수는 없습니다.

adb shell dumpsys battery
adb shell dumpsys batterystats --charged
adb shell dumpsys deviceidle

dumpsys battery로 배터리 잔량, 충전 상태, 온도를 확인할 수 있습니다. batterystats는 시스템에 누적된 배터리 활동을 살펴볼 때 사용하고, deviceidle은 기기 유휴 상태 관리 정보를 확인하는 데 사용할 수 있습니다. 테스트를 위해 일상적으로 사용하는 휴대전화에서 유휴 상태를 강제로 설정하지 마세요. 정상적인 사용 조건이 달라집니다.

USB 연결 중에는 휴대전화가 충전될 수 있으므로 테스트 시작 전후에 기록을 수집하는 편이 좋습니다. 장시간 안정적으로 비교하려면 전원을 분리하고 기록을 시작하세요. 무선 디버깅도 네트워크 활동을 발생시키므로 추가 비용이 전혀 없다고 가정해서는 안 됩니다. 로그를 공유하기 전에는 구독 주소, 노드 인증 정보, 접속 도메인, 앱 패키지명 등 공개하고 싶지 않은 정보를 삭제하세요.

최종 체크리스트: 연결 안정성과 배터리 소모를 따로 확인

1. 기준선 확인: 같은 네트워크와 장소에서 서비스를 켠 상태와 중지한 상태를 최소 한 번씩 비교하세요. 배터리 사용량 순위를 기기 전체 배터리 소모량 대신 사용하지 마세요.
2. 백그라운드 확인: 화면이 꺼진 뒤 연결이 끊기는 경우에만 배터리 제한과 자동 시작 권한 등을 하나씩 허용하고 변경 사항을 기록하세요.
3. 트래픽 확인: 필요에 따라 앱별 라우팅을 사용해 불필요한 백그라운드 작업을 줄이세요. 메시지, 로컬 네트워크, 필요한 앱이 계속 정상 작동하는지 확인하세요.
4. 설정 확인: 상태 확인 간격, 구독 업데이트, 노드 연결 실패 재시도, 설정 업데이트 후 재정의 적용 여부를 점검하세요.
5. 진단 종료 확인: 일반 로그 수준으로 되돌리고 실시간 화면을 닫은 뒤 화면을 끈 상태로 다시 테스트하세요.
6. 문제가 계속되면 제보: 휴대전화 모델, Android 버전, 클라이언트 및 커널 버전, 재현 시간, 네트워크 종류, 민감 정보를 가린 로그를 제공하세요.

특정 업데이트 이후 같은 조건에서 반복 가능한 대기 배터리 차이가 생겼다면, 모든 TUN이나 모든 Clash 계열 클라이언트의 문제라고 단정하지 말고 버전 변경 사항을 제보에 포함하세요. 클라이언트를 선택할 때는 다운로드 페이지에서 플랫폼과 유지 관리 상태를 확인할 수 있습니다. 설정 개념은 사용 설명서를 참고하세요. 목표는 필요한 연결 안정성을 유지하면서 근거로 확인된 불필요한 활동을 줄이는 것입니다.