배터리 소모 원인부터 구분하기: 터널, 앱 트래픽, 백그라운드 작업
휴대폰 상태 표시줄에 VPN이 계속 표시된다고 해서 프록시 코어가 계속 최대 부하로 작동하는 것은 아닙니다. Android 클라이언트는 보통 시스템 VPN 인터페이스로 가상 네트워크 어댑터를 만들고, 트래픽을 코어에서 처리합니다. iOS 호환 클라이언트는 대개 Network Extension의 패킷 터널을 사용합니다. 실제 배터리 소모량은 전송 데이터 양, 잦은 재연결 여부, 셀룰러 신호 안정성에도 영향을 받습니다.
이 글에서 ‘Clash 모바일 클라이언트’는 Clash 또는 mihomo 코어를 사용하는 Android 클라이언트와 관련 구독이나 규칙 형식을 지원하는 iOS 클라이언트를 뜻합니다. 모두 같은 앱은 아닙니다. 특히 iOS에서는 특정 Android 클라이언트의 설정 메뉴나 TUN 스위치, YAML 필드를 그대로 적용할 수 없습니다.
- 터널 처리 비용: 가상 네트워크 어댑터, 규칙 매칭, 프로토콜 암복호화를 거치면서 처리량이 늘어납니다. 동영상 시청, 다운로드, 핫스팟 공유 시 더 두드러집니다.
- 앱 트래픽 비용: 클라우드 사진, 메시지 동기화, 숏폼 동영상 미리 불러오기는 직접 연결되더라도 터널을 통과할 수 있습니다. 규칙을
DIRECT로 설정해도 시스템 VPN 계층을 우회한다는 뜻은 아닙니다. - 예약 작업 비용: 노드 상태 확인, 구독 새로고침, 규칙 세트 다운로드, 실패 후 재시도는 네트워크를 깨웁니다. 작업 간격이 짧을수록 대기 중 절전 효과가 줄어듭니다.
- 무선 네트워크 비용: 약한 신호, Wi-Fi와 셀룰러 간 전환, 반복적인 연결 설정은 무선 모듈이 더 오래 활성 상태를 유지하게 할 수 있습니다.
2시간 대기 테스트로 비교하고 감에 따라 설정하지 않기
먼저 짧은 시간 동안 비교한 뒤 백그라운드 실행 설정을 바꿀지 결정하세요. Android에서는 ‘설정’ → ‘배터리’ → ‘배터리 사용량’에서 확인할 수 있습니다. iOS 18에서는 ‘설정’ → ‘배터리’에서 배터리 그래프와 앱별 활동을 볼 수 있습니다. 제조사에 따라 메뉴 이름이 다를 수 있으니 찾기 어렵다면 시스템 설정에서 ‘배터리 사용량’을 검색하세요.
- 테스트 조건 고정: 같은 장소와 네트워크를 사용하고 시작 배터리 잔량도 비슷하게 맞추세요. 예를 들어 매번 80% 안팎에서 시작합니다. 시스템 업데이트, 사진 백업, 대용량 다운로드는 일시 중지하세요.
- 기준값 기록: 프록시가 필요하지 않은 테스트 시간에는 터널을 끄고, 화면을 잠근 채 2시간 대기합니다. 시작·종료 배터리 잔량, 백그라운드 활동, 네트워크 상태를 기록하세요.
- 현재 설정 기록: 터널과 기존 규칙을 다시 적용한 뒤 화면 잠금 상태로 2시간 테스트합니다. 노드, 속도 측정 주기, 시스템 절전 설정을 한꺼번에 바꾸지 마세요.
- 항목별 재테스트: 자동 속도 측정 주기만 늘리거나 백그라운드 제한 한 가지만 조정하세요. 나머지 조건은 그대로 두고 최소 두 차례 반복합니다.
예를 들어 한 차례 테스트에서 터널을 끄면 80%→78%, 켜면 80%→75%였다면 두 결과의 차이가 3%포인트라는 것만 알 수 있습니다. 이를 곧바로 TUN 탓으로 돌릴 수는 없습니다. 이 수치는 기록 방법을 설명하기 위한 예시이며, 이 사이트의 실측값이나 일반적인 정상 기준이 아닙니다. 두 번째 테스트 중 신호가 약해져 재연결되거나 사진 동기화가 진행됐다면 비교 자체가 의미 없어집니다.
매 테스트에서 다음 여섯 가지를 기록하세요
- 휴대폰 모델, OS 버전, 클라이언트 버전, 클라이언트에 표시된 코어 버전
- 테스트 시작·종료 시간과 배터리 잔량
- Wi-Fi 또는 셀룰러 여부, 신호 안정성
- 터널 상태, 규칙 모드, 선택한 노드
- 자동 속도 측정 주기, 구독 업데이트 주기, 규칙 세트 업데이트 주기
- 화면이 잠긴 동안 연결 끊김·재연결·알림 지연·휴대폰 발열이 있었는지
Android 백그라운드 실행: 연결 끊김 증상에 맞춰 배터리 최적화 설정하기
배터리 최적화 예외는 ‘시스템이 프로세스를 제한해 계속 작동하지 못하는 문제’를 해결하기 위한 설정이지, ‘프록시 트래픽 처리 비용’을 줄이는 설정이 아닙니다. 화면이 잠긴 뒤에도 네트워크가 정상이라면 우선 모든 백그라운드 제한을 해제할 필요는 없습니다. 화면을 잠근 지 몇 분 만에 연결이 끊긴다면 클라이언트의 백그라운드 권한을 확인하세요.
순정 Android 14에서 확인할 순서
- ‘설정’ → ‘앱’ → ‘모든 앱 보기’ → 클라이언트 선택 → ‘앱 배터리 사용량’으로 이동하세요. 일부 기기에서는 메뉴가 ‘배터리’로 표시됩니다. 먼저 백그라운드 사용이 허용되어 있는지 확인하세요.
- ‘제한됨’으로 설정한 뒤 화면을 잠그면 연결이 끊기는 경우 먼저 ‘최적화됨’으로 바꾸고 다시 테스트하세요. 그래도 중단되고 연결을 계속 유지해야 한다면 ‘제한 없음’을 시도해 보세요. 선택지는 OS 버전에 따라 다를 수 있습니다.
- 클라이언트의 VPN 상시 실행 알림도 확인하세요. Android 포그라운드 서비스는 일반적으로 계속 알림을 표시해야 합니다. 알림을 끄는 것을 절전 방법으로 여기지 마세요. 알림이 숨겨지는 것과 서비스가 계속 실행되는지는 별개의 문제입니다.
- 제조사 OS에 ‘자동 실행’, ‘백그라운드 실행’, ‘백그라운드 작업 잠금’ 설정이 따로 있다면 상시 실행이 필요한 클라이언트에만 필요한 항목을 허용하세요. 관련 없는 앱의 제한까지 해제하지 마세요.
시스템 VPN 설정은 순정 Android에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’으로 이동해 해당 클라이언트를 선택하면 확인할 수 있습니다. ‘항상 사용 설정 VPN’과 ‘VPN 없이 연결 차단’을 켠 상태에서 클라이언트가 중지되면 휴대폰 전체의 인터넷 연결이 끊길 수 있습니다. 이는 의도된 보호 동작일 수 있으며 노드 장애라고 단정할 수 없습니다. 문제를 확인하기 전에 두 스위치의 기존 상태를 기록하세요.
TUN과 앱별 프록시 중 선택하기
Android 일반 앱은 데스크톱 브라우저처럼 클라이언트의 HTTP 프록시 포트를 일괄적으로 따르지 않는 경우가 많습니다. 따라서 VPN/TUN을 끄고 로컬 리스닝 포트만 남겨도 휴대폰 전체에서 규칙에 따라 연결되는 것은 아닙니다. 전체 기기의 트래픽을 처리해야 한다면 터널을 유지하세요. 일부 앱만 프록시를 사용하면 된다면 Android VPN 기반 앱 포함·제외 목록을 클라이언트가 지원하는지 확인하세요.
앱별 제외 목록과 YAML의 직접 연결 규칙은 서로 다른 계층에서 작동합니다. 앱별 제외는 클라이언트와 시스템이 지원할 경우 특정 앱이 VPN을 우회하게 할 수 있습니다. 반면 직접 연결 규칙은 보통 트래픽이 코어에 전달된 뒤 직접 연결 경로를 선택합니다. 목록을 수정한 후에는 클라이언트 안내에 따라 연결을 다시 설정하고 브라우저, 메시지, 결제 앱을 각각 확인하세요.
자동 속도 측정과 규칙 세트 업데이트로 인한 깨어남 줄이기
‘속도 측정’에는 지연 시간 확인과 다운로드 속도 테스트가 있습니다. 지연 시간 확인은 요청 크기가 작지만 노드가 많고 주기가 짧으면 연결이 많이 발생합니다. 다운로드 테스트는 실제 데이터를 전송하므로 백그라운드에서 자주 실행하기에 더 적합하지 않습니다. 먼저 클라이언트가 추가로 예약한 전체 노드 순환 속도 측정을 끄고, 구독에 포함된 상태 확인과 자동 선택 그룹을 살펴보세요.
먼저 60초에서 600초로 바꿔 비교하기
노드가 100개인 제공자에서 매번 전체 노드를 확인한다고 가정해 보겠습니다. 주기가 60초면 시간당 약 6,000회, 600초면 약 600회 확인합니다. 노드 수와 주기를 기준으로 계산한 요청 횟수 예시입니다. 실제 횟수는 지연 검사, 실패 재시도, 클라이언트 스케줄링에 따라 달라지므로 배터리 절감량으로 바로 환산할 수는 없습니다.
해당 필드를 지원하는 mihomo 설정에서는 기존 proxy-providers 항목의 health-check에서 다음 필드를 조정할 수 있습니다. 기존에 정상 작동하는 검사 URL은 그대로 유지하세요. 아래는 일부 설정 예시일 뿐, 단독으로 가져올 수 있는 완전한 설정은 아닙니다.
health-check:
enable: true
interval: 600
lazy: true
interval의 단위는 초입니다. lazy: true를 사용하면 제공자를 사용하지 않을 때 정기 상태 확인을 줄일 수 있지만, 현재 연결의 데이터 전송을 중단한다는 뜻은 아닙니다. 설정에 url-test나 fallback 그룹이 있다면 해당 그룹의 검사 설정도 별도로 확인하세요. 제공자 검사와 정책 그룹 검사가 동시에 실행될 수 있으므로 한쪽만 바꿔서는 중복 확인이 없어지지 않을 수 있습니다.
세 가지 업데이트 작업의 주기를 따로 설정하기
| 작업 | 비교 시작값 | 유의 사항 |
|---|---|---|
| 노드 상태 확인 | 600초 주기 | 전환이 느려질 때만 주기를 줄이세요. 모든 노드를 매분 확인할 필요는 없습니다. |
| 구독 자동 업데이트 | 하루 한 번 | 서비스 제공자의 변경 주기에 맞추고 클라이언트와 스크립트가 중복으로 새로고침하지 않도록 하세요. |
| 원격 규칙 세트 업데이트 | 86400초 | 해당 필드를 지원하는 설정에서만 적용할 수 있습니다. 구독 업데이트 주기와 혼동하지 마세요. |
| 다운로드 속도 테스트 | 필요할 때 수동 실행 | 속도 측정은 실제 데이터를 다운로드하므로 상시 백그라운드 작업으로 적합하지 않습니다. |
구독을 업데이트하면 로컬 수정 내용이 덮어써질 수 있습니다. 클라이언트의 덮어쓰기 또는 병합 기능을 우선 사용하고, 구독을 한 번 업데이트한 뒤 최종 적용 설정을 확인하세요. 로그에 같은 규칙 주소의 다운로드 실패가 몇 초마다 반복된다면 모든 업데이트 주기를 늘리는 대신 주소나 네트워크 경로를 수정해야 합니다.
iOS 주문형 연결: 앱 화면 종료와 터널 중지 구분하기
iOS 클라이언트의 메인 화면과 시스템이 관리하는 터널 확장은 서로 다른 구성 요소입니다. 메인 화면이 보이지 않는다고 터널이 중지된 것은 아닙니다. 멀티태스킹 화면에서 앱을 계속 강제 종료하는 것도 믿을 만한 절전 방법이 아닙니다. 클라이언트에서 연결 상태를 확인하고 ‘설정’ → ‘일반’ → ‘VPN 및 기기 관리’ → ‘VPN’에서 현재 구성을 확인하세요.
네트워크 경계가 분명한 환경에 적합한 주문형 연결
주문형 연결은 클라이언트가 시스템 규칙을 설정해 조건에 맞는 네트워크에서 VPN을 연결하거나 해제하는 기능입니다. ‘화면이 꺼지면 연결 해제’와는 다릅니다. Wi-Fi 이름, 네트워크 유형, 도메인에 따라 설정할 수 있는지는 클라이언트에 따라 다릅니다. ‘주문형 연결’ 스위치만 보인다고 적절한 조건까지 이미 설정됐다고 단정하지 마세요.
- 하루 종일 프록시 사용: 우선 연결을 유지하고 잦은 속도 측정을 줄인 뒤, 안정적인 네트워크에서 대기 중 배터리 소모를 살펴보세요.
- 일부 네트워크에서만 사용: 클라이언트가 지원한다면 Wi-Fi나 네트워크 조건을 구체적으로 지정해 주문형 규칙을 설정하고, 해당 네트워크를 벗어난 뒤 상태도 확인하세요.
- 가끔 사용: 필요할 때 수동으로 연결하고 사용을 마치면 클라이언트에서 연결을 해제하는 방법이 가장 확인하기 쉽습니다. 다만 이후 백그라운드 앱은 일반 네트워크를 사용하게 됩니다.
수동으로 ‘연결 해제’를 눌렀는데 바로 다시 연결된다면 버튼 고장이 아니라 주문형 규칙이 여전히 적용되고 있을 수 있습니다. 연결을 잠시 멈추려면 해당 구성의 주문형 연결 스위치도 확인하세요. 반대로 저전력 모드와 백그라운드 앱 새로고침은 VPN 주문형 규칙을 대신할 수 없습니다. 터널을 계속 유지하려고 모든 앱의 백그라운드 새로고침을 켜지 마세요.
증상에 맞게 설정을 좁히고 되돌릴 수 있도록 기록하기
화면을 잠근 뒤 인터넷이 끊기지만 대기 중 배터리 소모는 크지 않음
먼저 Android 백그라운드 제한과 항상 사용 설정 VPN, 또는 iOS 주문형 규칙이 실제로 작동하는지 확인하세요. 연결이 안정된 뒤 배터리 소모를 비교하세요. 터널을 자주 재시작하면서 배터리 사용량을 평가하지 마세요. 연결이 반복해서 복구되는 것만으로도 네트워크 활동이 늘어납니다.
화면이 잠긴 상태에서도 발열이 있고 로그가 계속 쌓임
반복되는 속도 측정, 규칙 다운로드 실패, 노드 재연결, DNS 시간 초과부터 확인하세요. 로그 수준을 클라이언트의 기본 일상 설정으로 되돌리고 지속적인 패킷 캡처와 디버그 로그는 끄세요. 문제 해결에 필요한 짧은 기록만 남기면 됩니다. DNS 문제는 해석 경로를 수정하고, 트래픽 처리를 끄는 방식으로 오류를 덮지 마세요.
셀룰러 네트워크에서만 배터리 소모가 두드러짐
같은 장소에서 먼저 신호 강도를 비교한 다음 안정적인 노드 하나를 고정해 테스트하세요. TUN 스택, MTU, DNS 모드, 프로토콜을 한꺼번에 바꾸지 마세요. 특히 배터리 소모만으로 특정 MTU 값을 그대로 적용해서는 안 됩니다. 대용량 파일을 전송할 때만 문제가 생긴다면 먼저 속도, 발열, 재연결 횟수를 기록하고 네트워크 문제를 추가로 확인하세요.
설정 변경 후 점검 목록
- 화면을 잠근 뒤 30분이 지나도 필요한 앱에서 정상적으로 인터넷을 사용하고 알림을 받을 수 있습니다.
- Wi-Fi와 셀룰러 네트워크를 전환한 뒤 연결이 예상대로 복구되거나 중지됩니다.
- 구독을 한 번 업데이트한 뒤에도 속도 측정 주기와 사용자 지정 규칙이 적용됩니다.
- 동일한 조건으로 2시간 대기 테스트를 두 차례 완료하고, 한 번의 배터리 잔량만으로 판단하지 않습니다.
- 변경한 스위치를 기록해 두세요. 효과가 뚜렷하지 않다면 원래 값으로 되돌리고 조정을 계속 쌓지 마세요.
장기간 사용하기 좋은 설정은 연결이 안정적이고, 백그라운드 작업이 절제되어 있으며, 동작 원인을 설명할 수 있는 조합입니다. Android에서 배터리 최적화 예외를 설정할지는 화면 잠금 후 연결이 끊기는지에 따라 결정하세요. iOS에서 주문형 연결을 사용할지는 사용 환경과 연결 해제 후 네트워크 사용 요건에 따라 결정하세요. 불필요한 작업부터 줄인 다음 시스템의 백그라운드 실행을 조정하는 편이 모든 권한을 한꺼번에 켜는 것보다 원인을 찾기 쉽습니다.