Clash 상시 실행 시 배터리 소모 이상 점검: Android 백그라운드 정책과 절전 설정 체크리스트

20% 소모, 클라이언트 탓부터 하지 말 것: 원인을 짚는 3가지 신호

휴대폰에 프록시를 켜놓고 밤을 보내면 아침에 배터리가 20~30% 줄어 있는 걸 보고 바로 클라이언트 자체를 의심하기 쉽습니다. 하지만 프록시 소프트웨어의 상시 실행 소모는 크게 세 가지로 나뉩니다: 시스템이 백그라운드 지속 실행을 허용하는지, 네트워크 계층이 CPU를 자주 깨우는지, 규칙 매칭이 불필요한 연산을 잡아먹는지. 어느 지점이 문제인지 판단하려면 먼저 세 가지 신호를 확인하세요.

신호 1: 시스템 설정의 배터리 상세 항목에서 Clash 클라이언트의 "백그라운드 활동 시간"이 밤새 시간에 근접하는지 확인합니다. 근접하다면 시스템에 의해 제한되지 않고 계속 깨어 있는 상태라는 뜻이며, 이는 프록시의 정상적인 동작 방식이지 이상이 아닙니다. 신호 2: 같은 시간대의 "웨이크 락 횟수"나 "앱 대기 이상" 알림을 확인합니다. 횟수가 비정상적으로 많다면 탐지 간격이 너무 짧거나 규칙 매칭이 불안정해서 재연결이 빈번한 경우가 많습니다. 신호 3: 프록시를 켜지 않았을 때의 대기 소모 속도와 비교합니다. 차이가 5% 이내라면 소모의 주범은 다른 백그라운드 앱이며 클라이언트 설정에 계속 매달릴 필요가 없습니다.

시스템 절전 정책이 가장 큰 변수: 백그라운드 화이트리스트 항목별 설정

Android의 Doze 메커니즘 이후 각 제조사의 커스텀 시스템은 더 공격적인 절전 정책을 추가로 얹어놓았고, 이는 프록시 연결이 자주 끊기고 재연결 폭주를 유발하는 가장 흔한 원인입니다. 핵심 로직은 간단합니다: 시스템이 앱이 오래 백그라운드에 있고 화면이 꺼졌다고 판단하면 네트워크 접근과 CPU 웨이크업을 제한하고, 프록시 프로세스가 동결되면 TUN 가상 네트워크 카드의 트래픽 전달이 끊깁니다. 휴대폰이 다시 네트워크에 연결될 때 연결을 재구성해야 하는데, 이 반복되는 재연결 과정이 실제로 배터리를 크게 갉아먹는 부분입니다.

제조사별 시스템 설정 진입 경로와 제한 강도가 모두 다르므로 아래 항목들을 하나씩 확인하세요:

• MIUI(Xiaomi): 설정 → 앱 설정 → 앱 관리 → Clash 클라이언트 찾기 → 절전 정책을 "제한 없음"으로 선택하고, "자동 시작 관리"에서 해당 제한 항목도 해제합니다.
• ColorOS / realme UI(OPPO/realme): 배터리 → 앱 배터리 관리 → 클라이언트 찾기 → 백그라운드 실행 허용 + 고소모 허용, "기타 설정"에서 "절전 최적화"의 해당 앱 제한을 해제합니다.
• OriginOS / Funtouch OS(vivo/iQOO): i매니저 → 앱 관리 → 권한 관리 → 백그라운드 고소모, 클라이언트를 화이트리스트에 추가; 시스템 기본 "스마트 절전"의 해당 앱 제한도 해제합니다.
• EMUI / HarmonyOS(Huawei): 배터리 → 배터리 추가 설정 → 앱 실행 관리, 클라이언트를 "수동 관리"로 바꾸고 자동 시작, 연관 시작, 백그라운드 활동을 체크합니다.
• One UI(Samsung): 설정 → 배터리 → 백그라운드 사용 제한, 클라이언트를 "절전 앱" 또는 "深いスリープ 앱" 목록에서 제외합니다.
• 순정 Android / Pixel: 설정 → 앱 → 클라이언트 찾기 → 배터리 → "배터리 사용량"을 "제한 없음"으로 변경합니다.

이 단계가 프록시가 백그라운드에서 안정적으로 살아있을 수 있는지를 거의 결정합니다. 시스템 화이트리스트를 설정하지 않으면 이후 클라이언트 내부의 절전 튜닝은 근본적인 해결이 되지 못합니다.

TUN 모드 상시 실행과 절전의 트레이드오프

TUN 모드는 가상 네트워크 카드로 전체 트래픽을 인터셉트하며 개별 앱의 프록시 설정에 의존하지 않아 호환성이 가장 뛰어나지만, 그 대가로 네트워크 인터페이스 변화를 지속적으로 감지하는 상시 백그라운드 서비스가 필요합니다. 이 서비스 자체의 소모는 매우 낮으며, 실제로 배터리를 갉아먹는 건 부적절한 절전 정책과의 충돌입니다: 시스템이 백그라운드 프로세스 웨이크업을 제한하는 동시에 TUN 서비스는 네트워크 전환(예: Wi-Fi에서 모바일 데이터로)에 즉시 대응해야 하는데, 이 둘이 충돌하면 서비스가 종료된 뒤 자동으로 재시작되고, 재시작 과정에서 라우팅 테이블 재구성과 DNS 재해석이 통째로 일어나며 이것이 소모 스파이크의 원인입니다.

