iPhone Clash Battery Drain: Background Activity and Power-Saving Settings

Why Clash keeps working after the iPhone locks

Clash-style clients on iPhone typically create a local VPN through iOS Network Extension. Once connected, network data from websites, messaging apps, and system services enters the packet tunnel first. The Clash core then decides whether to connect directly, use a proxy, or reject the request according to its rules. Even after the main app moves to the background or is removed from the app switcher, the network extension responsible for the tunnel can continue running. That is why a proxy connection does not stop immediately after the screen locks, and why the Battery page may continue to record network activity.

Background operation does not mean the extension runs at full load whenever the screen is off. When there are no network requests, most of its time should be spent waiting. When push notifications, photo sync, mail refreshes, or app requests arrive, it must process connections, query DNS, match rules, and forward data. Actual battery use depends on transfer volume, wake frequency, node quality, DNS settings, log level, and policy-group checks.

Normal network activity that can continue after locking

• Messaging apps maintain connections and receive push notifications.
• iCloud Photos, files, or device backups continue uploading.
• Mail accounts fetch data in the background while system services sync time and account status.
• Policy groups run URL tests or node health checks at their configured intervals.
• Rule providers, proxy providers, or subscriptions send requests when they reach their update interval.
• On-demand rules detect a network change and establish the tunnel again.

Therefore, seeing Clash listed under Settings → Battery does not by itself prove abnormal drain. iOS shows each item’s relative share during the selected period. When other apps are barely used, a network extension that consumes only a small amount of power may still appear as a high percentage. Consider battery loss, background activity time, cellular signal, and actual traffic together.

How to distinguish normal from abnormal battery use

The most useful approach is not to watch a single percentage, but to run a controlled comparison. Before starting, charge the battery above 80%, stop active downloads, pause photo sync, keep the screen off, and use the same Wi-Fi network, location, and roughly the same duration for both rounds. Below 20% battery, system scheduling changes, so that level is not suitable for comparison.

Run a 30-minute comparison test

1. Open Settings → Battery and confirm there has been no large game, video export, or system update during the past hour.
2. Connect to stable Wi-Fi, turn off Personal Hotspot, and switch Clash to your usual profile and rule mode.
3. Lock the screen for 30 minutes. Record the starting and ending battery levels, then check Clash’s background activity.
4. Disconnect Clash’s VPN connection and leave the phone idle on the same network for another 30 minutes.
5. Repeat both rounds once to avoid misreading caused by rounded battery percentages.

One percentage point during a 30-minute test is only a troubleshooting trigger, not a universal standard for every iPhone. Battery capacity, battery health, ambient temperature, and rounded readings all affect the result. More reliable warning signs include persistent heat after locking, a steady drop of several percentage points per hour, a clear rise in background traffic, or the same connection error repeating every few seconds in the runtime log.

Which Battery fields to check

In Settings → Battery, switch to “Show Activity” and review both “Screen On” and “Background” activity. If Clash shows a long background duration but total battery loss is small, the network extension is usually just staying available. If background time, battery share, and cellular data all rise together, continue investigating. Cellular usage is available under Settings → Cellular. Recording the values before and after the test is more useful than looking at a percentage alone.

Frequent health checks are a common source of drain

A URL-test policy group periodically visits a test address and compares the response from candidate nodes. Proxy providers can also be configured with health checks. One request usually uses very little data, but a configuration with 40 nodes and a 30-second interval could theoretically trigger about 4,800 node probes per hour. Poor network conditions add DNS, TCP, or TLS retries, causing frequent wakeups.

There is no need to refresh policy groups every few seconds on a mobile device. For everyday use, start with an automatic test interval of 600 seconds; when routes rarely change, 900 seconds may be reasonable. Run a single manual test only when troubleshooting nodes. With a Clash Meta (mihomo)-compatible configuration, you can also enable lazy latency checks so policies that are not currently in use perform fewer active tests.

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

The subscription address in the example only shows where the field belongs. In actual use, keep your existing valid address. interval: 600 means checking every 600 seconds. tolerance: 100 means the client should not switch frequently when the latency difference between candidates is under 100 milliseconds. The provider’s interval: 86400 updates the configuration file every 24 hours; it is separate from the node health-check interval.

