Clash 안드로이드 배터리 소모 해결법: 백그라운드 실행 전략과 절전 체크리스트

먼저 소모 원인 파악하기: 시스템 배터리 통계 활용법

설정을 건드리기 전에, 배터리 소모가 정말 Clash 때문인지 먼저 확인해야 합니다. 구독 노드 연결 품질이 나빠서 반복적으로 재연결이 일어나거나, 다른 앱이 백그라운드 리소스를 점유하고 있을 수도 있습니다. 안드로이드 기본 배터리 통계로 대략적인 방향을 잡을 수 있습니다. 「설정 → 배터리 → 앱별 배터리 사용량」에서 해당 Clash 클라이언트(Clash Meta for Android, FlClash, Clash Verge 등 안드로이드 계열 앱은 이름이 다르므로 실제 설치된 앱 이름으로 찾으세요)를 찾아 「백그라운드 실행 시간」과 「깨움(wake) 횟수」 두 지표를 확인합니다.

깨움 횟수가 정상 범위를 크게 벗어난다면(경험적으로 헬스체크를 켠 상태에서 시간당 수십 회는 정상, 수백 회를 넘으면 의심할 필요가 있습니다) 헬스체크 간격이 너무 짧거나, 노드 풀에 무효 노드가 많아 반복적으로 탐지되고 있을 가능성이 큽니다. 백그라운드 실행 시간 자체는 긴데 깨움 횟수는 많지 않다면, 특정 이상 작업보다는 TUN 모드가 네트워크 계층을 계속 점유하면서 발생하는 지속적인 전력 소모일 확률이 높습니다.

헬스체크 간격과 탐지 빈도: Clash가 계속 "전화 거는" 상태를 막기

Clash와 Clash Meta(mihomo 커널) 그룹 설정에서 url-test, fallback 타입 프록시 그룹에는 interval 필드가 있습니다. 단위는 초이며, 그룹 내 노드에 얼마나 자주 지연 시간 탐지를 보낼지 결정합니다. 값이 작을수록 저지연 노드로 더 민감하게 전환되지만, 그 대가로 네트워크 모듈이 더 자주 깨어나 요청을 보내고 응답을 기다려야 합니다. 모바일 네트워크에서는 탐지 한 번마다 베이스밴드가 깨어날 수 있고, 이게 누적되면 눈에 띄는 배터리 소모로 이어집니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 노드A
      - 노드B

데스크톱용 구독에 기본으로 설정된 interval은 보통 60~120초인데, 이 빈도는 전원에 연결된 데스크톱에서는 문제가 없지만 모바일에 그대로 적용하면 지나치게 공격적입니다. 모바일에서는 300초 이상으로 늘리고, tolerance(허용 오차, 단위 밀리초)를 50~100 정도로 설정해 지연 시간이 살짝 흔들릴 때마다 불필요한 전환 판단이 일어나지 않도록 하는 것을 권장합니다. 구독이 원격으로 관리되어 이 필드를 직접 수정할 수 없다면, 클라이언트의 「오버라이드」 또는 「로컬 오버라이드 규칙」 기능으로 interval만 덮어쓰고 나머지 분기 규칙은 그대로 두는 방법도 있습니다.

• 장시간 백그라운드로 두고 전환 민감도가 크게 중요하지 않다면: interval을 300~600초로 설정하세요.
• 전면에서 자주 사용하고 지연에 민감한 경우(게임 부스트 등): 60~120초를 유지하되 그만큼의 배터리 소모는 감수해야 합니다.
• 노드 풀에 무효 노드가 계속 남아 있는 경우: 간격을 늘려서 덮으려 하지 말고, 먼저 구독이나 필터 규칙을 정리하세요.

TUN 모드 상시 실행의 대가와 대안

TUN 모드는 시스템 네트워크 계층에 가상 네트워크 인터페이스를 만들어 기기의 모든 트래픽을 예외 없이 처리하며, 개별 앱이 시스템 프록시 설정을 따르는지 여부에 의존하지 않습니다. 이 방식은 넓은 커버리지와 더 완전한 DNS 처리를 제공하지만, 대가로 가상 네트워크 인터페이스가 계속 활성 상태를 유지해야 합니다. 이는 안드로이드의 절전 전략과 근본적으로 충돌합니다. 시스템이 네트워크 모듈을 재우려 할수록 TUN은 패킷을 처리하기 위해 계속 깨어 있어야 하고, 이 줄다리기의 결과는 대개 배터리 소모가 크면서도 불안정한 상태입니다.

일상적으로 프록시를 거쳐야 하는 게 브라우저와 몇몇 앱뿐이라면, TUN 모드를 하루 종일 켜둘 필요는 없습니다. 시스템 프록시 모드로 돌아가고, 정말로 전면적인 처리가 필요할 때(특정 앱이 시스템 프록시 설정을 우회하거나 UDP/DNS 계층 처리가 필요한 경우)만 TUN을 임시로 켜는 방식을 추천합니다. 두 모드의 핵심 차이는 "앱이 자발적으로 따르는가"와 "네트워크 계층에서 강제로 가로채는가"인데, 자세한 동작 원리 차이는 이 사이트의 TUN과 시스템 프록시의 차이를 심층 분석한 다른 글에서 더 완전한 비교를 볼 수 있습니다.

로그 레벨과 GUI 새로고침: 놓치기 쉬운 숨은 배터리 소모 지점

로그 레벨 설정에서 debug 레벨은 모든 연결 생성 과정과 규칙 매칭 과정을 기록하는데, 기록 빈도가 매우 높습니다. 특히 규칙 수가 많고 동시 연결 수가 많은 상황에서는 지속적인 디스크 쓰기와 문자열 처리 자체가 CPU 자원을 소모합니다. 일상적으로는 로그 레벨을 info나 더 낮은 warning으로 돌려두고, 문제를 진단할 때만 임시로 debug로 전환한 뒤 확인이 끝나면 반드시 원래대로 되돌리는 것을 권장합니다.

