모바일에서 Clash 배터리 소모가 심할 때 점검법: 백그라운드 실행 정책과 절전 설정 조정

배터리 소모 진단의 기본 방향: 먼저 분류하고, 다음에 좁혀간다

모바일에서 "배터리 소모가 심하다"는 피드백은 단일 원인인 경우가 드물고, 대개 설정 계층과 시스템 계층 두 가지 문제가 겹쳐서 발생합니다. 설정 계층이란 Clash 또는 mihomo 커널 자체의 실행 파라미터를 의미합니다. 예를 들어 규칙 세트 갱신 빈도, 로그 출력 레벨, DNS 조회 방식 등입니다. 시스템 계층이란 안드로이드나 iOS가 백그라운드 프로세스에 적용하는 절전 제한, 그리고 앱이 시스템에 의해 "비활성"으로 판단된 후 트리거되는 다운클럭·슬립 정책을 의미합니다. 진단할 때는 아래 순서로 범위를 단계적으로 좁혀가는 것을 권장합니다.

1. 먼저 화면 잠금/백그라운드 상태에서만 배터리 소모가 비정상적으로 늘어나는지, 아니면 포그라운드 사용 시에도 높은지 확인합니다. 전자는 대부분 시스템 스케줄링 문제이고, 후자는 대부분 설정이나 프록시 경로 문제입니다.
2. 커널 로그 출력량을 확인해 재연결 반복, DNS 타임아웃 재시도, 규칙 매칭 실패로 인한 순환 요청이 있는지 판단합니다.
3. 구독과 규칙 세트의 자동 업데이트 주기를 확인해 폴링 간격이 지나치게 짧게 설정되어 있지 않은지 점검합니다.
4. 시스템 배터리 관리에서 클라이언트가 "제한됨"으로 표시되어 자주 깨워져 재연결되고 있지는 않은지 확인합니다.

아래 각 절에서는 이 네 가지 층위를 하나씩 다루며, 구체적인 확인 방법과 조정 파라미터를 제시합니다.

규칙 세트와 구독 폴링: 잘못된 갱신 주기 설정이 흔한 원인

mihomo 커널은 설정 파일에서 rule-providers 항목마다 독립적인 interval 필드를 설정할 수 있으며, 단위는 초로 해당 규칙 세트의 자동 가져오기 주기를 제어합니다. 일부 클라이언트 GUI는 설정 파일에 고정으로 적힌 간격을 그대로 따르는데, 구독 제작자가 간격을 몇 분 단위로 설정했다면 화면이 잠긴 상태에서도 주기적으로 네트워크 모듈이 깨어나 HTTP 요청을 보내게 됩니다. 이는 모바일 배터리 소모 진단에서 가장 쉽게 놓치는 항목입니다.

rule-providers:
  reject-list:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.yaml"
    path: ./rules/reject.yaml
    interval: 86400

변동이 잦지 않은 규칙 세트(광고 차단, 직접 연결 목록 등)는 interval을 43200초(12시간) 이상으로 조정하고, 분기 규칙이 자주 바뀌는 상황에서만 짧은 주기를 유지하는 것을 권장합니다. 마찬가지로 구독 자체의 자동 업데이트(프로필 단계의 update-interval 또는 클라이언트 GUI의 "구독 자동 업데이트" 옵션)도 1시간 이내로 설정하지 않는 것이 좋습니다. 그렇지 않으면 모바일 기기가 백그라운드에서 반복적으로 깨어나 전체 다운로드, 파싱, 설정 리로드 과정을 실행하게 되는데, 이 과정 자체가 디스크 쓰기와 커널 재시작을 수반해 1회당 소모되는 배터리 비용이 결코 낮지 않습니다.

로그 레벨과 DNS 동시 조회: 설정 파일에서 놓치기 쉬운 배터리 소모 스위치

로그 레벨을 debug나 info로 설정하면 커널은 연결 생성, 규칙 매칭, DNS 해석마다 로그 항목을 기록하며, 지속적인 디스크 I/O와 문자열 포맷팅 작업이 추가 CPU 점유를 유발합니다. 일상적인 모바일 사용에서는 로그 레벨을 warning으로 조정하고, 연결 문제를 직접 진단할 때만 임시로 debug로 전환한 뒤 진단이 끝나면 즉시 되돌리는 것을 권장합니다.

