Proxy Acceptable Use Policies: What Providers Ban and Why

Nearly every proxy AUP bans the same core activities: spam, credential stuffing, account takeover, fraud, DDoS, unauthorised scanning, malware and illegal content. No legitimate buyer needs to worry about those lists.

What differs between providers, and what trips legitimate buyers, is everything else:

• Restricted target categories, such as banking, government, streaming, ticketing and gaming sites, blocked outright on some providers and allowed after verification on others.
• Blocked ports, most commonly outbound mail (SMTP).
• Account rules: no reselling, no sharing one plan's credentials across clients, one account per person or organisation, no sustained attempts to exceed purchased concurrency.

Before you buy, match your target list and your team structure against those three groups. After you buy, enforce them in your own code, because the provider will enforce them at the gateway.

Providers split the rules across documents that are easy to confuse. Each answers a different question and is enforced at a different moment.

SparkProxy's terms of use contain all three post-signup elements in one place: an acceptable use section, a fair usage policy, and contract terms on resale, account count and refunds. Many providers publish them separately, so read all of them, not just the page titled "acceptable use".

1. Prohibited activities. What you are doing, regardless of target. SparkProxy's terms, for example, prohibit unauthorised penetration testing or vulnerability scanning, spam and phishing, malware distribution, credential stuffing and brute-force attacks, fraud, accessing illegal content, circumventing sanctions or export controls, and data collection that breaches a site's terms where that activity is unlawful.

2. Restricted targets. Where you are sending traffic. These are usually category lists (banking, government, streaming) enforced by hostname at the gateway, sometimes with a published example list.

3. Blocked ports and protocols. How you are sending it. Outbound SMTP is the classic example, because mail sent from proxy IPs lands the whole range on spam blocklists.

4. Account conduct. How you use the subscription itself: resale, credential sharing, multiple accounts, concurrency abuse. These rules have nothing to do with the websites you reach, which is exactly why well-behaved scraping teams break them.

Here is how four providers describe target restrictions on their own pages, as of September 2026. Blank cells mean the page we read did not address that category, not that the category is allowed.

Oxylabs also documents a separate list for its Web Scraper API, where several of those categories can be enabled after a short KYC procedure. That split is common: a managed scraping product lets the vendor control exactly what requests are made, so it can open targets that raw proxy access cannot.

Two practical takeaways. First, if a target on your list sits in a restricted category on a provider, no amount of good behaviour will open it there, so check before you buy. Second, note Oxylabs' restriction on IP-checking websites. If your code calls a public "what is my IP" service to verify exits, that call may fail on some providers for policy reasons rather than technical ones, so use the provider's own check endpoint where one exists.

Restricted categories look arbitrary until you see them from the provider's side. Four forces put a domain on the list.

Fraud concentration. Banking, payment, ticketing and gaming sites attract a large share of the account takeover and payment fraud attempts that run through proxies. Restricting the category removes most of that traffic at once.

Complaint volume. Sites that detect abuse send reports to the owner of the IP range, which for datacenter proxies means the hosting provider or the proxy company itself. Upstream providers can suspend entire allocations over repeated complaints, so the proxy company protects every customer's addresses by cutting the categories that generate them.

Licensing and legal exposure. Streaming restrictions exist largely because proxies are used to evade geographic licensing. Government sites carry legal and reputational risk that most providers decline to underwrite.

Pool reputation. On a shared or rotating pool, one customer's behaviour becomes every customer's IP reputation. A target that learns to associate a range with abuse blocks everyone on it. Our explainer on IP reputation covers how that damage spreads. Restrictions are partly a service to the customers who were never going to misbehave.

Buyers often assume a proxy provider reads everything, or nothing. Neither is right, and the difference shapes how enforcement works.

For HTTPS traffic through an HTTP proxy, your client sends a CONNECT request naming the destination host and port, then opens an encrypted TLS tunnel through it. The provider sees the hostname, port, timing, connection counts and bytes transferred. It does not see the URL path, query string, headers or page content inside the tunnel. Our explainer on the HTTP CONNECT method walks through the handshake. SOCKS5 connections similarly expose the destination address and port.

That is why AUP enforcement is mostly about hostnames, ports and volume patterns rather than content. A provider can block *.gov at the gateway, block port 25, spot one account opening thousands of concurrent connections to a single login endpoint's host, or notice a subscription's traffic suddenly spreading across hundreds of unrelated client IPs. It cannot tell which product page you requested.

The rest of enforcement arrives from outside: abuse complaints from target sites, reports from upstream networks, payment chargebacks and law enforcement requests. SparkProxy's terms state that it logs connection information for service operation, security monitoring and abuse prevention, and that logged data may be disclosed to law enforcement where required by law. Expect a similar clause from any reputable provider.

Enforcement is rarely a single event. Most providers work along a ladder, though severe violations skip straight to the top.

The top two steps are where contracts get unforgiving. SparkProxy's terms reserve the right to suspend or terminate an account violating the acceptable use policy "without prior notice and without refund", and state that accounts associated with fraudulent activity are blocked and permanently banned. Its fair usage policy handles the lower-severity case differently: sustained attempts to exceed an allocated thread count may lead to restricted bandwidth speed rather than closure. Other providers use similar wording, and Webshare's help centre lists account restrictions, verification procedures including KYC, or permanent suspension as possible outcomes.

