Acceptable Use Policy

An Acceptable Use Policy (AUP) defines which activities a proxy provider permits, which it prohibits, and when it can restrict or terminate access. It is part of the Provider Policies that govern the service. Buying a proxy gives the customer access to a network; the AUP sets the conditions for using that access.

In the second half of 2026, commercial proxy services openly support scraping, advertising research, and automation while prohibiting many other activities performed with similar software. The difference lies in what the software does, whose systems and data it accesses, and what permission exists. A fully paid, technically working proxy can be suspended for an unacceptable use case, even when the customer has traffic or subscription time left.

Why providers restrict paid access

A proxy request reaches a website from the provider's exit IP. If that address sends spam, attempts account takeovers, or overwhelms a server, the complaint initially points to the network carrying the traffic. The consequences can spread beyond one customer: address blocks damage the pool, residential participants receive unwanted attention, and infrastructure suppliers may demand that the activity stop.

For a datacenter proxy service, the decision can come from an upstream hosting company. Hosting rules allow individual addresses or entire servers to be locked after certain incidents. A proxy seller using that infrastructure may therefore have to stop a customer's traffic to protect access for everyone else.

AUP rules also protect commercial interests. A provider can prohibit reselling its service or mapping its pool even when the activity does not resemble a cyberattack. Legal activity and activity allowed by a particular provider are different questions.

Fair Use Policy addresses a related but different issue: resource consumption. A permitted price-monitoring job can exceed its connection allowance; a small stream of fraudulent login attempts can violate the AUP without using much traffic. An unlimited plan removes neither category of restriction.

Activities that AUPs prohibit

Attacks and unauthorized access

Prohibitions commonly cover denial-of-service attacks (DoS and DDoS), malware distribution, phishing, botnet activity, and attempts to access systems without permission. Password attacks include both brute force—trying possible passwords—and credential stuffing, which tests previously stolen username-and-password combinations on other services.

Port scanning, vulnerability scanning, and load testing require closer attention. They have legitimate security uses, but they can also trigger abuse reports. A provider may prohibit them outright or require written approval before they begin. Calling an activity research does not establish authorization.

Fraud, fake engagement, and account abuse

Advertising research and advertising fraud can use the same proxy infrastructure for opposite purposes. Checking whether an advertisement appears correctly in another country is a legitimate business use. Generating paid clicks or impressions that pretend to represent interested customers is click fraud.

Similar distinctions apply to social platforms. Managing accounts for real clients is different from manufacturing fake likes, followers, reviews, or account registrations. AUPs can prohibit bulk registration, impersonation, automated posting, or artificial engagement even when the product is advertised for social-media work.

Other explicit restrictions found in published policies include checking stolen payment-card details, manipulating votes, exploiting referral rewards, and using bots to defeat ticket-purchase limits. Ticket-bot restrictions can apply independently of whether a customer describes the operation as shopping automation.

Spam and unwanted messages

Spam restrictions can cover email, direct messages, comments, and automated posts. Purchasing proxies intended for automation does not grant permission to send unsolicited messages through them.

The important distinction is the activity itself. Blocking a mail port is one way to reduce email abuse, but a customer can still violate an anti-spam rule through a web application. Conversely, a provider's decision to block a port does not prove that a particular customer has sent spam.

Illegal content and restricted businesses

Policies commonly prohibit child sexual abuse material, unlawful threats, terrorist activity, illegal trade, and infringement of intellectual-property rights. They may also restrict lawful categories that the provider does not want to support, including adult content, gambling, streaming, or cryptocurrency-related services.

Those additional exclusions vary. An adult-content restriction is not evidence that all adult content is illegal, and a restriction on cryptocurrency trading is different from accepting cryptocurrency as payment for proxies. The wording identifies which activity the provider is refusing to carry.

Scraping, public information, and permission

An AUP for a data-collection network usually needs to distinguish permitted collection from prohibited access. Public product prices, search results, and advertisement placements are familiar commercial examples. Their availability does not settle every question about collection methods, personal information, or later reuse.

Content behind a login or paywall raises a separate issue. Some services limit their products to publicly available data; others require authorization for access to non-public information. Possessing a working account is not necessarily permission to export everything that account can display. A subscription to read content also does not automatically permit bypassing access controls or redistributing it.

