Clash 모바일 배터리 소모 문제 해결: 백그라운드 실행, 상태 점검 간격, 절전 설정

트래픽 전달에 따른 소모와 대기 중 비정상 소모를 구분하세요

휴대폰에서 Clash를 켜면 시스템 배터리 사용량 목록에서 VPN 클라이언트의 비중이 커질 수 있습니다. 그렇다고 클라이언트가 계속 높은 부하로 작동한다는 뜻은 아닙니다. Android의 트래픽 사용량과 배터리 소모 추정치는 VPN을 통한 전달의 영향을 받습니다. 동영상 재생, 다운로드, 동기화에서 발생한 네트워크 부하 일부가 VPN 앱의 사용량으로 집계될 수 있습니다. 문제를 판단할 때는 앱 순위만 보지 말고 전체 배터리 소모량, 화면 사용 시간, 네트워크 종류, 클라이언트 로그를 함께 확인하세요.

이 글은 Clash Meta for Android 또는 Mihomo 커널을 사용하는 다른 Android 클라이언트를 대상으로 합니다. Clash Verge Rev는 데스크톱 클라이언트이므로 서비스 모드나 시스템 프록시 메뉴를 휴대폰에 그대로 적용할 수 없습니다. Android는 일반적으로 VpnService로 로컬 VPN 인터페이스를 만들어 트래픽을 처리합니다. 다른 플랫폼은 백그라운드 작동 방식과 메뉴가 다르며, 아래의 Android 배터리 설정은 iOS에 적용되지 않습니다.

비교할 수 있도록 배터리 사용량 기록하기

같은 네트워크에서 세 가지 조건 비교하기

먼저 Android에서 「설정」→「배터리」→「배터리 사용량」을 확인한 뒤 해당 클라이언트의 앱 상세 정보로 이동하세요. 시스템에 따라 메뉴가 「배터리 사용량 순위」 또는 「앱 배터리 관리」로 표시될 수 있습니다. 전면 실행 시간, 백그라운드 실행 시간, 테스트 시작·종료 시 배터리 잔량을 기록하세요. 시스템에서 모바일 네트워크 활성 시간을 제공한다면 함께 기록합니다.

1. 기준 조건: 프록시 서비스를 중지하고 안정적인 Wi-Fi에 연결한 상태로 화면을 60분간 잠근 뒤 전체 배터리 잔량 변화를 기록합니다.
2. 현재 설정 조건: 프록시 서비스를 다시 켜고 같은 Wi-Fi, 앱 동기화 설정, 화면 잠금 시간을 유지합니다. 수동으로 속도를 측정하지 마세요.
3. 설정 변경 조건: 상태 점검 간격만 늘리거나 백그라운드 설정만 바꾼 뒤 60분간 다시 테스트합니다.

테스트 중에는 충전하거나 구독을 다운로드하고, 앱을 업데이트하거나 오디오를 재생하지 마세요. 모바일 신호가 약하면 모뎀의 전력 소모가 프록시 처리 부하보다 훨씬 클 수 있습니다. Wi-Fi 테스트 결과와 신호가 약한 5G 테스트 결과를 바로 비교하지 마세요. 배터리 잔량은 정수 단위로 표시되므로 60분 테스트 결과가 비슷하다면 3~6시간으로 늘려 반복 측정하세요.

이처럼 짧은 시간 동안 순차적으로 진행하는 테스트는 기기 온도, 백그라운드 작업, 배터리 잔량 구간의 영향을 받습니다. 설정 방향을 가늠하는 데는 도움이 되지만, 특정 설정이 반드시 배터리를 절약한다고 증명하지는 못합니다. 차이를 재현할 수 있도록 매번 사용한 구독 설정과 클라이언트 버전을 기록해 두세요.

상태 점검 간격: 노드 수와 중복 점검부터 확인하세요

상태 점검은 지정한 URL을 통해 노드의 사용 가능 여부와 지연 시간을 확인합니다. 점검 한 번에도 보통 연결을 수립해야 하며 HTTPS라면 TLS 통신도 포함됩니다. 노드가 많고 간격이 짧을수록 네트워크 활동이 잦아집니다. 모바일 네트워크에서는 작은 요청을 자주 보내도 무선 모듈의 활성 시간이 길어질 수 있습니다.

