For the second part of this series let’s talk about another command, this time, let’s talk about the geo command.

The geo command, as the name says, was created to allow geolocation information, but actually, you can think of geo as a “switch case” where you can match network blocks and get a result from it. So let’s say for example that you want your QA team to always go to your preproduction environment instead of production, with geo this can be done easily, provide your team have a fixed IP address that you match.

Another possibility is to route a single server or a group of servers to a different upstream, for example, to do regression tests in a debug server, this is possible if you use NGINX to route the API calls through your application stack.

The geo can also be used together with the rate limit module, allowing you to specify rules for specific netblocks, let’s say you have a global rate limit and you want to allow your special customer to be whitelisted.

The idea here is to use the variable $binary_remote_addr for every request except for the customer network, for the customer network we will return an empty value.

On the next post, we will talk about the map command.

If you have any suggestion for a post or if you even have NGINX questions feel free to contact me through the contact link here on the blog.

As the idea of this series of posts is to show different ways of using NGINX configurations, I would like to ask for your collaboration sending questions or even guest posts.

See you in the next post, thanks!