Просмотр кода страницы Веб-сервер на основе Nginx и PHP5-FPM

Существуют различные схемы построения веб-серверов для передачи данных по протоколу HTTP. Среди них достойное место по производительности занимают схемы с использованием «Nginx» в качестве внешнего (кэширующего, front-end) сервера. «Nginx» разработан для отдачи статических данных, при этом, он показывает высокое быстродействие и нагрузочную способность (см. Nginx vs Cherokee vs Apache vs Lighttpd), генерировать же динамическое содержимое он не способен. Поэтому, он часто применяется в связке с внутренним (back-end) сервером для обработки динамических данных которые потом отдаются «Nginx» как статические без участия внутреннего сервера. В качестве внутреннего сервера может применяться «Apache2» или, что и рассматривается в данной статье, «PHP-FPM».

В данной статье рассматривается установка и настройка связки Nginx и PHP-FPM на локальной ЭВМ, если требуется работа на выделенном сервере, то следует обратится к более серьезным инструкциям или/и непосредственной помощи специалистов
Данная статья написана любителем, никто из профессионалов её не проверял, она может содержать ошибки и вредные советы и потому нацелена на тех, кто хочет поиграться
=== Установка ===
Сервер «Nginx» поставляется в одноименном пакете «nginx» и его установка производится, например, командой в терминале

 sudo apt-get install nginx nginx-extras
Установку же «PHP-FPM» можно произвести, например, командой

 sudo apt-get install php5-cli php5-common php5-mysql php5-gd php5-fpm php5-cgi php5-fpm php-pear php5-mcrypt
=== Безопасность ===
Наряду с уязвимостями присущими ПО сервера, присутствуют также те, что обусловлены неосторожностью администратора сервера. Для их устранения следует соблюдать меры предосторожности:

Должно быть запрещено выполнение PHP-кода из открытых для записи директорий. Например, директории для загрузки аватаров, файлов или директории доступные также FTP-серверу, который позволяет произвести запись в них.
Следует следить за логами работы сервера, это позволяет выявить попытку взлома как можно раньше и минимизировать угрозу дальнейшего ущерба.
Необходимо обновлять ПО (в том числе «CMS» — системы управления содержимым сайтов), но не обязательно тогда когда выходят новые версии (они тоже могут содержать новые уязвимости), а, прежде всего, тогда, когда обновление связано с устранением серьезной уязвимости.
Обязательное наличие файлов для отката состояния сервера (в том числе, конфигурационных файлов).
Осторожное и осмотрительное следование подобным инструкциям (см. Don’t trust the tutorials: check your configuration!)
=== Настройка ===
Настройка состоит из двух этапов — настройки «Nginx» и «PHP-FPM». Для начала необходимо остановить процессы (демоны) «Nginx» и «PHP-FPM», например, командами

 sudo service nginx stop
 sudo service php5-fpm stop
=== Настройка PHP-FPM ===
Прежде всего, следует открыть файл «/etc/php5/fpm/php.ini» для редактирования, например, командой

 sudo nano /etc/php5/fpm/php.ini
после чего, найти строчку содержащую «cgi.fix_pathinfo», которая по-умолчанию выглядит так (закомментирована)

 ;cgi.fix_pathinfo = 1
и привести её к виду

 cgi.fix_pathinfo = 0
Это призвано устранить опасность неправильно трактования (и возникающей уязвимости) запросов вида «/image.gif/foo.php» (см. Don’t trust the tutorials: check your configuration!, Nginx 0day exploit for nginx + fastcgi PHP).

Если планируется загрузка больших файлов (важно для ownCloud версий < 8, в новой версии 8 и выше имеется отдельный файл для этих настроек), то можно увеличить максимальный объем загружаемых данных, например, до 200 МБ

 post_max_size = 200M
и ниже

 upload_max_filesize = 200M
Затем сохранить изменения в файле.

Далее, необходимо отрыть для редактирования файл «/etc/php5/fpm/pool.d/www.conf», например, командой

 sudo nano /etc/php5/fpm/pool.d/www.conf
найти строчку с параметров «security.limit_extensions» и привести её к виду

 security.limit_extensions = .php .php3 .php4 .php5