Adjustment order in the client

1. Open Settings → Preferences and look for latency tests, health checks, or policy-group test intervals.
2. Change intervals below 60 seconds to 600 seconds first, then observe for half a day.
3. Turn off automatic testing for unused policy groups and keep one primary automatic-selection group.
4. After updating a subscription, run one manual test instead of repeatedly testing every node.

Field names can differ slightly between clients. If the interface does not provide the relevant switch, edit the YAML only after confirming that you maintain the configuration yourself. A subscription service may overwrite local changes at the next update, so use the client’s override feature when available to preserve interval settings.

Reduce the burden from rules, DNS, and logs

Fewer rules are not always faster. The Clash core uses suitable data structures for domain and IP rules, and a few thousand ordinary rules do not usually cause noticeable drain by themselves. More worthwhile targets include duplicate rule sets, frequently updated remote rules, excessive scripting, and configurations that send every connection through a complex processing chain. On mobile, keep only clear and stable traffic-routing requirements.

Address three rule-configuration issues first

• Remove dead remote rule sets: Repeated requests to unreachable addresses create timeouts and retries.
• Reduce duplicate providers: The same domain category does not need to be loaded separately from multiple sources.
• Lengthen update intervals: Stable rule sets can use an 86400-second interval instead of being fetched every 10 minutes.

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

Rules are still matched from top to bottom. Put frequent, specific local-domain rules earlier in the list and keep MATCH as the final fallback. Do not remove LAN-direct, system-service, or DNS-related rules solely to save power; repeated retries after failed connections may cause more wakeups instead.

Prevent excessive DNS concurrency

Multiple nameserver and fallback entries do not mean every query is always sent to all servers sequentially, but complicated fallback and filtering can increase request volume. On mobile, two stable primary DNS servers are usually enough. When using encrypted DNS, also confirm that the servers are reachable on the current network. If a server frequently times out, every domain lookup may wait and retry.

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

Decide whether to disable IPv6 based on the current network. If your carrier network and home broadband support IPv6 reliably, keep it enabled. If the log repeatedly shows IPv6 connection timeouts while your actual proxy nodes offer only IPv4, consider disabling it. Do not change DNS, nodes, and rules at the same time based only on battery impressions, or you will not know which setting made a difference.

Keep the log level at info or warning

debug logging is useful for briefly locating rule matches, DNS requests, and connection failures, but it is not suitable for all-day use. A high volume of connections continuously generates logs and increases memory and storage activity. After troubleshooting, restore the log level to info; when the configuration is stable and the client supports it, warning may also be appropriate. Do not clear the logs before the issue can be reproduced. A captured three- to five-minute repeating segment is more useful.

How to configure on-demand connections and TUN mode

On-demand connections automatically enable the VPN when conditions are met, such as connecting after leaving home Wi-Fi and disconnecting when returning to a trusted network. With simple rules, this reduces manual work. Conflicting conditions, however, can repeatedly rebuild the tunnel when Wi-Fi and cellular networks switch, router signals fluctuate, or the device wakes.

Keep on-demand conditions specific

• Match only known Wi-Fi SSIDs or network types, and avoid overlapping rules.
• Do not set both “all Wi-Fi connections” and “specified Wi-Fi disconnected” without considering rule order.
• If reconnects occur every few dozen seconds, disable on-demand connections for 30 minutes as a comparison.
• If you often switch networks in subways, elevators, or underground car parks, temporarily disable automatic reconnects to test their battery impact.

If you need rule-based routing all day, one stable connection is often more efficient than repeatedly connecting and disconnecting. If you use it only for a few apps or specific networks, clear on-demand conditions can shorten tunnel runtime. The goal is not to restart the VPN as often as possible, but to reduce unnecessary active processing and failed retries.

TUN mode does not itself mean abnormal drain

