iPhone에서 Clash 배터리 소모가 비정상적으로 클 때: 백그라운드 작동 원리와 절전 설정

먼저 잠금 화면 이후에도 Clash가 작동하는 이유부터 알아보기

iPhone의 Clash 계열 클라이언트는 일반적으로 iOS Network Extension을 통해 로컬 VPN을 구성합니다. 연결을 켜면 웹 브라우징, 메신저, 시스템 서비스에서 발생한 네트워크 데이터가 먼저 패킷 터널로 들어간 뒤 Clash 코어가 규칙에 따라 직접 연결, 프록시 또는 차단을 결정합니다. 메인 앱이 백그라운드로 전환되거나 최근 앱 목록에서 시스템에 의해 정리된 뒤에도 터널을 담당하는 네트워크 확장은 계속 실행될 수 있습니다. 잠금 화면 이후에도 프록시 연결이 즉시 끊기지 않는 이유이자, 배터리 화면에 네트워크 활동이 계속 기록될 수 있는 이유입니다.

백그라운드에서 작동한다고 해서 화면이 꺼진 뒤 계속 최대 부하로 실행되는 것은 아닙니다. 네트워크 요청이 없을 때 확장은 대부분 대기 상태에 있어야 하며, 푸시 알림, 사진 동기화, 메일 새로고침 또는 앱 요청이 발생할 때만 연결 처리, DNS 조회, 규칙 매칭과 데이터 전달을 수행합니다. 실제 배터리 소모량은 전송량, 깨우기 빈도, 노드 품질, DNS 설정, 로그 수준, 프록시 그룹 검사에 따라 달라집니다.

잠금 화면 이후에도 나타날 수 있는 정상적인 네트워크 활동

• 메신저 앱이 연결을 유지하고 푸시 알림을 수신합니다.
• iCloud 사진, 파일 또는 기기 백업이 계속 업로드됩니다.
• 메일 계정이 백그라운드 가져오기를 수행하고 시스템 서비스가 시간과 계정 상태를 동기화합니다.
• 프록시 그룹이 설정된 간격에 따라 URL 테스트 또는 노드 상태 검사를 실행합니다.
• 규칙 제공자, 프록시 제공자 또는 구독이 업데이트 주기에 도달하면 요청을 보냅니다.
• 주문형 연결 규칙이 대상 네트워크 변화를 감지하고 터널을 다시 구성합니다.

따라서 Clash가 「설정」→「배터리」 목록에 표시된다는 사실만으로 배터리 소모가 비정상이라고 단정할 수는 없습니다. iOS가 표시하는 값은 선택한 기간 내 항목별 상대 비중입니다. 다른 앱의 사용량이 적으면 네트워크 확장이 소량의 배터리만 사용해도 높은 비율로 표시될 수 있습니다. 판단할 때는 배터리 잔량 감소, 백그라운드 활동 시간, 셀룰러 신호와 실제 트래픽을 함께 확인해야 합니다.

정상적인 배터리 소모와 비정상 소모를 구분하는 방법

가장 효과적인 방법은 한 번의 백분율 수치를 지켜보는 것이 아니라 조건을 고정한 비교 테스트를 진행하는 것입니다. 시작 전에 배터리를 80% 이상 충전하고, 다운로드 중인 콘텐츠를 중지하며, 사진 동기화를 일시 중지합니다. 화면은 꺼진 상태로 유지하고 두 차례 모두 동일한 Wi-Fi, 같은 장소, 비슷한 시간 동안 테스트합니다. 배터리가 20% 미만이면 시스템 스케줄링 정책이 달라지므로 비교에 적합하지 않습니다.

30분 비교 테스트 진행하기

1. 「설정」→「배터리」로 이동해 최근 한 시간 동안 대형 게임, 동영상 내보내기 또는 시스템 업데이트가 없었는지 확인합니다.
2. 안정적인 Wi-Fi에 연결하고 개인용 핫스팟을 끈 다음 Clash를 평소 사용하는 구성과 규칙 모드로 전환합니다.
3. 화면을 잠근 채 30분 동안 그대로 두고 시작·종료 배터리 잔량을 기록한 뒤 Clash의 백그라운드 활동도 확인합니다.
4. Clash의 VPN 연결을 끄고 같은 네트워크에서 다시 30분 동안 그대로 둡니다.
5. 배터리 표시가 정수로 반올림되어 잘못 판단하지 않도록 두 차례 모두 한 번씩 반복합니다.

