Android 프록시 배터리 소모 줄이기: 백그라운드 실행·배터리 최적화 예외·Clash 설정

먼저 구분하세요: 정상적인 트래픽 처리인지, 백그라운드에서 반복 재시작되는지

같은 조건에서 먼저 비교한 뒤 배터리 최적화 예외를 설정하세요. 휴대폰에서 프록시를 켜면 트래픽 전달, 암호화·복호화, 규칙 적용 과정이 추가되므로 배터리 소모가 늘어나는 것은 자연스럽습니다. 하지만 화면을 꺼도 계속 발열하거나, 몇 분마다 서비스가 재시작되거나, 모바일 네트워크 대기 중 배터리가 눈에 띄게 빨리 닳는다면 원인을 따로 확인해야 합니다. 모든 제한을 한꺼번에 해제하면 연결 끊김은 해결될 수 있지만, 배터리 소모 원인까지 사라졌다고 단정할 수는 없습니다.

Android용 Clash 클라이언트는 보통 VpnService로 로컬 VPN 인터페이스를 만든 다음, 선택한 앱의 트래픽을 코어에서 처리합니다. 이는 원격 VPN 서비스를 구매하는 것과는 다릅니다. 상태 표시줄에 열쇠 아이콘이 떠도 모든 연결이 원격 프록시 노드를 거친다는 뜻은 아닙니다. 규칙에 따라 DIRECT로 연결되는 트래픽도 로컬에서 전달될 수 있으며, 이 경우 원격 노드는 거치지 않습니다.

대기 상태 기록 두 건으로 기준을 잡으세요

“어제는 프록시를 켜고 오늘은 끈” 하루 전체 배터리 사용량을 비교해 결론을 내리지 마세요. 앱 업데이트, 신호 변화, 화면 밝기도 결과에 영향을 줍니다. 아래 방법으로 짧게 비교한 뒤 테스트를 연장할지 결정하세요.

1. 환경 기록: 휴대폰 모델, Android 버전, 클라이언트 및 코어 버전, Wi-Fi 또는 모바일 네트워크, 시작·종료 시 배터리 잔량을 적어 둡니다. 버전 정보는 보통 클라이언트의 ‘정보’ 페이지에서 확인할 수 있습니다.
2. 조건 고정: 같은 Wi-Fi와 장소를 사용하고 배터리 잔량도 비슷한 구간으로 맞춥니다. 시스템 업데이트, 클라우드 사진 백업, 대용량 다운로드는 잠시 중지하고, 충전하면서 테스트하지 마세요.
3. 첫 번째 테스트: 프록시 끄기: VPN 서비스가 중지됐는지 확인한 뒤 화면을 끄고 60분간 대기합니다. 배터리 잔량과 백그라운드 네트워크 활동을 기록하세요.
4. 두 번째 테스트: 프록시 켜기: 앱 상태는 그대로 유지하고 노드와 규칙 모드를 고정한 뒤 60분간 대기합니다. ‘전체 속도 테스트’는 함께 실행하지 마세요.
5. 한 번에 하나만 변경하고 재테스트: 예를 들어 먼저 상태 확인 간격만 늘리고 나머지 설정은 그대로 둡니다. 시스템이 배터리 잔량을 반올림해 표시할 수 있으므로 최소 한 번 더 반복해 최적화 효과를 확인하세요.

예를 들어 프록시를 끈 상태에서 80%에서 79%로, 켠 상태에서 80%에서 77%로 줄었다면, 두 번의 테스트에서 2%p 차이가 났다고만 볼 수 있습니다. 이 결과로 모든 휴대폰의 하루 배터리 소모량을 추정할 수는 없습니다. 기록 방법을 보여 주기 위한 예시이며 실제 클라이언트 측정값이 아닙니다. 한 시간 동안 차이가 거의 보이지 않으면 3시간으로 늘려 보세요. 모바일 네트워크 신호가 약한 환경은 별도로 테스트하고 Wi-Fi 결과와 섞지 마세요.

백그라운드 실행: 필요한 경우에만 배터리 최적화 예외 설정

배터리 최적화 예외는 백그라운드 종료를 줄이는 설정이지, 배터리를 절약하는 기능이 아닙니다. 화면을 끈 뒤 연결이 끊기거나 서비스가 정리되거나 반복해서 시작되는 경우에 우선 조정하세요. 알림이 계속 표시된다는 이유만으로 클라이언트가 높은 부하로 작동한다고 볼 수는 없습니다. 코어가 반복 초기화되는지, 연결이 자주 다시 만들어지는지 확인하는 편이 좋습니다.