These are the rules that suspend teams who never intended to misuse anything.

Sharing one plan across clients. Agencies and freelancers buy one plan and hand the credentials to several clients or contractors. SparkProxy's terms prohibit sharing a single plan's credentials across multiple users or machines, and reselling or providing access to third parties without written permission, and Bright Data and Webshare publish similar resale bans. If you serve clients, ask for written permission or a reseller arrangement, and read our guide to whitelabel and reseller proxy networks. Inside one organisation, separate credentials per project are the clean approach, covered in managing sub-users and credential rotation.

A second account to get another trial or more capacity. SparkProxy permits one account per individual or organisation and suspends duplicates without notice or refund. Opening a second account after a suspension usually gets both closed.

Pushing past purchased concurrency. Retrying aggressively when you hit the thread limit looks like an attempt to circumvent the allocation. Cap concurrency in your client at the plan figure. Our guide to concurrent connections in proxies explains how to size it.

Scanning or load testing your own systems. "Vulnerability scanning" and "stress or load testing" appear on prohibited lists without an exception for infrastructure you own, because the provider cannot verify ownership from traffic. Get written approval first, even for your own staging servers.

Email verification tools. Checking whether mailboxes exist often means talking to mail servers, and outbound SMTP is blocked by many providers. IPRoyal states that SMTP sending ports stay blocked even after identity verification. Plan email verification around that before you buy.

Collecting data behind logins. Bright Data's policy prohibits collecting non-public information, meaning data behind a login, and Webshare prohibits collecting non-public or sensitive data without permission. Scraping an account you legitimately own can still fall inside that wording.

Ticketing and drop automation. Treated as a prohibited or monitored category by several providers, and allowed by others. This one genuinely varies, so check the specific policy.

Take your real target list and team structure to the policy and answer these questions in writing. If the answer to any is unclear, ask the provider and keep the reply.

1. Do any of my target domains fall in a restricted category, and is that restriction permanent or can be lifted?
2. Which ports are blocked, and does my workload use any of them?
3. Can credentials be shared across team members, machines, projects or clients?
4. Is resale or client use allowed, and in what form?
5. What happens when my client exceeds purchased concurrency: refusal, throttling, or a breach?
6. Does the policy prohibit scanning, load testing or login-gated collection without an ownership exception?
7. What notice, if any, comes before suspension, and is there an appeal route?
8. Are fees refundable if the account is terminated for a disputed breach?
9. What connection data is logged, for how long, and under what conditions is it disclosed?

Question 8 deserves attention in procurement. A no-refund termination clause is standard, which is fine for monthly plans and a real financial risk on annual commitments. Larger buyers should see our enterprise proxy procurement checklist for how legal teams handle it.

Policies are enforced at the gateway. The cheapest way to never trip them is to enforce the same rules one step earlier, in your own code, where a mistake produces a log line instead of a suspension.

A minimal egress guard that refuses restricted hosts and ports before a request reaches the proxy:

from urllib.parse import urlsplit
import requests

PROXY = "http://USER:PASS@gateway.sparkproxy.io:11000"
DENY_SUFFIXES = (".gov", ".mil")           # extend from your provider's restricted list
DENY_HOSTS: set[str] = set()              # add hosts your own policy review excluded
ALLOWED_PORTS = {80, 443}
MAX_CONCURRENCY = 100                       # your plan's thread count, never more

class PolicyViolation(Exception):
    pass

def check(url):
    parts = urlsplit(url)
    host = (parts.hostname or "").lower()
    port = parts.port or (443 if parts.scheme == "https" else 80)
    if port not in ALLOWED_PORTS:
        raise PolicyViolation(f"blocked port {port} for {host}")
    if host in DENY_HOSTS or host.endswith(DENY_SUFFIXES):
        raise PolicyViolation(f"restricted target {host}")
    return url

def fetch(url, session=requests.Session()):
    return session.get(check(url), proxies={"http": PROXY, "https": PROXY}, timeout=30)

Beyond the guard, four habits keep accounts healthy:

• Keep a target inventory. Every domain your jobs touch, with the category and the date you checked it against the policy. Review it when either the policy or the job list changes.
• Separate credentials per project so that one misbehaving job can be identified and paused without touching the rest.
• Rate-limit per target, not just per account. Complaints come from targets, and a target that sees polite traffic has nothing to report. Our ethical scraping and rate limiting guide sets sensible defaults.
• Keep your own logs of what each job requested and when. If a complaint arrives, you can show exactly what happened instead of arguing from memory.

Stop all jobs using the account first, including retries and schedulers still running elsewhere. Continued connection attempts after suspension look like evasion.

Then reply through the provider's support channel with specifics: which jobs were running, the target domains, request rates and the business purpose. Attach your own logs if the suspension relates to a complaint. If you find the cause, say what you changed. Do not open a new account while the case is open; on providers with one-account rules that turns a resolvable issue into a permanent ban.

If the provider will not reinstate you, use the outcome to update your target inventory and egress guard before buying elsewhere. The same workload will meet a similar policy at the next vendor, and our overview of whether proxies are legal for business use is worth rereading before you do.