Android의 Clash 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 상태 표시줄에 열쇠 아이콘이 나타나면 앱이 연결, DNS 조회, 규칙 매칭을 계속 처리해야 하므로 배터리 기록에 백그라운드 활동이 장시간 표시되는 것은 정상입니다. 실제로 점검해야 할 부분은 비정상적인 추가 소모입니다. 대기 1시간에 5% 이상 감소하거나, 기기가 계속 뜨겁거나, 8시간 야간 대기 중 배터리가 15% 넘게 줄거나, 네트워크 전환 후 앱이 반복해서 재시작된다면 원인을 확인해야 합니다.
배터리 소모는 시스템 배터리 목록의 앱 비율만으로 판단해서는 안 됩니다. 일정 시간 동안 전체 배터리를 4%만 사용했고 그중 Clash가 30%를 차지했다면 실제 소모량은 약 1.2%포인트입니다. 전체 소모량이 25%에 이르렀을 때 같은 비율이 나타나야 우선적으로 해결할 가치가 있습니다. 점검 전에는 전체 배터리 잔량, 화면 사용 시간, 네트워크 유형, 테스트 시간을 기록한 뒤 설정을 하나씩 변경하세요.
배터리 소모가 클라이언트 때문인지 네트워크 환경 때문인지 먼저 판단하기
세 가지 테스트로 문제를 분리하기
가장 효과적인 방법은 바로 재설치하는 것이 아니라 조건을 동일하게 맞춘 세 가지 비교 테스트를 진행하는 것입니다. 각 테스트는 최소 45~60분 동안 유지하고 화면 밝기, 네트워크, 전면 앱을 동일하게 유지하세요.
- Clash 끄기: 시스템의 기본 배터리 소모를 기록해 모바일 신호, Wi-Fi, 다른 앱 자체에 문제가 없는지 확인합니다.
- Clash 켜기, 대기 상태 유지: 동영상을 재생하거나 속도 측정을 실행하지 않고 VPN이 계속 실행될 때의 추가 소모만 관찰합니다.
- Clash를 켜고 평소처럼 사용: 웹을 탐색하거나 메시지를 주고받고, 일정한 화질의 동영상을 재생해 트래픽이 많은 상황을 확인합니다.
예를 들어 Clash를 끈 상태에서 시간당 1.5% 감소하고, 켠 뒤 대기 상태에서 2.2% 감소했다면 차이인 0.7%포인트는 보통 허용 범위입니다. 하지만 켠 뒤 시간당 6%가 줄고 기기 온도가 30℃에서 38℃로 상승한다면 지연 시간 측정, 연결 재시도, 로그, DNS를 점검해야 합니다. 모바일 데이터 신호가 한두 칸뿐이면 모뎀이 송신 출력을 높이므로, 이때는 프록시를 꺼도 배터리가 눈에 띄게 소모될 수 있습니다.
Android 배터리 기록 확인하기
순정 Android와 Pixel에서는 「설정」→「배터리」→「배터리 사용량」으로 이동해 클라이언트를 열고 전면 및 백그라운드 사용 시간을 확인할 수 있습니다. 일부 시스템은 최근 24시간을 기준으로 집계하고, 일부는 마지막 완충 이후를 기준으로 집계합니다. 데이터를 비교할 때는 반드시 같은 집계 기간을 사용하세요.
- 백그라운드 시간이 길지만 시간당 배터리 변화가 적음: 일반적으로 VPN 서비스가 정상적으로 상시 실행 중인 상태입니다.
- 백그라운드 시간이 길고 CPU 활동 및 온도가 함께 상승함: 속도 측정, 로그, 재연결을 우선 점검하세요.
- Clash의 비율은 높지 않지만 ‘모바일 네트워크 대기’가 매우 높음: 먼저 신호 커버리지 문제를 해결하세요.
- 화면을 끈 뒤 연결이 자주 끊김: 일반적으로 제조사의 백그라운드 제한과 관련이 있으며, 커널이 계속 높은 부하로 실행 중이라는 뜻은 아닙니다.
지연 시간 측정 주기와 프록시 그룹 점검
클라이언트의 ‘자동 속도 측정’은 한 번 실행하고 끝나는 작업이 아닙니다. URL-Test, Fallback, Load-Balance 그룹은 일정한 간격으로 테스트 주소에 접속해 노드 지연 시간이나 사용 가능 여부를 판단할 수 있습니다. 구독에 노드가 80개 있고 세 프록시 그룹이 각각 독립적으로 확인하면 한 번에 수백 건의 연결이 발생할 수 있습니다. 간격을 30초로 설정하면 대기 중에도 네트워크와 CPU가 계속 깨어납니다.
점검 주기를 적정 범위로 조정하기
일상적인 모바일 환경에서는 먼저 600초, 즉 10분으로 설정하세요. 네트워크 변화가 많지 않다면 900초까지 늘릴 수 있습니다. 빠른 장애 전환이 필요한 Fallback 그룹은 300초를 유지해도 되지만, 모든 프록시 그룹을 30초나 60초로 실행하는 것은 권장하지 않습니다. ‘전체 속도 측정’을 수동으로 눌러도 연결이 한꺼번에 생성되므로, 점검 중에는 반복해서 실행하지 마세요.
proxy-providers:
mobile-nodes:
type: http
url: https://example.invalid/subscription
interval: 86400
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 600
lazy: trueinterval: 86400은 구독 프로바이더의 업데이트 주기를 초 단위로 제어하고, 상태 확인의 interval: 600은 노드 점검 주기를 제어합니다. 두 설정의 용도는 다릅니다. mihomo에서 지원하는 lazy: true는 사용하지 않는 프로바이더의 능동적인 점검을 줄일 수 있지만, 클라이언트 버전과 설정 형식이 해당 필드를 지원해야 합니다.
중복 자동 선택 그룹 줄이기
설정에 있는 여러 URL-Test 그룹이 같은 노드 묶음을 포함하는지 확인하세요. ‘자동 선택’, ‘스트리밍 자동’, ‘다운로드 자동’ 그룹이 모두 전체 노드를 대상으로 하면 각 그룹이 자체 점검 상태를 관리합니다. 모바일에서는 범용 자동 그룹 하나만 남기고, 특수 서비스에는 고정 노드를 사용하거나 점검 주기를 길게 설정할 수 있습니다. 노드 수를 120개에서 자주 쓰는 15~30개로 줄이는 것만으로도 한 번에 수행되는 탐색 규모를 낮출 수 있습니다.
상시 TUN과 시스템 VPN의 부담
Android 클라이언트의 TUN은 일반적으로 시스템 VpnService 위에서 동작합니다. 앱이 가상 네트워크 인터페이스의 패킷을 읽은 뒤 mihomo 커널로 전달합니다. 단일 앱에 HTTP 프록시만 설정하는 방식과 비교하면 TUN은 더 많은 앱과 프로토콜을 처리하므로 백그라운드 서비스가 계속 실행되어야 합니다. 다만 Android의 대부분의 Clash 계열 클라이언트는 원래 VPN 인터페이스에 의존합니다. 따라서 화면의 ‘TUN’ 스위치가 의미하는 바는 클라이언트 구현에 따라 다를 수 있으며, 데스크톱의 시스템 프록시 개념을 그대로 적용해서는 안 됩니다.
먼저 VPN이 처리할 앱 범위 줄이기
클라이언트에서 ‘앱별 프록시’, ‘앱 프록시’ 또는 ‘접근 제어’를 제공한다면 브라우저, 메신저, 프록시가 필요한 앱만 선택할 수 있습니다. 은행 앱, 지도, 카메라 동기화, 로컬 네트워크 화면 공유처럼 직접 연결이 명확한 앱은 제외하세요. 이렇게 하면 커널을 거치는 연결이 줄고, VPN을 감지한 일부 앱이 반복해서 재시도하는 현상도 피할 수 있습니다.
화이트리스트 모드로 전환하기 전에는 시스템 구성 요소가 프록시를 통해 접속해야 하는지 확인하세요. 앱 스토어, WebView, 다운로드 관리자는 별도의 시스템 프로세스에서 연결을 시작할 수 있습니다. 변경 후에는 웹 페이지 열기, 파일 다운로드, 메시지 푸시, 앱 업데이트를 테스트해야 하며 브라우저의 인터넷 연결만 확인해서는 안 됩니다.
필요하지 않은 상시 기능 끄기
- 로컬 네트워크 공유: 휴대폰을 다른 기기의 프록시 서버로 사용하지 않는다면 ‘로컬 네트워크 연결 허용’을 끄세요.
- 외부 컨트롤러: 원격 패널을 사용하지 않는다면 컨트롤러를
127.0.0.1:9090으로 제한하고 모든 네트워크 인터페이스에서 수신 대기하지 않도록 하세요. - 트래픽 패널 새로 고침: 점검 중에는 실시간 연결 화면을 종료하세요. 연결과 속도를 매초 새로 고치면 전면 CPU 활동이 늘어납니다.
- 상세 로그: 일상적인 사용에는 warning 또는 error를 선택하세요. debug 로그는 짧은 시간의 원인 분석에 적합하며 하루 종일 켜 두는 용도는 아닙니다.
- 핫스팟 공유: 휴대폰 핫스팟을 통한 프록시를 사용하지 않는다면 관련 전달 옵션을 끄세요.
mixed-port: 7890
external-controller: 127.0.0.1:9090
log-level: warning
allow-lan: falsemixed-port: 7890은 로컬 HTTP 및 SOCKS 혼합 포트일 뿐이며, 그 자체로 많은 배터리를 계속 소모하지는 않습니다. 실제로 주의할 부분은 다른 앱이 해당 포트에 지속적으로 접속하는지, 컨트롤러 패널이 연결 데이터를 계속 가져오는지입니다.
규칙, DNS, 스니핑 간소화 방법
규칙 수가 많다고 배터리 소모가 같은 비율로 증가하는 것은 아닙니다. mihomo는 규칙용 인덱스를 생성하므로 수만 개의 도메인 규칙도 안정적으로 실행된 뒤에는 부하가 크게 느껴지지 않을 수 있습니다. 더 흔한 문제는 규칙 프로바이더의 잦은 업데이트, 설정 반복 재로드, DNS 요청 루프, 스니핑과 앱 자체의 암호화 DNS 간 충돌입니다.
규칙 프로바이더는 시간 단위 또는 일 단위로 업데이트하기
광고, 스트리밍, 지역 규칙은 보통 매분 업데이트할 필요가 없습니다. 자주 쓰는 규칙 프로바이더는 43200초 또는 86400초로 설정할 수 있습니다. 업데이트할 때 클라이언트는 파일을 다운로드하고 내용을 파싱한 뒤 규칙을 교체합니다. 여러 프로바이더가 짧은 주기로 동시에 업데이트되면 대기 중에도 규칙적인 CPU 피크가 발생합니다.
rule-providers:
direct-list:
type: http
behavior: domain
format: mrs
interval: 86400
path: ./ruleset/direct.mrs
url: https://example.invalid/rules/direct.mrs바이너리 규칙 형식을 사용하면 로드해야 할 데이터 크기를 줄일 수 있지만, 규칙 소스와 현재 mihomo 버전이 호환되어야 합니다. 가져온 뒤 규칙 로드에 실패하면 클라이언트가 지원하는 YAML, text 또는 mrs 형식으로 되돌려야 하며 파일 확장자만 바꿔서는 안 됩니다.
DNS 루프와 중복 조회 확인하기
클라이언트 DNS가 로컬 주소를 가리키고 상위 암호화 DNS 요청까지 잘못 같은 로컬 포트로 되돌아가면 조회 루프가 발생할 수 있습니다. 대표적인 증상은 로그에 timeout, context deadline exceeded 또는 exchange failed가 연속해서 나타나고, 휴대폰이 대기 중에도 계속 뜨거워지는 것입니다. 먼저 클라이언트 기본 DNS 설정을 사용한 뒤 사용자 지정 상위 DNS를 하나씩 추가하세요.
- 일반 DNS는 보통 53번 포트, DoT는 853번 포트, DoH는 일반적으로 443번 포트를 사용합니다.
- Bootstrap DNS는 DoH 서버 도메인을 직접 해석할 수 있어야 하며, 아직 구축되지 않은 프록시 체인에 의존해서는 안 됩니다.
- 안정적인 상위 DNS 하나와 예비 DNS 하나면 대체로 충분하며, 서버를 열 개 넘게 동시에 설정할 필요는 없습니다.
- Fake-IP, Redir-Host 또는 스니핑 설정을 변경한 뒤에는 먼저 기존 연결을 정리하고 클라이언트를 재시작하세요.
도메인 스니핑은 커널이 일부 연결에 해당하는 도메인을 식별하도록 도와 도메인 규칙을 적용할 수 있게 합니다. 하지만 스니핑이 필요 없는 설정에서는 포트 범위를 넓히고 모든 프로토콜을 대상으로 해도 반드시 이점이 생기지는 않습니다. 로그에 sniff failed가 반복해서 나타나면 먼저 클라이언트 기본 스니핑 범위로 되돌린 뒤 한 시간 동안 배터리 소모와 규칙 적용 결과를 관찰하세요.
제조사 백그라운드 정책으로 반복 실행 방지하기
‘Clash를 켜기만 해도 배터리가 빨리 닳는’ 많은 경우는 실제로 시스템이 VPN 서비스를 계속 종료하고, 클라이언트가 ‘항상 켜진 VPN’이나 자동 시작 정책에 의해 다시 실행되면서 발생합니다. 한 번 완전히 재시작할 때마다 설정, 규칙, DNS 캐시를 다시 불러옵니다. 이 과정이 몇 분마다 반복되면 안정적으로 상시 실행하는 것보다 배터리를 더 많이 소모하고, 메시지 지연과 웹 연결의 간헐적인 끊김도 유발합니다.
순정 Android 및 Pixel
「설정」→「앱」→「모든 앱 보기」로 이동한 뒤 클라이언트를 선택하고 「앱 배터리 사용량」에서 백그라운드 사용을 허용하세요. 페이지에 ‘최적화’와 ‘제한 없음’이 표시된다면 연결이 자주 끊길 때 먼저 ‘제한 없음’을 하루 동안 테스트할 수 있습니다. 이 설정은 상주 시간이 약간 늘어날 수 있지만 반복적인 종료와 재시작을 방지하는 데 도움이 됩니다.
샤오미 HyperOS
일반적인 경로는 「설정」→「앱 설정」→「앱 관리」→클라이언트 선택→「배터리 절약」→「제한 없음」입니다. 이어서 앱 세부 정보 또는 권한 관리에서 ‘자동 시작’을 확인하세요. 최근 작업 화면에서 앱을 잠그는 기능은 정리될 가능성을 낮출 뿐, 백그라운드 정책 설정을 대신할 수는 없습니다. HyperOS 버전에 따라 메뉴 이름이 조금 다를 수 있습니다.
OPPO, OnePlus 및 realme
ColorOS 계열에서는 일반적으로 「설정」→「앱」→「앱 관리」→클라이언트 선택→「배터리 사용 관리」에서 백그라운드 활동을 허용할 수 있습니다. 또한 「설정」→「배터리」→「추가 설정」의 절전 대기 최적화도 확인하세요. 밤에만 연결이 끊기는 경우에는 먼저 절전 대기 관련 옵션을 테스트하는 것이 좋습니다.
삼성 One UI
「설정」→「배터리」→「백그라운드 사용 제한」으로 이동해 클라이언트가 ‘절전 상태 앱’ 목록에 포함되어 있지 않은지 확인하세요. 장시간 연결이 필요하다면 ‘절전 예외 앱’에 추가할 수 있습니다. 동시에 「설정」→「연결」→「기타 연결 설정」→「VPN」에서 현재 VPN 구성을 확인하세요.
시스템 VPN 옵션이 서로 충돌하지 않도록 하기
Android의 ‘항상 켜진 VPN’은 프록시가 계속 작동해야 하는 환경에 적합합니다. ‘VPN을 사용하지 않는 연결 차단’은 더 엄격한 옵션으로, VPN이 재시작되는 동안 모든 네트워크가 일시 중단될 수 있습니다. 클라이언트 자체가 불안정한 상태에서 두 옵션을 함께 켜면 연결 끊김이 더 두드러집니다. 점검 단계에서는 먼저 엄격한 차단을 끄고 일반 VPN만 유지한 뒤, 연결이 안정되면 필요에 따라 다시 설정하세요.
순서대로 실행하는 절전 설정 체크리스트
아래 순서는 위험이 낮고 효과가 분명한 항목부터 정리했습니다. 각 항목을 완료한 뒤 최소 60분 동안 관찰하고, 야간 배터리 소모 문제는 6~8시간 전체 테스트가 필요합니다.
- 연속으로 수동 속도 측정을 실행하지 말고, 자동 상태 확인 주기를 600초로 변경하세요.
- 구독 업데이트 주기를 86400초로, 규칙 프로바이더 주기를 43200초 또는 86400초로 변경하세요.
- 중복 자동 선택 그룹을 삭제하고 자주 사용하는 노드를 15~30개로 제한하세요.
- 로그 수준을 debug에서 warning으로 낮추고 실시간 연결 및 트래픽 패널을 종료하세요.
- 로컬 네트워크 공유, 핫스팟 전달, 사용하지 않는 외부 컨트롤러 수신 대기를 끄세요.
- 앱별 프록시를 활성화하고 실제로 프록시가 필요한 앱만 처리하도록 설정하세요.
- 기본 DNS로 되돌려 테스트하고 사용자 지정 DoH, DoT, Fake-IP 설정 문제를 배제하세요.
- 시스템 설정에서 클라이언트의 백그라운드 실행을 허용해 VPN 서비스의 반복 재시작을 방지하세요.
- Wi-Fi와 모바일 데이터를 각각 테스트해 약한 신호로 인한 모뎀 배터리 소모를 확인하세요.
- 마지막으로 클라이언트 버전을 바꾸거나 간소화한 설정을 다시 가져오는 방법을 고려하세요.
추가 분석이 필요할 때 ADB 사용하기
Android 디버깅 도구에 익숙하다면 먼저 배터리 통계를 초기화하고, 정해진 테스트 절차를 실행한 뒤 결과를 내보내세요. 휴대폰에서 개발자 옵션과 USB 디버깅을 활성화해야 하며, 명령은 컴퓨터에서 실행합니다.
adb shell dumpsys batterystats --reset
adb shell dumpsys batterystats
adb shell dumpsys activity services첫 번째 명령은 현재 배터리 통계를 초기화하므로 테스트 시작 전에 실행해야 합니다. 두 번째 명령은 깨우기, 네트워크, 프로세스 활동을 확인하는 데 사용하고, 세 번째 명령으로 VPN 서비스가 반복해서 생성되는지 확인할 수 있습니다. 같은 클라이언트에서 변경 전후의 깨우기 횟수와 실행 시간을 비교하는 것이 중요하며, 서로 다른 휴대폰 모델의 절대 수치를 직접 비교해서는 안 됩니다.
계속 발열하거나 배터리가 줄어들 때 확인할 이상 징후
기본 최적화를 마친 뒤에도 대기 1시간에 5% 이상 감소한다면 로그 타임라인을 확인하세요. 같은 오류가 계속 나타나는지는 단순한 앱 배터리 비율보다 원인을 찾는 데 더 유용한 단서가 되는 경우가 많습니다.
- 노드 연결 시간 초과: 현재 노드에 연결할 수 없어 클라이언트 또는 앱이 계속 재시도하고 있습니다. 안정적인 노드로 전환하고 실패한 노드를 자동 그룹에서 제외하세요.
- 구독 파싱 실패: 구독 내용이 클라이언트 형식과 호환되지 않아 백그라운드 업데이트가 매번 실패합니다. 먼저 자동 업데이트를 일시 중지하고 구독 형식을 확인하세요.
- 규칙 파일 다운로드 실패: 규칙 주소에 프록시가 필요하지만 프록시가 아직 구축되지 않아 시작 단계에서 요청이 반복될 수 있습니다.
- DNS 시간 초과: 연결 가능한 상위 DNS로 변경하고, 프라이빗 DNS, 클라이언트 DNS, 브라우저 보안 DNS가 중복으로 처리하고 있지 않은지 확인하세요.
- VPN 서비스 반복 시작: 다른 VPN, 가속기, 방화벽 또는 로컬 필터링 앱을 끄세요. Android에서는 일반적으로 동시에 하나의 VpnService만 활성화할 수 있습니다.
- 설정 반복 재로드: 설정 디렉터리를 파일 동기화 도구가 계속 수정하지 않도록 하고, 변경 감지 후 클라이언트가 반복해서 로드하는 상황을 방지하세요.
클라이언트를 업데이트하기 전에 현재 설정을 내보내고 재현 조건을 기록하세요. FlClash처럼 mihomo 기반 클라이언트는 커널 업데이트를 통해 호환성 문제가 해결될 수 있지만, 새 버전과 이전 버전의 TUN, DNS, 규칙 동작에는 차이가 있을 수 있습니다. 업데이트 후에는 먼저 기본 구독 하나만 가져와 테스트하고, 이전 버전의 실험적 설정을 한꺼번에 추가하지 마세요.
합리적인 목표는 시스템 배터리 화면에서 Clash가 완전히 사라지게 만드는 것이 아니라, 백그라운드 실행을 안정적으로 유지하는 것입니다. 화면을 꺼도 기기가 계속 뜨겁지 않고, VPN이 반복 재시작되지 않으며, 일반 대기 상태에서 시간당 추가 배터리 소모를 약 0.5~1.5%포인트로 유지하는 것이 기준입니다. 실제 결과는 배터리 상태, 5G 신호, 노드 지연 시간, 트래픽의 영향을 받으므로 같은 휴대폰에서 변경 전후를 비교해야 합니다.