Edgegap’s DDoS solution: Protecting the gaming industry from crippling attacks
In short: Edgegap handles DDoS attacks on game servers automatically, with no extra configuration from the studio. It detects common floods early, steers new matches away from the targeted machine, filters attack traffic at the edge so running matches can finish, then recycles the server's IP so the attacker loses the target.
Detection: Edgegap watches connection rates to catch TCP SYN floods, UDP floods and HTTP floods early.
Isolation: a machine under attack is declared "Under DoS", and new deployments are steered away from that site.
Mitigation: upstream scrubbing and edge firewall rules, including a null route for suspicious traffic, limit the impact on matches already running.
Recovery: once those matches end, the site's IP address is recycled, and new matches get a fresh, randomly assigned IP address and port.
A denial-of-service attack floods a server with traffic until legitimate players' packets can't get through, or arrive too late to matter. For a multiplayer game, that means lag spikes, disconnects and matches that can't be finished. Outages like these hurt player trust and the studio's reputation, whatever the attacker's motive.
Edgegap's approach, as described in its DDoS protection documentation, is to bring protection "to the edge instance infrastructure" and handle attacks automatically, with no extra configuration from the studio.
This page was first published in 2022. The mechanism has changed since then, and this version reflects the current documentation.
Step 1: Detect the Attack Early
The system looks for the common flood types used against game servers:
TCP SYN floods, which open connection requests faster than a server can handle them.
UDP floods, which matter most for games, since most real-time netcode runs over UDP.
HTTP floods, aimed at any web-facing endpoint.
Detection is based on three connection metrics: Port Connection Rate, Source Connection Rate and Total Connection Rate. A sudden spike in any of them is the signal.
Step 2: Isolate the Targeted Machine
Once an attack is detected, the machine is declared "Under DoS". Edgegap then steers new deployments away from the targeted site.
New matches don't land on a machine that's being flooded. They start somewhere else.
Step 3: Mitigate Traffic at the Edge
Matches already running on the targeted site still need to finish. To reduce the impact on them, Edgegap performs upstream scrubbing and injects routing and firewall policies locally at the edge, including a null route redirect for suspicious incoming traffic.
Because the filtering happens at the edge, the documentation notes that wasted upstream bandwidth from the server stays minimal. The game server spends its resources on players, not on junk packets.
Step 4: Recover With a Fresh IP Address
Attackers need a target. Once players on the targeted site finish their match and disconnect, Edgegap recycles that site's IP address so later matches can't be hit by the same attacker.
New matches then use a fresh server IP address and port, assigned randomly. An address an attacker collected from one match doesn't point to the next one.
Questions about a specific setup can go to Edgegap's Community Discord, as the documentation suggests.
Written by
Philip Coté (CTO)
