​
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:
  1. In Datacenter and ISP network: proxies are exclusively yours for all domains.
  2. 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.
Shell
curl "http://target.site" --proxy brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>-session-mystring12345:<zone_password>

​
Disable proxy rotation in case of unavailable peer

Our default behavior is to direct your request to another peer in case the peer is unavailable to allow fluent operations. In case you would like to prevent this, and only use a single peer for a session, and fail the request in case the peer is unavailable, add the -const option to the session parameter. When using the -const option, in case peer is unavailable you will get a HTTP 502 Error.
Shell
curl "http://target.site" --proxy brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>-session-mystring12345-const:<zone_password>

​
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:
  1. AMER: North, central and south America
  2. EMEA: Europe, Middle East and Africa
  3. 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
Shell
curl "http://target.site" --proxy brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>-session-mystring12345-const:<zone_password>

​
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