How Gcore DDoS Protection Works
Gcore provides DDoS protection via an anycast scrubbing architecture. Attack traffic is routed through Gcore's distributed network of Points of Presence (PoPs), filtered at the scrubbing layer, and clean traffic is forwarded to the operator's origin infrastructure via GRE tunnels or direct routing.
For network operators with BGP AS ownership, Gcore can announce your IP prefixes (typically /24 or larger) and absorb volumetric attacks at the network edge before they reach your upstream transit. For game server and hosting operators without a BGP AS, Gcore offers proxy-based or tunnel-based protection where traffic is redirected using DNS changes or GRE configuration.
Gcore operates 160+ PoPs globally[1], with scrubbing capacity concentrated in major internet exchange points. The global footprint is a genuine advantage for volumetric attack absorption.
BGP Requirements — What They Mean for Game Hosting
The difference between Gcore's network-level and proxy-level protection matters significantly for game hosting operators:
Network-level protection (BGP)
If you own a BGP Autonomous System (ASN) and IP prefix (/24 minimum in most configurations), Gcore can announce that prefix and divert attack traffic upstream before it reaches your servers. This is the architecture used by large hosting providers and ISPs with their own address space.
Operators leasing IPs from their upstream provider — the common situation for small-to-medium game hosting companies — do not own the BGP prefix themselves. Network-level Gcore protection is not directly available to them without coordination through their upstream provider.
Proxy/GRE protection
For operators without BGP AS ownership, Gcore offers application proxy or GRE tunnel configurations. Traffic is redirected to Gcore via DNS changes or GRE encapsulation, filtered, and forwarded clean. This does not require BGP AS ownership but introduces the full proxy model: all player traffic transits Gcore's infrastructure on every connection, not only during attacks.
The Scrubbing Layer — Where Visibility Ends
Gcore's protection operates at the network and transport layer of your infrastructure. What this means in practice:
No per-server host visibility
Gcore scrubs traffic at the network edge. It has no visibility into what is happening on your individual game server nodes — packet rates received at the host, CPU pressure during attack, connection table exhaustion, or server-side application behavior. A 50 Gbps attack may be fully absorbed by Gcore's scrubbing infrastructure while your game server simultaneously crashes from a separate low-volume L7 application attack — Gcore would have no view of the second event.
No PCAP forensics at the origin
Post-incident forensic analysis at the packet level requires capture infrastructure on your origin servers. Gcore provides scrubbing telemetry for what was observed at their edge; what reached your origin after scrubbing is not captured or retained by Gcore's platform.
Detection-to-mitigation window
Flow-based scrubbing services including Gcore detect volumetric attacks via traffic anomaly analysis. During the window between attack onset and detection triggering, attack traffic transits to your origin. For short-burst attacks — common in game server targeting — this window can be long enough to cause meaningful disruption before mitigation engages.
Latency Overhead in Proxy Mode
In proxy or GRE tunnel configurations, every player connection routes through Gcore's scrubbing infrastructure even when no attack is in progress. For players located near a Gcore PoP, the additional hop is small. For players in regions underserved by Gcore's network, the routing overhead is measurable in game latency.
Game servers are latency-sensitive workloads. Minecraft, FiveM, and other real-time game servers are affected by even modest increases in round-trip time. Operators should test latency from their player population's geographic distribution to Gcore's PoP coverage before committing to a proxy configuration.
Gcore DDoS vs. Flowtriq
| Feature | Gcore DDoS Protection | Flowtriq |
|---|---|---|
| Architecture | Anycast scrubbing / proxy | Per-server host agent |
| BGP AS required | For network-level protection | No |
| Traffic rerouting | Yes (always-on for proxy config) | No |
| Per-server visibility | No | Yes |
| PCAP forensics | No | Yes |
| Sub-second detection | No (flow-based) | Yes (per-packet) |
| Server-side metrics | No | Yes |
| Latency impact | Yes (proxy routing overhead) | None |
| Origin IP protection | Yes (proxy hides origin) | No (direct IP) |
| Pricing model | Bandwidth-based / custom | $9.99/node/month |
The two models address different parts of the problem. Gcore absorbs volumetric attack traffic upstream before it saturates your transit links. Flowtriq provides visibility and detection at the individual server level — useful for attacks that reach the origin after scrubbing, low-volume application-layer attacks, and post-incident forensics. Many operators use both in combination.
Need visibility at the server level, not just the scrubbing layer?
Flowtriq runs directly on your Linux game server. Per-packet detection, PCAP forensics, server-side metrics. No BGP AS required — deploys in minutes.
Start free 7-day trial →Evaluation Checklist Before Procurement
- Confirm whether you own a BGP AS and IP prefix — this determines which Gcore protection tier applies to you
- For proxy configurations, test latency from your player base to Gcore's nearest PoP before deploying
- Identify your game protocol — Gcore's protection is strongest for L3/L4 volumetric; verify L7 game protocol support for your specific game
- Document your origin IP exposure hygiene — in proxy mode, IP leakage routes attacks around Gcore entirely
- Assess your forensic requirements — if post-incident packet-level analysis matters, plan for a complementary host-based tool
- Evaluate total pricing including clean bandwidth, burst pricing, and GRE tunnel configuration costs
Frequently Asked Questions
What is Gcore DDoS protection?
Gcore DDoS protection is an anycast-based scrubbing service that routes attack traffic through Gcore's global network of PoPs for filtering before delivering clean traffic to the customer. It is available as a network-level service (requiring BGP AS ownership) or as a proxy-based service for game servers and websites.
Does Gcore DDoS protection require a BGP AS?
For network-level IP prefix protection (where Gcore announces your /24 or larger prefix via BGP), you need to own a BGP AS and IP address block. For application-level or proxy-based game server protection, a BGP AS is not required — traffic is routed via DNS or GRE tunnels instead.
What does Gcore DDoS protection not cover?
Gcore protects at the network and scrubbing layer. It does not provide per-server host-level visibility, PCAP forensics on individual game server nodes, or server-side metrics. Attack traffic that bypasses or saturates the scrubbing layer, or attacks targeting the origin after IP leakage, require additional host-based detection.
Does Gcore add latency to game server traffic?
Yes. In a scrubbing or proxy architecture, all player traffic routes through Gcore's infrastructure before reaching your origin server. For players located near Gcore PoPs, the additional hop is minimal. For players in regions without nearby PoPs, the routing overhead can measurably affect game latency.
What is an alternative to Gcore DDoS protection for game servers?
Game server and hosting operators who need per-server packet visibility, PCAP forensics, sub-second detection, or host-level metrics alongside network-layer scrubbing often evaluate Flowtriq. Flowtriq runs as an agent directly on the Linux server node and does not require BGP AS ownership or traffic rerouting to operate.
Back to Blog