Clash 안드로이드 배터리 소모 분석: 백그라운드 유지, TUN 모드와 제조사 절전 정책의 절충
모바일에서 프록시를 사용할 때 배터리 소모가 큰 원인은 대부분 백그라운드 웨이크업과 TUN 모드에 있습니다. 이 글은 주요 배터리 소모 원인을 분석하고, 백그라운드 실행 전략, 규칙 정리, 제조사별 절전 화이트리스트 설정 방법을 구체적으로 제시합니다.
배터리 소모 이상 먼저 분류하기: 진짜 소모인가, 체감 차이인가
안드로이드에서 프록시를 사용한 뒤 "폰이 더 뜨겁고 배터리가 더 빨리 닳는다"고 느낄 때, 반드시 프록시 소프트웨어만의 문제는 아닙니다. 먼저 기본적인 구분을 해서 잘못된 방향으로 문제를 찾지 않도록 해야 합니다. 시스템 설정의 배터리 사용량 통계를 열어, Clash 계열 앱의 소모 비율이 다른 상시 실행 앱(메신저, 메일 클라이언트 등)보다 눈에 띄게 높은지 확인합니다. 비율이 한 자릿수 퍼센트라면 대부분 정상적인 프록시 포워딩 오버헤드이고, 지속적으로 소모 순위 상위 3위 안에 들면서 화면이 꺼진 후에도 비율이 여전히 높다면 그때야 이상으로 판단해야 합니다.
또한 "배터리 소모"와 "발열"을 구분해야 합니다. 발열은 대부분 단시간 고부하로 인한 것으로, 구독을 막 가져왔거나 여러 노드의 지연 시간을 일괄 테스트하는 몇 분 사이에 발생합니다. 반면 배터리 소모는 긴 시간에 걸친 누적 소비로, 주로 백그라운드 상주 기간의 동작을 봐야 합니다. 이 글은 백그라운드 상시 실행 상태에서의 배터리 소모 문제에 초점을 맞추며, 짧은 시간의 고부하 발열은 다루지 않습니다.
세 가지 주요 배터리 소모 원인: 웨이크업, TUN, 규칙 매칭
백그라운드 웨이크업 빈도
Clash 계열 클라이언트는 프록시 서비스와 이미 맺어진 연결을 유지해야 하므로, 시스템 차원에서 생존을 유지해야 하는 프로세스로 표시됩니다. 클라이언트 자체나 시스템 스케줄러가 하트비트 확인, 연결 유지, 구독 만료 확인을 위해 CPU를 자주 깨운다면, 실제로 흐르는 트래픽이 없더라도 상당한 배터리 소모가 누적됩니다. 이 항목은 "밤에 폰을 켜 두고 사용하지 않는" 상황에서 가장 두드러집니다. 하룻밤 동안 방치했을 때 프록시를 설치하지 않았을 때보다 배터리가 눈에 띄게 더 빨리 줄어든다면, 웨이크업 빈도 문제로 거의 특정할 수 있습니다.
TUN 모드의 시스템 계층 인수
TUN 모드는 시스템 네트워크 계층에 가상 네트워크 카드를 만들어, 기기의 모든 앱 트래픽을 먼저 Clash 코어로 끌어와 처리한 다음 규칙에 따라 분산 전달합니다. 이 전역 인수 방식은 커버리지가 넓고 호환성이 좋아 프록시를 우회하는 앱이 거의 없지만, 대가로 모든 패킷마다 캡슐화, 디캡슐화, 규칙 매칭이라는 추가 계층이 생깁니다. 안드로이드에서는 TUN 모드가 시스템 VPN 서비스 프레임워크와도 상호작용해야 하며, 이 상호작용 자체에도 고정적인 리소스 소비가 있습니다. 모바일 기기의 CPU 성능과 발열 여유 공간은 데스크톱보다 훨씬 부족하므로, 이 오버헤드가 확대되어 배터리 소모와 발열로 나타납니다.
규칙 세트 크기와 매칭 복잡도
규칙 기반 분산은 각 연결의 목적지 도메인이나 IP를 규칙 목록과 하나씩 대조해야 하며, 규칙 세트가 크고 계층이 복잡할수록 한 번의 매칭에 걸리는 시간이 길어집니다. 일부 구독에 딸린 규칙 세트는 수천 개의 규칙과 여러 원격 규칙 세트(rule-providers)를 포함하며, 클라이언트는 백그라운드에서 설정된 주기마다 이 규칙 세트를 가져와 업데이트해야 합니다. 가져오기와 파싱 과정 자체도 CPU와 네트워크를 소모합니다. 크기가 큰 규칙 세트를 여러 개 동시에 마운트하면 백그라운드 유지 비용이 눈에 띄게 늘어납니다.
먼저 TUN 모드가 켜져 있는지 확인하고, 다음으로 규칙 세트 수와 업데이트 빈도를 보고, 마지막으로 시스템 절전 정책이 유지 메커니즘을 실수로 죽이고 있는지 확인하세요. 세 가지가 겹쳐 있을 때는 이 순서대로 변수를 하나씩 끄면서 어느 항목이 배터리 소모에 가장 큰 영향을 미치는지 개별적으로 테스트하는 것을 권장합니다.
백그라운드 실행 전략의 절충
안드로이드의 백그라운드 관리 메커니즘 자체는 "앱 생존 보장"과 "백그라운드 소모 제한" 사이에서 균형을 잡으려 하는데, 프록시 앱은 마침 이 둘의 모순점에 걸려 있습니다. 프록시는 연결을 지속적으로 유지하기 위해 백그라운드에서 장시간 동작해야 하지만, 시스템의 절전 정책은 백그라운드 프로세스를 제한하려는 경향이 있습니다. 여기에는 절대적으로 옳은 설정이 없고, 상황에 따른 절충만 있습니다.
- 일상적인 가벼운 사용: 웹 페이지를 보거나 뉴스를 확인하는 정도라면 프록시가 연중 백그라운드에서 연결을 유지할 필요가 없으므로, 사용하지 않을 때 프록시 서비스를 수동으로 끊어 백그라운드 웨이크업 횟수를 줄이는 것이 가장 직접적인 절전 방법입니다.
- 연결을 계속 유지해야 하는 상황(메시지 푸시를 받거나 장시간 방치하는 상황 등): 클라이언트를 시스템 백그라운드 화이트리스트에 추가해 절전 제한을 우회하도록 허용해야 하지만, 그에 따른 배터리 소모를 받아들여야 합니다. 이는 버그가 아니라 명확한 트레이드오프입니다.
- 특정 앱에서만 프록시 사용: 클라이언트가 앱별 규칙이나 패키지명 기준 분산을 지원한다면, 실제로 프록시가 필요한 앱만 TUN 통로로 보내고 나머지는 직접 연결하도록 하면 전체 규칙 매칭과 전달 부담을 크게 줄일 수 있습니다.
자신의 실제 사용 빈도에 맞춰 설정을 선택하는 것이 좋으며, 상황을 고려하지 않고 일괄적으로 가장 적극적이거나 가장 보수적인 설정을 적용하지 않는 것이 좋습니다.
규칙 정리: 백그라운드 상시 부담 줄이기
많은 구독에 딸린 규칙 세트는 "크고 방대한" 형태로 설계되어 다양한 소수 시나리오까지 포괄합니다. 대다수 사용자에게는 규칙 세트를 정리하는 것이 백그라운드 매칭과 업데이트 오버헤드를 직접 낮추는 방법입니다. 실행 가능한 방향은 다음과 같습니다:
- 클라이언트에 로드된 rule-providers 수를 확인하고, 오랫동안 쓰지 않는 분류 규칙 세트(예: 거의 방문하지 않는 특정 지역 서비스 규칙)를 병합하거나 삭제합니다.
- 규칙 세트의 업데이트 간격(interval)을 적절히 늘립니다. 매일 업데이트를 가져올 필요는 없으며, 대부분 규칙 세트의 실제 변경 빈도는 그리 높지 않으므로 3~7일 간격이면 보통 충분합니다.
- 동시에 마운트된 정책 그룹 수를 줄입니다. 정책 그룹 내 자동 속도 테스트(url-test)는 자체적으로 주기적인 탐지 요청을 보내므로, 정책 그룹이 많을수록 백그라운드 예약 작업도 많아집니다.
- 여러 구독 소스에서 교차로 도입된 중복 규칙 세트가 없는지 확인합니다. 중복 규칙은 매칭 속도를 늦출 뿐 실제 효과를 더하지는 않습니다.
rule-providers:
reject:
type: http
interval: 259200 # 기본값보다 더 자주가 아니라 3일에 한 번 업데이트
behavior: domain규칙 세트를 조정한 뒤에는 하루 이틀 정도 배터리 사용량을 비교 관찰한 뒤 계속 정리할지 판단하는 것이 좋습니다. 한꺼번에 너무 많이 삭제해 프록시를 타야 할 트래픽이 빠지는 일이 없도록 주의하세요.
제조사별 절전 정책에 따른 화이트리스트 설정
주요 안드로이드 제조사의 시스템은 순정 안드로이드 위에 각자의 절전 및 프로세스 관리 정책을 더해두었으며, 이 정책들은 사용자가 인지하지 못하는 사이에 프록시 서비스 프로세스를 종료시켜 프록시가 "이유 없이 끊기거나" 연결을 유지하려 반복적으로 재시작되면서 오히려 더 많은 전력을 소모하게 만드는 경우가 흔합니다. 아래 표는 흔한 설정 진입점이며, 실제 메뉴 문구는 시스템 버전에 따라 다소 다를 수 있습니다:
| 제조사 시스템 | 주요 설정 항목 | 권장 조치 |
|---|---|---|
| MIUI / HyperOS | 절전 정책 · 자동 실행 관리 · 백그라운드 잠금 | "무제한"으로 설정, 자동 실행 허용, 작업 목록에서 길게 눌러 잠금 |
| EMUI / HarmonyOS | 배터리 · 앱 시작 관리 | "자동 관리" 끄기, 자동 시작·연관 시작·백그라운드 실행 수동 허용 |
| ColorOS / OxygenOS | 배터리 · 앱 전력 사용 관리 | "백그라운드 활동 허용"으로 설정, 딥 슬립 제한 끄기 |
| Funtouch OS / OriginOS | 배터리 · 백그라운드 고소모 | 허용 목록에 추가, 해당 앱에 대한 "스마트 절전" 제한 끄기 |
| One UI (삼성) | 배터리 · 백그라운드 사용 제한 | "절전 중인 앱" 목록에서 제외, "감시 안 함"으로 설정 |
클라이언트를 화이트리스트에 추가하면 백그라운드 강제 종료와 연결 끊김 확률이 눈에 띄게 줄어들지만, 이는 일부 배터리를 소모해 안정성을 얻는 것이며 앞 절의 절전 정책과 상호 제약 관계에 있음을 알아야 합니다. 합리적인 방법은: 실제로 장시간 방치가 필요하면 화이트리스트에 추가하고, 간헐적으로만 사용한다면 시스템 기본 절전 제한을 유지한 채 사용할 때만 수동으로 켜는 것입니다.
일부 제조사 시스템의 "슈퍼 절전 모드"나 "극한 절전"은 화이트리스트에 없는 모든 앱의 네트워크 접속을 강제로 끊습니다. 이런 모드에서는 프록시 클라이언트가 화이트리스트에 있어도 시스템 전체 네트워크 정책 제한 때문에 정상적으로 인터넷에 연결되지 않을 수 있으므로, 이런 상황을 만나면 먼저 기기가 현재 슈퍼 절전 모드가 아닌지 확인해야 합니다.
TUN 모드를 쓰지 말아야 할 상황
TUN 모드가 유일한 선택은 아닙니다. 기기 발열과 배터리 소모가 이미 일상 사용에 눈에 띄게 영향을 준다면, 시스템 프록시 모드(프록시가 필요한 앱이나 브라우저에서 개별적으로 프록시 주소를 설정)로 전환해 커버리지 일부를 희생하고 시스템 계층 오버헤드를 낮추는 방법을 검토할 수 있습니다. 시스템 프록시 모드에서는 프록시를 직접 설정한 앱만 전달을 거치고, 나머지 앱은 전혀 영향을 받지 않아 매칭과 전달의 총량이 훨씬 줄어듭니다.
이 절충은 다음 상황에 적합합니다: 브라우저나 몇몇 앱에서만 프록시가 필요한 경우, 기기 성능이 낮아 발열에 민감한 경우, 또는 전역 커버리지를 추구하지 않는 일시적인 사용인 경우. 반대로 기기의 모든 앱을 커버해야 한다면(예: 일부 앱에 하드코딩된 도메인 검사가 있어 전역 프록시를 우회하면 기능 오류가 생기는 경우), TUN 모드가 여전히 더 안전한 선택입니다. 이때 배터리 소모는 반드시 감당해야 할 비용이며, 앞서 언급한 규칙 정리와 화이트리스트 설정에 집중해야 하고 TUN을 쓸지 말지 고민할 필요는 없습니다.
완전한 점검 절차 권장안
- 시스템 배터리 사용량 통계를 열어 소모 비율이 정말 이상한지 확인합니다(본문 첫 절의 판단 기준 참고).
- TUN 모드가 켜져 있는지 확인하고, 하루 동안 시스템 프록시 모드로 임시 전환해 배터리 소모 차이를 비교합니다.
- 현재 로드된 규칙 세트 수와 업데이트 간격을 점검하고, 오래 쓰지 않는 분류를 정리하고 업데이트 주기를 늘립니다.
- 정책 그룹 내 자동 속도 테스트의 탐지 빈도를 확인하고, 불필요한 예약 탐지 작업을 줄입니다.
- 제조사 절전 정책 설정이 합리적인지 확인합니다: 장시간 방치가 필요하면 화이트리스트에 추가하고, 간헐적으로 사용한다면 시스템 기본 제한을 유지합니다.
- 조정 후 하루 이틀의 배터리 곡선을 관찰해 소모가 합리적인 범위로 돌아왔는지 확인한 뒤, 추가 조정이 필요한지 판단합니다.
이 순서대로 하나씩 점검하면 배터리 소모 이상을 구체적인 단계에서 특정할 수 있으며, "프록시 소프트웨어가 배터리를 많이 먹는다"고 뭉뚱그려 결론짓지 않게 됩니다. 대부분의 경우 배터리 소모 문제의 근본 원인은 규칙 세트가 너무 크거나 백그라운드 웨이크업이 너무 잦은 데 있으며, 이 두 가지를 조정하는 것이 TUN 모드 사용 여부를 고민하는 것보다 훨씬 효과적입니다.