What is automatic failover for mobile proxies?

Automatic failover detects when a device has been offline past a configurable threshold and migrates every tunnel on that device to a healthy spare — automatically and without changing the proxy URL, credentials, or IP-reset links. The customer's tool continues working through the donor device.

Does the proxy URL or password change after a failover?

No. The proxy endpoint, port, username, password, subdomain, and IP-reset links all stay identical. The secrets that power the changeip and restartphone links are stored on the proxy record, not the device, so they survive any device swap.

How quickly does failover kick in?

The watchdog scans every 30 seconds. Once your chosen offline threshold elapses — default 10 minutes — the next scan triggers the migration. Total latency from device drop to active donor is roughly threshold + up to 30 seconds for the scan cycle.

What happens if I have both HTTP and SOCKS5 tunnels on the same device?

Failover treats all tunnels on a source device as an atomic group. Both tunnels migrate to the same donor device, guaranteeing the customer still gets one exit IP across both protocols. They never land on separate donors.

What donor selection strategies are available?

Four strategies are available: Idle only, Idle first (default), Any active, and Same token pool only. You can also set soft preferences to prefer the same carrier or token group, and exclude or star specific devices in the Donor Pool tab.

Can I get alerted when a failover happens?

Yes. Three webhook events fire on each transition: proxy.failover.started, proxy.failover.completed, and proxy.failback.completed. Subscribe to them under /webhooks and route to Slack, PagerDuty or any alerting system. Every event is also recorded in the History tab.

What happens when the original device comes back online?

It depends on your failback policy. Always restore (default) quietly migrates the tunnels back after a short delay to absorb flapping. Never restore makes the donor permanent. Manual lets you restore with one click from the History tab whenever you're ready.

Does failover work with rotating and sticky proxy modes?

Yes, both modes benefit automatically. For rotating proxies the next request simply comes from the donor's IP, indistinguishable from a normal IP rotation. For sticky sessions the lease continues on the donor, so the session is preserved at the cost of an exit IP change. No configuration change is needed in either case.

Automatic failover for mobile proxies — never lose a tunnel when a phone drops

The unromantic truth of running mobile proxies at scale: devices fall over. Batteries die, home Wi-Fi drops at midnight, the carrier swaps a cell tower mid-session, Android quietly schedules an OS reboot. Until now your only defence was racing to the panel and hand-picking another device before your customer noticed — or before you had a chance to sleep.

Not anymore. Automatic failover is live. If one of your devices stays offline past the threshold you set, every tunnel attached to it migrates to a healthy spare — automatically, silently, in under a minute. Not a single character of the customer's proxy URL changes: same subdomain, same port, same username, same password, same /changeip and /restartphone links. Only the physical phone behind the endpoint is different.

TL;DR — failover makes your proxy pool self-healing. Turn it on once; the panel handles device drops without waking you up.

Why "reconnect" alone is not enough

Reconnect already runs continuously in the background — the Android agent re-establishes its WebSocket session the moment cellular signal returns. But reconnect only helps when the device comes back. A phone that sits on charge for thirty minutes, stays offline overnight, or hits a hardware failure outside your control leaves reconnect with nothing to do. The tunnel stays dead for that entire window while the customer's scraper, browser or bot tries to use it.

Failover fills that gap. The moment the offline timer elapses — default ten minutes — the system picks a healthy spare from your pool and re-pins the tunnel onto it. Traffic flows from the new phone immediately. The only visible change from the outside world is the exit IP, which is exactly the part of a mobile proxy that is supposed to change. Your customer's tool never needs to be reconfigured.

How automatic failover compares with manual proxy management

Scenario	Without failover	With failover (Nodetonet)
Phone loses signal at 3 am	Tunnel dead until you wake up and act	New device pinned within 10 min; you see it in History at breakfast
Android OS reboot (5-min downtime)	Agent reconnects; brief disruption	Below threshold — reconnect handles it, failover never triggers
Battery fully drained (hours offline)	Customer's job fails; you are chased down	Job continues on donor device; original restored when charged
Permanent hardware failure	Manual re-assignment, customer credentials change	Donor promoted permanently (Never restore mode); credentials unchanged
Multi-protocol pair (HTTP + SOCKS5)	Two tunnels may land on two different spares	Atomic group — both move to the same donor, guaranteed

All tunnels on a device move together — atomically

Many operators open two tunnels on the same phone — one HTTP/HTTPS, one SOCKS5 — so a scraper or browser can test both protocols against the same exit IP. Failover treats every tunnel on a source device as an atomic group: all of them migrate to the same target device.

Without atomic grouping, the HTTP tunnel might land on device B while the SOCKS5 tunnel ends up on device C — silently breaking any customer who expected "same IP, two protocols." The grouped migration guarantees that does not happen. One source device always maps to one donor per failover event, no exceptions.

Donor selection strategies — you stay in control

The Failover button in the top-right of your devices dashboard opens a settings panel where you choose one of four selection strategies:

Idle only — only phones with zero attached proxies can be spares. The most conservative option: it keeps unused devices on standby without concentrating extra traffic on any busy phone. Ideal when you have a dedicated warm-standby pool.
Idle first, busy as fallback — the default. Tries idle devices first; if none are free, picks the least-loaded active device. The right balance for most pools.
Any active — grabs the first online device, ignoring load. Useful in tight pools where you cannot afford to leave any phone unused.
Same token pool only — restricts donor eligibility to devices paired with the same token group. Essential for teams that manage multiple isolated proxy clusters from one panel.

