Quick Summary: Unexpected surges of Russian traffic via ad networks like Liftoff Mobile can wreck your KPIs and server costs; here is my battle-tested guide to blocking, filtering, and mitigating the noise.

When Ad Traffic Goes Rogue: Handling Unexpected Russian Geos

I still remember the first time I saw a geo-distribution chart that looked completely wrong. It was 3:45 AM, my phone was buzzing off the nightstand, and PagerDuty was screaming that prod-api-04 was hitting 95% CPU usage. I groggily opened my laptop, expecting a DDoS attack. Instead, I saw a massive, sustained green wall of traffic on Grafana. The source? Russia. The problem? Our app was strictly launched in North America and the UK.

We were running a user acquisition campaign with a mobile partner—similar to the issues folks are seeing with Liftoff Mobile recently. We weren’t under attack by hackers; we were under attack by “cheap inventory.” When you work in DevOps, you learn quickly that marketing budgets can sometimes translate directly into infrastructure pain. If you’ve noticed a sudden influx of RU traffic while running Liftoff or similar ad networks, you aren’t crazy, and you aren’t alone.

The “Why”: It’s Not Always Bots (But It Usually Is)

Before we start writing firewall rules, let’s understand the root cause. When your marketing team sets up a campaign, ad networks optimize for “installs” or “events.” Sometimes, ad networks fill quotas by buying “remnant inventory” (leftover ad slots) from partner networks that aren’t as strict about geo-fencing as the primary provider claims to be.

In the case of the Russian traffic spikes discuss in the community, the traffic often passes the basic checks but fails the logic test. These users (or scripts) might be firing the /install endpoint, but their retention is zero. This does three things:

• Dilutes Analytics: Your conversion rates plummet because the denominator (total traffic) explodes.
• Increases Latency: Your US-East servers are now handling requests with massive round-trip times.
• Burns Cash: You are paying for egress bandwidth and compute cycles on users who will never pay you a dime.

Pro Tip: Always cross-reference your traffic spikes with the marketing calendar. If the spike correlates with a new “Performance Max” or “Global” campaign launch, talk to your CMO before you wake up the CISO.

Solution 1: The Quick Fix (WAF Geo-Blocking)

If you are using Cloudflare, AWS WAF, or Azure Front Door, this is your first line of defense. This is the “stop the bleeding” phase. We don’t care about nuances here; we just want to save the database.

I recommend implementing a “Challenge” or “Block” rule specifically for traffic that matches the unwanted ISO code but doesn’t match known good paths (like your health checks or admin routes).

(ip.geoip.country eq "RU" and not http.request.uri.path contains "/healthcheck")

In AWS WAF, this looks slightly different, but the logic is the same. Set the action to BLOCK if you are certain you have zero legitimate users there, or CAPTCHA if you want to be polite.

Solution 2: The Permanent Fix (Application Layer Middleware)

Sometimes you can’t just block the traffic at the edge. Maybe your marketing team needs to log these hits to prove to the ad network that the traffic is bad so they can get a refund. In that case, you let the traffic hit your load balancer, but you handle it in your ingress controller or middleware (like Nginx or Traefik).

Here is a snippet from a standard Nginx configuration we use on prod-lb-public to create a “blackhole” map. It returns a 444 No Response (which closes the connection immediately) or a 204 No Content (to save bandwidth but log the hit).

map $geoip_country_code $allowed_country {
    default yes;
    RU      no;
    CN      no;
}

server {
    listen 80;
    server_name api.techresolve.io;

    if ($allowed_country = no) {
        # Return 444 to drop connection without sending headers
        # Saves bandwidth, confuses bots.
        return 444; 
    }

    location / {
        proxy_pass http://backend_upstream;
    }
}

Solution 3: The ‘Nuclear’ Option (ASN Blocking)

If the geo-blocking isn’t working because they are using proxies or VPNs, you look at the ASN (Autonomous System Number). In the Liftoff Mobile incidents, we often see traffic coming from specific hosting providers rather than residential ISPs. Residential traffic is usually humans; Data Center traffic is usually bots.

If you see a surge from an ASN known for cheap VPS hosting, block the whole ASN. It’s aggressive, but it works.

At the end of the day, traffic anomalies like this are just part of the job. The key is to react calmly, analyze the headers, and apply the filter that causes the least amount of friction for your paying customers. Now, go check your Grafana boards—just in case.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions