Skip to main content
If you are using Bright Data proxies and testing your setup with third-party tools, you may notice that the DNS resolver location shown by those tools appears different from your proxy IP’s country. This is expected behavior in most cases. This article explains why it happens and what you can do about it.

​
How DNS resolution works in Bright Data’s proxy network

All requests made through Bright Data start by connecting to a Super Proxy (brd.superproxy.io). Two separate DNS resolutions happen at different stages of the request:

​
Stage 1: Entry gate DNS check

When your request first arrives at the Super Proxy entry gate, a preliminary DNS resolution is performed. This check is done solely to verify that the target domain exists and is a valid destination. It is performed at the Super Proxy level, not at the exit node (your actual proxy IP).

​
Stage 2: Exit node DNS resolution

Once the domain is confirmed as valid, the actual request is forwarded to the exit node: the proxy IP in your target country. A second, independent DNS resolution is performed at the exit node for the real request. This is the DNS resolution that matters for your actual traffic.
The preliminary DNS check at the entry gate does not affect how your actual request is routed. Your real traffic exits from your assigned proxy IP.

​
Why DNS leak test websites show a different DNS location

Some tools (such as whoer.net, browserleaks.com/ip, or whoerip.com) use JavaScript-based tests or DNS queries that interact with the entry gate DNS check rather than the actual exit node DNS. As a result:
  • The DNS resolver shown by these tools may reflect a Bright Data Super Proxy location rather than your assigned proxy IP’s country.
  • This is not a reflection of where your actual browsing traffic exits.
  • Your real requests exit from your assigned proxy IP.
This behavior is specific to how those tools probe for DNS information. It does not indicate a misconfiguration of your zone or your proxy credentials.

​
Which IP checker should you use?

Use Bright Data’s official endpoint to validate your proxy IP and its geolocation: 
curl -i --proxy brd.superproxy.io:33335 \
  --proxy-user brd-customer-<CUSTOMER_ID>-zone-<ZONE_NAME>:<ZONE_PASSWORD> \
  "https://geo.brdtest.com/welcome.txt?product=isp&method=native"
The response shows your actual assigned proxy IP and its correct country as recorded in Bright Data’s network.
Many third-party geolocation tools use outdated records or unreliable testing methods. Their results are not an accurate reflection of your proxy’s actual geolocation. Bright Data actively monitors and maintains correct records in all major geolocation databases.

​
Will this affect your real target websites?

For your actual target domains, DNS is properly resolved at the exit node, and your traffic exits from your assigned proxy IP in the correct country. You can verify this by running the curl command above against your real target domain.

​
Why are requests failing with a target_40001 error?

If your host is valid but cannot be resolved and you receive a target_40001 error (host could not be resolved), the domain may only be resolvable from specific geographic locations. In this case, contact Bright Data support to request that your host be added to the DNS whitelist, so it can skip the Super Proxy entry gate DNS check. See Error Catalog: target_40001 for the full error description.

​
Recommendations for best DNS behavior

If your use case requires precise DNS matching between your proxy IP location and the DNS resolver shown by third-party tools, apply the following steps.

​
Use the remote DNS resolution flag

Append -dns-remote to your proxy username to instruct the proxy to perform DNS resolution at the exit node: 
curl "https://example.com" \
  --proxy brd.superproxy.io:33335 \
  --proxy-user brd-customer-<CUSTOMER_ID>-zone-<ZONE_NAME>-dns-remote:<ZONE_PASSWORD>
The -dns-remote flag does not resolve cases where the entry gate DNS check returns a dns_resolve_skip result for specific domains. In those cases, the flag has no effect on what third-party tools report.

​
Ensure your client sends hostnames, not IP addresses

Bright Data’s proxy network requires requests to use domain names, not pre-resolved IP addresses. If your browser, anti-detect browser (such as Multilogin), or application resolves DNS locally before sending the request, DNS mismatch behavior is more likely. Configure your application to:
  • Send the hostname or domain to the proxy, not a pre-resolved IP
  • Use remote DNS resolution when that option is available in your application

​
Request domain whitelisting for location-sensitive hosts

For domains that can only be resolved from specific geographic locations and as a result return a target_40001 error from the Super Proxy DNS check, contact Bright Data support to whitelist the specific host. This allows it to skip the Super Proxy DNS check.