GcoreGlobal Network

Gcore TrafficGate gives Gcore CDN customers visibility into unwanted traffic and controls for bots, request sources, and L7 surges.Imagine a website facing an application-layer (L7) DDoS attack, a flood of web requests intended to overwhelm the service. In this example, the CDN absorbs part of the attack traffic at the edge, the website’s backend servers (its origin) stay available, and users notice no disruption. Technically, the protection worked. But without TrafficGate, the attack traffic handled by the CDN still counts toward CDN usage and is billed to the customer, leaving them paying for traffic they never wanted to serve.This is one version of a broader problem. An AI crawler can work through thousands of pages, a scraper can collect an entire product catalogue and its prices, and a legitimate client can call a compute-intensive API too frequently. A sudden influx of real users during a launch or live broadcast can put the origin under similar pressure.Individually, these requests may look completely normal. Collectively, they compete for bandwidth, compute resources, and budget. The question for modern web traffic is increasingly whether you want to serve it, under what conditions, and at what volume. TrafficGate gives Gcore CDN customers the visibility and controls to make those decisions at the edge.All screenshots below show demo data.Surge Control shows detected and prevented attacks alongside the requests that passed.Why this gap persistedA CDN delivers content quickly and reliably, while basic rules can restrict access by IP address, geography, or User-Agent, a request header that identifies the browser or other software making the request. For many use cases, those controls are enough.The problem becomes harder when traffic changes. Sources move, bots rotate addresses or use browser automation, and demand concentrates on specific URLs and API methods. A static blocklist quickly becomes outdated. A single rate limit, which controls how frequently requests are allowed, may fail to contain unwanted traffic or interfere with legitimate users when applied across an entire application.Rate limiting can be handled at the origin or API gateway, where the application has more context about each request. But by then, the request has already reached the infrastructure and started consuming resources. A full Web Application and API Protection (WAAP) platform offers another approach, protecting applications and APIs against security threats that exploit vulnerabilities in their software.There is an organisational reason this gap has persisted, too. CDN operations usually belong to DevOps, Platform, or SRE teams, while application security has a different owner and budget. DevOps needs origin headroom and traffic control, but may not need the broader security and investigation capabilities of a full WAAP deployment. The security team, meanwhile, is assessing application risk rather than CDN operating costs.Teams can end up maintaining IP lists, origin rate limits, and one-off scripts without a single place to understand and control unwanted traffic at the edge. TrafficGate brings those decisions into the CDN delivery path.First understand what is creating the loadTraffic Intelligence brings together information about requests, sources, bots, errors, and changes in demand. It helps you distinguish audience growth from crawler activity, identify an endpoint under pressure, and see which sources have changed the normal traffic profile.That information can guide policies before the next surge. An API provider, for example, may need a request threshold for an expensive search operation. Understanding which clients generate the most traffic, when requests increase, and which endpoints are affected helps establish an appropriate policy.Traffic Intelligence also provides a way to measure the effect of a policy. You can identify a change in traffic, find its source, apply a response through Traffic Policies, and see how the request patterns change.Traffic Intelligence brings audience traffic, AI agents, bots and crawlers, and errors into one timeline.Bots need different policiesAutomated traffic can create value. Search crawlers help people discover a website, preview bots generate link previews on social platforms, and monitoring services check availability. An AI agent may also retrieve a page in direct response to a user's request.Other automation collects content at scale, works through product catalogues, or creates unwanted load. A publisher may value search indexing but want to limit AI crawlers collecting large amounts of its content. An online shop may be more concerned about scrapers repeatedly extracting product listings and prices.Applying the same policy to every bot can disrupt useful services or leave businesses with little control over how their content and resources are used.TrafficGate Bot Control uses known-bot identification and behavioural signals to distinguish between types of automation. You can choose how different traffic should be handled: allow it, rate-limit it, require additional validation, or block it.Bot Control groups known bots by category so different types of automation can receive different policies.The decision depends on source, target, and intensityAn IP address or country can be a useful signal, but rarely tells the whole story. An address may belong to shared infrastructure, a source may use a proxy or hosting network, and a legitimate integration may generate unusually high request volumes.TrafficGate Access Control filters requests using IP addresses, geography, and source-reputation categories, which provide signals about how trustworthy a request’s source may be. Traffic Policies adds more context, including the URL, path, HTTP method, headers, and request rate.These controls allow policies to address specific situations. You could restrict an administrative area to trusted networks or rate-limit a compute-intensive search or export endpoint. An ecommerce business could apply a policy to scraper traffic collecting product information while preserving an exception for a trusted partner integration.You can also observe matches for a new rule before enabling enforcement, helping identify unexpected effects on legitimate traffic.Traffic Policies combines request conditions and actions so rules can be applied to specific traffic scenarios.Sudden demand hits the origin like an attackA product launch, sports broadcast, sale, or widely shared article can change the normal traffic profile within minutes. From the origin's perspective, the symptoms can resemble an attack: latency rises, workers and connections become exhausted, and errors begin to appear.The resources required to handle each request also vary. A static page, a search across a large catalogue, and a complex API call place very different demands on an application. A single domain-wide rate limit cannot reflect those differences.Surge Control contains application-layer (L7) DDoS traffic and sudden HTTP request spikes at the edge. Traffic Policies adds controls that reflect the specific target and the application's capacity, helping preserve resources for legitimate users and critical operations.Pay for clean requestsTrafficGate uses clean-request billing. Requests filtered as L7 DDoS, malicious automation, traffic from prohibited sources, or other unwanted activity are not billed.TrafficGate and WAAP solve different problemsTrafficGate focuses on understanding and controlling traffic: who or what is generating requests, whether the business wants to serve them, and how much the service can accept.Gcore WAAP addresses the broader application-security problem. It protects applications and APIs against attacks targeting vulnerabilities, including OWASP Top 10 threats. When the primary risk involves SQL injection, cross-site scripting (XSS), API vulnerabilities, virtual patching, or other threats to application logic, WAAP provides the appropriate security capabilities.Gcore CDN handles delivery, TrafficGate adds controls over the traffic using that delivery path, and WAAP protects applications and APIs against a wider range of security threats. Customers can expand their application-security capabilities as their requirements change.Start with one problem on real trafficTrafficGate is built for DevOps, Platform, and SRE teams using Gcore CDN to run public services with high or unpredictable HTTP request volumes.The requirements vary across industries. Media and publishing platforms may need policies for AI crawlers and content scraping. Gaming services can face sharp traffic increases during launches, while ecommerce businesses may need to manage automated price collection and pressure on checkout operations. SaaS and API platforms often need more precise limits for particular clients or expensive operations.TrafficGate is available to Gcore CDN customers. Start with one measurable problem, such as an L7 surge, bot traffic, scraping, or an overloaded endpoint.Establish a baseline, validate exceptions for legitimate traffic, and measure the outcome on your own workload before expanding the policy.Request a TrafficGate pilot →

