모바일 Clash 배터리 소모가 빠를 때: 백그라운드 유지와 절전 설정

먼저 배터리 소모와 백그라운드 연결 끊김을 구분하세요

먼저 두 가지를 확인하세요. 시스템 배터리 사용량을 살펴보고, 화면을 잠근 뒤 연결 상태를 기록합니다. 발열이 계속되거나 백그라운드 데이터 사용량이 늘어나는 문제와 화면을 잠근 뒤 프록시 연결이 끊기는 문제는 원인이 다릅니다. 앞의 두 경우에는 실제 네트워크 활동을 줄여야 하고, 연결이 끊기는 경우에는 백그라운드 제한을 확인해야 합니다. 절전 제한을 모두 해제하면 연결이 유지될 수 있지만, 기존의 잦은 노드 검사까지 계속되어 배터리 소모가 늘어날 수 있습니다.

Android 모바일 클라이언트는 보통 시스템 VPN 인터페이스를 통해 트래픽을 처리하고, mihomo 같은 코어가 설정을 해석해 규칙을 적용하고 연결을 관리합니다. iOS 클라이언트는 대개 Network Extension의 터널 확장을 사용합니다. VPN 아이콘은 터널이 연결되어 있다는 뜻일 뿐, 휴대전화가 계속 높은 부하로 작동한다는 의미는 아닙니다. 아이콘만으로 배터리 소모 원인을 판단할 수도 없습니다.

나중에 다시 확인할 수 있도록 기준을 기록하세요

휴대전화 모델, 운영체제 버전, 클라이언트 버전, 코어 버전을 기록하세요. 코어 정보는 보통 클라이언트의 ‘정보’ 메뉴나 실행 로그에서 확인할 수 있습니다. 메뉴 이름은 사용하는 앱에 따라 다를 수 있습니다.
같은 Wi-Fi, 같은 노드, 같은 규칙 모드를 유지하고 시스템 업데이트, 사진 백업, 대용량 파일 다운로드는 일시 중지하세요.
화면을 잠근 상태로 60분간 관찰하고, 시작·종료 배터리 잔량, 연결 끊김 여부, 클라이언트의 백그라운드 트래픽, 로그에 기록된 재연결 횟수를 적어 두세요.
한 번에 한 종류의 설정만 바꾸고 다시 관찰하세요. 최소 두 차례 반복해 배터리 잔량 표시가 정수 단위로 바뀐 것을 확정적인 결과로 오해하지 않도록 합니다.

예를 들어 한 차례는 80%에서 77%로, 다른 차례는 80%에서 78%로 줄었다면 각 관찰에서 3%포인트와 2%포인트 감소했다는 뜻입니다. 이는 기록 방법을 보여 주는 예시이며, 이 사이트에서 측정한 결과가 아닙니다. 짧은 시간 동안의 차이는 신호 상태, 온도, 배터리 잔량 추정의 영향을 받을 수 있습니다.

Android 백그라운드 유지: 필요한 클라이언트만 예외로 설정하세요

먼저 기본 배터리 설정을 유지하세요. 화면을 잠가도 연결이 정상이라면 백그라운드 권한을 추가로 제한 없이 허용할 필요가 없습니다. 화면을 잠근 뒤 서비스가 종료되거나 VPN 아이콘이 사라지거나, 로그에 프로세스 재시작이 기록될 때만 클라이언트의 배터리 최적화 설정을 확인하세요.

기기에 맞는 배터리 설정 찾기

Pixel / 순정에 가까운 Android 14: 클라이언트 아이콘을 길게 누르기 → ‘앱 정보’ → ‘앱 배터리 사용량’ → ‘백그라운드 사용 허용’을 확인합니다. 일부 시스템에는 ‘제한 없음’, ‘최적화’, ‘제한’ 옵션이 표시됩니다.
삼성 One UI 6: ‘설정’ → ‘애플리케이션’ → 클라이언트 선택 → ‘배터리’ → ‘제한 없음’을 선택합니다. 이어서 ‘설정’ → ‘배터리’ → ‘백그라운드 사용 제한’을 확인하고, 클라이언트가 ‘절전 상태로 전환된 앱’ 목록에 포함되지 않도록 합니다.
기타 Android 기기: 앱 정보에서 ‘배터리 관리’, ‘백그라운드 실행’, ‘자동 시작’ 등의 항목을 찾아보세요. 제조사와 시스템 업데이트에 따라 메뉴 이름이 달라질 수 있으므로 다른 휴대전화의 경로를 그대로 따르기보다 실제 화면을 확인하세요.

