Clash 모바일 배터리 소모가 빠를 때: Android·iOS 백그라운드 연결 유지 및 절전 설정

실제 배터리 소모와 배터리 사용량 집계부터 구분하기

먼저 같은 조건에서 비교한 뒤 설정을 바꾸세요. 상태 표시줄에 VPN 아이콘이 계속 보여도 시스템 터널이 연결되어 있다는 뜻일 뿐, 프로세서가 계속 최대 부하로 작동한다는 의미는 아닙니다. 잠금 화면 상태에서 발열이 뚜렷하거나 대기 중 배터리 소모가 늘거나, 로그에 연결 실패와 재연결이 반복되는지 확인하세요.

Clash는 Android와 iOS에서 완전히 동일한 앱을 가리키는 이름이 아니라, 코어와 설정 생태계를 뜻합니다. Clash Meta는 이후 mihomo라는 이름을 사용합니다. 클라이언트마다 사용하는 코어와 터널 구현, 설정 메뉴가 다를 수 있습니다. 특히 iOS에서 일부 Clash 형식 설정을 가져올 수 있다고 해서 mihomo의 모든 필드를 지원하는 것은 아닙니다. 아래의 시스템 메뉴 경로와 점검 방법은 일반적으로 적용할 수 있지만, 설정 필드는 해당 클라이언트 문서를 기준으로 확인하세요.

30분씩 두 번 테스트해 기준값 만들기

1. 휴대전화를 충전하지 않고 신호가 안정적인 시간대를 선택하세요. 화면 밝기, 네트워크 유형, 노드를 동일하게 유지하고, 테스트 중에는 시스템 업데이트를 다운로드하거나 사진을 대량 동기화하지 마세요.
2. 먼저 클라이언트 연결을 끄고 화면을 잠근 채 30분간 대기한 뒤, 시작·종료 시 배터리 잔량과 네트워크 유형, 기기 발열 여부를 기록하세요.
3. 그다음 같은 조건으로 클라이언트를 켜고 화면을 잠근 채 30분간 대기하세요. 테스트 중 지연 시간을 반복 측정하거나 실시간 로그를 열지 마세요.
4. 두 테스트의 차이가 1%포인트뿐이라면 더 긴 시간 동안 비교해 보세요. 배터리 잔량은 반올림되어 표시되므로 짧은 테스트 한 번만으로 원인을 단정할 수 없습니다.

예를 들어 80%에서 79%로 줄어든 경우와 79%에서 75%로 줄어든 경우는 추가 확인이 필요한 차이일 수 있습니다. 다만 이는 기록 방법의 예시일 뿐, 특정 클라이언트의 실측 결과가 아닙니다. 신호가 약하거나 백그라운드 백업이 진행 중인 경우, 배터리가 노후된 경우에도 차이가 생길 수 있으므로 배터리 사용량 순위 화면만 보고 결론을 내리지 마세요.

TUN 상시 연결: 트래픽 제어는 유지하고 터널 중복은 줄이기

Android 클라이언트는 보통 시스템 VPN 서비스를 통해 트래픽을 처리하며, 일부 앱에서는 관련 옵션을 VPN 또는 TUN이라고 부릅니다. iOS 클라이언트는 일반적으로 시스템에서 제공하는 Network Extension 터널을 사용합니다. 휴대전화에서는 시스템 프록시 설정이 모든 앱의 트래픽에 적용되지 않을 수 있으므로, 두 플랫폼 모두 데스크톱처럼 “TUN을 끄고 시스템 프록시만 사용”하는 방법을 그대로 적용하면 안 됩니다.

먼저 트래픽을 제어하는 기능이 중복 실행되는지 확인하기

