An account's exit IP follows its environment, not your office network. Routes are allocated from the proxy pool by each account's target region, the pairing holds over time once bound, and you can check the current exit whenever you want.
A whole office on one exit, and the accounts drag each other down for no obvious reason
Each environment takes its own route and no exit IP is shared, so accounts don't get lumped together because they left through the same office connection.
The proxy is configured but I can't tell if traffic is actually using it, so when something breaks I test them one by one
Run an exit-IP check and it returns the actual exit address and region. A misconfiguration, a dead route or traffic falling back to the default network shows up immediately.
The account was in Southeast Asia yesterday and Europe today, and the platform keeps asking it to verify
Once a route is bound to an account it stays put, with no random switching. Changing region is an explicit action, and it leaves a change record.
We buy proxies from someone else and the account-to-route mapping lives entirely in a spreadsheet
Your own proxies can be entered and managed here, bound in the same place as environments and accounts, so there's no separate mapping table to maintain.
Route management isn't about how many you have. It's about being able to tell which one an account is on right now, and how many times it's changed.
Routes are held in the proxy pool and allocated from there, classified by region and purpose. New environments draw a route from the pool instead of having one typed in by hand.
Every route in the pool is its own instance, with its own status, region and usage. Each can be started, stopped or replaced on its own.
Detect the protocol automatically or explicitly choose SOCKS5, HTTP, HTTPS or Shadowsocks, with credentials managed centrally.
Authentication details for your own proxies can be entered and kept here, selectable from the same list as platform routes.
Switching the route on an environment or device is an explicit action and takes effect immediately. The change goes to the audit log, so who did it and when is on the record.
Check the actual exit address and region in one click, to confirm a route is live and to track down misconfigurations and dead routes.
Choose the exit region by each account's target market, with multiple regions supported. Keep an account fixed to one region over time.
Routes come in through an apisix gateway. Configuration changes sync to the gateway and take effect there, so settings don't have to be edited environment by environment.
The point of a route is that every action a digital worker takes leaves from a sensible place. The region and exit policy are yours to set.
Platform routes and your own proxies both go into the proxy pool, classified by region and purpose, and become proxy instances ready to allocate.
Which region each account uses, whether it gets a dedicated route, and the circumstances under which a change is allowed — you set those rules.
The route is sent to the browser environment or cloud phone with the selected protocol. After saving the environment, run a proxy check to confirm the actual exit IP and country.
Warming, publishing, collection and conversation requests all leave over the account's own route. No account is on one route today and another tomorrow.
If a route is unreachable or the exit region doesn't match, the tasks stop and you're notified. Which route to move to, and whether to cross regions, is your judgement to make before anything happens.
Switching routes isn't something to do automatically. To a platform, a sudden change of exit region is the same class of signal as a sudden change of device, so an automatic fallback looks convenient but really adds one more anomaly at the moment an account is already in trouble. So the system's job is to stop and tell you; whether to switch, and to what, is yours.
Available regions and route types come from the resource pool at provisioning time. Only what's settled is written here.
Each browser environment binds one route. Fingerprint isolation only means something when it comes with a dedicated exit.
Cloud phone exits come from the proxy network too, configured the same way as browser environments.
Collection has to reach a market from a local exit to get the same content and leads a local user would see.
During warming, account and IP stay paired, and the exit region also determines which hours the actions run in.
No. IP quality is one input among many. A previously banned account on the same IP, or a range flagged as a data centre or proxy block, both raise the risk — but the reverse doesn't hold: even on a perfectly clean IP an account can still be restricted over its pacing, its device traits, how complete its profile is, or the content itself. A route settles one dimension, where traffic comes from, and it doesn't substitute for warming strategy or content quality. Anyone who promises that changing IP prevents bans isn't worth believing.
It depends on what the accounts are worth and on the platform. Give important accounts a dedicated route: several accounts on one exit look, from the platform's side, like a cluster at one network location, which is a clear linkage signal. Low-risk secondary accounts can share within reason. The system imposes no hard limit; billing follows route count and traffic.
Yes. Once entered, your own proxies bind to environments and devices just like platform routes, and exit-IP checks and change records apply to them as well. Their quality, availability and renewal are your supplier's responsibility, and we don't take on stability for that part.
Run an exit-IP check. It returns the exit address and region the environment actually uses to reach the internet; if the result is your office exit, the proxy isn't in effect. Check once after the first binding, and again whenever something looks wrong.
The affected tasks stop and their failure reason is recorded. They never bypass the proxy onto the default network, because that would expose the account's real exit. You get a prompt to deal with it, and switching routes is an explicit action.
Yes. A sudden change of exit region reads as an anomaly to platforms and can trigger verification or even restrictions, and the newer the account the more it shows. When you genuinely need to change, try it on a low-value account first and don't flip back and forth. The change record stays in the audit log, which makes it easier to line up account status against what happened later.
A consultant will put together a route configuration and resource quote around your platforms, account count and target markets.