Clash 안드로이드 배터리 과소모 문제 해결: 백그라운드 유지, 제조사 절전 정책과 VPN 상시 연결

먼저 배터리를 소모하는 원인부터 확인하기

Android 상태 표시줄에 열쇠 또는 VPN 아이콘이 나타난다고 해서 시스템이 VPNService 연결을 유지하고 있다는 뜻일 뿐, Clash 코어가 계속 높은 부하로 작동한다는 의미는 아닙니다. mihomo 코어, 클라이언트 화면, 모바일 네트워크, Wi-Fi 검색, 프록시를 사용하는 앱은 배터리 사용량에서 서로 다른 항목으로 집계될 수 있습니다. 문제를 확인하기 전에 ‘밤새 배터리 20% 감소’를 재현 가능한 데이터로 나누어 기록하세요.

비교 가능한 8시간 테스트 진행하기

1. 배터리를 80% 이상 충전하고 게임, 클라우드 사진 백업, 시스템 업데이트를 종료합니다.
2. 현재 네트워크 유형, 신호 세기, Clash 모드, 선택한 노드와 설정 업데이트 시간을 기록합니다.
3. 첫날 밤에는 Clash를 종료한 상태로 같은 장소에서 화면을 잠그고 8시간 동안 그대로 둔 뒤 배터리 감소율을 기록합니다.
4. 둘째 날 밤에는 같은 장소에서 동일한 Wi-Fi와 노드를 사용해 Clash를 켜고 다시 8시간 동안 그대로 둡니다.
5. 「설정」→「배터리」→「배터리 사용량」에서 Clash, Android 시스템, 모바일 네트워크, 주요 앱의 비중을 각각 확인합니다.

예를 들어 Clash를 끈 상태에서 8시간 동안 3% 감소하고 켠 뒤 6% 감소했다면, 추가된 3%포인트를 프록시 경로와 관련 깨우기 활동의 대략적인 비용으로 볼 수 있습니다. 두 테스트에서 각각 4%와 19%가 감소했고 ‘모바일 네트워크’가 가장 높은 비중을 차지한다면, 프록시 규칙을 바로 수정하기보다 약한 신호와 Wi-Fi 연결 끊김을 먼저 확인하세요.

시스템 도구로 백그라운드 활동 확인하기

Android 14와 Android 15에서는 제조사에 따라 메뉴 이름이 달라질 수 있지만, 일반적으로 「설정」→「배터리」→「배터리 사용량」에서 Clash를 열어 포그라운드 시간과 백그라운드 시간을 확인할 수 있습니다. 백그라운드 시간이 밤새 유지되는 것은 VPN 상시 연결의 정상적인 모습입니다. 화면을 잠근 뒤에도 CPU 사용량이 계속 높거나 기기가 따뜻하게 유지되거나 Clash의 배터리 사용 그래프가 연속해서 급격히 상승한다면 비정상 신호로 볼 수 있습니다.

ADB 환경이 있다면 컴퓨터에서 시스템 통계를 추가로 확인할 수 있습니다. 다음 명령은 클라이언트 설정을 변경하지 않습니다:

adb shell dumpsys batterystats
adb shell dumpsys deviceidle
adb shell dumpsys connectivity
adb shell dumpsys vpn_management

Android 버전에 따라 제공되는 서비스 항목이 다를 수 있습니다. 마지막 명령에서 서비스를 찾을 수 없다는 메시지가 나오면 앞의 두 항목만 사용하세요. 화면이 잠긴 동안의 깨우기 횟수, 네트워크 활동, Doze 상태를 중점적으로 확인하고, 특정 순간의 CPU 수치 하나만으로 결론을 내리지 마세요.

먼저 고주기 속도 측정과 자동 업데이트 끄기

많은 배터리 소모 문제는 정상적인 트래픽 전달보다 클라이언트가 백그라운드에서 URL-Test, 구독 업데이트 또는 노드 상태 확인을 반복 실행하는 데서 발생합니다. 한 번의 속도 측정은 정책 그룹에 포함된 여러 노드와 연결을 만들 수 있습니다. 한 그룹에 노드 80개가 있고 간격을 60초로 설정하면 이론상 한 시간에 수천 번의 연결 시도가 발생할 수 있습니다. 네트워크가 불안정하면 시간 초과와 재시도로 무선 통신 모듈의 활성 시간이 더 길어집니다.

정책 그룹의 속도 측정 간격 확인하기

현재 설정을 열고 type: url-test, type: fallback 또는 type: load-balance가 포함된 정책 그룹을 찾습니다. 일반적인 필드는 다음과 같습니다:

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 노드 A
      - 노드 B
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

