· 문제 해결 · 약 8분 소요

Clash 모바일 배터리 소모 이상 진단 및 백그라운드 실행 전략 최적화

모바일에서 Clash 배터리 소모가 높은 경우는 대개 백그라운드 유지, 전역 라우팅, 로그 레벨과 관련이 있습니다. 플랫폼별 절전 설정과 점검 순서를 정리했습니다.

먼저 짚고 갈 것: 배터리 통계의 숫자는 부풀려져 있다

키워드: 배터리 소모 귀인. Android와 iOS의 배터리 통계에는 공통점이 하나 있습니다. VPN 터널을 지나는 트래픽에서 발생한 네트워크 전력 소모는 전부 VPN 앱의 몫으로 기록된다는 점입니다. Clash는 모바일에서 VPN 형태로 동작하며, Android에서는 VpnService 인터페이스를, iOS에서는 Network Extension을 사용합니다. 메신저 영상 통화, 숏폼 영상, 지도 내비게이션이 주고받는 모든 바이트가 Clash 터널을 한 번씩 지나가고, 베이스밴드 깨어남과 RF 송신에 드는 전력도 전부 Clash에 계산됩니다. 프로세스 자체의 CPU 소모는 통계 수치의 꼬리표 정도에 지나지 않는 경우가 많습니다.

진짜 이상인지 판단하려면 두 가지 지표를 봅니다. Android에서는 「설정 → 배터리 → 앱별 배터리 사용량」으로 들어가 Clash 항목을 열어 CPU 포그라운드·백그라운드 활동 시간을 확인하고, iOS에서는 「설정 → 배터리」에서 Clash 항목 아래의 백그라운드 활동 시간을 확인합니다. 규칙 모드로 하루 종일 켜 두었을 때 Clash 자체의 CPU 시간은 보통 몇 분에 불과하고, 점유율이 5% 안팎으로 움직이면 정상 범위입니다. 점유율이 며칠 연속 15%를 넘고 CPU 시간이 시간 단위로 잡힐 때만 아래 절차대로 점검하면 됩니다.

심리적 기대치도 배제해야 합니다. 프록시를 상시 켜 두면 사용 습관도 함께 바뀌기 마련이고, 해외 콘텐츠를 더 많이 보게 되면 배터리 지속 시간은 자연스럽게 줄어듭니다. 정확한 방법은 반나절 대조 실험입니다. Clash를 끄고 비슷한 사용 강도를 유지한 뒤 화면 켜짐 시간과 대기 중 배터리 소모를 비교해서, 차이가 실제로 존재하는지 먼저 확인하고 설정을 건드릴지 결정하세요.

수치 해석 기준

배터리 사용량 순위의 백분율은 「프로세스 전력 소모」가 아니라 「귀인 비중」입니다. Clash가 이상인지 판단할 때는 CPU 활동 시간을 기준으로 삼고, 백분율 순위만 보지 마세요.

백그라운드 유지: 절전 정책과 연결 유지 사이의 균형

키워드: 배터리 최적화 예외 목록. 모바일에서 가장 흔한 딜레마는 이렇습니다. 시스템은 전력을 아끼려고 백그라운드 앱을 종료하고, 터널이 종료되면 프록시가 끊깁니다. 클라이언트는 연결을 유지하려고 프로세스 유지를 강화하는데, 그 유지 수단 자체가 또 전력을 소모합니다. 올바른 해법은 Clash가 더 공격적으로 살아남게 하는 것이 아니라, 시스템의 절전 관리 대상에서 빼서 시스템이 건드리지 않게 하는 것입니다.

Android의 표준 절차는 Clash를 배터리 최적화 예외 목록에 추가하는 것입니다. 경로: 설정 → 애플리케이션 → 특별 앱 권한 → 배터리 최적화에서 Clash를 찾아 「최적화 안 함」으로 변경합니다. 예외 목록에 들어가면 시스템이 더 이상 백그라운드 네트워크와 깨어남을 제한하지 않으므로, 포그라운드 서비스만으로도 터널을 안정적으로 유지할 수 있고 다른 수단은 필요 없습니다.

