Во время отладки иногда необходимо сначала выявить проблему и понять это проблема из-за PHP или Nginx делает что-то не правильно.
В этом случае может пригодиться cgi-fcgi.

Установка cgi-fcgi на Ubuntu

Достаточно запустить команду:
apt-get install libfcgi0ldbl​

Подключение к PHP-FPM на прямую

Предполагаем что вы запустили PHP-FPM используя TCP/IP с IP и PORT значениями 127.0.0.1 и 9000 соответственно.
Ниже приведены некоторые примеры кода, которые вы можете использовать.
Сложность в том, что некоторым скриптам необходимо знать через какую схему они работают, http, или https. Таким образом они формируют ссылки, а иногда принудительно перенаправляют клиентов куда нужно. Из-за не верной настройки серверного ПО переадресация не может завершиться и браузер покажет нам ошибку 'too many redirects'.

В статье рассмотрим две схемы:
nginx (front1, server2) -> nginx (front2, server1) -> php-fpm (back, server1)
nginx (front1, server2) -> nginx (front2, server1) -> apache (back, server1)
Давно искал что-то подобное.
Конфигурация nginx позволяет перенаправлять посетителей сайта на мобильную версию по UserAgent'у.
И казалось бы... это же совсем не сложно, но у нас есть ещё и плюшки.
Плюшки в том что мы можем добавить в адресную строку параметр для переключения на полную версию, или обратно на мобильную. Всё это записывается в cookies и сохраняется на заданное нами время. т.е. людей не будет напрягать то, что их при каждом входе принудительно перенаправляет на мобильную версию, а они то хотят полную.

Таким образом принудительное переключение с полной версии на мобильную происходит добавлением example.com?mobile=yes,
а переключение с мобильной на полную добавлением example.com?mobile=no
Заметка об использовании переменных в домене на web сервере nginx, или динамические поддомены.

Важно не забыть выше расположить статические поддомены, чтоб динамические их не перебивали.
Ну и примеры ниже:
server { 
    server_name www.example.com; 

    location / { 
        proxy_pass 127.0.0.1:80; 
    } 
}

Пару лет назад думал что настроил на вэб сервере поддержку ipv6, все онлайн тэсты проходили на ура. Но сейчас, настроив у себя ipv6, понял что при обращении к сайтам получаю в ответ "403 Forbidden". Не приятно конечно, но надо что-то делать.

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

listen [::]:80 ipv6only=on;


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

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

В конфигурационном файле, в папке, которую хотим закрыть надо только указать файл, где хранятся пароли.
Вот два примера для закрытия папки с файлами:

location ^~ /files/ {
 root /path/to/server;
 autoindex on;
 autoindex_exact_size off;
 auth_basic "Hello, please login";
 auth_basic_user_file /usr/nginx/passwords;
 access_log /usr/nginx/logs/files.log download;
 }


и админовской части c дополнительным ограничением по IP:

location ^~ /admin/ {
 fastcgi_pass unix:/home/project/server.sock;
 include conf/fastcgi.conf;
 allow 11.11.0.0/16;
 allow 22.22.22.22;
 deny all;
 auth_basic "Hello, Admin, please login";
 auth_basic_user_file /usr/nginx/adminpassword;
 access_log /usr/nginx/logs/admin.log main;
 }

В http-сервере Apache найдена опасная уязвимость, позволяющая вызвать отказ в обслуживании через исчерпание всей доступной памяти. Опасность уязвимости усугубляется тем, что для её осуществления уже доступен готовый эксплоит, позволяющий совершить атаку с одной машины с генерацией минимального трафика. При отсутствии отдельных лимитов на размер выделяемой Apache памяти, после выполнения эксплоита наблюдается полное исчерпание памяти с уходом в бесконечный своппинг без возможности зайти в консоль. 
Проблема вызвана ошибкой в реализации поддержки загрузки части файла по указанному диапазону (например, после обрыва соединения можно запросить загрузку начиная с определенной позиции). Ошибка связана с тем, что при обработке запроса, содержащего большое число диапазонов (например, "Range:bytes=0-,5-1,5-2,5-3,...,5-1000") в сочетании с использованием gzip-сжатия отдаваемого контента, расходуется слишком много памяти. Например, если в заголовке Range передана тысяча диапазонов, то Apache пытается отдельно сжать каждый диапазон. Так как каждая операция сжатия требует достаточно много памяти (даже для сжатия одного байта выделяется буфер для сжатия блока), в сумме легко исчерпать всю доступную память. Для осуществления удачной атаки достаточно отправить около 50 подобных запросов с составным Range на сервер.