• 다른 VPN, 방화벽 또는 로컬 VPN 방식의 필터링 앱을 잠시 중지한 다음 대상 클라이언트를 실행하세요. 동일한 시스템 사용자나 프로필 범위에서는 이런 도구들이 각자 별도의 활성 VPN 터널을 유지하지 못하는 경우가 많습니다.
• 클라이언트 상태가 “연결됨”과 “연결 중” 사이를 반복하는지 확인하세요. 수십 초마다 재연결된다면 먼저 재연결 문제를 해결하고, 백그라운드 유지 옵션을 더 추가하지 마세요.
• Wi-Fi에 연결된 상태에서 테스트한 다음 모바일 데이터에서도 테스트하세요. 신호가 약하거나 네트워크를 전환할 때만 발열이 발생한다면 TUN 구현을 바로 의심하기보다 네트워크와 노드를 먼저 확인하세요.

규칙 모드는 이미 제어 대상으로 지정된 트래픽의 출구만 결정합니다. DIRECT와 일치하는 연결도 클라이언트를 거칠 수 있으므로 터널을 완전히 우회한다는 뜻은 아닙니다. Android 클라이언트가 앱별 프록시를 지원한다면 VPN으로 처리할 필요가 없는 앱을 우회시켜 불필요한 처리를 줄일 수 있습니다. 다만 목록이 “선택한 앱만 프록시”인지 “선택한 앱 우회”인지 확인하세요. 두 설정은 적용 방향이 반대입니다.

일반적인 iOS 소비자용 클라이언트는 Android처럼 임의의 앱을 선택해 트래픽을 분리하지 못할 수 있습니다. 같은 이름의 옵션을 찾으려고 시스템 설정을 계속 바꾸지 마세요. 조직에서 관리하는 기기라면 앱별 VPN 기능이 관리 정책의 제한을 받을 수도 있습니다.

Android 백그라운드 연결 유지: 실제로 제한된 클라이언트만 허용하기

화면을 잠근 뒤 연결이 끊기고 배터리 소모가 커지는 현상은 같은 반복 과정에서 생길 수 있습니다. 시스템이 클라이언트를 일시 중지하면 연결이 실패하고, 잠금 해제 후 한꺼번에 재연결하기 때문입니다. 모든 앱을 “제한 없음”으로 설정하지 말고, 먼저 시스템이 실제로 해당 클라이언트를 제한하는지 확인하세요.

시스템 설정 메뉴에서 하나씩 확인하기

• Pixel 등 순정 Android에 가까운 시스템: 「설정」→「앱」→「모든 앱 보기」→대상 클라이언트→「앱 배터리 사용량」으로 이동해 “백그라운드 사용 허용” 등의 옵션을 확인하세요. 일부 Android 버전에는 이 메뉴에 “최적화”와 “제한 없음” 옵션이 있습니다.
• Samsung One UI: 「설정」→「배터리」→「백그라운드 사용 제한」으로 이동해 클라이언트가 “절전 상태 앱” 또는 “초절전 상태 앱”에 포함되어 있는지 확인하세요. 구버전에서는 「배터리 및 디바이스 케어」→「배터리」에 메뉴가 있을 수 있습니다.
• 기타 제조사 커스텀 시스템: 앱 정보에서 “배터리”, “백그라운드” 또는 “자동 시작”을 검색하세요. 프로세스가 종료되거나 재부팅 후 연결이 복구되지 않는 현상이 확인될 때만 필요한 권한을 허용하세요.

한 가지 설정을 바꾼 뒤 화면을 잠근 상태로 15~30분 기다렸다가 잠금을 해제하고 클라이언트의 연결 시간과 로그를 확인하세요. 터널이 계속 유지되고 연결도 정상이라면 백그라운드 유지 권한을 전부 추가할 필요가 없습니다. Android VPN 클라이언트는 작업 유지를 위해 포그라운드 서비스를 사용하는 경우가 많으므로, 알림이 계속 표시되는 것만으로 배터리 이상이라고 볼 수는 없습니다.

iOS 백그라운드 연결: 주문형 규칙을 확인하고 앱 강제 종료는 피하기

iOS의 프록시 터널 확장과 클라이언트의 전면 화면은 서로 다른 생명주기를 따릅니다. 앱 화면을 닫은 뒤에도 터널은 계속 작동할 수 있습니다. “백그라운드 앱 새로 고침”은 모든 VPN 터널의 작동 여부를 결정하는 일괄 설정도 아닙니다. 따라서 매일 클라이언트를 위로 쓸어 올려 강제 종료하는 방식은 절전 방법으로 권장하지 않습니다.

