nginx- duplicate default server error - nginx

In my error log i get
[emerg] 10619#0: a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/mysite.com:4
on Line 4 I have:
server_name mysite.com www.mysite.com;
Any suggestions?

You likely have other files (such as the default configuration) located in /etc/nginx/sites-enabled that needs to be removed.
This issue is caused by a repeat of the default_server parameter supplied to one or more listen directives in your files. You'll likely find this conflicting directive reads something similar to:
listen 80 default_server;
As the nginx core module documentation for listen states:
The default_server parameter, if present, will cause the server to become the default server for the specified address:port pair. If none of the directives have the default_server parameter then the first server with the address:port pair will be the default server for this pair.
This means that there must be another file or server block defined in your configuration with default_server set for port 80. nginx is encountering that first before your mysite.com file so try removing or adjusting that other configuration.
If you are struggling to find where these directives and parameters are set, try a search like so:
grep -R default_server /etc/nginx

OS Debian 10 + nginx.
In my case, i unlinked the "default" page as:
cd/etc/nginx/sites-enabled
unlink default
service nginx restart

Execute this at the terminal to see conflicting configurations listening to the same port:
grep -R default_server /etc/nginx

If you're on Digital Ocean this means you need to go to /etc/nginx/sites-enabled/ and then REMOVE using rm -R digitalocean and default
It fixed it for me!
Pic of Console on Windows 10 using Bitvise

In my case, commenting out the wildcard directive on include in the /etc/nginx/nginx.conf worked
#include /etc/nginx/sites-enabled/*;
include /etc/nginx/sites-enabled/abcdef.com;
PS: as per the comments above, this could be a solution if there is just one configuration (either default or your custom one)

