Sometimes the problem looks illogical. There is no sharp surge of visitors on the site, the traffic on the graphs does not hit the channel limit, the number of requests does not look catastrophic. But pages open slowly, some requests fail, the web server starts taking more memory, and the application responds every other time. In such cases, people often look for a heavy script, a database error, or a lack of resources on the plan. And that really does need to be checked. But there is one more scenario that is easy to miss: abnormal load through HTTP/2. In particular, an attack called HTTP/2 Bomb.
Its danger is not that millions of requests are flying at the server. The problem is different: a small number of specially formed HTTP/2 connections can force the server to spend a disproportionate amount of memory and hold internal resources for longer. From the outside, everything does not look that bad, while inside the web server is already working at its limit.
What HTTP/2 Bomb is about
HTTP/2 is not a problem by itself. It is a normal protocol that helps websites work faster: it allows several requests to be sent within one connection, compresses headers, and reduces extra connections between the browser and the server. But these same capabilities create room for abuse. If a server accepts HTTP/2 without sufficient limits, an attacker can keep connections open, create a lot of internal work for the web server, and gradually take up memory. At the same time, network traffic may remain relatively small.
So HTTP/2 Bomb is not an “attack by volume” in the usual sense. It is an attack on how the server handles connections. That is why it is harder to notice using simple traffic graphs.
Why VPS reacts to this kind of attack faster
With a VPS, resources are limited by the plan: RAM, CPU time, disk subsystem. If the web server suddenly starts consuming memory because of suspicious HTTP/2 connections, the reserve runs out quickly.
In practice, this can look like unstable operation of the whole site. First, nginx or Apache starts responding more slowly. Then PHP-FPM, Node.js, a Python application, or another backend begins to “choke”. After that, 502, 503, and 504 errors may appear. If there is not enough memory at all, the system starts terminating processes or services restart.
The worst part is that an attack on one site on a VPS can affect everything placed next to it. For example, an online store, a test project, a CRM, and a database are running on the server. Formally, only the public site is being attacked, but resources are taken away from the entire environment.
What happens on a dedicated server
A dedicated server has a larger power reserve, but that does not make it invulnerable. If HTTP/2 connections are handled by a front-facing web server, reverse proxy, or load balancer, this exact layer takes the first hit.
On a dedicated server, the consequences are often stretched out over time. At first, memory usage simply grows. Then the number of open connections increases. After that, sites that were not even the direct target of the attack start responding more slowly. If there are many virtual hosts or several client projects on the machine, the problem quickly stops being local and becomes server-wide.
A separate case is when a dedicated server is used as a proxy in front of other servers. In that situation, a failure at the HTTP/2 level can affect the whole scheme: the frontend stops passing requests further normally, although the backend servers are physically still alive.
How to understand that the problem may be in HTTP/2
The first warning sign is that the server is struggling, but there is no classic DDoS picture. The channel is not overloaded, total traffic does not look record-breaking, and the web server’s memory is growing faster than expected.
It is worth checking how many connections are open to nginx, Apache, Envoy, or another entry-point service. You need to see whether there are long-lived connections that transmit little data but remain active for a long time. Error logs, 502/503/504 statistics, changes in RAM usage, and process behavior after restarting the web server are also important.
If after a restart everything stabilizes only for a short time, and then the situation repeats, that is a reason to look more closely at the connection level. HTTP/2 Bomb is not necessarily to blame, but it should not be ruled out.
What to check in the configuration
It is better to start with the basics: the version of the web server, system packages, and components that accept HTTP/2 connections. Old versions of nginx, Apache, Envoy, IIS, or intermediate proxies may have behavior that has already been fixed in updates.
After that, the limits need to be reviewed. The server should not accept any number of streams without control, keep connections open for too long, or allow one client to consume a disproportionate amount of resources. Limits on waiting time, the number of simultaneous connections, the number of HTTP/2 streams, header size, and request rate are important.
For VPS, this is especially critical, because even a small mistake in limits can quickly turn into a service outage. For a dedicated server, limits are no less necessary, it is just that the problem may remain unnoticed for longer there.
How to reduce the risk
The simplest prevention is not to leave HTTP/2 “as is” if the server accepts public traffic. The web server needs to be updated, timeouts configured, connection limits introduced, rate limiting used, and monitoring should cover not only traffic, but also memory and the number of active connections.
If CDN or WAF is used, it is important not just to enable it formally, but to check how it works with HTTP/2. Part of the protection may filter large traffic flows, but it does not always see the problem well at the level of long-lived or “heavy” connections.
In a critical situation, HTTP/2 can be temporarily disabled on the entry web server to stabilize the site. This is not a universal solution and not a replacement for proper configuration, but as an emergency step it can sometimes help quickly return the service to a working state.
What to do after the incident
After stabilization, it is not worth stopping at the phrase “the server did not have enough resources”. You need to figure out why exactly they ran out. If the cause was HTTP/2 load, simply increasing RAM or moving to a more powerful plan will only postpone the problem repeating.
The correct logic is different: update components, close weak spots in the configuration, add limits, check logs, set up monitoring for connections and memory. For VPS, this helps avoid bringing the system to a sudden crash. For a dedicated server, it helps prevent one problematic entry layer from taking down several services at once.
HTTP/2 Bomb should not be treated as rare exotica, but as a reminder: a server can be vulnerable not only because of a weak password or an old application. Sometimes incorrectly limited connections are enough for a stable VPS or a powerful dedicated server to start behaving as if it is being attacked much harder than the traffic graphs show.