Android 14 설정 경로 예시

순정 Android에 가까운 Android 14를 예로 들면, ‘설정’ → ‘앱’ → ‘모든 앱 보기’ → Clash 클라이언트 → ‘앱 배터리 사용량’으로 이동해 ‘제한됨’으로 설정되어 있는지 확인할 수 있습니다. 프록시를 계속 사용해야 한다면 ‘제한 없음’을 테스트해 보세요. 시스템 업데이트에 따라 ‘백그라운드 사용 허용’ 등으로 표시될 수 있으므로 실제 기기의 메뉴를 기준으로 확인하세요.

• 제조사 배터리 관리: 설정에서 ‘배터리 최적화’, ‘백그라운드 활동’ 또는 ‘자동 시작’을 검색하세요. 시스템에 앱 시작 관리 기능이 따로 있다면 장시간 프록시를 사용할 클라이언트에만 권한을 허용하면 됩니다. 모든 앱의 제한을 해제할 필요는 없습니다.
• 최근 앱 잠금: 일부 시스템에서는 최근 앱 화면에서 앱 카드를 잠글 수 있습니다. 직접 앱을 정리할 때 실수로 종료하는 일을 줄일 수 있지만, Android 공통의 백그라운드 실행 보장 기능은 아니며 배터리 설정을 대신하지도 않습니다.
• 알림과 서비스 상태: 클라이언트 실행 상태를 확인할 수 있도록 설정하세요. Android 13 이상에서는 알림 권한과 포그라운드 서비스 실행이 별개의 설정입니다. 알림이 사라졌다는 이유만으로 VPN 서비스가 중지됐다고 판단하면 안 됩니다.
• 배터리 절약 모드: 먼저 문제가 시스템 배터리 절약 모드에서만 발생하는지 확인하세요. 테스트 중에는 설정을 동일하게 유지하고, 한쪽 테스트에서만 절약 모드를 켜거나 끄지 마세요.

‘항상 켜짐 VPN’이 필요한지 확인하세요

순정 Android 스타일의 시스템에서는 보통 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’으로 이동한 뒤 해당 설정 옆의 톱니바퀴 버튼을 누릅니다. 클라이언트가 지원하면 ‘항상 켜짐 VPN’과 ‘VPN 없이 연결 차단’ 옵션이 표시될 수 있습니다. 후자는 VPN을 사용할 수 없을 때 네트워크를 차단하는 기능이지, 노드 안정성을 높이는 옵션이 아닙니다. 켜기 전에 연결이 끊겼을 때 어떻게 동작하는지 확인하세요. 시스템이 의도대로 트래픽을 차단한 상황을 DNS 오류로 오해하지 마세요.

Android에서는 보통 사용자 또는 업무 프로필마다 VpnService 기반 서비스를 하나만 실행할 수 있습니다. VPN 방식의 방화벽, 필터링 앱 또는 프록시 앱을 다른 앱에서 시작하면 현재 서비스가 대체될 수 있습니다. 연결이 번갈아 끊긴다면 백그라운드 권한을 더 추가하기 전에 이런 앱이 동시에 실행 중인지 확인하세요.

상태 확인: 먼저 탐색 횟수를 줄이고, 그다음 노드 변경을 고려하세요

노드 상태 확인은 실제 네트워크 요청을 발생시킵니다. 노드가 많고 확인 간격이 짧으면 무선 네트워크가 깨어나는 횟수와 연결 활동이 늘어날 수 있습니다. 특히 모바일 네트워크에서는 짧은 요청을 자주 보내면 무선 모듈이 더 오랫동안 활성 상태를 유지할 수 있습니다. 실제 영향은 네트워크와 기기에 따라 다르므로 요청 한 건의 데이터 양만으로 판단할 수 없습니다.

mihomo에서 프록시 제공자의 상태 확인 설정은 proxy-providers 아래의 health-check에 있습니다. 아래는 기존 제공자 정의에 추가하는 일부 설정이며 전체 설정이 아닙니다. mobile-pool은 기존 제공자 이름으로 바꿔야 하며, 기존의 유형, 주소, 경로 등 필드는 그대로 유지해야 합니다.

proxy-providers:
  mobile-pool:
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