Эта настройка ограничит выполнение файлов по расширению имени. В этом же файле найти строчку с параметром «listen» и привести её к виду

 listen = /var/run/php5-fpm.sock
Это определит файл для связи «Nginx» с «PHP-FPM» (сокет). В целях безопасности запрещаем какой-попало программе писать в сокет (см. Обновление PHP 5.5.12 с устранением уязвимости в PHP-FPM ) путём указания прав доступа к сокету. Находим строчки с описанием параметров «listen.owner», «listen.group» и «listen.mode» (по-умолчанию они закомментированы) и приводим их к виду

 listen.owner = www-data
 listen.group = www-data
 listen.mode = 0660
Следует сохранить изменения в файле и перезапустить «PHP-FPM», например, командой

 sudo service php5-fpm restart
Можно убедится в том, что права доступа к сокету установлены верно:

 ls -la /var/run/php5-fpm.sock
Права доступа должны быть «srw-rw—-», владелец «www-data» (группа «www-data»), например,

 srw-rw---- 1 www-data www-data 0 May  2 16:36 /var/run/php5-fpm.sock
=== Настройка Nginx ===
Основные настройки «Nginx» хранятся в файле «/etc/nginx/nginx.conf». Настройки базового сайта хранятся в файле «/etc/nginx/sites-available/default». Базовый конфигурационный файл сайта принято помещать в папку «/etc/nginx/sites-available/» и затем включить его путём добавления символической ссылки на этот файл в папке «/etc/nginx/sites-enabled/». Например, создадим конфигурационный файл для сайта с доменным именем (для примера выбрано «example.com») в названии для удобства

 sudo touch /etc/nginx/sites-available/example.com
 sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
и откроем его для редактирования

 sudo nano /etc/nginx/sites-available/example.com
При редактировании данного файла необходимо учитывать синтаксис конфигурации «Nginx» (см. HttpCoreModule), готовые советы по настройке связки «Nginx + PHP-FPM» (см. PHPFcgiExample) и следовать некоторым правилам/рекомендация для достижения эффективной работы сервера (см. Pitfalls).
Описывать конфигурацию сайта в одном файле не очень удобно, для увеличения читабельности конфигурационного файла и гибкости настройки можно воспользоваться директивой «include» позволяющей указать «Nginx», что следует загрузить другой конфигурационный файл и затем продолжить чтение текущего. Создадим в папке «/etc/nginx/» каталог «common», где будут хранится общие настройки для сайта, которые затем будут подгружаться из основного конфигурационного файла «/etc/nginx/sites-available/example.com» с помощью директивы «include»

 sudo mkdir /etc/nginx/common
Некоторые запросы «Nginx» будет перенаправлять к «PHP-FPM», который в данном случае называется сервером выгрузки данных (upstream). Укажем как следует это делать. Создадим файл конфигурации с описанием серверов выгрузки данных

 sudo touch /etc/nginx/common/upstream
и откроем его для редактирования

 sudo nano /etc/nginx/common/upstream
и добавим в него строчки

 upstream php-fpm
 {
 	# PHP5-FPM сервер
 	server unix:/var/run/php5-fpm.sock;
 }
где «php-fpm» – название для сервера выгрузки данных, для удобства.

Редактируем файл «/etc/nginx/sites-available/example.com». Добавляем строчку

 include common/upstream;
для загрузки созданого выше конфигурационного файла. Как можно видеть – допускается указание относительного пути к файлу.

Далее описываем перенаправление от HTTP к HTTPS, если, конечно, это планируется. В таком случае необходимо наличие сертификатов для HTTPS (см. Сертификаты)

 server
 {
 	listen 80;
 	server_name example.com www.example.com;
 	return 301  https://$server_name$request_uri;
 }
иначе, можно опустить эти строчки.

