TCP limits and automatic outbound blocking
If your VPS is running but cannot reach external services, a network protection may have automatically blocked its outbound traffic after a TCP limit was exceeded or unusual behaviour was detected. This page explains what may trigger the block and what to do before asking support to unblock it.
Understand TCP limits
The default limit is 20 000 simultaneous TCP connections per IP address. There is no default limit on new connections per second (CPS). Targeted protection may nevertheless limit or block traffic when unusual or suspicious behaviour is detected.
Two different measurements must be distinguished:
Simultaneous connections: the number of TCP connections kept open at the same time.
New connections per second (CPS): how quickly new TCP connections are opened. This measurement may help with diagnosis, but it is not subject to a systematic default cap.
These limits are different from bandwidth in Mb/s or Gb/s. An application’s request count is also not the same as the number of new TCP connections: reusing a connection allows several requests to be sent through it.
If your workload requires more simultaneous connections or a specific protection has been applied to your IP, open a support ticket. Describe your workload and the observed peaks; support will confirm the applicable conditions.
What automatic protection blocks
When the simultaneous connection limit is exceeded or unusual behaviour is detected, the IP’s outbound traffic may be automatically restricted or blocked. Connections initiated by the VPS to APIs, update repositories, email services or other external services may then fail or time out.
An inbound connection may still work while an outbound connection fails. This does not guarantee that your application works completely: an externally reachable website may depend on a remote API or database that has become unreachable. Communication also depends on the filtering rule applied.
Such a restriction does not, by itself, prove that the VPS is stopped or that the entire infrastructure is unavailable. The block is applied at the network level; opening more ports in the operating system’s firewall is not enough to remove it.
Why the block may be triggered
Possible causes include an application opening a connection for every request, tasks starting simultaneously, too many workers, a heavily used proxy or repeated retries without a delay after an error. A compromised process or scanning traffic may also generate excessive activity.
A legitimate workload can reach a technical limit. Triggering protection does not, by itself, establish the client’s intent; the process and its behaviour need to be identified.
What to do if your IP is blocked
Reduce the source of traffic. Pause the suspected task or limit its simultaneous connections and frequency. If the source is unknown, identify active processes and examine their logs.
Correct connection bursts. Reuse connections with a pool or keep-alive, reduce the number of workers, spread out tasks and add increasing delays between retries.
Check the symptoms. State whether inbound access works, which destinations fail and whether IPv4, IPv6 or both are affected. A ping alone is not enough to draw a conclusion; follow the network diagnosis guide.
Ask how the block is lifted. Support will confirm the rule, any delay and the unblocking conditions applicable to your IP. The block may be lifted automatically depending on the protection used; traffic that remains excessive may trigger another block.
Test, then resume gradually. Once the block is lifted, make a limited test to the required destination before restarting the workload. If the block returns, stop the bursts and add your observations to the ticket.
In the ticket, include the affected service and IP, the start time with its timezone, destination IPs and ports, the application involved, error messages and actions already taken. Include connection or CPS peaks if you measure them, along with useful logs with confidential data removed.
Prevent another block
Measure peaks rather than just averages. Limit simultaneous connections, reuse connections, avoid rapid reconnection loops and spread out scheduled tasks. For a workload requiring a higher cap, have the adjustment validated before restarting production.
Ports, addresses and private networking
A port’s availability depends on the operating system’s firewall, network protections and any service restrictions. For SMTP email, have the conditions applicable to your IP addresses confirmed; this page does not guarantee that port 25 is permanently open.
Use your assigned addresses
Configure only the addresses and prefixes assigned to your service. Anti-spoofing protects the infrastructure against the use of unauthorised addresses. Do not replace the virtual MAC address or the provided routing to try to use another IP address.
Two VPS instances with public addresses can communicate over the Internet if their firewalls allow it. Tenant isolation does not mean that a public connection to another client is impossible.
For a private link between your services, arrange validation of a private network with support.
Traffic and fair use
Unlimited VPS traffic does not mean permanently guaranteed burst bandwidth. Excessive use may result in a temporary limit to the guaranteed bandwidth, according to the terms published for the plan.
If you receive an abuse report
Read the ticket you received, identify the service, secure the operating system and respond with the actions taken. Keep useful logs without disclosing your users’ data. The deadline requested in the report and the contractual terms determine the applicable procedure.
The terms of use are the reference for permitted uses. For a network problem, attach diagnostic information to your ticket.
Updated on 5 October 2026. References: VPS, terms of use.