Проблема присутствует в Apache 2.2.x, включая последний релиз 2.2.19. Исправление пока доступно в виде патча. Также имеется несколько способов временной защиты, не требующих пересборки Apache. Например, можно принудительно очищать заголовок Range при помощи mod_header ("RequestHeader unset Range" и "RequestHeader unset Request-Range") или блокировать длинные последовательности Range через mod_rewrite:

# Вариант 1:
RewriteEngine On
RewriteCond %{HTTP:Range} bytes=0-[0-9]+, [NC,OR]
RewriteCond %{HTTP:Range} bytes=([0-9-],){4,} [NC,OR]
RewriteCond %{HTTP:Range} bytes=[0-9,-]+,0-(,|$) [NC]
RewriteRule .? http://%{SERVER_NAME}/ [NS,L,F]

 

# Вариант 2:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(HEAD|GET) [NC]
RewriteCond %{HTTP:Range} ([0-9]*-[0-9]*)(\s*,\s*[0-9]*-[0-9]*)+
RewriteRule .* - [F]

 

# Вариант 3:
RewriteEngine On
RewriteCond %{HTTP:Range} bytes=0-.* [NC]
RewriteRule .? http://%{SERVER_NAME}/ [R=302,L]

Статья в виде заметки...

В файле /etc/httpd/conf/httpd.conf ищем секцию и немного увеличиваем значения (MaxRequestsPerChild лучше наоборот уменьшить). Например, таким образом (по умолчанию настройки слишком зажаты, мы же здесь увеличим лимиты, съедая попутно больше оперативной памяти):

StartServers 5
MinSpareServers 5
MaxSpareServers 15
ServerLimit 30
MaxClients 30
MaxRequestsPerChild 200
MaxKeepAliveRequests 50
KeepAliveTimeout 5


И, как, обычно, после этого необходимо выполнить 

# service httpd restart

Http-соединения могут быть переадресованы на https с помощью модуля apache mod_rewrite, который должен быть доступен в любой версии apache. Создайте файл с именем .htaccess в корневом каталоге сайта, который содержит следующие строки:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}


Если Вы используете ISPConfig 2 или 3, Вы можете также добавить эти строки в поле директив apache в настройках сайта, вместо их добавления в файл a .htaccess. Но метод с использованием файла .htaccess будет также работать и на ISPCONFIG.

Вы когда-нибудь искали, где определён виртуальный хост сайта в  файлах конфигурации apache? Существует удобная опция, в виде скрипта apache2ctl, который может помочь в этом вопросе. Если Вы наберёте команду:

apache2ctl -S


в командной строке, Вы получите список всех виртуальных хостов и серверов по умолчанию, включая номер строки, где они определены. Например:

# apache2ctl -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:8080                 is a NameVirtualHost
default server ispconfig.local (/etc/apache2/sites-enabled/000-ispconfig.vhost:10)
port 8080 namevhost ispconfig.local (/etc/apache2/sites-enabled/000-ispconfig.vhost:10)
*:8081                 is a NameVirtualHost
default server ispconfig.local (/etc/apache2/sites-enabled/000-apps.vhost:10)
port 8081 namevhost ispconfig.local (/etc/apache2/sites-enabled/000-apps.vhost:10)
*:80                   is a NameVirtualHost
default server ispconfig.local (/etc/apache2/sites-enabled/000-default:1)
port 80 namevhost ispconfig.local (/etc/apache2/sites-enabled/000-default:1)
port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.vhost:7)
Syntax OK

Вступление
Начиналось всё с сервера, который находился дома и его производительность меня не устраивала, наверное потому что изначально эта ОС вообще была десктопом. Для увеличения этой самой производительности я установил nginx как фронтэнд для apache. Сайтов было всего 3-4, прописать конфиги проблем не составляло, поэтому никакой панели управления небыло.
На данный момент куплен VPS, на который установлена панель управления ISPConfig 3. Причём с самого начала было точно определено что в любом случае перед apache будет установлен nginx. Не буду описывать все плюсы, которые мы получаем при его использовании...
Итак, сейчас у вас должна быть установлена ISPConfig 3 на Fedora 14, всё настроено и отлажено.