안드로이드 Clash 배터리 소모 줄이기: 백그라운드 실행 및 배터리 최적화 설정

배터리 소모와 백그라운드 종료를 구분하세요

안드로이드 프록시 클라이언트는 장시간 실행되는 동안 VPN 인터페이스를 통과하는 패킷을 처리하고, 규칙에 따라 트래픽을 분류하며 DNS를 조회하고 필요한 연결을 유지합니다. 배터리 소모량은 실제 트래픽, 네트워크 상태, 속도 테스트 작업, 코어 설정에 따라 달라집니다. 상태 표시줄에 VPN 아이콘이 있다고 해서 기기가 계속 높은 부하로 작동하는 것은 아닙니다.

화면을 잠근 뒤 프록시 연결이 끊기고 잠금을 해제해야 복구되는 경우도 있습니다. 이때는 속도 테스트 간격을 더 늘리기보다 먼저 백그라운드 제한을 확인하세요. 배터리 최적화 제외 목록에 클라이언트를 추가하면 백그라운드에서 실행될 가능성은 높아지지만, 배터리 소모가 직접 줄어드는 것은 아닙니다. 오히려 계속 실행되도록 허용하면 시스템의 백그라운드 사용 시간은 늘어날 수 있습니다.

재현 가능한 대기 상태 비교하기

시스템에 표시되는 ‘앱 배터리 사용 비율’은 휴대전화의 배터리 감소율과 다릅니다. 예를 들어 배터리가 총 10%p 줄어든 동안 특정 앱이 해당 시간의 배터리 사용량 중 30%를 차지했다고 해서, 그 앱 때문에 배터리가 30%p 감소했다는 뜻은 아닙니다. 일부 시스템은 VPN 전달 과정에서 발생한 네트워크 활동을 프록시 앱에 포함하기도 하므로, 배터리 사용량을 분류하는 방식은 기기마다 다를 수 있습니다.

한 번에 한 항목만 변경하세요

1. 시스템의 ‘설정’ → ‘배터리’ → ‘배터리 사용량 세부정보’ 또는 ‘배터리 사용량’에서 시작 배터리 잔량, 클라이언트의 백그라운드 실행 시간, 네트워크 유형을 기록합니다.
2. 같은 Wi-Fi와 비슷한 시작 배터리 잔량을 사용하고, 시스템 업데이트·클라우드 사진 백업·대용량 다운로드를 중지한 뒤 화면을 잠근 상태로 60분간 관찰합니다.
3. 종료 시 배터리 잔량, 연결 끊김 여부, 발열 여부와 클라이언트의 송수신 데이터량을 기록합니다. 트래픽 통계를 확인할 메뉴가 없다면 시스템의 앱 데이터 사용량을 확인하세요.
4. 예를 들어 속도 테스트 간격을 60초에서 600초로 바꾸는 식으로 한 가지 변수만 수정한 뒤 같은 방식으로 관찰합니다. 일시적인 네트워크 변동을 결론으로 오인하지 않도록 최소 두 차례 반복하세요.

여기서 60분은 테스트 시간을 제안한 것이며, 실제 기기에서 측정한 결과가 아닙니다. 배터리 잔량은 정수로 표시되므로 짧은 시간에는 차이가 드러나지 않을 수 있습니다. 더 오래 관찰하려면 야간 대기 테스트를 추가로 진행하세요. 모바일 네트워크와 Wi-Fi는 각각 비교해야 합니다. 신호가 약해 반복해서 재연결할 때 발생하는 배터리 소모를 모두 프록시 코어 탓으로 돌릴 수는 없습니다.

속도 테스트 및 상태 확인: 반복 탐색부터 줄이기

‘전체 속도 테스트’를 한 번 수동으로 누르는 것은 보통 단일 작업으로 끝납니다. 반면 그룹의 자동 테스트와 프록시 모음의 상태 확인은 주기적으로 실행될 수 있습니다. 구독에 url-test 또는 fallback 그룹이 여러 개 있고 상태 확인이 활성화된 proxy-providers도 포함되어 있다면, 화면의 스위치 하나만 보지 말고 각 항목의 테스트 범위를 확인하세요.

60초에서 600초로 바꾼다는 의미

후보 노드가 30개인 그룹이 60초마다 각 노드를 한 번씩 테스트한다고 가정하면, 한 시간 동안 약 1,800회 탐색이 발생합니다. 간격을 600초로 바꾸면 약 180회입니다. 이는 실행 빈도를 이해하기 위한 대략적인 계산입니다. 실제 횟수는 지연 실행, 시간 초과, 연결 재사용, 코어 구현에 따라 달라지며 배터리 소모가 같은 비율로 줄어든다는 뜻은 아닙니다.

아래는 mihomo 프록시 모음의 일부 설정 예시입니다. 상태 확인 옵션만 보여 주며, 그대로 가져와 사용할 수 있는 전체 구독 설정은 아닙니다.

health-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600
  timeout: 5000
  lazy: true

