Настройка wordpress сайта на сервере Nginx. Wordpress nginx

Настройка wordpress сайта на сервере Nginx

В данной статье хотелось бы рассказать о своем опыте в настройке WordPress сайта на nginx сервере. Покажу получившийся конфиг и поясню что за что отвечает.

Доступ к директории конфигурации nginx

Для начала необходимо открыть директорию с конфигурацией nginx. Для подключения к серверу я использовал протокол SFTP. Нужная нам директория следующая — /etc/nginx/sites-available (у вас она может немного отличаться). В ней необходимо создать файл с именем вашего домена, в моем случае dmkweb.ru. После создания файла откройте его в любом удобном вам текстовом редакторе.

Открыли? Теперь можно приступать к работе над конфигурацией.

Выбор портов и расположения сайта

Файлы конфигурации Nginx начинаются со слова server и фигурных скобочек внутри которых и будут располагаться все дальнейшие настройки.

server { listen 80; # указываем что будем слушать 80 порт listen [::]:80 ipv6only=on; # указываем что будет использоваться ipv6 протокол root /var/www/dmkweb.ru/html; # указываем расположение корневой директории сайта index index.php; # главная страница будет открываться файлом index.php server_name dmkweb.ru; # указываем имя домена (при необходимости можно указать вариант с www) }

Настройка логов доступа и ошибок

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

access_log /var/log/nginx/dmkweb.ru.access.log; error_log /var/log/nginx/dmkweb.ru.error.log;

Настройка красивых url-ов и кэша

Для корректной отправки запросов на наш WP сайт необходимо задать обработку основного lacation-а. Чтобы при запросе любых url-ов типа — «dmkweb.ru/about.html» nginx отдавал его верную интерпретацию в виде страницы с красивым url либо доставал результат из кэша.

location / { try_files /wp-content/cache/$http_host/$cache/index.html $uri $uri/ /index.php?$args ; }

Настройка php

Подобная настройка поведения PHP является оптимальной. В тонкости работы менеджера процессов fastcgi в данной статье я описывать не буду.

location ~ [^/]\.php(/|$) { try_files $uri =404; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/run/php/php7.0-fpm.sock; fastcgi_index index.php; include fastcgi_params; }

Запрет доступа к исполняемым файлам

Здесь все предельно ясно, блокируем возможность доступа к директориям и файлам php в папках uploads или files.

location ~ /\. { deny all; } location ~* /(?:uploads|files)/.*\.php$ { deny all; }

Избавление от лишнего в access log

Данные настройки убирают лишние ошибки на при работе с favicon-ками и файлами robots.txt

location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; }

Запреты кэширования

Чтобы не плодить кэш внесем следующие настройки в наш файл.

