Pull to refresh

Comments 28

Для разработки наверное кому-нибудь пригодится, но в продакшене такое лучше не использовать.
Почему нет, если продакшн состоит из 10000 сайтов с 10 хитами в день на каждом?
У кого десятки тысяч сайтов — скорее всего знают, как настраивать nginx. Я предостерегаю новичков от использования таких конфигов.
А можно всё-таки услышать хоть один агрумент против такого конфига?
Пусть это будет не 10000 сайтов, а просто 10. Допустим, что способы вызова скриптов везде одинаковые. Чем такой конфиг будет хуже десяти отдельных?
1. Он не читабелен. Подобные вопросы так часто всплывают в рассылке, что привело к появлению в FAQ данного пункта: nginx.org/en/docs/faq/variables_in_config.html Не надо программировать на конфигах nginx.

2. Он будет работать медленнее, потреблять больше ресурсов, чем 10 отдельных. Лучше написать скрипт, который вам сгенерирует N конфигов перед стартом nginx, чем использовать такие конструкции.

Из этого есть одно исключение: ооочень, очень много сайтов. Для 10к сайтов потребление памяти будет заметно выше со статическими конфигами.
И еще не забываем, что php-fpm будет работать от одного пользователя: группы в одном пуле.
Ну так оно на самом деле и существует. На всякие приличные сайты свой конфиг (без злостных ifов :)) и свой пул (ибо нефиг). На многотысячную свалку — этот конфиг и сэйфмод в PHP.
server {
    server_name ~^(www\.)?(?<domain>.+)$;

    location / {
        root /sites/$domain;
    }
}

Добавить в это include и вполне себе рабочее продакшн решение
server_name ~^(?:www\.)?(?<domain>.+)$;

Не зачем лишнюю группу создавать.
Нет предела совершенству ^) Спасибо
В логах при таком конфиге server_name страшно выглядит. А именно — "^(www\.)?(?.+)$". Не информативно абсолютно.
Ура! Вы, получили первый уровень в nginx, теперь получите еще 30 и вперед делиться конфигами
location ~ /\.ht
а какже .git, .svn, .ftpaccess? Добро пожаловать милости просим?
Все файлы с точкой в начале нужно считать скрытыми

location ~ /\. {
deny all;
access_log off;
log_not_found off;
}

Реврайт на www у вас 302, а обычно надо 301 чтобы происходила склейка (и обратите внимае тут в регулярке используется 1 карман, вы же почему-то www в скобки тоже взяли)

if ($host ~* www\.(.*)) {
set $host_without_www $1;
rewrite ^(.*)$ http://$host_without_www$1 permanent;
}

Вместо if (-e $request_filename) рекомендуется try files.
И вообще, в конфиге много магии, вкупе с 1 пуллом и юзером это делает его малопригодным для продакшена.
Ну, пожалуй, от магии автоматического разбиения на пулы я бы не отказался :)

Реврайт 301 нужен именно что для склейки, а в моём варианте её нет.
>> rewrite ^(.*)$ http://$host_without_www$1 permanent;

Не нужен тут реврайт (он вообще практически никогда не нужен).

return 301 http://$host_without_www$1

Ну и уже выше показали, как имя хоста без www получить регуляркой в server_name, безо всяких if-ов.
А так?
set $logName $sathost"_access.log";
access_log /var/log/nginx/all/$logName;

А вообще, Вам бы ещё не мешало разобраться с try_files, вместо этого огорода, ну и да, полистать чужие конфиги. Новичкам бы я этот не советовал.
Сработает, и так тоже (не надо доп. переменную создавать).
access_log "/var/www/$sathost/logs/access.log";

а вот с «error_log» такое уже не пройдет.
    server_name _;  # хитрый ключик, обозначающий, что этот конфиг применим для любого сайта



Нет. Это имя выбирают, чтобы с другими server не пересекалось.

    listen 80 default; # этот конфиг - умолчательный для 80 порта


Вот этот ключ говорит nginx, что если подходящий server не найдет, использовать этот.
Вместо default нужно использовать default_server.
До версии 0.8.21 этот параметр назывался просто default.

Это уже детали. Просто много людей думают, то "_" в качестве имени сделают этот сервер по-умолчанию, а потом пишут много вопросов на всяких askdev и.т.д.
        fastcgi_param  SCRIPT_FILENAME  /var/www/all/$sathost/$fastcgi_script_name;
        include fastcgi_params;

Потенциально бажный кусок. include после всех директив приведет к переопределению ранее инициированных значений.

Правильно делать в include на файл в который вынесены общие правила и дальше ниже по конфигу для конкретного location задать требуемые значения.

Вот кусок из моих конфигов:
server {
	...
    location / {
        index       index.php;
        try_files   $uri $uri/ @backend;
    }

    location ~ \.php$ {
        try_files       $uri @backend;
        fastcgi_pass    unix:/var/www/tmp/$server_name.fastcgi.socket;
        fastcgi_index   index.php;

        include         /etc/nginx/fastcgi_params;

        fastcgi_param   SCRIPT_FILENAME     /www/$server_name/public$fastcgi_script_name;
        fastcgi_param   QUERY_STRING        q=$uri&$args;
        fastcgi_param   REQUEST_URI         q=$uri&$args;
        fastcgi_param   DOCUMENT_ROOT       /www/$server_name/public;
    }

    location @backend {
        fastcgi_pass    unix:/var/www/tmp/$server_name.fastcgi.socket;
        fastcgi_index   index.php;

        include         /etc/nginx/fastcgi_params;

        fastcgi_param   SCRIPT_FILENAME     /www/$server_name/public/index.php;
        fastcgi_param   SCRIPT_NAME         index.php;
        fastcgi_param   QUERY_STRING        q=$uri&$args;
        fastcgi_param   REQUEST_URI         q=$uri&$args;
        fastcgi_param   DOCUMENT_ROOT       /www/$server_name/public;
    }
}
Правильно вообще не дублировать значения. Они не переопределяются. Если у вас дважды указано какое-то значение на одном уровне (скажем в include и так), то оба значения будут отправлены на бэкенд в порядке их следования, а там уже зависит от бэкенда какое из них он возьмет — первое или последнее.
Что отправит как есть на бэкэнд это-то понятно. Но в данном контексте мы говорим о связке с PHP который переопределит данные. В результате конфига как у автора возможна ситуация, когда после добавления данных в общий конфиг который include-тся сломается один из location-ов. Что для не очень опытного админа чревато долгим чесанием головы.
Если вам приходилось настраивать Nginx под нужды… сеошников

3. Делает стандартный редирект на index.php в корне сайта при запросе несуществующего пути.


Что-то бред какой-то. Такой редирект явно не на пользу сео.
Если путь не существует — надо на 404 страницу слать людей.
Хотя блин, вопрос конечно спорный. С точки зрения пользы для юзера — полезнее показать ему главную. С точки зрения поисковой системы — лучше не смешивать и на ошибки отдавать специальную страницу с 404 ответом сервера.
Не нужно показывать ему главную. Нужно показать ему 404-ую в рамках которой нужно попытаться устранить ошибку. К примеру, если страница была, но её удалили, то нужно об этом явно написать и есть у страницы есть новый адрес, то указать ссылку на него. При тихом редиректе на главную совершенно будет не понятно, что же пошло не так.
Only those users with full accounts are able to leave comments. Log in, please.