log-level: warning

DNS 부분도 반드시 점검해야 합니다. enhanced-mode: fake-ip를 활성화하고 여러 nameserver로 동시 조회하는 방식은 흔한 설정이지만, 지나치게 많은 상위 DNS(특히 해외 서버)를 동시에 설정하고 합리적인 fallback-filter를 지정하지 않으면 도메인 하나를 해석할 때마다 여러 요청을 동시에 보내고 타임아웃 판정으로 최적 결과를 기다리게 됩니다. 모바일 네트워크 신호가 불안정한 환경에서는 이로 인해 무선 모듈 활성 시간이 뚜렷하게 늘어납니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - "tls://8.8.8.8:853"
  fallback-filter:
    geoip: true
    geoip-code: KR

nameserver 목록을 응답이 안정적인 두세 개 서버로 줄이고, fallback은 명확히 해외 도메인으로 판정된 경우에만 작동하도록 하면 불필요한 동시 해석 요청을 줄일 수 있습니다.

안드로이드: 배터리 최적화 예외 목록과 백그라운드 자동 실행 권한

안드로이드 6.0부터 도입된 Doze 모드와 각 제조사의 커스텀 시스템(딥 커스터마이징 기반 절전 관리 프레임워크 등)은 오랫동안 백그라운드에 상주하며 화면이 꺼진 뒤에도 네트워크 연결을 유지하는 앱을 제한합니다. 구체적으로는 서비스가 시스템에 의해 강제 종료된 뒤 VPN 프레임워크가 재연결을 시도하는데, 이 재연결 과정에서 짧은 시간 내에 네트워크 하드웨어가 여러 번 깨어나면서 "겉보기엔 배터리를 많이 쓰지만 실제로는 반복 재시작 때문"인 상황이 발생합니다. 해결 방법은 클라이언트를 배터리 최적화 예외 목록에 추가하고 필요한 자동 실행 권한을 유지하는 것입니다.

1. 시스템 배터리 관리 설정 열기

   「설정 → 배터리 → 배터리 최적화」또는 해당 제조사 시스템의 「절전 정책」페이지로 들어가 Clash 클라이언트 앱을 찾습니다.

2. 앱을 제한 없음으로 설정

   「최적화 안 함」또는 「백그라운드 활동 허용」을 선택해, 화면 잠금 후 시스템이 이 프로세스의 네트워크 연결을 강제로 일시 중단하지 않도록 합니다.

3. 자동 실행 및 연관 실행 권한 확인

   앱 권한 관리에서 「자동 실행」이 켜져 있는지 확인합니다. 일부 시스템에서는 「연관 실행」도 추가로 허용해야 합니다. 그렇지 않으면 VPN 서비스가 시스템에 의해 회수된 뒤 스스로 복구되지 못하고 사용자가 직접 앱을 다시 열어야만 합니다.

4. 알림 상시 표시 권한이 꺼져 있지 않은지 확인

   VPN 서비스는 포그라운드 알림에 의존해 프로세스 우선순위를 유지합니다. 알림 권한이 시스템이나 사용자에 의해 수동으로 꺼져 있으면 서비스 생존 시간이 눈에 띄게 줄어들고, 그 결과 재연결 순환이 더 자주 발생합니다.

참고로 예외 목록에 추가하는 것 자체는 배터리 소모를 늘리지 않으며, 단지 시스템이 프로세스를 자주 종료하고 재시작하는 것을 막아줄 뿐입니다. 실질적인 배터리 소모 원인은 여전히 앞의 두 절에서 다룬 규칙 폴링 주기와 DNS 동시 조회 설정에 있으며, 예외 목록 조정은 "연결 불안정으로 인한 간접적인 배터리 소모"를 해결하는 것입니다. 두 가지를 동시에 처리해야 눈에 띄는 효과를 볼 수 있습니다.

iOS: 온디맨드 연결과 VPN 프로파일의 절전 설정

