Optimizing Nginx for Reverse Proxy

Hey everyone, I’m going to @SgtAwesomesauce @Adubs @cekim and @BookrVII but anyone else that wants to participate can :grin:

Scenario:

Flask application running on port 5000
VueJS application running on 80 (just simple landing/info pages, SSL not needed)

Implementation:

Nginx with single default.conf file that listens on 80 for the Vue and performs a proxy_pass on the Flask.

server {
    listen 80;
    root /var/www/internal/html/
    
    location / {
        root /var/www/internal/html/welcome-site
        index index.html index index.htm index.php
    }

    location /getClicks {
        proxy_pass http://localhost:5000/getClicks
    }

    location /getViews {
        proxy_pass http://localhost:5000/getViews
    }

    location /getGot {
        proxy_pass http://localhost:5000/getGot
    }

You get the idea.

My question is sort of split into two: Should this be divided into two files in the /etc/nginx/conf.d/ directories, separated by server (one for Vue, likely in the default.conf and one for Flask in api.conf or something), and is there a more “optimal” way of doing this? Or is it normal to declare each location for various API calls?

Right now the above works just fine for what I’m doing. Routes work and content is rendered without declaring ports. I plan on doing some caching for the images. But I want to get an optimal config first.

1 Like

no fucking clue, I still havent gotten around to dicking around with nginx.

@BirdoBaggins might know something.

1 Like

Lulz. Thanks. Right now the above works just fine. I plan on doing some caching for the images. But I want to get an optimal config first. Should probably throw this in OP :thinking:

If that’s easier for you to administrate go for it, it won’t do anything for performance though. It really comes down to personal preference and makes the site easier for you to manage.

The performance impact of doing things this way should be basically 0.

1 Like

ditto for me on nginx… and my apache usage has never been fancy.

1 Like

Word, thanks man!

But muh minimal web serv! :scream:

I only use nginx for let’s encrypt cert updates without a config file. So, I’m no good to you for this sort of chicanery. As a general rule though, what bird said… run-time performance should not care how obtuse your config files might be. It reads those in and converts them to its internal state/rules. It’s not re-parsing that stuff on each call.

1 Like

I need to get with the program but I’ve never had a situation where I HAD to reverse proxy something. Would be nice to consolidate my open ports but meh. Im lazy and its not broken.

2 Likes

[IIS INTENSIFIES]

1 Like

This was largely my case until this gig. It’s pretty cool, and is making me rethink how a lot of the stuff I’ve run. Although, now that I think about it, I think I’m doing that for my little portfolio site. It’s just been a while. Might be using IPTables for that.

Having a “backend” and “frontend” on the same server is what has inspired me to use it. It’s pretty cool when it works. :grin: Now to figure out how the caching works.

Keyword is “”“minimal”"" :wink:

1 Like

check a box, make a website

its so easy a caveman could do it.

1 Like

Makes sense, my knowledge of how this works (as well as Apache and Logstash) is your config files are loaded into a giant file and read linearly after that. I figured my “clean up” was from a preference.

This was my main concern, but I suppose at the end of the day if it’s all being compiled into a giant file the number of location definitions per file doesn’t matter.

Thanks guise for the confirmation bias validation :yay:

Maybe, but the Linux/JavaScript people here might get a little upset when I start selling them on IIS :grin:

1 Like

REEEEEEEEEEEEEE

:wink:

1 Like

tbh, as a windows guy… even I use apache for everything. I havent tried IIS in a while though so maybe its not as bad as it used to be.

1 Like

You can have multiple conf files if you so wish, it more or less is an organizational thing to have more than one conf file. You can even use includes to pull conf files from other locations to make management of things like certs easier.

Is the target to proxy flask from port 5000 to port 80 via the main server?

1 Like

split into so many files that you have to edit /etc/security/limits.conf for it to work

Ah, that’s a good point. I’ll consider breaking it out with SSL stuff.

Yeah, so if they go maindomain it’ll take them to main server and maindomain/apiCall it’ll forward/pass to maindomain:5000/apiCall

Lol I’ll try that and see what happens.

you would need THOUSANDS of config files

3 Likes

I just checked my config to see what I have, I don’t see why yours won’t work.
Another option is you could always stick flask to a subdomain and just have all apicalls automatically go to that without the need to individually identifying each one as it own “location” entry.


So the other potential option as an example would be:

server {
    listen 80
    server_name flask.domain.local

    location / {
        proxy_pass http://localhost:5000
    }
}
1 Like

Oh yeah, see bottom of OP. I made an edit. It does work, I just didn’t know if the way I had it was “the best” way. It has worked the whole time :grin: Sorry for the confusion.