Acceptable Use Policies
This is an industry-wide overview of acceptable-use rules at proxy services. The restrictions described below belong to different providers; ProxyCompass conditions are stated separately in the final section.
An Acceptable Use Policy, or AUP, describes what customers may do through a proxy service. It forms part of the provider’s service policies and may be published separately or included in the Terms of Service. Its practical purpose becomes clear when two services advertise proxies for the same task but allow different ways of performing it.
For example, one published policy prohibits collecting information behind a login. Another permits access to non-public information with authorization. Elsewhere, written approval is required for a load test even when the customer owns the website. These differences can determine whether a paid, technically working proxy is suitable for the job.
Scraping: what changes when a page requires a login?
Suppose a company collects prices from a supplier’s website. Some prices are visible to everyone; wholesale prices appear after the company signs into its customer account. For the company this is one price-monitoring project. For an AUP restricted to public data, the two parts fall on opposite sides of the permitted use: the customer’s own valid login does not remove the provider’s restriction.
A policy that permits authorized access to non-public data allows a different assessment. The relevant question becomes whether the customer has permission for the collection itself. Permission to view an account page, export its contents and redistribute the resulting data are separate matters. A subscription that lets an employee read material does not necessarily authorize a program to copy and resell it.
Other clauses concern how the collection runs. Published AUPs expressly require compliance with a target’s robots.txt instructions, API limits and technical rate limits. Under such a clause, spreading requests across many IPs does not by itself make prohibited collection acceptable. The customer agreed to that condition when buying the proxy service; this is not a claim that every robots.txt instruction is a law.
The contents of the pages matter too. Public product prices and publicly visible personal contact details are different data. AUPs can require a lawful basis for personal-data collection and stricter conditions for medical information, children’s data or tracking identifiable people. Restrictions may also cover later publication or AI training. Successful download of a page settles none of these later uses.
Automation is judged by what it does
“Scraper”, “bot” and “social-media tool” describe software, but say little about its behavior. The same browser automation can inspect an advertisement or manufacture a paid click. Published AUPs distinguish the following activities; support for the task in the left column does not imply permission for the action on the right.
| Task a service may support | Activity restricted by published AUPs |
|---|---|
| Checking ad placement and visibility | Generating fake impressions or paid clicks, including clicks intended to consume another advertiser’s budget. |
| Monitoring search results and positions | Manufacturing clicks to manipulate rankings or make traffic appear to come from interested users. |
| Managing a business’s social accounts | Creating fake profiles, reviews, followers or engagement; mass account registration can also be prohibited. |
| Monitoring ticket prices and availability | Automated purchasing for mass acquisition or scalping. Some policies prohibit ticket-purchasing bots as a category. |
The same distinction explains why an anti-spam rule can apply even when email ports are blocked. Messages can be sent through a website’s forms, comments or private-message interface. Closing an SMTP port prevents one route for sending email; it does not stop every form of unsolicited messaging.
More direct forms of abuse include brute force, which tries possible passwords, and credential stuffing, which tests stolen login-and-password pairs. Policies also prohibit phishing, stolen-card checks, malware distribution, DDoS attacks and illegal content, including exploitation of children and copyright infringement. These prohibitions concern the activity itself: a small number of attempts can breach AUP even when almost no traffic is consumed.
Restrictions that go beyond attacks and fraud
AUPs also contain commercial exclusions. Actual published lists include paid surveys, trading in-game items, streaming-related domains, cryptocurrency trading, gambling and adult content. These are examples from different service rules, not a common ban across the industry. A provider can exclude a business activity without claiming that every instance of it is criminal.
Resale is another concrete restriction. Selling customers access to rented proxy credentials can require a separate agreement or be prohibited by the standard contract. A dashboard’s subuser feature does not settle the issue: separate credentials can be intended for a customer’s own team. An agency using proxies to prepare reports and a business selling the proxy access itself are offering different services.
Some terms protect the proxy pool itself. They prohibit supplying information obtained about its addresses and nodes to databases that detect proxies, assess IP reputation or block traffic. For example, renting access to catalogue the IPs used by the provider to reach websites and contribute them to a proxy-detection database can breach such a clause even though no target website was attacked. The restriction protects the network’s commercial value.
These clauses explain why AUP cannot be reduced to a list of crimes. They can decide whether a lawful business model fits a particular service. A change from internal research to resale, or from collecting public prices to building a dataset about people, may change the contractual assessment even if the same program and proxy settings are used.
Testing your own website can still require approval
A company hires a contractor to scan its website for vulnerabilities. The company can authorize the test, but it does not control the contractor’s proxy network. Published proxy rules include an explicit requirement for the provider’s written consent before vulnerability scanning or stress and load testing. The website owner’s permission therefore does not always complete the approval needed for the job.
The network carrying the test also faces the resulting traffic and complaints. A scan may reach systems outside the agreed target; a load test can affect shared hosting or protective services. Where a provider allows these tests, agreement on the targets, methods and period identifies which traffic it agreed to carry. A general description such as “security research” does not establish that scope.
How activity through a proxy becomes an abuse report
A destination sees the IP used by the proxy. If its operator observes password attacks or a network scan, its evidence initially identifies that address. The report may go to the proxy provider or to the hosting company supplying the address and server. In the second case, the proxy seller receives the issue from its own supplier.
Published hosting documentation shows what such evidence can contain. A network-scan record lists the time, source IP, destination IP and destination port. Repeated connections from one source to port 22 on different servers, for example, can be reported as a scan of SSH services. A traffic-flood report may instead contain packet rates and a summary of traffic by destination. These records describe different incidents and require different explanations.
The provider then needs to associate the external event with customer activity. With a dedicated address the assignment may help; with shared or rotating proxy IPs, the address alone can be insufficient. Customers may use the same IP at different times or simultaneously. Exact time, its time zone and, where available and relevant, source ports help distinguish connections. This depends on the records actually held by the network.
The time a complaint arrives is also different from the time of the activity it describes. A job that is idle when support writes to the customer may have generated the reported traffic earlier. That is why checking only the current process list or whether the proxy works now does not answer the report.
This process does not require a proxy provider to read every HTTPS page. With ordinary end-to-end TLS through a proxy tunnel, page paths, submitted passwords and response contents are encrypted. A target can supply evidence from its own side, while a provider or host has the network information available to it. A managed browser or scraping API that actually processes pages has a different role and visibility.
Why one destination may stop working while others still load
Enforcement does not always disable an account. A published complaint-handling procedure allows temporary restriction of only the website or host named in a report. Other traffic can continue. In that situation a proxy checker can report a working connection even though the customer’s main job cannot reach its destination.
There are also preventive rules. Some services monitor request rates to sensitive destinations, such as bank login pages, and apply additional restrictions when activity becomes excessive. A category can therefore be reachable under normal use without being available for unrestricted automated requests. These are destination controls, not necessarily a monthly traffic allowance.
AUP and fair use can overlap here, but the reason for intervention still matters. A price collector can overload a shared resource while performing an allowed task. Password attacks can violate AUP at a much lower volume. Buying more traffic addresses the first problem only if it changes the relevant capacity; it does not authorize the second activity.
An upstream host can impose a wider restriction. Hosting rules describe locks on an individual IP, several addresses or an entire server after attacks and scans. A proxy seller using that infrastructure may have to resolve the incident with the host before access returns. Replacing a proxy IP while continuing the same activity leaves the cause in place.
Nor is there a universal warning sequence. Some policies describe attempts to resolve a problem with the customer while reserving suspension after a first offense. Published account systems also distinguish an abuse report, a detected AUP violation and a payment-fraud problem. The customer needs to know the stated reason and scope of the restriction; the single word “suspended” does not provide that information.
If a contractor or another user sent the traffic
Proxy credentials may be installed in several applications or handed to an agency. Provider terms can make the account holder responsible for activity performed through that access. The provider’s relationship is with the customer who purchased the service, so an explanation that a contractor ran the program does not by itself resolve the incident.
The practical task is to identify which application or person used the credentials at the reported time and stop the relevant activity. If access was leaked, exposed credentials need to be revoked or changed. Separate credentials and task records, where the service supports them, can make this work easier. They do not create an exception to AUP.
Account restrictions can also cover attempts to bypass the provider’s own rules: opening replacement accounts after a ban, claiming repeated trials against the stated conditions, or evading identity verification. A new account or newly assigned IP does not turn the same prohibited operation into an approved one.
What happens to the paid package and its balance
There are several possible financial consequences, and they should be kept distinct. One is a fee for the work involved in handling a complaint. Another is loss of unused service entitlement when a contract is terminated for a breach. A third is an obligation to cover specified third-party claims or expenses caused by the customer’s conduct. The amount paid for the proxy package does not necessarily limit all of these obligations.
These are actual contractual differences. Published terms include forfeiture of unused credits after termination for a breach, while providing different treatment when the provider ends service for its own convenience. Some also state that a compliance suspension does not automatically extend the subscription or the credits’ validity. An idle account therefore does not necessarily mean its paid term has paused.
A complaint-handling fee has no standard industry-wide amount. Paying it covers the charge stated in the agreement; it does not buy permission to continue prohibited activity or guarantee restoration. Conversely, the arrival of a report alone does not establish every financial consequence. The relevant grounds for restriction or termination and the applicable payment provisions determine the contractual result, subject to mandatory legal rights.
What to send when support contacts you
Support needs a response about the activity described in the report. “The proxy works”, “the package is paid” and “we only do scraping” do not identify what generated the reported connections. A useful response links the event to the customer’s actual job and explains what has been done.
- Pause the affected job and retain its settings and available logs. Use the time of the reported activity, including its time zone, rather than the time you received the message.
- Identify the application, scheduled task, employee or contractor using the access. Compare the destination and proxy IP with your records. Request any missing details through the provider’s support channel.
- Describe the cause and the change you made: for example, the job was stopped, an unintended destination removed, or exposed access revoked. For a previously agreed test, include the written permission and its scope.
- Confirm which restriction remains and what the provider requires before the permitted work can resume. Avoid restarting the same operation on another IP while the cause remains unresolved.
The provider may use a ticket, a dashboard form or a dedicated response process. Some services expose the complaint text and its status through an API. These are ways to handle the incident; none establishes a universal time for restoration. A deadline for reviewing the customer’s response is also different from a promise to reactivate the service.