I am using the following Nginx reverse proxy configuration.
server {
listen 80;
listen [::]:80;
server_name www.test.com;
access_log /var/log/nginx/www.test.com.access.log;
error_log /var/log/nginx/www.test.com.error.log warn;
location / {
proxy_pass http://12.23.45.78:8080;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
}
}
By adding the access_log and error_log parameters, it will log the access log.
Now I want to skip some logging, such as not logging favicon.ico and apple-touch-icon.png, so I added the following configuration.
location ~* ^/(?:favicon|apple-touch-icon) {
log_not_found off;
access_log off;
}
But here is the problem, when I do this, http://www.test.com/favicon.ico will not be accessed properly, it prompts "404 Not Found" error.
It seems to indicate that the reverse proxy host is taking over the favicon.ico access without forwarding it to upstream for processing, is this normal Nginx behavior please?
If this is normal behavior, how should I set not to log for a given resource?
Any help is appreciated in advance!
Every request ends up in some location (if not being finished before). Every location uses its own content handler. Unless you specify something explicitly via content handler declaration directive (examples include, bit not limited to proxy_pass, fastcgi_pass, uwsgi_pass, etc.), it will be a static content handler to serve the requested content from local filesystem. Check my ServerFault answers (1, 2) to find out some more details.
In some cases such a task can be solved using the map block, e.g.
map $uri $log {
~^/(?:favicon|apple-touch-icon) off;
default /var/log/nginx/access.log;
}
server {
...
access_log $log;
This approach can work when you need to implement lets say conditional basic auth (example). Unfortunately it won't work with the access_log directive - instead nginx will create the second log file named off for icon requests. So if you want every request to be passed to the 12.23.45.78 upstream, I don't see any other way but to duplicate content handler declaration for both locations. However every other used directive can be moved one level up, thus being inherited by both locations:
server {
listen 80;
listen [::]:80;
server_name www.test.com;
error_log /var/log/nginx/www.test.com.error.log warn;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
location / {
access_log /var/log/nginx/www.test.com.access.log;
proxy_pass http://12.23.45.78:8080;
}
location ~ ^/(?:fav|apple-touch-)icon {
access_log off;
proxy_pass http://12.23.45.78:8080;
}
}
On the other hand, nothing can stop you from serving those two files locally and not passing those requests anywhere. Just put them into some dedicated directory and use a location with a static content handler:
location ~ ^/(?:fav|apple-touch-)icon {
access_log off;
root /full/path/to/folder/with/icons;
}
Related
I'm in the unfortunate situation that I need to extend my react application with an iframe containing an external application.
My application is hosted by a nginx reverse proxy that handles /api and signalr communication.
Unfortunately it also handles the outbout iframe src url.
in this example my site is on the url https://example.com
The iframe src url is in this case "https://external-site.com/someapp/session?token=1234"
When i see the requests in the browser the url has changed to https://example.com/esternal-site.com/someapp/session?token=1234, which needless to say is not working out of the box.
I've been toying with the nginx configuration but has been unable to just pass the request through without modification.
The iframe/destination works as expected when running locally.
I've attempted with a few different configuations inspired by stackoverflow and medium etc. but they've all returned various error codes.
the server runs on port 80, but https is handled by ingress on azure.
This is what i have currently:
upstream bff_service {
server ${BFF_HOST}:${BFF_PORT};
keepalive 32;
keepalive_requests 1000;
keepalive_timeout 75s;
}
server {
listen 80;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
try_files $uri $uri/ /index.html;
add_header Set-Cookie "msal_client_id=${BFF_MSAL_CLIENT_ID};Path=/;Secure";
}
location /api {
proxy_read_timeout 300s;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host ${BFF_HOST};
proxy_set_header X-NginX-Proxy true;
proxy_pass ${BFF_PROTOCOL}://bff_service;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_redirect off;
}
location ^~ /external-site.com {
add_header Content-Security-Policy "frame-src 'self' https://external-site.com";
proxy_pass https://external-site.com/$request_uri;
}
}
I've also tried adding the lines below to the location:
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-NginX-Proxy true;
I'm looking for a configuration that allows me to embed an iframe with an external location. Perhaps even avoid nginx proxying it at all?
I have a Single Page Application running on a node server serving angular at www.xxx.com. This is currently working.
I am trying to server a second Node application named www.yyy.com however when I set up the NGINX server blocks it is defaulting to the NGINX welcome page.
www.xxx.com NGINX server block (Which is working fine):
server {
listen 80;
listen [::]:80;
server_name xxx.com.au www.xxx.com.au;
return 301 https://xxx.com.au$request_uri;
}
server {
listen 443;
server_name xxx.com.au www.xxx.com.au;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://127.0.0.1:3000/;
proxy_redirect off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_redirect off;
proxy_set_header X-Forwarded-Proto $scheme;
}
ssl on;
ssl_certificate /etc/letsencrypt/live/xxx.com.au/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/xxx.com.au/privkey.pem;
}
www.yyy.com Server block: (Currently only serving welcome page)
server {
listen 80;
server_name yyy.com www.yyy.com;
location /site {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true;
proxy_pass http://127.0.0.1:3002/;
proxy_redirect off;
}
}
I have all the DNS set up and the host names set up on my droplet as well. I am using Vultr running Ubuntu if that helps.
I have added both via symbolic link to Sites-available and the line is present in the conf file.
EDIT: As Henry pointed out I was server /site
location /site {
You're serving the app at /site and not /.
You can map different different config blocks to different URLs, so you could e.g. route /example to a different node server if you wanted.
Replacing location /site { with location / { as for your working block will serve your node application at the root. With no configuration for the root node nginx routes it to its default page.
I am playing around with Nginx and I successfully set up a simple (for now HTTP only) reverse proxy. As a newbie, I am wondering what would I need to modify to make this production ready. Which leads me to the following questions:
Is there a way to unify the proxy_set_header directive so that I don't need to repeat myself for every virtual host?
Am I missing any other important host header modifications than X-Forwarded-Proto, X-Url-Scheme, X-Forwarded-For and Host?
nginx.conf:
worker_processes 1;
events {
worker_connections 1024;
}
http {
sendfile on;
gzip on;
# skip log_format/access_log
server {
listen 80;
server_name server1.company.com;
location / {
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Url-Scheme $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_pass http://server1; # IP or FQDN would be better here
}
}
server {
listen 80;
server_name server2.company.com;
location / {
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Url-Scheme $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_pass http://server2; # IP or FQDN would be better here
}
}
}
Any feedback/point to a direction would be appreciated.
If you place all of your proxy_set_header statements in the http block, they will be inherited into the server blocks and then into the location blocks. The inheritance only happens into blocks without another proxy_set_header statement. See this document for details.
Alternatively, place common statements into a separate file and pull them into any part of your configuration by using an include directive. See this document for details.
Which headers you should set is dependent on your application. But this article discusses preventing certain headers from being passed to the proxied server, e.g.
proxy_set_header Accept-Encoding "";
And this article mitigates the HTTPoxy vulnerability with:
proxy_set_header Proxy "";
I have a Flask application served using gunicorn, and with NGINX on top of it. I want to use Basic Authentication (user/password) to protect all URL's starting with /admin, which is the back office, but still continue serving all other URLs with gunicorn without password.
Here is my current NGINX config:
server {
listen 80;
server_name example.com;
charset utf-8;
location / {
proxy_pass http://localhost:8000;
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 /admin {
auth_basic "Administrator Login";
auth_basic_user_file /home/app/.htpasswd;
# the following four directives are duplicated :(
proxy_pass http://localhost:8000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
If I don't duplicate the proxy_* directives in the second location block, then the URLs starting with /admin doesn't get forwarded to gunicorn and I get a 404.
Is there any way to avoid the configuration duplication? I tried location nesting but apparently in the end NGINX only "executes" a single location block.
The proxy_pass must be within the location block. However, there's no need to duplicate the proxy_set_header directives, they can be moved into the server block. So your mistake was simply the assumption that proxy_pass could live in the server block :-)
I currently have two WORDPRESS websites sitting behind an NGINX proxy cache:
htxtp://local.example.com
htxtp://local.example.org
I want to access a URL from the first site but serve it from the second site whilst not losing the URL structure of the first (to allow website2.com to see the website1.com cookies).
For example:
I want:
htxtp://local.example.com/somepage/
To proxy the page built at:
htxtp://local.example.org/somepage/
BUT I don't want the URL to BE htxtp://local.website2.com.
My NGINX config is as follows:
server {
listen 80;
server_name local.example.com;
access_log logs/local.example.com.access.log;
error_log logs/local.example.com.error.log;
location /somepage {
proxy_pass http://localhost:8080;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host local.example.org;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location / {
proxy_pass http://localhost:8080;
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host local.example.com;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Any suggestions? I am trying to work out where the actual redirect is happening.