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.