nginx

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

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

Это руководство написано по использованию nginx как самостоятельного вебсервера, вместо Apache, без Apache. Обратите внимание, что nginx не является полной и равноценной заменой всем возможностям Apache, вам следует знать о ключевых различиях, которые затронут WordPress:

  • nginx не использует файлы конфигурации на уровне каталогов, такие как .htaccess в Apache или web.config в IIS. Все изменения конфигурации управляются администратором сервера, WordPress не может вносить туда изменения способом доступным для IIS или Apache.
  • WordPress не может самостоятельно создать или обновить правила перезаписи ссылок.

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

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

Общая конфигурация и поддержка сети сайтов Общая конфигурация и поддержка сети сайтов

Для работы WordPress на nginx вам потребуется настроить обработчик PHP (backend), это может быть php-fpm, php-cgi или fastcgi. Оптимальным и простым в установке вариантом является использование php-fpm, который поддерживается начиная с PHP 5.3

Наверх ↑

Основной файл конфигурации Основной файл конфигурации

Обычно это /etc/nginx/nginx.conf , но может и располагаться и в другом месте в зависимости от вашего дистрибутива операционной системы и источника пакетов nginx.

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

# Секция http управляет глобальными настройками для всех виртуальных серверов (сайтов) на сервере. Некоторые директивы могут быть переопределены в секциях настройки отдельных виртуальных серверов 
http {
# Разрешает сжатие HTTP-трафика
gzip on;

# Эта директива устанавливает максимальный размер загружаемого файла, должна быть не менее чем значение директивы настройки PHP max_upload
client_max_body_size 64m;

Настройка PHP обработчика может быть произведена так (как в глобальном контексте http {} так и для каждого сайта в контекстах server {} , настройки должны соответствовать тем, что указаны в настройках директивы listen пула (pool) для php-fpm

upstream php {
# перепроверьте путь к сокету или номер порта TCP и выберите ОДНУ из двух директив             
 server unix:/tmp/php-fpm.sock;
 server 127.0.0.1:9000;
 }

Во многих дистрибутивах конфигурации для отдельных сайтов (контекст server{} ) вынесены в папку sites-available, на которые создаются символические ссылки в папке sites-enabled. Конфигурации включенных сайтов загружаются в конце nginx.conf директивой include

include sites-enabled/*;

Наверх ↑

Некоторые полезные директивы для конфигурации сайта Некоторые полезные директивы для конфигурации сайта

server {
# Это адрес сайта
    server_name example.com;
# Путь к папке с файлами сайта (корню)
    root /var/www/example.com;
# Файл индекса сайта.
    index index.php;
# А вот показ индекса файлов в папках без файла-индекса отключим
    autoindex off;
# Журнал доступа может быть записан в отдельный файл с отложенной записью
access_log  /var/log/jinx/www-example.com.log main buffer=2k flush=30s;
# А для некоторых файлов журнал доступа можно и вовсе отключить
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;
}

# Вот так можно закрыть доступ к папке кеша (плагинов)
location ~ ^/wp-content/cache { deny all; }

# Запрет выполнения PHP в папках для загруженных файлов
location ~* /(?:uploads|files)/.*\.php$ {
    deny all;
}
# А директивы ниже показывают как можно установить заголовки кеширования для статических ресурсов (а также изменить сжатие gzip для некоторых из них)
location ~* ^.+\.(jpg|jpeg|png|ico|gif|swf|webp|srv)$ { expires 3w; gzip off; }
location ~* ^.+\.(css|js)$ { expires 7d; add_header Vary Accept-Encoding; }
location ~* ^.+\.(eot|ttf|woff|woff2)$ { expires 92d; add_header Vary Accept-Encoding; }

# Не забываем добавить обработчик для PHP
location ~ \.php$ {
 include fastcgi.conf;
 fastcgi_intercept_errors on;
 fastcgi_param  SCRIPT_FILENAME  $root$fastcgi_script_name;
# Должен соответствовать имени, определенному в примере директивы upsteam выше.
 fastcgi_pass php;
        }
# Ну и наконец, правила для "красивых постоянных ссылок"
location / { try_files $uri $uri/ /index.php?$args; }
# поближе к закрытию контекста server
}

Обязательно убедитесь в том, что в php.ini установлено значение константы

cgi.fix_pathinfo=0

это предотвратит исполнение иных (без расширения .php) файлов, возможно содержащих PHP код, возможным злоумышленником.

Много других рецептов и хитростей по конфигурированию nginx можно посмотреть например здесь: https://www.nginx.com/resources/wiki/start/topics/recipes/wordpress/

Наверх ↑

Конфигурация для сети сайтов Конфигурация для сети сайтов

С тех пор, как установка сети сайтов стала частью WordPress (а не отдельным пакетом WPMU), дополнительные правила для nginx не требуются, вам следует лишь иметь идентичные блоки server{} для всех сайтов вашей сети, вы можете создать отдельный файл и включать его в конфигурации сайтов директивой include. Переопределяя лишь server_name и если вам нужно — access_log.

Если же ваша сеть сайтов имеет общий домен, то вы можете разместить её на одном виртуальном сервере, с одним блоком конфигурации server{}.

Директива server_name .example.com; будет работать с любым доменом третьего уровня в домене example.com.

Внимание: вы можете оставить комментарий обратной связи к этой статье.

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

Также вы можете поучаствовать в составлении и дополнении документации на русском языке.
Подробнее тут.

Была ли эта статья полезной? Как мы можем улучшить её?