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.
What are “Static residential” proxies?
“Static residential proxies” are datacenter hosted proxies registered as owned by Internet Service Providers (ISP) and enable have a fixed, static IP address. In Bright Data we name these proxies: “ISP Proxies” and not “Static residential”.Rotation in dedicated residential proxies
Since residential proxies vary in their availability, we group together a number of proxies to a group which we callgIP. 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
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
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 samesession 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
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 samesession 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