Verify a Block Manually

Replay a real browsing session through your Residential Proxy to tell whether a block comes from the target website or from the proxy itself.

When a scraper suddenly starts failing, the proxy is the easiest thing to blame. But in most cases the target website has changed how it handles automated requests, and the same IPs still work fine for ordinary browsing.

This guide walks through a manual test: browse the target website through your Residential Proxy in a real browser, exactly the way a human would. The result tells you which side the block is actually coming from.

When to use this

Use this test when your scraper worked before and started failing, or when a scrape is blocked but you're not sure whether the proxy IPs or the website is responsible. If you haven't run the automated check yet, start with Troubleshoot URL Access first, it's faster.

Why direct URL access fails

Many websites treat a request for a deep page (a product page, a listing, a search result) with no prior history differently from a normal visit. A real visitor almost never lands there cold. They arrive from a search engine, from the homepage, or from a category page, carrying cookies, a referrer, and a browsing history that the site has already seen.

That's why a scraper hitting a product URL directly can fail while the exact same IP loads the site normally in a browser. The test below reproduces the natural path so you can compare the two.

What you need

Run the test

Route Chrome through the proxy

Open FoxyProxy, add a new proxy, and fill in the connection details:

FieldValue
Proxy typeHTTP
Hostname / IPproxy.mrscraper.com
Port10000
UsernameYour proxy username, for example user-country-us
PasswordYour proxy password

Set the country in the username to match the target website's audience. For a Brazilian website, use -country-br.

Save the proxy, then enable it from the FoxyProxy toolbar icon. Confirm the traffic is actually routed by opening api.ipify.org and checking that the IP is not your own.

Search for the website on Google

Go to google.com and search for the target website's name or homepage, for example ifood.com.br.

Don't paste the target page URL into the address bar. The point of this test is to arrive at the site the way a visitor does.

Click through from the search results

Click the organic search result that leads to the website's homepage. This gives the session a search engine referrer and lets the site set its cookies on a page it expects first-time visitors to land on.

From the homepage, reach the page you want to scrape using the site's own navigation: menus, category links, the on-site search box, pagination. Take a moment between clicks instead of firing them back to back.

If you reach the page and it loads normally, the website is serving your proxy IP without complaint.

If regular Chrome fails, retry with CloakBrowser

CloakBrowser is an open source Chromium-based browser. Comparing it with regular Chrome tells you whether the result depends on the browser rather than the IP.

Launch it in headed mode with the same proxy credentials, then repeat steps 2 to 4 inside it:

import { launch } from 'cloakbrowser';

const browser = await launch({
  headless: false,
  proxy: {
    server: 'http://proxy.mrscraper.com:10000',
    username: 'user-country-br',
    password: 'pass123'
  }
});

const page = await browser.newPage();
await page.goto('https://www.google.com');
// Now search for the site and click through by hand.

Interpret the results

Manual browser testWhat it meansNext action
✅ Works in regular ChromeThe proxy IPs are fine. The difference is in how your scraper sends requests, such as its headers or navigating directly to the target URL.Reproduce the natural flow in your scraper: start from the homepage or a search result, keep cookies across requests, and enable browser rendering.
❌ Fails in Chrome, ✅ works in CloakBrowserThe IPs are fine. The result depends on the browser, not the IP.See the CloakBrowser examples.
❌ Fails in both, even with natural navigationThe website is rejecting the IP itself, or the whole country or ASN.Try a different proxy country and repeat the test. If it still fails, contact support.
❌ Fails in both, and the site also fails without the proxyThe website is blocking your region or is down for everyone.Verify from a different network before investigating the proxy further.

A failure is not always about IP quality

A website that recently changed its configuration can reject a healthy residential IP when the request doesn't match a normal browsing session. Running this test before escalating saves you from swapping proxies that were never the problem.

On this page