혼동하기 쉬운 세 가지 간격 구분하기

• proxy-providers 아래의 interval: 원격 노드 공급자 업데이트 간격이며, 노드 속도 측정 간격이 아닙니다.
• health-check.interval: 노드 공급자의 상태 점검 간격이며, 단위는 초입니다.
• url-test, fallback 등의 정책 그룹 아래에 있는 interval: 해당 그룹이 자체 방식으로 점검하는 간격입니다. provider만 수정했다고 모든 점검이 줄어드는 것은 아닙니다.

예를 들어 노드 100개를 60초마다 모두 점검한다면, 노드당 한 번씩 시도한다고 단순 계산했을 때 시간당 약 6,000회가 됩니다. 이를 600초로 바꾸면 약 600회입니다. 이 계산은 규모를 설명하기 위한 것이며 실제 패킷 수를 나타내지는 않습니다. 실제 동작은 지연 점검, 노드 사용 여부, 타임아웃, 커널 구현 등에 따라 달라집니다.

수동으로 계속 측정하지 말고 600초부터 시작하세요

모바일에서 일상적으로 사용할 때는 관련 자동 점검 간격을 우선 600초로 설정하고 노드 장애 전환이 필요한 수준으로 빠른지 확인하세요. 네트워크 환경이 자주 바뀐다면 300초를 시도해 볼 수 있고, 고정된 안정적인 노드를 사용한다면 1,800초도 검토할 수 있습니다. 간격이 길수록 장애 발견이 늦어질 수 있으므로 가장 긴 간격이 항상 최선인 것은 아닙니다.

# 기존 proxy-providers의 해당 공급자 설정에 병합하세요.
# 기존 type, url, path 및 구독 업데이트 interval은 유지하세요.
# 이 조각은 그대로 가져올 수 있는 완전한 구독 설정이 아닙니다.
proxy-providers:
  mobile:
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      timeout: 5000
      lazy: true

여기서 interval의 단위는 초이고 timeout의 단위는 밀리초입니다. lazy: true는 사용하지 않는 공급자의 정기 점검을 줄이는 옵션이며, 모든 정책 그룹의 점검을 중지하는 것은 아닙니다. 기존 설정에서 공급자 이름이 mobile이 아니라면 구독 주소가 없는 항목을 새로 추가하지 말고 기존 항목을 수정하세요.

수정하기 전에 설정을 백업하세요. 구독을 업데이트한 뒤 설정이 덮어써지지 않도록 클라이언트가 지원하는 로컬 오버라이드 기능을 우선 사용하세요. 설정을 저장하고 다시 불러온 뒤 로그를 잠시 확인해 정상적으로 적용됐는지 확인하고, 다음 점검 시간에 설정이 반영되는지 살펴보세요. 절전 설정을 확인하려고 「전체 속도 측정」을 연달아 누르면 새로운 테스트 부하가 발생합니다.

백그라운드 실행: 계속 프록시를 사용할 때 필요한 권한만 허용하세요

Android의 VpnService 권한은 VPN을 설정할 수 있는지를 결정하고, 배터리 설정은 백그라운드 프로세스를 어떻게 관리할지 결정합니다. 서로 다른 설정입니다. VPN 권한을 허용했더라도 화면을 잠근 뒤 제조사 백그라운드 관리 기능이 앱을 제한할 수 있습니다. 반대로 배터리 제한을 해제해도 작동하지 않는 노드나 잘못된 DNS 문제는 해결되지 않습니다.

연결이 끊기는 증상에 따라 설정을 선택하세요

