Содержание
Рецепт конфигурации nginx для UMI.CMS с использованием статического кэша — DiPHOST.Ru wiki system
Материал из DiPHOST.Ru wiki system
Перейти к: навигация, поиск
Рецепт nginx «UMI.CMS кэш nginx»
Коллекция рецептов nginx нашего хостинга
UMI.CMS способна создавать статическую копию сайта: кэширование через nginx. Это позволяет в 10-ки раз ускорить работу сайтов. Предполагается, что config.ini UMI.CMS имеет такие строки:
- [includes]
- static.system-cache = /home/ваш_логин/www/site<N>/public_html/sys-temp/static-cache
- [cache]
- static.enabled = «1»
- static.mode = «nginx»
Так выглядит конфигурация nginx сайта для хостинга:
# конфигурация nginx для гипотетического пользователя хостинга username для сайта номер "один" # конфигурация обеспечивает работу со специальным кэшированием UMI.CMS # http://wiki.umisoft.ru/кэширование_через_nginx # # параметр listen и proxy_pass генерируется нашей системой автоматически по внутренним параметрам server { listen 192. 168.0.1:80; # IP-адрес сервера proxy_buffer_size 8k; # параметр изменяется в панели управления client_max_body_size 16m; # параметр изменяется в панели управления client_body_buffer_size 512k; # кэш имён файлов для disable_symlinks open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; # имена сайта server_name example.com; server_name www.example.com # отключение лишних журналов access_log off; log_not_found off; # корневая папка для статических файлов root /home/username/www/site1/public_html; index index.html; # запрет символьных ссылок на "чужие" файлы # если файл находится внутри папки /home/username/www/site1/public_html , # то эту часть не проверять по соображением производительности disable_symlinks if_not_owner from=/home/username/www/site1/public_html; # обработать запрос, не соответствующий уточнениям ниже location / { access_log /home/username/www/site1/logs/nginx-access. log; # кодировка прописана во избежании ситуаций, когда отдаваемые nginx файлы .html интерпретируется # браузером в соответствии с его настройкой charset utf-8; source_charset utf-8; # не смотреть в кэше, если метод запроса POST или есть аргументы, или пользователь залогинен error_page 412 = @apache; if ($request_method = 'POST') { return 412; } if ($is_args = '?') { return 412; } if ($cookie_umicms_session) { return 412; } # переопределить корень сайта на папку статического кэша # попытаться воспользоваться им root /home/username/www/site1/public_html/sys-temp/static-cache/$host/; try_files $uri/index.html @apache; } # запретить доступ к файлам репозиториев, если они случайно оказались в публичном месте location ~ /\. /admin { error_page 412 = @apache; return 412; } # обрабатывать php-файлы веб-сервером apache location ~* \.php$ { error_page 412 = @apache; return 412; } # попытаться отдать файл с одним из расширений напрямую минуя apache location ~* \.(swf|zip|rar|arj|cab|exe|dll|ico|jpg|jpeg|gif|bmp|png|mp3|avi|mov|mpg|mpeg|amr|mmf|wml|wbmp|mid|midi|3gp|css|js|html|htm|txt)$ { access_log /home/username/www/site1/logs/nginx-access.log; charset utf-8; source_charset utf-8; try_files $uri @apache; } # передать запрос к apache location @apache { proxy_pass http://127.0.0.1:11111; } }
Рецепт конфигурации nginx для UMI.
CMS — DiPHOST.Ru wiki system
Материал из DiPHOST.Ru wiki system
Перейти к: навигация, поиск
Рецепт nginx «UMI.CMS»
Коллекция рецептов nginx нашего хостинга
Для обработки статических файлов веб-сервером nginx мы разработали специальную с учётом особенностей UMI.CMS.
Так выглядит конфигурация nginx сайта для хостинга:
# конфигурация nginx для гипотетического пользователя хостинга username для сайта номер "один" # # параметр listen и proxy_pass генерируется нашей системой автоматически по внутренним параметрам server { listen 192.168.0.1:80; # IP-адрес сервера proxy_buffer_size 8k; # параметр изменяется в панели управления client_max_body_size 16m; # параметр изменяется в панели управления client_body_buffer_size 512k; # кэш имён файлов для disable_symlinks open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; # имена сайта server_name example. com; server_name www.example.com # отключение лишних журналов access_log off; log_not_found off; # корневая папка для статических файлов root /home/username/www/site1/public_html; index index.html; # запрет символьных ссылок на "чужие" файлы # если файл находится внутри папки /home/username/www/site1/public_html , # то эту часть не проверять по соображением производительности disable_symlinks if_not_owner from=/home/username/www/site1/public_html; # обработать запрос, не соответствующий уточнениям ниже location / { proxy_pass http://127.0.0.1:11111; } # запретить доступ к файлам репозиториев, если они случайно оказались в публичном месте location ~ /\.svn { deny all; } location ~ /\. git { deny all; } location ~ /\.hg { deny all; } # запретить доступ к файлам .htaccess и .htpasswd location ~ /\.ht { deny all; } # попытаться отдать файл с одним из расширений напрямую минуя apache location ~* \.(swf|zip|rar|arj|cab|exe|dll|ico|jpg|jpeg|gif|bmp|png|mp3|avi|mov|mpg|mpeg|amr|mmf|wml|wbmp|mid|midi|3gp|css|js|html|htm|txt)$ { access_log /home/username/www/site1/logs/nginx-access.log; charset utf-8; source_charset utf-8; try_files $uri @apache; } # передать запрос к apache location @apache { proxy_pass http://127.0.0.1:11111; } }
Nginx — Какая CMS?
Manage
nginx
Web Server
nginx. org/en
5,226,248
Websites
30.01%
Top 1M Market Share
Compare
Get a customized list of websites использование Nginx
Статистика использования
Доля рынка
С 20 декабря 2020 года Nginx сохраняет довольно стабильную долю рынка во всех сегментах популярности веб-сайтов.
Nginx Versions
Major Versions
- v1 (99.56%)
- v0 (0.429%)
- 3 Others (0.014%)
Minor Versions
- v1.9 (0.016%)
- v1 .7 (0,016%)
- v1.5 (0,037%)
- v1.3 (0,022%)
- v1.21 (13,3%)
- v1.20 (18,8%)
- v1.2 (0,1% )
- v1.19 (4,001%)
- v1.17 (9,414%)
- v1.15 (4,488%)
- v1. 14 (13,48%)
- v1.13 (1,663%)
- v1.12 (10,25%)
- v1.11 (1,598%)
- v1.10 (21,5%)
- v1.1 (0,439%)
- v1,00 (0,43%)
- v0.8 (0,105%)
- v0.7 (0,27%)
- v0.6 (0,03%)
- v0.5 (0,021%)
- 7 Другие (0,019%)
1
1
Домены верхнего уровня
Веб-сайты, использующие Nginx, были обнаружены на 274 доменах верхнего уровня
- Коммерческие (.com) (40,06%)
- Австралия (.au) (5,295%)
- Россия (.ru) (4,946%)
- Германия (.de) (4,711%)
- Организация (.org) (3,687%)
- Великобритания (.uk) (2,772%)
- Сеть (.net) (2,541%)
- Австрия (.at) (2,392%)
- Нидерланды (.nl) (2,178%)
- Италия (.it) (1,725%)
- Франция (.fr) ( 1,723%)
- Дания (.dk) (1,723%)
- Украина (.ua) (1,369%)
- Новая Зеландия (.nz) (1,217%)
- Швейцария (.ch) (1,129%)
- Испания (.es) (1,097%)
- Польша (. pl) (1,091%)
- Япония (.jp) (0,797%)
- Греция (.gr) (0,78%)
- Чехия (.cz) (0,751%)
- Беларусь (.by) (0,733%)
- Колумбия (.co) (0,724%)
- Канада (.ca) (0,69%)
- Бельгия (.be) (0,68) %)
- Чили (.cl) (0,659%)
- Европейский Союз (.eu) (0,653%)
- Индия (.in) (0,65%)
- Бразилия (.br) (0,634%)
- Информация (.info) (0,542%)
- Швеция (.se) (0,488%)
- Румыния (.ro) (0,48%)
- Норвегия (.no) (0,477%)
- Словакия (.sk) (0,475%)
- Британская территория в Индийском океане (.io) (0,402%)
- Казахстан (.kz) (0,399%)
- XYZ (.xyz) (0,387%)
- Китай (.cn) (0,358%)
- Финляндия (.fi) (0,343 %)
- Венгрия (.hu) (0,302%)
- Португалия (.pt) (0,291%)
- Иран (.ir) (0,283%)
- Вьетнам (.vn) (0,283%)
- Online (.online) (0,254%)
- Черногория (.me) (0,236%)
- Израиль (.il) (0,23%)
- Biz (. biz) (0,218%)
- Россия (кириллица) ( .рф) (0,213%)
- Корея, Южная (Республика Корея) (.kr) (0,208%)
- ЮАР (.za) (0,192%)
- Мексика (.mx) (0,188%)
- 224 Другие (5,345%)
Родственные технологии
Дополнительные технологии
Технологии | Категория | Сайты | Сравнить |
---|---|---|---|
PHP | Язык программирования | 2 912 705 | Nginx против PHP |
MySQL | База данных | 1 923 424 | Nginx против MySQL |
WordPress | Блог / CMS | 1 806 175 | Nginx против WordPress |
Элементор | Конструктор целевых страниц / CMS | 359 791 | Nginx против Elementor |
WooCommerce | Электронная коммерция / CMS | 358 910 | Nginx против WooCommerce |
Облачная вспышка | CDN | 339 107 | Nginx против Cloudflare |
wpПекарня | Конструктор целевых страниц / CMS | 247 896 | Nginx против wpBakery |
cdnjs | CDN | 246 622 | Nginx против cdnjs |
Библиотеки, размещенные в Google | CDN | 235 713 | Nginx в сравнении с размещенными на Google библиотеками |
Апач | Веб-сервер | 213 127 | Nginx против Apache |
Убунту | Операционная система | 196 141 | Nginx против Ubuntu |
Зависимости
Nginx зависит от 0 технологий
иждивенцев
3 Технологии зависят от NGINX
OpenRestyCentminMinMINMODBSALE
Популярные сайты с использованием NGINX
We Det STACE SITES. Следующие SITES. .ru
gandi.net
wordpress.com
bit.ly
tiktok.com
Nginx | Документация Grav
Быстрое меню
- Требования
- Конфигурация
Nginx — это программное обеспечение HTTP-сервера, ориентированное на основные функции веб-сервера и прокси. Это очень распространено из-за эффективности использования ресурсов и отклика под нагрузкой. Nginx порождает рабочие процессы, каждый из которых может обрабатывать тысячи подключений. Каждое из соединений, обрабатываемых рабочим процессом, помещается в цикл событий, где они существуют с другими соединениями. В цикле события обрабатываются асинхронно, что позволяет выполнять работу неблокирующим образом. Когда соединение закрывается, оно удаляется из цикла. Этот стиль обработки соединений позволяет Nginx невероятно масштабироваться с ограниченными ресурсами.
Требования
На этой странице объясняется, как запустить Grav с Nginx в качестве HTTP-сервера и PHP-FPM (FastCGI Process Manager) для обработки сценариев PHP, поэтому эти пакеты должны быть установлены на вашем сервере:
-
нгинкс
-
php-fpm
Конфигурация
Если вы новичок в Nginx и еще не имеете базового представления о директивах/контексте блоков, рекомендуется прочитать Руководство Nginx для начинающих, особенно разделы Структура файла конфигурации и Обслуживание статического содержимого.
Предполагается, что ваша конфигурация Nginx находится в /etc/nginx/
, а ваша установка Grav хранится в /var/www/grav/
. Структура конфигурации представляет собой блок http
, содержащий общие директивы, актуальные для всех страниц, обслуживаемых Nginx, а также один или несколько блоков server
для каждой страницы, содержащих директивы для конкретных сайтов. Основной файл конфигурации сервера — nginx.conf
и хранит http
, в то время как конфигурации для конкретных сайтов (блоки серверов
) хранятся на сайтах — доступно
и связаны символическими ссылками на сайтов — разрешено
.
Права доступа к файлам
Каталог /var/www
и все содержащиеся в нем файлы и папки должны принадлежать $USER:www-data
(или как вы назовете пользователя/группу Nginx). В разделе «Устранение неполадок/Разрешения» объясняется, как настроить права доступа к файлам и каталогам для Grav, в данном случае с использованием общей группы. В основном то, что вы хотите, это 775
для каталогов и 664
для файлов в каталоге Grav, поэтому Grav разрешено изменять содержимое и обновлять себя. Вы должны добавить своего пользователя в группу www-data
, чтобы иметь доступ к файлам, созданным Grav/Nginx.
Пример nginx.conf
Следующая конфигурация представляет собой улучшенную версию стандартного файла /etc/nginx/nginx.conf
, в основном с улучшениями из github.com/h5bp/server-configs-nginx. См. их репозиторий для получения пояснений по этим настройкам или документацию по основному модулю Nginx и http-модулю, чтобы найти конкретные директивы.
Рекомендуется использовать обновленный файл определения типов MIME ( mime.types
) с github.com/h5bp/server-configs-nginx. Это позволит убедиться, что типы правильно установлены для сжатия gzip.
nginx.conf :
www-данные пользователя; рабочие_процессы авто; worker_rlimit_nofile 8192; # должно быть больше, чем worker_connections pid /run/nginx. pid; События { использовать эполл; worker_connections 8000; мульти_принять; } http { отправить файл включен; tcp_nopush включен; tcp_nodelay включен; keepalive_timeout 30; # более длинные значения лучше подходят для каждого клиента ssl, но дольше занимают рабочее соединение типы_хэш_макс_размер 2048; server_tokens отключены; # максимальный размер загружаемого файла # обновить 'upload_max_filesize' и 'post_max_size' в /etc/php/fpm/php.ini соответственно client_max_body_size 32 м; # client_body_timeout 60 с; # увеличение для очень длинных загрузок файлов # установить индексный файл по умолчанию (можно перезаписать для каждого сайта отдельно) индекс index.html; # загружаем MIME-типы включить mime.types; # получить этот файл с https://github.com/h5bp/server-configs-nginx default_type application/octet-stream; # установить тип MIME по умолчанию # протоколирование журнал_доступа /var/log/nginx/access.log; журнал_ошибок /var/log/nginx/error. log; # включаем сжатие gzip gzip включен; gzip_disable "msie6"; gzip_vary включен; gzip_proxy любой; gzip_comp_level 5; gzip_buffers 16 8k; gzip_http_версия 1.1; gzip_min_length 256; gzip_types приложение/атом+xml приложение/javascript приложение/json приложение/ld+json приложение/манифест+json приложение/rss+xml приложение/vnd.geo+json приложение /vnd.ms-fontobject приложение/x-шрифт-ttf приложение/x-веб-приложение-манифест+json приложение/xhtml+xml приложение/xml шрифт/открытый тип изображение/bmp изображение/svg+xml изображение/x-значок текст/кэш-манифест текст/CSS текст/обычный текст/визитная карточка текст /vnd.rim.location.xloc текст/vtt текст/x-компонент text/x-междоменная политика; # отключить сниффинг типов контента для большей безопасности add_header "X-Content-Type-Options" "nosniff"; # установить последнюю версию IE add_header "X-UA-совместимый" "IE=Edge"; # включить фильтр защиты от межсайтовых сценариев, встроенный в IE 8+ add_header "X-XSS-защита" "1; режим = блок"; # включить конфиги виртуального хоста включить сайты с поддержкой/*; }
Конфигурация сайта Grav
Grav поставляется с файлом конфигурации для вашего сайта в каталоге webserver-configs
вашей установки Grav. Вы можете скопировать этот файл в каталог конфигурации nginx:
cp /var/www/grav/webserver-configs/nginx.conf /etc/nginx/sites-available/grav-site
Откройте этот файл в редакторе и замените «example.com» с вашим доменом/IP-адресом (или «localhost», если вы хотите просто запустить его локально), замените строку «root» на «root /var/www/grav/;» а затем создайте символическую ссылку вашего сайта-конфига в site-enabled
:
ln -s /etc/nginx/sites-available/grav-site /etc/nginx/sites-enabled/grav-site
Наконец, позвольте Nginx перезагрузить свою конфигурацию:
nginx -s reload
Исправление уязвимости httpoxy
httpoxy — это набор уязвимостей, которые затрагивают код приложения, работающий в среде CGI или CGI-подобной среде.
(Источник: httpoxy.org)
Чтобы обезопасить свой сайт от этой уязвимости, вы должны заблокировать Заголовок прокси
. Это можно сделать, добавив параметр FastCGI в вашу конфигурацию. Просто откройте файл /etc/nginx/fastcgi.conf
и добавьте в конец эту строку:
fastcgi_param HTTP_PROXY "";
Использование SSL (с существующим сертификатом)
Если вы хотите использовать существующий сертификат SSL для шифрования трафика вашего веб-сайта, в этом разделе приведены необходимые шаги для изменения конфигурации Nginx для этого.
Сначала создайте файл /etc/nginx/ssl.conf
со следующим содержимым и настройте пути к вашему сертификату и ключевому файлу. Последний раздел посвящен сшиванию OSCP и требует от вас предоставления сертификата цепи + корня. Если вы этого не хотите, вы можете прокомментировать или удалить все, что находится ниже комментария OCSP Stapling
. Если ваш веб-сайт использует только SSL (включая поддомены), вы можете отправить свой домен для предварительной загрузки в браузерах по адресу https://hstspreload.appspot.com. Если это не так, вы можете удалить предварительную загрузку ;
из строки, которая добавляет заголовок «Strict-Transport-Security». Обязательно проверьте, все ли эти параметры работают для вашей установки.
ssl.conf :
# здесь укажите пути к вашему сертификату и файлам ключей ssl_certificate /etc/ssl/certs/example.com.crt; ssl_certificate_key /etc/ssl/private/example.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers :DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA -AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128 -SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM -SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4: !MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA; ssl_prefer_server_ciphers включен; ssl_session_cache общий: SSL: 10 м; # кэш размером 1 Мб может содержать около 4000 сессий, поэтому мы можем хранить 40000 сессий ssl_session_timeout 24 часа; # Используйте более высокий тайм-аут проверки активности, чтобы уменьшить потребность в повторных рукопожатиях keepalive_timeout 300 с; # по сравнению с 75 секундами по умолчанию # отправить домен для предварительной загрузки в браузерах по адресу: https://hstspreload. appspot.com add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; предварительная загрузка;"; # Сшивание OCSP # nginx будет запрашивать у ЦС подписанные ответы OCSP и отправлять их клиентам, чтобы клиенты не выполняли свои собственные вызовы OCSP. # см. https://sslmate.com/blog/post/ocsp_stapling_in_apache_and_nginx о том, как создать цепочку + корень ssl_stapling включен; ssl_stapling_verify включен; ssl_trusted_certificate /etc/ssl/certs/example.com.chain+root.crt; резольвер 198.51.100.1 198.51.100.2 203.0.113.66 203.0.113.67 действительный=60с; резолвер_таймаут 2 с;
Теперь измените содержимое вашей специфичной для Grav конфигурации /etc/nginx/sites-available/grav-site
, чтобы перенаправить незашифрованные HTTP-запросы на HTTPS, что означает, что сервер
блокирует прослушивание порта 443 и включая ваш . ssl.conf
(замените «example.com» своим доменом/IP-адресом). Вы также можете изменить это, чтобы перенаправить с версии без www на версию вашего домена с www.
grav-site :
# перенаправление с http на https без www сервер { слушать [::]:80; слушать 80; имя_сервера example.com www.example.com; вернуть 302 https://example.com$request_uri; } # перенаправление с www https на https без www сервер { слушать [::]:443 ssl; слушать 443 ssl; имя_сервера www.example.com; # добавить сертификат ssl и параметры включить ssl.conf; вернуть 302 https://example.com$request_uri; } # обслуживать веб-сайт сервер { слушать [::]:443 ssl; слушать 443 ssl; имя_сервера пример.com; # добавить сертификат ssl и параметры включить ssl.conf; корень /var/www/example.com; индекс index.html index.php; # ... # остальная часть этого блока сервера (директивы местоположения) идентична той, что была в присланном конфиге }
Наконец, перезагрузите конфигурацию Nginx:
nginx -s reload
Также рекомендуется включить их в рабочей среде. Эти дополнения к файлу конфигурации справятся с ними.