Real streaming problems rarely show up with a label on them. The broadcaster's ops team is fielding complaints. A dashboard glows with elevated stall counts. Meanwhile the CDN logs look perfectly healthy — latency is nominal, cache hits are high, nothing's on fire. And the picture still stalls for people at home.That was the setup for one of the more satisfying investigations we've run: a 24/7 channel for a major national broadcaster, with a two-hour DVR window, streamed to millions of viewers. Broadcast-grade — where tolerances are brutal and the margin for error is milliseconds. We found the real problems across four layers and tuned them out one by one, with QoE ground truth from the team at AVEQ and their Surfmeter probes.The one-line version: Some stalls were real. Some were the measurement lying to us. The most interesting one was a timing race no dashboard was built to see. Fixing all three is what broadcast-grade actually means.QoS and QoE are not the sameThe terms Quality of Service and Quality of Experience get used interchangeably all the time — which is exactly how you end up staring at a green dashboard while viewers rage-quit. They measure different universes.QoS is the network's story: latency, packet loss, TCP retransmissions, cache hits, response codes. It's objective, it lives in your logs, and — the trap — it's largely independent of what any one person sees on screen.QoE is the viewer's story: does it stall, does it drop to a blurry rendition, how long to first frame. It's measured at the player, not in the pipe. A stream can post gorgeous QoS numbers and still be a miserable watch. Closing that gap is the whole game.In terms of QoE and what users notice, we treat a video freeze of 100 ms or longer as a stall. Anything below that will likely not be perceivable, per AVEQ's research.What "something's wrong" looked likeWhen Gcore was notified of the problem, we collected a list of specific issues:Viewers were seeing visible quality drops and frequent rendition switches mid-playback.Stall counts were running higher than the best-in-class CDNs carrying the same stream under the same conditions.Mean Opinion Score (the viewer quality score, via AVEQ) sliding from a healthy 4.5 to 3.4.One ISP was performing consistently worse than the rest of the pool.The broadcast bar is fewer than five stall events per 24 hours. We were well over it. So — one layer at a time.You can't fix what you can't see truthfullyNo single vantage point tells the truth on its own, so we triangulated with three:AVEQ Surfmeter — a client-side QoE app, deployed in several spots, including a probe wired straight to the underperforming ISP. It gave viewer-side metrics — stall counts and stalling time, down-switches, bitrate behavior, MOS — sliced by ISP and player build. CDN logs can't reproduce that.Gcore HAS Probe — our in-house HLS/DASH emulator. It behaves like a player but logs everything: TTFB, time-to-first-frame, manifest and segment timing, and manifest parse errors. It catches what a player hits, but a CDN log shrugs off.CMCD + raw CDN logs — client data emitted by the players, lined up against edge logs so we could tie an infrastructure event to the exact viewer-side impact it caused.Giving the busiest path room to breatheThe first finding was in the network. One ISP path caused more degradations than the rest of the pool, and unevenly. At peak, its TCP retransmissions climbed higher than we like. That bites: adaptive streaming has a tight download window, so even a small bump lowers the buffer margin that prevents stalls.The cause was simple capacity distribution: at peak, that path wanted rebalancing across facilities. We redistributed the load, opened headroom on the busiest transit, and let routing settle. Retransmissions tightened to 0.3% — a tenfold improvement — and manifest and segment timing sharpened with it. One QoS number is easy to misfile as a viewer metric: mean delivery duration — server-side processing time, read straight from raw logs, with no client round trip in it. It landed at 23.1 ms, inside the 30 ms target.When the measurement is the bugHere's where it got fun: some of the stalls we were chasing weren't noticeable.Micro-stalls: ghosts in the counter. Running Surfmeter against individual quality profiles, we saw "stall" durations absurdly short — well under the 100 ms bar. These micro-stalls were padding both our counts and the broadcaster's reference stats. To help focus on what matters, AVEQ configured Surfmeter to ignore any stalling below 100 ms, we recomputed every affected test, and the baseline dropped.Player bugs wearing an infrastructure costume. By working together with the broadcaster, we had access to several player versions, including historical ones. Older builds of the broadcaster's reference player were generating false-positive stalls of their own. With AVEQ's data and our CDN log analysis, the player team pinned the trigger. Two releases solved most of the issues — the first alone cut stalls by about 20%.Your player and your measurement tools are part of the quality stack, not neutral observers of it. A CDN investigation that never looks at the player will misattribute problems all day.Because Surfmeter watched the whole multi-CDN setup at once — the same stream through Gcore and the other CDNs, across every player build — we could slice stalling by build and by CDN, separating a player quirk from real CDN behavior instead of guessing. Before the fix, spikes were everywhere, competitors included. After it, Gcore significantly improved its metrics, dropped into the low, flat band and stayed there on every build, while some CDNs kept spiking.A race condition nobody's dashboard could seeThe most interesting find came from HAS Probe's manifest timing — the kind of bug no health dashboard shows.In the broadcaster's case, the stream uses 2-second segments and a big manifest: a two-hour DVR window runs to about 500 KB. Stack a few caching layers in front of that and a timing race appears. The window is tiny — it only opens when a player asks for the manifest a tiny bit before the segment boundary. But across millions of viewers, tiny becomes a steady drip of stalls. Our CDN logs showed manifest-update errors landing exactly on the stalls Surfmeter measured — theory into root cause.The fix: sub-second freshness, no origin changes required. There were two ways out. The clean, structural one is counterintuitive: lengthen the segments, from 2s to 4s — that gives the cache more headroom against the player's polling and makes a stale manifest far less likely. We proposed it, but the origin is shared by every CDN in the pool and running in production, so a segment-length change wasn't something the broadcaster would make for one provider. Fair enough.So, we solved it entirely on our own side, with a Gcore feature we built and proved on this workload: sub-second caching, which revalidates the manifest toward origin at sub-second granularity so the edge always has the freshest segment — no origin changes needed. We validated it on a test resource and can switch it on for the main channels on request. We also resized the shield's hot cache, so the full two-hour DVR window stays warm.What this case teachesA few things that generalize to anyone running live at scale:QoS and QoE need separate instruments. Infra metrics won't surface player bugs, measurement artefacts, or manifest races. You need the player's-eye view.A specialist measurement partner pays off. AVEQ's ISP- and build-segmented data was the difference between guessing and knowing.Manifests are an underrated quality lever. Cache TTL, segment length, and polling interval interact in ways standard dashboards never show.Broadcast-grade quality isn't one well-configured box. It's every layer, tuned together — and proven with measurement you can trust.Live streaming, built for broadcast scaleGcore delivers low-latency live to millions of concurrent viewers, with proactive CMCD monitoring, sub-second caching, and a team that treats "the numbers look fine" as the start of the investigation, not the end.Ground truth from AVEQ SurfmeterAVEQ's Surfmeter measures Quality of Experience from the viewer's side — stall counts, quality switches, bitrate behavior, and MOS, segmented by ISP and player build. It's the layer that told us which stalls were real. Highly recommended for any serious streaming operation.Get in touch to learn more.

