Комментарии 28
Для разработки наверное кому-нибудь пригодится, но в продакшене такое лучше не использовать.
Почему нет, если продакшн состоит из 10000 сайтов с 10 хитами в день на каждом?
У кого десятки тысяч сайтов — скорее всего знают, как настраивать nginx. Я предостерегаю новичков от использования таких конфигов.
А можно всё-таки услышать хоть один агрумент против такого конфига?
Пусть это будет не 10000 сайтов, а просто 10. Допустим, что способы вызова скриптов везде одинаковые. Чем такой конфиг будет хуже десяти отдельных?
Пусть это будет не 10000 сайтов, а просто 10. Допустим, что способы вызова скриптов везде одинаковые. Чем такой конфиг будет хуже десяти отдельных?
1. Он не читабелен. Подобные вопросы так часто всплывают в рассылке, что привело к появлению в FAQ данного пункта: nginx.org/en/docs/faq/variables_in_config.html Не надо программировать на конфигах nginx.
2. Он будет работать медленнее, потреблять больше ресурсов, чем 10 отдельных. Лучше написать скрипт, который вам сгенерирует N конфигов перед стартом nginx, чем использовать такие конструкции.
Из этого есть одно исключение: ооочень, очень много сайтов. Для 10к сайтов потребление памяти будет заметно выше со статическими конфигами.
2. Он будет работать медленнее, потреблять больше ресурсов, чем 10 отдельных. Лучше написать скрипт, который вам сгенерирует N конфигов перед стартом nginx, чем использовать такие конструкции.
Из этого есть одно исключение: ооочень, очень много сайтов. Для 10к сайтов потребление памяти будет заметно выше со статическими конфигами.
И еще не забываем об If Is Evil.
И еще не забываем, что php-fpm будет работать от одного пользователя: группы в одном пуле.
Ну так оно на самом деле и существует. На всякие приличные сайты свой конфиг (без злостных ifов :)) и свой пул (ибо нефиг). На многотысячную свалку — этот конфиг и сэйфмод в PHP.
server {
server_name ~^(www\.)?(?<domain>.+)$;
location / {
root /sites/$domain;
}
}
Ура! Вы, получили первый уровень в 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 пуллом и юзером это делает его малопригодным для продакшена.
а какже .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 нужен именно что для склейки, а в моём варианте её нет.
Реврайт 301 нужен именно что для склейки, а в моём варианте её нет.
>> rewrite ^(.*)$ http://$host_without_www$1 permanent;
Не нужен тут реврайт (он вообще практически никогда не нужен).
return 301 http://$host_without_www$1
Ну и уже выше показали, как имя хоста без www получить регуляркой в server_name, безо всяких if-ов.
Не нужен тут реврайт (он вообще практически никогда не нужен).
return 301 http://$host_without_www$1
Ну и уже выше показали, как имя хоста без www получить регуляркой в server_name, безо всяких if-ов.
А так?
А вообще, Вам бы ещё не мешало разобраться с try_files, вместо этого огорода, ну и да, полистать чужие конфиги. Новичкам бы я этот не советовал.
set $logName $sathost"_access.log";
access_log /var/log/nginx/all/$logName;
А вообще, Вам бы ещё не мешало разобраться с try_files, вместо этого огорода, ну и да, полистать чужие конфиги. Новичкам бы я этот не советовал.
server_name _; # хитрый ключик, обозначающий, что этот конфиг применим для любого сайта
Нет. Это имя выбирают, чтобы с другими server не пересекалось.
listen 80 default; # этот конфиг - умолчательный для 80 порта
Вот этот ключ говорит nginx, что если подходящий server не найдет, использовать этот.
Вместо default нужно использовать default_server.
До версии 0.8.21 этот параметр назывался просто default.
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-ую в рамках которой нужно попытаться устранить ошибку. К примеру, если страница была, но её удалили, то нужно об этом явно написать и есть у страницы есть новый адрес, то указать ссылку на него. При тихом редиректе на главную совершенно будет не понятно, что же пошло не так.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Один конфиг Nginx для работы с кучей разных сайтов