전체 투명 프록시가 필요 없다면(예: 특정 앱만 분산 처리) TUN 모드를 끄고 시스템 VPN 인터페이스나 앱 단위 프록시 설정으로 전환해 상시 네트워크 서비스를 하나 줄이는 방법을 고려할 수 있습니다. 하지만 TUN으로 전체 트래픽을 분산하거나 UDP/ICMP 트래픽을 가로챌 필요가 있다면 TUN 모드를 유지하면서 앞 절의 시스템 화이트리스트를 제대로 설정하는 것이 TUN을 끄는 것보다 낫습니다.

측정 간격과 동시 탐지: 놓치기 쉬운 소모 원인

정책 그룹 설정의 url-test 타입은 정해진 간격으로 노드에 지연 탐지를 보내며, 이 간격은 interval 필드로 제어되고 단위는 초입니다. 많은 구독이 기본값을 짧게 잡아두는데(60초나 그보다 더 짧게), 이는 클라이언트가 매분마다 네트워크 모듈을 깨워 각 노드에 HTTP 요청을 보낸다는 뜻입니다. 야간 대기 상태라면 휴대폰이 딥 슬립에 들어가야 하는데 이런 정기 탐지에 의해 계속 깨어나며, 이게 쌓이면 상당한 전력 소모로 이어집니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies: [노드1, 노드2, 노드3]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval을 300~600초로 늘리면 대부분의 사용 환경에서 눈에 띄는 영향 없이 야간 웨이크업 횟수를 크게 줄일 수 있습니다. 정책 그룹 안에 노드가 많으면 탐지가 동시에 실행되므로 노드가 많을수록 한 번의 웨이크업에 걸리는 시간과 소모도 늘어납니다. 구독의 수십 개 노드를 전부 같은 자동 측정 그룹에 넣을 필요 없이 자주 쓰는 5~10개로 정리하면 충분합니다.

규칙 복잡도가 CPU를 잡아먹는 이유와 정리 방법

규칙 섹션의 매칭은 위에서 아래로 순서대로 비교되며, 규칙 항목이 많고 뒤쪽에서 매칭될수록 연결 하나를 맺는 데 소모되는 CPU 사이클이 길어집니다. 수천 줄짜리 커뮤니티 규칙 세트를 규칙 목록 맨 앞에 두고 대부분의 도메인을 분류 규칙 세트(RULE-SET)가 아닌 문자열 정확 매칭으로 처리하면, 새 연결이 생길 때마다 긴 비교 로직을 매번 돌게 됩니다. 백그라운드 앱 생존 유지나 푸시 하트비트처럼 연결이 장기간 빈번하게 발생하면 CPU 사용률 곡선에 작은 스파이크가 자주 나타나고, 이 스파이크들이 누적되면서 배터리 소모의 일부가 됩니다.

정리 방향은 간단합니다: 매칭률이 높은 규칙(예: 다이렉트 연결하는 중국 본토 도메인, 자주 쓰는 분산 도메인)을 규칙 목록 앞쪽에 두어 평균 비교 횟수를 줄입니다. 개별 도메인 규칙을 일일이 쌓기보다 잘 정리된 분류 규칙 세트를 참조하는 RULE-SET을 최대한 활용합니다. 명백히 중복되거나 상위 규칙에 이미 커버되는 항목은 삭제합니다. 규칙 세트 자체는 로딩과 인덱싱 방식이 최적화되어 있어 개별 명시 규칙보다 효율이 높고, 규칙 수가 한 자릿수 줄어들면 매칭 오버헤드도 함께 줄어듭니다.

바로 실행 가능한 절전 설정 체크리스트

아래 순서대로 하나씩 확인하면 클라이언트 자체가 원인이 아닌 소모 이상은 대부분 걸러낼 수 있습니다:

1. 시스템 배터리 설정을 열어 Clash 클라이언트를 백그라운드 실행 화이트리스트에 추가하고, 제조사가 붙여놓은 "스마트 절전", "절전 최적화" 제한을 모두 해제합니다.
2. 자동 시작 권한, 연관 시작 권한이 꺼져 있지 않은지 확인합니다. 백그라운드에서 동결된 프로세스는 화이트리스트에 등록되어도 스스로 깨어나지 못할 수 있습니다.
3. 정말로 TUN 모드가 필요한지 확인합니다. 전체 분산이 필요 없다면 앱 단위 프록시로 바꾸면 상시 서비스를 하나 줄일 수 있습니다.
4. 설정 파일을 열어 url-test 정책 그룹의 interval을 300초 이상으로 조정해 정기 웨이크업 빈도를 줄입니다.
5. 자동 측정 그룹의 노드 수를 정리해 자주 쓰는 몇 개만 남기고 한 번의 탐지에 드는 동시 부하를 줄입니다.
6. 규칙 섹션의 항목 수를 확인하고, RULE-SET으로 규칙 세트를 참조하는 방식을 우선 사용하며 매칭률 높은 규칙을 목록 앞쪽으로 옮깁니다.
7. 프록시를 켜기 전후의 대기 소모 속도를 비교합니다. 차이가 여전히 10% 이상이라면 앞의 단계들이 제대로 적용됐는지 다시 하나씩 확인합니다.