Network
South America: Brazil first, and what the exit really decides
Most searches for a South America proxy are, in practice, Brazil searches — the largest single market on the continent and the only major Portuguese-language one. We run no node there. What follows is which parts of that work a US exit does perfectly well, which parts it cannot do at all, and a cheap test that tells you which you are in.
What we do not offer
There is no RoamingProxy egress in South America. Three datacenter regions in our own AWS account are the whole fleet — us-east (N. Virginia), us-west (Oregon) and europe (Ireland) — so no Brazil exit, no Argentina or Chile exit, no per-country selection, no city or state targeting, and no residential or mobile addresses. The earlier version of this page offered residential addresses across the continent with per-country and ISP-level targeting. That was fiction. If your work requires a Brazilian residential address, it requires a different product from ours.
Brazil is most of the problem, and it is its own problem
Brazil is the continent's largest internet market by a wide margin and the only large Portuguese-language one, which makes it a different collection job from Spanish-speaking Argentina, Chile, Colombia or Peru rather than a bigger version of the same one. Different domains, different retail platforms, different payment rails and different invoice and tax conventions on the pages themselves. A parser written for Brazilian retail rarely survives being pointed at a Chilean site, and the reverse holds just as firmly.
The language split matters for the same practical reason. Brazilian Portuguese is not European Portuguese, and regional Spanish varies enough between Argentina, Chile and Colombia that a single continental dataset usually has to be broken into per-market ones later, at more cost than splitting it at the start would have taken.
One caveat before you assume a local exit is what surfaces the local language: our nodes send a fixed Accept-Language of en-US,en;q=0.9 and User-Agent is the only outbound header a caller can influence. A site that negotiates language by header serves us its English variant from every region we run. Where a locale URL exists — /pt-br/, /es-ar/ — fetch that directly, and the exit region stops being part of the question.
The two-region test
Before shopping for an exit on the continent, find out whether your target keys on the client address at all. Fetch the same URL twice, once through us-east and once through europe. Those are separate machines on separate continents with unrelated addresses, so they are a genuine A/B of the client's apparent location.
If the two responses are materially identical, the site does not vary by address, and a US exit will serve you as well as a Brazilian one ever would — you are only paying round-trip time. If they differ, the site does key on the address and you have learned something worth knowing: you need an exit we do not have. Either way the test costs two requests, and it beats reasoning about it from a map. Compare final_url and the redirect list too, since a country picker firing on first visit shows up there before it shows up in the body.
What a US exit reaches, and what it will not
The honest split is wider on the reachable side than most geographic proxy pages imply, because a lot of the continent's valuable public data is not gated at all.
Reaches fine
Government and statistics portals, regulator registries and gazettes, exchange filings, news sites and feeds, documentation, and retail pages that do not localise by address.
Will not reach as a local
Address-keyed pricing and currency, licensed media, country-restricted services, and anything whose point is describing what a Brazilian user sees.
Check the hosting first
Many Latin American properties sit behind CDNs or on US infrastructure, so an in-region exit is not automatically the shorter path. Measure it per target rather than assuming.
Round trips, and asking for a node
All three of our regions are far from the continent, and us-east is the nearest of them to its Atlantic side. Distance is charged per round trip — DNS, TCP, TLS, the request, then again on every redirect hop — so it compounds across a large crawl and shows up as wall-clock time and timeouts on slow origins rather than as money, since we bill per request rather than per second. We publish no latency numbers because we measure none; elapsed_ms on your own fetches is the figure that matters.
If you need an exit on the continent, say so. Provisioning a region is a scripted deploy from the same repository as the API, so it is a question of demand rather than of engineering effort. Email support@roamingproxy.com with the countries, the targets and the volume, and you will get a straight answer about whether and when — including a straight no, if that is the answer.
Questions
- Do you have a Brazil proxy?
- No. There is no exit in Brazil or anywhere else in South America. Of the three regions we do run, us-east in northern Virginia is the nearest to the Atlantic side of the continent.
- How do I tell whether I actually need a Brazilian exit?
- Fetch the same URL through us-east and through europe and compare the responses, including final_url and the redirect list. Identical means the site does not vary by client address and a US exit is fine. Different means it does, and we cannot serve that target the way you need.
- Can I get a Brazilian residential address?
- No. Everything we egress from is a datacenter address on an EC2 instance we run, in one of three regions. We hold no residential or mobile addresses in any country and cannot obtain one for a single job.
Get a key
Create an account and mint an API key in the dashboard. The full endpoint reference — request shapes, parameters and error codes — is published at https://api.roamingproxy.com/v2/docs.