트래픽 소모, 백그라운드 재시작, 배터리 사용량 집계를 구분하세요
먼저 실제 배터리 소모 속도를 확인한 다음 배터리 사용량 화면에서 Clash Meta의 순위를 살펴보세요. 안드로이드 VPN은 다른 앱의 연결을 한곳에서 처리하므로 시스템에서 일부 네트워크 활동을 VPN 앱의 사용량으로 집계할 수 있습니다. 배터리 소모 비율이 가장 높다고 해서 엔진이 계속 CPU를 최대한 사용한다는 뜻은 아닙니다. 지속적인 다운로드, 클라우드 사진 백업, 동영상 재생, 이동통신 신호 약화가 프록시 처리보다 배터리를 더 많이 소모할 수도 있습니다.
Clash Meta는 클라이언트와 엔진 관련 명칭이고, mihomo는 널리 쓰이는 엔진 이름입니다. 안드로이드 클라이언트마다 설정 위치, 설정 덮어쓰기, 백그라운드 서비스 구현 방식이 다릅니다. 문제를 확인하기 전에 클라이언트 버전, 엔진 버전, Android 버전, 현재 설정 이름을 기록하세요. Linux의 systemd 백그라운드 실행 방법이나 TUN 권한 명령을 휴대폰에 그대로 적용하지 마세요.
같은 조건으로 두 차례 측정하세요
- 신호가 안정적인 Wi-Fi를 사용하고 신호 세기, 화면 밝기, 백그라운드 동기화 설정을 동일하게 유지하세요. 먼저 다운로드와 백업을 일시 중지하고, 부팅 직후나 시스템 업데이트 중, 충전 후 발열이 남아 있는 시간은 피하세요.
- 화면을 끈 상태로 60분 동안 측정하고 시작·종료 배터리 잔량, 연결 끊김 여부, 기기 발열 여부를 기록하세요. 프록시를 끈 비교 테스트에서도 앱 부하는 동일하게 유지해야 합니다. 네트워크에 연결할 수 없어 앱 동기화가 중단된다면 그 결과는 직접 비교하기 어렵습니다.
- 같은 앱을 같은 시간 동안 사용해 화면을 켠 상태에서도 테스트하세요. 동영상 화질, 게임 프레임 속도, 네트워크 방식이 바뀌면 기준 데이터를 다시 측정해야 합니다.
예를 들어 기록상 60분 동안 배터리가 80%에서 77%로 줄었다면 해당 테스트에서 3%p 감소한 것입니다. 이는 계산 예시일 뿐 Clash Meta의 실측 기준이 아닙니다. 배터리 잔량은 반올림되므로 한 번 1% 줄어든 결과만으로 최적화 효과를 판단하기 어렵습니다. 최소 두 번 반복하고 발열, 재연결 횟수, 알림 도착 여부도 함께 기록하세요.
상태 확인: 간격을 늘린 뒤 중복 측정을 줄이세요
노드 속도 측정은 네트워크 요청을 발생시킵니다. 노드가 많고 측정 간격이 짧으면 직접 웹을 탐색하지 않아도 주기적으로 연결이 발생합니다. 모바일 네트워크에서는 이런 요청으로 무선 모듈이 저전력 상태에서 자주 깨어날 수 있습니다. 먼저 proxy-providers의 상태 확인 설정을 살펴본 다음, url-test, fallback 등의 프록시 그룹에서 같은 종류의 테스트를 별도로 수행하는지 확인하세요.
| 항목 | 용도 | 조정 시작값 |
|---|---|---|
health-check.interval | Provider 노드 상태 확인 간격(초) | 먼저 900초로 설정 |
health-check.lazy | Provider를 사용하지 않을 때 주기 확인 건너뛰기 | 필요에 따라 true로 설정 |
proxy-providers.*.interval | HTTP 유형 Provider의 설정 업데이트 간격 | 86400초부터 시험 |
proxy-groups.*.interval | 자동 선택 프록시 그룹의 측정 간격 | Provider와 중복되는지 확인 |
아래는 기존 Provider 항목에 합쳐 넣는 일부 필드이며, 전체 구독 설정이 아닙니다. 해당 항목의 기존 type, url, path, 상태 확인용 url은 유지하세요. 테스트 주소는 접근이 확인된 주소를 사용하고, 예시를 그대로 적용하려고 임의로 바꾸지 마세요.
interval: 86400
health-check:
enable: true
interval: 900
lazy: true
예를 들어 80개 노드를 60초마다 측정하고 매회 전체 검사를 한 시간 동안 수행하면 이론상 약 4,800회의 노드 테스트가 발생합니다. 간격을 900초로 늘리면 약 320회입니다. 이 계산에는 재시도, 최초 로드, 수동 측정이 포함되지 않으며 실제 HTTP 요청 횟수나 절전 비율을 뜻하지도 않습니다. 노드가 불안정하다면 300초부터 시작해 전환 속도와 백그라운드 활동 사이에서 단계적으로 조정하세요.
- 구독 업데이트와 노드 속도 측정은 따로 조정하세요. 설정을 매일 업데이트한다고 노드 확인도 하루에 한 번만 하는 것은 아닙니다. 두
interval은 서로 다른 계층에 있습니다. - 중복 확인을 줄이세요. 같은 노드가 여러 자동 선택 그룹에서 참조된다면 각 그룹의 설정도 확인하세요. Provider만 수정했다고 모든 자동 탐색이 중단된 것은 아닙니다.
- 실제로 적용된 설정을 확인하세요. 클라이언트의 설정 덮어쓰기, 구독 업데이트, 앱 화면의 설정이 파일 내용을 덮어쓸 수 있습니다. 다시 불러온 뒤 실행 설정이나 로그에서 확인 주기를 살펴보세요.
로그, 대시보드, 재시도: 불필요한 백그라운드 작업 줄이기
일상적인 사용에는 먼저 info를 사용하고, 배터리 문제를 확인할 때 warning을 시험해 보세요. 상세 로그는 보관 기간도 짧게 설정하는 것이 좋습니다. debug는 문제를 잠깐 재현할 때 적합하며 밤새 켜 두고 관찰하는 용도로는 적합하지 않습니다. 로그 양은 연결 수와 클라이언트 구현에 따라 달라지므로 로그 수준을 바꾸는 것만으로 일정한 비율의 절전 효과를 기대할 수는 없습니다.
log-level: warning
계속 갱신되는 연결 목록, 실시간 속도 그래프, 외부 컨트롤 패널을 닫으세요. 화면이 꺼진 뒤에도 클라이언트가 이런 화면을 갱신하는지는 구현에 따라 다르므로, 먼저 패널을 닫고 다시 측정해 보세요. 발열이 눈에 띄게 줄었다면 화면 갱신, 로그 기록, 실제 트래픽 중 무엇이 차이를 만든 것인지 추가로 구분해야 합니다.
상세 로그는 몇 분만 켜고 반복 이벤트를 확인하세요
- 연결 시간 초과가 반복됨: 먼저 안정적인 노드로 바꾸고 재시도가 줄어드는지 확인하세요. 시간 초과를 짧게 설정한다고 항상 배터리가 절약되는 것은 아닙니다. 실패 후 재연결이 잦아질 수 있습니다.
- DNS 요청 실패가 반복됨: 상위 DNS 서버에 접근할 수 있는지, 사용할 수 없는 노드를 통해 연결하는지, DNS 조회가 순환하는지 확인하세요. DNS 서버 수를 무작정 늘리는 방식으로 해결하지 마세요.
- 설정이 반복해서 로드되거나 엔진이 재시작됨: 속도 측정 간격을 더 줄이기보다 백그라운드 제한, 클라이언트 비정상 종료, 자동 전환 스크립트를 먼저 확인하세요.
로그를 공유하기 전에 구독 주소, 인증 정보, 노드 비밀번호, 접속 도메인을 삭제하세요. 연결이 끊긴 시점부터 복구될 때까지 확인할 수 있으면 충분하며, 보통 하루치 전체 로그는 필요하지 않습니다. 연결이 안정되면 로그 수준을 평소 사용 값으로 되돌리세요.
배터리 최적화 예외: 백그라운드 실행 안정성을 위한 설정이지 절전 기능이 아닙니다
배터리 최적화 예외는 시스템의 백그라운드 실행 제한을 줄여 줍니다. 화면이 꺼진 뒤 네트워크 연결이 끊기거나 VPN이 종료되거나 예약 작업이 늦어지는 문제를 해결할 수는 있지만, 배터리 소모를 자동으로 줄여 주지는 않습니다. 클라이언트가 이미 안정적으로 실행된다면 ‘절전’을 위해 자동 실행, 백그라운드 활동, 고배터리 사용 권한을 모두 허용할 필요는 없습니다.
반대로 시스템이 앱을 계속 종료했다가 다시 시작하면 VPN을 재설정하고 도메인을 조회하며 노드에 연결하는 작업이 반복됩니다. 화면을 켜면 바로 복구되지만 몇 분 후 화면을 끄면 연결이 끊기는 경우에는 상태 확인 같은 주기 작업을 조정하기 전에 서비스 안정성부터 해결하세요.
| 기기 | 일반적인 설정 위치 | 확인할 항목 |
|---|---|---|
| Pixel / 순정에 가까운 Android | 설정 → 앱 → Clash Meta → 앱 배터리 사용량 → 백그라운드 사용 허용 | 필요하면 제한 없음으로 설정하고 화면이 꺼진 상태에서 연결 확인 |
| 샤오미 MIUI / HyperOS | 앱 정보 → 배터리 절약 → 제한 없음; 설정에서 ‘백그라운드 자동 시작’ 검색 | 기기를 재부팅한 뒤 예상대로 시작되는지 확인 |
| Samsung One UI | 설정 → 애플리케이션 → Clash Meta → 배터리 → 제한 없음 | 절전 앱 또는 초절전 앱에 등록되어 있는지 확인 |
| OPPO / OnePlus | 앱 정보 → 배터리 관리 → 백그라운드 활동 허용 | 화면을 꺼도 서비스가 계속 실행되는지 확인 |
| vivo / iQOO | 설정 → 배터리 → 백그라운드 배터리 사용 관리 | 필요한 경우에만 백그라운드 고배터리 사용과 자동 시작 허용 |
위 항목은 일반적인 메뉴 이름이며 Android 버전, 지역별 펌웨어, 제조사 버전에 따라 이름이 달라질 수 있습니다. 메뉴를 찾기 어렵다면 앱 아이콘을 길게 눌러 ‘앱 정보’로 이동하거나 시스템 설정에서 ‘배터리 최적화’, ‘백그라운드 활동’, ‘자동 시작’을 검색하세요. 최근 앱 화면에서 앱을 잠그는 기능은 일부 제조사의 추가 설정일 뿐 배터리 권한 설정을 대신하지 않습니다.
Android VPN과 TUN: 어떤 앱의 트래픽을 처리할지 먼저 결정하세요
안드로이드 클라이언트는 보통 시스템의 VpnService로 가상 네트워크 인터페이스를 만든 다음 데이터를 프록시 엔진에 전달합니다. Linux에서 tun.enable을 활성화하고 경로를 설정해 네트워크 권한을 부여하는 방식과는 다릅니다. 앱 화면의 ‘VPN 모드’가 직접 편집할 수 있는 동일한 YAML 설정을 뜻하는 것도 아닙니다.
브라우저, 메신저, 프록시 설정을 지원하지 않는 앱까지 함께 라우팅해야 한다면 VPN 연결 방식이 보통 더 편리합니다. 수동 프록시를 지원하는 일부 앱만 연결하면 된다면 ‘로컬 프록시 포트’와 VPN 모드를 비교해 볼 수 있습니다. 다만 클라이언트가 프록시 서비스만 실행할 수 있는지, 대상 앱이 실제로 해당 프록시를 사용하는지 확인하세요.
트래픽 처리 범위를 줄일 때 확인할 세 가지
- 프록시가 필요 없는 트래픽은 앱별로 우회하세요. 클라이언트의 ‘접근 제어’ 또는 ‘앱별 프록시’에서 앱을 선택하고, 현재 설정이 ‘선택한 앱만 프록시 사용’인지 ‘선택한 앱 우회’인지 확인하세요. 목록의 적용 방식이 반대라면 실제 트래픽 처리 범위가 완전히 달라집니다.
- 규칙의 DIRECT는 VPN 우회를 뜻하지 않습니다. 데이터가 먼저 가상 인터페이스로 들어간 다음 엔진이 판별해 직접 연결할 수 있습니다. 앱별 제외는 보통 더 앞단에서 적용되지만, 구체적인 구현과 DNS 동작은 직접 확인해야 합니다.
- 로컬 포트는 전체 VPN을 대체할 수 없습니다. 예를 들어
127.0.0.1:7890은 클라이언트가 해당 포트를 실제로 열어 둔 경우에만 사용할 수 있습니다. Android의 Wi-Fi HTTP 프록시는 모든 앱이나 UDP 트래픽을 처리하지 않으며 모바일 네트워크에도 자동으로 적용되지 않습니다.
처리 단계를 하나 줄이겠다고 VPN을 성급하게 끄지 마세요. 반드시 작동해야 하는 앱을 정리하고 알림, 웹 페이지, 음성 통화, 모바일 네트워크 전환이 정상인지 확인하세요. 일부 클라이언트는 사용자 영역 네트워크 스택을 선택할 수 있습니다. 이름과 지원 범위는 현재 버전을 기준으로 확인해야 합니다. 모든 휴대전화에 가장 절전 효과가 좋은 스택은 없으며, 변경 후에는 VPN을 다시 연결하고 UDP, IPv6, 도메인 조회를 재시험해야 합니다.
시스템의 ‘항상 VPN 사용’과 ‘VPN 없이 연결 차단’은 주로 연결 정책을 설정하는 기능이지 성능 최적화 기능이 아닙니다. 후자는 제외된 앱이 직접 연결하지 못하게 할 수 있습니다. 앱별 우회를 시험하기 전에 두 옵션을 확인해 시스템이 연결을 차단한 것을 규칙 오류로 오해하지 않도록 하세요.
시스템 배터리 사용량과 ADB로 백그라운드 동작 확인하기
먼저 ‘설정 → 배터리 → 배터리 사용량’에서 프록시 클라이언트의 화면 켜짐 시간, 백그라운드 실행 시간, 해당 시간대의 데이터 사용량을 확인하세요. 제조사마다 집계 기준이 다르며 백그라운드 시간이 길다는 사실만으로 이상 동작을 입증할 수는 없습니다. 네트워크가 안정적인데도 화면을 끈 상태에서 휴대전화가 계속 뜨거워진다면 무한 반복이나 과도한 재시도를 추가로 확인할 필요가 있습니다.
컴퓨터가 있다면 USB 디버깅을 켜고 연결을 승인한 뒤 아래의 읽기 전용 명령을 실행할 수 있습니다. ADB는 Android SDK Platform-Tools에 포함되어 있으며, 이 확인 작업에는 루트 권한이 필요하지 않습니다. 출력이 길 수 있으므로 컴퓨터에 저장한 다음 프로세스 이름, UID, 시간대를 기준으로 검색하는 편이 좋습니다.
adb devices
adb shell pm list packages | grep -i clash
adb shell dumpsys battery
adb shell dumpsys batterystats --charged > battery-session.txt
adb shell dumpsys deviceidle > deviceidle-session.txt
adb shell dumpsys connectivity > connectivity-session.txt
grep은 컴퓨터에서 결과를 필터링하는 명령입니다. Windows PowerShell에서는 Select-String clash로 바꿔 사용할 수 있습니다. 패키지 이름에 clash가 포함되지 않으면 첫 번째 필터에서 결과가 나오지 않을 수 있으므로 전체 패키지 목록에서 실제 클라이언트 패키지 이름을 찾으세요. 다른 클라이언트의 패키지 이름을 그대로 가져와 통계를 해석하지 마세요.
dumpsys battery: 배터리 잔량, 충전 상태, 온도 항목을 확인합니다. 온도 단위는 보통 섭씨의 10분의 1이므로 기기 출력에 맞춰 해석해야 합니다.batterystats --charged: 해당 충전 통계 주기가 시작된 뒤의 기록을 확인합니다. 최근 60분만 따로 집계한 보고서가 아니며 정확한 하드웨어 전력 측정값도 아닙니다.dumpsys deviceidle: 유휴 상태와 관련 예외 목록을 확인합니다. 한 번의 출력만으로 절전량을 계산할 수 있는 것은 아닙니다.dumpsys connectivity: VPN과 기본 네트워크 상태를 확인하는 데 도움이 됩니다. 표시되는 정보는 버전마다 다르며 보고서에 네트워크 식별 정보가 포함될 수도 있습니다.
USB로 연결하면 충전도 함께 이루어져 배터리 소모 비교에 영향을 줄 수 있습니다. 성능 기록과 배터리 소모 테스트는 따로 진행하고, 케이블 연결 중의 배터리 변화를 화면이 꺼진 상태의 소모량으로 간주하지 마세요. 파일을 공유하기 전에는 네트워크 이름, 주소, 앱 사용 정보도 확인해야 합니다.
증상에 맞춰 설정을 좁힌 뒤 일상적인 사용 상태를 확인하세요
| 증상 | 먼저 확인할 항목 | 확인 방법 |
|---|---|---|
| 화면을 끈 뒤 주기적으로 발열 | 상태 확인, 동기화 작업, 재시도 | 900초로 조정한 뒤 60분 테스트 반복 |
| 화면이 꺼지면 연결이 끊기고 켜면 복구 | 배터리 제한, 백그라운드 서비스 종료 | 클라이언트에 필요한 백그라운드 권한만 허용 |
| 모바일 네트워크에서만 배터리 소모가 큼 | 신호, 잦은 네트워크 전환, 노드 재연결 | 안정적인 Wi-Fi에서 비교 테스트 |
| 대시보드를 열 때만 발열이 뚜렷함 | 실시간 갱신, 연결 목록, 상세 로그 | 대시보드를 닫고 평소 로그 수준으로 복원 |
| 앱별 프록시를 조정한 뒤 일부 앱의 연결이 끊김 | 목록 적용 방식, 항상 VPN 사용의 차단 옵션 | 직접 연결 앱과 프록시 앱을 하나씩 확인 |
마지막에는 안정적으로 사용할 설정을 유지하세요. 상태 확인은 900초부터 시험하고, 구독 업데이트는 실제 필요에 맞게 설정하며, 상세 로그는 문제를 재현할 때만 켜세요. 백그라운드 권한은 계속 실행해야 하는 클라이언트에만 부여하세요. 사용할 수 없는 노드를 발견하는 데 시간이 너무 오래 걸린다면 확인 주기를 단계적으로 줄이면 됩니다. 수십 초마다 모든 노드를 측정하는 설정으로 바로 되돌릴 필요는 없습니다.
조정이 끝나면 화면을 끈 상태의 알림 수신, Wi-Fi와 모바일 네트워크 전환, 음성 통화, 재부팅 후 연결 상태를 순서대로 확인하세요. 절전 효과와 연결 안정성을 함께 검증해야 합니다. 발열이나 CPU 사용량이 계속 높다면 클라이언트 및 엔진 버전, 시스템 버전, 최소 재현 설정, 짧은 로그를 제출하세요. 설정 항목의 의미는 설정 참고 자료에서 확인할 수 있으며, 기본 연결 문제는 문제 해결 가이드를 참고하세요.