It’s possible you’ll imagine that the above works – and it does, however I’d wish to show it.
- Apache APISIX configured as above
- Two upstreams, one in English and one in French
/usr/native/apisix/conf/apisix.yaml
upstreams:
- id: 1
kind: roundrobin
nodes:
"english:8082": 1
- id: 2
kind: roundrobin
nodes:
"french:8081": 1
routes:
- uri: /
upstream_id: 1
- uri: /
upstream_id: 2
#ENDWith this snippet, each consumer accesses the English upstream. I intend to direct customers situated in France to the French upstream and the remainder to the English one. For this, we have to configure the second route:
/usr/native/apisix/conf/apisix.yaml
routes:
- uri: /
upstream_id: 2
vars: [["geoip_country_code", "==", "FR"]] (1)
precedence: 5 (2)| 1 | The magic occurs right here; see under. |
| 2 | By default, route matching guidelines are evaluated in arbitrary order. We’d like this rule to be evaluated first. So we improve the precedence – the default is 10. |
Most Apache APISIX customers are used to matching on routes, strategies, and domains, however there’s extra to it. One can match on Nginx variables, as proven above. In our case, the route matches if the geoip_country_code variable is the same as "FR".
Word that vars values readability over energy. Use the filter_func(vars) attribute for those who want extra complicated logic.
We are able to nonetheless not take a look at our characteristic at this level, as we would wish to vary our IP tackle. Fortuitously, it’s doable to cheat (a bit), and the cheat is useful in different situations. Think about that Apache APISIX just isn’t straight uncovered to the Web however sits behind a reverse proxy. There is likely to be a number of causes for this: “historical past”, a single RP pointing to a number of gateways beneath the duty of various groups, and so on.
On this case, the shopper IP could be the RP’s proxy. To propagate the unique shopper IP, the agreed-upon technique is so as to add an X-Forwarded-For request HTTP header:
The X-Forwarded-For (XFF) request header is a de-facto commonplace header for figuring out the originating IP tackle of a shopper connecting to an online server by means of a proxy server.
When a shopper connects on to a server, the shopper’s IP tackle is shipped to the server (and is commonly written to server entry logs). But when a shopper connection passes by means of any ahead or reverse proxies, the server solely sees the ultimate proxy’s IP tackle, which is commonly of little use. That’s very true if the ultimate proxy is a load balancer which is a part of the identical set up because the server. So, to offer a more-useful shopper IP tackle to the server, the
X-Forwarded-Forrequest header is used.
The Nginx module affords this configuration however restricts it to an IP vary. For testing, we configure it to any IP; in manufacturing, we should always set it to the RP IP.
/usr/native/apisix/conf/config.yaml
nginx_config:
http:
geoip_proxy 0.0.0.0/0;We are able to lastly take a look at the setup:
{
"lang": "en",
"message": "Welcome to Apache APISIX"
}
curl -H "X-Forwarded-For: 212.27.48.10" localhost:9080 (1)| 1 | 212.27.48.10 is a French IP tackle |
{
"lang": "fr",
"message": "Bienvenue à Apache APISIX"
}
