배터리 소모가 프록시 때문인지 전면 사용 때문인지 먼저 확인하기
휴대전화에서 Clash 클라이언트의 배터리 소모량이 높게 표시되더라도 프록시 코어가 계속 CPU를 많이 사용한다는 뜻은 아닙니다. Android는 VPN 인터페이스 전달, 백그라운드 서비스, 일부 네트워크 활동을 클라이언트 사용량에 포함하며, iOS는 Packet Tunnel 네트워크 확장의 활동을 해당 앱에 합산할 수 있습니다. 화면을 계속 켜 두거나 로그 화면을 자주 열고, 연속 속도 측정과 반복적인 구독 업데이트를 수행하면 짧은 시간의 측정값이 크게 높아집니다.
판단하기 전에 비교 가능한 유휴 테스트를 한 번 진행하세요. 배터리를 80% 이상 충전하고 화면을 끈 뒤 네트워크 환경을 동일하게 유지하면서, 프록시를 켰을 때와 껐을 때 각각 2시간 동안 배터리 변화를 기록합니다. 테스트 중에는 대용량 파일 다운로드, 동영상 재생, Wi-Fi와 모바일 데이터 전환을 하지 마세요. 시스템 화면의 배터리 사용 비율만 보면 오판하기 쉽습니다. 비율은 해당 측정 구간의 전체 소모량에서 차지하는 비중일 뿐, 별도로 측정한 mAh 값이 아니기 때문입니다.
| 현상 | 우선 확인할 항목 | 판단 기준 |
|---|---|---|
| 대기 중 시간당 2% 초과 감소 | 상태 확인, 로그, 네트워크 재연결 | 화면을 꺼도 트래픽이 계속 발생하거나 자주 깨움 |
| 모바일 네트워크에서만 배터리 소모가 빠름 | 약한 신호, IPv6, 연결 재구축 | 안정적인 Wi-Fi로 전환하면 뚜렷하게 회복 |
| 구독 업데이트 후 잠시 발열 발생 | 속도 측정 및 노드 일괄 확인 | 몇 분 후 CPU 사용량과 온도가 낮아짐 |
| 화면을 잠그면 프록시가 자주 끊김 | 시스템 배터리 최적화 | 화면을 다시 켜야 서비스가 복구됨 |
| 연결 또는 로그 화면을 열 때 발열 발생 | 인터페이스 새로 고침 빈도 | 모니터링 화면을 닫으면 정상으로 돌아옴 |
상태 확인이 네트워크를 계속 깨우는 이유
노드가 많을수록 확인 요청이 촘촘해집니다
프록시 제공자의 상태 확인은 각 노드를 통해 테스트 주소에 정기적으로 접속한 뒤 응답 결과에 따라 노드 사용 가능 여부를 표시합니다. 구독에 노드 80개가 있고 확인 간격이 300초라면 클라이언트가 5분마다 수십 건의 연결을 만들 수 있습니다. 개별 요청의 트래픽은 적지만 연결 핸드셰이크, TLS 협상, 무선 네트워크 깨우기, 실패한 요청의 재시도가 추가 전력을 소모합니다.
모바일에서는 보통 300초마다 전체 노드를 확인할 필요가 없습니다. 일반적인 웹 탐색이라면 간격을 900~1800초로 늘리고 지연 확인을 활성화하세요. `lazy: true`는 제공자가 실제로 사용되지 않을 때 적극적인 테스트를 줄인다는 의미지만, 구체적인 작동 방식은 클라이언트의 mihomo 버전과 인터페이스 설정에 따라 달라집니다. 소수의 노드만 고정적으로 사용하는 구성이라면 900초가 장애 감지 속도와 대기 전력의 균형을 맞추기 좋습니다.
proxy-providers:
mobile-subscription:
type: http
url: "구독 주소"
path: ./providers/mobile.yaml
interval: 86400
health-check:
enable: true
lazy: true
url: https://www.gstatic.com/generate_204
interval: 900
timeout: 5000여기서 `interval: 86400`은 구독 업데이트 주기이며 단위는 초입니다. 상태 확인의 `interval: 900`은 노드 검사 주기입니다. 두 설정의 용도는 다릅니다. 구독 업데이트를 24시간으로 설정해도 노드가 15분마다 확인되는 것을 막지는 못합니다. 클라이언트 그래픽 인터페이스에 ‘자동 업데이트’와 ‘자동 속도 측정’이 함께 있다면 두 스위치를 각각 확인하세요.
자동 속도 측정은 사용 가능 여부 확인보다 배터리를 더 많이 소모합니다
사용 가능 여부 확인은 테스트 주소가 응답하는지만 확인하면 됩니다. 지연 시간 정렬은 여러 노드의 응답 시간을 측정하고, 대역폭 테스트는 더 많은 데이터를 전송합니다. 모바일에서 몇 분마다 전체 노드의 속도를 자동으로 측정하는 것은 적합하지 않습니다. 사용 가능 여부 확인은 유지하되 전체 속도 측정은 수동으로 전환하고, 노드 목록이 바뀌거나 현재 회선이 눈에 띄게 느려졌을 때만 실행하세요.
- 노드가 20개 미만이면 상태 확인을 900초로 설정할 수 있습니다.
- 노드가 20~100개라면 1800초를 권장하며 지연 확인을 활성화하세요.
- 노드가 100개를 초과하면 먼저 구독 그룹을 정리한 뒤 3600초로 늘리는 방법을 고려하세요.
- 셀룰러 네트워크 신호가 약할 때는 일괄 속도 측정을 일시 중지해 실패한 연결의 반복 재시도를 피하세요.
DNS 조회와 규칙 매칭이 미치는 실제 영향
Clash는 Fake-IP 모드에서 앱의 DNS 조회를 받아 도메인과 매핑 주소의 관계를 저장한 다음 규칙에 따라 도메인을 매칭합니다. 이 과정 자체는 보통 주요 배터리 소모 원인이 아닙니다. 실제로 주의할 부분은 조회 실패 후 반복되는 요청, 지나치게 많은 원격 DNS 업스트림, 네트워크 전환 후 연결 재구축, 백그라운드에서 앱이 계속 보내는 원격 측정 또는 동기화 요청입니다.
불필요한 업스트림과 시간 초과 재시도 줄이기
모바일 구성에 많은 DNS 서버를 동시에 입력할 필요는 없습니다. 각 그룹에 안정적인 업스트림 2개만 남기세요. 응답이 느리거나 현재 네트워크에서 접근할 수 없는 암호화 DNS를 여러 개 설정하면 조회가 시간 초과될 때까지 기다린 뒤 다른 업스트림을 시도합니다. 한 번의 실패는 큰 문제가 아니지만 백그라운드 앱이 계속 조회하면 반복되는 시간 초과로 무선 모듈의 활성 시간이 길어집니다.
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
ipv6: false
nameserver:
- https://223.5.5.5/dns-query
- https://1.12.12.12/dns-query
fake-ip-filter:
- "*.lan"
- "*.local"
- "time.*.com"`ipv6: false`는 현재 프록시 노드, 규칙, 네트워크 환경이 모두 IPv6에 의존하지 않을 때만 적합합니다. 가정용 인터넷이나 모바일 네트워크에서 IPv6 리소스에 접근해야 한다면 배터리 절약만을 이유로 끄지 마세요. 먼저 로그에서 연속적인 AAAA 조회 실패, 라우팅 불가 또는 연결 폴백이 있는지 확인한 뒤 조정해야 합니다.
Fake-IP 필터 목록도 무한히 늘리지 않는 것이 좋습니다. 필터 항목이 많다고 해서 바로 배터리가 크게 소모되지는 않지만, 일부 앱이 예상한 도메인 매핑을 우회해 추가 조회와 연결을 시도할 수 있습니다. LAN 기기 이름, 시간 동기화 도메인, 실제 주소가 명시적으로 필요한 앱의 도메인은 필터에 추가하고 나머지는 간결하게 유지하세요.
TUN 모드와 시스템 VPN의 배터리 소모 범위
Android와 iOS의 Clash 계열 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. TUN을 활성화하면 앱 트래픽이 가상 네트워크 카드로 들어가고, 코어가 DNS 처리, 규칙 매칭, 프록시 전달을 수행합니다. 단일 앱에 HTTP 프록시만 설정하는 것보다 TUN의 적용 범위가 넓어 더 많은 백그라운드 연결을 처리합니다.
TUN이 반드시 배터리를 많이 소모한다는 뜻은 아닙니다. 구성이 정상이고 노드가 안정적이면 추가 부담은 대개 제한적입니다. 비정상적인 소모는 노드의 반복적인 연결 해제와 재연결, 규칙으로 인한 연결 루프, 약한 신호에서 많은 장기 연결 유지, 또는 시스템 절전 기능이 VPN 서비스를 반복적으로 종료하고 재시작하는 상황에서 더 자주 발생합니다. 터널을 자주 재구축하는 것이 안정적으로 유지하는 것보다 전력을 더 많이 소모하는 경우가 많습니다.
Android: 필요한 백그라운드 실행 허용
순정 Android 14와 Android 15를 예로 들면 「설정」→「앱」→「Clash 클라이언트」→「앱 배터리 사용량」으로 이동해 「백그라운드 사용 허용」을 켤 수 있습니다. 일부 제조사 시스템에서는 「제한 없음」, 「백그라운드 활동 허용」 또는 「최적화하지 않음」으로 표시되지만 목적은 같습니다. 화면을 잠근 후 시스템이 VPN 서비스를 종료하지 않도록 하는 것입니다.
프록시를 항상 유지해야 한다면 「설정」→「네트워크 및 인터넷」→「VPN」→해당 클라이언트 오른쪽의 설정 버튼으로 이동한 뒤 「항상 켜진 VPN」을 활성화할 수 있습니다. 필요한 모든 트래픽이 정상적으로 통과하는지 확인했을 때만 「VPN 없이 연결 차단」을 켜세요. 잘못된 노드나 구성에서는 기기 전체가 인터넷에 연결되지 않을 수 있습니다.
백그라운드 권한은 많을수록 좋은 것이 아닙니다. 알림 권한, 부팅 시 시작, VPN 백그라운드 실행은 연결 유지에 필요할 수 있지만, 화면 위에 표시, 지속적인 위치 접근, 주변 기기 검색은 클라이언트 기능에 실제로 필요한 경우에만 허용하세요. 시스템 배터리 설정에서 「백그라운드 실행 허용」과 타사 관리자의 「화면 잠금 시 정리」 규칙이 충돌하지 않도록 해야 합니다.
iOS: 저전력 모드와 네트워크 확장
iOS 클라이언트는 Network Extension을 통해 프록시 터널을 실행합니다. 「설정」→「일반」→「VPN 및 기기 관리」→「VPN」에서 구성 상태를 확인할 수 있으며, 배터리 기록은 「설정」→「배터리」에 있습니다. 「지난 24시간」과 「지난 10일」을 확인할 때는 ‘백그라운드 활동’과 전면 화면 사용 시간을 구분하세요.
저전력 모드는 일부 앱의 백그라운드 새로 고침을 제한하지만 이미 연결된 VPN 터널은 시스템이 관리하므로 클라이언트를 반복해서 열어 유지하려 해서는 안 됩니다. 화면을 잠근 후 자주 끊긴다면 먼저 클라이언트의 온디맨드 연결 규칙, 노드 안정성, 시스템 로그를 확인하고 VPN을 계속 껐다 켜지 마세요. 전환할 때마다 인터페이스, DNS 상태, 프록시 연결을 다시 구축해야 합니다.
바로 적용할 수 있는 세 가지 절전 조합
| 사용 환경 | 상태 확인 | TUN 정책 | 권장 작업 |
|---|---|---|---|
| 하루 종일 연결 유지 | 900~1800초, lazy 활성화 | 계속 켜기 | 안정적인 노드를 고정하고 전체 자동 속도 측정 끄기 |
| 웹 탐색할 때만 사용 | 1800~3600초 | 필요할 때 켜기 | 사용하지 않을 때 VPN 서비스를 직접 중지 |
| 모바일 네트워크 및 약한 신호 환경 | 1800초 이상 | 단일 모드 유지 | 노드 전환과 동시 속도 측정 줄이기 |
| 인스턴트 메시지 우선 | 900초 | 계속 켜기 | 백그라운드 실행을 허용해 시스템이 프로세스를 반복 종료하지 않도록 하기 |
조합 1: 하루 종일 온라인
- 구독 자동 업데이트를 24시간마다 한 번으로 설정합니다.
- 상태 확인 간격을 900초 또는 1800초로 설정하고 지연 확인을 활성화합니다.
- 지연 시간이 안정적인 노드를 선택하고, 자동 선택 때마다 전체 그룹의 속도를 측정하는 전략은 사용하지 않습니다.
- TUN 또는 시스템 VPN을 유지하고 클라이언트에 필요한 백그라운드 활동을 허용합니다.
- 실시간 로그 화면과 연결 목록은 닫아 두고 문제가 있을 때만 잠시 엽니다.
조합 2: 필요할 때만 연결
- 시스템의 항상 켜진 VPN을 끕니다.
- 클라이언트 빠른 전환 버튼을 Android 빠른 설정 또는 iOS 제어 센터에 추가합니다.
- 사용을 마친 뒤에는 화면만 닫지 말고 클라이언트의 중지 버튼으로 VPN을 종료합니다.
- 다음에 시작할 때 먼저 구독 업데이트 시간을 확인한 뒤 수동 새로 고침 여부를 결정합니다.
조합 3: 약한 신호에서 배터리 사용 시간 우선
- 지하철, 엘리베이터 또는 신호가 불안정한 지역에서는 노드 속도 측정을 피합니다.
- 상태 확인 간격을 1800~3600초로 늘립니다.
- 최근 안정적인 노드 하나를 고정해 자동 전환을 줄입니다.
- 불필요한 클라우드 드라이브 동기화, 사진 백업, 백그라운드 동영상 재생을 일시 중지합니다.
- 네트워크가 안정된 뒤 구독 업데이트와 노드 사용 가능 여부 확인을 실행합니다.
재현 가능한 데이터로 최적화 효과 검증하기
참고 테스트는 다음 조건으로 진행할 수 있습니다. Pixel 8, Android 15, 약 -48 dBm의 Wi-Fi 신호, 정상적인 배터리 상태, 화면을 끈 2시간입니다. 노드 76개가 포함된 구성에서 300초 전체 상태 확인을 사용하면 2시간 동안 배터리가 3% 감소했고, 1800초로 변경하고 지연 확인을 활성화하자 1% 감소했습니다. 같은 기기에서 VPN을 끈 대조군도 1% 감소했습니다. 이 수치는 테스트 방법을 설명하기 위한 예시이며 모든 휴대전화에서 같은 결과가 나온다는 의미는 아닙니다.
iPhone 15와 iOS 18.6에서 진행한 4시간 유휴 테스트에서는 안정적인 노드와 온디맨드 연결 규칙을 사용할 때 배터리가 2% 감소했고, 빈번한 자동 속도 측정과 여러 차례의 Wi-Fi·셀룰러 네트워크 전환을 켜면 5% 감소했습니다. iOS 배터리 표시는 정수 백분율로 기록되므로 2시간보다 짧은 테스트는 오차가 큽니다. 따라서 4시간 또는 하룻밤 결과를 비교하는 편이 적합합니다.
각 테스트에서는 한 번에 변수 하나만 바꾸세요. 예를 들어 먼저 상태 확인 간격만 조정하고, 다음 테스트에서 DNS를 조정한 뒤, 마지막으로 TUN 설정을 비교합니다. 설정 다섯 가지를 동시에 바꾸면 배터리 소모가 줄어도 실제로 효과가 있었던 항목을 알 수 없습니다. 테스트할 때는 실내 온도, 신호 유형, 노드, 다운로드 활동, 화면 사용 시간도 기록해야 합니다.
배터리 소모가 계속 비정상일 때의 점검 순서
1단계: 자동 작업 일시 중지
자동 속도 측정을 끄고 상태 확인을 잠시 3600초로 변경한 뒤 구독 자동 업데이트를 일시 중지합니다. 화면을 잠근 상태로 2시간 테스트하세요. 배터리 소모가 뚜렷하게 줄면 기능을 하나씩 다시 활성화합니다. 변화가 없다면 문제는 노드 연결, 다른 백그라운드 앱 또는 시스템 네트워크 환경에서 비롯되었을 수 있습니다.
2단계: 반복 오류 확인
실행 로그를 열어 3~5분 동안 관찰하면서 `timeout`, `network is unreachable`, `connection reset` 및 연속적인 DNS 실패를 중점적으로 확인합니다. 같은 대상에서 몇 초 간격으로 오류가 반복되면 연결이 계속 재시도되고 있을 수 있습니다. 먼저 안정적인 노드로 바꾼 다음 DNS와 IPv6 구성을 점검하세요.
3단계: Wi-Fi와 모바일 네트워크 비교
안정적인 Wi-Fi에서 한 차례 테스트한 뒤 4G 또는 5G에서도 같은 시간 동안 테스트합니다. 모바일 네트워크에서만 문제가 발생한다면 먼저 신호 세기와 네트워크 방식 전환을 확인하세요. 휴대전화가 5G, 4G, 서비스 없음 상태 사이를 자주 오가면 프록시를 꺼도 배터리가 크게 소모될 수 있습니다.
4단계: 구성 규모 확인
규칙 집합이 너무 크면 시작 시 파싱 시간과 메모리 사용량이 늘어나지만, 안정적으로 실행된 뒤의 주요 부담은 대개 실제 네트워크 활동에서 발생합니다. 잠시 간소화된 구성으로 테스트하면서 프록시 그룹 하나, 소수의 규칙, DNS 구성 하나만 남겨 보세요. 간소화된 구성에서 정상으로 돌아오면 규칙 제공자와 프록시 제공자를 단계적으로 추가합니다.
5단계: 클라이언트와 코어 업데이트
클라이언트가 유지 관리되는 버전을 사용하는지 확인하고 코어 버전과 업데이트 기록을 살펴보세요. mihomo의 버전에 따라 모바일 네트워크 전환, DNS 캐시 또는 TUN 연결 문제가 수정되었을 수 있습니다. 업그레이드 전에 현재 구성을 내보내고, 업그레이드 후에는 먼저 기존 구성으로 다시 테스트하세요. 많은 매개변수를 동시에 바꾸지 마세요.
절전 설정 결론
Clash 모바일에서 배터리를 절약하는 핵심은 모든 백그라운드 기능을 단순히 끄는 것이 아니라 의미 없는 깨움과 재연결을 줄이는 것입니다. 상태 확인을 900~1800초로 유지하고 지연 확인을 활성화하며, 고빈도 전체 노드 속도 측정을 중지하고 안정적인 DNS와 노드를 사용하면 클라이언트를 반복 종료하는 것보다 대체로 효과적입니다.
Android에서는 시스템 배터리 최적화와 VPN 백그라운드 서비스의 충돌을 해결해야 하며, iOS에서는 온디맨드 연결, 네트워크 확장 상태, 저전력 모드에서의 작동을 확인해야 합니다. TUN 모드는 노드가 안정적이고 규칙에 연결 루프가 없으며 네트워크 환경이 안정적이라는 전제에서 장기간 유지할 수 있습니다. 변경을 완료한 뒤 2~4시간의 유휴 비교 테스트로 결과를 검증하고 추가 조정 여부를 결정하세요.