Clash 모바일 배터리 소모가 빠를 때: 백그라운드 실행·DNS 반복 요청·절전 설정 점검

먼저 조건을 맞춰 비교하세요: 데이터 사용량·대기 중 소모·배터리 통계 구분하기

Clash를 켠 뒤 휴대폰이 뜨거워졌다고 해서 프록시 엔진이 계속 CPU를 최대로 사용하는 것은 아닙니다. 동영상 다운로드, 클라우드 사진 업로드, 신호가 약한 곳에서의 셀룰러 데이터 재전송이 동시에 일어날 수도 있습니다. Android의 로컬 VPN은 다른 앱의 트래픽을 전달하므로 시스템 배터리 화면에서 일부 네트워크 사용량이 VPN 클라이언트로 집계될 수 있습니다. 시스템마다 집계 방식도 다릅니다. 먼저 휴대폰 전체의 배터리 감소량을 확인하고 앱별 순위는 참고만 하세요.

각 60분 이상, 두 차례 비교 테스트

조건을 일정하게 유지: 같은 Wi-Fi와 비슷한 시작 배터리 잔량, 실내 온도를 유지하세요. 다운로드와 시스템 업데이트는 일시 중지하고, 충전하면서 테스트하지 마세요.
프록시를 끄고 한 차례 테스트: 화면을 잠근 채 60분 동안 두고 시작·종료 배터리 잔량, 발열 여부, 백그라운드 앱과 신호 상태를 기록하세요.
프록시를 켜고 한 차례 테스트: 같은 노드와 설정을 사용하고 화면을 잠근 채 60분 동안 테스트하세요. 두세 차례 반복하고, 가능하면 테스트 순서를 바꿔 진행하세요.
셀룰러 데이터 테스트도 추가: 모바일 네트워크에서만 문제가 두드러진다면 TUN 스택을 바로 바꾸기보다 신호 상태, 네트워크 전환, 연결 재시도를 먼저 확인하세요.

예를 들어 배터리 잔량이 80%에서 77%로 줄었다면 “한 시간 동안 3%포인트 감소”라고 기록할 수 있지만, 이를 근거로 정확한 전력 소모량을 계산할 수는 없습니다. 아래 항목은 기록을 위한 참고 목록이며 이 사이트에서 직접 측정한 결과가 아닙니다. 배터리 잔량 표시는 반올림 오차가 있으므로 차이가 작다면 3~6시간으로 테스트 시간을 늘리는 편이 유용합니다.

기록 항목	기록할 내용	확인 목적
소프트웨어 환경	클라이언트 버전, 커널 버전, Android 버전	업데이트 전후 결과를 같은 테스트로 혼동하지 않도록
네트워크 조건	Wi-Fi 또는 셀룰러, 노드, 테스트 시간	네트워크 경로 차이 배제
배터리 및 온도	시작·종료 배터리 잔량, 눈에 띄는 발열 여부	기기 전체의 변화를 확인
실행 상태	서비스 재시작 여부, 네트워크 재연결 여부	백그라운드에서 반복 실행되는지 확인

백그라운드 실행: 필요한 권한만 허용하고 반복 실행은 막기

Android 클라이언트는 보통 VpnService로 로컬 VPN 인터페이스를 만든 다음 트래픽 처리를 커널에 맡깁니다. 시스템에 상시 알림이 표시된다고 해서 부하가 계속 큰 것은 아닙니다. 반대로 알림을 숨기거나 백그라운드 실행을 제한하면 서비스가 종료됐다가 자동으로 다시 시작되면서 연결이 끊기고 초기화가 반복될 수 있습니다.

먼저 Android의 설정 메뉴 세 곳을 확인하세요

배터리 제한: Android 13~15에서는 보통 ‘설정’ → ‘앱’ → ‘모든 앱 보기’ → 클라이언트 선택 → ‘앱 배터리 사용량’에서 확인할 수 있습니다. 일부 기기에서는 ‘배터리’ → ‘제한 없음/최적화/제한’으로 표시됩니다. 메뉴 이름은 기기에 따라 다를 수 있습니다.
VPN 설정: 기본 Android에서는 보통 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’ → 클라이언트 옆 설정 버튼에서 ‘항상 켜기 VPN’과 ‘VPN 없이 연결 차단’을 확인할 수 있습니다. 후자는 VPN 연결이 끊겼을 때 트래픽을 차단하는 기능이지 절전 옵션이 아닙니다.
제조사별 백그라운드 관리: 앱 정보 화면에서 ‘자동 시작’, ‘백그라운드 실행’ 등의 옵션을 확인하세요. 먼저 해당 클라이언트만 조정하고 모든 백그라운드 앱을 한꺼번에 허용하지 마세요.