Gcore has been recognized as one of the top 100 fastest-growing technology startups in France and Benelux by Sifted — one of Europe's leading tech publications. Our inclusion in the B2B SaaS & Cloud Infrastructure category points to rising demand for sovereign, high-performance European cloud infrastructure, something our edge distribution platform is built to help address.What the Sifted 100 ranking meansThe Sifted 100 is one of Europe's most rigorous startup rankings. Compiled by a team of journalists and analysts at Sifted, it identifies companies combining strong revenue growth, market relevance, and strategic momentum across the France and Benelux region.Ranking 89th out of 100 shortlisted companies, Gcore joins the list as a new entrant. The recognition spans the B2B SaaS & Cloud Infrastructure category, where competition is defined by technical depth, global reach, and the ability to serve enterprise customers at scale.Why edge distribution is winning: the platform Gcore builtThe cloud market is consolidating around a fundamental truth: proximity to end users and data sources matters. Latency, data sovereignty, and resilience cannot be solved by centralized hyperscaler regions alone. Gcore's edge distribution platform is built on this premise — and the Sifted 100 inclusion confirms that market demand has caught up.The Gcore platform spans four interconnected capability areas:Global Edge NetworkDDoS Protection at ScaleFastEdgeAI Cloud Stack and Everywhere InferenceAligned with the market. Built for what's next.The Sifted 100 recognition is significant not as an end point, but as external validation of the direction we have been building toward. Enterprise cloud infrastructure is shifting from centralized, legacy models to distributed, edge-first architectures. AI workloads demand low-latency inference at the point of consumption. Security threats are growing faster than perimeter-based defenses can absorb them.Gcore's platform is built to address each of these vectors simultaneously — through a single infrastructure partner with global scale and European roots.Explore Gcore's Edge Cloud platformWhether you're looking to reduce latency at the edge, protect mission-critical applications from DDoS attacks, or deploy AI inference closer to your users, the Gcore platform is built for the workloads enterprises are running today — and the ones they're preparing for tomorrow. Get in touch to learn more.