> ## Documentation Index > Fetch the complete documentation index at: https://docs.brightdata.com/llms.txt > Use this file to discover all available pages before exploring further. # Proxy and IP Rotation control > How Bright Data proxy IP rotation works across 4 networks (Datacenter, ISP, Residential, Mobile) and how to control rotation with session parameters. ## 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. ### 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 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](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. ```sh Shell theme={null} curl "http://target.site" --proxy brd.superproxy.io:33335 --proxy-user brd-customer--zone--session-mystring12345: ``` ## 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. ```sh Shell theme={null} curl "http://target.site" --proxy brd.superproxy.io:33335 --proxy-user brd-customer--zone--session-mystring12345-const: ``` ## 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, if 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` ```sh Shell theme={null} curl "http://target.site" --proxy brd.superproxy.io:33335 --proxy-user brd-customer--zone--session-mystring12345-const: ``` ## 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](https://docs.brightdata.com/api-reference/proxy/c-tag)