30분 테스트에서 1% 감소는 문제를 살펴보기 위한 기준일 뿐 모든 iPhone에 적용되는 통일된 표준은 아닙니다. 배터리 용량, 성능 상태, 주변 온도와 배터리 표시의 반올림이 결과에 영향을 줍니다. 더 신뢰할 수 있는 이상 신호는 잠금 화면 이후 지속되는 발열, 매시간 일정하게 수%씩 감소하는 현상, 백그라운드 네트워크 트래픽의 뚜렷한 증가 또는 실행 로그에 몇 초마다 같은 연결 오류가 반복되는 경우입니다.

배터리 화면에서 확인할 항목

「설정」→「배터리」에서 “활동 보기”로 전환한 뒤 “화면 켜짐”과 “백그라운드” 활동을 각각 확인합니다. Clash의 백그라운드 시간이 길게 표시되지만 전체 기기 배터리 소모가 크지 않다면 대개 네트워크 확장이 사용 가능한 상태를 유지하고 있을 뿐입니다. 백그라운드 시간, 배터리 사용 비율과 셀룰러 데이터가 동시에 증가할 때 추가 원인을 찾아야 합니다. 셀룰러 데이터는 「설정」→「셀룰러」에서 확인할 수 있으며, 테스트 전후 수치를 기록하는 편이 백분율만 보는 것보다 명확합니다.

빈번한 상태 검사는 대표적인 배터리 소모 원인

URL 테스트 프록시 그룹은 정기적으로 검사 주소에 접속해 후보 노드의 응답 결과를 비교합니다. 프록시 제공자에도 상태 검사를 설정할 수 있습니다. 요청 한 번의 트래픽은 대개 매우 적지만, 구성이 노드 40개를 포함하고 검사 간격이 30초라면 이론적으로 시간당 약 4,800회의 노드 탐색이 발생할 수 있습니다. 네트워크 상태가 좋지 않으면 DNS, TCP 또는 TLS 재시도가 더해져 기기를 자주 깨울 수 있습니다.

모바일 환경에서 프록시 그룹 새로고침을 몇 초 간격으로 설정할 필요는 없습니다. 일상적인 사용에서는 자동 테스트 간격을 우선 600초로 늘리고, 경로 변화가 적다면 900초로 설정할 수 있습니다. 노드를 수동으로 점검할 때만 테스트를 한 번 실행하세요. Clash Meta（mihomo）호환 구성에서는 지연 검사 지연 실행을 함께 활성화해 현재 사용하지 않는 프록시 그룹의 능동 검사를 줄일 수도 있습니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    use:
      - mobile-provider
    url: http://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100
    lazy: true

proxy-providers:
  mobile-provider:
    type: http
    url: https://example.com/subscription.yaml
    path: ./providers/mobile.yaml
    interval: 86400
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 600
      lazy: true

예시의 구독 주소는 필드 위치만 보여 주는 것이므로 실제 사용 시에는 현재 사용 중인 유효한 주소를 유지해야 합니다. interval: 600은 600초마다 한 번씩 검사한다는 뜻이며, tolerance: 100은 후보 간 지연 시간 차이가 100밀리초 미만일 때 불필요하게 자주 전환하지 않는다는 의미입니다. 제공자의 interval: 86400은 구성 파일을 24시간마다 업데이트하는 설정으로, 노드 상태 검사 간격과는 별개입니다.

클라이언트 화면에서 조정하는 순서

1. 「설정」→「매개변수 설정」으로 이동해 지연 시간 테스트, 상태 검사 또는 프록시 그룹 테스트 간격을 찾습니다.
2. 60초 미만으로 설정된 주기를 먼저 600초로 늘린 뒤 반나절 동안 관찰합니다.
3. 사용하지 않는 프록시 그룹의 자동 테스트를 끄고 주요 자동 선택 그룹 하나만 남깁니다.
4. 구독을 업데이트한 뒤에는 전체 노드 속도 테스트를 연속으로 실행하지 말고 한 번만 수동으로 테스트합니다.

클라이언트마다 필드 이름은 조금씩 다를 수 있습니다. 화면에 해당 스위치가 없다면 직접 관리하는 구성인지 확인한 뒤 YAML을 편집하세요. 구독 서비스가 자동 생성한 구성은 다음 업데이트 때 로컬 변경 사항을 덮어쓸 수 있으므로 클라이언트의 오버라이드 기능으로 간격 설정을 유지할 수 있습니다.