Two soft preferences refine the scoring inside any strategy: prefer same operator (Vodafone falls back to Vodafone, keeping the exit IP region consistent) and prefer same token group. Under the Donor Pool tab you can also exclude specific devices from ever being chosen as a spare — weak-signal phones, models with a failing battery, devices reserved for a specific customer — or star others as preferred candidates to be picked first.

Why do the proxy URL and credentials never change?

When a proxy is created, Nodetonet generates two long random secrets: changeIpSecret and restartPhoneSecret. These secrets are stored on the proxy row itself, not on the physical device. So your /changeip?u=<secret> and /restartphone?u=<secret> links work no matter which phone the proxy is currently pinned to — failover updates the internal device binding, not the URL.

The same holds for every other connection parameter: port, username, password, subdomain, and the automatic IP-rotation schedule. All of those live on the proxy record, and failover never touches them. A customer who saved the proxy credentials on Monday will connect through a donor device on Tuesday without reconfiguring anything. For more background on how proxy records and device bindings interact, see single-device proxies explained and token groups: creating pools.

Failback — what happens when the original device returns

Failover without a clear restoration policy creates its own chaos — you end up with permanently mismatched device/tunnel assignments. Three policies cover every situation:

Always restore (default) — when the original device reconnects and a configurable delay expires (default two minutes, to absorb flapping reconnects), the system quietly moves the tunnel back. From the customer's perspective: zero additional disruption.
Never restore — the donor promotion is permanent. The original device is freed to host new proxies or serve as a spare for other failovers. Use this when a hardware failure is likely permanent or when you simply want simpler steady-state accounting.
Manual — the tunnel stays on the donor until a human clicks Restore in the History tab. This is the right choice after a hands-on intervention: you can inspect the original phone, confirm it is healthy, and then deliberately migrate back on your own schedule.

Visibility — log, history, and webhooks

Every failover event is recorded in the History tab with a full audit trail: which proxy triggered it, source device, donor device, offline duration, donor score, and group size. This gives you exactly the evidence you need if a customer queries an IP change.

Three webhook events fire on each transition, making it easy to pipe alerts into Slack, PagerDuty or your own monitoring stack:

proxy.failover.started — the watchdog detected an offline threshold breach and is selecting a donor
proxy.failover.completed — the donor is active and traffic is flowing
proxy.failback.completed — the original device has been restored

Subscribe to these under /webhooks. If you are already using webhooks for IP-change events, failover events slot into the same subscriber model — subscribe to proxy.failover.completed alongside your existing proxy.ip_changed subscription.

For teams watching pool health at a glance, the devices dashboard shows an EDGE badge on edge-served devices and a MIGRATING state during active failovers, so you always have a live picture of what is happening.

Dry-run: see what would happen before committing

The "What would happen now?" button in the failover settings panel sends a simulation query to the engine. It runs your current selection strategy and preferences against the live pool and returns a list of which devices would be covered and which donors would be chosen — without migrating a single tunnel. Use this to validate your policy before going live, or after changing your Donor Pool exclusions to confirm the result looks right.

Failover, rotating proxies, and sticky sessions

Failover works across all proxy modes. For a rotating proxy, the next request after a failover simply comes from the donor device's IP — indistinguishable from a normal IP rotation. For a sticky session (created by appending -session-XXXX to the username), the sticky lease continues on the donor, so the session is preserved at the cost of an exit IP change. Neither mode requires any configuration change to benefit from failover.

If you are managing a large pool and want to understand the device-selection logic more deeply, round-robin device selection and when to use rotating mobile proxies provide complementary context.

Per-client controls still apply

Failover is invisible to per-client settings. If a proxy has an IP allow-list, domain restriction, quota limit or expiry set on a client credential, those constraints follow the proxy through the failover — they live on the proxy and client records, not on the device. Geo-targeting username modifiers (carrier, country, city) continue to influence device selection where possible, including during donor scoring, so a Turkcell-targeting proxy will prefer a Turkcell donor.

How to turn it on — recommended checklist

Open your devices dashboard and click Failover in the top-right corner.
Flip the master switch to Enabled. The watchdog starts scanning every 30 seconds immediately.
Set the offline threshold to match your workload — ten minutes is strict (good for customer-facing pools), thirty minutes is lenient (good for overnight scraping jobs where brief gaps are acceptable).
Choose a donor selection strategy. Idle first, busy as fallback is the correct default for most operators.
Enable Prefer same operator if consistent carrier geography matters to your customers.
Open the Donor Pool tab and mark any weak-signal or reserved devices as excluded.
Subscribe to proxy.failover.completed on /webhooks so you receive an alert for every completed migration.
Click "What would happen now?" to run a dry-run and confirm the policy makes sense for your current pool.

The defaults — ten-minute threshold, idle-first strategy, always restore, prefer same operator — are sensible for almost every operator. You can leave them as-is and already be in a much better position than manual management. Tune over time using the History tab.

Get started

Failover is available to all Nodetonet accounts with at least two devices in the pool. No upgrade, no extra charge — it is part of the core platform. Create a free account, pair your phones via the mobile proxy setup guide, and enable failover from the devices dashboard. If you have questions or edge cases you want to discuss, reach out at support@nodetonet.com or join the community at discord.gg/nodetonet.