Scenario / Questions

I have some experience using linux but none using nginx. I have been tasked with researching load-balancing options for an application server.

I have used apt-get to install nginx and all seems fine.

I have a couple of questions.

What is the difference between the sites-available folder and the conf.d folder. Both of those folders were INCLUDED in the default configuration setup for nginx. Tutorials use both. What are they for and what is the best practice?

What is the sites-enabled folder used for? How do I use it?

The default configuration references a www-data user? Do I have to create that user? How do I give that user optimal permissions for running nginx?

Find below all possible solutions or suggestions for the above questions..

Suggestion: 1

The sites-* folders are managed by nginx_ensite and nginx_dissite. For Apache httpd users who find this with a search, the equivalents is a2ensite/a2dissite.

The sites-available folder is for storing all of your vhost configurations, whether or not they’re currently enabled.

The sites-enabled folder contains symlinks to files in the sites-available folder. This allows you to selectively disable vhosts by removing the symlink.

conf.d does the job, but you have to move something out of the folder, delete it, or make changes to it when you need to disable something. The sites-* folder abstraction makes things a little more organized and allows you to manage them with separate support scripts.

(unless you’re like me, and one of many debian admins who just managed the symlinks directly, not knowing about the scripts…)

Suggestion: 2

I would like to add to the previous answers that the most important is not how you call the directories (though that is a very useful convention), but what you actually put in nginx.conf. Example configuration:

http {
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*.conf;
    include /etc/nginx/sites-enabled/my_own_conf;

The only directive used here is include, so there is no internal difference between e.g. conf.d/ and sites-enabled/.

From the documentation above:

Syntax:     include file | mask;
Default:    —
Context:    any

Includes another file, or files matching the specified mask, 
into configuration. Included files should consist of 
syntactically correct directives and blocks.

So, to answer the original question: there is no internal difference, and you may use them in the best way you can, remembering advice from the other answers. And please, don’t forget to choose the ‘right’ answer.

Suggestion: 3

Typically, the sites-enabled folder is used for virtual host definitions, while conf.d is used for global server configuration. If you’re supporting multiple web sites — i.e., virtual hosts — then each one gets its own file, so you can enable and disable them very easily by moving files in and out of sites-enabled (or creating and removing symlinks, which is probably a better idea).

Use conf.d for things like module loading, log files, and other things that are not specific to a single virtual host.

The default configuration references a www-data user? Do I have to
create that user?

You should have nginx running as a non-root user. This is in some cases named www-data, but you can name it anything you want.

How do I give that user optimal permissions for
running nginx?

I’m less certain of the answer to this question (I’m not running nginx at the moment), but if it’s anything like Apache the answer is that the www-data user only needs read permissions to any static files (and read+execute on directories) that you’re serving, or read/execute permissions on things like CGI scripts, and no permissions anywhere else.

Suggestion: 4

What’s Going On?

You must be using Debian or Ubuntu, since the evil sites-available / sites-enabled logic is not used by the upstream packaging of nginx from

In either case, both are implemented as a configuration convention with the help of the standard include directive in /etc/nginx/nginx.conf.

Here’s a snippet of /etc/nginx/nginx.conf from an official upstream package of nginx from

http {
    include /etc/nginx/conf.d/*.conf;

Here’s a snippet of /etc/nginx/nginx.conf from Debian/Ubuntu:

http {
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;

So, from the point of view of NGINX, the only difference would be that files from conf.d get to be processed sooner, and, as such, if you have configurations that silently conflict with each other, then those from conf.d may take precedence over those in sites-enabled.

Best Practice Is conf.d.

You should be using /etc/nginx/conf.d, as that’s a standard convention, and should work anywhere.

If you need to disable a site, simply rename the filename to no longer have a .conf suffix, very easy, straightforward and error-proof:

sudo mv -i /etc/nginx/conf.d/default.conf{,.off}

Or the opposite to enable a site:

sudo mv -i /etc/nginx/conf.d/{.disabled,}

Avoid sites-available & sites-enabled At All Costs.

I see absolutely no reason to be using sites-available / sites-enabled:

  • Some folks have mentioned nginx_ensite and nginx_dissite scripts — the names of these scripts are even worse than the rest of this debacle — but these scripts are also nowhere to be found — they’re absent from the nginx package even in Debian (and probably in Ubuntu, too), and not present in a package of their own, either, plus, do you really need a whole non-standard third-party script to simply move and/or link the files between the two directories?!

  • And if you’re not using the scripts (which is, in fact, a smart choice as per above), then there comes the issue of how do you manage the sites:

    • Do you create symbolic links from sites-available to sites-enabled?
    • Copy the files?
    • Move the files?
    • Edit the files in place in sites-enabled?

The above may seem like some minor issues to tackle, until several folks start managing the system, or until you make a quick decision, only to forget about it months or years down the line…

Which brings us to:

  • Is it safe to remove a file from sites-enabled? Is it soft link? A hard link? Or the only copy of the configuration? A prime example of configuration hell.

  • Which sites have been disabled? (With conf.d, just do an inversion search for files not ending with .conffind /etc/nginx/conf.d -not -name "*.conf", or use grep -v.)

Not only all of the above, but also note the specific include directive used by Debian/Ubuntu — /etc/nginx/sites-enabled/* — no filename suffix is specified for sites-enabled, unlike for conf.d.

  • What this means is that if one day you decide to quickly edit a file or two within /etc/nginx/sites-enabled, and your emacs creates a backup file like default~, then, suddenly, you have both default and default~ included as active configuration, which, depending directives used, may not even give you any warnings, and cause a prolonged debugging session to take place. (Yes, it did happen to me; it was during a hackathon, and I was totally puzzled of why my conf wasn’t working.)

Thus, I’m convinced that sites-enabled is pure evil!

Suggestion: 5

The sites-available and sites-enabled folders have a big advantage.

Whenever there is a system update, some packages (e.g. mod_ssl) add default files to the conf.d / sites-available folders (e.g. ssl.conf).
But whereas an apache configuration with sites-available is not affected, a new file in conf.d will be active, immediately, and could destroy your current configuration (like it was in our case after last server patching day…).