Skip to main content
Three symptoms bring people here, and only one is usually the proxy. Work the checks in order and stop at the first one that explains what you see.

​
Is this even broken?

Idle browsers power off after 15 minutes without activity and wake on the next due sync or action, and recurring syncs only start inside the account’s sync window. The power-off and a closed sync window write nothing to the browser event log; the wake writes a started_by_user row, Starting by user: system.

​
Check 1: read the two statuses

The browser and the proxy carry separate statuses, and a dead proxy does not show up as a proxy-named browser status. Read both on the Browser tab of the account drawer (Senders, click the row): the proxy block shows residential or datacenter, country, latency and a Proxy uptime row. Hover the Proxy uptime row to read Proxy status: active | no connection | country mismatch | fraud flagged | replaced. Only two browser statuses point at the proxy: running issue, a runtime fault and where a proxy failure lands, and start issue, frequently a proxy that timed out. login issue is a lost session (Check 6); idle is auto-suspend; subscription required is billing; shared out leaves the proxy with the owning team (full list).
A browser escalates to investigating after more than 10 failures with more than 10 errors in 48 hours, and that state emails the account owner. The failure counter is cleared only when the browser comes back up and reports running, never by time; the 48 hour window applies to the error rows, so once old errors age out the browser stops escalating even though the counter still stands. Proxy failures do not increment it, so proxy errors alone never escalate a browser. One restart attempt is worth it; if it escalates again, open a ticket.

​
Check 2: read the event log

Scroll to Browser event log at the bottom of the same tab, or search it at POST /api/antidetect-browser-logs/search. Match what you see against the exact strings: The 666, -3, -2 and 5xx rows all land as runtime_error: the numeric Code is the only axis that tells them apart, so filter on code, not on a finer event_type. If the newest entry is proxy_replaced with Proxy replaced after failure, the platform already moved the browser onto a healthy proxy but did not restart it: use Start in the row menu.

​
Check 3: run the connectivity check

This is the answer to “is the proxy actually dead”. It performs a real HTTPS request through the proxy and times it. Take the proxy sid (ab_px_...) off the browser row by searching antidetect-browsers with "include": ["antidetect_browser_proxy"]. This check and the location one run over the API and MCP only, with no button in the app, and both require the can_change_proxy permission: a member without it gets a 403.
curl
The result carries total_checked, ok, avg_connection_time_ms (the mean over the rows that answered, null when none did) and failed[], where each entry has an error_kind:
The probe times out at 30 seconds for both connect and read. Only an HTTP 407 from the proxy counts as a failure; any other status, including a 5xx from the probe target, counts as success, because it proves the request was routed. A failed probe flips the proxy to no_connect and a later successful one flips it back to active, but rows already in country_mismatch, fraud_flagged or replaced only get their latency refreshed.
Send exactly one of sid or filter. Both or neither returns 422 with field_errors.sid_or_filter set to Provide exactly one of sid or filter. In filter mode a single call probes at most 50 rows; the response reports the true match count in total_matched and sets truncated: true when the cap was hit.

​
Check 4: run the location check

Run this when the account keeps hitting verification challenges rather than failing to load. It asks several geo vendors and several fraud databases where the exit IP really is. Same request as above with the endpoint swapped for check-proxy-location, same sid or filter rule, same 50-row cap. Two things can trip:
  • Country mismatch. The verdict is the real exit country, measured through the proxy, not a vote among IP databases. If it disagrees with the country the proxy is registered as, the proxy is flagged country_mismatch. The disagreement_pct is context only.
  • Fraud flag. The aggregated score is the highest score any responding database returned.
A proxy is flagged fraud_flagged at an aggregated score of 75 or above. Rows in country_mismatch or fraud_flagged are never handed out to a new browser, and no automatic process returns them to active. Move the affected browser onto another proxy yourself (Check 5) and tell support about the flagged one.
Inconclusive rows are skipped, never flagged: the check needs the through-proxy reading plus at least one other vendor that answered, and a skipped row is not counted in total_checked.

​
Check 5: swap the proxy

Two different operations, one dialog. On Senders, open the account’s row menu, click Change proxy, pick a mode and confirm. Rotating is the safe default. The country dropdown lists only countries that currently have an active proxy in the pool, and blocks the country the browser is already in.
Changing the country flips where LinkedIn thinks the sender is, and doing that mid-campaign is a classic trigger for a verification challenge. Pick the country the account genuinely operates from and keep it.

​
What each swap restarts

Both verbs stop the live session, push the new upstream into the profile, commit, then start the browser again. A running browser keeps egressing through the old proxy until it respawns. The response carries restarted: true|false and restart_error, the literal string restart_failed when the browser could not come back up. In the app that shows the toast “The proxy was changed, but the browser could not be started again. Start it from the row menu.” The swap itself still committed.

​
Swap refusals

Switch on error.field_errors for 422 and on error.context.reason for 409 and 503: the top-level error.code is only validation_failed, conflict or service_unavailable. For a browser you brought yourself the menu item is disabled, with the hover reason “This browser runs on a profile you brought yourself, so its proxy is not ours to change.”

​
Check 6: if it is the session, not the proxy

A browser in login issue is not a network problem. LinkedIn invalidated the session, the status is sticky, and no proxy swap, restart or wait will clear it. During the initial sync the drawer shows Sync paused, action needed with the reason browser:logged_out; after the initial sync it shows Signed out of LinkedIn with a Log in via cloud browser button. Re-login is the only fix, in the app or through Generate re-login link for the account’s owner (how). Meanwhile a sync run parked on a broken browser re-checks every 30 minutes and holds its place in the queue, and a run waiting on an idle browser to cold-start re-checks every 60 seconds. Only running and idle browsers are woken automatically: one in running_issue, start_issue, login_issue, error_investigation or maintenance waits for an explicit start, forever.

​
What the platform already does on its own

  • Every active and no-connection proxy is probed on a 15 minute cycle, 100 rows per tick, coldest first, and flagged or replaced rows are skipped entirely. Geo and fraud are re-checked daily, also 100 rows per tick.
  • A browser that reports a proxy error is rotated automatically, but never restarted (Check 2).
  • Integrations get told by the antidetect-browsers.proxy-issue and antidetect-browsers.proxy-back-alive webhook events, both carrying antidetect_browser_proxy_sid. There is no separate proxy-level webhook.

​
When to contact support

A ticket resolves in one round trip when it carries the account name, a screenshot of the drawer’s Browser tab showing both statuses, the literal Code and Message of the newest error row in the event log, and the raw JSON of any 422, 409 or 503 a swap returned. Request shapes for every endpoint above are in the API reference.