Global traffic interception on iOS usually relies on the packet-tunnel capability provided by the system. The client may call it VPN, TUN, or enhanced mode. It handles system traffic, so its coverage is broader than entering an HTTP proxy for one app, but it should not remain under heavy load while idle. Check UDP session counts, connection loops, DNS timeouts, and packet loss at the node instead.

If traffic sniffing is enabled, first confirm that domain-based rule recovery is actually needed. Sniffing reads initial connection information to assist rule matching and adds processing when connection volume is high. Before disabling it, check whether the configuration depends on the recovered domains; otherwise, some rules may fall back to IP matching or the default policy.

Nodes and cellular signal can amplify battery drain

Failed node handshakes, packet loss, and long-distance routes cause repeated retransmissions. Clash may appear to be using the battery, while the actual cause is an unreachable proxy server or poor network quality. First choose a stable node and stop automatic switching. Then check whether the log repeatedly shows errors such as timeout, connection reset, or TLS handshake timeout.

Use concrete measurements to assess a node

• Run five consecutive tests on the same Wi-Fi network. Results that vary slightly between 80 and 130 ms are usually more stable than one result at 60 ms followed by another at 900 ms.
• Low latency in a single test does not make a node suitable for long-lived connections in a lossy network. Switch routes to verify when calls or push notifications disconnect repeatedly.
• Disable a node after three consecutive timeouts instead of letting an automatic policy probe it again every 30 seconds.
• When testing in a weak-signal area, temporarily lock cellular service to LTE for comparison so 5G and LTE switching does not distort the result.

To view cellular mode, open Settings → Cellular → the relevant number → Voice & Data. Availability and naming vary by carrier. Locking to LTE is useful only as a troubleshooting step; once you confirm that network switching is unrelated, restore the previous automatic setting.

Complete a power investigation in order

Changing ten options at once makes the results impossible to interpret. The sequence below starts with common factors that are easy to reverse. Observe for at least 30 minutes after each step; for idle battery drain, six to eight hours is better.

1. Confirm background traffic: Pause photo sync, cloud-drive activity, and system updates to rule out genuine high-volume transfers.
2. Fix one stable node: Temporarily leave automatic selection and check whether heat or rapid drain continues.
3. Lengthen check intervals: Set health checks and URL tests to 600 seconds and disable duplicate testing groups.
4. Inspect the logs: Look for DNS timeouts, handshake failures, or tunnel rebuilds repeating every few seconds.
5. Compare with on-demand connections off: Check whether Wi-Fi and cellular switching is triggering a connection loop.
6. Restore a normal log level: Change debug back to info or warning.
7. Check remote resources: Remove failed rule providers and set stable resources to an 86400-second update interval.
8. Rebuild the VPN configuration: Delete the old VPN configuration and let the client create it again only if the earlier steps fail.

Before deleting a VPN configuration, save the current subscription URL, override rules, and policy selections. Go to Settings → General → VPN & Device Management → VPN, open the relevant configuration, and delete it. Reopen the client and allow it to add the VPN configuration again. Do not delete other VPNs used by an organization or work account.

When to update the client or core

If the issue began after a client update, review that version’s release notes first. If you are using an older build, upgrade to the current stable version available on the download page. The Clash Meta (mihomo) core continues to address protocol, DNS, and networking issues, but configuration compatibility can also change. Export the configuration before upgrading, test the original configuration afterward, and avoid combining an upgrade with a large rule overhaul.

When the battery or system is more likely at fault

If the phone stays warm after Clash is disabled, or several system items show long background activity under Settings → Battery, the issue may not be the proxy configuration. Check Maximum Capacity under Settings → Battery → Battery Health & Charging. Standby drain can change when capacity has fallen significantly, the device has just completed a system upgrade, or Photos is re-indexing. Restarting the device and repeating the same controlled comparison is more effective than repeatedly deleting subscriptions.

Frequently asked questions

Troubleshooting Clash battery drain on iPhone starts by separating “the network extension stays connected” from “the device is under continuous heavy load.” Begin with a controlled comparison, then check frequent health checks, failed remote resources, node reconnects, and complex on-demand rules. Change one variable at a time to identify the setting that truly affects battery life.