Bot Traffic Moves: Build API Defenses That Follow Behavior

Blocking one source network can make a dashboard look safer while the automation simply moves. The operator changes cloud providers, the source IPs and autonomous system number (ASN) change, and the same request sequence resumes against the same API paths.

That pattern became visible in an October 2026 Cloudflare analysis of the Yandex network disruption. Cloudflare observed one targeted customer's matching bot traffic disappear from Yandex.Cloud and appear from other Russian hosting ASNs with the same JA4 TLS fingerprint, uncommon paths and headers, and custom user-agent strings. Across the described week, the relevant Russian bot traffic for that account remained roughly flat. This is one network's observation of specific traffic; it does not identify the operator or prove that every bot migrates.

The Hacker News discussion made the operational question timely: if hostile or unwanted automation can change infrastructure faster than a blocklist review, which controls should remain effective after the move?

Key Takeaways

• Use source IP and ASN as signals, not as durable identities.
• Authenticate valuable API operations and rate-limit by a trustworthy consumer or tenant identity where possible.
• Combine identity, route, method, request cost, concurrency, and behavior; no single fingerprint is permanent.
• Keep global abuse controls separate from per-replica counters and document degradation behavior.
• Measure allowed, challenged, rate-limited, and blocked traffic by policy reason, not only by source network.
• A gateway can enforce API policy, but upstream DDoS absorption, device reputation, and application fraud controls remain separate layers.

What the Yandex Event Actually Showed

Cloudflare separated two Yandex networks with different traffic profiles. The Yandex Search ASN primarily carried verified search crawlers. Yandex.Cloud carried third-party workloads and a different mix of automation. During the disruption, requests from both networks fell, but their meaning was not the same.

For one gambling customer, Cloudflare saw identical request behavior move from Yandex.Cloud to Radist and Selectel. The evidence was not merely “traffic increased elsewhere.” It included the same TLS client fingerprint, unusual paths and headers, and custom user-agent strings. That correlation made workload migration a stronger explanation than unrelated traffic.

Two cautions belong next to that conclusion:

1. A source network does not prove who operates a request. Cloud platforms host many unrelated tenants.
2. A fingerprint describes observed behavior at a point in time. A capable client can change its TLS stack, headers, timing, and hosting provider.

An API defense should therefore use source attributes as part of a decision, not equate them with identity.

Build Controls That Survive an IP Change

The most durable control is a principal or credential the API can validate and bind to a consumer or tenant. For an authenticated API, that may be a validated access token, service identity, consumer credential, or tenant key. Rate limits and authorization can then follow the caller across networks.

That identity is only as strong as its verification and lifecycle. A raw header such as X-Tenant-ID is caller-controlled unless a trusted authentication layer binds it to a verified principal. A leaked API key lets automation carry the same identity to a new provider. Pair the identifier with expiration, rotation, revocation, scope, and anomaly detection.

For public or anonymous endpoints, combine weaker signals:

Signal	Useful for	Limitation
Source IP or ASN	Burst control and emergency containment	Shared, rotating, proxied, or easy to move
Authenticated consumer	Quotas and attribution	Credential theft or sharing changes the actor behind it
Route and method	Protecting expensive operations	Does not distinguish callers on the same operation
Request shape	Detecting scanners and repeated abuse sequences	Legitimate clients can share shapes; bots can mutate them
TLS or client fingerprint	Correlating toolchains across networks	Can change and may group unrelated clients
Concurrency and cost	Protecting capacity	Needs a defensible cost model and safe thresholds

The goal is not a magical bot score. It is a policy whose important limits still hold when one signal changes.

Rate-Limit by the Resource You Need to Protect

A request-per-second limit is useful when request cost is reasonably uniform. Many APIs are not uniform. A cached GET and a report export may consume very different database, CPU, and bandwidth capacity. Login attempts, search queries, uploads, and bulk writes also need different windows and keys.

Design limits around the protected resource:

• per verified consumer for contractual quotas;
• per tenant and route for shared-credential applications;
• per IP for unauthenticated bursts, with proxy trust configured correctly;
• per operation for expensive endpoints;
• concurrency limits for long-running requests;
• a global safety ceiling for origin capacity.

