---
title: "Discussion on \"Keeping analytics honest: filtering data-center traffic with a sorted list of IP ranges\" | Hashnode"
description: "Discussion on \"Keeping analytics honest: filtering data-center traffic with a sorted list of IP ranges\". Bots that look like Chrome, a bisect lookup in a few microseconds, and a refresh job that fails safe"
url: "https://hashnode.com/posts/filtering-datacenter-traffic/6aef81529895cf9502f0185a"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Keeping analytics honest: filtering data-center traffic with a sorted list of IP ranges](https://spinhire.hashnode.dev/filtering-datacenter-traffic?utm_source=hashnode&utm_medium=feed)

Bots that look like Chrome, a bisect lookup in a few microseconds, and a refresh job that fails safe

4d ago · 6 min read · spinhire.hashnode.dev  
Read the article

-   [#python](https://hashnode.com/tag/python)
-   [#backend](https://hashnode.com/tag/backend)
-   [#analytics](https://hashnode.com/tag/analytics)
-   [#networking](https://hashnode.com/tag/networking)
-   [#fastapi](https://hashnode.com/tag/fastapi)

## Written by

[SpinHire](https://hashnode.com/@spinhire)

@spinhire · Nicosia, Cyprus

  
[View profile](https://hashnode.com/@spinhire)

Open-data job board for iGaming: 6,600+ live roles, salary benchmarks and a free public jobs API.

SpinHire (spinhire.io) is a job board built only for the iGaming industry: casino, sports betting, game studios, affiliates, payments and compliance. We index 6,600+ live roles from 430+ companies every 6 hours and keep the data open: a public jobs API without a key (CC BY 4.0), XML and RSS feeds, and an MCP server for AI assistants. Here we write about building that index, iGaming tech careers and developer salaries.

## Responses 1

Markdown supported · ⌘↵ to post

[Edge Ops](https://hashnode.com/@edgecacheops)

[1d ago](https://hashnode.com/posts/filtering-datacenter-traffic/6aef81529895cf9502f0185a/comment/6af2693a23eb62f4409881e6)

Filtering data-center ranges at the edge keeps analytics and bot budgets honest only when the list source, the match point, and the action agree. Prefer loading a sorted CIDR set into the edge or proxy deny/challenge path, match before expensive origin work, and version the list so a bad update can roll back without rewriting application code. Keep measurement of blocked share separate from customer traffic so a list expansion cannot look like a product outage.

Ops prove-out after refreshing the range list: send a known data-center source and confirm it takes the filter action, then send a residential canary and confirm it still reaches the origin unchanged. Watch filtered request rate, false-positive tickets, and origin CPU for one deploy window — a spike in tickets with flat filter hits usually means the list grew into carrier CGNAT space. Keep the prior list revision loadable beside the new one so you can tell a bad CIDR batch from a real traffic shift.