Back to Blog Search

    Guides

    Signs of a DDoS Attack: How to Tell and What to Do Next

    Alexander Haglund

    Chief Executive Officer

    A
    July 13, 20265 min read

    Your server stops responding, players start dropping, and support messages pile up. The first question is always the same: is this a DDoS attack, or did something just break? The two problems call for completely different responses, so answering it quickly can save you hours of downtime. This guide covers the signs that point to an attack, the checks that help you confirm one, and the steps that get you back online.

    What an attack does to your server

    A DDoS attack (short for distributed denial of service) floods a server or network with junk traffic from many sources at once. The attacker is not trying to break in or steal data. The goal is simpler: use up something you only have a limited amount of, such as bandwidth, connection capacity, or processing power, until real users can no longer get through.

    That goal shapes the symptoms. A compromised server behaves strangely: files change, unknown processes appear, settings move on their own. A server under DDoS attack usually behaves normally. It is just buried. The service is healthy but unreachable, like a shop with a crowd blocking the door.

    Common signs you are under attack

    No single symptom proves an attack on its own. What you are looking for is a combination.

    Everything degrades at once. When junk traffic fills your internet connection, every service behind that connection suffers together: the website, the game server, remote access, all of it. A crashed application takes down one thing. A flooded connection takes down everything at the same moment.

    Ping times and packet loss climb together. Connections that normally respond in 20 milliseconds suddenly take hundreds, and some packets never arrive at all. Players experience this as rubber-banding and disconnects. Website visitors see pages that half-load or time out.

    Inbound traffic jumps far beyond anything normal. If your traffic graph shows ten or a hundred times the usual volume, and there is no launch, event, or marketing push to explain it, that spike is the clearest signal you will get.

    The timing fits. Attacks against game servers often follow a ban, a lost match, or an argument, because attack traffic can be rented cheaply by people with a grudge. If your server went down minutes after a heated exchange, treat that as evidence.

    Your host takes the IP offline. Many providers respond to large floods by null-routing the target address. Null-routing means the provider drops all traffic to that IP, good and bad alike, to keep the flood from affecting other customers. If your host tells you an address was null-routed, that is close to direct confirmation of an attack.

    Four quick checks before you decide

    1. Test from a different network. Try reaching the service from a phone on mobile data, or ask someone in another location. If it works fine from elsewhere, your problem is probably local rather than an attack.
    2. Compare server load with network load. During many floods the server itself sits nearly idle while the network interface is completely full. That mismatch, a quiet CPU behind a saturated connection, points at an attack rather than a software problem.
    3. Check whether neighbors are affected. If other services or servers on the same connection are struggling at the same time, the problem sits at the network level, which fits an attack or an upstream outage rather than a single broken application.
    4. Ask your hosting provider. Your host can see traffic before it reaches you and can usually confirm within minutes whether an address is being flooded.

    Problems that look like an attack but are not

    Ruling these out matters, because the wrong diagnosis wastes hours.

    A legitimate traffic spike can flatten a small server just as effectively as a flood. The difference is behavior: real visitors load pages, join games, and act like users. Attack traffic mostly connects and does nothing useful, or never completes a connection at all.

    A bad deploy or configuration change is the most common cause of sudden outages. If the trouble began right after you changed something, suspect the change first, no matter how dramatic the symptoms look.

    An upstream outage at your provider or one of its carriers produces the same packet loss and timeouts as an attack. Check your provider's status page before assuming the worst.

    What to do while it is happening

    Contact your hosting provider first. They can see what is arriving, confirm whether it is a flood, and tell you what options exist on their side.

    Resist the urge to keep restarting the server. If the connection is saturated, a restart changes nothing, and repeated restarts can corrupt state or make diagnosis harder.

    Be careful with your real IP address. If you move the service to a new address to escape an attack, avoid publishing that address anywhere public. The unprotected address behind a protection service is often called the origin, and attackers who learn it can aim at it directly and bypass filtering entirely.

    Finally, understand why filtering on the server itself cannot save you. Once a flood is large enough to fill your internet connection, the junk has already consumed your capacity by the time any firewall rule on your machine sees it. Filtering has to happen earlier along the path, inside a network with more capacity than the attack. For the full picture of upstream filtering, see the guide on how GRE tunnel DDoS protection works.

    Reducing the damage next time

    A flood can fill a connection in seconds, so protection that someone switches on after noticing an attack usually arrives after the damage is done. Always-on filtering, where traffic is inspected continuously instead of only after impact, removes that gap. Sterile Networks includes always-on Layer 3/4 mitigation with every plan; Layers 3 and 4 are the parts of network communication that handle addressing and connections, which is where most floods operate.

    Beyond that, preparation is mostly about knowing your options before you need them.

    • Know your normal. Keep basic traffic graphs, even simple ones. Spotting an attack takes minutes when you know what an ordinary Tuesday looks like, and far longer when you do not.
    • Game servers. Sterile's game server DDoS protection includes premade filter profiles for games such as Minecraft, Rust, and CS2 that you bind to your server's port.
    • Providers and operators with their own IP space. Network and ASN protection can cover whole ranges at once, with clean traffic delivered over GRE or BGP.

    If you suspect you are a target, or you have already been hit once, compare the available protection plans or contact the team to talk through your setup. Decide before the next incident; the middle of an attack is the worst time to start evaluating options.

    Related Posts