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...)

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.

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 http://nginx.org/packages/.

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 nginx.org:

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{,.disabled}

Or the opposite to enable a site:

sudo mv -i /etc/nginx/conf.d/example.com.conf{.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 .conf — find /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!

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.

With respect to containers [Docker]

As mentioned in a comment, the sites-* abstraction does not make sense when using containers.

It's important to note that sites-available|sites-enabled is a Debian-ism and is not something that nginx or Apache do. It was probably quite useful in the past, but its utility is somewhat limited in an age of configuration management and containers. – Michael Hampton Dec 22 '16 at 17:43

Allow me to clarify this.

Note that the current (1.21.6) NGINX Docker is built on Debian unless you specify Alpine instead. The Debian image does not use the sites-* abstraction; it is built from source (this makes sense).

So first of all, if you want to use sites-* then there are more lines of code. Creation of sites-* folders and symlinks, and editing of the default nginx.conf (or worse, checking one in that will not be updated when you upgrade your NGINX version).

If you want to keep your confs in git and have a fully reproducible build, then you commit the current state of your confs and let CI/CD do a deployment. This means that if you decided to use sites-* despite requiring more code, then you have to edit the Dockerfile or similar to adjust the symlinks that are created to enable/disable sites.

I say this

and want to keep your confs in git and have a fully reproducible build

because you could start a container that uses sites-*, log in to your server, and execute commands on the running container to manage the symlinks. In fact, this is the only way using sites-* makes sense with containerization. But with this workflow, the current state is only kept in the container (not in git, and starting a new container from the image will alter the enabled sites).

With the full conf.d approach, all you have to do is git mv mysite.com.conf mysite.com.conf.disabled and push the changes. Personally, I would rather push a rename commit than either editing the Dockerfile or logging in to a server to exec symlink commands.

So for writing less code, keeping the current state in git, and slightly more automation, I would recommend the pure conf.d approach when it comes to containers.