화면이 꺼진 뒤에도 연결이 안정적이고 서비스 종료 기록이 없다면 ‘백그라운드 실행을 더 강하게 유지’하려고 예약 재시작, 서드파티 감시 앱, 주기적인 네트워크 요청을 추가할 필요는 없습니다. 화면을 잠근 뒤 연결이 끊긴다면 먼저 클라이언트의 정상적인 백그라운드 실행을 허용한 다음 배터리 소모 변화를 확인하세요. 절전과 연결 유지는 각각 따로 검증해야 합니다. 권한을 계속 바꾸며 운에 맡기지 마세요.

필요한 앱만 VPN에 포함하면 커널이 처리하는 연결 수를 줄일 수 있지만 기기 전체의 배터리 소모가 줄어든다고 보장할 수는 없습니다. 제외된 앱도 백그라운드에서 계속 다운로드할 수 있습니다. 설정을 바꿀 때마다 브라우저, 메시지 알림, 지도, 로컬 네트워크 접근을 확인하세요. 기능이 작동하지 않는 것을 절전에 성공한 것으로 착각하지 않도록 주의하세요.

예약 작업: 상태 확인부터 살펴보고 구독 업데이트 점검하기

대기 중에도 주기적으로 네트워크에 연결된다면 노드 상태 확인, 자동 선택 정책, 구독 또는 규칙 업데이트가 원인일 수 있습니다. 이 작업들은 서로 다른 종류의 타이머입니다. 노드 확인은 연결 가능 여부를 테스트하고, 구독 업데이트는 설정이나 노드 목록을 내려받으며, 규칙 업데이트는 트래픽 분류 데이터를 새로 고칩니다. 세 작업을 모두 수십 초 간격으로 실행하면 불필요한 요청이 늘어날 수 있습니다.

확인 간격과 노드 수를 함께 살펴보세요

노드가 80개인 그룹을 60초마다 모두 검사한다고 가정하면, 일정 횟수만 계산해도 시간당 검사 시도는 4,800회입니다. 간격을 600초로 늘리면 480회로 줄어듭니다. 실제 횟수는 지연 검사, 실패 처리, 클라이언트 구현에 따라서도 달라집니다. 이는 설정 규모를 보여주는 예시일 뿐 배터리 실측 결과가 아니며 모든 노드가 동시에 연결된다는 뜻도 아닙니다.

문제 해결 중에는 불필요한 자동 속도 측정을 끄거나 간격을 60초에서 600~1,800초로 늘리세요.
일시적으로 수동 선택 정책을 사용하고 같은 노드에서 화면을 잠근 상태의 배터리 소모를 비교해 잦은 자동 전환을 배제하세요.
일반 구독은 우선 24시간마다 업데이트하도록 설정하세요. 변경 사항을 더 빨리 받아야 할 때 간격을 줄이면 됩니다.
같은 노드를 대상으로 하는 촘촘한 검사를 여러 그룹에서 동시에 실행하지 마세요. 상태 확인과 정책 그룹 테스트가 각각 요청을 보낼 수 있습니다.

mihomo provider 설정 예시

아래 예시는 기존 proxy-providers 안의 HTTP provider에서 해당 필드만 바꾸기 위한 것입니다. 기존 이름, 구독 URL, 경로는 그대로 두고 YAML 최상위에 붙여 넣지 마세요. 여기서 interval과 상태 확인의 interval 단위는 초이며, timeout 단위는 밀리초입니다.

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

lazy: true는 사용하지 않는 provider의 주기적인 검사를 줄이는 설정이며, 사용 중인 노드의 모든 검사를 끄지는 않습니다. 검사 주소는 해당 노드를 통해 접속할 수 있어야 합니다. 현재 네트워크에서 해당 주소에 접근할 수 없다면 주소 문제를 노드 장애로 잘못 판단할 수 있습니다. 이전 버전의 Clash 커널은 지원하는 필드가 다를 수 있으므로 가져오기 전에 커널 종류를 확인하고 저장한 뒤 설정 오류 메시지도 살펴보세요.

클라이언트 자체의 ‘구독 자동 업데이트’는 YAML의 provider 업데이트와 별개로 동작할 수 있습니다. 두 위치를 모두 확인하세요. 숫자 하나만 바꾸면 충분하지 않을 수 있습니다. 관리형 설정은 다음 업데이트 때 직접 수정한 내용이 덮어써질 수도 있으니 클라이언트의 오버라이드 또는 병합 기능을 우선 사용하세요.

DNS 반복 요청: 리졸버를 무작정 바꾸지 말고 로그로 원인 찾기

일반적인 DNS 조회는 앱이 도메인을 확인할 때 발생합니다. fake-ip를 켰다고 휴대폰이 모든 도메인을 일정한 간격으로 조회하는 것은 아닙니다. fake-ip는 주로 도메인 매핑과 연결 처리 방식을 바꿉니다. ‘DNS 반복 요청으로 배터리가 소모된다’고 느껴지는 현상은 앱의 재시도, 상태 확인, 암호화 DNS 연결 재수립 또는 DNS 설정으로 인한 순환 참조가 원인일 수 있습니다.