Personal data requires another distinction: publicly visible does not mean free of privacy obligations. Published contact details or social profiles can still concern identifiable people. Medical records, financial details, identity documents, passwords, and children's information create additional risks and can be expressly prohibited by a provider's policy. Rules such as the GDPR and California's CCPA may also apply to a collection project, depending on the people, data, and business involved.

An AUP may also require compliance with a target's terms, API restrictions, robots.txt instructions, or other stated collection limits. These are contractual requirements of that service; they should not be confused with a universal claim that every robots.txt instruction is itself a law.

The same separation matters for tools marketed as unblockers. A product's ability to deliver a page does not establish permission for every use of that page. Some policies now address what happens after collection, including prohibited uses of data in AI systems. Successful retrieval is only one part of the permitted workflow.

Security testing needs two kinds of permission

A company may authorize a security consultant to test its own website, yet the consultant's proxy service may still prohibit scanning or stress testing. The target owner's permission concerns the target. The proxy provider's permission concerns the network used to perform the work.

Published proxy rules include requirements for the provider's written consent before scanning or load testing. Where approval is available, its scope matters: a specified target, test type, and period do not amount to unrestricted permission to test other systems.

This is also why an explanation such as “we were only testing” may not resolve a complaint. The provider must distinguish authorized testing from activity that it never agreed to carry.

Accounts, contractors, trials, and resale

The account holder's responsibility often extends to activity performed with their proxy credentials by employees, contractors, or other authorized users. Giving an automation agency access does not move the provider's contract from the customer to the agency. A compromised password can also cause the account to be restricted while the incident is investigated.

Policies may separately prohibit sharing a main account, creating replacement accounts after a ban, registering multiple accounts to obtain repeated trials, or bypassing identity checks. An approved business purpose can matter too: an account opened for price monitoring is not necessarily approved for an unrelated operation started later.

Resale is another contractual boundary. Some providers require prior written consent; others prohibit third-party access under their standard terms. A dashboard that supports subusers or separate credentials does not, by itself, grant permission to sell access to strangers.

There are less obvious restrictions as well. Published terms include prohibitions on probing the provider's own pool and supplying its IP information to systems that identify or blacklist proxies. These clauses protect the network's commercial value. They are examples of why an AUP can extend well beyond a list of illegal activities.

How providers detect possible violations

An external complaint is one starting point. Others include suspicious connection patterns, payment problems, misuse of accounts, or activity inconsistent with the declared purpose. Providers can combine automatic rules with manual review and requests for an explanation. A fraud alert, an abuse report, and a confirmed AUP violation are different events, even if each can temporarily affect access.

Monitoring does not require reading every page a customer opens. Connection destinations, timing, traffic volume, and other available network records can reveal patterns worth investigating. A target site or hosting company may also supply evidence that is not visible from the proxy's own records.

An ordinary HTTPS tunnel does not automatically reveal the full page URL, submitted password, or response content to the proxy provider. End-to-end TLS protects that content. A managed browser or scraping API that processes pages for the customer has a different role and can see information needed to perform that task. Claims that every proxy network scans all encrypted page contents would confuse these services.

Automated classification can assist enforcement, but the actual information available depends on the product, its configuration, and its logging practices. Detection can be manual as well; a provider does not need an AI system to act on a well-documented complaint.

Blocked websites, apps, and ports

Some providers prevent access to selected destinations before any individual complaint arrives. Restrictions can cover government or military domains, including .gov and .mil, banking websites, and payment services such as PayPal or Stripe. Coverage differs by provider and product; these categories are not automatically blocked across the entire proxy market.

Port restrictions are another preventive measure. A provider may block email-sending ports such as 25, 465, or 587 to reduce spam. A blocked destination or port describes where traffic cannot go; the AUP explains which activities are unacceptable. Even when a destination is reachable, its use remains subject to those rules.

What an abuse report establishes

An abuse report is a claim about activity, not a verdict. It can come from a website operator, a security team, a rights holder, or an infrastructure supplier. Reports may identify an exit IP, a time, a destination, and the behavior observed.

That detail matters when addresses are shared or rotated. Two customers can use the same exit IP at different times—or simultaneously. An address appearing in a complaint does not, on its own, identify the responsible account. Accurate timestamps and, where available and relevant, connection ports help match an event to the network's records. A timestamp interpreted in the wrong time zone can point an investigation toward the wrong session.

