Proxy and IP Rotation control
How does proxy IP rotation work, and how can you configure or control it.
Default proxy IP rotation in Shared Pool
Shared pool proxies, also known as “Rotating Proxies” are available in all Bright Data proxy networks: Datacenter, ISP, Residential & Mobile.
By default, Bright Data assigns a random proxy from the available proxies in the zone, according to your configuration.
For example: if you chose to target a specific country, for example Canada, using the -country=ca
parameter, we will randomly assign a proxy in Canada out of all the proxies located in Canada that we have in the pool.
The next request, will be directed to a different proxy, and so on, selected randomly from our pool. Executing requests in high rate or by multiple calling agents may result in reuse of the same proxy IPs.
Default proxy IP rotation in dedicated proxy zone
When you configure a set of dedicated proxies dedicated proxies are assigned to your exclusive use in the following manner:
-
In Datacenter and ISP network: proxies are exclusively yours for all domains.
-
In Residential and Mobile networks: are exclusively yours towards specific domains.
In dedicated proxy zones we will rotate to next available proxy to serve the next request.
Rotation in dedicated residential proxies
Since residential proxies vary in their availability, we group together a number of proxies to a group which we call gIP
. This gIP
gets a unique identifier, and peers assigned to it (members of the group) are selected according to configuration you specify. For example: if you require 3 dedicated residential ips towards target http://example.com ; we will provide 3 gIPs
which we rotate over to serve your requests.
Using explicit proxy for multiple requests: ip
To explicitly target a request to a specific proxy, use the -ip
parameter in your proxy zone username request. This is when you issue a set of requests on a different connection (like a sequence of curl
requests).
Using the same proxy for multiple requests: session
To keep the same proxy IP address for multiple requests, use the -session
parameter with a session identifier you create and control. Each request, carrying the same -session
value will be forwarded to the same proxy IP.
The -session
parameter value is generated by you and controlled by you, yet its format should include alphanumeric characters only. Using special characters like -
or *
will result in errors.
If you work with native proxy access (within code libraries or 3rd party tools which take proxy ip:port and credentials) then you embed the session parameter in the user name parameter as shown below for session identified mystring12345
. If you are using our proxy REST API, then the session
parameter in request body
shall carry the session identified value.
Losing session context
The following describes scenarios where session context can be lost, and consequent requests will be executed by different proxies.
Session Idle Time
Session idle time is 5 minutes. In case there are more than 5 minutes idle time between two consequent requests, the second request, although carrying the same session
parameter as the first, will use a randomly selected proxy from the pool.
Session origin must be from same global region
In order to keep the same session, you must ensure your calling process issuing the request is not switching between global regions. We recognize 3 global regions:
-
AMER: North, central and south America
-
EMEA: Europe, Middle East and Africa
-
APAC: Asia and Pacific
Example: If you issue 2 consequent requests, one from your company server in Canada (in AMER region) and one from your company server in France, even if both requests will carry the same session
parameter, they will be executed by different proxy peers.
Other parameters must be identical
In case 2 consequent requests carry different country, city or any other parameter: session context will be lost , even if they carry the same session
parameter.
Error on lost session
By default, is session is lost or reset, Bright Data will randomly assign a proxy to your request. If you wish to avoid this default assignment, and error instead, use the -const
parameter in your request. If the same peer is not available from any reason to 2 consequent requests, the second request will result in HTTP Error 502
Keeping track of requests and their responses (C-Tag)
We’ve implemented an optional feature that can greatly help tracking and linking requests with their corresponding responses, see the following article for more information: more info on C-Tag
Was this page helpful?