Am I under a DDoS attack? How to tell, and what to do
When a server slows down, the first explanation that comes to mind is an attack. In reality most cases are not attacks: a resource bottleneck, a misconfiguration, or the application itself. So the first half of the diagnosis is eliminating what is not an attack; the second half is knowing what to do if there really is one.
The conceptual explanation of attack types and protection layers is in a separate article: what is DDoS protection. Here there is only one question: are you under an attack right now?
1. Rule out the ordinary causes first
An attack is the most expensive explanation; start with the cheapest ones. If one of the CPU, memory or disk measurements inside the server is at its limit, the explanation may end there: why did my server slow down
The distinguishing sign is this: in an attack the in-server resources look comfortable while access from outside breaks. In a resource bottleneck the opposite happens — you can log in, but everything inside is slow.
2. Which layer is the symptom in?
There are three typical patterns and they point at three different places.
| Symptom | Likely layer |
|---|---|
| In-server measurements clean, no access at all from outside | Line saturation, volumetric attack |
| High CPU with most of the load in the kernel / softirq side | Packet processing load, packet-rate attack |
| Only the web service is unresponsive, SSH opens normally | Application layer (L7) or an application fault |
| Everything is slow and the resources are full too | Not an attack — a resource bottleneck |
3. Look at the traffic graph
The bandwidth and packet graphs in the customer panel are the fastest evidence. The signature of an attack is a sudden, vertical and sustained rise in inbound traffic; normal load grows gradually and moves in proportion with outbound traffic. Inbound swelling out of proportion to outbound is a strong sign on its own.
While you are looking at the graph, check the status page too: if there is a general incident, the diagnosis ends there.
4. Two measurements from inside the server
ss -s
ss -tn state syn-recv | wc -lThe first gives a summary of open connections. The second counts half-open TCP connections: that number climbing into the thousands is the classic signature of a SYN flood.
If you want to see what the traffic looks like, a short sample is enough:
tcpdump -n -i any -c 200What you are looking for is a pattern: small, similar packets arriving at the same port from a large number of different source addresses. Heavy requests from a single source are not a DDoS, and can simply be blocked.
5. Why the picture is different on a UDP game server
In TCP a connection is established with a three-way handshake, so the source address can be verified. UDP has no such step: the source address can easily be forged. That has two practical consequences.
First, the source addresses you see are most likely not real; blocking IPs with iptables achieves nothing except blocking innocent third parties. Second, because the packet has already reached your line, no measure taken inside the server will empty that line. For game and voice traffic, filtering has to happen at the network layer; that is why protection on the game server plans is configured on the network side rather than inside the server.
For the same reason, a proxy in front of HTTP does not protect a game server: that layer never sees the UDP packets.
6. What happens during an attack at Datafex
Traffic passes through layers in sequence before it reaches you. The first scrubbing happens where traffic comes in: traffic from Turkish ISPs is filtered at distributed nodes inside Türkiye and international traffic at filters abroad. What remains reaches our DPDK + VPP router, where reflection and amplification attacks (DNS, NTP and TCP amplification among them) are filtered as well. The last layer is Fexwall; working between L4 and L7, it removes traffic with forged source addresses, tracks connection state and applies the rules defined for your project.
This has an important consequence for diagnosis: most of a volumetric attack never reaches your server at all. Not being able to "see" the attack from inside the machine is therefore normal; the right place to look is the Fexwall section of the panel, where dropped traffic, blocked sources and active rules are shown. The protection is included free on all virtual server and dedicated server plans; transit capacity is 100 Gbps domestic and 10 Tbps international.
If you own your IP range and an ASN, the same filtering can be applied even when your servers are somewhere else: BGP protection
What to do on your own side
What needs doing during an attack is short. Narrow the service surface: close every port that does not need to face the internet, restrict management panels to your own address, and keep the database port off the internet. All of it is in the basic server security steps.
What not to do matters more: do not try to block spoofed UDP traffic inside the server, do not panic-write broad firewall rules that lock out your own players, and do not assume changing your IP address is a permanent fix — the attacker will find the new one too.
When to open a support ticket
Unlike the other diagnoses here, there is no reason to wait: if there is any sign of line saturation, open a ticket immediately. Having a filter rule defined for your specific attack profile produces results faster than anything you can do inside the server.
Put this in the ticket: the target IP and port, the protocol (TCP/UDP), the time the attack started, the exact symptom, and the time range of the traffic spike if you can see one in the panel. If you are not a customer yet and are under attack at your current provider, write through the contact page; how the protection side is set up during a migration is planned separately.