In my case junk files from editor caused the problem.
I had a config as below:
#...
http {
# ...
include ../sites/*;
}
In the ../sites directory initially I had a default.config file.
However, by mistake I saved duplicate files as default.config.save and default.config.save.1.
Removing them resolved the issue.

If davidjb's answer does not show multiple default_server lines, check for multiple include directives.
It is possible you accidentally included your default (or another site) twice.

Related

rewrite is not working as desired for redirect URL in NGINX

I have an Nginx problem and after reading a lot and trying multiple combinations, I do not find the solutions to my problem.
I have a Jira server behind a reverse proxy using Nginx. My problem is that I want to have jira.mydomain.com as the default url but when using support.mydomain.com I want it to redirect to https://jira.mydomain.com/servicedesk/customer/portal/1 because is where the Service Desk. This is what I do not make.
The result that I have now is that both jira.mydomain.com and support.mydomain.com go to the same place which probably is the normal behavior and I do not know how to configure it but if anyone can help would be very appreciated.
Thanks to all of you and the hivemind.
This is what I have right now
/etc/nginx/conf.d/default.conf
upstream jira {
server jira_ip_adress:8081;
}
server {
server_name jira.mydomain.com;
server_name support.mydomain.com;
rewrite ^/support.mydomain.com https://jira.mydomain.com/servicedesk/customer/portal/1;
[...]
location / {
proxy_pass http://jira;
[...]
}
Nginx uses the server_name directive to match the domain name part of a URL. You need to use two server blocks, one for each of the domain names.
For example:
server {
server_name support.mydomain.com;
return 301 https://jira.mydomain.com/servicedesk/customer/portal/1;
}
server {
server_name jira.mydomain.com;
...
}
Obviously, if these are https services, you will need to add the appropriate listen statements to both server blocks.
Use nginx -T (uppercase T) to test the configuration file and view the entire configuration across all included files.
Many many thanks. I tried this yesterday but I had the next error when using nginx -T
nginx: [emerg] unexpected "E" in /etc/nginx/conf.d/default.conf:183
nginx: configuration file /etc/nginx/nginx.conf test failed
I have tried again after your help, and you spotted me in the right direction because today have been able to know what the error was telling to me and fixed.
So know, with your suggestion, is working like a charm.
Thanks a lot!

Nginx server_name regex match not setting passenger_app_env

Nginx: Built with passenger-install-nignx-module
Passenger Version: 5.0.28
OS: Ubuntu 14.04
I have symlinked each of my apps into their own set of environment folders:
/Repository
/development.manager
/app
...
/test.manager
/staging.manager
...
Where the actual folders is at another location on my HDD. All of these folders are symlinks pointing to that one folder.
The problem is that Nginx doesn't seem to be setting the passenger environment variable properly. Checking the logs it throws an app error that doesn't make sense (and the nginx config is the only thing that's changed since things broke). Also, the error page showing states:
Because you are running this web application in staging or production
mode, the details of the error have been omitted from this web page
for security reasons.
Which means that it's not using the development environment even though the root directory in the logs shows development.manager. This is when I access through the url: http://manager-development/.
Here's the relevant excerpt from my nginx sites-enabled configuration:
server {
listen 80;
server_name ~^manager-(?<environment>development|test)$;
passenger_app_env $environment;
passenger_ruby /home/vagrant/.rvm/gems/ruby-2.3.1#manager/wrappers/ruby;
passenger_enabled on;
root /home/vagrant/apps/$environment.manager/public;
client_max_body_size 30M;
}
I have a feeling the solution might be a combination of an answer I provided here as well as a possibly misconfigured nginx block.
EDIT: I explicitly raised an error in my rails app that output the environment as a string and it's literally "$environment"...
I've given up on this approach as it seems variables aren't interpreted by nginx when used in certain places. I'm now using a custom Bash/Ruby script to iterate over my environments/app names and generate the configuration blocks.

Nginx server names priority

I have two server sections for nginx in different files.
The first one:
server {
server_name _;
...
}
The second one:
server {
server_name ~someRegex;
...
}
I have some constraints - I can't change the first server section (i.e. I can't edit first file)
Documentation says the following about server names priority:
exact name
longest wildcard name starting with an asterisk, e.g. “*.example.org”
longest wildcard name ending with an asterisk, e.g. “mail.*”
first matching regular expression (in order of appearance in a configuration file)
As I understand server_name _ is used as catch-all server.
So when I have request from host matched someRegex request is handled by first server section. Is there a way to handle these request by second server section?
Not quite.
_ simply renders the server_name invalid. See this document.
What makes a server block the default is either being defined first for a given port or being defined with the listen ... default_server modifier. See this document.
So your configuration will work as you expect, assuming that your regex is valid and that the second server block has indeed been installed by nginx. Check your error log after reloading nginx and/or test the configuration using
nginx -t

How do I add new site/server_name in nginx?

I'm just starting to explore nginx on my ubuntu 10.04. I installed nginx and I'm able to get the "Welcome to Nginx" page on localhost. However I'm not able to add a new server_name.
Even when I make the changes in site-available/default. I also tried reloading/restarting nginx, but nothing works.
To build on mark's answer, Debian/Ubuntu distros default configuration file has an include /etc/nginx/sites-enabled/*; directive with site configuration file stored in /etc/nginx/sites-available/, a default site is usually included in that dir.
For examples beyond the default config, follow nginx beginner's guide or see wiki.nginx.org for more details.
After creating a new configuration in sites-available, create a symbolic link with this command, assuming that your conf file is named "myapp" and nginx is at /etc/nginx (could also be at /usr/local/etc/nginx):
ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/myapp
By the way, you could always create your conf file directly in sites-enabled but the recommended way above allows you to "enable and disable" sites on the server very quickly without actually moving/deleting your conf files.
P.S: Don't trust the tutorials: check your configuration!
P.P.S: You can use the command nginx -t to test your sites conf and nginx -s reload to reload the conf.
The usual way to add another site in Nginx in Ubuntu is to copy the sites-available/default file to sites-available/new-site-name, then create a symbolic link in sites-enabled to sites-available/new-site-name.
In the new configuration file, you need to edit the listen and server directives. Use listen to specify the IP address and port, and the server directive to specify the hostnames. For more details, see HttpCoremodule.

nginx - client_max_body_size has no effect

nginx keeps saying client intended to send too large body. Googling and RTM pointed me to client_max_body_size. I set it to 200m in the nginx.conf as well as in the vhost conf, restarted Nginx a couple of times but I'm still getting the error message.
Did I overlook something? The backend is php-fpm (max_post_size and max_upload_file_size are set accordingly).
Following nginx documentation, you can set client_max_body_size 20m ( or any value you need ) in the following context:
context: http, server, location
NGINX large uploads are successfully working on hosted WordPress sites, finally (as per suggestions from nembleton & rjha94)
I thought it might be helpful for someone, if I added a little clarification to their suggestions. For starters, please be certain you have included your increased upload directive in ALL THREE separate definition blocks (server, location & http). Each should have a separate line entry. The result will like something like this (where the ... reflects other lines in the definition block):
http {
...
client_max_body_size 200M;
}
(in my ISPconfig 3 setup, this block is in the /etc/nginx/nginx.conf file)
server {
...
client_max_body_size 200M;
}
location / {
...
client_max_body_size 200M;
}
(in my ISPconfig 3 setup, these blocks are in the /etc/nginx/conf.d/default.conf file)
Also, make certain that your server's php.ini file is consistent with these NGINX settings. In my case, I changed the setting in php.ini's File_Uploads section to read:
upload_max_filesize = 200M
Note: if you are managing an ISPconfig 3 setup (my setup is on CentOS 6.3, as per The Perfect Server), you will need to manage these entries in several separate files. If your configuration is similar to one in the step-by-step setup, the NGINX conf files you need to modify are located here:
/etc/nginx/nginx.conf
/etc/nginx/conf.d/default.conf
My php.ini file was located here:
/etc/php.ini
I continued to overlook the http {} block in the nginx.conf file. Apparently, overlooking this had the effect of limiting uploading to the 1M default limit. After making the associated changes, you will also want to be sure to restart your NGINX and PHP FastCGI Process Manager (PHP-FPM) services. On the above configuration, I use the following commands:
/etc/init.d/nginx restart
/etc/init.d/php-fpm restart
As of March 2016, I ran into this issue trying to POST json over https (from python requests, not that it matters).
The trick is to put "client_max_body_size 200M;" in at least two places http {} and server {}:
1. the http directory
Typically in /etc/nginx/nginx.conf
2. the server directory in your vhost.
For Debian/Ubuntu users who installed via apt-get (and other distro package managers which install nginx with vhosts by default), thats /etc/nginx/sites-available/mysite.com, for those who do not have vhosts, it's probably your nginx.conf or in the same directory as it.
3. the location / directory in the same place as 2.
You can be more specific than /, but if its not working at all, i'd recommend applying this to / and then once its working be more specific.
Remember - if you have SSL, that will require you to set the above for the SSL server and location too, wherever that may be (ideally the same as 2.). I found that if your client tries to upload on http, and you expect them to get 301'd to https, nginx will actually drop the connection before the redirect due to the file being too large for the http server, so it has to be in both.
Recent comments suggest that there is an issue with this on SSL with newer nginx versions, but i'm on 1.4.6 and everything is good :)
You need to apply following changes:
Update php.ini (Find right ini file from phpinfo();) and increase post_max_size and upload_max_filesize to size you want:
sed -i "s/post_max_size =.*/post_max_size = 200M/g" /etc/php5/fpm/php.ini
sed -i "s/upload_max_filesize =.*/upload_max_filesize = 200M/g" /etc/php5/fpm/php.ini```
Update NginX settings for your website and add client_max_body_size value in your location, http, or server context.
location / {
client_max_body_size 200m;
...
}
Restart NginX and PHP-FPM:
service nginx restart
service php5-fpm restart
NOTE: Sometime (In my case almost every time) you need to kill php-fpm process if it didn't refresh by service command properly. To do that you can get list of processes (ps -elf | grep php-fpm) and kill one by one (kill -9 12345) or use following command to do it for you:
ps -elf | grep php-fpm | grep -v grep | awk '{ print $4 }' | xargs kill -9
Please see if you are setting client_max_body_size directive inside http {} block and not inside location {} block. I have set it inside http{} block and it works
Someone correct me if this is bad, but I like to lock everything down as much as possible, and if you've only got one target for uploads (as it usually the case), then just target your changes to that one file. This works for me on the Ubuntu nginx-extras mainline 1.7+ package:
location = /upload.php {
client_max_body_size 102M;
fastcgi_param PHP_VALUE "upload_max_filesize=102M \n post_max_size=102M";
(...)
}
I had a similar problem recently and found out, that client_max_body_size 0; can solve such an issue. This will set client_max_body_size to no limit. But the best practice is to improve your code, so there is no need to increase this limit.
I meet the same problem, but I found it nothing to do with nginx. I am using nodejs as backend server, use nginx as a reverse proxy, 413 code is triggered by node server. node use koa parse the body. koa limit the urlencoded length.
formLimit: limit of the urlencoded body. If the body ends up being larger than this limit, a 413 error code is returned. Default is 56kb.
set formLimit to bigger can solve this problem.
Assuming you have already set the client_max_body_size and various PHP settings (upload_max_filesize / post_max_size , etc) in the other answers, then restarted or reloaded NGINX and PHP without any result, run this...
nginx -T
This will give you any unresolved errors in your NGINX configs. In my case, I struggled with the 413 error for a whole day before I realized there were some other unresolved SSL errors in the NGINX config (wrong pathing for certs) that needed to be corrected. Once I fixed the unresolved issues I got from 'nginx -T', reloaded NGINX, and EUREKA!! That fixed it.
I'm setting up a dev server to play with that mirrors our outdated live one, I used The Perfect Server - Ubuntu 14.04 (nginx, BIND, MySQL, PHP, Postfix, Dovecot and ISPConfig 3)
After experiencing the same issue, I came across this post and nothing was working. I changed the value in every recommended file (nginx.conf, ispconfig.vhost, /sites-available/default, etc.)
Finally, changing client_max_body_size in my /etc/nginx/sites-available/apps.vhost and restarting nginx is what did the trick. Hopefully it helps someone else.
In case you are using Kubernetes, add the following annotations to your Ingress:
annotations:
nginx.ingress.kubernetes.io/client-max-body-size: "5m"
nginx.ingress.kubernetes.io/client-body-buffer-size: "8k"
nginx.ingress.kubernetes.io/proxy-body-size: "5m"
nginx.ingress.kubernetes.io/proxy-buffer-size: "8k"
Confirm the changes were applied:
kubectl -n <namespace> describe ingress <ingress-name>
References:
Client Body Buffer Size
Custom max body size
Had the same issue that the client_max_body_size directive was ignored.
My silly error was, that I put a file inside /etc/nginx/conf.d which did not end with .conf. Nginx will not load these by default.
If you tried the above options and no success, also you're using IIS (iisnode) to host your node app, putting this code on web.config resolved the problem for me:
Here is the reference: https://www.inflectra.com/support/knowledgebase/kb306.aspx
Also, you can chagne the length allowed because now I think its 2GB. Modify it by your needs.
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="2147483648" />
</requestFiltering>
</security>
The following config worked for me. Notice I only set client_max_body_size 50M; once, contrary to what others are saying...
File: /etc/nginx/conf.d/sites.conf
server {
listen 80 default_server;
server_name portal.myserver.com;
return 301 https://$host$request_uri;
}
server {
resolver 127.0.0.11 valid=30s;
listen 443 ssl default_server;
listen [::]:443 ssl default_server;
ssl_certificate /secret/portal.myserver.com.crt;
ssl_certificate_key /secret/portal.myserver.com.pem;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
server_name portal.myserver.com;
client_max_body_size 50M;
location /fileserver/ {
set $upstream http://fileserver:6976;
proxy_pass $upstream;
}
}
If you are using windows version nginx, you can try to kill all nginx process and restart it to see.
I encountered same issue In my environment, but resolved it with this solution.

Resources