Nginx serving files from non-domain url? - nginx

Is it possible for me to have an nginx server's domain to contain slashes? For example, for the server's root url location to be https://example.com/apps/app1?
I have a server whose files need to be served from /opt/production/app1/public. My current nginx.conf configuration, which doesn't work, contains:
location /apps/app1 {
root /opt/production/app1/public;
}
But obviously, this doesn't work because my files aren't at /opt/production/app1/public/apps/app1. I would like for nginx to consider https://example.com/app/apps1 to be my domain, so that my nginx.conf can access content as so:
location / {
root /opt/production/app1/public;
}
Is this at all possible? If not (which I suspect is the case), is there a way to work around this w/o changing the url schema?

If I understand your question correctly, you can try an alias directive for /apps/app1/ location:
location /apps/app1/ {
alias /opt/production/app1/public/;
}

Related

Nginx uri rewriting per domain

I have few domains pointing to the same server, for example:
server_name www.domain1.dev www.domain2.dev www.domain3.dev
Most of the configurations are the same, and they are pointing at the same php file, but i have a different assets folder for each domain:
/www.domain1.dev/assets/
/www.domain2.dev/assets/
/www.domain3.dev/assets/
that's why i want to rewrite requests like http://www.domain1.dev/assets/* into http://www.domain1.dev/www.domain1.dev/assets/*
Was trying to play with location - return, but didn't find how to get current domain name.
The currently requested domain name can be in $host or $http_host. See this document for the differences.
For example:
location ^~ /assets {
root /path/to/root/$host;
}
Or:
location ^~ /assets {
return 301 /$host$request_uri;
}
An alternative approach would be to separate your domain names into separate server blocks and use an include statement to pull in the common content.

NGINX multiple server_name, but have robots.txt file for each server_name?

I have to create a server_name as a listener for origin pulls by my CDN.
The CDN wants to pull from origin.mydomain.com
I already have 100s of lines of code under www.mydomain.com that showcases all the rewrites, rules and such, and I need to use all this code again.
My easy solution would be to have
server_name www.mydomain.com origin.mydomain.com
To easily have NGINX listen for the requests to the "origin" subdomain.
My fear is that google discovers the subdomain and starts crawling it. I'd like to block google from the "origin" subdomain somehow. Since declaring multiple server_name, I am not sure I can just place robots.txt file somewhere, since using same root folder as live site.
Is there an easy way to do this?
All feedback appreciated.
Cheers
Ryan
Use two server blocks and use the include directive to pull in the common code. For example:
server {
server_name www.mydomain.com;
include /path/to/common/config;
location = /robots.txt {
root /path/to/friendly/dir;
}
}
server {
server_name origin.mydomain.com;
include /path/to/common/config;
location = /robots.txt {
root /path/to/unfriendly/dir;
}
}
So you have two robot.txt files in different directories - or use rewrite ... last to map the URI to different local files.

Wordpress & Nginx with Docker: Static files not loaded

I'm using Docker to serve my simple WordPress website. A nginx container and a wordpress container. Simple setup:
upstream wordpress_english {
server wordpress_en:80;
}
server {
listen 80;
server_name my_domain.com www.my_domain.com;
location / {
proxy_pass http://wordpress_english;
}
}
Problem: Static files (css, js and images) are not loaded.
The output from the browser console shows a 404:
http://wordpress_english/wp-content/themes/twentyfifteen/genericons/genericons.css?ver=3.2
Its easy to spot the problem: The browser looks for the static files at wordpress_english (the nginx upstream name), instead of my_domain.com
How can I fix this problem?
This is not a nginx problem, but a WordPress problem.
Solution:
In wp-config.php, add the following two lines:
define('WP_HOME','http://my_domain.com');
define('WP_SITEURL','http://my_domain.com');
During the WordPress installation, WordPress automatically sets WP_HOME to nginx upstream name. The above solution overwrites the default setting.
Seems to be an issue in your nginx config file.
When declaring your server my_domain you provide location / with proxy_pass wordpress_english. I don't know a lot on nginx, but I don't see any declaration of path in your server my_domain and is root is linked to wordpress_english. Seems normal that he is looking for files in wordpress_english and not in you server. (In fact, I guess he is looking in your server but your server tells to look in wordpress).
Not sure about it cause I don't know well nginx and proxy_pass functions.

With nginx proxy/rewrite can I keep the original URL in the browser's Location field?

Using nginx.conf features like proxy-pass/rewrite, can I keep the original URL in the browser's Location field?
I have several PlayFramework apps running on different ports (9001, 9002, ...) with proxy forwarding set up via nginx.conf. People browse to them as:
http://domain.name/App1/
http://domain.name/App2/
etc.
My nginx.conf entries look like this:
location /App1/ {
proxy_pass http://localhost:9001/;
rewrite ^/App1/(.*) http://domain.name:9001/$1;
}
If I ask for http://domain.name/App1/, what I see in the browser's Location field is http://domain.name:9001. What I wish I saw was http://domain.name/App1/, that is, I want the name App1 to remain in the URI, and I'd rather not expose the port number.
Let's say App1 has a link /location/ABC. When I click on it I see http://domain.name:9001/location/ABC when I wish I saw http://domain.name/App1/location/ABC.
Can I achieve this with nginx.conf?
P.S. I put http://domain.name explicitly in the rewrite rule because without it I was getting localhost in the browser, and my browser's localhost is not the same as the server's.
Rewrites issue redirects for browser.
If you just want to mount several locations from upstreams - you do not need rewrites, just use:
location /App1/ {
proxy_pass http://localhost:9001/;
}
But apps should use relative links or account for their absolute location.
For more complex url manipulation you can use break-rewrites:
location /App1/ {
rewrite ^/App1/(.*) /$1 break;
proxy_pass http://localhost:9001;
}

Nginx match location for root path and all other paths separately

I am running Play framework server behind nginx server. At the root path, I am serving static website and all other paths should be redirected to the Play server. I have the following default.conf file in /etc/nginx/conf.d (The system is RHEL 6.7)
# to match the root path only to serve static website
location = / {
root /usr/share/nginx/html;
index index.html index.htm;
# try_files $uri $uri.html $uri/ /index.html;
}
# to match the cms login page
location /cms/ {
proxy_pass http://localhost:9000/;
}
# to match all the requests from the cms
location / {
proxy_pass http://localhost:9000/;
}
However, this configuration doesn't match the root path request. It gives 404 error. However, if I remove the third location rule, then it serves the static page at the root path.
Also, I noticed that first time I tried this, it worked. But now, it's not working any more. Please help.
The result you are getting is most likely due to the 2nd and 3rd location blocks not having "index" directives set. Except for well understood specific reasons, such as overriding the default index file type(s), the "index" should always be set at least within the server context or, preferably, within the http context. Similarly, the "root" directive should be set in the server context.
With your config, when a request hits the 3rd location block, there is no information your what to do with it. Actually, the 2nd block should not be needed from what you have described.
Also, as you are proxying to what appears to be another webserver, you need to ensure that this has the equivalent of "index" and "root" set.
Not sure exactly how the backend you are using works with respect to these. If not configurable there, then you must ensure that that every request hitting it has the URI spelt out fully.
To start with, depending on how exactly things are set up on your server, I will move the "index" and "root" directives up to the "server" level

Resources