규칙, DNS와 로그 부담 줄이기

규칙 수가 적다고 무조건 더 빠른 것은 아닙니다. Clash 코어는 도메인과 IP 규칙을 적절한 자료 구조로 처리하므로 수천 개의 일반적인 규칙만으로 눈에 띄는 배터리 소모가 발생하는 경우는 드뭅니다. 더 우선적으로 정리할 대상은 중복 규칙 세트, 자주 업데이트되는 원격 규칙, 과도한 스크립트 로직, 모든 연결을 복잡한 처리 체인으로 보내는 구성입니다. 모바일에서는 명확하고 안정적인 트래픽 분할 요구만 우선 남기세요.

규칙 구성에서 먼저 확인할 세 가지

• 사용하지 않는 원격 규칙 세트 삭제: 연결할 수 없는 주소에 계속 요청하면 시간 초과와 재시도가 발생합니다.
• 중복 제공자 줄이기: 같은 도메인 분류를 여러 출처에서 따로 불러올 필요는 없습니다.
• 업데이트 주기 늘리기: 안정적인 규칙 세트는 86400초 주기를 사용하면 되며, 10분마다 가져올 필요가 없습니다.

rule-providers:
  direct-sites:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/direct-sites.yaml
    url: https://example.com/direct-sites.yaml
    interval: 86400

규칙은 여전히 위에서 아래 순서로 매칭됩니다. 자주 사용하고 조건이 명확한 로컬 도메인 규칙은 앞쪽에 배치하고, 마지막에는 MATCH를 최종 대체 규칙으로 남기세요. 배터리를 아끼려고 LAN 직접 연결, 시스템 서비스 또는 DNS 관련 규칙을 함부로 삭제하면 연결 실패 후 재시도가 오히려 기기를 더 자주 깨울 수 있습니다.

DNS 설정에서 과도한 동시 요청 피하기

여러 nameserver와 fallback을 설정한다고 해서 모든 조회가 매번 순차적으로 실행되는 것은 아니지만, 복잡한 폴백과 필터링은 요청량을 늘릴 수 있습니다. 모바일에서는 일반적으로 안정적인 기본 DNS 2개면 충분합니다. 암호화 DNS를 사용한다면 현재 네트워크에서 해당 서버에 연결할 수 있는지도 확인하세요. 서버 시간 초과가 자주 발생하면 도메인 조회마다 대기와 재시도가 반복될 수 있습니다.

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

IPv6를 끌지는 현재 네트워크를 기준으로 판단해야 합니다. 통신사 네트워크와 가정용 인터넷이 IPv6를 안정적으로 지원한다면 유지하세요. 로그에 IPv6 연결 시간 초과가 계속 나타나고 실제 프록시 노드가 IPv4만 제공한다면 그때 비활성화를 고려할 수 있습니다. 배터리 소모만 보고 DNS, 노드와 규칙을 동시에 변경하면 어떤 설정이 영향을 주었는지 확인할 수 없습니다.

로그 수준은 info 또는 warning으로 유지

debug 로그는 규칙 매칭, DNS 요청과 연결 실패를 짧은 시간 동안 확인할 때 적합하며 하루 종일 켜 두기에는 적합하지 않습니다. 연결이 많으면 로그가 계속 생성되어 메모리와 저장소 작업이 늘어납니다. 점검이 끝나면 로그 수준을 info로 되돌리고, 구성이 안정적이며 클라이언트가 지원한다면 warning을 사용할 수도 있습니다. 문제가 재현되기 전에 로그를 지우지 말고 3~5분 동안 반복된 구간을 먼저 추출하는 편이 더 유용합니다.

주문형 연결과 TUN 모드 설정 방법

주문형 연결은 조건을 충족할 때 VPN을 자동으로 켜는 기능입니다. 예를 들어 집 Wi-Fi를 벗어나면 연결하고 신뢰할 수 있는 네트워크로 돌아오면 해제할 수 있습니다. 규칙이 단순하면 수동 조작을 줄일 수 있지만, 조건이 충돌하면 Wi-Fi와 셀룰러 전환, 라우터 신호 변동 또는 기기 깨우기 때 터널을 반복해서 구성할 수 있습니다.

주문형 연결에는 명확한 조건만 남기기