• 프록시를 계속 사용하며 화면을 잠그면 서비스가 종료되는 경우: 앱 아이콘을 길게 누르기 → 「앱 정보」→ 「배터리」 또는 「앱 배터리 사용량」→ 「제한 없음」을 선택합니다. 일부 시스템에서는 「백그라운드 활동 허용」과 자동 시작도 켜야 합니다.
• 서비스가 안정적이고 화면 잠금 중 연결이 끊기지 않는 경우: 현재 백그라운드 설정을 유지하세요. 관련 앱 모두에 권한을 허용할 필요는 없습니다.
• 짧은 작업에만 사용하는 경우: 작업이 끝나면 클라이언트에서 프록시 서비스를 중지하세요. 화면만 닫거나 최근 앱 목록에서 앱을 지워도 VPN이 중지되지 않을 수 있습니다.

Android 13, 14 등에서는 제조사에 따라 메뉴 이름이 다릅니다. 설정에서 「배터리 최적화」, 「백그라운드 실행」, 「자동 시작」을 검색해 관련 메뉴를 찾으세요. 최근 앱 목록에서 앱을 고정하는 기능은 일부 제조사의 추가 기능입니다. VpnService 권한을 대신할 수 없으며 시스템이 프로세스를 종료하지 않는다고 보장하지도 않습니다.

VPN 항상 사용을 설정했다면 「설정」→「네트워크 및 인터넷」→「VPN」에서 해당 앱 옆의 설정 버튼을 확인하세요. 「VPN 없이 연결 차단」을 켜면 서비스가 중지된 뒤 일반 네트워크 연결도 시스템에서 차단될 수 있습니다. 이 기능은 VPN 연결이 끊겼을 때 트래픽이 우회하는 것을 막아야 하는 경우에 적합하며, 절전 기능은 아닙니다.

DNS와 규칙: 타임아웃 원인을 찾고 Fake-IP를 무작정 바꾸지 마세요

DNS 설정 오류는 웹페이지가 오래 로딩되거나 앱이 계속 새로고침되고, 로그에 DNS 조회 타임아웃이 반복되는 형태로 나타나는 경우가 많습니다. 배터리 소모는 반복 요청과 연결 재시도에서 발생하며, 특정 DNS 모드가 본질적으로 배터리를 더 많이 소모하는 것은 아닙니다. Fake-IP는 도메인과 합성 주소의 매핑을 유지해 이후 연결과 규칙 매칭에 사용합니다. 실제 IP 모드로 바꿔도 접근할 수 없는 상위 DNS 서버 문제가 저절로 해결되지는 않습니다.

1. 발생 시점의 연관성을 먼저 확인하세요: 클라이언트의 「로그」 페이지에서 잠시 info 수준을 사용하고 문제가 발생하는 앱을 열어 DNS 타임아웃, 연결 타임아웃 또는 동일한 도메인의 실패 기록이 반복되는지 확인하세요.
2. 상위 DNS 서버 연결을 확인하세요: DNS 서버에 예상한 경로로 접속할 수 있는지 확인하세요. 특히 프록시로 접속해야 하는 암호화 DNS가 아직 조회에 실패하는 프록시 노드 도메인에 의존하는지 살펴보세요.
3. 시스템 비공개 DNS를 확인하세요: Android의 「설정」→「네트워크 및 인터넷」→「비공개 DNS」 설정이 일부 조회 경로에 영향을 줄 수 있습니다. 기존 설정을 기록한 뒤 한 번에 하나씩 비교 테스트하고, 커널 DNS와 시스템 DNS를 동시에 바꾸지 마세요.
4. 규칙 적용 결과를 다시 확인하세요: 규칙 모드는 순서대로 평가되며 일반적으로 먼저 일치한 규칙이 트래픽의 경로를 결정합니다. 트래픽이 많은 앱이 불안정한 노드에 잘못 연결되면 재연결이 반복될 수 있으므로 먼저 규칙이나 정책 그룹 선택을 수정하세요.

「DNS 조회 속도 향상」을 위해 상위 DNS 서버를 여러 개 추가하지 마세요. 설정에 따라 동시에 조회가 진행될 수 있으며, 상위 서버가 많아도 요청 수가 줄어드는 것은 아닙니다. 현재 설정이 안정적이라면 출처가 불분명한 DNS 설정 전체를 복사하기보다 잘못된 경로부터 바로잡으세요. 배터리 테스트를 위해 캐시를 한꺼번에 지우는 것도 피하세요. 초기 조회와 새 연결이 늘어날 수 있습니다.