자동 시작은 기기를 켜거나 프로세스가 종료된 뒤 다시 실행할 기회를 제어합니다. 배터리 최적화는 백그라운드 실행을 제한하고, 최근 앱 화면에서 앱을 잠그는 기능은 일부 제조사의 앱 정리 방식에만 영향을 줍니다. 서로 다른 설정이므로 하나씩 바꾸고 결과를 기록하세요. 인터넷을 사용하는 모든 앱을 한꺼번에 예외 목록에 추가하지 마세요.

VPN 상시 연결은 절전 설정이 아닙니다

Android의 ‘VPN 상시 연결’은 VPN 연결 정책을 유지하기 위한 설정입니다. ‘VPN 없이 연결 차단’은 터널을 사용할 수 없을 때 다른 네트워크 연결을 제한합니다. 둘 다 배터리 최적화 설정이 아니며, 노드 자체의 불안정 문제를 해결해 주지도 않습니다. 트래픽을 계속 VPN으로 처리해야 할 때만 켜고, 먼저 기기 재시작, 네트워크 전환, 화면 잠금 후 연결 복구 여부를 확인하세요.

iOS 백그라운드 앱 새로 고침: VPN 터널 설정과 분리해서 확인하세요

iOS 17 또는 iOS 18에서는 ‘설정’ → ‘일반’ → ‘백그라운드 앱 새로 고침’에서 앱 권한을 확인할 수 있습니다. 이 설정은 일반 앱이 백그라운드에서 새로 고침할 기회에 주로 영향을 주며 VPN 터널 전체를 켜고 끄는 스위치는 아닙니다. 트래픽을 처리하는 터널 확장은 클라이언트의 메인 앱과 작동 방식이 다릅니다. 백그라운드 앱 새로 고침을 꺼도 VPN 연결이 반드시 끊기는 것은 아니며, 켜도 터널이 계속 유지된다고 보장되지는 않습니다.

설정을 직접 가져오고 구독을 수동으로 업데이트한다면, 먼저 클라이언트 메인 앱의 백그라운드 앱 새로 고침을 끈 뒤 터널이 정상적으로 작동하는지 확인할 수 있습니다.
구독 자동 업데이트를 사용하는 경우 클라이언트가 해당 기능을 지원하는지, 백그라운드 앱 새로 고침이 필요한지, 시스템에서 실제로 어떤 조건일 때 실행을 허용하는지 확인하세요.
‘설정’ → ‘배터리’에서 활동 기록을 확인하세요. 저전력 모드를 켠 뒤 새로 고침 작업과 연결 복구에 영향이 있는지도 살펴보세요.

Android의 ‘백그라운드 앱 잠금’ 사용법을 iOS에 그대로 적용하지 마세요. 절전을 확인한다며 앱 전환 화면에서 클라이언트를 반복해서 쓸어 올려 종료하는 것도 피하세요. 메인 앱을 강제 종료하면 이후 백그라운드 작업에 영향을 줄 수 있으며, 터널 동작은 클라이언트 구현에 따라 다릅니다. 먼저 클라이언트 내부의 연결 스위치를 사용해 연결과 해제를 비교하세요.

필요할 때만 연결해 불필요한 온라인 시간을 줄이세요

클라이언트에 온디맨드 연결, 신뢰하는 Wi-Fi, 네트워크 변경 시 연결 같은 옵션이 있다면 먼저 어떤 네트워크에서 프록시가 필요한지 정한 뒤 조건을 설정하세요. 온디맨드 연결은 터널을 언제 만들지 관리하는 기능이지, 노드 검사 주기를 조정하는 기능이 아닙니다. 조건이 많거나 서로 충돌하면 네트워크를 전환할 때 연결이 반복될 수 있습니다. 먼저 조건 하나만 설정해 Wi-Fi와 셀룰러 간 전환을 확인한 뒤 다른 조건을 추가하세요.

노드 검사 간격: 일괄 검사와 중복 작업을 줄이세요

먼저 자동 전략 그룹과 프록시 제공자의 상태 확인 설정을 살펴보세요. 노드 40개를 60초마다 검사하고 한 번의 검사에 모든 노드가 참여한다고 가정하면 시간당 약 2,400회 검사하게 됩니다. 간격을 600초로 바꾸면 약 240회입니다. 이는 예정된 요청 횟수의 추정치입니다. 지연 검사, 실패 재시도, 구현 방식에 따라 실제 횟수는 달라지며 배터리 사용량으로 바로 환산할 수는 없습니다.