iOS 플랫폼의 네트워크 확장 프레임워크(NetworkExtension)는 백그라운드 프록시 프로세스에 대한 제한이 더 엄격하며, 시스템은 기기의 배터리 상태, 네트워크 종류, 사용 빈도에 따라 확장 프로세스의 스케줄링 우선순위를 동적으로 조정합니다. 클라이언트는 iOS에서 보통 VPN 설정 형태로 시스템에 연동되며, 설정 프로파일의 「온디맨드 연결」(On-Demand) 규칙이 VPN 터널의 생성 시점을 직접 결정합니다. 설정이 잘못되면 불필요한 상황에서 터널이 반복적으로 생성되고 끊어질 수 있습니다.

1. 클라이언트 설정의 VPN 프로파일 관리 페이지로 들어가 「온디맨드 연결」또는 「On-Demand Rules」옵션을 찾습니다.
2. 규칙이 「항상 연결」로 설정되어 있지 않은지, 네트워크 종류별로 구분되어 있는지 확인합니다. 예를 들어 모바일 데이터를 사용할 때나 지정한 Wi-Fi 이름 이외의 네트워크에 연결됐을 때만 터널을 자동으로 생성하도록 합니다.
3. 「특정 Wi-Fi 제외」가 설정되어 있다면, 목록에 집이나 회사 등 오래 머무는 신뢰할 수 있는 네트워크가 포함되어 있는지 확인해, 이런 환경에서 VPN 터널이 의미 없이 유지되는 것을 방지합니다.
4. 시스템 설정의 「VPN 및 기기 관리」에서 해당 프로파일 상태가 정상인지 확인합니다. 상태가 비정상이면 시스템이 더 높은 빈도로 터널 재협상을 시도하며, 이 역시 배터리 소모를 늘립니다.

또한 iOS에서도 로그 레벨은 낮게 유지하는 것을 권장합니다. 이유는 안드로이드, 데스크톱 환경과 동일합니다. 확장 프로세스가 깨어난 김에 고빈도 로그 쓰기를 실행하면 해당 깨어남의 지속 시간이 길어지고, 이는 시스템이 해당 확장 프로세스의 스케줄링 우선순위를 판단하는 데 간접적으로 영향을 줍니다.

장기 모니터링: 패널 도구로 배터리 소모 추이 지속 관찰

위 조정을 마친 후에는 클라이언트에 내장된 연결 패널이나 트래픽 통계 기능으로 일정 기간의 실행 상태를 관찰하는 것을 권장하며, 단순히 체감만으로 문제 해결 여부를 판단하지 않는 것이 좋습니다. 중점적으로 확인할 지표는 세 가지입니다. 화면 잠금 후에도 활성 연결 수가 계속 증가하는지, DNS 조회 횟수가 정상적인 인터넷 사용에 필요한 수준보다 눈에 띄게 많은지, 규칙 세트 리로드 이벤트가 로그에서 얼마나 자주 나타나는지입니다. 화면 잠금 후에도 활성 연결 수가 눈에 띄게 줄지 않는다면, 대개 백그라운드 앱이 계속 네트워크 요청을 보내고 있다는 신호입니다. 이런 문제의 근본 원인은 흔히 Clash 자체가 아니라 시스템 계층의 다른 앱에 있으며, 앱별 프록시 모드를 임시로 켜서 화면 잠금 후에도 활성 연결을 유지하는 앱이 구체적으로 무엇인지 확인할 수 있습니다.

배터리 소모 문제 진단의 본질은 단계적으로 배제해 나가는 과정입니다. 설정 계층의 규칙 폴링 주기, 로그 레벨, DNS 동시 조회 설정은 커널 자체의 기본 부하를 결정하고, 시스템 계층의 배터리 최적화 예외 목록과 온디맨드 연결 규칙은 백그라운드 생존 방식이 효율적인지를 결정합니다. 둘 중 어느 한쪽이라도 잘못 설정되면 배터리 사용 시간에서 그 영향이 크게 드러나므로, 본문의 순서대로 하나씩 점검하고 한 가지만 조정한 뒤 곧바로 결론을 내리지 않는 것을 권장합니다.