--- title: "How to detect a DDoS attack on your server: Linux diagnosis | StreetHosting" description: "How to identify a DDoS attack by its symptoms and with Linux commands, separate an attack from a legitimate spike, and gather the right evidence for support." url: "https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server" type: "page" language: "en-US" --- Infrastructure · 9 min · Intermediate Published on Sep 28, 2026 · Updated on Sep 28, 2026 # How to tell if your server is under a DDoS attack General lag, players dropping and a sluggish SSH session can be a DDoS or just an overloaded server. Here are the symptoms, the commands that confirm the attack and what to send to support without wasting time. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [DDoS protection](https://streethosting.com.br/en/guides/topics/ddos-protection) [Linux administration](https://streethosting.com.br/en/guides/topics/linux) [Network, DNS and domains](https://streethosting.com.br/en/guides/topics/networking) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fdetect-ddos-attack-on-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fdetect-ddos-attack-on-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fdetect-ddos-attack-on-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fdetect-ddos-attack-on-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fdetect-ddos-attack-on-server.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=How%20to%20detect%20a%20DDoS%20attack%20on%20your%20server%3A%20Linux%20diagnosis&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fdetect-ddos-attack-on-server "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fdetect-ddos-attack-on-server "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fdetect-ddos-attack-on-server "Share on LinkedIn") [](https://wa.me/?text=How%20to%20detect%20a%20DDoS%20attack%20on%20your%20server%3A%20Linux%20diagnosis%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Finfrastructure%2Fdetect-ddos-attack-on-server "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server.md) In this guide 7 sections * [Symptoms that raise suspicion](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#sintomas) * [The first minutes in the terminal](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#primeiros-comandos) * [A short tcpdump capture](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#amostra-tcpdump) * [Common patterns and how they show up](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#padroes) * [Attack or legitimate spike](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#pico-legitimo) * [What to do during the attack](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#o-que-fazer) * [Where the protection needs to be](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#protecao-inclusa) Quick answer To **detect a DDoS attack on your server**, cross-check three signals: packet loss and high latency for everyone at the same time, bandwidth or packets per second far above normal, and CPU stuck in softirq while the application sits idle. Confirm with iftop, ss and a short tcpdump capture, and compare it with how a legitimate spike behaves. If it is an attack, do not reboot in a loop: keep the evidence and open a ticket with the time, IP, port and the capture. ## Symptoms that raise suspicion[](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#sintomas) A DDoS almost never announces itself. The first warning is the complaints on Discord: everyone lagging, people dropping, the control panel taking forever to open. The problem is that an overloaded server, a bad route and a stuck plugin all produce similar complaints. What points to an attack is the combination of symptoms, not a single sign. * **Packet loss for everyone at the same time:** users on different ISPs and in different states complain within the same minute. A routing problem usually hits one group, such as the customers of a single ISP. * **High latency even over SSH:** the terminal lags behind what you type. That points to a full network queue, not a slow application. * **Saturated link:** inbound traffic brushes the port limit, close to 1 Gbps on a VPS with a 1 Gbps uplink, or packets per second shoot up with few people connected. * **CPU in softirq:** top shows a high si column and `ksoftirqd` processes at the top, while the game or the application uses little. That is the kernel burning CPU just to receive and discard packets. * **Kernel warnings:** SYN flooding messages or a full conntrack table in dmesg. One detail changes the whole reading: what you see inside the VPS is only what is left after the provider's network. With edge protection filtering, the machine can look calm while players feel a brief wobble at the start of mitigation. And if the volume exceeds the link itself, packets are lost before they arrive: the server goes offline and iftop looks almost empty. The attack types behind each picture are covered in [what a DDoS is on a game server](https://streethosting.com.br/en/guides/infrastructure/what-is-a-ddos-attack-game-server). | Symptom | What it suggests | How to confirm | | ------------------------------------------ | --------------------------------------- | --------------------------------------------------------------------- | | General, simultaneous packet loss | Network saturation or volumetric attack | nload on the VPS and MTR from two ISPs | | Loss only for one ISP or region | Routing problem, not DDoS | MTR with loss that starts at one hop and continues to the destination | | High si CPU with the application idle | Small-packet flood | top, mpstat and sar with packets per second | | Thousands of connections in SYN RECV | SYN flood | ss and dmesg messages | | Slow website with normal bandwidth | Layer 7 HTTP flood | Requests per minute in the Nginx log | | A single slow service and a normal network | Internal CPU, disk or memory bottleneck | htop, iostat and free | To separate an attack from a bad route, run an MTR from different networks, as shown in the guide on [how to use MTR to diagnose the network](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr). Loss that appears at an intermediate hop and disappears at the destination is rarely a real problem. ## The first minutes in the terminal[](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#primeiros-comandos) Install the tools before you need them. During an attack apt can be slow, and vnstat only shows history if the service was already collecting data before the problem. `sudo apt update sudo apt install iftop nload vnstat tcpdump sysstat whois ip -br a` The last command lists the network interfaces. On a VPS the name is usually `eth0` or `ens3`. Replace `eth0` in the examples with the name that shows up for you. ### Bandwidth and packets per second[](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#banda-pacotes) `nload eth0 # live graph of inbound and outbound traffic sudo iftop -i eth0 -nNP # who is talking to whom, without resolving names vnstat -l -i eth0 # live rate and packets per second vnstat -5 -i eth0 # 5-minute averages, to compare with yesterday sar -n DEV 1 5 # the rxpck/s column shows packets received per second` In iftop, the `-n` option matters: without it the tool tries to resolve the name of every IP and generates even more traffic at a bad moment. Look at packets too, not just bandwidth. A flood of small packets takes the server down with bandwidth nowhere near the limit, because the cost is in processing each packet, not in the volume in megabits. ### CPU, connections and kernel messages[](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#cpu-conexoes) `top # press 1 to see each core; watch the si column mpstat -P ALL 1 5 # %soft column per core ss -s # socket summary by state ss -Htan state syn-recv | wc -l sudo dmesg -T | grep -Ei 'syn flooding|conntrack|dropping' | tail cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max` In normal operation, connections in `SYN-RECV` stay near zero or in the low dozens. Thousands of them, combined with a line like `Possible SYN flooding on port 25565. Sending cookies.` in dmesg, indicate a SYN flood and show that the kernel has turned on SYN cookies. If the conntrack counter is brushing the maximum, the table is full and the system starts dropping new connections, including those from real players. To see which IPs concentrate established connections on a port, replace 443 with the port of your service: `ss -Htn state established '( sport = :443 )' \ | awk '{print $4}' | sed -E 's/:[0-9]+$//' \ | sort | uniq -c | sort -rn | head` ## A short tcpdump capture[](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#amostra-tcpdump) tcpdump shows what is actually arriving. The rule is to capture little: a few thousand packets, headers only, without your own SSH traffic. A long capture during an attack fills the disk in minutes and adds no information. `sudo tcpdump -ni eth0 -s 96 -c 5000 \ -w /root/amostra-$(date +%Y%m%d-%H%M).pcap 'not port 22'` The `-s 96` option keeps only the first 96 bytes of each packet, enough to see protocol, ports and flags without recording the payload. `-c 5000` stops the capture on its own after 5,000 packets, which during a flood takes a fraction of a second. With the file saved, you can analyze it calmly: `A=/root/amostra-AAAAMMDD-HHMM.pcap # first lines, to see the pattern sudo tcpdump -nr $A | head -30 # most frequent sources sudo tcpdump -nr $A 2>/dev/null | awk '{print $3}' | cut -d. -f1-4 \ | sort | uniq -c | sort -rn | head # how many packets are pure SYN and how many are UDP sudo tcpdump -nr $A 'tcp[tcpflags] == tcp-syn' 2>/dev/null | wc -l sudo tcpdump -nr $A udp 2>/dev/null | wc -l # source ports of the UDP received (53, 123 and 11211 point to reflection) sudo tcpdump -nr $A udp 2>/dev/null | awk '{print $3}' | awk -F. '{print $NF}' \ | sort | uniq -c | sort -rn | head` Keep the .pcap file. It is the most useful piece of evidence for support, and a few seconds of capture are enough. Do not post it in an open group: even without payload, it carries the IPs of real players, and that is personal data. ## Common patterns and how they show up[](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#padroes) You do not need to classify the attack precisely to ask for help, but recognizing the pattern speeds up the conversation with support and shows whether anything on your side is worth changing. The explanation of each type by network layer is in [layer 3, 4 and 7 DDoS](https://streethosting.com.br/en/guides/infrastructure/layer-3-vs-layer-4-vs-layer-7-ddos). | Pattern | What shows up in the capture | Sign on the system | | ----------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | SYN flood | Many packets with only the S flag to the same port, varied sources, almost no ACK coming back | Thousands of connections in SYN RECV and a SYN flooding warning in dmesg | | UDP flood | Burst of UDP to the game port or to random ports, packets of almost the same size | Packets per second far above normal and high softirq | | DNS amplification | UDP arriving with source port 53, large responses you never requested, many fragments | Inbound far larger than outbound, bandwidth near the limit | | NTP amplification | UDP with source port 123 coming from thousands of different servers | Inbound bandwidth saturated in a few seconds | | memcached amplification | UDP with source port 11211 and large packets | Very high, very short bandwidth spikes | | HTTP flood | TCP traffic on port 443 that looks normal | Requests per minute out of pattern in Nginx and application CPU pegged | In amplification, the IPs that appear in the capture are not the attackers. They are misconfigured servers across the internet answering forged queries that carry your address as the sender. That is why blocking IP by IP does not solve it: filtering by source port and by volume has to happen at the provider's edge, before your link. ### HTTP flood in the Nginx log[](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#logs-nginx) In an HTTP flood the bandwidth can be normal. The sign is in the access log, which in the default format lives at `/var/log/nginx/access.log`. `L=/var/log/nginx/access.log # requests per minute over the last few minutes sudo awk '{print substr($4, 2, 17)}' $L | uniq -c | tail -20 # most frequent IPs, URLs, user agents and status codes sudo awk '{print $1}' $L | sort | uniq -c | sort -rn | head -20 sudo awk '{print $7}' $L | sort | uniq -c | sort -rn | head -20 sudo awk -F'"' '{print $6}' $L | sort | uniq -c | sort -rn | head sudo awk '{print $9}' $L | sort | uniq -c | sort -rn` Be suspicious when a single expensive URL, such as search, login or cart, concentrates most of the requests, when the same user agent shows up thousands of times, or when 499, 502 and 504 codes shoot up. If the site sits behind a proxy or CDN, the first field shows the proxy's IP, and you need to configure the Nginx real\_ip module to see the origin. The defenses for that layer are in [layer 7 DDoS](https://streethosting.com.br/en/guides/infrastructure/layer-7-ddos-attack). ## Attack or legitimate spike[](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#pico-legitimo) Before sounding the alarm, check the calendar. A modpack update, a giveaway, a video from a content creator, a streamer raid and the start of a season fill the server with real people, and blocking those people by mistake is worse than the attack. The table sums up the differences that help most. | Criterion | Legitimate spike | Attack | | -------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | Origin | Residential and mobile ISPs in Brazil, in proportion to your audience | Datacenters, countries where you have no players, or thousands of IPs of the same kind | | Start | Ramps up and follows the announcement | Jumps from zero to maximum in seconds, stops the same way and comes back in waves | | Behavior | Full connection, login, browsing through several pages | SYN with no response, the same URL repeated, identical user agent, packets of the same size | | Timing | Coincides with a stream, event, update or post | Coincides with a ban, a fight between communities, a threat or a dead late-night hour | | Bandwidth and players | Bandwidth grows along with the number of connected players | Huge bandwidth with players flat or dropping | | Correlation with promotion | Spikes line up with each promotional action | No event of yours explains the volume | To check the origin of an IP that shows up a lot in the capture, whois shows the block owner and the country: `whois 198.51.100.7 | grep -Ei 'owner|orgname|org-name|netname|country'` A foreign datacenter block hammering a server whose audience is 100% Brazilian is a strong sign. Hundreds of IPs from Brazilian ISPs, with full connections and normal usage, is real people arriving. In that case the problem is capacity, and the answer is to size better, not to block. ## What to do during the attack[](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#o-que-fazer) 1. **Do not reboot the VPS in a loop.** A reboot does not stop traffic coming from outside, it wipes the kernel messages and the counters and, when the server comes back, every player reconnects at once, which looks like a new spike. Restarting a stuck process once is a different matter. 2. **Write down the essentials:** start time with time zone, affected IP and port, and what users are experiencing. 3. **Collect the evidence:** a short tcpdump capture, the output of ss and dmesg, screenshots of nload or vnstat and, for a website, an excerpt of the Nginx log. 4. **Open the ticket** with all of it in a single message, like the template below. 5. **Tell the community** with a short, honest message. The playbook of roles and ready-made messages is in the [incident response plan](https://streethosting.com.br/en/guides/infrastructure/incident-response-plan-gaming-community). 6. **Once things settle,** review the exposed ports and look for where the IP may have leaked. `Subject: Suspected DDoS on IP 203.0.113.10 Service: VPS, service ID from the control panel IP and port: 203.0.113.10, TCP 25565 Start: 09/28/2026 at 21:14 (Brasília time), still ongoing Symptoms: packet loss for every player, slow SSH Measurements: 850 Mbps and 400,000 packets/s inbound in vnstat, 12,000 connections in SYN-RECV in ss Attachments: amostra-20260928-2114.pcap (5000 packets, headers only), nload screenshot, dmesg output` Do not try to retaliate or track down the attacker on your own. Attacking back is a crime, even against whoever started it, and it also puts your IP in the middle of the problem. * Tools installed and vnstat collecting before any incident * Network interface name written down in the runbook * Short capture command ready to copy and paste * Ticket template saved outside the server * Message to the community written in advance ## Where the protection needs to be[](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#protecao-inclusa) No command on this page holds back a volumetric attack. When the link fills up, the only defense is before your machine, in the provider's network. That is why Anti-DDoS has to come with the server, not as a separate item. At StreetHosting the protection is included on every [VPS](https://streethosting.com.br/en/vps) and on the [dedicated servers](https://streethosting.com.br/en/dedicated), with a datacenter in São Paulo. * **Xeon VPS:** Anti-DDoS Enterprise, from R$ 26.00 per month with 2 vCPU, 2 GB of RAM and 20 GB NVMe up to R$ 553.00 with 24 vCPU and 64 GB. More vCPU for your money, a good fit for websites, APIs and bots. * **Ryzen 9 9950X VPS:** DDR5 and clocks up to 5.7 GHz, from R$ 40.00 with 1 vCPU and 2 GB up to R$ 846.00 with 14 vCPU, 64 GB and 640 GB NVMe. It is the line recommended for game servers. Both VPS lines have a 1 Gbps uplink. * **AMD dedicated servers:** Anti-DDoS Gamer, a dedicated 10 Gbps port and 2 TB NVMe, starting at R$ 1,499.00 per month on the Budget SM, with a Ryzen 9 5900XT and 64 GB DDR4. With filtering at the edge, the work on this page changes in nature: instead of trying to hold back the attack, you confirm what is happening and hand support solid evidence. Details on the network and the datacenter are on the [StreetHosting infrastructure page](https://streethosting.com.br/en/infraestructure). In this guide * [Symptoms that raise suspicion](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#sintomas) * [The first minutes in the terminal](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#primeiros-comandos) * [A short tcpdump capture](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#amostra-tcpdump) * [Common patterns and how they show up](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#padroes) * [Attack or legitimate spike](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#pico-legitimo) * [What to do during the attack](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#o-que-fazer) * [Where the protection needs to be](https://streethosting.com.br/en/guides/infrastructure/detect-ddos-attack-on-server#protecao-inclusa) ## Frequently asked questions How do I know if my server is under a DDoS attack? Look for the combination of signs: packet loss and high latency for every user at the same time, bandwidth or packets per second far above normal, and CPU busy in softirq while the application sits idle. Confirm with iftop, ss and a short tcpdump capture before drawing a conclusion. Does rebooting the VPS stop a DDoS attack? No. The traffic comes from outside and keeps hitting the IP after the reboot. Rebooting in a loop wipes the kernel messages and counters that would serve as evidence, and it also triggers a mass reconnection when the server comes back, which muddies the diagnosis. How do I tell a DDoS from a spike in players? A legitimate spike ramps up, follows a promotion or an event, and comes from residential and mobile ISPs that match your audience, with full connections. An attack usually jumps from zero to maximum in seconds, comes from datacenters or from sources unrelated to the community, and shows repetitive patterns, such as SYN with no response or the same URL over and over. What should I send to support during an attack? Start time with time zone, affected IP and port, the symptoms observed, bandwidth and packets-per-second figures, the output of ss and dmesg, and a short tcpdump capture with a few thousand packets. With that, support can locate the event without having to ask everything again. Why is the server offline while iftop shows little traffic? Because what the VPS sees is only what is left after the provider's network. If edge protection is filtering, little gets through. If the volume exceeded the link itself, packets are lost before they enter the machine. In both cases the diagnosis needs the provider's view, so open a ticket. Next step See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS. [See VPS plans](https://streethosting.com.br/en/vps) [See dedicated servers Exclusive hardware in São Paulo with NVMe and Anti-DDoS.](https://streethosting.com.br/en/dedicated) [Explore the infrastructure Datacenter in São Paulo, gamer network and options for high-demand projects.](https://streethosting.com.br/en/infraestructure) ## Related guides [Infrastructure Beginner What is a DDoS attack on a game server? Explained DDoS is not ordinary lag, and it is not a crash caused by a badly written plugin. It is a coordinated campaign to flood the network or the CPU until nobody can connect. This guide explains the attack in plain language and what your community should expect from real mitigation. 6 min Read guide](https://streethosting.com.br/en/guides/infrastructure/what-is-a-ddos-attack-game-server) [Infrastructure Intermediate Layer 3 vs layer 4 vs layer 7 DDoS: what's the difference? A layer 3 DDoS fills the pipe, a layer 4 DDoS fills up connection tables, and a layer 7 DDoS makes the application work until it falls over. See what each one exhausts and at which point in the infrastructure each defense works. 9 min Read guide](https://streethosting.com.br/en/guides/infrastructure/layer-3-vs-layer-4-vs-layer-7-ddos) [Infrastructure Intermediate Anti-DDoS for game servers in Brazil: how edge protection works A DDoS attack on a game server can combine high volume, streams of tiny packets and fake connections to wear the network down. Effective mitigation starts before traffic reaches the server, with edge filtering, traffic analysis and an operation that is ready for real incidents. For anyone hosting communities in Brazil, the right choice cuts downtime during peak hours. 5 min Read guide](https://streethosting.com.br/en/guides/infrastructure/anti-ddos-game-server-brazil) [← Back to the Guide Center](https://streethosting.com.br/en/guides)