---
title: "Comment by Edge Ops on \"Keeping analytics honest: filtering data-center traffic with a sorted list of IP ranges\" | Hashnode"
description: "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"
url: "https://hashnode.com/posts/filtering-datacenter-traffic/6aef81529895cf9502f0185a/comment/6af2693a23eb62f4409881e6"
---

[Discussion](https://hashnode.com/posts/filtering-datacenter-traffic/6aef81529895cf9502f0185a)

Comment [Keeping analytics honest: filtering data-center traffic with a sorted list of IP ranges](https://hashnode.com/posts/filtering-datacenter-traffic/6aef81529895cf9502f0185a)

[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.