Residential products FAQ

When sending your request, add the -country flag, after your zone’s name in the request, followed by the 2-letter ISO code for that country.

In the example below: We added -country-us to our request, so we will send a request originating from the United States (“us”).

curl "http://target.site" --proxy brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>-country-us: <zone_password>

The allocation of a country within the EU is random.

Relevant for DC, ISP, and Web Unlocker/SERP API

You can target the entire European Union region in the same manner as “Country” above by adding “eu” after “country” in your request: -country-eu

Requests sent using -country-eu, will use IPs from one of the countries below which are included automatically within “eu”:

AL, AZ, KG, BA, UZ, BI, XK, SM, DE, AT, CH, UK, GB, IE, IM, FR, ES, NL, IT, PT, BE, AD, MT, MC, MA, LU, TN, DZ, GI, LI, SE, DK, FI, NO, AX, IS, GG, JE, EU, GL, VA, FX, FO

In order to target a specific city you will need to use a Shared (pay-per-IP) or Dedicated proxy network.

When configuring your proxy zone, after selecting your preferred country, you can add a city, to further specify your geotargeting

Once you click on ‘Add city’ you will be displayed the available cities to target, for the selected country. In order to check the number of available IPs for a specific geolocation.

Once configured, you’ll be able to send requests from the selected city, using the following syntax

curl "http://target.site" --proxy brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>-country-<country>-city-<city>: <zone_password>

When selecting a two-word city it’ll be written as one word.

For example, when targeting Buenos Aires the syntax of the request will be:

-country-ar-city-buenosaires

To view more geotargeting examples, you may want to review our proxy integration examples page.

This can be done by adding the session parameter to the proxy username:

brd.superproxy.io:33335 br-customer-<customer_id>-zone-<zone_name>-session-rand39484

Generate the random number on thread startup, and change it when you want to change the Proxy Peer assigned for the thread’s connection.

Session ID can be any random string/counter: requests with the same session string will use the same Proxy Peer (as long as possible); requests with different session strings will be assigned different Proxy Peers.
To force an IP change, just modify the session ID
If an assigned Proxy Peer (exit node IP) becomes unavailable, the Super Proxy will return an error “502 - No peers available” for the first request and then on the second request the super proxy will assign a new peer even if you do not change the session ID.
The Session IP is kept persistent for up to 5 minute of idle time. After 5 minutes with no requests, the IP is released back to the pool. To keep this Session/IP for longer, send a tiny keep-alive request every 30 seconds, to prevent this session from becoming idle for over a minute. This request may be anything small, such as /favicon.ico, or even a request that returns 404 (as long as the web server does not disconnect the socket due to this request).

When using Bright Data’s Residential Proxy network, you may find the need to use a specific IP allocated to your zone.

Send a test request with a ‘—verbose’ or ‘-v’ option added (this will turn on verbose logging)

curl "https://lumtest.com/myip.json" --verbose --proxy brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>:<zone_password>

Locate the x-brd-ip response header and copy its value

Add the -ip- flag to your request, after your zone’s name and use the hashed IP value copied in the previous step
Send a test request, and review the response

curl "https://lumtest.com/myip.json" --proxy brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>-ip-<hashed-ip>:<zone_password>

We recommend using https://lumtest.com/myip.json as the target domain for testing, and to review your IP credentials.

This feature can be enabled by adding the ASN parameter to your Zone configuration, under Geolocation Targeting.

Once the configuration is saved, the ASN flag can be added to the Zone’s credentials
and be integrated when using the Residential proxies. For example:

curl --proxy brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>-asn-<asn-number>:<zone_password> "<target_site>"

Note: Values for ASN number can be found here.

Dedicated residential IPs can be targeted in the form of gIPs. They can be allocated under the zone’s configuration page by selecting a “Dedicated” IP type and choosing a number of gips. Also targeting a specific domain is required.

Once the configuration is saved, selecting “Show allocated Dedicated residential IPs” will provide a list of hash values that represent group IPs.

These values can be used to target a specific gip. For example:

curl --proxy brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>-gip-<gip_hash_value>:<zone_password> "<target_site>"

When outside of China
Targeting Chinese Residential IP peers is enough:

curl --proxy brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>-country-cn:<zone_password> "<target_site>"

When inside ChinaIn addition to Targeting Chinese Residentials IP peers, targeting our Chinese super-proxy is also required.

When using API commands, the proxy DNS server isservercountry-cn.brd.superproxy.io

curl --proxy servercountry-cn.brd.superproxy.io:33335 --proxy-user brd-customer-<customer_id>-zone-<zone_name>-country-cn:<zone_password> "<target_site>"

When using the Proxy Manager:
- Select relevant Port settings by simply clicking on the port
- Select Targeting and set China as the country
- Select IP control: set Super Proxy location to “China”.

You can choose to use a specific carrier from this list:

a1, aircel, airtel, att, celcom, chinamobile, claro, comcast, cox, digi, 
dt, docomo, dtac, etisalat, idea, kyivstar, meo, megafon, mtn, mtnza, mts,
optus, orange, qwest, reliance_jio, robi, sprint, telefonica, telstra, 
tmobile, tigo, tim, verizon, vimpelcom, vodacomza, vodafone, vivo, zain,
vivabo, telenormyanmar, kcelljsc, swisscom, singtel, asiacell, windit, 
cellc, ooredoo, drei, umobile, cableone, proximus,tele2, mobitel, o2, 
bouygues, free, sfr, digicel

For Example

Residential Proxy - No, SERP API is the ideal product for targeting SERPs as it has a guaranteed success rate (pay only for success) with active unlocking, automatically chooses the best proxies, customizes headers, fingerprinting, solves CAPTCHAs, and more. Targeting Google SERPs from the Residential network will result in Super-proxy bypass, which will casue the request to be sent from our servers instead of the peer.

Datacenter & ISP Proxies - No. When attempting to specifically target Google through either of these proxy networks, your request will be denied and you will receive the following error message in the response headers:

HTTP/1.1 403 Search engine host is not allowed
X-Luminati-Error: Forbidden: This target URL isn't supported on proxy networks, use the SERP API product for targeting this URL. You may contact your account manager or open a support ticket for assistance

When targeting search engines through the Residential or Mobile networks, the request will not go through the Residential or Mobile peer but instead will be sent directly through one of our super proxies. The reason for this behavior is to support the integration of the Residential and Mobile networks with a browser, which might need to load search engine resource endpoints from the target website.

In case you target a search engine domain using Residential or Mobile networks, the request will be passed directly through the super proxy, and the following response header will serve as an indication:

x-luminati-ip: superproxy bypass

For single-step scraping:

For multi-step scraping (playwright/puppeteer/selenium):