I would like nginx set an appropriate accept-language header depending on requested domain:
www.domain.ru set ru-RU
www.domain.com set en-US
www.domain.de set de-DE
www.domain.eu do nothing let Django get the header from the browser.
For 3 specified above domains force changing of the accept-language header even
if english user enters www.domain.ru (force it to use russian language).
Here's my nginx config:
server {
listen 1.1.1.1;
server_name domain.eu www.domain.eu domain.de www.domain.de domain.com www.domain.com domain.ru www.domain.ru;
if($host ~* (.*)\.ru) {
set $http_accept_language 'ru-RU';
}
location / {
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_connect_timeout 10;
proxy_read_timeout 10;
proxy_pass http://127.0.0.1:8888/;
}
}
This is a part of my config (running Django via gunicorn).
Django checks accept-language header if session language is not set.
try
if ($host ~* \.ru$) {
set $language 'ru-RU';
}
add_header Accept-Language $language;
setting the variable with $http_.... is probably not the best idea as variables starting with $http_ are interpreted and set with by nginx itself (specifically the name you used would mean 'content of the http header 'accept_language' see http://wiki.nginx.org/HttpCoreModule#Variables). I'm not sure whether your set or nginx's would win but why play with fire?
Related
How can I configure ngnix to redirect a proxypass from a domain with subfolder to /?
Example:
https://example.com/yoursub/
to
localhost without /yoursub/ prefix
At the moment the direct access to the server ip http://xxx.xxx.xxx.xx/ from the intranet works without problems.
my nginx config file:
upstream app_server {
server unix:/home/myname/APP-Server/gunicorn/gunicorn.sock fail_timeout=0;
}
server {
listen 80;
# add here the ip address of your server
# or a domain pointing to that ip (like example.com or www.example.com)
server_name 123.456.789.1;
keepalive_timeout 5;
client_max_body_size 4G;
access_log /home/myname/APP-Server/logs/nginx-access.log;
error_log /home/myname/APP-Server/logs/nginx-error.log;
location /static/ {
alias /home/myname/APP-Server/static-root/;
}
# checks for static file, if not found proxy to app
location / {
try_files $uri #proxy_to_app;
}
location #proxy_to_app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
}
If it's relevant: The backend is a django app with a gunicorn server. Do I have to consider anything about the redirect from https to http? I have no control over the base domain.
If I understand correctly, you want to remove the first part of the URI. There are multiple ways you can do that, but the easiest is probably with the alias directive, which will remove the portion of the URI that matches the current location block:
location /foo/ {
alias /home/myname/APP-Server/static-root/; # It doesn't really matter what you put here, since you're proxying everything.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
If your Nginx server is running on foobar.example and you request http://foobar.example/foo/bar, the upstream server will see a request for http://foobar.example/bar.
The alias directive can be a bit buggy/unintuitive, so it's best to keep your location directive top-level (not nested within other location blocks) and as simple as possible.
If instead you want to add a prefix to the URI, you can do that within the proxy_pass directive itself:
location #proxy_to_app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server/foo$uri$is_args$args;
}
If your Nginx server is running on foobar.example and you request http://foobar.example/bar, the upstream server will see a request for http://foobar.example/foo/bar
Try this:
server {
...
location #proxy_to_app {
...
proxy_pass http://app_server/; # note the trailing slash
}
}
Explanation
As per the nginx docs:
If the proxy_pass directive is specified with a URI, then when a request is passed to the server, the part of a normalized request URI matching the location is replaced by a URI specified in the directive.
Since / location matches anything, then everything will be replaced by / (the trailing slash in proxy_pass) before being proxied to the upstream.
The way I handle this is with a rewrite rule:
location /yoursub {
rewrite /yoursub(.*) $1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
}
The rewrite will convert your url from /yoursub/path/to/view to /path/to/view for your app server.
I have a situation here with my Nginx reverse proxy configuration. My distribution is Ubuntu 14.04
I have a domain, let's call it foo.bar.net, and I want the /grafana endpoint to redirect to my grafana server (localhost:3000), the /sentry endpoint to redirect to my sentry server (localhost:9000) and finally, the /private endpoint to redirect to my django server (localhost:8001). I am using gunicorn for the tuneling between django and nginx.
Here is what I tried :
server {
# listen on port 80
listen 80 default_server;
# for requests to these domains
server_name foo.bar.net;
location /sentry {
# keep logs in these files
access_log /var/log/nginx/sentry.access.log;
error_log /var/log/nginx/sentry.error.log;
# You need this to allow users to upload large files
# See http://wiki.nginx.org/HttpCoreModule#client_max_body_size
# I'm not sure where it goes, so I put it in twice. It works.
client_max_body_size 0;
proxy_pass http://localhost:9000;
proxy_redirect off;
proxy_read_timeout 5m;
allow 0.0.0.0;
# make sure these HTTP headers are set properly
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /grafana {
proxy_pass http://localhost:3000;
proxy_redirect off;
proxy_read_timeout 5m;
allow 0.0.0.0;
# make sure these HTTP headers are set properly
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /private {
proxy_pass http://127.0.0.1:8001;
}
location /private/static/ {
autoindex on;
alias /home/user/folder/private/static/;
}
}
The server won't even start correctly, the config is not loading.
I would also like the / path to redirect to the private endpoint if possible.
Additionally, I am not even sure where to put this configuration (sites-available/??)
Can anyone help me with that ?
Thanks a lot,
There are some missing semicolons and other syntax errors. Look at main nginx error log for details and fix them one by one.
Where to put that config file depends on your distribution. For some of them it should be sites-available directory and symlink to that file inside sites-enabled directory for quick enabling and disabling sites, if you don't have sites-available and sites enabled directory, you should put it into conf.d dir in your distribution.
I have an nginx proxy_pass setup to pass every request on /api through to a backend Tomcat REST service. This service in some cases returns a Location header which varies according to the type of request, e.g., Location: http://foo.bar/baz/api/search/1234567 -- the baz part is due to it being hosted on Tomcat.
My current configuration rewrites the foo.bar host name correctly, but leaves the baz part intact. I'd like to strip this, but the proxy_pass options seem to be limited to clearing or setting a new value for the header.
Is there a way to modify headers dynamically before being passed on to the client, using a regex substitute, for instance? This is my nginx configuration:
location /api {
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_max_temp_file_size 0;
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;
proxy_redirect off;
proxy_pass http://foo.bar:8080/baz/api;
}
You may be able to use regexp to modify it but a better way is to use a proxy redirect:
proxy_redirect http://foo.bar/baz/ /;
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_redirect
Any Location headers for foo.bar/baz/ will go to /
If you just want to redirect /baz/api, that'll work too.
If any redirects are also adding the port, you'll need to add http://foo.bar:8080/baz/ as well (separate redirect).
Hope this helps!
I have a Ubuntu 13.04 virual machine with nginx frontend server and apache backend
serving a django project. Apache itself seems to work fine when operating separately
from nginx(and vice versa). But it looks like requests are not passed by nginx to
Apache when they work together.
After typing in my_host_name.com in the browser i get nginx "Welcome....!" page,
but it should be an apache-rendered page instead.
UPD: the "Welcome..." page appears only on first load, after the browser(chrome) is restarted(caching?), otherwise it returns just an empty page ("This webpage is not available .......... Error code: ERR_CONNECTION_RESET "). I get the same error page immediatly when accessing _my_domain_name.com_ from the host OS. I restart both servers(just in case) after each configuration change.
Typing in my_domain_name.com:8000 returns a correct apache response(static files
excluded)
After a day of googling still can't find what's wrong.
My servers' settings are:
File: /etc/nginx/proxy_params
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
File: /etc/nginx/sites-available/my_domain_name
server {
listen 80;
server_name my_domain_name.com;
location / {
access_log /var/log/nginx/localhost.access.log;
proxy_pass http://127.0.0.1:8000;
include /etc/nginx/proxy_settings;
}
location /static/ {
root /path/to/my/project/root;
}
location /media/{
root /path/to/my/project/root;
}
}
File: /etc/apache2/sites-available/my_domain_name.conf
<VirtualHost *:8000>
WSGIScriptAlias / /path/to/my/project/root/django.wsgi
ServerName my_domain_name.com
<Directory /path/to/my/project/root>
Order allow,deny
Allow from all
</Directory>
LogLevel warn
CustomLog /var/log/apache2/access.log combined
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 192.168.137.10 127.0.0.1
</VirtualHost>
File: /etc/apache2/ports.conf
NameVirtualHost *:8000
Listen 8000
File: /etc/hosts
192.168.137.10 my_domain_name.com
127.0.0.1 my_domain_name.com
Thanks!
I was having a similar issue with my Nginx setup with my Apache back end, specifically when Apache was issuing a redirect for:
/some-location => /some-location/
Nginx was running on port 80, and my back end Apache on port 8000. and port 8000 was being passed onto the client in the 301 redirect.
It took a bit of playing, but I was able to get it to work. Here is what I had to do:
location / {
proxy_pass http://127.0.0.1:8000;
proxy_redirect default;
proxy_redirect http://$host:8000/ http:/$host/;
... etc ..
}
Both Nginx and Apache virtual servers are using the same hostname (i.e. mydomain.com)
I'm trying to test my Django app locally using SSL. I have a view with the #login_required decorator. So when I hit /locker, I get redirected to /locker/login?next=/locker. This works fine with http.
However, whenever I use https, the redirect somehow drops the secure connection, so I get something like https://cumulus.dev/locker -> http://cumulus.dev/locker/login?next=/locker
If I go directly to https://cumulus.dev/locker/login?next=locker the page opens fine over a secure connection. But once I enter the username and password, I go back to http://cumulus.dev/locker.
I'm using Nginx to handle the SSL, which then talks to runserver. My nginx config is
upstream app_server_djangoapp {
server localhost:8000 fail_timeout=0;
}
server {
listen 80;
server_name cumulus.dev;
access_log /var/log/nginx/cumulus-dev-access.log;
error_log /var/log/nginx/cumulus-dev-error.log info;
keepalive_timeout 5;
# path for static files
root /home/gaurav/www/Cumulus/cumulus_lightbox/static;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
if (!-f $request_filename) {
proxy_pass http://app_server_djangoapp;
break;
}
}
}
server {
listen 443;
server_name cumulus.dev;
ssl on;
ssl_certificate /etc/ssl/cacert-cumulus.pem;
ssl_certificate_key /etc/ssl/privkey.pem;
access_log /var/log/nginx/cumulus-dev-access.log;
error_log /var/log/nginx/cumulus-dev-error.log info;
keepalive_timeout 5;
# path for static files
root /home/gaurav/www/Cumulus/cumulus_lightbox/static;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header Host $http_host;
proxy_redirect off;
if (!-f $request_filename) {
proxy_pass http://app_server_djangoapp;
break;
}
}
}
Django is running on plain HTTP only behind the proxy, so it will always use that to construct absolute URLs (such as redirects), unless you configure it how to see that the proxied request was originally made over HTTPS.
As of Django 1.4, you can do this using the SECURE_PROXY_SSL_HEADER setting. When Django sees the configured header, it will treat the request as HTTPS instead of HTTP: request.is_secure() will return true, https:// URLs will be generated, and so on.
However, note the security warnings in the documentation: you must ensure that the proxy replaces or strips the trusted header from all incoming client requests, both HTTP and HTTPS. Your nginx configuration above does not do that with X-Forwarded-Ssl, making it spoofable.
A conventional solution to this is to set X-Forwarded-Protocol to http or https, as appropriate, in each of your proxy configurations. Then, you can configure Django to look for it using:
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTOCOL', 'https')