실제 배터리 소모인지, 배터리 통계의 집계 문제인지 먼저 확인하기
화면을 끈 상태에서 배터리가 얼마나 줄어드는지 기록한 뒤 연결 유지 설정을 조정하세요. 배터리 사용량 목록에서 Clash가 상위에 있다고 해서 프록시 엔진에 문제가 있다고 단정할 수는 없습니다. 다운로드, 동영상 재생, 백그라운드 동기화 트래픽이 VPN 터널을 통과하면 시스템이 일부 네트워크 처리 비용을 VPN 앱에 합산할 수 있습니다. 전체 배터리 감소량, 백그라운드 실행 시간, 전송 데이터량, 발열 여부를 함께 살펴보고 단일 비율만으로 판단하지 마세요.
Android 앱은 보통 VpnService로 트래픽을 처리하며, iOS 앱은 Network Extension의 Packet Tunnel 확장을 사용할 수 있습니다. Clash와 Clash Meta(mihomo)는 관련 엔진 및 생태계 개념이며, 모든 모바일 앱에 같은 설정이 있는 것은 아닙니다. 특히 iOS에서는 해당 앱과 사용 중인 엔진을 먼저 확인하고, Android 배터리 최적화 예외 안내를 그대로 적용하지 마세요.
먼저 점검 기록을 남기세요
- 휴대전화 모델, 운영체제 버전, 앱 버전, 엔진 버전을 기록하세요. 앱 버전은 보통 ‘설정’ → ‘정보’에서 확인할 수 있습니다. 엔진 버전은 시작 로그에서 확인해야 할 수도 있습니다.
- 테스트 시작·종료 시 배터리 잔량, 테스트 시간, Wi-Fi 또는 모바일 데이터 사용 여부, 신호 세기, 화면이 계속 꺼져 있었는지 기록하세요.
- 현재 프록시 모드, 선택한 정책 그룹, 구독 노드 수, 자동 속도 측정·상세 로그·자동 재연결 사용 여부를 기록하세요.
- 현재 설정을 백업하세요. 구독 설정을 덮어쓰는 변경은 앱에서 지원하는 오버라이드 또는 병합 설정에 적용해 다음 구독 업데이트 때 변경 사항이 사라지지 않도록 하세요.
화면을 끈 상태로 두 차례 테스트해 원인을 좁히세요
신호가 안정적인 장소에서 매회 60분씩 관찰하세요. 두 테스트는 가능한 한 같은 네트워크와 비슷한 시작 배터리 잔량으로 진행하고, 대용량 파일 다운로드·시스템 업데이트·사진 백업은 일시 중지하세요. 충전 직후이거나 운영체제 업데이트 후 색인 작업이 진행 중이거나 휴대전화 온도가 크게 오른 경우에는 상태가 안정된 뒤 테스트하세요. 아래의 60분은 원인 파악을 위한 측정 시간이지 배터리 사용 시간 보장이 아닙니다.
- 1차 테스트로 기준을 잡습니다: 프록시 서비스를 잠시 중지하고 시스템 VPN 연결이 끊겼는지 확인한 뒤, 화면을 끄고 60분간 둡니다. 전체 배터리 감소량과 백그라운드 데이터 사용량을 기록하세요. 계속 인터넷 연결이 필요한 작업은 사용하지 않는 시간에 테스트할 수 있습니다.
- 2차 테스트는 기존 설정을 유지합니다: 프록시를 실행하고 평소 사용하는 규칙 모드와 노드를 선택한 뒤, 같은 조건에서 60분간 관찰하세요. 연결 끊김이나 재연결, 지속적인 발열이 있었는지 기록합니다.
- 변수는 하나만 바꾸세요: 2차 테스트에서 배터리 소모가 눈에 띄게 늘었다면 다음 테스트에서는 주기적인 속도 측정만 끄거나 안정적인 노드 하나로만 바꿔 보세요. DNS, 라우팅, 예외 목록, 연결 유지 설정을 한꺼번에 변경하면 원인을 찾기 어렵습니다.
- 한 번의 결과로 결론 내리지 말고 재시험하세요: 배터리 잔량은 정수 단위로 표시되어 짧은 시간에는 오차가 큽니다. 차이가 뚜렷하지 않으면 2~3시간으로 늘리고 다른 날에도 반복하세요.
프록시를 중지해도 배터리가 빠르게 줄어든다면 먼저 약한 신호, 다른 앱의 백그라운드 활동, 시스템 동기화를 확인하세요. 프록시를 켰을 때만 문제가 생긴다면 터널 트래픽, 탐색 작업, 재연결을 점검하세요. 프록시가 필요한 앱은 1차 테스트 중 계속 재시도할 수 있어 기준 결과에 영향을 줍니다. 이런 경우 두 테스트 모두 해당 앱의 백그라운드 작업을 먼저 중지하세요.
Android 배터리 최적화 예외: 계속 실행해야 하는 앱만 허용
배터리 최적화 예외는 시스템이 백그라운드 작업을 제한할 가능성을 낮추는 기능이지, 엔진 자체의 연산량을 줄이는 기능은 아닙니다. 화면을 끈 직후에는 정상인데 시간이 지나면서 연결이 끊기고 화면을 켜면 복구된다면 백그라운드 제한을 먼저 확인하세요. 휴대전화가 계속 뜨겁고 데이터 사용량이 늘고 있다면 ‘제한 없음’으로 설정해도 문제가 있는 작업만 더 오래 실행될 수 있습니다.
운영체제에서 백그라운드 권한 확인하기
- 순정 Android 14에 가까운 기기: ‘설정’ → ‘앱’ → ‘모든 앱 보기’ → 사용 중인 앱 → ‘앱 배터리 사용량’에서 백그라운드 사용 권한을 확인할 수 있습니다. 제조사에 따라 메뉴가 ‘배터리’ 또는 ‘배터리 사용량’으로 표시되며, ‘제한 없음’, ‘최적화’, ‘제한’ 등의 옵션이 제공될 수 있습니다.
- 제조사 맞춤형 운영체제: 앱 정보에서 ‘자동 시작’, ‘백그라운드 활동’, ‘배터리 절약 정책’도 확인하세요. 자동 시작을 허용했더라도 별도의 백그라운드 네트워크 제한이 있는지 계속 살펴봐야 합니다.
- 최근 앱 화면에서 잠금: 일부 운영체제에서는 최근 앱 화면에서 앱을 잠글 수 있습니다. 이 기능은 보통 앱 정리 동작에만 영향을 주므로 배터리 및 백그라운드 권한 설정을 대신할 수 없습니다.
먼저 운영체제의 기본 최적화 설정을 유지하세요. 화면이 꺼진 뒤 실제로 제한되는 것을 확인한 경우에만 프록시 앱에 별도로 예외를 적용하면 됩니다. 인터넷을 사용하는 모든 앱을 예외 목록에 추가할 필요는 없습니다. 설정을 바꾼 뒤 화면을 끄고 30~60분간 관찰하고, Wi-Fi에서 모바일 데이터로 전환한 뒤 연결이 복구되는지도 확인하세요. 화면을 한 번 켰을 때 인터넷이 된다고 해서 백그라운드 연결이 내내 정상적이었다는 뜻은 아닙니다.
상시 알림과 VPN 항상 켜기는 서로 다른 설정입니다
Android의 포그라운드 서비스는 보통 상시 알림을 표시해야 합니다. 알림은 서비스가 실행 중임을 시스템과 사용자에게 알리며, 알림 자체가 주요 배터리 소모 원인인 경우는 드뭅니다. 알림을 숨겨도 프록시가 중지되는 것은 아니며, 알림이 표시된다고 노드 연결이 정상이라는 뜻도 아닙니다.
Android 13 이상에서는 알림 권한과 포그라운드 서비스 요구 사항을 별도로 이해해야 합니다. 알림 권한을 거부해도 포그라운드 서비스가 시스템 관리 대상에서 제외되는 것은 아닙니다. 점검할 때는 서비스 알림을 유지하고 연결 상태를 직접 확인하는 편이 알림을 숨겨 배터리를 아끼려는 것보다 효과적입니다.
시스템의 ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’에서 일부 기기는 ‘VPN 항상 켜기’와 ‘VPN을 사용하지 않는 연결 차단’을 제공합니다. 전자는 선택한 VPN 연결을 유지하고, 후자는 터널을 사용할 수 없을 때 다른 네트워크 연결을 제한합니다. 후자를 켜면 연결이 끊겼을 때 모든 앱의 인터넷 접속이 차단될 수 있으므로 배터리 절약 옵션으로 사용하면 안 됩니다. 메뉴 이름과 지원 여부는 운영체제 및 앱에 따라 다릅니다.
상태 확인과 자동 속도 측정: 주기를 늘리고 대상을 줄이세요
노드 상태 확인은 네트워크 요청을 직접 보냅니다. 요청 하나의 데이터량은 적더라도 네트워크를 자주 깨우고 연결 시간 초과와 암호화 핸드셰이크가 반복되면 백그라운드 처리 비용이 늘어날 수 있습니다. 모바일 네트워크에서는 배터리 소모가 데이터량에 단순 비례하지도 않습니다. 노드가 많은 구독을 사용한다면 프록시 제공자의 상태 확인, 정책 그룹 탐색, 앱 자체의 예약 속도 측정을 각각 확인하세요.
| 점검 항목 | 설명 | 점검 방법 |
|---|---|---|
health-check.interval |
해당 설정을 지원하는 프록시 제공자의 상태 확인 주기(초) | 현재 300초라면 900초로 늘려 보고 노드 전환 속도가 괜찮은지 확인하세요. |
정책 그룹 interval |
url-test, fallback 등 그룹의 주기적인 탐색 간격 |
제공자 상태 확인과 별도로 점검해 여러 곳에서 모두 60초로 설정되지 않았는지 확인하세요. |
lazy |
지원되는 상태 확인 또는 정책 그룹에서 미사용 상태일 때 탐색을 미룰지 설정합니다. | 엔진 문서에서 지원 범위를 확인한 뒤 true 사용을 검토하세요. |
| 앱 자동 속도 측정 | 앱 화면에서 추가로 실행하는 지연 시간 또는 다운로드 테스트 | 예약 작업을 먼저 끄고 필요할 때 수동으로 테스트하세요. |
| 구독 업데이트 주기 | 노드와 설정을 다시 가져오는 작업이며, 노드 속도 측정과는 다릅니다. | 자주 업데이트할 필요가 없다면 12시간 또는 24시간으로 설정할 수 있습니다. |
노드 80개를 60초마다 한 차례씩 모두 확인한다고 가정하면 한 시간에 약 4,800회 탐색이 발생합니다. 주기를 900초로 늘리면 약 320회입니다. 이는 예약 작업 수를 보여 주는 예시이지 실제 배터리 측정 결과가 아니며, 재시도·지연 탐색·다른 정책 그룹 작업은 포함하지 않습니다. 특정 측정에서 몇 KB를 사용했는지만 볼 것이 아니라 주기와 탐색 대상을 먼저 확인해야 한다는 뜻입니다.
노드를 하나 수동 선택해 비교할 수 있지만 제공자의 백그라운드 상태 확인까지 중지된다고 보장할 수는 없습니다. 앱에서 수동 선택으로 전환했는데도 로그에 여러 노드 탐색이 주기적으로 기록된다면 제공자와 앱 차원의 예약 작업을 계속 점검하세요.
재연결·DNS·TUN: 기능을 무작정 끄지 말고 반복 작업을 확인하세요
모바일 기기에서 VPN으로 트래픽을 처리할 때 화면에 ‘TUN 모드’라는 이름이 표시되지 않거나 데스크톱과 같은 설정이 제공되지 않을 수 있습니다. 중요한 것은 이상 동작이 반복되는지 확인하는 것입니다. 네트워크를 전환한 뒤 계속 재연결하거나, DNS 요청이 반복해서 시간 초과되거나, 특정 백그라운드 앱이 연결에 계속 실패하는지 살펴보세요. 정상적인 트래픽 처리와 규칙 매칭에도 비용이 들지만 TUN이 켜져 있다는 이유만으로 문제의 원인이라고 단정하면 안 됩니다.
- 먼저 노드 문제를 확인하세요: 사용 가능한 노드 하나를 고정해 30분간 관찰하세요. 재연결이 눈에 띄게 줄면 기존 노드의 안정성과 자동 전환 조건을 점검합니다.
- 다음으로 DNS 시간 초과를 확인하세요: 로그에 DNS 확인 시간 초과, 연결 실패, 동일 도메인에 대한 반복 요청이 있는지 잠시 살펴보세요. DNS 요청 시간 초과로 상위 앱이 계속 재시도하면 네트워크와 처리 자원이 지속적으로 소모될 수 있습니다.
- 네트워크 설정을 확인하세요: Android의 ‘비공개 DNS’ 또는 다른 DNS 도구를 직접 설정했다면 먼저 현재 값을 기록하세요. 그런 다음 앱 문서를 참고해 설정 간 충돌 가능성을 확인하고 DNS 설정을 여러 곳에서 동시에 임의로 바꾸지 마세요.
- 백그라운드 트래픽의 출처를 확인하세요: 앱의 연결 화면에서 데이터 사용량이나 연결 수를 기준으로 클라우드 저장소 업로드, 사진 백업, 동영상 미리 로드 등의 작업을 찾아보세요. 프록시는 데이터가 지나가는 경로일 뿐, 지속적인 부하는 해당 앱에서 발생할 수 있습니다.
규칙 모드는 일상적인 트래픽 분리에 적합하지만 ‘직접 연결’이라고 해서 데이터가 기기의 VPN 처리를 완전히 우회하는 것은 아닙니다. 트래픽이 터널에 들어간 뒤라면 엔진이 여전히 분류와 전달을 처리할 수 있습니다. 반대로 전역 모드라고 해서 모든 백그라운드 작업이 자동으로 줄어드는 것도 아닙니다. 절전을 위해 모드를 계속 바꾸지 말고 실제 연결 상태와 규칙 적용 결과를 함께 확인하세요.
로그는 짧은 시간만 수집하세요. 로그 수준을 잠시 debug로 바꾸고 2~5분간 문제를 재현한 뒤 info 또는 앱 기본값으로 되돌립니다. 상세 로그를 계속 켜 두거나 실시간 연결 화면을 열어 자주 새로 고치면 추가 작업이 발생합니다. 로그를 다른 사람에게 전달하기 전에 구독 주소, 토큰, 노드 인증 정보 및 기타 민감한 내용을 삭제하세요.
iOS 백그라운드 연결 유지: 앱 화면과 터널 확장을 구분하세요
iOS에는 Android의 ‘제한 없음’에 해당하는 범용 배터리 최적화 예외가 없습니다. Packet Tunnel을 지원하는 앱은 보통 확장이 터널을 처리하므로 앱 화면이 백그라운드로 이동해도 터널이 반드시 중지되는 것은 아닙니다. ‘백그라운드 앱 새로 고침’을 켜도 VPN 확장이 무제한으로 연결을 유지하는 것은 아닙니다. 연결이 계속 유지되는지는 시스템 VPN 상태와 앱의 연결 기록으로 확인하세요.
다음 세 곳을 확인하세요
- 배터리 통계: iOS 18 기준 ‘설정’ → ‘배터리’로 이동해 ‘지난 24시간’ 또는 ‘지난 10일’을 선택하고 해당 시간대의 활동을 확인하세요. 다른 운영체제 버전에서는 통계 기간과 메뉴 위치가 다를 수 있습니다.
- VPN 구성: ‘설정’ → ‘일반’ → ‘VPN 및 기기 관리’ → ‘VPN’으로 이동해 현재 사용 중인 구성을 확인하세요. 다른 앱의 연결을 현재 앱의 연결로 착각하지 않도록 주의하세요.
- 온디맨드 연결: 앱에서 ‘온디맨드 연결’ 또는 자동 연결 규칙을 제공한다면 Wi-Fi와 모바일 데이터 전환 때 반복 실행되는지 확인하세요. 잠시 끄고 비교 테스트를 진행한 뒤 다시 사용할지 결정하세요.
저전력 모드는 일부 시스템 백그라운드 동작을 조정하지만, 이를 근거로 VPN이 반드시 끊기거나 배터리가 반드시 절약된다고 단정할 수는 없습니다. 지속적인 연결이 필요한 경우 저전력 모드를 켠 상태에서 화면을 끈 테스트와 네트워크 전환 테스트를 각각 진행하세요. 앱을 자주 강제 종료하는 것도 보편적인 연결 유지 방법은 아닙니다. 영향은 앱과 운영체제의 구현에 따라 다릅니다.
앱에서 탐색 간격, 로그 수준, 앱별 설정을 제공하지 않는다면 다른 플랫폼의 YAML 설정을 억지로 적용하지 마세요. 앱이 실제로 지원하는 항목을 먼저 확인하고, 노드 고정·예약 속도 측정 줄이기·온디맨드 연결 점검 등 사용할 수 있는 방법으로 비교하세요.
사용 환경에 맞춰 연결 유지 수준을 정하세요
| 사용 환경 | 권장 시작 설정 | 고려할 점 |
|---|---|---|
| 가끔 웹페이지를 확인하는 경우 | 필요할 때만 켜고 끄며 기본 배터리 최적화를 유지하세요. | 사용 전에 직접 연결해야 할 수 있습니다. |
| 메시지와 동기화를 하루 종일 사용하는 경우 | 필요한 Android 백그라운드 권한만 허용하고 적정한 상태 확인 주기를 유지하세요. | 연결을 계속 유지하면 기본적인 배터리 소모가 발생하므로 화면이 꺼진 상태의 안정성을 확인해야 합니다. |
| 출퇴근 중 네트워크를 자주 전환하는 경우 | 안정적인 노드를 우선 선택하고 자동 재연결과 온디맨드 규칙을 확인하세요. | 신호가 약하면 재시도와 네트워크 전환으로 배터리 소모가 늘 수 있습니다. |
| 특정 네트워크에서만 사용하는 경우 | 앱에서 지원하는 네트워크 조건 규칙을 사용하세요. | 네트워크 조건이 바뀌면 터널이 다시 연결될 수 있습니다. |
마지막으로 세 가지만 기록하면 됩니다. 같은 조건에서 화면을 끈 동안의 배터리 감소량, 화면이 꺼진 동안 연결이 끊겼는지, 네트워크 전환 후 연결이 복구되는지입니다. 먼저 중복 탐색과 실패한 재연결을 줄인 다음 필요한 경우에만 백그라운드 권한을 늘리세요. 연결이 안정적이라면 배터리 사용량 순위 때문에 DNS를 반복해서 바꾸거나 규칙을 다시 작성할 필요는 없습니다.
원인을 찾지 못했다면 휴대전화 모델, 운영체제·앱 버전, 엔진 버전, 테스트 시간대, 네트워크 유형, 민감 정보를 삭제한 짧은 로그를 제출하세요. “화면을 끄고 40분 뒤 연결이 멈췄지만 화면을 켜자마자 복구됐다”처럼 설명하면 “배터리가 너무 빨리 닳는다”는 말만 하는 것보다 백그라운드 제한, 노드 문제, 터널 이상을 구분하기 쉽습니다.