Requests between webservers in Nginx
So I've got 2 servers up and running on my Nginx server. Both are working/routing correctly, and I've made one a subdomain of the other:
api.example.com & example.com
If I need to communicate between the two do I still just make a request to api.example.com? Is that request going out to the internet and then back to Nginx, or is there a way to tell Nginx just to make the request directly?12 Replies
that depends on a lot of things, but not at all on nginx
when some of your code runs and performs a request to
api.example.com, it's treated like any other request made by any process on the server. DNS is checked to get an IP, the routing table is checked to see how to get to that IP, the right header is added to a request packet, and it's sent
the route the package takes is determined by what api.example.com resolves to, and how the routing table is set up
the easiest way to ensure that api.example.com is sent internally, is by editing /etc/hosts and adding this line:
assuming your server for api.example.com is at 10.0.0.1 and example.com is at 10.0.0.2
if they're both on the same Ip, you can just do this
or if they're both on the machine you're doing the requests from
Hmm, interesting. Yeah they are both on the same IP, just using Nginx as a proxy server.
So setting
127.0.0.1 for api.example.com (example.com will never be called locally) will tell ubuntu (rather than Nginx?) that this domain is found locally, and Ubuntu will reflect the request back at Nginx which will then just proxy the request as normal? Would that be the same as making the axios call to 127.0.0.1 in the application instead, rather than using a domain name?
Are there any benefits to doing this? Like if I don't need the api exposed to the internet at all that seems like a good thing
Sorry for the 20 questions 😁no worries 🙂
When a computer does a DNS request, the first thing it checks is the hosts file, so adding
127.0.0.1 api.example.com to /etc/hosts will tell Ubuntu that if it needs to reach api.example.com, it needs to talk to 127.0.0.1. Depending on which network interfaces nginx binds to, you may have to put the local IP in there instead of the loopback IP (127.0.0.1). All the other network stuff will work as normal.
As for not having it exposed to the internet: You can use this to redirect traffic from your server, but not to your server. It makes it so you can access the server from the inside without the traffic ever leaving the server itself, but you can't use the hosts file to prevent connections from the outside, you'll have to do that some other way.
the main benefit is that your network traffic never leaves your server. It's all handled internally, so there's no real bandwidth impact, or latency.
a lot of network setups also don't like traffic coming from the inside of the network targeting the external IP. So if your server requests stuff for api.example.com and it resolves to the internet IP of the server, some modems / routers / firewalls will just drop your trafficI did consider that maybe I wouldn't even be able to make a request back to my own server, so this is good to know.
As for incoming traffic, yeah I just meant if I can redirect my request, as the only traffic to the api I can just remove the server_block for that api entirely. So use the host file to redirect my request from my server to my api locally, and then remove all routing by nginx to the api.
God this is bringing up memories of lugging a load of pcs to a friends back in the day to play age of empires 2 😆
yeah, you can definitely use this to redirect to the API, though you could also just call the IP based on its API internally and skip the entire hosts file step
yeah so just call 127:0.0.1 from my
example.com app, and have a server block listening to that ip in order to route it to the port my api is listening on?I can't really say without knowing your network layout
mostly, you can use hosts to make your server think a domain is elsewhere. If an http(s) request to a certain IP would give you access to your API, you can use /etc/hosts to turn that IP into a domain name. That's all it does
yeah sure, I was just thinking about bypassing it, but I guess the same applies
i just have to have a server block with the localhost ip rather than the domain name
so if your api is listening to localhost / 127.0.0.1 on HTTP, you can either put http://127.0.0.1/api/ to access your API, or put
127.0.0.1 api.example.com in hosts and use http://api.example.com/apiGreat, I've definitely got enough to have a crack at this either way. Thanks a lot for your help, made things a lot easier (the last few days learning ubuntu and nginx have been a bit of a baptism of fire!)
Unknown User•16mo ago
Message Not Public
Sign In & Join Server To View
Appreciate the vote of confidence in my skills, but I'm not sure I'm quite there yet 😄
am fairly keen on looking at docker/kubernetes at some point, which I'm guessing would deal with that side of things for me, but all in good time!