I have a server with Nginx.
I would like to set up two sites:
backend.mysite.com
staging.backend.mysite.com
Here is my server blocks config:
www.backend.mysite.com:
server {
listen 80;
server_name backend.mysite.com www.backend.mysite.com;
location / {
proxy_pass http://127.0.0.1:8800/;
}
}
server {
listen 8800;
server_name my.ip.address;
root /projects/backend/production/html;
index index.html;
location / {
try_files $uri $uri/ /index.html;
}
}
www.staging.backend.mysite.com:
server {
listen 80;
server_name staging.backend.mysite.com www.staging.backend.mysite.com;
location / {
proxy_pass http://127.0.0.1:8900/;
}
}
server {
listen 8900;
server_name my.ip.address;
root /projects/backend/staging/html;
index index.html;
location / {
try_files $uri $uri/ /index.html;
}
}
My problem is that backend.mysite.com is overriding staging.backend.mysite.com. How can I say to Nginx to never override if there is a sub subdomain on my adress?
UPDATE:
I've tried to add another domain (my_other_site.com) in my second config to check if it works:
server {
listen 80;
server_name my_other_site.com www.my_other_site.com staging.backend.mysite.com www.staging.backend.mysite.com;
location / {
proxy_pass http://127.0.0.1:8900/;
}
}
server {
listen 8900;
server_name my.ip.address;
root /projects/backend/staging/html;
index index.html;
location / {
try_files $uri $uri/ /index.html;
}
}
When I visit my_other_site.com it works well. The second site is reached as expected.
my_other_site.com, www.my_other_site.com, staging.backend.mysite.com and www.staging.backend.mysite.com have the same DNS A configuration, they are pointing on the same IP.
UPDATE 2:
When I disable www.backend.mysite.com server block, it works. The site staging.backend.mysite.com is working as expected. That mean that indeed the first block overrides the second one.
How can I tell the first server block to not take in account staging.backend.mysite.com? Is there a way to exclude a specific domain name?
Try to give for included config files same names as domain names, e.g.:
aa.domain.com --> aa.domain.com.nginx.conf
bb.domain.com --> bb.domain.com.nginx.conf
so nginx will include and catch in natural alphabetic order
I was running into the same experience, but eventually when I ran sudo nginx -T, it spat out:
nginx: [emerg] could not build server_names_hash, you should increase server_names_hash_bucket_size: 32
nginx: configuration file /etc/nginx/nginx.conf test failed
So, I edited nginx.conf and uncommented the relevant line:
# ...
server_names_hash_bucket_size: 64;
# ...
I picked 64 because that was what was in the file, commented out. Then I restarted and everything worked.
Then I cleared the cache in my browser.
Related
I am trying to implement something like that in the nginx conf:
subdomain
sub.domain.com -> Serve html
sub.domain.com/api -> proxy to port 3001
sub.domain.com/viewer -> serve another html
subdomain2
sub2.domain.com -> proxy to port 3000
The only route that doesn't work is the viewer, I get the html from the "location /". All other configurations work well.
I tried to move the viewer to the bottom then to the top and to the middle no matter what it doesn't work.
I use CentOS7. This is the configurations currently in the server:
events {
}
http {
server {
listen 80;
listen [::]:80;
server_name www.sub.domain.com subdomain.com;
location /viewer {
root /opt/viewer/;
try_files $uri /index.html;
index index.html;
}
location / {
root /opt/client-bo/;
try_files $uri /index.html;
index index.html;
}
location /api {
proxy_pass "http://localhost:3001";
}
}
server {
listen 80;
server_name www.sub2.domain.com sub2.domain.com;
listen [::]:80;
location / {
proxy_pass "http://localhost:3000";
}
}
}
Thanks!
If your viewer app located in the /opt/viewer directory and you want it to be available under the /viewer URI prefix, you should use root /opt; for the location /viewer { ... }. Check the difference between root and alias directives.
Next, the very last argument of the try_files directive is treated as the new URI to re-evaluate, so you /index.html being treated as the new URI going to be served with the location / { ... }. You should change that directive to
try_files $uri /viewer/index.html;
I am trying to implement something like that in the nginx conf:
subdomain
sub.domain.com -> Serve html
sub.domain.com/api -> proxy to port 3001
sub.domain.com/viewer -> serve another html
subdomain2
sub2.domain.com -> proxy to port 3000
The only route that doesn't work is the viewer, I get the html from the "location /". All other configurations work well.
I tried to move the viewer to the bottom then to the top and to the middle no matter what it doesn't work.
I use CentOS7. This is the configurations currently in the server:
events {
}
http {
server {
listen 80;
listen [::]:80;
server_name www.sub.domain.com subdomain.com;
location /viewer {
root /opt/viewer/;
try_files $uri /index.html;
index index.html;
}
location / {
root /opt/client-bo/;
try_files $uri /index.html;
index index.html;
}
location /api {
proxy_pass "http://localhost:3001";
}
}
server {
listen 80;
server_name www.sub2.domain.com sub2.domain.com;
listen [::]:80;
location / {
proxy_pass "http://localhost:3000";
}
}
}
Thanks!
If your viewer app located in the /opt/viewer directory and you want it to be available under the /viewer URI prefix, you should use root /opt; for the location /viewer { ... }. Check the difference between root and alias directives.
Next, the very last argument of the try_files directive is treated as the new URI to re-evaluate, so you /index.html being treated as the new URI going to be served with the location / { ... }. You should change that directive to
try_files $uri /viewer/index.html;
I have Nginx setup Flask based backend running on port 8080 with the below configuration
server {
listen 8080 default_server;
listen [::]:8080;
root /var/www/html;
server_name _;
location /static {
alias /var/www/html/static/;
}
location / {
try_files $uri #wsgi;
}
location #wsgi {
proxy_pass http://unix:/tmp/gunicorn.sock;
include proxy_params;
}
location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
access_log off;
log_not_found off;
expires max;
}
}
I have also setup a systemd service that uses gunicorn to run the flask app using: gunicorn --bind=unix:/tmp/gunicorn.sock --workers=4 start_backend:web_app
Now the above is working for Python Flask backend on port 8080, I also want to add Vue app on default port 80 as well.
Update
server {
listen 80 default_server;
listen [::]:80;
root /var/www/html/dist;
server_name _;
location /static {
alias /var/www/html/dist/static/;
}
location / {
root /var/www/html/dist;
try_files $uri $uri/ /index.html;
}
location /api {
root /var/www/html;
try_files $uri #wsgi;
}
location #wsgi {
proxy_pass http://unix:/tmp/gunicorn.sock;
include proxy_params;
}
Sounds like you need to add another server block to serve the frontend.
server {
listen 80 default_server;
listen [::]:80;
location / {
root /path/to/dist;
try_files $uri $uri/ /index.html;
}
}
I've based this code on this tutorial where /path/to/dist in the above example should be changed to the dist directory of the Vue.js front-end from your vue app.
If you have a read of the section Setting Up Nginx in this tutorial, you'll notice that they are serving the Flask application and the Vue.js fronted at different URLs in the same server block:
server {
listen 80;
server_name 123.45.67.89;
location /api {
include uwsgi_params;
uwsgi_pass unix:/home/survey/flask-vuejs-survey/backend/surveyapi.sock;
}
location / {
root /home/survey/flask-vuejs-survey/frontend/survey-spa/dist;
try_files $uri $uri/ /index.html;
}
If this app will be facing the internet then this is probably a better way to do things, as port 8080 outgoing may be blocked by your users' internet provider. With the second configuration everything is served through port 80.
You may have to adjust your vue.js app slightly to make it look for the API at /api (or something) leaving / free to serve the frontend.
I have an IP address of my server that I want to put my website Frontend and Backend admin. The site1 part is simply should be at "http://IP/" and and site2 should be in "http://IP/admin" .
I have installed Nginx in server and my websites files are inside: Lets say its like :
site1: /var/www/html/site1/index.html
site2: /var/www/html/site2/index.html
I created 2 files in /etc/nginx/site-available/ called "site1.conf" and "site2.conf" .
site1.conf:
server {
listen 80;
listen [::]:80;
root /var/www/html/site1;
index index.html index.htm;
server_name http://myIP;
location / {
try_files $uri $uri/ =404;
}
}
site2.conf:
server {
listen 80;
listen [::]:80;
server_name http://myIP;
location /admin {
autoindex on;
alias /var/www/html/site2;
try_files $uri $uri/ /index.html last;
index index.html;
}
}
Then I linked these 2 files into "/etc/nginx/site-enabled"
After restarting the Nginx, my "http://ip/" opens site1 "index.html" and works fine.
but "http://ip/admin/" gives 404 error instead of opening site2 "index.html"
http://IP/ and http://IP/admin both point to the same server, with the server_name "IP".
Your server contains at least two location blocks.
For example:
server {
listen 80;
listen [::]:80;
server_name 1.2.3.4;
root /var/www/html/site1;
index index.html index.htm;
location / {
try_files $uri $uri/ =404;
}
location /admin {
alias /var/www/html/site2;
...
}
}
The server name only contains the text of the IP address or the DNS name. See this document for more.
You can spread your configuration across as many files as you choose. See the include directive.
The nginx configuration is a file called nginx.conf and contains an include statement to source all of the files in the sites-available directory. The content of these files are contained within the http { ... }.
As I have already stated, your two services are one server { ... } block, as far as nginx is concerned. However, you can still create a server block file in sites-available that includes files from some other location. Just don't use sites-avalable or conf.d, as nginx is aready using those directory names.
For example:
In sites-available/mysites.conf:
server {
listen 80;
listen [::]:80;
server_name 1.2.3.4;
include /path/to/my/location/confs/*.conf;
}
And in /path/to/my/location/confs/site1.conf:
root /var/www/html/site1;
index index.html index.htm;
location / {
try_files $uri $uri/ =404;
}
And in /path/to/my/location/confs/site2.conf:
location /admin {
alias /var/www/html/site2;
...
}
I am not saying that this is a good way to organise your files, but with nginx, many things are possible.
I ham trying to make http://example.com serve http://example.com/home.html from /home/ubuntu/mysitedir/home.html.
I have the following conf file which successfully redirects everything to https, and proxies to uwsgi. The http->https redirection works fine, and the uwsgi proxy works, but http(s)://example.com/, http(s)://example.com/home.html, http(s)://example.com/index.html, and http(s)://example.com/index.htm are all 404
Any pointers as to what I can try?
Here is my conf file:
server {
listen 80;
server_name example.com;
return 301 https://$server_name$request_uri;
root /home/ubuntu/mysitedir/;
index home.html;
}
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/nginx/ssl/example_combined.crt;
ssl_certificate_key /etc/nginx/ssl/www.example.com.key;
root /home/ubuntu/mysitedir/;
index home.html;
location /images/ads {
alias /home/ubuntu/mysitedir/images/ads/;
}
location /images {
alias /home/ubuntu/mysitedir/images/;
}
location /static {
alias /home/ubuntu/mysitedir/static/;
}
location / {
alias /home/ubuntu/mysitedir/;
include uwsgi_params;
uwsgi_pass unix:/tmp/mysitedir.sock;
}
}
Thanks.
location / is the catch-all. You could try the try_files directive like this:
location #wsgisite {
include uwsgi_params;
uwsgi_pass unix:/tmp/mysitedir.sock;
}
location / {
index home.html;
try_files $uri $uri/ #wsgisite;
}
Any thing coming into the base location will first check to see if it is a file, or a directory with an index (home.html) file in it, and if not, then pass it on to the #wsgisite.
This should also make the other three location directives obselete, since nginx will be checking for the files first before passing it to the wsgi block.