log-level: info
# 문제 진단 시 임시로 debug로 변경, 확인 후 반드시 원상 복구

또 하나 놓치기 쉬운 부분은 클라이언트 화면의 실시간 새로고침입니다. 일부 안드로이드 클라이언트는 메인 화면에 실시간 트래픽 그래프와 연결 목록 스크롤 새로고침이 들어 있는데, 클라이언트가 렌더링 리소스를 제대로 해제하지 않으면 백그라운드로 넘어가도 화면 합성 관련 프로세스가 계속 CPU를 점유하며 깨어 있게 됩니다. 클라이언트 설정에 「백그라운드에서 화면 새로고침 일시 정지」나 「절전 모드」 같은 스위치가 있는지 확인하고 켜두세요. 또한 알림바가 1초 단위로 트래픽 수치를 갱신하도록 설정돼 있는지도 확인하세요. 이런 고빈도 알림 갱신이 배터리에 미치는 영향은 생각보다 큽니다. 알림 설정에서 갱신 주기를 몇 초 단위로 늘리거나, 실시간 수치 대신 연결 상태만 표시하도록 바꾸는 것도 방법입니다.

제조사 백그라운드 제한 설정: 잘못 맞추면 오히려 더 소모됩니다

중국 본토 주요 안드로이드 제조사(샤오미, 화웨이, OPPO, vivo 등)는 시스템 차원에서 각자의 백그라운드 관리 정책을 추가로 얹어놓았습니다. 이를 제대로 허용해두지 않으면 백그라운드 제한 메커니즘이 프로세스를 자주 "동결-깨움"시키게 되는데, 매번 깨어나서 노드에 재연결하고 TUN 인터페이스를 다시 세우는 비용이 그냥 백그라운드에서 정상적으로 유지되는 것보다 오히려 더 많은 전력을 소모합니다. 설정 방향은 대체로 비슷하지만 구체적인 진입 경로 이름은 조금씩 다릅니다:

• 샤오미(MIUI/澎湃 OS): 설정 → 앱 설정 → 앱 관리 → 클라이언트 선택 → 절전 정책을 「제한 없음」으로 설정하고, 「자동 실행 관리」의 추가 차단 항목도 함께 해제하세요.
• 화웨이(EMUI/HarmonyOS): 설정 → 배터리 → 앱 실행 관리 → 해당 앱의 「자동 관리」를 끄고, 자동 실행·연계 실행·백그라운드 활동 세 가지를 수동으로 켜세요.
• OPPO(ColorOS): 설정 → 배터리 → 앱 배터리 사용 관리 → 클라이언트를 찾아 「백그라운드 활동 허용」으로 설정하고, 「절전 모드 화이트리스트」에도 추가하세요.
• vivo(OriginOS/Funtouch OS): i매니저 → 앱 관리 → 권한 관리 → 백그라운드 고소모 → 클라이언트를 허용으로 설정하세요.

한 가지 짚어둘 점은, 이 설정들은 본질적으로 "백그라운드 정상 유지 허용"이지 "무제한 배터리 소모 허용"이 아니라는 겁니다. 클라이언트를 화이트리스트에 등록한 뒤에도 앞서 다룬 헬스체크 간격, TUN 사용 범위, 로그 레벨 조정은 여전히 해줘야 합니다. 그렇지 않으면 원래부터 배터리를 많이 쓰는 설정을 그대로 허용해준 셈이 되어 배터리 수명이 더 나빠질 뿐입니다. 두 가지는 세트로 묶여 있는 것이지, 하나만 해서는 안 됩니다.

배터리 수명과 안정적인 유지를 동시에 잡는 설정 체크리스트

앞선 내용을 바로 대조해서 실행할 수 있는 체크리스트로 정리하면, 우선순위 높은 순서는 다음과 같습니다:

1. 구독 노드 풀 상태를 먼저 확인하고, 장기간 무효한 노드를 정리해 헬스체크가 무효 노드에 탐지 횟수를 낭비하지 않도록 합니다.
2. url-test / fallback 그룹의 interval을 300초 이상으로 늘리고, tolerance는 50~100밀리초로 유지합니다.
3. 필요한 경우가 아니면 TUN 모드를 상시 켜두지 말고, 전면적인 처리나 특수 DNS 처리가 필요할 때만 임시로 켭니다.
4. 로그 레벨은 일상적으로 info 이하로 유지하고, 문제 진단 시에만 임시로 debug로 바꾼 뒤 즉시 원래대로 되돌립니다.
5. 클라이언트의 실시간 새로고침 알림을 끄거나 갱신 주기를 낮추고, 「백그라운드에서 화면 새로고침 일시 정지」 스위치가 있는지 확인해 켭니다.
6. 제조사별 백그라운드 제한 해제를 완료합니다. 자동 실행, 연계 실행, 백그라운드 활동, 절전 화이트리스트 네 가지를 한 번에 모두 처리해서 하나라도 빠뜨려 프로세스가 계속 동결되는 일이 없도록 합니다.

---

헬스체크 간격과 TUN 사용 범위를 조정했는데도 노드에서 계속 대량 타임아웃이나 연결 이상이 발생한다면, 이제 배터리 문제가 아니라 노드나 구독 자체에 문제가 있을 가능성이 큽니다. 이 경우 구독 유효성, 로컬 시간 오차, 포트 점유 같은 더 근본적인 원인을 순서대로 점검해보세요.