• interval: 600의 단위는 초이고 timeout: 5000의 단위는 밀리초입니다. 단위를 혼동하지 마세요.
• lazy: true를 설정하면 해당 프록시 모음을 사용하지 않을 때 주기적인 확인을 건너뛸 수 있습니다. 구체적인 동작은 사용 중인 코어 구현에 따라 다르며, 모든 네트워크 요청이 중지되는 것은 아닙니다.
• 예시의 테스트 주소는 현재 네트워크와 프록시 출구에서 접속할 수 있어야 합니다. 계속 시간 초과가 발생한다면 간격을 줄여 반복 재시도하기보다 주소에 접속할 수 있는지 확인하세요.
• 노드를 직접 선택할 수 있는 select 그룹에서는 먼저 수동으로 속도 테스트를 실행한 뒤 노드를 선택할 수 있습니다. 대신 장애가 발생하면 직접 노드를 바꿔야 할 수 있습니다.

자동 장애 전환과 테스트 빈도 사이에는 절충이 필요합니다. 600초는 관찰을 시작하기 위한 참고값일 뿐, 모든 네트워크에 적합하다고 보장할 수 없습니다. 구독 관리자가 업데이트할 때 로컬 변경 사항을 덮어쓸 수도 있으므로, 클라이언트의 오버라이드 또는 영구 설정 기능을 우선 사용하고 업데이트 후 최종 적용 설정을 확인하세요.

DNS·규칙·로그: 비정상적인 재시도 확인하기

DNS 조회는 정상적인 네트워크 활동입니다. 점검이 필요한 경우는 같은 도메인의 조회가 계속 실패하거나, 암호화 DNS가 연결되지 않거나, DNS 요청의 출구가 아직 끝나지 않은 DNS 조회에 의존해 재시도가 반복되는 상황입니다. 이때 연결 화면에 같은 대상이 계속 표시되고 로그에도 시간 초과나 조회 실패가 반복될 수 있습니다.

다음 순서로 확인하세요

1. 클라이언트의 ‘로그’ 페이지에서 임시로 info 수준을 선택하고 1~2분간 확인해, 반복 오류가 DNS·노드 연결·상태 확인 중 어디에서 발생하는지 파악합니다.
2. DNS 업스트림 주소, 선택한 프록시 노드와 관련 라우팅에 접속할 수 있는지 확인하세요. DNS 요청이 프록시를 거치도록 설정되어 있다면, 먼저 해당 프록시가 연결되는지 확인해야 합니다.
3. mihomo를 사용하고 respect-rules를 활성화했다면 코어 문서에서 proxy-server-nameserver 설정 요구사항을 확인하세요. 프록시 노드 도메인의 조회가 프록시 자체에 의존하는 상황을 피할 수 있습니다.
4. 계속 출력되는 debug 로그를 끄세요. 문제를 확인한 뒤에는 클라이언트 기본 수준으로 되돌리거나, 지원되는 경우 warning을 사용하세요.

배터리를 아끼려고 DNS 모드, 업스트림 서버, 전체 규칙을 한꺼번에 바꾸지 마세요. 어떤 설정이 영향을 주었는지 파악하기 어려워집니다. fake-ip는 DNS와 연결 매핑 방식이지 별도의 배터리 절약 스위치가 아닙니다. redir-host가 더 적은 배터리를 사용한다고 보장할 수도 없습니다. 먼저 클라이언트와 호환되는 설정을 사용하고 구체적인 오류를 해결하세요.

규칙 수만으로 문제를 판단해서도 안 됩니다. 규칙이 많다는 이유로 중요한 규칙을 삭제하면, 원래 직접 연결되던 대용량 트래픽이 프록시를 거치게 되어 처리 부담이 늘어날 수 있습니다. 필요한 트래픽만 분기하면 불필요한 전달을 줄일 수 있지만, 변경 후에는 규칙 이름만 믿지 말고 앱의 실제 연결 경로를 확인하세요.

배터리 최적화 제외 및 제조사별 백그라운드 실행 설정

화면을 잠근 뒤에도 인터넷 연결을 유지해야 하는 경우에만 백그라운드 제한을 단계적으로 해제하세요. 먼저 클라이언트의 배터리 설정을 백그라운드 실행 허용으로 바꾸고 화면 잠금 테스트를 진행합니다. 그래도 앱이 종료된다면 자동 실행과 최근 앱 고정을 확인하세요. 아래는 일반적인 설정 경로입니다. 시스템 버전, 지역, 기종에 따라 메뉴 이름이 다를 수 있습니다. 메뉴를 찾지 못하면 설정에서 ‘배터리 최적화’, ‘자동 실행’, ‘백그라운드 활동’을 검색하세요.

최근 앱 화면에서 앱을 ‘잠금’하는 것은 보조 조치일 뿐, 배터리 최적화 제외 목록에 추가하는 것과 같지 않으며 모든 시스템 제한을 해제하지도 않습니다. 전체 절전 모드, 초절전 모드, 시스템 정리 도구, 백그라운드 데이터 제한은 여전히 VPN 서비스에 영향을 줄 수 있습니다. 항목별로 확인하고 휴대전화의 배터리 관리를 전부 끄지는 마세요.