짧은 시간 로그를 켜고 다음 세 가지 패턴을 확인하세요

같은 도메인이 몇 초 간격으로 반복 표시됨: 메시지 앱, 광고 요청, 동기화 작업, 속도 측정 주소인지 먼저 확인하세요. 필요한 경우 해당 앱을 잠시 중지해 요청도 멈추는지 살펴보세요.
시간 초과 후 즉시 재시도하는 요청이 많음: DNS 상위 서버에 접속할 수 있는지, 아직 연결되지 않은 프록시에 의존하는지, 상위 서버 도메인을 어떤 부트스트랩 DNS로 해석하는지 확인하세요.
로컬 주소끼리 요청을 반복 전달함: 클라이언트 DNS가 자신이 가로채는 엔드포인트로 다시 전달되는지 확인하세요. 127.0.0.1의 수신 포트를 상위 서버로도 지정해 순환 구조를 만들지 마세요.

문제를 확인하는 동안 접속이 검증된 DNS 상위 서버 하나를 남기고 중복된 재정의 설정을 잠시 중단한 뒤 하나씩 복원하세요. 절전을 위해 모든 DNS 규칙을 비우거나 캐시 만료 시간을 지나치게 늘리지 마세요. 도메인이 바뀐 뒤에도 새 주소가 제때 반영되지 않을 수 있습니다. nameserver-policy는 도메인별로 리졸버를 선택하는 설정이지 타이머 전체를 끄는 스위치가 아닙니다.

Android의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘비공개 DNS’ 설정도 기록해 두세요. 시스템 비공개 DNS, 브라우저의 보안 DNS, 클라이언트 내장 DNS가 함께 작동할 수 있습니다. 실제 동작은 VPN 라우팅과 앱 구현에 따라 다릅니다. TUN에서 53번 포트를 가로채더라도 모든 암호화 DNS를 처리할 수 있는 것은 아닙니다. 비교 테스트가 필요하다면 한 번에 하나만 변경하고 테스트 후에는 개인정보 보호 요구에 맞는 설정으로 되돌리세요.

로그 수준과 연결 화면: 문제 해결 후 불필요한 부하 줄이기

디버그 로그는 형식 변환, 파일 쓰기, 화면 갱신에 드는 작업을 늘립니다. 원인을 찾을 때는 잠시 켤 수 있지만 로그 화면을 장시간 띄워 둔 채 사용하는 것은 피하세요. 연결 목록이 초당 한 번씩 갱신되는 경우 프런트엔드 작업도 늘어납니다. 화면을 잠근 상태의 배터리 소모를 테스트할 때는 앱을 백그라운드로 보내 대시보드를 계속 켜 두지 마세요.

mihomo는 일상적인 로그 수준으로 우선 아래 값을 사용하면 됩니다. 이 설정은 dns, tun과 같은 최상위 레벨에 둡니다. 올바른 값은 warning이며 warn이 아닙니다.

log-level: warning

문제를 재현할 때만 info로 잠시 바꾸고 5~10분 동안 기록하세요.
더 자세한 진단이 필요할 때만 debug를 사용하고, 테스트 중에 대량의 로그를 계속 내보내지 마세요.
로그를 공유하기 전에 구독 URL의 토큰, 노드 인증 정보, 개인 접속 기록을 가리세요.
클라이언트에 별도의 화면 로그 설정이 있다면 그것도 확인하세요. 커널 로그 수준이 모든 프런트엔드 로그를 제어하는 것은 아닙니다.

로그 수준을 낮추면 기록에 드는 부하는 줄지만 노드 패킷 손실이나 DNS 순환 문제가 해결되지는 않습니다. 같은 오류가 계속 발생한다면 로그만 숨기지 말고 오류의 원인을 해결하세요.

TUN 스택과 노드 프로토콜: 실제 기기에서 테스트해 선택

Android에서는 VpnService가 가상 네트워크 인터페이스를 제공하고, 클라이언트가 전달받은 패킷의 처리 방식을 결정합니다. 데스크톱 튜토리얼의 TUN 스위치를 Android 구현에 그대로 적용할 수는 없습니다. 일부 모바일 클라이언트는 자체적으로 인터페이스를 만들므로 YAML의 tun 필드가 모든 동작을 제어하지 않을 수도 있습니다.

선택 가능한 옵션을 확인한 뒤 변수를 하나씩 바꿔 테스트하세요