1. 「설정」→「배터리」에서 클라이언트 연결 전후의 활동과 기기 전체 배터리 그래프를 비교하세요. iOS 버전에 따라 “지난 24시간” 또는 날짜별 사용량으로 표시될 수 있으니 현재 시스템에서 제공하는 화면을 확인하세요.
2. 「설정」→「일반」→「VPN 및 기기 관리」→「VPN」으로 이동해 현재 활성화된 구성을 확인하세요. “주문형 연결” 설정은 구성 세부 정보에 있거나 클라이언트에서 관리할 수 있습니다.
3. 수동으로 연결을 끊어도 바로 다시 연결된다면 주문형 연결이 켜져 있는지 확인하세요. 특정 Wi-Fi에 연결할 때만 연결 상태가 반복해서 바뀐다면 해당 네트워크에 적용된 주문형 규칙을 살펴보세요.
4. 먼저 하나의 네트워크에 연결한 채 30분간 관찰한 다음 Wi-Fi와 모바일 데이터 간 전환을 테스트하세요. 주문형 규칙과 DNS, 노드를 한꺼번에 바꾸면 어떤 설정이 효과가 있었는지 판단하기 어렵습니다.

저전력 모드는 일부 백그라운드 활동을 제한하지만, 작동하지 않는 노드나 잘못된 DNS, 반복 실행되는 연결 정책을 자동으로 해결하지는 않습니다. 저전력 모드를 켜도 발열이 계속된다면 더 강력한 절전 옵션을 찾기보다 연결 로그와 트래픽 발생 원인을 확인하세요.

DNS 조회와 실패 재시도: 같은 오류가 반복되는지 확인하기

정상적인 DNS 조회는 대개 캐시를 사용합니다. 도메인 조회 로그가 보인다는 이유만으로 배터리 소모에 문제가 있다고 판단할 필요는 없습니다. 같은 도메인 조회가 짧은 시간 동안 연속 실패하거나, 상위 DNS 서버에 연결할 수 없거나, 조회 경로가 순환하거나, 연결 실패 때문에 앱이 계속 재시도하는 상황을 먼저 살펴보세요.

로그는 잠시 켜고 2~5분간 확인하기

1. 클라이언트 로그 화면에서 timeout, DNS, failed 등의 키워드를 검색해 오류가 계속 반복되는지 확인하세요.
2. 오류가 발생한 시각과 도메인, 상위 서버 주소를 기록하세요. 한 번의 시간 초과는 일시적인 네트워크 문제일 수 있지만, 같은 오류가 연속으로 발생한다면 우선 조치할 필요가 있습니다.
3. Android에서 「설정」→「네트워크 및 인터넷」→「비공개 DNS」로 이동해 현재 설정을 기록하세요. 사용자 지정 호스트 이름이 입력되어 있다면 통제된 테스트에서 “자동”으로 변경해 시스템 설정과 클라이언트 DNS 경로가 어떻게 상호작용하는지 확인할 수 있습니다. 테스트를 마친 뒤 필요에 따라 원래 설정으로 되돌리세요.
4. iOS에서는 추가 DNS 프로파일이 설치되어 있거나 다른 DNS 앱이 활성화되어 있는지 확인하세요. 먼저 동시에 작동하는 요소를 줄이고, 필요한 설정은 클라이언트 안내에 따라 다시 적용하세요.

암호화 DNS 오류를 해결하려고 인증서 검증을 무작정 끄지 마세요. 먼저 시스템 날짜와 네트워크 연결 상태, 상위 서버 설정을 확인하세요. fake-ip도 “켜면 반드시 배터리가 더 들고 끄면 절약되는” 옵션이 아닙니다. 이 설정은 앱 호환성에 영향을 줄 수 있으므로 로그나 재현 절차에서 DNS 문제가 의심될 때만 비교 테스트하세요.