interval: 600은 600초마다 한 번씩 확인한다는 뜻으로, 휴대전화에서 상시 연결할 때는 60초보다 적합합니다. mihomo가 지원하는 lazy: true를 사용하면 정책 그룹을 오랫동안 사용하지 않을 때 불필요한 탐색을 줄일 수 있습니다. 해당 필드를 클라이언트 설정 편집기가 유지하는지는 내보낸 YAML을 기준으로 확인해야 하며, 일부 구독은 업데이트할 때마다 로컬 수정 내용을 덮어씁니다.

클라이언트마다 메뉴 이름은 통일되어 있지 않습니다. 일반적인 경로는 「설정」→「현재 설정」→「오버라이드」 또는 「설정」→「구독」→「자동 업데이트」입니다. 화면에서 구독 업데이트 주기만 설정할 수 있다면 정책 그룹의 속도 측정 간격은 설정 제공자나 로컬 오버라이드에서 조정해야 합니다.

규칙 규모와 DNS 부하 줄이기

Clash의 규칙 매칭은 일반적으로 휴대전화 상시 연결에서 배터리를 가장 많이 소모하는 원인이 아닙니다. 하지만 설정 파일이 지나치게 크거나 규칙 세트가 자주 업데이트되거나 DNS 조회가 반복적으로 다른 서버로 전환되면 메모리 사용량과 네트워크 깨우기가 늘어날 수 있습니다. 여러 규칙을 중복으로 불러오거나 실제 트래픽 판단에 사용하지 않는 provider를 많이 활성화했을 때 문제가 자주 발생합니다.

중복 규칙과 지나치게 잦은 업데이트 줄이기

설정 로그를 열고 시작할 때 불러오는 rule-provider 수를 확인합니다. 같은 도메인 목록을 원격 규칙 세트, 인라인 DOMAIN-SUFFIX, 스크립트 오버라이드의 세 가지 방식으로 중복해 등록하지 마세요. 원격 규칙 세트의 업데이트 주기는 콘텐츠 변경 빈도에 맞추는 것이 좋습니다. 광고나 일반 도메인 목록은 보통 12~24시간이면 충분하며, 지리 데이터베이스를 매일 업데이트해도 실질적인 이점은 없습니다.

rule-providers:
  common-direct:
    type: http
    behavior: domain
    interval: 86400
    path: ./ruleset/common-direct.yaml

interval: 86400은 24시간을 의미합니다. 규칙 제공자의 다운로드는 클라이언트 또는 코어가 시작하며, 잦은 업데이트는 네트워크를 깨우고 저장 장치에 데이터를 기록합니다. 설정이 매시간 업데이트되도록 되어 있지만 규칙 파일 자체는 몇 주에 한 번만 바뀐다면 주기를 바로 늘리세요.

DNS 순환과 실패 재시도 확인하기

DNS 설정에 문제가 있으면 웹페이지가 처음 열릴 때 느리거나 로그에 timeout이 반복해서 나타나거나 대기 중에도 클라이언트가 계속 DNS 조회를 수행하는 증상이 나타납니다. Fake-IP 모드는 규칙 기반 분기에 적합하며 그 자체가 배터리를 많이 소모한다는 뜻은 아닙니다. 실제로 확인해야 할 부분은 연결할 수 없는 nameserver, 반복되는 fallback 시간 초과, 그리고 먼저 자체 도메인을 조회해야 하는 DoH 주소의 의존성 구조입니다.

• 도메인 형식의 DoH 서버에 연결 가능한 bootstrap DNS 조회 경로를 설정합니다.
• 시스템 비공개 DNS, 브라우저 보안 DNS, Clash DNS에 같은 유형의 전달 설정을 여러 겹으로 쌓지 마세요.
• 로컬 네트워크의 DNS가 휴대전화에서 Clash가 수신 중인 포트로 요청을 되돌려 보내지 않는지 확인합니다.
• 로그에 3초 또는 5초 시간 초과가 계속 나타난다면 동시 서버 수만 늘리지 말고 연결할 수 없는 상위 DNS 서버를 먼저 교체하세요.

일반적으로 사용하는 mixed-port는 7890이지만 Android 클라이언트가 VPNService로 트래픽을 처리할 때는 보통 앱에서 이 포트를 직접 입력할 필요가 없습니다. 브라우저에 127.0.0.1:7890을 별도로 설정한 뒤 시스템 VPN까지 함께 사용하면 경로가 꼬일 수 있습니다. 일부 트래픽만 프록시하는 테스트가 아니라면 앱 트래픽은 하나의 진입점만 통과하도록 설정하세요.