모바일에서 시작하기 좋은 url-test 설정

아래는 mihomo 전략 그룹 설정 예시이며 시간 단위는 초입니다. 노드 이름은 기존 설정에 있는 이름과 일치해야 합니다. 이 내용을 구독 설정 전체에 그대로 덮어쓰지 마세요. 다음 구독 업데이트 때 설정이 초기화되지 않도록 클라이언트에서 지원하는 덮어쓰기 또는 병합 기능을 사용하세요.

proxy-groups:
  - name: 모바일 자동 선택
    type: url-test
    proxies:
      - 일상용 노드
      - 예비 노드
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100
    lazy: true

interval: 600: 정기 노드 검사 간격을 10분으로 설정합니다. 절전 효과를 비교할 때 시작점으로 사용할 수 있지만, 모든 설정에 가장 적합한 값은 아닙니다.
tolerance: 100: 전환 허용 오차를 밀리초 단위로 설정해 지연 시간이 조금 바뀔 때마다 전환되는 일을 줄입니다. 연결 시간 초과 값은 아닙니다.
lazy: true: 그룹을 사용하지 않을 때 정기 검사를 줄입니다. 구체적인 작동 방식은 사용 중인 mihomo 버전에 따라 다릅니다.
url: 여기에는 검사 대상 주소를 입력하며 구독 주소가 아닙니다. 현재 네트워크에서 안정적으로 접속할 수 있는지 확인해 검사 대상의 장애를 모든 노드의 장애로 오인하지 않도록 하세요.

안정적인 노드를 하나만 사용한다면 먼저 수동 선택 그룹과 비교해 보세요. 자동 검사 간격을 줄이면서 클라이언트의 모든 노드 정기 검사까지 켜지 마세요. proxy-providers 아래의 health-check도 확인하세요. 전략 그룹 검사와 별도의 검사 작업이 함께 실행될 수 있습니다. 중복 작업을 줄인 뒤 연결 끊김 복구 필요성에 맞춰 간격을 조정하세요. 간격이 길어지면 장애를 발견하는 시점도 늦어질 수 있습니다.

구독과 규칙 세트: 내용이 바뀌는 주기에 맞춰 업데이트하세요

구독 업데이트, 프록시 제공자 업데이트, 규칙 세트 업데이트, 노드 검사는 서로 다른 작업입니다. 구독에는 전체 설정이 들어갈 수 있고, 프록시 제공자는 주로 노드 정보를 제공하며, 규칙 제공자는 규칙 데이터를 불러옵니다. 노드 검사는 노드 사용 가능 여부만 확인합니다. 모든 작업을 1분마다 실행해도 일상적인 편의가 그만큼 좋아지는 것은 아닙니다.

작업	비교 시작값	확인할 항목
전체 구독 업데이트	24시간마다 또는 수동	업데이트 후 설정이 자동 전환되거나 코어가 재시작되는지
노드 상태 확인	600초	모든 노드 검사도 동시에 실행되는지
원격 규칙 세트 업데이트	86400초	파일 크기, 실패 재시도, 리소스 수
실시간 로그와 대시보드	문제 해결 시 켜기	연결 목록과 트래픽 그래프가 계속 새로 고쳐지는지

이 값은 비교를 위한 출발점이지 모든 서비스에 일괄 적용할 기준은 아닙니다. 노드가 자주 바뀌는 구독은 업데이트 간격을 줄이고, 변경이 적은 규칙 세트는 하루 한 번 업데이트해도 됩니다. mihomo의 HTTP 유형 rule-providers에서 interval: 86400은 24시간을 뜻합니다. 클라이언트의 전체 구독 자동 업데이트 간격은 분 또는 시간 단위를 사용할 수 있으므로 설정 전에 화면에 표시된 단위를 확인하세요.

문제 원인을 찾는 데 필요한 로그만 보관하세요

평소에는 log-level: warning을 사용하고, 연결 끊김 원인을 확인할 때만 info로 잠시 바꾼 뒤 재현 후 원래대로 돌리세요. debug를 계속 사용하면 로그 생성과 처리에 드는 부하가 늘어납니다. 실시간 연결 대시보드를 장시간 켜 두면 화면 새로 고침 작업도 증가합니다. 로그를 줄이기 전에 중요한 오류 기록을 저장하세요. 기록이 없으면 인증 실패, DNS 시간 초과, 터널 재시작 중 무엇이 원인인지 확인하기 어렵습니다.

TUN, DNS, 약한 신호: 실제 트래픽이 발생하는 곳을 확인하세요

