Amazon Scraper API vs Proxy: Choose a Product Data Source
Distinguish authorized Amazon APIs, licensed product data and proxy-based page checks by record quality and access rights.
Read guideUnderstand DNS, exit-IP, and WebRTC observations, what each can reveal about a proxy route, and why one passing check cannot certify anonymity.

A proxy leak check separates DNS resolution, HTTP exit IP, and browser WebRTC candidates. One passing IP check does not cover other paths or applications. Each observation applies to the tested client, hostname, and network configuration.
An HTTP exit-IP test observes the address a particular web endpoint sees for that HTTP request. It does not show which resolver handled the hostname, whether a browser used another network path, or what a different app will do.
A DNS leak test asks which resolver sees a lookup; its result depends on the hostname, cache, resolver configuration, and test design.
Web Real-Time Communication (WebRTC) uses Interactive Connectivity Establishment (ICE) candidates to find possible network paths between peers. A web application can inspect candidate addresses; MDN notes that candidate addresses can reveal network details and that relay-only policy restricts candidates, with a tradeoff in available paths (RTCIceCandidate address). This is separate from an HTTP proxy setting.
| Observation | What it can support | What it cannot establish alone |
|---|---|---|
| HTTP request reports proxy exit address | That tested request reached the checker with that source address | DNS resolver path or every app’s route |
| DNS test reports a resolver | The resolver visible to that test under its conditions | Which app made every lookup or whether another hostname behaves the same |
| WebRTC page lists ICE candidates | Candidate addresses exposed to that page | A complete inventory of all network traffic or identity |
No checker certifies anonymity. Results depend on software, permissions, cached state, proxy type, target behavior, and network configuration. Report the URL, client version, proxy scheme, settings, time, and exact observed output with the conclusion.
For SOCKS5, the request can carry a destination as a domain name (RFC 1928 §5). Whether the client resolves it locally or asks the proxy to resolve it depends on the client’s proxy mode.
curl documents socks5:// for local name resolution and socks5h:// for proxy-side hostname resolution (CURLOPT_PROXY). Other clients use different configuration names. The SOCKS5 vs SOCKS5h guide explains this client-specific setting and its limits.
A controlled test can compare the client configured for its intended proxy mode with the client’s direct behavior, using a hostname under the operator’s control and a resolver log that identifies query time and name. Avoid treating a public DNS checker’s result as proof of the resolver used by every request.
Browser Secure DNS settings, operating-system resolvers, application-level DNS, caches, and exceptions can change which path is observed.
An HTTP exit check from the same client supplies a separate observation: the source address visible to that endpoint. Browser and command-line clients may follow different settings. Proxy environment variables and bypass rules can route selected hosts directly even when another request uses the proxy.
A WebRTC candidate test reports addresses and candidate types exposed by the evaluated browser profile. It does not inspect every network connection or establish whether every candidate was used. Browser policy and application settings influence which candidates are available.
A supported browser policy or application setting may restrict candidate gathering when direct peer-to-peer connectivity is unnecessary. The appropriate setting depends on the browser and the application's connectivity needs.
A relay-only policy can reduce direct candidate exposure, but it may prevent connections when a relay is unavailable. It also does not change DNS behavior or prove that ordinary HTTP requests use the proxy. A setting that restricts candidates can also break a required application feature; its network and functional effects need separate validation.
A useful finding names the path, not a broad label such as “leak fixed.” For example: “On 2026-09-26, Firefox profile A sent the test HTTPS request through exit address X; the controlled DNS log showed resolver Y; the WebRTC page exposed candidate type Z.” Replace this illustrative sentence with observed values and keep sensitive addresses private when publishing a report.
A path that differs from the intended route may be owned by the proxy mode, system resolver, browser setting, direct-connect exception, or WebRTC policy. Changing one component does not establish that the others changed too. A passing result narrows the tested configuration; it does not certify anonymity, other devices, or future network state.
Non-expiring traffic, location targeting and rotating or sticky sessions for your existing tools.
Distinguish authorized Amazon APIs, licensed product data and proxy-based page checks by record quality and access rights.
Read guideConnect a buyer-owned proxy to an Apify Actor, keep the session boundary clear, and validate records instead of counting requests.
Read guideSeparate Australian egress from en-AU content, AUD pricing, GST display, postcode validation and the state delivery context.
Read guide