How BGP Anycast Scrubbing Works: Traffic Steering, Layered Filtering, and Origin Injection

Simply put, BGP Anycast scrubbing does three things:

1. Steering: The provider announces the same IP range via BGP from scrubbing nodes (PoPs) in multiple regions. Routers of various carriers follow BGP path selection rules to send traffic destined to that IP range to the nearest node on the network. Attack traffic is also distributed to each node instead of overwhelming a single data center.
2. Scrubbing: Each node filters traffic locally. Layers 3 and 4 handle volumetric attacks like SYN Flood and UDP Flood, while layer 7 handles HTTP Flood and CC attacks.
3. Re-injection: The remaining legitimate traffic is sent back to your origin via reverse proxy or tunnels such as GRE or IPsec.

Each step determines a specific class of issues: steering decides whether the total volume can be absorbed and how high user latency is; scrubbing decides how accurately attacks are blocked and whether false positives occur; re-injection decides whether the origin can be bypassed and how stable the backhaul link is. The following sections elaborate in this order and conclude with questions you can directly ask providers when selecting a service.

First, clarify: Anycast scrubbing is not the same as domestic "BGP high-defense"

When domestic data centers say "BGP high-defense," they usually mean an IP in a single data center that connects to multiple carriers like China Telecom, China Unicom, and China Mobile. It solves the problem of "smooth access for users on different carriers," and scrubbing is generally done within that one data center. BGP Anycast, on the other hand, places the same IP range on nodes in multiple regions and announces it simultaneously, focusing on distributing traffic and attacks across multiple locations.

Both use BGP, but their architectures differ, and so do the ways to evaluate defense capabilities. For trade-offs between multi-line BGP and single-line, refer to Which is stronger: BGP high-defense or single-line high-defense.

Step 1: Announcing the same IP range in multiple locations, traffic enters nearby

Normally, an IP prefix is announced to the public internet from only one location. Anycast has multiple nodes' routers announce the same prefix simultaneously. After routers of carriers worldwide see multiple reachable paths, they each select one based on BGP rules (e.g., shorter AS-Path preferred), so visitors in different regions land on different nodes.

Two points affect actual experience:

• "Nearest" refers to network topology proximity, not necessarily geographic proximity. Which node a user ultimately enters depends on their carrier's routing policy. The theoretically nearest node may not be the one the user actually lands on.
• For mainland China users, the landing point must be tested. The three major carriers have different routing policies for international routes. When accessing overseas Anycast nodes, traffic may detour to a farther node and latency may be noticeably higher. There is no one-size-fits-all conclusion; the most reliable way is to test from your main user locations per carrier. If your users are mainly in mainland China, refer to Hong Kong CN2 vs Hong Kong BGP for line selection.

Step 2: Attack traffic is distributed across multiple nodes

The problem with traditional single-point protection is that all attack traffic squeezes toward one data center. Once the uplink is saturated, even the strongest scrubbing equipment is useless because traffic cannot enter.

Anycast changes this. Since traffic from different regions enters different nodes based on proximity, distributed attack traffic is also split, and each node only bears a portion of the peak, making it harder to saturate a single link.

However, the distribution effect depends on the attack source distribution. The more distributed the attack sources, the more even the pressure on each node; if attack sources are concentrated in one region, that traffic will concentrate on the local node. So when evaluating capacity, besides total scrubbing capacity, you also need to know how much a single node can handle. For factors determining capacity limits and what happens when exceeded, refer to How much traffic can BGP high-defense mitigate.

Step 3: Layered scrubbing within each node

After traffic enters a node, it passes through an inline or diversion-based scrubbing system. Different attack layers are handled differently:

• Layers 3 and 4: Block volumetric attacks like SYN Flood and UDP Flood through protocol compliance checks, malformed packet filtering, SYN Proxy / SYN Cookie, and rate limiting.
• Layer 7: Block HTTP Flood and CC attacks through reverse proxy, WAF rules, client fingerprinting, and human verification.

Layer 7 scrubbing requires nodes to see HTTP request content, so for HTTPS services, nodes need to terminate TLS connections and certificates must be deployed on the nodes. If your main threat is CC, confirm whether the provider has layer 7 capabilities in the same node, not just volumetric scrubbing. For how much CC protection can block and when it can be overwhelmed, refer to Can high-defense CDN prevent CC attacks.

Step 4: Clean traffic is re-injected to the origin

After scrubbing, legitimate traffic must be sent back to the origin. There are two common re-injection methods:

• Reverse proxy mode (layer 4 or 7): Nodes terminate user connections and initiate new connections to the origin as themselves, backhauling via internal backbone or optimized links. The origin sees node IPs, and the real client IP must be passed via HTTP headers or proxy protocol; origin logs and risk control rules need adjustment. This is the most common method for websites, APIs, and gaming services.
• Network layer tunnel mode: Encapsulate original packets and forward them to the origin network via GRE, IPsec, or MPLS; the origin receives original packets. This method is common in enterprise networks with their own IP ranges.

Regardless of the method, the origin should only accept traffic from scrubbing nodes. Once the origin's real IP is leaked, attackers can bypass scrubbing and hit the origin directly, rendering the first three steps useless. For common leakage paths of origin IP and the order of closure, see Will origin IP still be exposed after high-defense CDN integration.

How it differs from traditional centralized scrubbing

Traditional scrubbing is usually on-demand: traffic goes directly to the origin normally, and only after an attack is detected does routing change to steer traffic to a few centralized scrubbing centers, then back. This has two costs:

• Detour latency: User traffic from one region may first detour to a distant scrubbing center and then back to the origin, potentially adding tens of milliseconds or more.
• Switchover risk: There is a window between attack detection and route convergence, during which services may be affected. Also, concentrating traffic to a few centers can itself create congestion points.

BGP Anycast scrubbing is typically always-on: traffic always passes through nodes, there is no switchover when an attack comes, and users always enter from nearby nodes. The trade-off is that all traffic passes through the provider's network long-term, so node line quality directly affects daily access experience.

Limitations to note: Route flapping may break long connections

BGP routes are computed independently by each autonomous system. When network jitter or route flapping occurs, subsequent packets from the same client may be sent to another node. If scrubbing or proxying is stateful and there is no session synchronization between nodes, the new node does not recognize the connection, and the TCP connection may break.

Short-lived web requests are less affected; they can reconnect after a break. But long-lived connections in gaming, WebSocket, and live streaming are more sensitive. If your business falls into this category, ask the provider how they handle cross-node session issues and specifically observe long connection drop rates during testing.

Turn principles into specific questions when selecting a provider

With the four steps above in mind, you can verify each item when evaluating an Anycast scrubbing service:

1. Which nodes will your users land on? Ask the provider for node distribution, then test landing points and latency from your main user regions per carrier; don't just look at the number of nodes.
2. What are the single-node capacity and total capacity? When attack sources are concentrated, single-node capacity is more critical.
3. Is it always-on or on-demand steering? For on-demand steering, ask how long the switchover takes.
4. Is layer 7 scrubbing on the same link? For businesses at risk of CC, confirm that WAF and human verification do not require separate integration.
5. Which re-injection method is used, and how is the origin hidden? Ask for the backhaul IP range to set up a whitelist at the origin.
6. How are long connections handled? Gaming and real-time services should focus on testing this.

If you are evaluating RockCloud, its acceleration and defense are completed on the same link, with one fee, billed by peak and unlimited traffic. You can directly ask the questions above, then use the free trial to test landing points, latency, and long connection performance from your user locations before making a decision.