• 알려진 Wi-Fi의 SSID 또는 네트워크 유형만 기준으로 사용하고 범위가 겹치는 규칙을 여러 개 만들지 마세요.
• “모든 Wi-Fi 연결”과 “지정된 Wi-Fi 연결 해제”를 함께 설정하면서 규칙 순서를 무시하지 마세요.
• 수십 초마다 재연결된다면 먼저 주문형 연결을 30분 동안 끄고 비교하세요.
• 지하철, 엘리베이터 또는 지하 주차장에서 네트워크를 자주 전환한다면 자동 재연결을 잠시 꺼서 배터리 소모 변화를 확인할 수 있습니다.

하루 종일 규칙 기반 분할이 필요하다면 안정적인 연결 하나를 유지하는 편이 자주 연결하고 해제하는 것보다 대체로 리소스를 덜 사용합니다. 일부 앱이나 특정 네트워크에서만 사용한다면 명확한 주문형 조건으로 터널 실행 시간을 줄일 수 있습니다. 절전의 목표는 VPN을 최대한 자주 재시작하는 것이 아니라 불필요한 활성 처리와 실패 재시도를 줄이는 것입니다.

TUN 모드 자체가 비정상적인 배터리 소모를 뜻하지는 않음

iOS에서 전역 네트워크를 처리하는 기능은 일반적으로 시스템이 제공하는 패킷 터널 기능에 의존하며, 클라이언트 화면에서는 VPN, TUN 또는 강화 모드라고 부를 수 있습니다. 시스템 트래픽을 처리하므로 단일 앱에 HTTP 프록시만 지정하는 것보다 적용 범위가 넓지만, 정상적인 유휴 상태에서 계속 높은 부하로 실행되어서는 안 됩니다. 실제로 확인해야 할 항목은 UDP 세션 수, 연결 반복, DNS 시간 초과와 노드 패킷 손실입니다.

구성에서 트래픽 스니핑을 함께 켜 두었다면 도메인 기반 복원이 정말 필요한지 먼저 확인하세요. 스니핑은 규칙 판단을 돕기 위해 연결 초기 정보를 읽으며, 연결량이 많을 때 처리 작업을 늘릴 수 있습니다. 끄기 전에는 구성이 스니핑으로 얻은 도메인에 의존하는지 확인해야 합니다. 그렇지 않으면 일부 규칙이 IP 매칭으로 대체되거나 최종 대체 정책으로 처리될 수 있습니다.

노드와 셀룰러 신호도 배터리 소모를 키울 수 있음

노드 핸드셰이크 실패, 패킷 손실과 장거리 경로는 연결 재전송을 반복하게 만듭니다. 겉으로는 Clash가 배터리를 많이 사용하는 것처럼 보여도 실제 원인은 프록시 서버에 연결할 수 없거나 현재 네트워크 품질이 나쁜 것일 수 있습니다. 먼저 안정적인 노드 하나를 선택하고 자동 전환을 중지한 다음, 로그에 timeout, connection reset, TLS handshake timeout 등의 오류가 반복되는지 확인하세요.

구체적인 수치로 노드 상태 판단하기

• 같은 Wi-Fi에서 연속 5회 테스트했을 때 결과가 80~130밀리초 사이에서 조금씩만 변한다면, 한 번은 60밀리초이고 다음에는 900밀리초인 노드보다 일반적으로 더 안정적입니다.
• 패킷 손실이 있는 환경에서는 한 번의 지연 시간이 낮아도 장시간 연결에 적합하다는 뜻이 아닙니다. 음성 통화나 푸시 알림이 반복해서 끊기면 다른 경로로 바꿔 확인하세요.
• 노드가 3회 연속 시간 초과되면 먼저 비활성화하고, 자동 정책이 30초마다 다시 탐색하게 두지 마세요.
• 신호가 약한 지역에서 테스트할 때는 셀룰러 네트워크를 잠시 LTE로 고정해 비교하세요. 5G와 LTE의 잦은 전환이 결과에 영향을 주는 것을 막을 수 있습니다.

셀룰러 모드는 「설정」→「셀룰러」→해당 회선→「음성 및 데이터」에서 확인할 수 있습니다. 이 옵션의 표시 여부와 이름은 통신사에 따라 달라집니다. LTE 고정은 문제를 찾기 위한 단계로만 사용하고, 문제가 네트워크 전환과 무관하다는 것을 확인한 뒤에는 원래의 자동 설정으로 되돌리세요.