상시 알림과 VPN·TUN 모드의 차이

안드로이드 클라이언트는 보통 시스템의 VpnService로 가상 네트워크 인터페이스를 만들고, 조건에 맞는 앱 트래픽을 코어에 전달해 처리합니다. 시스템 프록시 주소로 연결하는 데스크톱 방식과 다르므로 데스크톱의 ‘TUN을 끄고 시스템 프록시만 사용’하는 설정을 안드로이드에 그대로 적용할 수 없습니다. 안드로이드의 VPN 아이콘도 특정 원격 프록시 프로토콜을 사용 중이라는 뜻은 아닙니다.

서비스 알림은 유지하고 잦은 새로 고침 줄이기

계속 실행되는 VPN 서비스는 일반적으로 포그라운드 서비스 알림을 표시합니다. 고정된 알림 자체는 주된 배터리 소모 원인이 아닙니다. 초당 속도 갱신, 통계의 지속적인 계산, 반복적인 로그 출력은 점검해 볼 만한 추가 작업입니다. 클라이언트에 ‘실시간 트래픽’, ‘알림 속도’, ‘새로 고침 간격’ 설정이 있다면 먼저 실시간 속도를 끄거나 1초 간격을 5초로 바꾼 뒤 차이를 확인하세요.

알림을 강제로 차단해 정상적인 백그라운드 설정을 대신하지 마세요. Android 13 이상에서 알림 권한, VPN 서비스 상태, 제조사별 백그라운드 유지 설정은 서로 다른 항목이며, 알림을 숨겨도 서비스가 중지된다고 보장할 수 없습니다. 서비스가 계속 실행 중인지 확인하려면 클라이언트의 서비스 상태와 시스템 VPN 화면을 확인하세요.

‘항상 켜져 있는 VPN’은 신중하게 사용하세요

일부 시스템에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’에서 클라이언트 옆의 설정 버튼을 눌러 ‘항상 켜져 있는 VPN’을 켤 수 있습니다. 이 기능은 VPN 사용 정책을 유지하기 위한 것이며 배터리 절약 기능도, 노드 장애 해결 방법도 아닙니다. ‘VPN 연결 없이 차단’을 켜면 VPN을 사용할 수 없을 때 해당 네트워크 연결이 차단됩니다. 인터넷이 끊길 수 있다는 점을 감수할 수 있는지 확인한 뒤 사용하세요.

일반적인 사용 환경에서는 활성 VPN 서비스를 하나만 사용할 수 있는 경우가 대부분입니다. 로컬 VPN 광고 차단 앱, 패킷 캡처 도구, 다른 VPN 클라이언트가 프록시 클라이언트와 서로 연결을 대체할 수 있습니다. 서비스가 계속 끊긴다면 백그라운드 권한을 더 늘리기 전에 이러한 충돌부터 확인하세요.

변경 사항 확인 및 되돌리기

우선순위는 다음과 같습니다. 먼저 비정상적인 트래픽과 오류를 확인하고, 반복되는 속도 테스트와 로그 부하를 줄인 다음, 화면 잠금 후 연결이 끊기는지에 따라 백그라운드 실행 설정을 조정하세요. 대기 중 안정성이 목표라면 배터리만 보지 말고 필요한 앱이 제때 인터넷에 연결되는지도 함께 확인해야 합니다.

• 대기: 같은 네트워크에서 60분간 비교하고 시작·종료 배터리 잔량과 트래픽을 기록하세요. 시스템의 앱 배터리 사용 순위만 비교하지 마세요.
• 네트워크 전환: Wi-Fi에서 모바일 데이터로 전환한 뒤 다시 Wi-Fi로 돌아와 클라이언트 연결이 복구되는지, 로그에 오류가 계속 기록되는지 확인하세요.
• 화면 잠금: 평소 필요한 메시지 수신, 동기화, 웹 연결이 되는지 확인하세요. 백그라운드 앱 자체에도 시스템 제한이 적용될 수 있습니다.
• 설정 업데이트: 구독을 업데이트한 뒤 상태 확인 간격, DNS, 로그 수준을 다시 확인하고 영구 오버라이드가 적용 중인지 확인하세요.
• 되돌리기: 테스트 간격을 늘려 장애 전환이 너무 느려졌다면 더 짧은 간격으로 되돌리세요. 배터리 최적화 제외로 안정성이 개선되지 않았다면 불필요한 권한을 다시 제한하세요.

업무 트래픽이 거의 없는데도 기기가 눈에 띄게 뜨거워진다면 클라이언트 버전, 코어 버전, 시스템 버전과 짧은 오류 로그를 기록해 해당 프로젝트에 문의하세요. 로그를 공개하기 전에는 구독 주소, 토큰, 노드 인증 정보, 개인 접속 기록을 삭제하세요. 설정 가져오기와 기본 사용법은 사용 가이드를, 자주 발생하는 연결 문제는 FAQ 문제 해결 안내를 확인하세요.