• interval: 600: 상태 확인 간격을 600초로 설정합니다. 우선 300~600초로 설정해 변화를 살펴보세요. 최신 지연 시간을 확인하려고 수십 초마다 점검할 필요는 없습니다.
• lazy: true: 제공자 노드를 사용하지 않을 때는 주기적인 상태 확인을 건너뜁니다. 노드가 사용 중으로 판단되는지는 정책 그룹 참조 여부와 실제 사용 상태에 따라 달라집니다.
• url: 현재 네트워크에서 연결할 수 있고 응답이 가벼운 테스트 주소를 선택하세요. 주소에 연결할 수 없으면 잘못 판단할 수 있으며, 확인 간격을 줄여도 해결되지 않습니다.

대략적인 규모를 계산해 보겠습니다. 한 번 확인할 때 노드 50개를 점검하고 간격이 60초라면, 이론상 한 시간에 최대 약 3,000회의 노드 확인을 예약할 수 있습니다. 간격을 600초로 늘리면 약 300회가 됩니다. 이 계산으로 실제 배터리 소모 배수를 알 수 있는 것은 아니며, 지연 실행, 시간 초과, 다른 정책 그룹의 점검도 반영하지 않았습니다. 다만 설정에서 중복 작업이 발생하는지 파악하는 데 도움이 됩니다.

url-test, fallback 같은 정책 그룹 자체의 interval과 클라이언트의 자동 일괄 속도 테스트 설정도 확인하세요. 제공자 상태 확인과 정책 그룹 점검이 동시에 실행될 수 있습니다. proxy-providers의 interval은 구독 내용 업데이트 간격이고, 여기서 말하는 상태 확인 간격은 health-check.interval입니다. 계층을 혼동해 잘못 수정하지 마세요.

DNS와 연결 재시도: 반복 요청의 원인 해결하기

DNS 업스트림을 많이 추가한다고 항상 안정성이 높아지는 것은 아닙니다. 특정 업스트림에 계속 연결할 수 없거나, DNS 조회가 아직 완료되지 않은 프록시 연결에 의존하면 앱이 계속 재시도할 수 있습니다. 로그에 i/o timeout, context deadline exceeded가 연속으로 나타나면 해당 도메인, 대상 주소, 발생 시각을 기록하세요. 이런 오류는 연결이나 상태 확인 과정에서도 발생할 수 있으므로, 오류 문구만 보고 DNS 문제라고 단정하면 안 됩니다.

1. 예상한 경로만 사용 중인지 확인: 클라이언트 DNS, Android의 ‘비공개 DNS’, 다른 필터링 앱을 확인하세요. 순정 Android에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘비공개 DNS’에서 확인할 수 있습니다. 세 곳을 동시에 바꾸지 마세요.
2. 비공개 DNS를 잠시 비교: 사용자 지정 제공자 호스트 이름을 설정했다면 기존 값을 기록하고 잠시 ‘자동’으로 전환해 현재 VPN 경로와 충돌하는지 확인하세요. 테스트가 끝나면 필요한 설정으로 되돌리세요.
3. mihomo 필드 확인: dns.nameserver는 기본 DNS 업스트림이고, dns.proxy-server-nameserver는 프록시 노드 도메인 조회에 사용됩니다. 후자를 사용할지는 기존 설정과 코어 문서를 확인해 결정하세요. 무조건 추가하지 마세요.
4. 반복 요청의 원인 확인: 같은 앱이 실패하는 도메인에 계속 접속한다면 캐시를 반복해서 비우기보다 실제로 적용되는 규칙, 노드의 연결 경로, DNS 조회 결과를 먼저 확인하세요.

fake-ip와 redir-host는 DNS 처리 방식이지 배터리 절약 모드가 아닙니다. 모드를 바꾸면 앱 호환성이나 캐시 동작이 달라질 수 있지만 배터리가 덜 소모된다고 보장할 수는 없습니다. 기존에 웹사이트가 정상적으로 열린다면 배터리 절약만을 이유로 DNS 설정을 크게 바꾸지 마세요. 명확한 시간 초과와 반복 요청부터 해결하는 것이 좋습니다.

규칙, TUN, 로그: 불필요한 처리 줄이기

규칙 모드에서도 트래픽은 로컬 VPN을 거칩니다