mihomo에서 흔히 볼 수 있는 스택 옵션은 system, gvisor, mixed입니다. 모바일 클라이언트에서 이 옵션을 제공하는지, 어떤 방식으로 연결하는지는 해당 버전에 따라 다릅니다. 모든 휴대폰에 통하는 ‘최저 전력 스택’은 없습니다. 기본 스택이 안정적으로 작동한다면 그대로 두세요. CPU 점유율이 계속 높거나 UDP 이상, 알려진 호환성 문제가 있을 때만 지원되는 다른 스택을 테스트하세요.

현재 클라이언트와 커널의 전체 버전 번호를 기록하고 정상 작동하는 설정을 백업하세요.
스택만 바꾸고 노드, 규칙, DNS, 테스트 네트워크는 그대로 유지하세요.
클라이언트 안내에 따라 VPN을 다시 연결한 뒤 화면을 잠근 대기 상태와 실제 사용 상태를 각각 테스트하세요.
웹 페이지, 음성 통화, 게임 UDP, IPv6, 로컬 네트워크 기기 접근을 확인하세요. 문제가 다시 나타나면 이전 설정으로 되돌리세요.

노드 측의 패킷 손실, 혼잡, 프로토콜 구현도 배터리 소모에 영향을 줍니다. 네트워크가 불안정해 계속 재연결된다면 정상적인 핸드셰이크 한 번보다 그 원인을 먼저 살펴봐야 합니다. 먼저 같은 프로토콜의 안정적인 노드로 바꾼 뒤 프로토콜 차이를 비교하세요. 노드 변경, IPv6 끄기, 스택 전환을 한꺼번에 하지 마세요. 무엇이 효과가 있었는지 판단하기 어렵습니다.

절전 설정 점검 목록: 위험이 낮은 항목부터 적용

순서	조정할 항목	확인 기준
1	실시간 로그 화면을 닫고 일상 사용에는 warning 적용	오류 메시지가 반복해서 쏟아지지 않고 기능이 정상 작동함
2	상태 확인 간격을 우선 600초로 설정해 반복 검사 줄이기	노드를 계속 정상적으로 선택할 수 있고 검사 빈도가 낮아짐
3	구독 업데이트 간격을 우선 24시간으로 설정	설정이 정상적으로 갱신되고 반복 다운로드가 없음
4	DNS 시간 초과와 재시도 순환 문제 해결	같은 오류가 사라지고 도메인이 정상적으로 조회됨
5	필요에 따라 백그라운드 권한과 앱 목록 조정	화면을 잠근 상태에서도 연결, 알림, 필요한 트래픽이 정상 작동함
6	노드와 TUN 스택을 비교 테스트	반복 테스트에서 개선되고 서비스 기능에 문제가 없음

iPhone 사용자도 같은 네트워크 조건에서 비교 테스트를 먼저 해야 하지만 Android의 배터리 최적화 제외 목록이나 VpnService 메뉴를 그대로 따라 해서는 안 됩니다. iOS 클라이언트는 대개 Network Extension을 사용합니다. 구독 업데이트, 속도 측정, 로그 설정은 사용 중인 앱에서 확인하세요. 이 문서의 mihomo YAML 예시도 클라이언트가 해당 설정을 명시적으로 지원하는 경우에만 적용됩니다.

배터리가 계속 빨리 닳는다면: 재현 가능한 문제 기록 준비

위 단계를 모두 거친 뒤에도 휴대폰이 계속 뜨거워진다면 “백그라운드에서 배터리를 많이 써요”라는 한마디보다 최소 재현 기록을 준비하는 편이 원인을 찾는 데 도움이 됩니다. 클라이언트 프로젝트의 문제 제보 페이지에 제출할 때는 다음 정보를 포함하세요.

휴대폰 모델, 시스템 버전, 클라이언트 버전, 커널 버전과 업그레이드 후 처음 문제가 나타났는지 여부.
Wi-Fi 또는 셀룰러 사용 여부, 화면 잠금 여부, 테스트 시작·종료 시간, 프록시를 켰을 때와 껐을 때의 전체 배터리 감소량.
상태 확인과 업데이트 간격, 로그 수준, TUN 스택, 앱별 프록시 사용 여부.
민감한 정보를 삭제한 짧은 로그, 처음 이상이 발생한 시간, 서비스 재시작이나 네트워크 전환이 동반됐는지 여부.

프록시를 꺼도 배터리가 똑같이 빨리 닳는다면 신호 상태, 백그라운드 동기화, 배터리 상태, 시스템 업데이트 작업을 확인하세요. 문제 해결은 먼저 측정하고, 불필요한 깨우기를 줄인 뒤, 마지막으로 하위 구현을 조정하는 순서로 진행합니다. 한 번에 하나씩 바꾸고 되돌릴 설정을 백업해야 결과를 제대로 비교할 수 있습니다. 기본 사용법은 사용 가이드에서 확인하고, 연결 문제가 있다면 전체 문제 해결 문서를 참고하세요.