A reverse proxy sits in front of your application and takes incoming requests before sending them to the right server. Think of it as the front desk. Your app doesn’t need to deal with every visitor directly.<\/p>\n
You’ll need a server running your application and another server, or the same machine, running the reverse proxy. Nginx is a solid choice here. It’s fast, well documented, and frankly, there’s no good reason to make this harder than it needs to be.<\/p>\n
The basic path looks like this:<\/p>\n
\u2022 Browser traffic hits Nginx first, which is the whole point of putting it there.<\/p>\n
\u2022 Your application keeps listening on its private port, say 3000, while Nginx handles the public-facing side.<\/p>\n
\u2022 A request for \/api gets passed to the app, and the proxy keeps the outside world from needing to know that port exists.<\/p>\n
On Ubuntu, you can install it with sudo apt update followed by sudo apt install nginx. Then check that the service is running. Open the server’s IP address in your browser. You should see the default Nginx page.<\/p>\n
That little page is useful. It tells you the proxy server itself is alive before you start blaming your application for problems.<\/p>\n
Now comes the part that actually makes Nginx a reverse proxy. Create a server block and tell it where requests should go.<\/p>\n
A simple configuration looks like this:<\/p>\n
server {<\/p>\n
listen 80;<\/p>\n
server_name example.com;<\/p>\n
location \/ {<\/p>\n
proxy_pass http:\/\/127.0.0.1:3000;<\/p>\n
proxy_set_header Host $host;<\/p>\n
proxy_set_header X-Real-IP $remote_addr;<\/p>\n
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;<\/p>\n
proxy_set_header X-Forwarded-Proto $scheme;<\/p>\n
}<\/p>\n
}<\/p>\n
The important line is proxy_pass. Nginx receives the request and forwards it to your app on port 3000. The header settings matter too because your application may need to know the original host, client address, or whether the request arrived over HTTPS.<\/p>\n
Don’t edit the config and immediately walk away. Run sudo nginx -t. If Nginx reports that the configuration is valid, reload it with sudo systemctl reload nginx.<\/p>\n
Raj once spent ten minutes staring at a blank browser page because he’d missed a semicolon in his config. He eventually fixed it, then stopped reopening the same five terminal tabs every morning to check which service was broken.<\/p>\n
HTTP works for testing. For a real site, use HTTPS. Certbot can obtain a certificate and configure Nginx for you, which is much less painful than managing certificates by hand.<\/p>\n
You’ll also want to think about what the proxy should expose. Keep the application port closed to the public internet when possible. Only Nginx needs to accept normal web traffic.<\/p>\n
\u2022 Logging is worth keeping on, especially while you’re debugging. A request that disappears without a trace gets annoying fast.<\/p>\n
\u2022 Timeouts deserve attention too, because a slow backend shouldn’t leave connections hanging forever.<\/p>\n
\u2022 WebSocket apps need extra proxy settings, so don’t assume a normal HTTP setup covers them.<\/p>\n
A reverse proxy should feel almost invisible once it’s working. That’s a good thing.<\/p>\n
Start with one app behind it. Test the routing. Add HTTPS. Then add more rules if you actually need them. You don’t get bonus points for turning a simple proxy into a maze of configuration files.<\/p>\n
And when something breaks, check the path one piece at a time: browser to Nginx, then Nginx to the application. Usually, the problem gets obvious pretty quickly.<\/p>","protected":false},"excerpt":{"rendered":"
A reverse proxy sits in front of your application and takes incoming requests before sending them to the right server….<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[31],"tags":[],"class_list":["post-4371","post","type-post","status-publish","format-standard","hentry","category-learn"],"_links":{"self":[{"href":"https:\/\/cybx.in\/blog\/wp-json\/wp\/v2\/posts\/4371","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cybx.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybx.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cybx.in\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/cybx.in\/blog\/wp-json\/wp\/v2\/comments?post=4371"}],"version-history":[{"count":1,"href":"https:\/\/cybx.in\/blog\/wp-json\/wp\/v2\/posts\/4371\/revisions"}],"predecessor-version":[{"id":4396,"href":"https:\/\/cybx.in\/blog\/wp-json\/wp\/v2\/posts\/4371\/revisions\/4396"}],"wp:attachment":[{"href":"https:\/\/cybx.in\/blog\/wp-json\/wp\/v2\/media?parent=4371"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybx.in\/blog\/wp-json\/wp\/v2\/categories?post=4371"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybx.in\/blog\/wp-json\/wp\/v2\/tags?post=4371"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}