Apache APISIX provides request-rate, count, and concurrency controls. Its current limit-count documentation supports variable and variable-combination keys. This article references Apache APISIX 3.19 documentation available on October 20, 2026; confirm behavior in your deployed release.

Do not compose a limit key from an unverified header and call it tenant-aware. Authenticate first, or explicitly treat the value as a weak partition that an attacker can change.

Understand Local and Shared Counter Boundaries

Distributed gateways introduce another scope problem. With the default local policy documented for APISIX limit-count, each gateway instance maintains its own counters. If traffic reaches several instances, the effective aggregate allowance is approximately the configured limit multiplied by the number of instances.

That may be acceptable for coarse load shedding. It is usually wrong for a contractual tenant quota that must apply across the fleet. APISIX also documents Redis-backed policies for shared counters. The trade-off is a runtime dependency: latency, availability, synchronization, and failure behavior now affect enforcement.

Write the intended semantics next to the configuration:

• Is the limit per instance or fleet-wide?
• What happens when the shared counter store is slow or unavailable?
• Is temporary over-admission acceptable?
• Which status and Retry-After behavior does the client receive?
• Can an operator disable or bypass the rule, and is that action audited?

The HTTP specification defines 429 Too Many Requests and permits a Retry-After header. A gateway may be configured to return another status, so test the actual route rather than assuming the default communicates the policy you intended.

Use Behavior for Detection, Identity for Enforcement

Behavioral signals help discover that traffic moved. Identity and resource controls decide what it is allowed to do.

Suppose an API sees a sequence of requests for rarely used administration paths. After one ASN is blocked, the same sequence returns from several providers. A useful response is not an endless list of ASNs. It is to verify that administrative routes require authentication, reduce anonymous reachability, rate-limit repeated failures, and alert on the sequence across source changes.

At the gateway, record the smallest useful evidence:

• verified consumer or anonymous classification;
• route and method;
• status and policy outcome;
• rate-limit key category, without logging the secret itself;
• source network and trusted proxy chain;
• request-size and latency bands;
• bounded behavioral or fingerprint labels;
• origin outcome and gateway-generated outcome separately.

Avoid logging full credentials, request bodies, or personal data merely to improve correlation. The API gateway logging best practices apply here: evidence should support response without creating a second sensitive-data store.

Separate Gateway Policy from the Other Defense Layers

An API gateway is well placed to authenticate, authorize, apply route-aware limits, normalize selected requests, and produce consistent decision telemetry. It is not every part of bot defense.

Volumetric attacks may need upstream network or DDoS protection before traffic reaches the gateway. Browser automation may need challenge, device, or session signals. Credential stuffing requires identity-provider and account-risk controls. Business abuse—such as inventory hoarding or promotion fraud—needs application context the gateway may not have.

The OWASP API Security Top 10 calls out unrestricted resource consumption and sensitive business flows as distinct risks. Treat them that way. One capacity limit should not stand in for transaction authorization, and a WAF rule should not stand in for account recovery controls.

For scraping-specific patterns, use the narrower guidance in How to Protect Your APIs from Scrapers. The lesson from migrating traffic is to make those controls portable across source changes.

Test the Migration Counterexample

Before rollout, run a small adversarial test:

1. Send the same allowed and denied request sequences from two source networks.
2. Rotate the source IP while keeping a valid consumer credential.
3. Keep the source fixed while changing the credential.
4. Remove the shared counter backend in a test environment.
5. Send an expensive operation below the simple request-rate threshold.
6. Confirm which layer blocks, which status the caller sees, and which evidence operators receive.

The counterexample is the real gate: if changing an IP resets every meaningful control, the design still depends on location rather than caller or cost. If losing Redis silently removes a fleet-wide quota, the failure policy is incomplete. If the rule blocks legitimate crawler or integration traffic without an exception process, it is not operationally ready.

Conclusion

Bot infrastructure is replaceable. Durable API defenses therefore need to follow verified identity, protected resources, and repeated behavior—not a single IP range or ASN.

Use network blocks for tactical containment, then move the lasting policy to the gateway boundary: authenticate valuable operations, scope limits to the right identity and route, make distributed-counter behavior explicit, and preserve evidence that correlates a workload across source changes. Apache APISIX and API7 Gateway can provide that policy and observation point, while DDoS, identity, fraud, and application teams keep ownership of the layers the gateway cannot replace.