GeoIP blocking on nginx and Cloudflare: DevOps guide

GeoIP blocking: where access logic breaks

GeoIP blocking looks like a simple rule: match the client's address against a range from the region database and return a denial. In reality, it is one of the most fragile places in the access perimeter — a failure does not show up immediately or where people look for it.

The first typical failure is false client blocks. Mobile operators aggregate traffic behind a shared gateway, corporate networks go online through a single node, and the address no longer matches the user's actual region.

A paying customer from a target country gets denied, support spends hours investigating, because the logs only show the triggered country rule.

Second is bypassing the block through proxies and VPNs. Exit nodes are rented in clouds and data centers whose ranges are assigned to another country, so the "allow only our regions" filter lets through exactly those from whom you were closing off.

Geo-filtering traffic by address country in such a scheme provides not protection but an illusion of control.

Third is the currency of region databases and their desynchronization between nodes.

Ranges move between operators, databases update on a schedule, and if some servers read an old copy while the external filter applies its own table, the same client gets different decisions depending on the entry point.

On top of that, manual edits in configurations pile up: exceptions added for a specific incident remain in the files and gradually override the original logic.

We break down how this is closed: where to keep the region database, how to separate rules by layers, and what to log so a false block is visible before the customer writes to support.

What region-based access control provides

Geography-based access control is valuable not for the very fact of "closing a region" but for a measurable filter at the entry point.

When cut-off rules stand at the perimeter, only target traffic reaches the application — the number of requests that previously occupied workers and the connection pool drops.

Server load reduction is measured by the share of requests rejected before being passed to the application, and by how many freed resources went to useful work.

Parasitic background is cut off before it reaches application logs, so the service handles peak spikes without emergency scaling, and response time on target requests stops fluctuating.

The main risk of any regional filter is erroneous access denials. Real users come through mobile operators, corporate proxies, satellite links, and public VPN exit points, and their addresses do not always match the expected geography.

That is why the false-positive rate is measured separately, an exception list is maintained, and every filter decision is logged — an incident is investigated based on facts, not guesses.

Automation of access rules removes manual configuration edits.

Lists and exceptions are described declaratively, go through review, and are applied from a single source — no discrepancies between environments arise, and the volume of manual changes is reduced to a few lines per release.

Together this gives service stability: an entire class of failures goes away — connection pool exhaustion and degradation during spikes from non-target regions. The filter works as a standard fuse before the application, not as a crutch inside it.

Comparison of approaches: nginx, Cloudflare, load balancer

The decision on geo-filtering can be made at three levels: before the request reaches your infrastructure, at its entry point, or already inside the application. The choice affects resource consumption, rule accuracy, and which client address the system sees.

A separate practical point is working behind a proxy: if the real address is not inserted into the chain of trusted headers, server-level blocking starts cutting off the wrong users. Below are four schemes and their limitations.

The limitations of the approaches add up: the earlier we cut off, the cheaper the traffic, but the coarser the rules. A hybrid scheme usually provides the best balance — a coarse country filter at the entry point and precise exceptions on the server.

Implementation order: from audit to handover

Geo-filtering rarely breaks production at the moment it is enabled — the problem comes later, when rules live in several places and gradually diverge.

That is why we structure the geo-filtering implementation stages so that every decision relies on measured traffic, not on an assumption about "where our users come from."

1. Audit of access rules and traffic inventory. We gather the real picture: shares of requests by country, bot sources, existing restrictions at the perimeter and in the application. This also shows who the filter will affect first.
2. Filtering scheme. We determine the decision point — the network edge or the web server itself — the geo data source, and behavior when the database is outdated: allow or deny. We separately define what to do with search engine bots and payment gateway notifications.
3. Setting up geo data sources. We connect an updatable address database, set up regular updates and control of desynchronization between the perimeter and the server, so that rules do not diverge.
4. Soft mode. The filter only writes to the log and does not return a denial. We keep it as long as needed to make sure no legitimate scenario has triggered it.
5. Testing on a staging environment. We run typical and edge-case requests from different regions, check response codes and headers, and test rollback to previous rules in advance.
6. Enabling and handover with procedures. We switch to production mode in stages, hand over the scheme, database update procedure, and maintenance regulations: who and how adds exceptions, how quickly we roll back, and where logs are viewed.

What we hand over: configurations and procedures

We hand over the project not at the moment a rule starts working in production, but when your team can reproduce, adjust, and roll it back without us.

That is why what is handed over is not a set of screenshots but a working set of artifacts by which a new engineer is onboarded into the perimeter in one day.

• Rule files — GeoIP configurations on nginx and expression sets in Cloudflare, consolidated into a repository with change history, not scattered across personal dashboards.
• Request path map: at which node the blocking decision is made, which headers reach the application, and where the real client address is substituted.
• Geo data sources and their update schedule: which database is used, how often it is pulled, and what happens when the source is unavailable.
• Access documentation: roles, areas of responsibility, where keys are stored, how they are rotated, and who approves issuance.
• Exception policies: allowlists for search engine bots, monitoring, payment callbacks, and internal services — with the procedure for adding and approving them.
• Change rollback procedure: which edit is removed with one command, how long application takes, and by which metrics it is clear that the block has actually been removed.
• Rule update procedure: testing on a staging environment, application window, who approves disputed blocks, and how the decision is recorded.
• Contacts of responsible parties on both sides and an escalation point in case a rule affects real customers.