The provider needs suitable evidence to make that association. This does not mean every provider retains the same logs or can reconstruct every request. It does explain why both an unexplained accusation and “that IP was in my package” are incomplete descriptions of an incident.

A provider may restrict access during the review because the potential harm is still ongoing. Temporary action therefore does not necessarily mean that it has finished deciding responsibility.

What happens to the service

Enforcement can affect one destination, part of a product, or the whole account. The following measures have different consequences:

There is no universal requirement to issue a warning before suspension. A policy can promise to try to resolve problems with the customer while reserving the right to suspend access after a first incident. A suspected attack in progress is not necessarily handled like an accidental configuration problem that has already stopped.

An upstream restriction can also limit what support can restore. If a hosting supplier has locked an address or server, changing the status in the proxy provider's dashboard may not be enough to bring it back.

Review, appeals, and restoration

Some providers offer a formal response or appeal process. Published implementations include access to complaint details and a dedicated way to challenge a suspension. One service states that it reviews a customer's response to an abuse report within one business day. That is a service-specific review period, not a market-wide promise of restoration within 24 hours.

The useful substance of a review is what happened and whether the cause remains. For an erroneous report, that can be a mismatch between the reported time, destination, and assigned session. For a real incident, it can be an uncontrolled script, compromised access, or a contractor's activity that has now stopped. These are different explanations with different evidence.

Replacing an IP while continuing the same prohibited behavior does not resolve the complaint. Restoration depends on the provider's decision and, sometimes, its infrastructure supplier's approval. An accepted explanation may restore access; repeated or deliberate violations can instead end the relationship.

What happens to prepaid money

Service access and money are separate decisions. Published contracts include termination for an AUP breach without a refund, forfeiture of unused credits, and continued liability for charges already incurred. A customer can therefore lose access before the end of a prepaid month or before using the purchased traffic.

That does not make every complaint an automatic forfeiture. A temporary investigation, a confirmed contractual breach, and termination for another reason are different cases. The applicable agreement and the provider's stated grounds determine how it treats unused funds, subject to applicable law.

The financial exposure can also extend beyond the package price. Some terms require the customer to cover specified third-party claims, losses, or legal expenses arising from their conduct. This is commonly called an indemnity clause. It is not the same as a fixed fee for receiving an abuse complaint, and no standard industry-wide abuse fee should be assumed.

A refund guarantee is therefore not insurance against prohibited use. Its conditions can exclude AUP breaches even when an ordinary refund window has not expired.

Copyright complaints and official requests

Copyright complaints are one type of abuse report. In the United States, DMCA procedures concern copyright; the label does not turn a spam report or a scanning complaint into a copyright case. A proxy carrying traffic also has a different role from a service hosting an infringing file, so hosting-style removal procedures do not automatically describe every proxy incident.

Some provider agreements permit disclosure of relevant customer information in response to applicable legal requirements and reporting of serious violations to authorities. Payment for anonymity does not remove those obligations. The jurisdiction, type of request, and data actually held affect what can be disclosed; an ordinary complaint does not prove that every requester receives the customer's full records.

Customer conduct and the origin of the IPs

Residential networks have another responsibility: obtaining appropriate permission from the people whose connections carry traffic. Participation may be offered through an application's software development kit (SDK). A legitimate arrangement can involve an informed opt-in, an explanation of how the connection will be used, and a stated benefit or payment. Customer verification helps the provider assess who wants access and for what purpose.

These are separate safeguards. Consent from a residential participant does not authorize a customer to attack a website, and a customer's completed identity check does not establish that every address in the network was sourced properly. AUP, identity verification, and IP sourcing address different parts of the service.

Security assurances need the same separation. ISO 27001 certification concerns an information-security management system within its scope. A SOC 2 report examines specified service controls. Neither is a blanket approval of every customer activity or a guarantee that abuse cannot happen.

When the rules change

Permitted use can change during a long-running project. Published policies range from advance notice of material changes—for example, 14 days—to terms allowing updates without individual notice. New restrictions can concern a target, an activity, or how collected data is used.

For a customer, the decisive question is whether the service permits the actual operation: its targets, access method, automation, and use of the results. A product may support the right country, protocol, and number of connections yet still exclude the business activity it was purchased for.