순서대로 절전 문제 점검하기

옵션 열 개를 한꺼번에 바꾸면 결과를 참고하기 어렵습니다. 아래 순서는 가장 흔하고 되돌리기 쉬운 요인부터 처리하도록 구성했습니다. 각 단계를 완료한 뒤 최소 30분 동안 관찰하고, 대기 상태의 배터리 소모와 관련된 경우에는 6~8시간 동안 확인하는 것이 좋습니다.

1. 백그라운드 트래픽 확인: 사진, 클라우드 저장소와 시스템 업데이트를 일시 중지해 실제 대용량 전송을 배제합니다.
2. 안정적인 노드 하나로 고정: 자동 선택을 잠시 중지하고 기기가 계속 뜨겁거나 배터리가 빠르게 줄어드는지 확인합니다.
3. 검사 간격 늘리기: 상태 검사와 URL 테스트를 600초로 설정하고 중복 속도 테스트 그룹을 끕니다.
4. 로그 확인: 몇 초마다 반복되는 DNS 시간 초과, 핸드셰이크 실패 또는 터널 재구성을 찾습니다.
5. 주문형 연결을 끈 상태로 비교: Wi-Fi와 셀룰러 전환이 연결 반복을 일으키는지 확인합니다.
6. 정상 로그 수준으로 복원: debug에서 info 또는 warning으로 되돌립니다.
7. 원격 리소스 확인: 사용하지 않는 규칙 제공자를 제거하고 안정적인 리소스의 업데이트 주기를 86400초로 설정합니다.
8. VPN 구성 재생성: 앞의 단계가 효과가 없을 때만 기존 VPN 구성을 삭제하고 클라이언트에서 다시 생성합니다.

VPN 구성을 삭제하기 전에 현재 구독 주소, 오버라이드 규칙과 프록시 그룹 선택을 먼저 저장하세요. 경로는 「설정」→「일반」→「VPN 및 기기 관리」→「VPN」이며, 해당 구성을 연 뒤 삭제를 실행합니다. 클라이언트를 다시 열고 VPN 구성 추가를 허용하면 복구할 수 있습니다. 기업 또는 업무 계정에서 사용하는 다른 VPN은 삭제하지 마세요.

클라이언트 또는 코어를 업데이트해야 하는 경우

특정 클라이언트 업데이트 이후 문제가 시작되었다면 먼저 해당 버전의 변경 기록을 확인하세요. 오래된 빌드를 사용 중이라면 다운로드 페이지에서 제공하는 현재 안정 버전으로 업그레이드하는 것도 좋습니다. Clash Meta（mihomo）코어는 프로토콜, DNS와 네트워크 스택 문제를 계속 수정하지만 구성 호환성도 바뀔 수 있습니다. 업그레이드 전에 구성을 내보내고, 업그레이드 후에는 기존 구성으로 먼저 테스트하세요. 업데이트와 대규모 규칙 변경을 한 번에 진행하지 마세요.

배터리 또는 시스템 문제일 가능성이 높은 경우

Clash를 끈 뒤에도 계속 발열이 발생하거나 「설정」→「배터리」에서 여러 시스템 항목에 장시간 백그라운드 활동이 동시에 나타난다면 문제의 원인이 프록시 구성에 있지 않을 수 있습니다. 「설정」→「배터리」→「배터리 성능 상태 및 충전」에서 최대 용량을 확인하세요. 용량이 크게 줄었거나 기기가 방금 시스템 업그레이드를 마쳤거나 사진을 다시 색인하는 중이면 대기 상태 배터리 소모가 달라질 수 있습니다. 구독을 반복해서 삭제하기보다 기기를 재시동한 뒤 같은 조건으로 다시 비교하는 편이 효과적입니다.

자주 묻는 질문

iPhone에서 Clash 배터리 소모를 점검할 때 핵심은 ‘네트워크 확장이 연결을 유지하는 상태’와 ‘지속적인 고부하’를 구분하는 것입니다. 먼저 조건을 고정해 비교한 다음 빈번한 상태 검사, 사용하지 않는 원격 리소스, 노드 재연결과 복잡한 주문형 규칙을 점검하세요. 매번 변수 하나만 바꿔야 실제 배터리 사용 시간에 영향을 주는 설정을 찾을 수 있습니다.