Network Protection: DDoS Mitigation and Server Shielding
Network-level DDoS mitigation through our infrastructure provider, per-server firewall rules, and platform-assigned ports keep your server protected.
What the platform does today
Every server is given its own block of 100 ports on the host it runs on, taken from the 28000-39000 range. Two servers on this platform never share a port, and you cannot change your ports — they are assigned by the platform and written into the game’s own configuration for you.
The host firewall is opened for exactly the ports your game needs from the internet and nothing else. A Windrose server on port base 28100, for example, gets internet-facing inbound rules for 28100 (game, TCP and UDP) and 28101 (query, UDP) — while its RCON port and, if you turn Windrose Plus on, its dashboard port are opened only to the machine itself, so neither is reachable from the internet at all. Everything the platform uses between hosts runs over a private mesh network rather than the public internet.
The address your players use is the host’s own public IP and your allocated port — the Server Address row in the Connection Info panel on the Overview tab is the authoritative copy of it. There is no proxy or hostname in front of game traffic: your players connect to the machine directly.
Network-level DDoS mitigation is included on every GameGrid server through our infrastructure provider, at no extra cost. Protection is always on and requires no configuration. Volumetric attacks targeting your server are filtered at the network layer before they reach the game process.
The Customer API and the website apply their own request-rate limits, published at GET /api/public/v1/meta/rate-limits: eight tiers from 600 requests a minute for live status polling down to 10 a minute for uploads and streams, plus a per-server limit of 10 control actions a minute. Those limits protect the control plane. They do not sit in front of your game server’s UDP or TCP traffic.
What the platform does NOT do
Support cannot apply per-customer traffic filtering rules on request. There is no tooling for it, so a ticket asking for one cannot be actioned.
If your game server is the target of an attack large enough to overwhelm the infrastructure-level mitigation, the practical effects are the ones you would expect on any host: packet loss, latency and, at enough volume, the server becoming unreachable until the traffic stops.
If you think your server is being attacked
Check the badge in the status bar at the top of the server panel first. A server that is still "Online" with a normal player count is more likely suffering a routing or ISP problem between your players and the host than an attack on the host.
The Resource Usage card on the Overview tab shows your own game process’s network in and out, refreshed every 10 seconds. A sustained inbound figure far above what your player count would explain is the signal worth reporting.
Ask an affected player to run a WinMTR report — see How to Create a WinMTR Report — because that distinguishes loss on the path from loss at the destination.
Then open a support ticket with your Service ID (bottom of the Connection Info panel), the times it started and stopped, the Net In figures you saw, and the WinMTR export. Our team can look at the host’s own counters and tell you what reached it. Be aware of what that ticket can and cannot achieve: we can confirm what happened and move your server if the host itself is the problem, but we cannot filter the traffic for you.
What you can do yourself
Understand that your server’s address IS the host’s public IP, and that there is no way to hide it from the people you invite. Anyone you give the address to knows the machine. Network-level DDoS mitigation filters volumetric attacks, but it cannot hide the IP from people who already have it.
Set a server password, or use your game’s whitelist where it has one, on the Settings tab under Player Management. That does not stop packets arriving, but it stops the far more common problem of unwanted players joining.
Take backups before anything you would not want to repeat. An attack cannot corrupt a backup that is already in off-site storage — see How Backups Work.