중국 제조사 ROM에는 두 번째 제한이 더 있습니다. 샤오미 MIUI는 「자동 시작」을 따로 켜고, 최근 작업 화면에서 Clash 카드를 아래로 당겨 잠금해야 합니다. 화웨이 EMUI는 「앱 시작 관리」에서 자동 관리를 끄고 수동으로 바꾼 뒤 백그라운드 활동을 허용합니다. OPPO, vivo는 설정 항목 이름이 다를 뿐 논리는 같습니다. 백그라운드 실행 허용, 백그라운드 고전력 소모 허용. 이 단계를 빼먹으면 예외 목록도 ROM 자체의 정리 정책을 막지 못합니다.

상시 알림은 끄지 마세요. Clash의 VPN 알림은 포그라운드 서비스 알림으로, Android가 규정상 허용하는 유지 메커니즘입니다. 알림이 거슬린다고 알림 권한을 통째로 끄면 포그라운드 서비스가 강등되고, 프로세스가 종료될 때마다 반복적으로 재시작됩니다. 재시작할 때마다 터널을 다시 만들고 핸드셰이크를 다시 해야 해서 오히려 전력을 더 씁니다.

iOS에는 수동으로 살아남는다는 개념 자체가 없습니다. Network Extension은 시스템이 관리하며, 터널의 시작과 정지는 시스템 스케줄링에 맡겨집니다. Clash Plus의 온디맨드 연결(On Demand)을 켜 두기만 하면 됩니다. 시스템이 네트워크 수요가 있을 때 터널을 올리고 유휴 상태일 때 일시 중지하므로, 수동으로 자주 껐다 켜는 것보다 훨씬 전력이 적게 듭니다.

절전 앱과 VPN의 충돌

이른바 「배터리 절약 앱」 「백그라운드 정리 앱」들은 VPN 터널을 정리 대상으로 간주합니다. 터널을 죽이면 클라이언트가 다시 연결을 시도하고, 죽이고 연결하기를 반복하면서 전력을 소모합니다. 이런 앱을 설치했다면 Clash를 예외 목록에 먼저 추가하거나, 아예 삭제하세요. 시스템 내장 배터리 관리만으로 충분합니다.

라우팅 모드와 규칙 세트: 매칭 비용의 대부분

키워드: 규칙 모드. 라우팅 모드는 얼마나 많은 트래픽이 암호화 전달을 거칠지를 결정하며, 전력 소모 차이가 가장 크게 벌어지는 설정입니다. 전역 라우팅(Global)에서는 모든 트래픽이 프록시로 들어가 매 바이트마다 암호화와 전달을 거치므로 전력 소모가 가장 크고, 연결 상태를 임시로 점검할 때만 적합합니다. 규칙 모드(Rule)는 중국 본토 사이트를 직접 연결하고 규칙에 맞는 트래픽만 프록시로 보내므로, 평소에는 규칙 모드를 상시 사용해야 합니다. 직접 연결(Direct) 모드는 프록시를 끈 것과 같아서 여기서는 다루지 않습니다.

규칙 세트는 많다고 좋은 게 아닙니다. 새 연결이 생길 때마다 규칙을 한 줄씩 전부 대조해야 하므로, 수만 줄짜리 GEOSITE 규칙은 매번 매칭할 때마다 CPU 비용이 든다는 뜻입니다. 구독 구성에 기본으로 포함된 규칙 세트면 보통 충분하니 서드파티 대형 목록을 덧붙이지 마세요. 규칙 수가 두 배가 되면 매칭 비용도 두 배가 되는데, 체감되는 이득은 거의 없는 경우가 많습니다.

DNS는 fake-ip를 사용하세요. redir-host 모드에서는 프록시 대상 도메인을 먼저 실제 DNS 조회한 뒤 규칙 매칭에 넣기 때문에, 조회 한 번마다 네트워크 왕복과 베이스밴드 깨어남이 한 번씩 발생합니다. fake-ip 모드는 예약 대역의 가짜 주소를 바로 반환하고 도메인은 그대로 원격지에서 조회하도록 넘기므로, 로컬 조회의 대기와 깨어남을 없앨 수 있어 모바일에서 켜 두는 것을 권장합니다.