모바일 VPN 트래픽 처리를 데스크톱의 시스템 프록시 스위치와 똑같이 볼 수는 없습니다. 앱별 우회가 가능한지, TUN 옵션이 표시되는지는 클라이언트와 플랫폼 기능에 따라 다릅니다. Android 일부 클라이언트는 앱별 분할 라우팅을 지원해 프록시가 필요하지 않은 앱을 우회시킬 수 있습니다. 일반적인 개인용 VPN 환경에서 iOS는 Android의 앱 제외 목록을 그대로 사용할 수 없습니다.

먼저 대용량 트래픽이 어느 앱에서 발생하는지 확인한 뒤 규칙이 어떻게 적용되는지 살펴보세요. 동영상 자동 재생, 클라우드 저장소 동기화, 시스템 다운로드는 클라이언트가 직접 노드를 검사하지 않아도 무선 네트워크를 계속 사용해 배터리를 소모할 수 있습니다. 해당 트래픽을 DIRECT로 보내면 불필요하게 원격 프록시를 거치는 경로를 줄일 수 있지만, VPN 처리를 완전히 우회하거나 데이터 전송을 중단하는 것은 아닙니다.

DNS 모드를 별도의 절전 스위치로 취급하지 마세요

DNS 중복 조회 실패, 시간 초과, 연결 재시도가 있는지 먼저 확인한 뒤 DNS 설정을 바꾸세요. 정상 작동하는 Fake-IP를 배터리 사용량 순위가 높다는 이유만으로 비활성화할 필요는 없습니다.
DNS 조회 경로를 명확히 유지하세요. 코어 DNS, 시스템 암호화 DNS, 다른 VPN 계열 도구를 함께 사용할 때는 접속할 수 없는 DNS 서버가 있거나 요청이 순환 전달되지 않는지 확인하세요.
네트워크를 전환한 뒤 연결이 한 번씩 다시 설정되는 것은 정상일 수 있습니다. 같은 네트워크에서 재시도가 계속된다면 노드 접속 가능 여부, DNS 조회 결과, 로그에 기록된 시간을 확인하세요.

셀룰러 신호가 약하면 무선 통신에 더 많은 전력이 들 수 있습니다. 프록시 프로토콜을 원인으로 오해하지 않도록 같은 장소에서 Wi-Fi와 셀룰러를 먼저 비교한 뒤 노드 두 개를 비교하세요. 지연 시간이 가장 짧은 노드가 반드시 배터리를 가장 적게 쓰는 것은 아닙니다. 한 번의 검사에서 나온 낮은 수치보다 안정적인 전송, 적은 재시도와 잦지 않은 노드 전환이 더 유용한 판단 기준입니다.

세 차례 비교로 백그라운드 유지와 절전의 균형을 찾으세요

1차: 백그라운드 작업 줄이기: 노드를 고정하고 노드 검사 간격은 600초, 규칙 세트 업데이트는 하루 한 번으로 설정합니다. 지속적인 디버그 로그를 끄고 시스템 배터리 설정은 그대로 둡니다.
2차: 백그라운드 제한 확인: 화면을 잠근 뒤 연결이 끊기는 경우에만 Android 클라이언트의 배터리 제한을 완화하세요. iOS에서는 메인 앱의 백그라운드 앱 새로 고침과 터널 연결 상태를 각각 확인합니다.
3차: 실제 사용량 확인: 평소 사용하는 앱을 다시 사용하면서 동영상 재생, 동기화, 셀룰러 데이터 사용량을 기록하고 해당 활동에 따라 배터리 소모가 늘어나는지 확인합니다.

화면을 잠근 상태의 연결 유지, 네트워크 전환 후 복구, 일상적인 인터넷 사용에 필요한 최소한의 백그라운드 작업만 남기세요. 발열이 계속되거나 짧은 시간에 데이터 사용량이 급증하거나 매분 재시작이 반복되면 먼저 연결을 중지하고 개인정보를 가린 로그를 저장한 뒤 문제 해결에서 원인을 확인하세요. 로그를 공유하기 전에 구독 주소, 토큰, 노드 비밀번호와 개인을 식별할 수 있는 정보를 삭제하세요.

클라이언트를 바꿀 때는 먼저 운영체제와 코어가 호환되는지 확인하세요. 클라이언트, 노드, 모든 규칙을 한꺼번에 바꾸지 마세요. 설정을 다시 해야 한다면 사용 가이드에 따라 하나씩 복원하고, 안정성을 확인한 설정을 비교용으로 보관하세요.