mode: rule은 규칙에 따라 연결 경로를 선택하며, DIRECT는 원격 프록시 노드를 거치지 않는다는 뜻입니다. 앱 트래픽이 Android 로컬 VPN으로 들어갔다면 여전히 코어에서 처리될 수 있습니다. 따라서 “규칙 모드로 바꾸면 배터리를 쓰지 않는다”고 할 수는 없습니다. 다만 모든 트래픽을 불필요하게 원격으로 보내는 대신 적절히 직접 연결하면 추가 연결과 일부 암호화 작업을 줄일 수 있습니다.

클라이언트에 ‘앱별 프록시’ 또는 ‘앱 제외’ 기능이 있다면 필요에 따라 프록시가 처리하는 앱 범위를 줄일 수 있습니다. 단, 해당 화면이 허용 목록인지 제외 목록인지 먼저 확인하세요. 두 방식은 의미가 반대입니다. 앱을 제외하면 일반적으로 해당 앱의 네트워크 연결은 이 프록시 규칙의 제어를 받지 않으므로, 조정 전에 연결 요구 사항을 확인하세요.

데스크톱 TUN의 배터리 절약 방법을 그대로 적용하지 마세요

휴대폰은 원래 VPN 인터페이스로 트래픽을 처리하는 경우가 많으므로, 데스크톱에서 쓰는 ‘TUN을 끄고 시스템 프록시만 사용’하는 방법을 Android의 공통 대안으로 보면 안 됩니다. 다른 작동 모드를 지원하는지는 클라이언트에 따라 다릅니다. tun.stack의 선택값과 동작도 코어 및 통합 방식에 따라 달라지므로 이름만 보고 선택하지 마세요. 같은 네트워크와 작업 부하에서 호환성과 배터리 소모를 테스트해야 합니다.

문제 해결 후 일반 로그 수준으로 복원하세요

상세 로그를 오래 유지하면 처리와 저장에 추가 부담이 생깁니다. 원인을 찾을 때만 잠시 상세 로그를 켜고, 문제가 재현되면 필요한 부분을 내보낸 뒤 최종 설정의 log-level을 info 또는 클라이언트의 기존 수준으로 되돌리세요. 대기 상태 비교 중에는 실시간 연결 새로고침, 반복 속도 테스트, 로그 자동 스크롤 화면을 백그라운드에서 계속 실행하지 마세요.

설정 변경 후 확인 순서

아래 순서대로 마무리하세요. 배터리 사용량 순위의 특정 숫자만 낮추는 것이 아니라 백그라운드에서 안정적으로 작동하는지, 인터넷이 정상적으로 연결되는지, 대기 중 소모량이 적절한지 함께 확인해야 합니다.

1. 먼저 백그라운드 확인: 화면을 끄고 30분 뒤 다시 켠 다음 VPN 서비스가 계속 실행 중인지, 네트워크가 정상적으로 복구되는지, 로그에 반복 시작 기록이 있는지 확인하세요.
2. 그다음 설정 확인: 상태 확인 간격이 최종 설정에 적용됐는지, 자동 일괄 속도 테스트가 다시 시작되지 않았는지, 구독 업데이트 후에도 수정 내용이 유지되는지 확인하세요.
3. 배터리 재측정: 앞서 안내한 60분간의 동일 조건 테스트로 배터리 감소량과 비정상 연결을 기록하세요. 결과 편차가 크면 설정을 계속 추가하기보다 테스트 시간을 늘리세요.
4. 마지막으로 평소 설정 복원: 임시 상세 로그를 끄고 필요하지 않은 테스트 권한을 되돌리세요. 백그라운드 안정성에 실제로 필요한 설정만 유지하면 됩니다.

모바일 네트워크에서 Wi-Fi보다 배터리가 훨씬 빨리 닳는다면 신호 품질과 노드 경로부터 확인하세요. 특정 노드에서만 계속 시간 초과가 발생한다면 사용 가능한 노드로 고정해 다시 측정하세요. 클라이언트를 바꿔도 문제가 계속되면 시스템 네트워크와 백그라운드 앱을 다시 확인해야 하며, 특정 코어의 문제라고 바로 단정해서는 안 됩니다.

가져오기 절차를 다시 확인하려면 사용 안내를 참고하세요. 오버라이드 미적용, DNS 시간 초과, 예상과 다른 규칙 연결 경로가 문제라면 고급 설정에서 항목별로 확인할 수 있습니다. 로그를 공유하기 전에 구독 주소, 액세스 토큰, 노드 비밀번호, 개인 연결 기록을 삭제하세요.