Nginx aliases and proxy_pass

configurationnginxweb-hosting

I'm using nginx as web front-end and apache2 as web back-end. Apache runs several websites locally and nginx access them.

At the moment, different sub-domains are hosted, but I want to migrate them into a single one using http://my-single-domain.com/subdomain-alias thanks to nginx.

The root directory and the apache2 vhost port is different for each sub-domain (sounds obvious, doesn't it?).

I tried several configurations but I cannot get the resource being sent, i.e., the index html is sent but the resources are not found by the server (404 Not Found) despite the rule root being set.

I tried several solution such as:

location /alias1 {
  proxy_pass   http://127.0.0.1:9095/;
  include      /etc/nginx/proxy.conf;
}

location /alias1 {
  alias  /alias1/;
  proxy_pass   http://127.0.0.1:9095/;
  include      /etc/nginx/proxy.conf;
}

or even

location /alias1/ {
  rewrite ^/alias1(/.*)$ $1 break;
  proxy_pass http://127.0.0.1:9095/;
}

or again

location /alias1/ {
  rewrite ^/alias1(/.*)$ $1 break;
  proxy_pass   http://127.0.0.1:9095/;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

What is wrong with this setup? How to set nginx to retrieves assets from a specific root directory when the age /alias1/page is requested ?

Asked first on webmasters.stackexchange.com

—### /etc/nginx/proxy.conf
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
#client_max_body_size 10m;
#client_body_buffer_size 128k; proxy_connect_timeout 90;
#proxy_send_timeout 90; proxy_read_timeout 90;
proxy_buffers 32 4k;

/etc/nginx/nginx.conf

 user              www-data  www-data;

 worker_processes  2;

 pid        /var/run/nginx.pid;

 worker_rlimit_nofile 1024;

 events {
         worker_connections 512;
 }


 http {

         include /etc/nginx/mime.types;
         default_type application/octet-stream;
         sendfile "on";
         tcp_nopush "on";
         tcp_nodelay "on";
         keepalive_timeout "65";
         access_log "/var/log/nginx/access.log";
         error_log "/var/log/nginx/error.log";
         server_tokens off;
         types_hash_max_size 2048;

         include /etc/nginx/conf.d/*.conf;
         include /etc/nginx/sites-enabled/*/*;
 }

/etc/nginx/site-enable/single-domain.conf

server {
        listen      443;
        ssl on;
        ssl_certificate /etc/ssl/private/single-domain.com-with_chain.crt;
        ssl_certificate_key /etc/ssl/private/single-domain.com.key.pem;

        ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
        ssl_prefer_server_ciphers on;
        ssl_dhparam /etc/ssl/private/dhparams.pem;

        server_name www.single-domain.com;

        location / {
                proxy_pass   http://127.0.0.1:8090/;
                include      /etc/nginx/proxy.conf;
        }

        location /alias/ {
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_pass   http://127.0.0.1:8103/;
        proxy_set_header Host alias.single-domain.com;
        root /var/www/alias.single-domain.com;
        }

        location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx|otf|eot|svg|ttf|woff)$ {
                root /var/www/single-domain.com/public;
                proxy_buffering on;
                proxy_cache_valid 200 120m;
                expires 864000;
        }

        access_log /var/log/nginx/single-domain.com/www-access.log;
        error_log /var/log/nginx/single-domain.com/www-error.log;
}

Best Answer

If apache is listening on port 9095 for domain sub1.example.com and on port 9096 for domain sub2.example.com, and you want nginx to pass http://www.example.com/alias1 to first, and http://www.example.com/alias2 to second apache virtualhost, you would do:

location /alias1/ {
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_pass   http://127.0.0.1:9095/;
        proxy_set_header Host sub1.example.com;
}

location /alias2/ {
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_pass   http://127.0.0.1:9096/;
        proxy_set_header Host sub2.example.com;
}

then for example original request to nginx at http://your-single-domain.example.com/alias1/foo/page1.html would be forwarded to apache as if it went to http://sub1.example.com:9095/foo/page1.html

And original request to nginx at http://your-single-domain.example.com/alias2/bar/baz/page2.html would be forwarded to apache as if it went to http://sub2.example.com:9096/bar/baz/page2.html

Update1 (proof of concept): with the nginx having only config file as above, we run netcat as nc -l -p 9095 (apache should not be listening on that port for this debug), and then open in browser http://www.single-domain.com/alias1/assets/style.css. We should see in netcat output the following:

GET /assets/style.css HTTP/1.1
Host: sub1.example.com
Connection: close
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.6.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1

If there was apache listening on port 9095 instead of our netcat, it would thus get HTTP/1.1 request for URL "http://sub1.example.com/assets/style.css" (which would be shown in /var/log/apache2/access_log or similar)

Note that rewrite ^/alias1(/.*)$ $1 break; isn't needed, as location /alias1/ will automatically strip that /alias1/ part of URL.

If you get different output when using your nginx config file, that means you have conflicting directives in nginx - I that case recommend starting with just the configuration in this answer, checking that it works, and then start adding old configuration blocks one by one until it breaks - and then you'll have conflicting block which needs to change.

Update2: since you posted your nginx config, it is obvious - you have location override that says all your .css files (along the bunch of other files) are to be served directly with nginx from /var/www/single-domain.com/public. Remove or edit it, and it will go through apache.

Correct way in new versions of nginx

Turn out my first answer to this question was correct at certain time, but it turned into another pitfall - to stay up to date please check Taxing rewrite pitfalls

I have been corrected by many SE users, so the credit goes to them, but more importantly, here is the correct code:

server {
       listen         80;
       server_name    my.domain.com;
       return         301 https://$server_name$request_uri;
}

server {
       listen         443 ssl;
       server_name    my.domain.com;
       # add Strict-Transport-Security to prevent man in the middle attacks
       add_header Strict-Transport-Security "max-age=31536000" always; 

       [....]
}

Nginx – need Nginx and something like Gunicorn

Overly simplified: You need something that executes Python but Python isn't the best at handling all types of requests.

[disclaimer: I'm a Gunicorn developer]

Less simplified: Regardless of what app server you use (Gunicorn, mod_wsgi, mod_uwsgi, cherrypy) any sort of non-trivial deployment will have something upstream that will handle the requests that your Django app should not be handling. Trivial examples of such requests are serving static assets (images/css/js).

This results in two first tiers of the classic "three tier architecture". Ie, the webserver (Nginx in your case) will handle many requests for images and static resources. Requests that need to be dynamically generated will then be passed on to the application server (Gunicorn in your example). (As an aside, the third of the three tiers is the database)

Historically speaking, each of these tiers would be hosted on separate machines (and there would most likely be multiple machines in the first two tiers, ie: 5 web servers dispatch requests to two app servers which in turn query a single database).

In the modern era we now have applications of all shapes and sizes. Not every weekend project or small business site actually needs the horsepower of multiple machines and will run quite happily on a single box. This has spawned new entries into the array of hosting solutions. Some solutions will marry the app server to the web server (Apache httpd + mod_wsgi, Nginx + mod_uwsgi, etc). And its not at all uncommon to host the database on the same machine as one of these web/app server combinations.

Now in the case of Gunicorn, we made a specific decision (copying from Ruby's Unicorn) to keep things separate from Nginx while relying on Nginx's proxying behavior. Specifically, if we can assume that Gunicorn will never read connections directly from the internet, then we don't have to worry about clients that are slow. This means that the processing model for Gunicorn is embarrassingly simple.

The separation also allows Gunicorn to be written in pure Python which minimizes the cost of development while not significantly impacting performance. It also allows users the ability to use other proxies (assuming they buffer correctly).

As to your second question about what actually handles the HTTP request, the simple answer is Gunicorn. The complete answer is both Nginx and Gunicorn handle the request. Basically, Nginx will receive the request and if it's a dynamic request (generally based on URL patterns) then it will give that request to Gunicorn, which will process it, and then return a response to Nginx which then forwards the response back to the original client.

So in closing, yes. You need both Nginx and Gunicorn (or something similar) for a proper Django deployment. If you're specifically looking to host Django with Nginx, then I would investigate Gunicorn, mod_uwsgi, and maybe CherryPy as candidates for the Django side of things.

/etc/nginx/nginx.conf

/etc/nginx/site-enable/single-domain.conf

Best Answer

Related Solutions

Nginx – In Nginx, how can I rewrite all http requests to https while maintaining sub-domain

Correct way in new versions of nginx

Nginx – need Nginx and something like Gunicorn

Related Topic