Redirecting users to city-specific content from a single domain can be a headache, but it’s solvable. Learn three practical methods, from quick server-side fixes with Nginx to scalable, cloud-native solutions using GeoIP at the edge.

One Domain, Ten Cities: A Senior Engineer’s Guide to Geo-Targeted Landing Pages

I still remember the “CityLaunch” project from a few years back. 3 AM, the night before a major marketing campaign goes live. The frantic Slack message comes in from a junior dev: “The landing page isn’t working! Everyone in the London office is seeing the New York page!” We had one domain, `citylaunch.io`, and a mandate to show a unique experience for ten different metro areas. The dev had built ten beautiful pages, but the server, `prod-web-01`, was blissfully unaware of geography and just served up the default `index.html` to everyone. It’s a classic problem: your application is smart, but your infrastructure is dumb. We fixed it with a hacky, middle-of-the-night patch, but it taught me a valuable lesson: routing isn’t just about URLs, it’s about user context.

The “Why”: Servers Don’t Carry Passports

At its core, the problem is simple. When a user in Berlin visits your website, your web server (be it Nginx, Apache, or Caddy) only sees an IP address. By itself, that IP address is just a string of numbers. The server has no inherent knowledge that 81.2.69.142 is likely someone in London. To make intelligent, location-based decisions, you have to give the server a “translator”—a tool to map that IP address to a physical location. Once you have that city, state, or country, you can rewrite the request, serve a different file, or redirect the user entirely.

So, let’s look at a few ways to build that translator, from the quick fix to the “right” way.

Solution 1: The ‘Duct Tape’ Fix (Manual IP Mapping)

This is the “It’s 3 AM and this just has to work” solution. It’s brittle, a pain to maintain, but it’s fast and requires no external modules. You basically create a manual list (a “map”) of known IP blocks for the cities you care about and tell your web server what to do with them.

Let’s say you want to show a special page for your London office, and you know their public IP range is 81.2.69.0/24. You could add this to your Nginx config:

http {
    # Map the client IP to a variable, let's call it $landing_page
    geo $landing_page {
        default         /index.html;      # Everyone else gets the default
        81.2.69.0/24    /london.html;     # Our London office IP block
        # You could add more here... but don't. Please don't.
    }

    server {
        listen 80;
        server_name example.com;

        location = / {
            # Internally rewrite the request for the root path
            rewrite ^ /.$landing_page last;
        }

        # ... other server config ...
    }
}

Why it’s “Duct Tape”: You have to manually find and update IP ranges for every city. These change, and you’ll never get them all. This is only viable for a tiny, known set of users, like internal offices, not the general public.

Solution 2: The Permanent Fix (The GeoIP Database)

This is the proper way to do it on a single server or traditional VM. You use a dedicated module and a professional GeoIP database (like the free GeoLite2 database from MaxMind) to do the IP-to-location mapping for you.

First, you’d need to install the Nginx GeoIP2 module (`ngx_http_geoip2_module`). Then, you download the database files and point your Nginx config to them.

http {
    # Load the GeoIP databases
    geoip2 /etc/nginx/geoip/GeoLite2-City.mmdb {
        # Map the remote IP to a city name variable
        $geoip2_city_name source=$remote_addr city names en;
    }

    # Map the city name to a specific page
    map $geoip2_city_name $landing_page {
        "London"    /london.html;
        "Tokyo"     /tokyo.html;
        "New York"  /new-york.html;
        default     /index.html;
    }

    server {
        listen 80;
        server_name example.com;

        location = / {
            # Rewrite based on the city found in the map
            rewrite ^ /.$landing_page last;
        }
    }
}

Why it’s better: This is far more accurate and comprehensive than a manual list. It handles millions of IP ranges for you. The only ongoing work is running a cron job to update the .mmdb database file once a month so your data stays fresh.

Pro Tip: Always have a default option in your map. GeoIP lookups can fail or return an unknown location. If you don’t have a fallback, users from unlisted cities will get a 404 error, which is a terrible user experience.

Solution 3: The ‘Cloud Native’ Way (Offload to the Edge)

If you’re running on a modern cloud stack, managing GeoIP databases on individual servers is kind of old-school. Why handle that logic on your origin server when you can have a global network do it for you at the “edge”—long before the request ever hits your infrastructure? This is faster for the user and simpler for you to manage.

This approach uses services like a Content Delivery Network (CDN) or a cloud provider’s DNS routing.

Why it’s the future: This decouples the location logic from your application servers. Your app servers can be “dumb” again; they just serve the content they’re told to. This approach is more scalable, often faster for end-users, and reduces the processing load on your origin. The downside? It usually involves vendor lock-in and can be more complex to set up initially.

Ultimately, the right choice depends on your stack. But for that panicked junior dev at 3 AM? We used a variation of Solution 2 and got the campaign launched. The next week, though, we started planning our migration to an edge-based solution.

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