앱별 프록시, 로그, 네트워크 전환 시 고려할 점

앱별 프록시와 DIRECT 규칙은 서로 다릅니다

클라이언트에서 앱별 프록시를 지원한다면 실제로 필요한 앱만 VPN에 포함할 수 있습니다. Android의 앱별 설정은 VPN 인터페이스 단계에서 앱 범위를 제한합니다. 반면 DIRECT 규칙은 일반적으로 트래픽이 커널에 들어온 뒤 직접 연결할 경로를 선택합니다. 처리 경로가 다르므로 직접 연결 규칙을 「클라이언트를 완전히 우회하는 기능」으로 이해하면 안 됩니다.

「선택한 앱만 프록시 사용」을 선택했다면 브라우저, 메시지 알림, 로그인 리디렉션, 파일 다운로드를 직접 테스트하세요. 앱이 시스템 다운로드 구성 요소나 다른 앱을 호출해 작업할 수 있으므로 허용 목록이 너무 좁으면 관련 연결의 경로가 서로 달라질 수 있습니다. 업무, 금융, 사내 네트워크 환경에서는 해당 네트워크 사용 규칙도 따라야 합니다.

문제 해결 후 진단 부하를 원래대로 되돌리세요

• debug로 임시 변경한 로그 수준을 info 또는 클라이언트 기본값으로 되돌리세요. 로그 수준을 바꿔도 연결 문제는 해결되지 않으며, 상세 로그는 처리와 저장 부하를 늘립니다.
• 상시 확인할 필요가 없는 연결 모니터링 화면은 닫으세요. 화면을 계속 켜 두고 관찰하는 방식은 화면을 잠근 상태의 테스트를 대신할 수 없습니다. 화면 갱신과 디스플레이 전력 소모가 결과에 영향을 줍니다.
• 구독 자동 업데이트 빈도를 확인하세요. 자주 업데이트할 필요가 없다면 12시간 또는 24시간 간격으로 조정할 수 있습니다. 이 설정은 상태 점검 간격 600초와 별개입니다.
• Wi-Fi와 모바일 네트워크를 전환한 뒤에는 기존 연결이 다시 수립될 때까지 기다리세요. 신호가 약한 곳에서만 문제가 발생한다면 안정적인 Wi-Fi에서 먼저 비교 테스트하고, 구독 전체를 서둘러 바꾸지 마세요.

모바일의 VPN 트래픽 처리와 데스크톱의 TUN 모드는 모두 가상 네트워크 인터페이스를 사용하지만 설정 메뉴는 서로 다릅니다. 데스크톱의 「시스템 프록시 끄기, TUN 켜기」 메뉴 경로를 그대로 따라 하지 마세요. Android에서는 VPN 서비스 상태, 앱별 적용 범위, 사용 중인 설정이 서로 일치하는지 먼저 확인하세요.

증상에 맞춰 설정을 좁히고 복원 가능한 설정을 보관하세요

문제 해결을 시작할 때는 규칙 모드를 유지하고 검증된 노드를 사용하세요. 관련 자동 상태 점검 간격은 우선 600초로 설정하고, 화면 잠금 후 실제로 연결이 끊기는 경우에만 배터리 제한을 해제하세요. 점검이 끝나면 일반 로그 수준으로 되돌리면 됩니다. 이는 비교를 시작하기 위한 설정일 뿐, 모든 휴대폰에 맞는 고정값은 아닙니다.

설정 종류별로 한 번에 하나씩 바꾸고 변경 시간과 복구 방법을 기록하세요. 문제를 문의할 때는 휴대폰 모델, Android 버전, 클라이언트 및 커널 버전, 네트워크 종류, 화면 잠금 테스트 시간, 민감 정보를 삭제한 오류 로그를 함께 제공하세요. 구독 URL, 액세스 토큰, 노드 인증 정보는 공개하지 마세요. 배터리 사용량 순위 화면 한 장보다 재현 가능한 기록이 문제 원인을 찾는 데 더 도움이 됩니다.