mihomo의 DNS 상위 서버에 접속할 때 프록시가 필요하다면, 부트스트랩 조회와 노드 도메인 조회가 모두 가능한 경로를 확보하세요. DNS 조회가 프록시에 의존하고 프록시도 같은 DNS 결과에 의존하는 상황은 피해야 합니다. 출처가 불분명한 설정을 여러 개 조합하기보다 구독에서 제공하는 기본 DNS 설정을 사용하는 편이 문제를 찾기 쉽습니다. 필드별 의미는 설정 참고에서 확인하세요.

속도 측정, 규칙 세트와 구독 업데이트: 백그라운드 작업 간격 늘리기

배터리 소모가 실제 웹 사용 때문만은 아닐 수 있습니다. 여러 프록시 그룹에서 속도를 자주 측정하거나 규칙 제공자를 반복해서 다운로드하면 백그라운드 네트워크 요청이 늘어납니다. 특히 모바일 데이터 신호가 약하면 작고 잦은 요청도 무선 모듈을 반복해서 활성화할 수 있습니다.

위 표의 값은 비교 테스트를 시작할 때 참고하는 값이며 모든 기기에 최적이라는 뜻은 아닙니다. mihomo에서 url-test 프록시 그룹의 interval과 규칙 제공자의 업데이트 간격은 보통 초 단위입니다. 클라이언트의 구독 업데이트 화면은 같은 단위를 사용하지 않을 수 있습니다. 600초는 10분, 86400초는 24시간이므로 값을 입력하기 전에 단위를 확인하세요.

측정 간격뿐 아니라 중복 측정도 확인하기

예를 들어 설정에 자동 테스트 그룹 4개가 있고 각 그룹에 노드 20개가 등록되어 있으며 60초마다 테스트한다면, 한 주기마다 이론상 80개 항목을 측정하게 됩니다. 실제 요청량은 지연 실행 여부, 그룹 사용 여부, 코어 스케줄링 등에 따라 달라지므로 고정된 요청 수로 볼 수는 없지만, 중복 측정을 점검할 이유는 충분합니다. 사용하지 않는 테스트 그룹을 먼저 삭제하거나, 클라이언트에서 지원한다면 필요할 때만 테스트하도록 설정하세요.

설정을 바꾸기 전에 먼저 복사본을 만드세요. 원격 구독에서 내려받은 YAML을 직접 수정해도 다음 업데이트에서 변경 내용이 덮어써질 수 있습니다. 오버라이드나 병합을 지원하는 클라이언트라면 변경 사항을 유지할 수 있는 전용 메뉴를 사용하세요. iOS 클라이언트가 해당 mihomo 필드를 지원하지 않는다면 자체 “자동 테스트”나 “업데이트 간격” 설정을 조정하고, 호환되지 않는 설정을 억지로 붙여 넣지 마세요.

증상별로 설정 범위 좁히기: 연결 안정성과 배터리 수명

일상적으로는 규칙 모드, 안정적인 활성 노드 하나, 적절한 자동 테스트 간격, 필요한 주기에 맞춘 구독 업데이트, 기본 또는 info 로그 수준으로 시작할 수 있습니다. Android에서는 시스템이 실제로 클라이언트를 종료하는 경우에만 백그라운드 제한을 해제하세요. iOS는 실제 네트워크 사용 방식에 맞춰 주문형 연결을 설정하고 터널을 수동으로 반복해서 켜고 끄지 마세요.

한 번에 하나씩 설정을 바꾸고, 같은 조건의 테스트 시간을 최소 한 번은 확보하세요. 문제가 계속되면 휴대전화 모델, 시스템 버전, 클라이언트 버전, 코어 버전, 네트워크 유형, 시작·종료 시 배터리 잔량과 오류 발생 시각을 정리한 뒤 도움말 센터에서 증상에 맞는 방법을 확인하세요. 로그를 공유하기 전에 구독 링크, 토큰, 노드 주소와 개인 접속 기록을 가리세요. 전체 구독 파일을 그대로 공개 업로드하는 것은 적절하지 않습니다.