DNS 업스트림은 욕심내지 마세요. nameserver에 업스트림을 일곱 여덟 개 쌓아 두면 동시 조회 때 업스트림마다 패킷을 보내야 해서 무선 모듈이 반복적으로 깨어납니다. 지연이 낮은 업스트림 두세 개면 충분합니다. 예를 들어 통신사 DNS에 공용 DNS 한 조를 곁들이는 식입니다.

mode: rule
log-level: warning
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

이 스니펫은 구독 구성의 재정의(override) 구간에 합치거나, 클라이언트 설정 화면에서 항목별로 대응해 입력하면 됩니다. 수정 후 구성을 다시 불러오면 적용됩니다.

로그와 화면 새로고침: 간과하기 쉬운 두 가지

키워드: 로그 레벨. log-level을 debug나 info로 열어 두면 연결의 생성, 매칭, 종료마다 로그 한 줄씩 기록되고, 잦은 파일 쓰기와 깨어남은 모바일에서 실질적인 전력 소모입니다. 평소에는 warning이나 error로 고정하고, 문제를 점검할 때만 임시로 info로 되돌렸다가 끝나면 다시 원래대로 두세요.

화면을 계속 띄워 두는 것도 전력을 먹습니다. 연결 패널과 로그 패널은 실시간으로 새로고침되므로, 화면을 열어 두고 연결이 스크롤되는 것을 보는 동안 CPU와 화면이 계속 깨어 있습니다. 확인이 끝나면 바로 나가고, 클라이언트를 오래 포그라운드에 두지 마세요.

노드 자동 지연 측정은 자제해야 합니다. 일부 클라이언트는 기본적으로 주기적으로 전체 노드의 지연을 측정하는데, 간격이 너무 짧으면 정해진 시간마다 노드 목록 전체를 한 바퀴 도는 셈이라 수십, 수백 개 노드에 각각 탐지 패킷을 보냅니다. 자동 측정을 끄거나 간격을 30분 이상으로 늘리세요. 평소 노드 선택에는 수동 측정이면 충분합니다.

플랫폼별 절전 설정 체크리스트

결론부터 표로 정리하고, 이후 플랫폼별로 풀어 설명합니다:

설정 항목절전 설정값설명
라우팅 모드규칙(Rule)전역 모드는 전량 암호화 전달로 전력 소모가 가장 큼
DNS 모드fake-ip로컬 실제 조회의 네트워크 왕복 제거
DNS 업스트림2~3개동시 조회 시 업스트림마다 패킷 전송
로그 레벨warning / errordebug와 info는 연결마다 로그 기록
자동 지연 측정끄기 또는 30분 이상주기적 탐지가 노드 목록 전체를 순회
배터리 최적화예외 목록에 추가시스템의 백그라운드 종료로 인한 반복 재연결 방지

Android(Clash for Android / FlClash)

iOS(Clash Plus)

표준 점검 순서

배터리 소모 문제가 생기면 정해진 순서대로 진행하세요. 단계마다 변수를 하나만 바꾸고, 바꾼 뒤 반나절에서 하루 정도 관찰합니다:

  1. 배터리 통계에서 CPU와 백그라운드 활동 시간을 보고, 진짜 이상인지 귀인 때문에 부풀려진 것인지 확인합니다.
  2. 라우팅 모드를 확인하고, 전역이면 규칙으로 되돌립니다.
  3. 로그 레벨을 warning으로 낮추고 자동 지연 측정을 끕니다.
  4. DNS 업스트림과 규칙 세트를 줄이고, fake-ip가 켜져 있는지 확인합니다.
  5. 배터리 최적화 예외 목록과 ROM 백그라운드 권한을 점검하고, 상시 알림은 켜 둡니다.
  6. 반나절 대조 테스트를 합니다. 그래도 이상이면 로그를 임시로 info로 올려 일부를 캡처하고, 기기 모델과 시스템 버전을 함께 클라이언트 프로젝트에 피드백합니다.

대부분의 사례는 세 번째 단계까지 오면 정상 수준으로 돌아옵니다. 클라이언트 결함이 원인인 전력 소모는 드물기 때문에, 순서대로 점검하면 이리저리 헤매는 일을 피할 수 있습니다.

클라이언트 다운로드