Начинаем описывать конфигурацию сайта

 server
 {
 Сетевой порт для приема соединений: 80 — обычный HTTP; 443 — HTTPS (см. выше)
 
 	# Порты
 	listen	80;
 	listen	443	ssl;	# использовать шифрование для этого порта
Корневая директория сайта работающего на данном сервере

 	root			/var/www;
Возможные имена индексных файлов (их «Nginx» пытается открыть если он получил запрос вида «example.com/», вместо явного «example.com/index.html»)

 	index			index.php index.html index.htm;
Имя сервера – обычно доменное имя Вашего сервера

 	server_name		example.com www.example.com;
=== Шифрование ===
Необходимо наличие сертификата «*.crt» или «*.pem» и приватного секретного ключа «*.key» (см. Сертификаты). Самоподписанный сертификат можно сгенерировать командой в терминале (см. man openssl, man req)

 openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout example.com_nginx.key -out example.com_nginx.crt
При этом программа запросит данные, среди них «commmon name» — следует указать доменное имя сервера. Можно использовать шаблон, если необходимо учесть домены нижнего уровня, например, «*example.com». Иначе могут возникнуть проблемы с некоторыми программами, например, «davfs2» (см man davfs2.conf).

Но можно пойти дальше и воспользоваться сервисом «StartSSL» где выдают бесплатные сертификаты для личного пользования (см. startssl.com и Получение и установка бесплатного SSL-сертификата), но сам приватный ключ (который нельзя никому показывать) лучше сгенерировать самому, например, так

 openssl genrsa -out example_nginx.com.key 4096
затем сформировать файл запроса на подпись (при этом прийдётся вводить те же данные что и для генерации самоподписанного сертификата, но это не важно, т.к. сервис «StartSSL» проигнорирует все кроме публичного ключа)

 openssl req -new -sha256 -key example.com_nginx.key -out example.com.csr
открыть полученный файл текстовым редактором

 nano example.com.csr
и скопировать его содержимое в текстовое поле на сайте «StartSSL» для запроса сертификата (см. ссылки на подробные инструкции выше). Файл *.csr больше не нужен. Затем загружаем подписанный сертификат (например, файл называется signed.crt) и объединяем его с сертификатом того кто этот сертификат подписал

 wget https://www.startssl.com/certs/sub.class1.server.ca.pem
 cat signed.crt sub.class1.server.ca.pem > example.com_nginx.crt
Файл «signed.crt» можно удалить.

Копируем секретный ключ в системную папку и выставляем права доступа

 sudo cp example.com_nginx.key /etc/ssl/private/
 sudo chown www-data:www-data /etc/ssl/private/example.com_nginx.key
 sudo chmod 400 /etc/ssl/private/example.com_nginx.key
И в соседнюю папку сам сертификат

 sudo cp example.com_nginx.crt /etc/ssl/certs/
Для пущей надежности можно сгенерировать ключ Диффи-Хеллмана (тоже секретный файл который очень долго генерируется)

 openssl dhparam -out example.com.dh.key 4096
 sudo cp example.com_nginx.dh.key /etc/ssl/private/
 chown www-data:www-data example.com_nginx.dh.key
 chmod 400 example.com_nginx.dh.key
Продолжаем редактировать конфигурационные файлы.

Для удобства описываем настройки шифрования во внешнем файле «/etc/nginx/common/ssl»

 sudo touch /etc/nginx/common/ssl
Редактируем файл «/etc/nginx/common/ssl»

 sudo nano /etc/nginx/common/ssl
Файлы сертификатов для «HTTPS»

 ssl_certificate /etc/ssl/certs/example.com_nginx.crt;		# сертификат (можно свободно распространять)
 ssl_certificate_key /etc/ssl/private/example.com_nginx.key;	# приватный ключ (секретный файл - НИКОМУ НЕ ПОКАЗЫВАТЬ)
Дополнительные параметры требуемые для «HTTPS»

 ssl_dhparam				/etc/ssl/private/example.com_nginx.dh.key;	# писать эту строчку только если файл есть
 ssl_session_timeout			20m;	# время 20 минут
 ssl_session_cache			shared:SSL:20m;	# размер кеша 20МБ
 ssl_protocols				TLSv1 TLSv1.1 TLSv1.2;
 ssl_prefer_server_ciphers		on;
 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:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK;
На этом настройки «SSL» в «Nginx» завершены, сохраняем и закрываем файл. После завершения описания конфигурации (см. ниже) можно будет проверить надежность сервисом «SSLLabs»

Продолжаем редактировать файл «/etc/nginx/sites-available/example.com». Подгружаем созданный выше конфигурационный файл с описанием настроек SSL

	# Настройка шифрования SSL
	include common/ssl;
=== Прочие настройки ===
Указание максимального размера запроса – необходимо если сервер будет использоваться для загрузки больших файлов (например, для построения небольшого облачного хранилища на основе «ownCloud», эта строчка по сути делает то же что и указанные выше при настройке «PHP-FPM», только теперь для «Nginx»)

	client_max_body_size		200m;	# увеличение максимального объема файла для загрузки до 200МБ
Ещё одна опция

	# Buffers
	fastcgi_buffers 64 4K;
=== Безопасность ===
Опишем настройки безопасности в отдельном файле

 sudo touch /etc/nginx/common/security
 sudo nano /etc/nginx/common/security
И укажем в нём

 add_header		X-Frame-Options		"SAMEORIGIN";
 add_header		X-Content-Type-Options	"nosniff"; 
Сохраним и закроем файл, а затем подключим его строкой

	include common/security;
=== Сжатие ===
Для экономии трафика лучше включить сжатие (иногда со влючённым сжатием могут возникать проблемы, например, у «ownCloud», см. ниже). Опишем настройки сжатия в отдельном файле

 sudo touch /etc/nginx/common/gzip
 sudo nano /etc/nginx/common/gzip
и введём

 gzip		on;
 gzip_disable	"msie6";
 gzip_comp_level	6;
 gzip_min_length	1100;
 gzip_buffers	16 8k;
 gzip_proxied	any;
 gzip_types	text/plain application/xml text/css text/js text/xml application/x-javascript text/javascript application/javascript application/json application/xml+rss; 
Следует сохранить, закрыть и затем подключить этот файл срочкой

	include common/gzip;
=== Директории сайта ===
Далее указание директорий сайта и правил работы с ними с использованием директив «location». Данная директива может обрабатывать регулярные выражения «Perl» (см. Регулярные выражения (шаблоны))

Важно учитывать порядок проверки директив «location» (см. location)
Блокировать доступ к файлам и подпапкам обычно следует посредством регулярных выражений
Корневая директория

	location "/"
		{
		index index.php index.html index.htm;	# варианты индексных файлов если имя файла в запросе не задано
		try_files	$uri $uri/	=404;	# проверить есть ли файл из запроса на диске, иначе - вернуть ошибку 404
		}
К примеру, если хочется построить сайт на основе «WordPress», то можно описать корневую директорию так

	location "/"
	{
		index index.php index.html index.htm;
		try_files	$uri $uri/ /wordpress/;	# проверяем существования файла или папки, иначе перенаправляем к example.com/wordpress
		rewrite "^/$" "/wordpress/" redirect;	# перенаправляем запрос example.com/ к example.com/wordpress
	}
Соответственно сам сайт должен размещаться в каталоге «/var/www/wordpress/»

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

	include common/locations/*.inc;
которая укажет «Nginx», что нужно подключить все файлы в директории «/etc/common/locations/» которые соответствуют шаблону «*.inc», таким образом, если один из файлов нужно будет временно отключить, то его можно просто переименовать убрав расширение в имени. Создадим директорию где будут хранится эти файлы

 sudo mkdir /etc/nginx/common/locations
Некая директория «/var/www/restricted» доступная только авторизованным пользователям сервера. Создадим для неё файл конфигурации «/etc/nginx/common/locations/restricted.inc»

 sudo touch /etc/nginx/common/locations/restricted.inc
 sudo nano /etc/nginx/common/locations/restricted.inc
со строчками

 location ^~ "/restricted/"
 {
 	auth_basic		"Access to this folder is restricted";
 	auth_basic_user_file	htpasswd;
 	autoindex	on;
 	allow		all;
 	try_files	$uri $uri/ =404;
 }
Синтаксис «^~» указывает, что при совпадении здесь директивы «location» ниже проверяться не будут.

Этот конфигурационный файл подключится автоматически, за счёт шаблона (см. выше).

=== Wordpress ===
Для более полной информации по настройке «Nginx» для «WordPress» следует обратиться к официальной документации (см. codex.wordpress.org/Nginx и wiki.nginx.org/WordPress)

Натройки «Wordpress», который, в данном примере, находится в папке «/var/www/wordpress» будут описаны в файле «/etc/nginx/common/locations/wordpress.inc»

 sudo touch /etc/nginx/common/locations/wordpress.inc
 sudo nano /etc/nginx/common/locations/wordpress.inc
Указываем виртуальную директорию (используется для удобства и читабельности) в которую будут перенаправляться запросы при необходимости

 location @wordpress
 {
 	rewrite "^/wordpress/(.*)$" "/wordpress/index.php?q=$1" last;
 }
Аналогично примеру выше предотвращаем обработку остальных директив «location»

 location ^~ "/wordpress/"
 {
 	root		"/var/www";
 	index		index.php;
 	try_files	$uri $uri/ @wordpress;	# проверить существует ли файл, иначе направить в виртуальную директорию
	
	# Ограничение доступа к секретному файлу
	location ~* "^/wordpress/wp-config.php(/.*)?$"
	{
		deny all;
		return 404;
	}
	# Ни в коем случае не выполнять файлы php в папках куда их может кто-то загрузить
	# Проще всего просто заблокировать любые операции с такими файлами регулярным выражением
	location ~* "/(uploads|files)/.*\.php.?(/.*)?$"
	{
		deny all;
		return 404;
	}
	# Перенаправление php-файлов к серверу «PHP-FPM» см. ниже по статье
	location ~ "^(/wordpress/.+?\.php)(/.*)?$"
	{
		# Проверяем существование файлов, пробуем исправить если нет, иначе выдаём ошибку
		# $1 указывает на первую скобку в регулярном выражении выше - собственно адрес запрошенного php файла
		try_files	$1 $uri $uri/ $uri/index.php	=404;
		include common/php-fpm;
	}
	# Другие настройки, см. ниже по статье
	include common/deny;
	include common/cache;
 }
Сохраняем и закрываем этот файл. Опять же, он будет подключён автоматически.

=== ownCloud ===
Для наиболее полной информации следует обратится к официальному руководству «OwnCloud» (см. Nginx Configuration). К примеру, «ownCloud» находится в папке «/var/www/owncloud».

Создадим файл настроек для «ownCloud» и отредактируем его

 sudo touch /etc/nginx/common/locations/owncloud.inc
 sudo nano /etc/nginx/common/locations/owncloud.inc
Многое аналогично примеру для «Wordpress»

 location ^~ "/owncloud/"
 {
	root		"/var/www"; 
	index index.php index.html index.htm;
	try_files	$uri $uri/ =404;
	# ownCloud предоставляет свои красивые страницы для ошибок 404 и 403 - используем их
	error_page 403 /owncloud/core/templates/403.php;
	error_page 404 /owncloud/core/templates/404.php;
 
	# Отключаем сжатие - оно создаёт проблемы для клиента синхронизации ownCloud
	gzip			off;
	# Переопределяем глобальную настройку описанную в главном файле
	# увеличиваем максимальный размер загружаемых файлов
	client_max_body_size	16G;
	# Запрещаем читать секретные файлы
	location ~* "^/owncloud/(\.user\.ini|data|config|db_structure\.xml|README)(/.*)?$"
	{
		deny all;
		return 404;
	}
	location ~ "^(/owncloud/.+?\.php)(/.*)?$"
	{
		try_files	$1 $uri $uri/ $uri/index.php	=404;
		include common/php-fpm;
	}
	include common/deny;
	include common/cache;
 }
Начиная с версии «ownCloud» 8 появился отдельный файл для переопределения некоторых настроек «PHP-FPM» взамен указанных в «/etc/php5/fpm/php.ini». Открыть его можно командой

 sudo nano /var/www/owncloud/.user.ini
и в нем найти строчки

 upload_max_filesize=513M
 post_max_size=513M
и поменять значения на требуемые.

=== Базовые ограничения ===
Выше была написана строчка для подключение файла «/etc/nginx/common/deny»

 include common/deny;
рассмотрим его содержание. В нём идет запрет доступа к некоторым стандартным файлам. Создадим этот файл

 sudo touch /etc/nginx/common/deny
 sudo nano /etc/nginx/common/deny
с содержанием

 # Запрет доступа к .htaccess и .htpasswd файлам
 location ~* "/\.(htaccess|htpasswd)$"
 {
	deny all;		# запретить все для всех
	return 404;		# вернуть код ошибки
 }
Следует быть бдительным, неверно указанный шаблоны для запрета доступа (не только здесь но и в примерах выше) могут сильно навредить. Например, клиент ownCloud может начать удалять файлы которые не сможет загрузить на сервер из-за неправильного запрета где-то в конфигурационном файле
Следует переписать все файлы «.htaccess» в директивы «Nginx». Найти эти файлы среди файлов сайта можно, например, командой

 sudo find /var/www/ -name .htaccess
=== Вызов PHP-FPM ===
В примерах выше использовался файл «/etc/nginx/common/php-fpm» — в нём идет перенаправление обработки php-скриптов внутреннему серверу «PHP-FPM»

В файле «php.ini» должно быть установлено «cgi.fix_pathinfo = 0;» Также, в файле »/etc/php5/fpm/pool.d/www.conf» должно присутствовать ограничение на разширение имени исполняемых скриптов - «security.limit_extensions = .php .php3 .php4 .php5»
Создаём этот файл

sudo touch /etc/nginx/common/php-fpm
sudo nano /etc/nginx/common/php-fpm
с содержанием

 # Настройки порта или сокета PHP-FPM производятся в файле "/etc/php5/fpm/pool.d/www.conf"
 fastcgi_pass	php-fpm;
 # Порядок важен - строчка "include fastcgi_params" должна быть первой
 include fastcgi_params;
 fastcgi_split_path_info			^(.+?\.php)(/.*)?$;
 # Вместо переменной "$document_root" можно указать адрес к корневому каталогу сервера и это желательно (см. http://wiki.nginx.org/Pitfalls)
 fastcgi_param	SCRIPT_FILENAME		$document_root$fastcgi_script_name;
 fastcgi_param	PATH_TRANSLATED		$document_root$fastcgi_script_name;
 # См. http://trac.nginx.org/nginx/ticket/321
 set		$path_info		$fastcgi_path_info;
 fastcgi_param	PATH_INFO		$path_info;
 # Additional variables
 fastcgi_param	SERVER_ADMIN		email@example.com;
 fastcgi_param	SERVER_SIGNATURE	nginx/$nginx_version;
 fastcgi_index	index.php;
=== Кеширование ===
Выше, в примерах, был упомянут файл «/etc/nginx/common/cache»

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

 sudo touch /etc/nginx/common/cache
 sudo nano /etc/nginx/common/cache
где укажем

 location ~* ".+\.(?:ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|css|swf|js|atom|jpe?g|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		max;
	}
=== Окончание ===
Закрываем фигурные скобки директивы «server» в «/etc/nginx/sites-available/example.com»

 }
На этом правка файла «/etc/nginx/sites-available/example.com» завершена. Убедитесь в том, что все фигурные скобки «{ }» закрыты корректно и части файла верно вложены друг в друга («location» внутри «server» и т.п.).

Сохраняем все изменённые файлы.

Теперь можно перезапустить демоны

 sudo service nginx restart
 sudo service php5-fpm restart
=== Проверка ===
Проверить свой сайт можно создав файл «info.php» с содержанием

 <?php
 phpinfo();
 ?>
затем скопировав его, например, в «/var/www/wordpress/wp-content/uploads/», затем открыв адрес в браузере «http://example.com/wordpress/wp-content/uploads/info.php», если он выполнится вместо того чтобы просто сохранится — то что-то настроено неправильно, в этой директории php файлы выполняться не должны ни в коем случае (она доступна для загрузки)

Проверить свой сайт на скорость и прочее можно тут:

[https://webpagetest.org webpagetest.org]

[https://developers.google.com developers.google.com]

[https://ssllabs.com ssllabs.com]


[[Category:Ubuntu]] [[Category:Debian]] [[Category:PHP]] [[Category:PHP-FPM]] [[Category:NGINX]]