Skip to main content
This page explains the default restrictions for SOAX residential and mobile proxies. Before you buy, check the destinations, ports, and protocols your application needs. Other SOAX products may support different features or have different access requirements.

​
Restricted destinations

Some destinations are restricted by default to help manage legal, security, and network risks. The categories below give an overview, not a complete list of blocked domains and IP addresses. We may add or remove destinations as risks and requirements change. A destination not in these examples may still be unavailable because of other access limits or the destination’s own restrictions. Contact support if you need to check a specific destination before buying. A rule can apply to one hostname or also include its subdomains. For example, example.com covers that hostname and all its subdomains; =example.com covers only that exact hostname.

​
Check a destination

Check whether a URL is on the destination blocklist. A result of “Not on the blocklist” does not guarantee access: port limits, package settings, and the destination website’s own restrictions still apply.

​
Ports & protocols

These are destination ports on the service you want to reach, not the port you use to connect to the SOAX gateway. All other destination ports are blocked by default. This includes common TCP ports for email (25, 465, 587), FTP (21), SSH (22), and RDP (3389). For UDP traffic, use SOCKS5; the HTTP proxy interface does not support it. Destination and port restrictions apply independently: allowing a hostname does not open a blocked port.

​
Your package settings

Your package’s Settings → Guardrails section lets you add your own destination and port restrictions. These can further limit access, but cannot override SOAX’s restrictions. An exception lifts a specific SOAX restriction for the approved package. Other package rules, account requirements, and usage limits still apply. See Package Management for how to manage your packages.

​
Blocked requests and access changes

If a request fails, check both destination and port restrictions. The destination website may also reject a request; see Connection Debugging to troubleshoot. If you contact support, include your package ID, destination, and error message. Do not include credentials. We may review, limit, or withdraw access as risks or requirements change. Our Terms of Use explain how access changes and notifications are handled. Request additional access if your use case needs a destination or port that is restricted by default. An exception does not enable unsupported features or allow prohibited uses. Buying a plan or adding credits does not grant an exception.