Transparency Report: How Domain Blocking Works on Massive's Network

Massive lets each account block up to 1,000 domains from its proxy traffic in the Massive Dashboard. Blocks apply instantly, support wildcard patterns, and return a 452 (Disallowed Content) error when a request hits one. They sit on top of the network-layer blocks Massive already enforces. This report explains how the blocklist works, where its limits are, and how to handle a 452 in your own code. Every product detail comes from Massive's public documentation.

This edition documents controls. It doesn't report enforcement numbers.

Key Takeaways

• Up to 1,000 blocked domains per account in the Massive Dashboard, applied to proxy connections instantly (Massive Docs).
• A blocked request returns 452 (Disallowed Content). Treat it as final, not as something to retry.
• *.example.com covers subdomains only, so block example.com too.
• Resellers set per-sub-account blocklists through the Reseller API, which accepts a list of up to 100 domains.

Why publish how domain blocking works?

Buyers have a sharper reason to ask about proxy controls than they did a year ago. In January 2026, Google's Threat Intelligence Group described disrupting IPIDEA, a residential proxy network whose exit nodes it saw used by over 550 threat groups in a single seven-day period (Google Cloud Blog, 2026). Google's guidance to proxy providers was that "any claims of 'ethical sourcing' must be backed by transparent, auditable proof of user consent."

Consent covers how devices join a network, and we explained Massive's side of that in how Massive's opt-in network works. Controls cover what traffic is allowed to do once it's on the network. A security reviewer needs both written down somewhere they can read. This report covers the controls.

How does the domain blocklist work?

The blocklist lives in the Massive Dashboard. Per the documentation, blocks are "applied instantly to your proxy connections," and they supplement the network-layer blocks Massive already enforces.

Source: Massive Docs, Domain blocking.

Wildcard patterns Massive supports

A single wildcard (*) per entry lets one rule cover many hosts. The documentation gives these patterns:

Entries with more than one wildcard, such as ads.*.test.*.example.com, are rejected. Because *.example.com matches subdomains only, blocking a whole site takes two entries: example.com and *.example.com. It's an easy gap to miss in review.

What does a 452 error mean, and should you retry it?

A 452 means the destination is blocked, so no retry will succeed. The status code is what makes the block workable in code. With a distinct code, an engineering team can tell a policy block apart from a timeout, a target-site block, or a network error. Without one, a blocked request looks like a flaky one, and a retry loop keeps hitting a destination you deliberately ruled out.

A Python client using requests sees a 452 in one of two ways. For an http:// target, the proxy returns the 452 as the response status. For an https:// target, the client first opens a tunnel through the proxy with a CONNECT request, and a rejected tunnel surfaces as a ProxyError whose message includes the status code. This minimal pattern handles both:

import logging
import time
import requests

def fetch(url, proxies, max_retries=3):
    for attempt in range(max_retries):
        try:
            response = requests.get(url, proxies=proxies, timeout=60)
        except requests.exceptions.ProxyError as err:
            if "Tunnel connection failed: 452" in str(err):
                # HTTPS target: the CONNECT tunnel was refused by policy.
                logging.warning("Blocked domain, not retrying: %s", url)
                return None
            time.sleep(2 ** attempt)
            continue
        except requests.exceptions.RequestException:
            # Timeouts and connection errors: worth retrying.
            time.sleep(2 ** attempt)
            continue
        if response.status_code == 452:
            # HTTP target: Disallowed Content. Log it and stop.
            logging.warning("Blocked domain, not retrying: %s", url)
            return None
        if response.status_code >= 500:
            time.sleep(2 ** attempt)
            continue
        # Other statuses (including target-site 403 or 429) go back to the caller.
        return response
    return None

The rule is simple: log a 452, don't retry it, and alert when it appears somewhere you didn't expect. If you see a 452 on a domain you never blocked yourself, contact Massive support to find out which block applied.

A starter CSV for a team that wants to keep one competitor's site and one ad network out of its jobs looks like this, one domain per line, with each apex and its wildcard as separate entries:

example-competitor.com
*.example-competitor.com
doubleclick.net
*.doubleclick.net

What is domain blocking for?

• Cost control. A page often pulls in ad, analytics, and media hosts you don't need. Blocking them at the proxy saves bandwidth for the content you came for. Two entries, doubleclick.net and *.doubleclick.net, cover an ad network's apex domain and every host under it.
• Policy enforcement. Make sure no automated job, from any team, reaches a domain your legal or compliance team has ruled out.
• Safety for agents. An AI agent following links can wander anywhere. For traffic routed through Massive, a blocklist sets hard limits on where its requests can go, whatever the model decides. Our post on giving AI agents live web access covers the rest of that setup.

How do resellers block domains for their customers?

Partners who resell Massive access manage blocklists per sub-account through the Reseller API, not the Dashboard. The update domains blocklist endpoint (PUT /accounts/{id}/blocklist) is described in the docs as a way to "configure which domains are blocked for this account's proxy access." It accepts a list of up to 100 domains, each up to 253 characters. For synchronized sub-accounts, "the blocklist is merged with the parent's blocklist," so a rule a partner sets at the top applies to every synced customer below it.

What can't Massive's domain blocklist do?

• It blocks domains, not paths. You can't block one section of a site and allow the rest.
• It's capped. The Dashboard allows 1,000 entries per account. Wildcards stretch that a long way, but it isn't unlimited.
• Override scope isn't spelled out. The docs say "admins may apply global blocklists that override personal settings" but don't define which admins or how far those blocklists reach. If that matters for your setup, ask Massive support before you rely on it.
• It adds restrictions; it doesn't lift them. The blocklist supplements Massive's network-layer blocks. The documentation doesn't list what those network-layer blocks cover. For security review questions, the Massive Trust Center is the starting point, or contact Massive directly.

Where this fits in Massive's transparency series

This report is part of our Thursday transparency series. For how anti-bot systems judge proxy traffic, and why sourcing matters, see our myth-busting post on rotating proxy pools. Product details for the residential network are on the Residential Proxies page.

Domain blocking: the bottom line

• Add both example.com and *.example.com when you mean the whole site, and treat every 452 as final.
• Every product detail in this report is in Massive's public docs, so you can check it rather than take our word for it.

Sources

• Massive Docs, "Domain blocking"
• Massive Docs, "Update domains blocklist"
• Google Cloud Blog (Google Threat Intelligence Group), "Disrupting the World's Largest Residential Proxy Network", 2026
• Massive, "Massive Trust Center"