Before handover, we run through the scenario using these documents step by step: add an exception, roll back a change, update the database. If any step has to be explained from memory, we improve the document rather than leave it as is.

Case study: false positives and perimeter load

What it was like before the changes

An online store with traffic from several regions kept geo-filtering right at the perimeter: rules on nginx and country lists on the Cloudflare side. Address ranges changed, and rules were updated manually — the on-call engineer edited configs and restarted the service. False positives reached 6–8% of login attempts, and support handled about 40 tickets per week.

The side effect was routine: 2–3 hours a day went into reconciling lists with logs, and one erroneous entry disabled an entire region.

What was changed

We separated geo data sources and decision logic: the database updates on a schedule, responses are cached, and there is a separate exception list for service addresses and verified customers.

Geolocation checking stopped being a hot spot on the perimeter because every request no longer goes to the database. We enable new rules canary-style on a small share of traffic, and the share of denials by region is displayed on a dashboard next to the response code.

The data source is access logs and a support ticket export for comparable periods with the same traffic profile. Canary enablement caught problematic ranges twice before rollout to all traffic — those denials did not reach customers.

How GeoIP blocking on nginx differs from Cloudflare

In both cases the same logic works — "region by database — rule — denial" — but the decision point is different.

GeoIP blocking on the server lives in the nginx configuration: the request reaches the machine, the address is checked against the geolocation database, and only then the request either goes to the application or gets denied.

On the CDN side, the check happens at the provider's node — before traffic even enters your perimeter.

Hence the main discrepancy is determining the client's region behind a proxy. If a load balancer or CDN stands in front of the server, the socket returns the address of the intermediate node, not the visitor's.

Without correctly configured trusted proxies and a header with the original address, the filter will start comparing the region of the intermediate link itself — the rule formally works, but the decision is made based on someone else's data.

On the CDN side, the client address is known from the start, there is nothing to substitute it with, but you also cannot influence this part of the chain.

Geolocation data is updated differently. On the server, the database is with you: it needs to be regularly fetched, monitored for freshness, and reloaded after an update — usually this is a configuration reload, so updates are scheduled separately from releases.

On the CDN side, the provider updates the database: you have neither the timing nor the ability to roll it back — behavior changes on its own, and this should be factored into exception rules for disputed ranges and mobile operators.

The difference in latency and load is also noticeable. Local filtering does not speed up the response: the request still occupies a connection and server processing, but it gives full control over rules, exception logic, and denial logs.

CDN-side filtering cuts traffic off earlier — it offloads the channel and application but is less flexible. In practice, the approaches are combined: the CDN acts as a coarse first filter, nginx as the second layer and a point for non-standard rules.

Common technical doubts before starting

Before enabling filtering, engineers have the same list of questions: what will happen to live traffic, how not to break integrations, and when a rule can be considered tested.

Will the block affect live customers?

That is why we enable a soft filtering mode: instead of a denial, the request gets a bot check or is allowed with a log entry. Borderline addresses remain served, and we collect statistics.

How current is the geo data?

Datasets update once every one to two weeks, and for some ranges the country is not determined. By default, we do not consider such requests violators — we define a rule for them separately.

Will partners and services abroad not fall off?

We maintain explicit exceptions: addresses of partner platforms, monitoring nodes, services already deployed abroad, plus a bypass via a secret header. The list lives in the configuration next to the rules.

How can a rule be tested before launch?

First, observation mode: requests are logged but not cut off. The logs show volume, countries, and affected scenarios. We enable full blocking last, with a rollback plan.

Let's discuss the task and come back with an implementation plan

To discuss the task substantively and come back with an implementation plan rather than general considerations, we need source data for assessment.

Geo rules work differently depending on where encryption terminates, which services stand behind the delivery network, and who should remain on the allowlist — this affects both the scope of work and the order of enablement.

• Traffic path diagram: where exactly the connection terminates, which nodes stand in front of the application, whether there are intermediate links and load balancers.
• List of services and regions: which domains and applications fall under the restriction, from which countries legitimate users open them.
• Current rules: existing geo lists, static networks, rules on the web server and on the delivery network side, and the order of their application.
• Exception requirements: who must not be blocked — search engine bots, monitoring systems, payment and partner addresses, corporate employee exits.
• Access requirements: which roles are needed in the control panel and on servers, who approves changes and coordinates the maintenance window.
• Launch mode: first observation without blocking with statistics collection, then targeted enablement by region, then full application with rollback via one edit.
• Acceptance criteria: which metrics we consider success, what false-positive rate we allow, and in what timeframe we reach target values.

With such a set, we immediately see bottlenecks and propose a realistic sequence of steps. Describe the task and send what you have — we will come back with a timeline estimate and an implementation plan.