Папки sites- * управляются nginx_ensite и nginx_dissite. Для пользователей Apache httpd, которые находят это с помощью поиска, эквиваленты: a2ensite/a2dissite.

В sites-available папка предназначена для хранения все конфигураций вашего виртуального хоста, независимо от того, включены они в данный момент или нет.

В sites-enabled Папка содержит символические ссылки на файлы в папке с доступными сайтами. Это позволяет вам выборочно отключать vhosts, удаляя символическую ссылку.

conf.d выполняет свою работу, но вам нужно переместить что-то из папки, удалить или внести в него изменения, когда вам нужно что-то отключить. Абстракция папок sites- * делает вещи немного более организованными и позволяет управлять ими с помощью отдельных сценариев поддержки.

(если вы не похожи на меня и не один из многих администраторов Debian, которые просто управляли символическими ссылками напрямую, не зная о скриптах ...)

Я хотел бы добавить к предыдущим ответам, что наиболее важным является не то, как вы вызываете каталоги (хотя это очень полезное соглашение), а то, что вы фактически вставляете nginx.conf. Пример конфигурации:

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

Здесь используется единственная директива включают, поэтому нет внутренней разницы между, например, conf.d/ и sites-enabled/.

Из документации выше:

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.

Итак, чтобы ответить на исходный вопрос: нет внутренней разницы, и вы можете использовать их наилучшим образом, вспоминая советы из других ответов. И, пожалуйста, не забудьте выбрать «правильный» ответ.

Обычно sites-enabled папка используется для определений виртуальных хостов, а conf.d используется для глобальной конфигурации сервера. Если вы поддерживаете несколько веб-сайтов, то есть виртуальные хосты, тогда каждый из них получает свой собственный файл, поэтому вы можете очень легко включать и отключать их, перемещая файлы внутрь и из sites-enabled (или создание и удаление символических ссылок, что, вероятно, лучше).

Использовать conf.d для таких вещей, как загрузка модуля, файлы журнала и другие вещи, которые не относятся к одному виртуальному хосту.

Конфигурация по умолчанию ссылается на пользователя www-data? Мне нужно создать этого пользователя?

У вас должен быть запущен nginx как пользователь без полномочий root. В некоторых случаях это называется www-data, но вы можете называть его как хотите.

Как мне предоставить этому пользователю оптимальные разрешения для запуска nginx?

Я менее уверен в ответе на этот вопрос (в данный момент я не использую nginx), но если это что-то вроде Apache, то ответ таков: www-data пользователю нужны только разрешения на чтение для любых статических файлов (и чтение + выполнение в каталогах), которые вы обслуживаете, или разрешения на чтение / выполнение для таких вещей, как сценарии CGI, и никаких разрешений где-либо еще.

В чем дело?

Вы должны использовать Debian или Ubuntu, поскольку злой sites-available / sites-enabled логика не используется восходящая упаковка nginx из http://nginx.org/packages/.

В любом случае оба варианта реализованы как соглашение о конфигурации с помощью стандарта include директива в /etc/nginx/nginx.conf.

Вот отрывок /etc/nginx/nginx.conf из официального апстрима nginx от nginx.org:

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

Вот отрывок /etc/nginx/nginx.conf из Debian / Ubuntu:

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

Итак, с точки зрения NGINX, единственное отличие будет заключаться в том, что файлы из conf.d должны быть обработаны раньше, и, следовательно, если у вас есть конфигурации, которые молча конфликтуют друг с другом, то те из conf.d может иметь приоритет перед sites-enabled.

Лучшая практика conf.d.

Вы должны использовать /etc/nginx/conf.d, так как это стандартное соглашение, и оно должно работать где угодно.

Если вам нужно отключить сайт, просто переименуйте имя файла, чтобы больше не было .conf суффикс, очень простой, понятный и безошибочный:

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

Или наоборот включить сайт:

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

Избегайте sites-available & sites-enabled Любой ценой.

Я не вижу абсолютно никаких причин использовать sites-available / sites-enabled:

• Некоторые люди упомянули nginx_ensite и nginx_dissite скрипты - имена этих скриптов даже хуже, чем остальная часть этого фиаско - но этих скриптов тоже нигде нет - они отсутствуют в nginx пакет даже в Debian (и, вероятно, в Ubuntu тоже), и не присутствует в собственном пакете, плюс, вам действительно нужен целый нестандартный сторонний скрипт, чтобы просто перемещать и / или связывать файлы между два каталога ?!

• И если вы не используете сценарии (что, по сути, является разумным выбором, как указано выше), тогда возникает вопрос, как вы управляете сайтами:

  • Вы создаете символические ссылки из sites-available к sites-enabled?
  • Скопировать файлы?
  • Переместить файлы?
  • Отредактируйте файлы на месте в sites-enabled?

Вышеупомянутое может показаться незначительными проблемами, которые необходимо решить, пока несколько человек не начнут управлять системой, или пока вы не примете быстрое решение, только чтобы забыть об этом через несколько месяцев или лет ...

Что подводит нас к:

• Безопасно ли удалять файл из sites-enabled? Это софт-ссылка? Жесткая ссылка? Или единственный экземпляр конфигурации? Яркий пример конфигурационного ада.

• Какие сайты были отключены? (С участием conf.d, просто выполните инверсионный поиск файлов, не заканчивающихся на .conf - find /etc/nginx/conf.d -not -name "*.conf", или используйте grep -v.)

Не только все вышеперечисленное, но и обратите внимание на конкретные include директива, используемая Debian / Ubuntu - /etc/nginx/sites-enabled/* - суффикс имени файла не указан для sites-enabled, в отличие от conf.d.

• Это означает, что если однажды вы решите быстро отредактировать один или два файла в /etc/nginx/sites-enabled, и ваш emacs создает файл резервной копии, например default~, то внезапно оба default и default~ включена в качестве активной конфигурации, которая, в зависимости от используемых директив, может даже не выдавать никаких предупреждений и вызывать длительный сеанс отладки. (Да, это случилось со мной; это было во время хакатона, и я был полностью озадачен, почему мой conf не работал.)

Таким образом, я убежден, что sites-enabled это чистое зло!