if ($request_method = POST) { # запрещаем кэширование при использовании POST запросов set $cache 'null cache'; } if ($query_string != "") { # запрещаем кэширование если были переданы параметры set $cache 'null cache'; } # запрещаем кеш если идет доступ к служебным файлам if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") { set $cache 'null cache'; } # запрещаем кеш если используются cookie if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") { set $cache 'null cache'; }

Так же настоятельно советую вам при работе с WordPress установить плагин для кэширования: WP Super Cache.

Стандартный конфиг готов. Самое основное указано. Найти готовый файл вы можете по ссылке.

На этом все, Успехов!

dmkweb.ru Права на контент защищены.

dmkweb.ru

Руководство по настройке блога WordPress на nginx.

Wordpress на Nginx

Данное руководство рассчитано на вебмастеров, стремящихся решить проблему недостаточной производительности сайтов, построенных на платформе WordPress. В нем описана пошаговая настройка сервера с ограниченными ресурсами (1 ядро, 512 RAM на примере минимального тарифа Flops.ru) для использования в связке LEMP (Linux + nginx + MySQL + PHP). Для комфортного использования материала вы должны иметь общие представления о работе сайтов и серверов на базе Linux.

Эволюция требований к хостингу при увеличении масштабов проекта.

Наиболее популярным решением для веб серверов по прежнему остается связка LAMP (Linux, Apache, MySQL, PHP). Подобный вариант легок в настройке, хорошо документирован, часто используется для небольших проектов. Но за простоту использования приходится платить чрезмерным потреблением ресурсов и высокими рисками даунтайма при увеличении нагрузки (возросшее число посетителей, большое количество материалов, тяжелые плагины).

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

Часто в качестве следующего шага развития используется LAMP за proxy сервером nginx, обеспечивающим быструю отдачу статики, тем самым снижая нагрузку на Apache. Подобное решение позволяет с минимальными усилиями и поддержкой специфических для Apache возможностей (например .htaccess) существенно повысить производительность. Для ускорения динамики в ход идут исполнение PHP в режиме CGI, средства кэширования байт-кода и SQL запросов. При этом в подобной связке все равно остается узкое место — производительность Apache.

Следующим витком эволюции в погоне за производительность стает полный отказ от Apache, использование FPM, полное кэширование страниц сайта.

Это руководство подробно рассказывает о настройке WordPress, выдерживающей нагрузки в несколько сотен конкурентных запросов в секунду в условиях крайне ограниченных серверных ресурсов. Руководство описывает все шаги установки, включая первичную настройку сервера, обеспечивающую защиту от стандартных угроз, установку и настройку LEMP, настройку WordPress. Выполнение всех пунктов гарантирует получение работоспособного сервера.

ВАЖНО: В руководстве не описана процедура резервного копирования, так как Flops.ru обеспечивает создание резервных копий и снэпшотов, а использование сторонних мест хранения сугубо индивидуально.

ВАЖНО: Набор предустановленных пакетов у разных хостинг-провайдеров может варьироваться. Руководство подразумевает наличие схожих с Flops.ru пакетов.

ЗАМЕЧАНИЕ: В интернете гуляет множество статей по использованию в подобной связке Varnish, но nginx отдает статику не хуже, а конфигурация, представленная ниже, преимущественно будет работать именно со статикой, так что не вижу смыла усложнять проект еще одной прослойкой, тем более сильно отягчающей жизнь проектам, использующим SSL. Для формирования статической выдачи будет использоваться плагин WP Super Cache.

Требования к серверу.

server В руководстве приводятся примеры конфигурации для сервера VPS с одним ядром, 512Mb Ram, SSD. Тестовые сервера были развернуты у хостинг-провайдера Flops.ru, но вы можете воспользоваться любыми другими. Так как приведенные ниже настройки рассчитаны на максимальное использование кэшированных на дисках объектов, наиболее важным параметром будет производительность дисковой подсистемы.

Для установки сервера был выбран дистрибутив Debian 7 x86, так как в микроинстялляциях он обеспечивает более экономное использование памяти по сравнению с x64 версиями.

Подготовка серверного окружения.

После установки сервера установим с ним соединение по ssh.

Сразу после установки не назначены локали по умолчанию. Укажем основной локалью en_US.UTF-8.

echo LC_ALL=en_US.UTF-8 >>/etc/environment echo LANG=en_US.UTF-8 >>/etc/environment

echo LC_ALL=en_US.UTF-8 >>/etc/environment

echo LANG=en_US.UTF-8 >>/etc/environment

Для того, чтобы изменения вступили в силу, необходимо завершить сеанс SSH и начать его заново.

Обновим ПО сервера.

apt-get update apt-get upgrade

apt-get update

apt-get upgrade

Установим и настроим sudo.

Добавим нового пользователя, под которым будем получать доступ по SSH.

useradd -m -U -s /bin/bash webmaster passwd webmaster

useradd -m -U -s /bin/bash webmaster

passwd webmaster

Настроим sudo.

# При авторизации под root будет спрашивать пароль root, # а не пользователя. Defaults rootpw # Разрешить пользователю webmaster присваивать root права. webmaster ALL=(ALL) ALL

# При авторизации под root будет спрашивать пароль root,

# а не пользователя.

Defaults rootpw

# Разрешить пользователю webmaster присваивать root права.

webmaster ALL=(ALL) ALL

Теперь перелогинимся под новым пользователем и убедимся, что все хорошо.Если проблем не возникло ограничим доступ root пользователю к SSH.

sudo nano /etc/ssh/sshd_config

Найдем строку

и заменим ее на

После внесения изменений перезагрузим OpenSSH.

Ограничим возможности потенциальных злоумышленников к подбору паролей SSH. Воспользуемся утилитой fail2ban. Также позже мы настроим fail2ban для блокирования возможности подбора пароля к WordPress.

sudo apt-get install fail2ban

Для нашей задачи дополнительные настройки fail2ban не требуются.Теперь при шестикратном неправильном вводе пароля ssh, пользователь будет блокироваться с помощью iptables на 600 секунд.

Настроим синхронизацию времени.

#Установка необходимых пакетов sudo apt-get install ntp ntpdate #Установка сервера синхронизации sudo ntpdate -s pool.ntp.org #Запуск демона ntp sudo service ntp start

#Установка необходимых пакетов

sudo apt-get install ntp ntpdate

#Установка сервера синхронизации

sudo ntpdate -s pool.ntp.org

#Запуск демона ntp

sudo service ntp start

Настроим exim4 для отправки писем с сайта.

sudo apt-get install exim4 sudo dpkg-reconfigure exim4-config

sudo apt-get install exim4

sudo dpkg-reconfigure exim4-config

General type of mail configuration:Выберем верхний пункт internet site; mail is sent and received directly using SMTP.

System mail name:Укажем полное имя сервера, например admins.su.

IP-addresses to listen on for incoming SMTP connections:127.0.0.1

Other destinations for which mail is accepted:Оставим пустым.

Domains to relay mail for:Оставим пустым.

Machines to relay mail for:Оставим пустым.

Keep number of DNS-queries minimal (Dial-on-Demand)?No

Delivery method for local mail:Любое значение.

Split configuration into small files?Yes

Резюме выполненных действий:

1. Создан пользователь webmaster для доступа по ssh.2. Для повышения привилегий до root требуется дополнительный ввод пользователем webmaster пароля root.3. Настроена защита от перебора пароля по ssh.4. Настроена синхронизация времени.5. Настроена почта для отправки писем с сайта.

Установка LEMP.

Мы будем использовать установку из пакетов для простого управления обновлениями. Для того, чтобы получить более свежий nginx (стандартно ставится nginx 1.2.1), мы подключим родной репозиторий nginx.

Скачаем и установим PGP ключ сервера nginx.

mkdir ~/installfiles cd ~/installfiles wget http://nginx.org/keys/nginx_signing.key sudo apt-key add nginx_signing.key

mkdir ~/installfiles

cd ~/installfiles

wget http://nginx.org/keys/nginx_signing.key

sudo apt-key add nginx_signing.key

Добавим репозиторий nginx в список sources.list менеджера apt.

sudo nano /etc/apt/sources.list

deb http://nginx.org/packages/debian/ wheezy nginx deb-src http://nginx.org/packages/debian/ wheezy nginx

deb http://nginx.org/packages/debian/ wheezy nginx

deb-src http://nginx.org/packages/debian/ wheezy nginx

Обновим данные о доступных пакетах.

Теперь настало время установки необходимых для работы веб сервера пакетов.

sudo apt-get install nginx mysql-server php5-fpm php5-mysql php5-gd php-apc unzip

После недолгой установки мы получили работоспособную связку nginx, php-fpm,mysql.

Настройка LEMP.

Создадим директорию, в которой будут располагаться файлы сайта.

Вместо %SITENAME% необходимо указать имя сайта без http и www. Например admins.su или blog.admins.su

sudo mkdir /srv/%SITENAME% sudo chown -R www-data:www-data /srv/%SITENAME%

sudo mkdir /srv/%SITENAME%

sudo chown -R www-data:www-data /srv/%SITENAME%

Создадим базу данных для сайта.

ВАЖНО: В листинге требуется изменить название базы, имя пользователя и его пароль.

#Создание базы #вместо имени базы blog укажем желаемое. CREATE DATABASE blog; #Создание пользователя #вместо user укажем имя пользователя, вместо testpass #его пароль. CREATE USER 'user'@'localhost' IDENTIFIED BY 'testpass'; #Предоставление пользователю полного доступа в базу #Не забудьте сменить user и blog в строке ниже на #указанные в предыдущих запросах. GRANT ALL PRIVILEGES ON blog . * TO 'user'@'localhost'; #Сброс привилегий FLUSH PRIVILEGES; #Выход из MySQL EXIT;

#Создание базы

#вместо имени базы blog укажем желаемое.

CREATE DATABASE blog;

#Создание пользователя

#вместо user укажем имя пользователя, вместо testpass

#его пароль.

CREATE USER 'user'@'localhost' IDENTIFIED BY 'testpass';

#Предоставление пользователю полного доступа в базу

#Не забудьте сменить user и blog в строке ниже на

#указанные в предыдущих запросах.

GRANT ALL PRIVILEGES ON blog . * TO 'user'@'localhost';

#Сброс привилегий

FLUSH PRIVILEGES;

#Выход из MySQL

EXIT;

Теперь настроим FPM.

Удалим стандартную конфигурацию.

sudo rm /etc/php5/fpm/pool.d/www.conf

Создадим новую конфигурацию.

sudo nano /etc/php5/fpm/pool.d/blog.conf

ВАЖНО: В листинге необходима замена параметра %SITENAME% на название сайта без www.

# PHP-FPM conf # Это конфигурация для эффективной работы Wordpress на сервере 1CPU, 512 RAM. # Если на сервере вы хотите использовать более одного сайта, скопируйте данный файл # и замените в нем все вхождения названия старого сайта на называние нового. # Подробно о настройке вы можете прочитать, перейдя по ссылке # https://admins.su/rukovodstvo-po-nastrojke-bloga-wordpress-na-nginx # Замените %SITENAME% на имя вашего сайта без http и www. # Например admins.su или blog.admins.su [%SITENAME%] # Имя пользователя и группы, от которых будет производиться # запуск процессов php-fpm user = www-data group = www-data #Путь до сокета listen = /var/run/$pool.sock listen.owner = www-data listen.group = www-data listen.mode = 0660 # Режим управления worker процессами. pm = dynamic # Максимальное количество worker процессов. Этот параметр устанавливает # ограничение на число одновременных запросов, которые будут обслуживаться. pm.max_children = 8 # Количество worker процессов при старте. pm.start_servers = 3 # Минимальное количество поддерживаемых свободных worker процессов. pm.min_spare_servers = 2 # Максимальное количество поддерживаемых свободных worker процессов. pm.max_spare_servers = 4 # Число запросов дочернего процесса, после которого процесс будет перезапущен. # Это полезно для избежания утечек памяти при использовании сторонних библиотек. pm.max_requests = 600 # Ограничивает указанным деревом каталогов файлы, которые могут быть # доступны для PHP, включая сам файл. php_admin_value[open_basedir] = /srv/$pool:/tmp # Настройка записи медленных скриптов. request_slowlog_timeout = 5s slowlog = /var/log/php-fpm-slowlog-$pool.log

# PHP-FPM conf

# Это конфигурация для эффективной работы Wordpress на сервере 1CPU, 512 RAM.

# Если на сервере вы хотите использовать более одного сайта, скопируйте данный файл

# и замените в нем все вхождения названия старого сайта на называние нового.

# Подробно о настройке вы можете прочитать, перейдя по ссылке

# https://admins.su/rukovodstvo-po-nastrojke-bloga-wordpress-na-nginx

# Замените %SITENAME% на имя вашего сайта без http и www.

# Например admins.su или blog.admins.su

[%SITENAME%]

# Имя пользователя и группы, от которых будет производиться

# запуск процессов php-fpm

user = www-data

group = www-data

#Путь до сокета

listen = /var/run/$pool.sock

listen.owner = www-data

listen.group = www-data

listen.mode = 0660

# Режим управления worker процессами.

pm = dynamic

# Максимальное количество worker процессов. Этот параметр устанавливает

# ограничение на число одновременных запросов, которые будут обслуживаться.

pm.max_children = 8

# Количество worker процессов при старте.

pm.start_servers = 3

# Минимальное количество поддерживаемых свободных worker процессов.

pm.min_spare_servers = 2

# Максимальное количество поддерживаемых свободных worker процессов.

pm.max_spare_servers = 4

# Число запросов дочернего процесса, после которого процесс будет перезапущен.

# Это полезно для избежания утечек памяти при использовании сторонних библиотек.

pm.max_requests = 600

# Ограничивает указанным деревом каталогов файлы, которые могут быть

# доступны для PHP, включая сам файл.

php_admin_value[open_basedir] = /srv/$pool:/tmp

# Настройка записи медленных скриптов.

request_slowlog_timeout = 5s

slowlog = /var/log/php-fpm-slowlog-$pool.log

После того, как мы создали файл конфигурации php-fpm, необходимо перезагрузить сервис.

sudo service php5-fpm restart

Если потребуется создать еще один сайт на этом сервере, достаточно будет сделать копию конфигурационного файла, не забыв изменить имя сайта.

Теперь настроим nginx.

sudo nano /etc/nginx/nginx.conf

Изменим имя пользователя с nginx на www-data.

# user nginx; user www-data;

# user nginx;

user www-data;

Найдем и раскомментируем строки.

#tcp_nopush on; tcp_nopush on;

#tcp_nopush on;

tcp_nopush on;

Настроим gzip.

gzip on; gzip_min_length 1000; gzip_proxied any; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js; gzip_disable "MSIE [1-6]\.(?!.*SV1)"; gzip_comp_level 6;

gzip on;

gzip_min_length 1000;

gzip_proxied any;

gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js;

gzip_disable "MSIE [1-6]\.(?!.*SV1)";

gzip_comp_level 6;

Изменим время таймаута keepalive.

#keepalive_timeout 65; keepalive_timeout 10;

#keepalive_timeout 65;

keepalive_timeout 10;

Удалим стандартные конфигурационные файлы:

sudo rm /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/example_ssl.conf

Создадим новый конфигурационный файл.

sudo nano /etc/nginx/conf.d/blog.conf

ВАЖНО: В листинге необходима замена параметра %SITENAME% на название сайта без www.

# nginx site conf # Это конфигурация для эффективной работы Wordpress на сервере 1CPU, 512 RAM. # Если на сервере вы хотите использовать более одного сайта, скопируйте данный файл # и замените в нем все вхождения названия старого сайта на называние нового. # Подробно о настройке вы можете прочитать, перейдя по ссылке # https://admins.su/rukovodstvo-po-nastrojke-bloga-wordpress-na-nginx # Замените %SITENAME% на имя вашего сайта без http и www. # Например admins.su или blog.admins.su. server { listen *:80; server_name %SITENAME% www.%SITENAME%; access_log /var/log/nginx/%SITENAME%.access.log; error_log /var/log/nginx/%SITENAME%.error.log; root /srv/%SITENAME%; index index.php; # Не сообщать о отсутствии favicon, не писать информацию о доступе к нему в access лог . location = /favicon.ico { log_not_found off; access_log off; } # Не сообщать о отсутствии robots.txt, не писать информацию о доступе к нему в access лог. location = /robots.txt { allow all; log_not_found off; access_log off; } # Запретить доступ к файлам, начинающимся с точки. Например .htaccess location ~ /\. { deny all; } # Запретить доступ к файлам php в директориях uploads, files. location ~* /(?:uploads|files)/.*\.php$ { deny all; } rewrite /wp-admin$ $scheme://$host$uri/ permanent; # Для файлов отключить логирование, установить максимальный срок жизни кэша. location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ { access_log off; log_not_found off; expires 90d; } set $cache_uri $request_uri; # Запретить кэширование, если используются POST запросы. if ($request_method = POST) { set $cache_uri 'null cache'; } if ($query_string != "") { set $cache_uri 'null cache'; } # Запретить кэширование при доступе к служебным скриптам. if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") { set $cache_uri 'null cache'; } # Запретить кэширование, если используются cookie. if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") { set $cache_uri 'null cache'; } # Отдавать кэш. location / { try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html $uri $uri/ /index.php?$args ; } # Для файлов php отдавать обработку FASTCGI серверу. location ~ [^/]\.php(/|$) { root /srv/%SITENAME%; fastcgi_split_path_info ^(.+?\.php)(/.*)$; if (!-f $document_root$fastcgi_script_name) { return 404; } fastcgi_index index.php; include fastcgi_params; fastcgi_pass unix:/var/run/%SITENAME%.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; #fastcgi_param SCRIPT_FILENAME /srv/%SITENAME%/$fastcgi_script_name; } }

100

# nginx site conf

# Это конфигурация для эффективной работы Wordpress на сервере 1CPU, 512 RAM.

# Если на сервере вы хотите использовать более одного сайта, скопируйте данный файл

# и замените в нем все вхождения названия старого сайта на называние нового.

# Подробно о настройке вы можете прочитать, перейдя по ссылке

# https://admins.su/rukovodstvo-po-nastrojke-bloga-wordpress-na-nginx

# Замените %SITENAME% на имя вашего сайта без http и www.

# Например admins.su или blog.admins.su.

server {

listen *:80;

server_name %SITENAME% www.%SITENAME%;

access_log /var/log/nginx/%SITENAME%.access.log;

error_log /var/log/nginx/%SITENAME%.error.log;

root /srv/%SITENAME%;

index index.php;

# Не сообщать о отсутствии favicon, не писать информацию о доступе к нему в access лог .

location = /favicon.ico {

log_not_found off;

access_log off;

}

# Не сообщать о отсутствии robots.txt, не писать информацию о доступе к нему в access лог.

location = /robots.txt {

allow all;

log_not_found off;

access_log off;

}

# Запретить доступ к файлам, начинающимся с точки. Например .htaccess

location ~ /\. {

deny all;

}

# Запретить доступ к файлам php в директориях uploads, files.

location ~* /(?:uploads|files)/.*\.php$ {

deny all;

}

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Для файлов отключить логирование, установить максимальный срок жизни кэша.

location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {

access_log off; log_not_found off; expires 90d;

}

set $cache_uri $request_uri;

# Запретить кэширование, если используются POST запросы.

if ($request_method = POST) {

set $cache_uri 'null cache';

}

if ($query_string != "") {

set $cache_uri 'null cache';

}

# Запретить кэширование при доступе к служебным скриптам.

if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {

set $cache_uri 'null cache';

}

# Запретить кэширование, если используются cookie.

if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {

set $cache_uri 'null cache';

}

# Отдавать кэш.

location / {

try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html $uri $uri/ /index.php?$args ;

}

# Для файлов php отдавать обработку FASTCGI серверу.

location ~ [^/]\.php(/|$) {

root /srv/%SITENAME%;

fastcgi_split_path_info ^(.+?\.php)(/.*)$;

if (!-f $document_root$fastcgi_script_name) {

return 404;

}

fastcgi_index index.php;

include fastcgi_params;

fastcgi_pass unix:/var/run/%SITENAME%.sock;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

#fastcgi_param SCRIPT_FILENAME /srv/%SITENAME%/$fastcgi_script_name;

}

После сохранения конфигурационного файла необходимо проверить работоспособность конфигурации.

Если ошибок не обнаружено перезагрузим nginx.

sudo service nginx restart

Резюме выполненных действий:

1. Установлена БД MySQL. Создана база для WordPress, создан пользователь, заданы привилегии.2. Установлен и настроен php-fpm.3. Установлен и настроен nginx.

Установка WordPress.

Установка WordPress на сервер ничем не отличается от установки на Apache.

Загрузим последнюю версию WordPress на сервер, распакуем ее и изменим владельца файлов на www-data.

cd ~/installfiles/ wget http://wordpress.org/latest.zip unzip latest.zip sudo mv wordpress/* /srv/%SITENAME%/ sudo chown -R www-data:www-data /srv/%SITENAME%

cd ~/installfiles/

wget http://wordpress.org/latest.zip

unzip latest.zip

sudo mv wordpress/* /srv/%SITENAME%/

sudo chown -R www-data:www-data /srv/%SITENAME%

Далее перейдем к браузеру, продолжив установку там. Подробно установку описывать не буду, так как она интуитивно понятна.

Сразу после этого установим и активируем 2 необходимых для нормальной работы в LEMP плагина: Nginx Helper и WP Super Cache.

Плагин Nginx Helper в нашем случае не требует настройки , важен лишь факт его присутствия и активации. В условиях того, что за кэш будет отвечать плагин WP Super Cache, кнока Purge сверху работать не будет.

WP Super Cache требует незначительной настройки.

После активации необходимо выбрать нужный вид ЧПУ на странице http://%SITENAME%/wp-admin/options-permalink.php

В настройке самого плагина перейдем на вкладку «Настройки»

Выставим следующие настройки (с остальных галки необходимо снять):

[*]Кэшировать сессии просмотров для быстрого доступа. (Рекомендовано)[*]Использовать mod_rewrite для обслуживания кэша. (Рекомендовано)[*]Сжимать файлы кэша чтобы ускорить работу. (Рекомендовано)[*]Ошибка 304. Данная ошибка возникает тогда, когда страница не была изменена со времени прошлого запроса. (Рекомендовано)[*]304 support is disabled by default because some hosts have had problems with the headers used in the past.[*]Авто перестройка кэша. Гости блога увидят устаревшие версии страниц кэша пока новые будут генерироваться. (Рекомендовано)[*]Clear all cache files when a post or page is published or updated.[*]Дополнительная сверка кэша (очень редко может нарушить работу кэширования). (Рекомендовано)[*]Обновлять страницу при добавлении нового комментария к ней

После внесения изменений нажмите кнопку «Обновить».

При попытке сохранения сверху вы увидите следующее сообщение:

Права на запись должны быть обновлены

Необходимые для работы плагина права были изменены или отсуствуют. Прокрутите страницу вниз и нажмите кнопку Обновить правила Mod_Rewrite.

WP Super Cache не знает, что используется nginx и сообщает, что требуется изменить файл .htaccess. Для того, чтобы все заработало, надо разрешить ему сделать это. Прокрутим страницу вниз и нажмем кнопку Обновить правила mod_rewrite.

На вкладке «Обслуживание» установим галочку:

[*]Очищать кэш при ошибке.

И также нажмем кнопку «Обновить».

Теперь перейдем на вкладку Кэш и проверим, что все работает нажатием кнопки «Проверить».

Если вы увидели надпись «Временные штампы обоих вариантов страницы совпадают!«, значит все настройки сделаны правильно.

Резюме выполненных действий:

1. Установлен WordPress.2. Установлены и настроены плагины WP Super Cache и Nginx helper.

На этом настройка завершена.

На заметку:

Не забывайте, что скорость работы блога сильно зависит от используемых на нем плагинов. Они разрабатываются в основном энтузиастами и часто работают неоптимально и имеют ошибки, создающие дополнительную нагрузку.

В руководстве не упоминается тюнинг MySQL. Это отдельная большая тема, про которую я обязательно напишу.

admins.su

Переводим wordpress на HTTPS + nginx — Всё о web

Если Вы ещё не в курсе, гугл уже давно https сайты ранжирует выше, чем http. А в ближайших планах он начнёт помечать все http сайты как небезопасные. К счастью «Let’s Encrypt» предоставляет бесплатные сертификаты.

Первое что нужно сделать это ознакомиться с инструкцией: https://letsencrypt.org/getting-started/

Из которой мы узнаём что нам нужны Certbot и shh доступ к серверу. На этом месте я передаю пламенный привет всем любителям shared хостингов и конструкторов сайтов. 5$ за собственный сервер это так дорого, Вы же не лохи, у Вас же серьёзный бизнес.

Если у Вас нет ssh доступа к серверу, или Вы не знаете что это, не читайте дальше.

Получаем https сертификат

Заходим на страницу Certbot: https://certbot.eff.org/#ubuntuxenial-nginx и читаем её внимательно.

Действуем по инструкции, устанавливаем letsencrypt:

sudo apt-get install letsencrypt

Останавливаем nginx:

Сервер можно не останавливать, но тогда придётся сперва его переконфигурировать, чтобы доступ к папке /.well-known был всегда открыт.

Теперь получаем сам сертификат:

letsencrypt certonly --standalone -d example.com -d www.example.com

В процессе Вас попросят согласиться с условиями использования:

и ввести email для связи:

Файлы сертификата будут лежать в папке: /etc/letsencrypt/archive/_ВАШ_ДОМЕН, а в папке /etc/letsencrypt/live/_ВАШ_ДОМЕН будут лежать симлинки, которые нам потребуются позднее. Сертификаты, обязательно, забэкапте.

Переконфигурируем nginx под https

Открываем конфигурационный файл Вашего веб-сайта, это будет что-то вроде: /etc/nginx/sites-available/default

Всё где есть упоминание 80 порта комментируем, или удаляем, например:

listen 80; listen 80 default_server; listen [::]:80 default_server ipv6only=on;

listen 80;

listen 80 default_server;

listen [::]:80 default_server ipv6only=on;

И все подобные строки. Вместо них добавляем:

listen 443 ssl; server_name _ВАШ_ДОМЕН_ www._ВАШ_ДОМЕН_;

listen 443 ssl;

server_name _ВАШ_ДОМЕН_ www._ВАШ_ДОМЕН_;

Этим мы сообщили серверу, что слушать нужно ssl порт, а не http. Далее добавляем поддержку сертификата:

ssl_certificate /etc/letsencrypt/live/_ВАШ_ДОМЕН_/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/_ВАШ_ДОМЕН_/privkey.pem;

ssl_certificate /etc/letsencrypt/live/_ВАШ_ДОМЕН_/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/_ВАШ_ДОМЕН_/privkey.pem;

Запускаем nginx:

И проверяем. Теперь адрес http://_ВАШ_ДОМЕН_ не должен открываться, зато адрес https://_ВАШ_ДОМЕН_ должен работать.

Фиксим, в этот же конф. файл добавляем секцию:

> server { listen 80; server_name _ВАШ_ДОМЕН_ www._ВАШ_ДОМЕН_; return 301 https://$host$request_uri; }

server {

listen 80;

server_name _ВАШ_ДОМЕН_ www._ВАШ_ДОМЕН_;

return 301 https://$host$request_uri;

}

Перезапускаем nginx:

Опять проверяем адрес: http://_ВАШ_ДОМЕН_ сейчас он должен автоматически редиректиться на https адрес.

Теоретически, теперь у нас всё готово. Но мы можем ещё улучшить шифрование. Давайте cгенерируем сильную группу Дефи-Хелмана:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

И допишем конфиг nginx:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_dhparam /etc/ssl/certs/dhparam.pem; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256: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: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_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_stapling on; ssl_stapling_verify on; add_header Strict-Transport-Security max-age=15768000;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_prefer_server_ciphers on;

ssl_dhparam /etc/ssl/certs/dhparam.pem;

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256: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: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_session_timeout 1d;

ssl_session_cache shared:SSL:50m;

ssl_stapling on;

ssl_stapling_verify on;

add_header Strict-Transport-Security max-age=15768000;

Итоговый конфиг для nginx с https:

server { listen 80; server_name _ВАШ_ДОМЕН_ www._ВАШ_ДОМЕН_; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name _ВАШ_ДОМЕН_ www._ВАШ_ДОМЕН_; ssl_certificate /etc/letsencrypt/live/_ВАШ_ДОМЕН_/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/_ВАШ_ДОМЕН_/privkey.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_dhparam /etc/ssl/certs/dhparam.pem; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256: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: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_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_stapling on; ssl_stapling_verify on; add_header Strict-Transport-Security max-age=15768000; root /var/www/_ВАШ_ДОМЕН_; index index.html index.htm index.php; proxy_read_timeout 20; proxy_send_timeout 20; gzip on; gzip_disable "msie6"; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; location ~ /\. { deny all; } location ~* /(?:uploads|files)/.*\.php$ { deny all; } location = /xmlrpc.php { deny all; access_log off; log_not_found off; } location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ { access_log off; log_not_found off; } location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.0-fpm.sock; } }

server {

listen 80;

server_name _ВАШ_ДОМЕН_ www._ВАШ_ДОМЕН_;

return 301 https://$host$request_uri;

}

server {

listen 443 ssl;

server_name _ВАШ_ДОМЕН_ www._ВАШ_ДОМЕН_;

ssl_certificate /etc/letsencrypt/live/_ВАШ_ДОМЕН_/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/_ВАШ_ДОМЕН_/privkey.pem;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_prefer_server_ciphers on;

ssl_dhparam /etc/ssl/certs/dhparam.pem;

ssl_session_timeout 1d;

ssl_session_cache shared:SSL:50m;

ssl_stapling on;

ssl_stapling_verify on;

add_header Strict-Transport-Security max-age=15768000;

root /var/www/_ВАШ_ДОМЕН_;

index index.html index.htm index.php;

proxy_read_timeout 20;

proxy_send_timeout 20;

gzip on;

gzip_disable "msie6";

gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

location ~ /\. {

deny all;

}

location ~* /(?:uploads|files)/.*\.php$ {

deny all;

}

location = /xmlrpc.php {

deny all;

access_log off;

log_not_found off;

}

location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {

access_log off;

log_not_found off;

}

location / {

try_files $uri $uri/ /index.php?$args;

}

location ~ \.php$ {

include snippets/fastcgi-php.conf;

fastcgi_pass unix:/run/php/php7.0-fpm.sock;

}

Поделиться "Переводим wordpress на HTTPS + nginx"

Как настроить постоянные ссылки в Wordpress на nginx? — Toster.ru

У вас не конфиг, а какой-то винегрет...return 301 https://$server_name$request_uri; В рамках listen :80 вы редиректите на https?!location / { try_files $uri $uri/ /index.php?$args; } Этот фрагмент у вас вложен в такой жеlocation / { ... location / { try_files $uri $uri/ /index.php?$args; } ... } Что это за чушь? В этом конфиге даже разбираться не хочется.

Вот базовый конфиг, который работает и отвечает за пермалинки в том числе:

server { # Слушаем 80й порт listen 80; # Обслуживаем доменное имя, www тут же слушать не надо - будут дубликаты контента, печаль для SEO server_name example.com; # Корневая директория проекта root /var/www/example.com/httpdocs; # Индексы index index.php index.html; # Обработка запросов # $uri - существует ли конкретный файл # $uri/ - существует ли директория # /index.php?$args - если это не запрос на существующий файл или директорию, то перебрасываем на роутер WordPress (это и есть то, что надо для пермалинков) location / { try_files $uri $uri/ /index.php?$args; } # Обрабатываем PHP location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini fastcgi_pass unix:/var/run/php5-fpm.sock; # или php7.0-fpm.sock fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } # Все остальное # Запрещаем доступ к .htaccess location ~ /\.ht { deny all; } # Просим кешировать статику на Х дней, не писать в логи location ~* ^.+\.(js|css|swf|xml|txt|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ { access_log off; log_not_found off; expires 30d; } } # Отдельно слушаем домен с www и редиректим на основной server { # Слушаем 80й порт listen 80; # Обслуживаем доменное имя c www server_name www.example.com; # Отправляем запрос на основной домен return 301 $scheme://example.com$request_uri; } Снабдил комментами для ясности.

Что касается протокола HTTPS, то во-первых, его слушать надо на отдельном порту, а во-вторых, там еще SSL-сертификат надо подключать.

toster.ru

Настройка Nginx для Wordpress-сайта. | Techlist

Доброго времени суток читатели и гости моего блога. В этой статье мы продолжим настраивать Nginx и напишем конфигурацию для будущего сайта на основе WordPress. С предыдущей статьей можно ознакомиться здесь.

Во время установки Nginx был создан набор каталогов для размещения конфигурационных файлов. Сейчас нас интересуют следующие каталоги: /etc/nginx/sites-enabled и /etc/nginx/sites-available.

В каталоге /etc/nginx/sites-available создадим файл test, в котором будет задана конфигурация будущего сайта.

touch /etc/nginx/sites-available/test

Те, кто внимательно читал предыдущую статью, могут заметить что файл test создан в каталоге sites-available, а в nginx.conf был подключен каталог sites-enabled. Следовательно создадим символическую ссылку на файл test в каталоге /etc/nginx/sites-enabled, таким образом мы включим файл в конфигурацию сервера.

ln -s /etc/nginx/sites-available/test /etc/nginx/sites-enabled/test

Откроем файл test в редакторе и начнем писать конфигурацию сайта.

nano /etc/nginx/sites-available/test

Пропишем первый блок server {}, в который добавим запрет на обращение к серверу по ip-адресу.

# Запрет на обращение к серверу по ip-адресу server { listen 80 default_server; server_name _; return 444; }

# Запрет на обращение к серверу по ip-адресу

server {

listen 80 default_server;

server_name _;

return 444;

}

Теперь все попытки вызова сервера по ip-адресу на 80-м порту будут пресекаться, сервер будет возвращать таким клиентам ошибку 444 и разрывать с ними соединение.

Во втором блоке server {} пропишем редирект с www на основной домен. Если у вас есть доменное имя вида test.com, то будьте уверены что всегда найдется какой-нибудь умник, который добавит к нему в начало www. Если не добавить редирект в конфигурацию сайта, то такие люди не смогут попасть на него.

# Редирект с www на основное доменное имя server { listen 80; server_name www.test.com; return 301 $scheme://test.com$request_uri; }

# Редирект с www на основное доменное имя

server {

listen 80;

server_name www.test.com;

return 301 $scheme://test.com$request_uri;

}

При обращении к серверу по имени вида www.test.com, клиенту будет возвращен 301-ый ответ с указанием перейти по адресу test.com.

return 301 $scheme://test.com$request_uri;

Здесь можно использовать два варианта ответов - 301 и 302, но они имеют существенное различие. Ответ 301 (Moved Permanently - Перемещено навсегда) кэшируется браузером клиента и в следующий раз браузер пойдет по адресу из кэша и так будет происходить все время, пока кэш не будет очищен. Ответ 302 (Moved Temporarily - Перемещено временно) не кэшируется браузером клиента и в следующий раз запрос к серверу будет послан заново.

Добавим третий блок server {}, в котором будет находиться все оставшееся.

Начнем с указания порта, который будет слушать сервер. По умолчанию это 80-й порт.

Укажем доменное имя сайта, для примера я использую test.com.

Добавим корневую директорию сайта и тип индексного файла.

root /var/www/test/public; index index.php;

root /var/www/test/public;

index index.php;

Укажем местонахождение лог-файлов доступа (access) и ошибок (error).

access_log /var/www/test/logs/access.log; error_log /var/www/test/logs/error.log;

access_log /var/www/test/logs/access.log;

error_log /var/www/test/logs/error.log;

Основная часть почти готова, уже в таком виде сервер может обслуживать простенькие сайты на html, только тогда index.php нужно будет заменить на index.html.

Но поскольку сайт будет работать на WordPress, то необходимо добавить набор некоторых опций и правил, согласно WordPress-документации для Nginx.

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

Создадим два дополнительных файла в каталоге /etc/nginx/conf.

touch /etc/nginx/conf/restrictions.conf touch /etc/nginx/conf/wordpress.conf

touch /etc/nginx/conf/restrictions.conf

touch /etc/nginx/conf/wordpress.conf

Подключим созданные файлы внутри третьего блока server {}, сразу после лог-файлов. Подобное подключение выполняется там где оно прописано и равносильно записи внутри самого блока. Файлы должны включаться в такой последовательности.

# Подключение restrictions.conf include /etc/nginx/conf/restrictions.conf; # Подключение wordpress.conf include /etc/nginx/conf/wordpress.conf;

# Подключение restrictions.conf

include /etc/nginx/conf/restrictions.conf;

# Подключение wordpress.conf

include /etc/nginx/conf/wordpress.conf;

Готовый файл test выглядит так.

### хост-файл test ### ### Включается в контекст http {}, файла nginx.conf ### Располагается в /etc/nginx/sites-available # Запрет на обращение к серверу по ip-адресу server { listen 80 default_server; server_name _; return 444; } # Редирект с www на основное доменное имя server { listen 80; server_name www.test.com; return 301 $scheme://test.com$request_uri; } server { # Порт который будет слушать nginx listen 80; # Имя сайта server_name test.com; # Корневая директория и индексный файл root /var/www/test/public; index index.php; # Лог-файлы access_log /var/www/test/logs/access.log; error_log /var/www/test/logs/error.log; # Подключение restrictions.conf include /etc/nginx/conf/restrictions.conf; # Подключение wordpress.conf include /etc/nginx/conf/wordpress.conf; }

### хост-файл test ###

### Включается в контекст http {}, файла nginx.conf

### Располагается в /etc/nginx/sites-available

# Запрет на обращение к серверу по ip-адресу

server {

listen 80 default_server;

server_name _;

return 444;

}

# Редирект с www на основное доменное имя

server {

listen 80;

server_name www.test.com;

return 301 $scheme://test.com$request_uri;

}

server {

# Порт который будет слушать nginx

listen 80;

# Имя сайта

server_name test.com;

# Корневая директория и индексный файл

root /var/www/test/public;

index index.php;

# Лог-файлы

access_log /var/www/test/logs/access.log;

error_log /var/www/test/logs/error.log;

# Подключение restrictions.conf

include /etc/nginx/conf/restrictions.conf;

# Подключение wordpress.conf

include /etc/nginx/conf/wordpress.conf;

}

restrictions.conf

Добавляем содержимое в restrictions.conf.

nano /etc/nginx/conf/restrictions.conf

Немного облегчим работу сервера снизив на него нагрузку. Не будем отмечать в логах доступа запросы к файлам favicon.ico и robots.txt. Также не станем фиксировать 404-ю ошибку в случае их отсутствия.

location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; }

location = /favicon.ico {

log_not_found off;

access_log off;

}

location = /robots.txt {

allow all;

log_not_found off;

access_log off;

}

Немного обезопасим работу сервера путем запрета доступа к скрытым файлам и запрета выполнения php-файлов в директории uploads.

# Запрещаем доступ к скрытым файлам location ~ /\. { deny all; } # Запрещаем доступ к файлам .php в директории uploads location ~* /(?:uploads|files)/.*\.php$ { deny all; }

# Запрещаем доступ к скрытым файлам

location ~ /\. {

deny all;

}

# Запрещаем доступ к файлам .php в директории uploads

location ~* /(?:uploads|files)/.*\.php$ {

deny all;

}

Готовый файл restrictions.conf выглядит так.

### restrictions.conf ### ### Включается в контекст server {} ### Располагается в /etc/nginx/conf location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } # Запрещаем доступ к скрытым файлам location ~ /\. { deny all; } # Запрещаем доступ к файлам .php в директории uploads location ~* /(?:uploads|files)/.*\.php$ { deny all; }

### restrictions.conf ###

### Включается в контекст server {}

### Располагается в /etc/nginx/conf

location = /favicon.ico {

log_not_found off;

access_log off;

}

location = /robots.txt {

allow all;

log_not_found off;

access_log off;

}

# Запрещаем доступ к скрытым файлам

location ~ /\. {

deny all;

}

# Запрещаем доступ к файлам .php в директории uploads

location ~* /(?:uploads|files)/.*\.php$ {

deny all;

}

wordpress.conf

Добавляем содержимое в wordpress.conf.

nano /etc/nginx/conf/wordpress.conf

Первым делом установим правило обработки входящих запросов и дальнейшей их передачи на обработку PHP. Работает оно примерно так. Все запросы поступающие к серверу должны передаваться на обработку PHP/Wordpress, но если запрос обращен к конкретному файлу существующему на сервере, то такой файл следует отдать самостоятельно, не прибегая к помощи PHP.

Правило задается директивой try_files, сначала проверяется существование нужного файла $uri, потом на его наличие проверяются директории $uri/, а если запрос не является запросом конкретного файла, то он передается на index.php, для обработки силами WordPress. Правило задается внутри контекста "location/".

location / { try_files $uri $uri/ /index.php?$args; }

location / {

try_files $uri $uri/ /index.php?$args;

}

Следующее выражение добавляет конечный слэш "/" к запросам содержащим "/wp-admin".

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

Настроим передачу запросов к FastCGI-серверу.

location ~ \.php$ { try_files $uri =404; include fastcgi_params; fastcgi_index index.php; fastcgi_pass unix:/var/run/php-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }

location ~ \.php$ {

try_files $uri =404;

include fastcgi_params;

fastcgi_index index.php;

fastcgi_pass unix:/var/run/php-fpm.sock;

fastcgi_param SCRIPT_FILENAME

$document_root$fastcgi_script_name;

}

Теперь запросу "index.php" будет соответствовать не только префиксный location "/", а еще и регулярное выражение "\.php$". Следовательно запрос будет обработан в контексте регулярного выражения и передан FastCGI-серверу через UNIX-сокет - /var/run/php-fpm.sock. Сокет задается в значении директивы fastcgi_pass.

В fastcgi_param SCRIPT_FILENAME задается значение двух переменных: $document_root и $fastcgi_script_name. Переменная $document_root задает директорию /var/www/test/public, переменная $fastcgi_script_name задает значение "/index.php". Теперь FastCGI-сервер знает местонахождение файла для выполнения.

Готовый файл wordpress.conf выглядит так.

### wordpress.conf ### ### Включается в контекст server {} ### Располагается в /etc/nginx/conf location / { try_files $uri $uri/ /index.php?$args; } rewrite /wp-admin$ $scheme://$host$uri/ permanent; location ~ \.php$ { try_files $uri =404; include fastcgi_params; fastcgi_index index.php; fastcgi_pass unix:/var/run/php-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }

### wordpress.conf ###

### Включается в контекст server {}

### Располагается в /etc/nginx/conf

location / {

try_files $uri $uri/ /index.php?$args;

}

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

location ~ \.php$ {

try_files $uri =404;

include fastcgi_params;

fastcgi_index index.php;

fastcgi_pass unix:/var/run/php-fpm.sock;

fastcgi_param SCRIPT_FILENAME

$document_root$fastcgi_script_name;

}

Написанную конфигурацию можно проверить. Ответ должен быть таким как у меня.

nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Если все в порядке, то можно перезапустить сервер и переходить к установке WordPress. Описание установки WordPress в следующей статье. До встречи.

techlist.top

Как настроить NGINX для ЧПУ Wordpress? — Toster.ru

Здравствуйте, помогите заставить работать .htaccess на Nginx + Php-fpm

Есть сайт на Wordpress, в качестве панели использую VestaCP последней версии.

Раньше мне достаточно было выбрать шаблон Шаблон WebNGINX "wordpress2" для домена. После установки последней версии(16) не работают все внутренние ссылки с этим шаблоном. Главная грузится должным образом, а вот внутренние выдают 404

Нашел такую инструкцию (goo.gl/uik5eU):

"try_files $uri $uri/ /index.php?$args;" /home/мой пользователь/conf/web/. "try_files $uri $uri/ /index.php?$args;" Needs to be added to the location section of each website you host. Пробовал править шаблон wordpress2, находящийся по адресу /usr/local/vesta/data/templates/web/nginx/php-fpm/wordpress2.tpl /usr/local/vesta/data/templates/web/nginx/php-fpm/wordpress2.stpl

Но там уже присутствует этот код в первой секции location. Приведу полный конфиг шаблона wordpress2:

server { listen %ip%:%web_port%; server_name %domain_idn% %alias_idn%; root %docroot%; index index.php index.html index.htm; access_log /var/log/nginx/domains/%domain%.log combined; access_log /var/log/nginx/domains/%domain%.bytes bytes; error_log /var/log/nginx/domains/%domain%.error.log error; location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location / { try_files $uri $uri/ /index.php?$args; location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ { expires max; } location ~ [^/]\.php(/|$) { fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; if (!-f $document_root$fastcgi_script_name) { return 404; } fastcgi_pass %backend_lsnr%; fastcgi_index index.php; include /etc/nginx/fastcgi_params; } } error_page 403 /error/404.html; error_page 404 /error/404.html; error_page 500 502 503 504 /error/50x.html; location /error/ { alias %home%/%user%/web/%domain%/document_errors/; } location ~* "/\.(htaccess|htpasswd)$" { deny all; return 404; } include /etc/nginx/conf.d/phpmyadmin.inc*; include /etc/nginx/conf.d/phppgadmin.inc*; include /etc/nginx/conf.d/webmail.inc*; include %home%/%user%/conf/web/nginx.%domain%.conf*; }

службы рестартилservice nginx restartservice php-fpm restart (на всякий пожарный)

Если выбрать Шаблон WebNGINX "wordpress" то внутренние не выдают больше 404, а просто показывают контент главной. Люди добрые, помогите как можно быстрее наладить работу ЧПУ на Nginx для Wordpress. До обновления VestaCP до 16 версии все с шаблонами работало на ура...

Жду ваших мнений, решений, что я делаю не так и рекоммендаций

P.S.Свежеустановленный wordpress-4.5.2-ru_RU ведет себя аналогично на шаблоне WebNGINX "wordpress2" - выдает 404, на шаблоне "wordpress" показывает главную

toster.ru

Кэшируем Wordpress средствами Nginx | Блог Боши

Wordpress далеко не самая производительная платформа для ведения блогов, и крупные сайты, как правило, используют кэширование для ускроения его работы. Для wordpress, есть много популярных дополнений реализующих кэширование, но все они на мой взгляд довольно осложненные, и, как правило, требуют либо установки дополнительного программного обеспечения, такого как, например, Varnish или memcached, либо перекладывают кэширование на плечи PHP который тоже производительным не назовешь. В этом посте я расскажу как настроить кэширование wordpress средствами nginx, без установки дополнительного ПО.

В nginx есть FastCGI модуль который предоставляет директивы, позволяющие кэшировать ответ от fastcgi. Использование данного модуля избавляет нас от необходимости использовать сторонние средства кэширования. Модуль так же позволяет нам не кэшировать часть ресурсов опираясь на различные параметры запроса, такие как, например: тип (GET, POST), куки, адрес страницы и другие. Сам модуль умеет исключительно добавлять в кэш, но не умеет его очищать или удалять отдельные записи из него. Без очистки кэша при добавлении, редактировании и добавлении комментария к посту кэш не будет обновляться, и сделанные изменения будут видны только с большой задержкой, поэтому для очистки кэша мы будем использовать сторонний nginx модуль - nginx_cache_purge.

Настройка nginx

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

nginx -V 2>&1 | grep -o nginx-cache-purge

Если после выполнения команды вы видите nginx-cache-purge, то значит можно продолжать. Если после выполнения команды ничего не появилось, то у вас вероятно какой-то из старый дистрибутивов ubuntu, в котором nginx собран без поддержки этого модуля. В данном случае необходимо переустановить nginx из стороннего ppa:

sudo add-apt-repository ppa:rtcamp/nginx sudo apt-get update sudo apt-get remove nginx* sudo apt-get install nginx-custom

Настроим nginx. Откроем файл с настройками виртуального хоста, и приведем его к примерно такому содержимому:

fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m; fastcgi_cache_key "$scheme$request_method$host$request_uri"; fastcgi_cache_use_stale error timeout invalid_header http_500; fastcgi_ignore_headers Cache-Control Expires Set-Cookie; # Upstream to abstract backend connection(s) for php upstream php { server unix:/var/run/php5-fpm.sock fail_timeout=0; } server { listen 80; server_name .example.com; root /var/www/example.com/html; index index.php; error_log /var/www/example.com/log/error.log; access_log /var/www/example.com/log/access.log; set $skip_cache 0; # POST requests and urls with a query string should always go to PHP if ($request_method = POST) { set $skip_cache 1; } if ($query_string != "") { set $skip_cache 1; } # Don't cache uris containing the following segments if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") { set $skip_cache 1; } # Don't use the cache for logged in users or recent commenters if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") { set $skip_cache 1; } location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { try_files $uri =404; include fastcgi_params; fastcgi_pass php; fastcgi_cache_bypass $skip_cache; fastcgi_no_cache $skip_cache; fastcgi_cache WORDPRESS; fastcgi_cache_valid 60m; } location

the-bosha.ru

Настройка wordpress сайта на сервере Nginx. Wordpress nginx