TUN, VPNService와 상시 표시 아이콘의 선택 기준

Android의 Clash 계열 클라이언트는 일반적으로 시스템 VPNService로 가상 네트워크 인터페이스를 만든 다음 트래픽을 mihomo 코어로 전달합니다. 상태 표시줄에 VPN 아이콘이 계속 표시되는 것은 시스템 동작입니다. 프록시가 활성화되어 있다면 이 서비스가 유지되는 것이 정상이며, 알림을 강제로 숨기거나 프로세스를 중지하거나 백그라운드를 주기적으로 정리하면 오히려 터널이 자주 재생성될 수 있습니다.

하루 종일 상시 연결할 만한 상황

• 메시지, 협업 도구와 개발 서비스에서 항상 규칙에 따라 트래픽을 분기해야 할 때.
• 휴대전화가 Wi-Fi와 모바일 데이터 사이를 자주 전환해 프록시 경로를 자동으로 복구해야 할 때.
• 설정에 직접 연결 규칙이 있어 대부분의 한국 국내 트래픽이 원격 노드를 거치지 않을 때.
• 클라이언트의 속도 측정 및 구독 업데이트 주기를 적절하게 설정했을 때.

매일 고정된 앱에서 잠깐만 프록시를 사용한다면 필요할 때만 켜는 편이 배터리를 절약할 수 있습니다. 하루 종일 상시 연결하는 이유는 연결의 연속성을 확보하기 위해서이지 속도를 높이기 위해서가 아닙니다. Clash를 끄면 시스템이 VPN 인터페이스를 해제하며, 다시 켤 때 기존 TCP 연결을 새로 만들어야 할 수 있습니다. 이는 정상적인 동작입니다.

일반 VPN과 항상 켜진 VPN

Android 기본 설정에서는 보통 「설정」→「네트워크 및 인터넷」→「VPN」→ 해당 Clash 항목의 톱니바퀴 버튼으로 이동하면 ‘항상 켜진 VPN’을 확인할 수 있습니다. 제조사별 시스템에서는 「연결 더보기」→「VPN」에 있을 수도 있습니다. 이 기능을 켜면 시스템이 해당 VPN 앱을 계속 실행하려고 합니다. 동시에 ‘VPN 없이 연결 차단’을 켜면 Clash 실행에 실패했을 때 다른 앱의 네트워크가 완전히 차단될 수 있습니다.

TUN 모드는 더 넓은 범위의 TCP와 UDP 트래픽을 처리하므로 시스템 HTTP 프록시를 따르지 않는 앱에 적합합니다. Android 클라이언트에서는 VPNService 자체가 이미 TUN 연결 역할을 하는 경우가 많으므로 데스크톱의 ‘시스템 프록시+TUN’ 조합을 그대로 적용하지 마세요. 클라이언트에 ‘로컬 네트워크 우회’, ‘선택한 앱만 프록시’ 또는 ‘앱별 프록시’ 옵션이 있다면 이를 통해 처리 범위를 먼저 줄이세요.

제조사별 백그라운드 허용 목록 설정

시스템이 백그라운드 앱을 정리하는 문제와 배터리가 계속 소모되는 문제는 서로 반대 방향의 현상입니다. 허용 목록의 목적은 프로세스가 잘못 종료되지 않도록 하는 것이지 모든 권한을 무조건 허용하는 것이 아닙니다. 먼저 자동 실행과 백그라운드 실행을 허용한 뒤 24시간 관찰하세요. 화면을 잠근 후에도 터널이 끊길 때만 배터리 최적화를 추가로 조정하는 것이 좋습니다.

시스템 버전, 지역, 기기 모델에 따라 메뉴 이름이 달라집니다. 해당 경로를 찾을 수 없다면 설정 검색창에 ‘배터리 최적화’, ‘백그라운드 활동’ 또는 ‘자동 실행’을 입력하세요. 변경 후 화면을 30분 동안 잠그고 다른 기기에서 휴대전화로 메시지를 보낸 다음 Wi-Fi와 모바일 데이터를 한 번 전환해 VPN 아이콘과 네트워크 연결이 계속 유지되는지 확인합니다.

최근 앱 화면의 ‘앱 잠금’은 한 번에 모두 정리할 때 앱이 종료되는 것을 줄여 줄 뿐, 시스템 배터리 허용 목록을 대신할 수 없습니다. 반대로 Clash를 허용 목록에 추가한 뒤에도 최근 앱을 자주 직접 정리하면 포그라운드 서비스가 중단될 수 있습니다. 안정적인 설정을 위해 서로 충돌하는 조작은 최대한 줄이세요.

로그로 비정상 연결과 반복 재시작의 원인 찾기

화면을 잠근 뒤 휴대전화가 뜨거워진다면 Clash의 로그 화면을 열고 시간순으로 정렬하세요. 정상적인 대기 상태에서도 소량의 연결, 규칙 세트 확인, 네트워크 변경 기록은 나타날 수 있습니다. 비정상적인 경우에는 같은 오류가 몇 초마다 반복되는 패턴이 보입니다.

반복 기록은 네 가지 유형을 중점적으로 확인하세요

1. DNS timeout: 상위 DNS 서버에 연결할 수 없어 코어가 계속 대기하며 다른 서버를 시도합니다.
2. connection refused: 로컬 포트 또는 원격 서비스가 연결을 거부하고 있어 특정 앱이 빠르게 재시도하고 있습니다.
3. network changed: Wi-Fi 신호 불량 또는 듀얼 SIM 데이터 전환으로 터널이 반복해서 재생성되고 있습니다.
4. provider update failed: 구독 또는 규칙 세트 주소에 연결할 수 없는데 업데이트 주기까지 너무 짧게 설정되어 있습니다.

먼저 로그 수준을 info로 유지하세요. debug 또는 trace는 더 많은 로그를 기록하므로 짧은 재현 테스트에만 적합합니다. 5~10분 동안 기록한 뒤 일반 로그 수준으로 되돌리고 오류가 발생한 시간, 네트워크 유형, 해당 앱을 함께 저장하세요.

앱별 프록시도 원인을 좁히는 데 사용할 수 있습니다. 먼저 Clash가 브라우저만 처리하도록 설정하고 화면을 잠근 채 관찰하세요. 배터리 소모가 정상으로 돌아오면 소셜, 동영상, 동기화 도구를 차례로 추가합니다. 특정 그룹을 추가한 뒤 백그라운드 연결 수가 눈에 띄게 늘어난다면 해당 앱 그룹의 푸시, 자동 재생, 클라우드 백업 또는 폴링 설정을 확인하세요. 프록시는 연결을 전달하지만 요청 빈도는 대개 개별 앱이 결정합니다.

위험이 낮은 단계부터 영향이 큰 단계로 진행하는 점검 순서

열두 개가 넘는 설정을 동시에 바꾸지 마세요. 어느 단계가 효과가 있었는지 판단할 수 없게 됩니다. 아래 순서대로 진행하고 각 단계마다 최소 한 번의 8시간 대기 주기를 관찰하세요.

1. Clash를 끈 상태와 켠 상태의 대기 기준을 만들고 추가 배터리 감소율을 확인합니다.
2. URL-Test 간격을 600초 이상으로 늘리고 구독 업데이트를 12~24시간으로 변경합니다.
3. 클라이언트의 지연 시간 패널을 끄고 로그 수준을 info로 되돌립니다.
4. DNS timeout, provider 업데이트 실패, 네트워크 전환 반복을 확인합니다.
5. 중복 규칙 세트를 정리하고 규칙 제공자 주기를 86400초로 변경합니다.
6. 앱별 프록시로 백그라운드 연결을 계속 생성하는 앱을 찾습니다.
7. Clash의 백그라운드 활동과 자동 실행을 허용해 절전 정책으로 서비스가 반복 종료되지 않도록 합니다.
8. 하루 종일 연결해야 할 때에만 시스템의 ‘항상 켜진 VPN’을 활성화합니다.

마지막으로 클라이언트 버전과 설정의 호환성도 확인해야 합니다. mihomo 기반 클라이언트를 업그레이드한 뒤 기존 설정에서 바로 충돌이나 반복 재시작이 발생한다면 먼저 설정을 내보낸 다음 노드 하나, 정책 그룹 하나, 기본 MATCH 규칙만 포함한 최소 설정을 새로 만드세요. 최소 설정에서 대기가 정상이라면 원래 설정에 문제가 집중된 것입니다. 최소 설정에서도 문제가 계속되면 클라이언트 버전, 시스템 VPN 권한, 제조사 백그라운드 정책을 추가로 확인하세요.

Android 프록시 상시 연결의 합리적인 목표는 VPNService 안정성, 화면 잠금 후에도 끊기지 않는 연결, 낮은 빈도의 속도 측정과 업데이트, 기기가 계속 뜨거워지지 않는 상태입니다. 백그라운드 시간이 길다고 해서 배터리를 많이 소모하는 것은 아니며 VPN 아이콘이 계속 표시된다고 고장인 것도 아닙니다. 비교 테스트와 로그, 단계별 변경을 활용하면 프로세스를 반복해서 정리하는 것보다 안정적인 원인을 더 빠르게 찾을 수 있습니다.