Настраиваем веб-сервер — nginx и apache на одном сервере
В этом руководстве мы рассмотрим процедуру установки и настройки работы двух web-серверов с целью использования преимуществ каждого из них, где Nginx — как frontend и Apache — как backend.
Установка и настройка NGINX
apt-get install nginx
Внесем изменение в файл nginx.conf:
Снимаем комментарий со строки:
http
Так на практике, может встретиться ошибка could not build server_names_hash, you should increase server_names_hash_bucket_size: 32.
Она возникает при большом количестве виртуальных серверов или если один из них будет иметь длинное название. Данная строка в конфиге исправит ситуацию.
systemctl enable nginx
systemctl start nginx
Проверим работу веб-сервера. Открываем браузер и вводим в адресной строке http://.
В итоге мы должны увидеть заголовок «Welcome to nginx!».
Если стартовая страница не загружается, проверяем состояние сервиса и исправляем причину:
systemctl status nginx
Установка и настройка Apache
Для поддержки файла .htaccess, который используется многими сайтами, необходимо установить и настроить веб-сервер Apache.
Устанавливаем apache и модуль для php:
apt-get install apache2 libapache2-mod-php php php-xml php-intl php-gd php-curl php-zip php-mbstring
Заходим в настройки портов:
И редактируем следующее:
Listen 127.0.0.1:8080 # # Listen 443 # # # Listen 443 # *мы настроили прослушивание на порту 8080, так как на 80 уже работает NGINX. Также мы закомментировали прослушивание по 443, так как и он будет слушаться NGINX.
по умолчанию, apache2 может быть установлен с модулем мультипроцессовой обработки mpm_event. Данный модуль не поддерживает php 7 и выше.
Разрешаем модуль мультипроцессовой обработки mpm_prefork:
Разрешаем модуль php:
Разрешаем модуль rewrite:
*в данном примере установлен php версии 7.3.
Разрешаем модуль setenvif:
Разрешаем автозапуск и запускаем службу:
systemctl enable apache2
systemctl start apache2
Открываем браузер и вводим в адресную строку http://:8080. Мы должны увидеть привычную страницу.
*в разделе Server API мы должны увидеть Apache.
NGINX и Apache одновременно
Открываем конфигурационный файл nginx для сайта по умолчанию и редактируем:
. location / < location ~ [^/]\.ph(p\d*|tml)$ < try_files /does_not_exists @fallback; >location ~* ^.+\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|docx|xls|xlsx|exe|pdf|ppt|tar|wav|bmp|rtf|js)$ < try_files $uri $uri/ @fallback; >location / < try_files /does_not_exists @fallback; >> location @fallback < proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; access_log off; >. systemctl restart nginx
Пробуем открыть в браузере http:// — должна открыться та же страница, что при проверке Apache (с добавлением 8080).
Apache Real IP
Запросы на apache приходят от NGINX, и они воспринимаются первым как от IP-адреса 127.0.0.1. На практике, это может привести к проблемам, так как некоторым сайтам необходимы реальные адреса посетителей. Для решения проблемы будем использовать модуль remoteip.
Создаем конфигурационный файл со следующим содержимым:
RemoteIPHeader X-Forwarded-For RemoteIPTrustedProxy 127.0.0.1/8 systemctl restart apache2
Для проверки настройки открываем браузер и вводим в адресную строку http://, где откроется наша страница phpinfo.
В разделе Apache Environment мы должны увидеть внешний адрес компьютера, с которого обращаемся к серверу в опции REMOTE_ADDR.
Установка СУБД MariaDB
В данной статье мы установим MariaDB. Установка выполняется следующей командой:
apt-get install mariadb-server
Разрешаем автозапуск и запускаем СУБД:
systemctl enable mariadb
systemctl start mariadb
Зададим пароль для учетной записи mysql-root:
mysqladmin -u root password
Для возможности подключаться к базе данных скриптами PHP, необходимо установить следующие модули:
apt-get install php-mysql php-mysqli
После перезагружаем apache2:
systemctl restart apache2
mysql -uroot -p mysql> GRANT ALL PRIVILEGES ON *.* TO 'dbuser'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION; # ALL PRIVILEGES: предоставляет полные права на использование данных. # *.* : права предоставляются на все базы и все таблицы. # dbuser: имя учетной записи. # localhost: доступ для учетной записи будет предоставлен только с локального компьютера. # password: пароль, который будет задан пользователю. # WITH GRANT OPTION: будут предоставлены дополнительные права на изменение структуры баз и таблиц. > quit И открываем наш сайт в браузере. В phpinfo появится новая секция MySQL.
Настраивает возможность входа в adminer.php
> use mysql; > update user set plugin='' where User='root'; > flush privileges; > exit sudo systemctl restart mariadb.service
Настройка пользователя
Добавляем пользователя в группу www-data
adduser dev www-data
Даем права sudo пользователю
usermod -aG sudo dev
NGINX
Открываем и редактируем следующий файл:
И внутри секции http добавляем:
После перезапускаем nginx:
systemctl restart nginx
Установка Memcached
Memcached — Программное обеспечение, реализующее сервис кэширования данных в оперативной памяти на основе хеш-таблицы.
Для начала, выполняем установку пакетов:
apt-get install memcached php-memcached
После разрешаем автозапуск и запускаем сервис кэширования:
systemctl enable memcached
systemctl start memcached
systemctl restart apache2
Для проверки, что модуль memcached появился в PHP, открываем наш сайт в браузере — в phpinfo должна появиться новая секция Memcached.
Создание первого сайта
Создаем новый файл виртуального домена NGINX:
Обязательно на конце должен быть *.conf, так как только такие файлы веб-сервер подгружает в конфигурацию.
И добавляем следующее содержимое.
Для HTTP
# Устанавливается только на главный домен, чтобы шел редирект с ip на главный домен. server < listen 80; server_name Ваш_ip; return 301 http://site.altopromo.com$request_uri; >server < listen 80; server_name site.altopromo.com www.site.altopromo.com; set $root_path /var/www/site.altopromo.com/www; access_log /var/www/site.altopromo.com/log/nginx/access_log; error_log /var/www/site.altopromo.com/log/nginx/error_log; gzip on; gzip_disable "msie6"; gzip_min_length 1000; gzip_vary on; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss root $root_path; location / < location ~ [^/]\.ph(p\d*|tml)$ < try_files /does_not_exists @fallback; >location ~* ^.+\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|docx|xls|xlsx|exe|pdf|ppt|tar|wav|bmp|rtf|js)$ < try_files $uri $uri/ @fallback; >location / < try_files /does_not_exists @fallback; >> location @fallback < proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; access_log off; >> ln -s /etc/nginx/sites-available/site.altopromo.com.conf /etc/nginx/sites-enabled/site.altopromo.com
Где site.altopromo.com — домен, для которого создается виртуальный домен;
/var/www/site.altopromo.com — каталог, в котором будет размещаться сайт.
Все запросы будут переводиться на локальный сервер на порт 8080, на котором работает apache, кроме обращений к статическим файлам (jpg, png, css и так далее).
Для HTTPS
Существующий Сертификат
# Устанавливается только на главный домен, чтобы шел редирект с ip на главный домен. server < listen 80; server_name Ваш_ip; return 301 https://site.altopromo.com$request_uri; >server < listen 443 ssl; ssl on; ssl_certificate /etc/nginx/ssl/cert.pem; ssl_certificate_key /etc/nginx/ssl/cert.key; server_name site.altopromo.com www.site.altopromo.com; set $root_path /var/www/site.altopromo.com/www; access_log /var/www/site.altopromo.com/log/nginx/access_log; error_log /var/www/site.altopromo.com/log/nginx/error_log; gzip on; gzip_disable "msie6"; gzip_min_length 1000; gzip_vary on; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss root $root_path; location / < location ~ [^/]\.ph(p\d*|tml)$ < try_files /does_not_exists @fallback; >location ~* ^.+\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|docx|xls|xlsx|exe|pdf|ppt|tar|wav|bmp|rtf|js)$ < try_files $uri $uri/ @fallback; >location / < try_files /does_not_exists @fallback; >> location @fallback < proxy_pass http://127.0.0.1:8080; proxy_redirect http://127.0.0.1:8080 /; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; access_log off; >> ln -s /etc/nginx/sites-available/site.altopromo.com.conf /etc/nginx/sites-enabled/site.altopromo.com
В первой секции server мы перенаправляем все запросы по незащищенному http на https.
ssl_certificate и ssl_certificate_key — пути к публичному и приватному ключам соответственно.
/etc/nginx/ssl/cert.pem — в cert.pem вставляем публичный сертификат
/etc/nginx/ssl/cert.key — в cert.key вставляем приватный сертификат
Получение бесплатного SSL сертификата Let’s Encrypt
sudo apt install certbot
Отредактировал конфиг etc/letsencrypt/cli.ini добавив:
authenticator = webroot webroot-path = /var/www/site.altopromo.com post-hook = service nginx reload text = True Создал произвольный файл:
mkdir -p /var/www/site.altopromo.com/.well-known/acme-challenge
echo Success > /var/www/site.altopromo.com/.well-known/acme-challenge/example.html
Зарегистрировался в Let’s Encrypt:
certbot register —email me@example.com
Добавил в конфиг nginx:
location /.well-known < root /var/www/site.altopromo.com; >Файл example.html что мы создали должен быть доступен, для проверки, выполним:
curl -L http://site.altopromo.com/.well-known/acme-challenge/example.html
Если все хорошо ответ будет Success.
После проверки файл удалим:
Получение сертификата
Прежде чем получить сертификат рекомендуется провести тест:
certbot certonly —dry-run -d example.com
Если все ок получаем сертификат:
certbot certonly -d example.com -d www.example.com
Далее получим список сертификатов (find /etc/letsencrypt/live/ -type l) и зададим настройки для nginx:
server_name site.altopromo.com; listen site.altopromo.com:443 ssl; access_log off; ssl_certificate /etc/letsencrypt/live/site.altopromo.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/site.altopromo.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/site.altopromo.com/chain.pem; ssl_stapling on; ssl_stapling_verify on; resolver 127.0.0.1 8.8.8.8; expires off; *не забыть в админке включить SSL и принудительное перенаправление.
Теперь создаем виртуальный домен в Apache:
Define root_domain site.altopromo.com Define root_path /var/www/site.altopromo.com ServerName $ ServerAlias www.$ DocumentRoot $/www ErrorLog $/log/apache/error_log TransferLog $/log/apache/access_log DirectoryIndex index.php index.html index.htm AllowOverride All Options Indexes ExecCGI FollowSymLinks Require all granted SetEnvIf X-Forwarded-Proto https HTTPS=on php_admin_value upload_tmp_dir $/tmp php_admin_value doc_root $ php_value open_basedir $:/usr/local/share/smarty:/usr/local/share/pear php_value post_max_size 512M php_value upload_max_filesize 512M php_flag short_open_tag On # где post_max_size — максимальный объем отправляемых на сервер данных; # где upload_max_filesize — максимально допустимый размер одного загружаемог; # где short_open_tag — разрешение использования короткого способа открытия php ( ln -s /etc/apache2/sites-available/site.altopromo.com.conf /etc/apache2/sites-enabled/site.altopromo.com.conf
Создаем каталоги для сайта:
mkdir -p /var/www/site.altopromo.com/
mkdir -p /var/www/site.altopromo.com/log/
Создаем индексный файл со следующим содержимым:
Hello world!
"; ?>
Задаем права на папки:
chown -R www-data:www-data /var/www/site.altopromo.com
chmod -R 775 /var/www/site.altopromo.com
Проверяем корректность настроек конфигурационных файлов:
systemctl reload nginx
systemctl reload apache2
Открываем сайт в браузере по нашему домену site.altopromo.com (он должен быть прописан в DNS или можно его задать в локальном файле hosts того компьютера, с которого мы открываем сайт в браузере).
Мы должны увидеть фразу «Hello world!».
Как проверить, является ли apache бэкэндом для nginx?
Есть сервер на Ubuntu 14.04.3, и к нему есть доступ по SSH. На сервере установлен nginx/1.4.6 и Apache/2.4.7 Но вот в чем вопрос. Работают ли в паре Nginx+Apache? То есть, является ли nginx «фронтэндом», а apache «бэкэндом»? Есть ли какая нибудь ssh-команда, которая бы показала это?
Отслеживать
67.9k 216 216 золотых знаков 77 77 серебряных знаков 219 219 бронзовых знаков
задан 6 окт 2015 в 15:42
151 2 2 серебряных знака 12 12 бронзовых знаков
А вы уверены, что именно apache бэкенд для nginx, а не наоборот?
6 окт 2015 в 16:32
@Foxtrot, посмотри глазами в конфигах nginx (/etc/nginx/nginx.conf и дальше в инклюды)
6 окт 2015 в 16:43
@norbornen, я слишком долго смотрел в вопрос и не так его понял. Естественно, nginx не может быть бэкендом. По крайней мере мне об этом ничего не известно.
6 окт 2015 в 16:52
@norbornen, бэкендом для nginx много что может быть.
6 окт 2015 в 17:03
@ВикторРэд, Естественно, nginx не может быть бэкендом — запросто, ведь nginx — полноценный http-сервер. при желании можно использовать даже связку apache+nginx «наоборот» — чтобы apache проксировал запросы к nginx-у. только так вряд ли кто-то делает.
6 окт 2015 в 18:38
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
можно воспользоваться такой командой:
$ sudo lsof -Pn -iTCP -sTCP:LISTEN -c nginx -c apache -c httpd -a и проанализировать её вывод. пример (реальный сервер, часть строк опущена для наглядности):
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME apache2 2206 root 3u IPv4 58834967 0t0 TCP 127.0.0.1:8080 (LISTEN) apache2 13377 www-data 3u IPv4 58834967 0t0 TCP 127.0.0.1:8080 (LISTEN) nginx 13289 root 6u IPv4 58829785 0t0 TCP *:80 (LISTEN) nginx 13289 root 7u IPv4 58829786 0t0 TCP *:443 (LISTEN) nginx 13624 www-data 6u IPv4 58829785 0t0 TCP *:80 (LISTEN) nginx 13627 www-data 7u IPv4 58829786 0t0 TCP *:443 (LISTEN) из него видно, что nginx слушает 80-й и 443-й порты на всех адресах ( *:80 и *:443 ), а apache — лишь порт 8080 и только на адресе 127.0.0.1 ( 127.0.0.1:8080 ).
откуда вытекает вполне логичный вывод: nginx слушает внешние обращения и (возможно) передаёт (некоторые из них) apache-у.
«расшифровка» использованных опций программы lsof :
- -P — отображать номера портов, а не имена, взятые из файла /etc/services
- -n — отображать ip-адреса, не пытаясь преобразовать их в доменные имена
- -iTCP -sTCP:LISTEN — отобразить процессы, слушающие tcp-порты
- -c nginx -c apache -c httpd — отобразить процессы, начинающиеся с этих строк
- -a — логическое and для параметров (правда, не для всех: в данном случае применяется для «связывания» -iTCP и -c имя ). если его опустить, то будут выведены ещё и открытые указанными (с помощью опций -c ) процессами файлы (вообще программа lsof в первую очередь для отображения открытых файлов и писалась).
Как узнать какой сервер на хостинге Apache или Nginx
Существует несколько простых способов выяснить, какой веб-сервер установлен на вашем хостинге. В их основе лежит просмотр заголовков HTTP-запроса посредством различных сервисов или вручную. Чаще всего поиски данной информации заканчиваются тем, что пользователь сталкивается с такими вариантами ответа: Nginx или Apache – одни из самых популярных и хорошо зарекомендовавших себя проектов, предоставляющих в совокупности до 50% веб-трафика, который гонится на сайт. Следовательно, в этом материале мы разберем упомянутые веб-сервера. Данное руководство будет полезно всем пользователям, которые сталкиваются с этим вопросом впервые.
Важно! Радикальных различий между Nginx и Apache не существует, но все-таки приходится говорить об отличительной обработке соединений.
Вернемся к тому, как узнать тип веб-сервера на хостинге, и какие сервисы станут наилучшими помощниками для этих целей.
Определяем руками, просмотр HTTP заголовков
В этом варианте будем использовать сам браузер и инструменты разработчика CTRL+ SHIFT +I. В качестве браузере, рассмотрим на примере Google Chrome. Шаг 1. В браузере Google Chrome открываем сайт, у которого требуется узнать веб-сервер. 
Шаг 2. Открываем инструменты разработчика. Меню (три тоски) --> Дополнительные инструменты --> Инструменты разработчика. 
Шаг 3. Заходим на вкладку network (сеть), затем перезагружаем сайт. 
Шаг 4. В столбце "Name" находим название сайта, в моем случае это vseprolinux.ru. Кликаем левой кнопкой мыши. В появившемся окне справа в headers ищем слово "server". Это и есть веб-сервер, который используется на сайте. 
Bertal
- http
- https
- ftp
Чтобы произвести успешную проверку http-заголовка, пользователю потребуется заполнить поля формы на странице сайта. Если пользователь предпочтет заполнить одно поле (URL сайта), то он получит лишь основную информацию о своём хостинге. Для получения развернутой информации все же рекомендуется заполнять все имеющиеся поля на странице сайта.
Примечательно, что запрос информации происходит несколькими способами:
Выдача результата будет напрямую зависеть от того, какие данные укажет пользователь в полях формы на сайте.
Несколько интересных фактов о популярных веб-серверах
- Разработка проекта стартовала в 1995 году. Сервер улучшали вплоть до 1999-го года. И уже через год после этого продукт начал широко применяться в сети Интернет.
- Имеет множество модулей, гибкий.
- Разработка сервера стартовала в 2002 году. Готовый продукт был представлен широкой публике в 2004 году.
- Обладает высокой чувствительностью при мощных нагрузках.
Заключение
У пользователя может возникнуть срочная необходимость выявить тип веб-сервера на своём хостинге. В этой статье мы рассказали, как получить нужную информацию самостоятельно, без обращения в саппорт. Просто используйте для этих целей один из упомянутых способов.
Веб-сервер на связке nginx+apache
Разворачиваем веб-сервер под операционной системой Linux, который будет использовать одновременно nginx и apache.
Пусть имеется аппаратная платформа, на которой уже установлен CentOS.
Настроим связку apache+nginx. На передовую (front-end) выставляем лёгкий и высокопроизводительный nginx, который будет обрабатывать запросы к статическому контенту (картинки, стили, js и т.п.). В тылу (back-end) нас будет страховать apache, задачей которого является предоставление динамического контента (в основном, PHP).
Безусловно, возникает законный вопрос, нельзя ли обойтись без apache вообще? Действительно, ничего не мешает настроить совместную работу nginx+php+mysql (вызываем PHP в режиме FastCGI с помощью php-fpm). Производительность такой системы будет ещё выше. Но есть и серьезный недостаток: большинство стандартных движков сайтов ориентировано непосредственно на работу под apache (правила доступа к различным директориям сайта настраиваются в файле .htaccess); а ввиду того, что nginx не обрабатывает .htaccess, без доработок такие сайты под nginx работать не будут. Причем, если переработка одного сайта является вполне выполнимой технической задачей, то обслуживание нескольких сайтов (особенно чужих), становится настоящей проблемой.
Итак, жертвуем экстремальной производительностью, но сохраняем поддержку .htaccess.
Устанавливаем apache, mysql, php. Для этого нам пригодится yum и стандартные репозитории.
yum -y install httpd mysql mysql-server php php-mysql php-mbstring php-cli
Установка nginx чуть сложнее, придётся сходить на сайт разработчика и прочитать методику установки. К счастью, под распространенные дистрибутивы (CentOS и подобные), разработчик предоставляет готовые пакеты.
Настраиваем всю связку:
- Конфигурация mysql
- Конфигурация php
- Конфигурация apache
- Конфигурация nginx.
Теперь рассмотрим каждый шаг подробно.
Конфигурация mysql
Конфигурация php
Практически не требуется, в деталях описана в отдельной статье. Главное не забыть про shorttag: short_open_tag = On.
Конфигурация apache
Так как на передовую мы выдвигаем nginx, значит именно он будет работать на стандартном порту 80, а обращение к apache будет проксироваться через любой другой порт. Я выбрал 8080.
Модифицируем файл глобальных настроек. Я привожу только самые важные параметры, которые надо проверить:
Timeout 60
KeepAlive Off
# MaxKeepAliveRequests 100
# KeepAliveTimeout 10
StartServers 2
MinSpareServers 2
MaxSpareServers 4
ServerLimit 6
MaxClients 10
MaxRequestsPerChild 800
# Слушаем нестандартный порт,
# так как у нас на передовой nginx
Listen 127.0.0.1:8080
# Пользователь и группа
User apache
Group apache
# Определяем порт
NameVirtualHost *:8080
Интересно, что KeepAlive следует отключать (спасибо за наводку внимательному читателю Mike). Производительность системы будет повышаться, если процесс httpd, отдав динамическое содержимое, будет тут же освобождаться.
Важно завести пользователя и группу, от которых будут работать в связке две службы: и nginx, и httpd. Естественно, это должен быть один и тот же пользователь как для httpd, так и для nginx во избежание конфликтов! Я для этих целей использую пользователя и группу apache; в результате httpd работает из-под "своего" имени, а nginx вынужден работать под чужим именем.
Следующим шагом будет настройка виртуальных серверов. Каждый виртуальный сервер будем настраивать, создавая для него отдельный конфигурационный файл в /etc/httpd/conf.d/ , причем необходимо следить, чтобы расширением являлось именно .conf . Предположим, создаётся виртуальный сервер для сайта drach.pro, тогда потребуется файл /etc/httpd/conf.d/drach.pro.conf со следующим содержимым:
# Слушаем выбранный порт:
ServerName drach.pro
ServerAlias www.drach.pro
ServerAdmin Этот адрес электронной почты защищен от спам-ботов. У вас должен быть включен JavaScript для просмотра.
DocumentRoot /var/www/html/drach.pro
CustomLog /var/log/httpd/drach.pro_access.log combined
ErrorLog /var/log/httpd/drach.pro_error.log
AllowOverride All
Options +Includes
Таким образом необходимо описать все виртуальные сервера. Кроме того, надо не забыть про файлик vhost.conf, в который надо поместить конфигурацию сайта по умолчанию.
Теперь десерт! Не достаточно настроить apache на обычную работу, необходимо корректно обрабатывать REMOTE_ADDR заголовка. Для этих целей устанавливаем и настраиваем RPAF (mod_rpaf соответствует первой версии apache, а mod_rpaf2 - второй).
Без RPAF будем иметь REMOTE_ADDR не пользовательский, а IP-адрес сервера с передовой (это nginx). RPAF будет обрабатывать заголовок X-Forwarded-For, который получен от nginx и генерировать корректный REMOTE_ADDR.
Таким образом заголовок REMOTE_ADDR снова имеет пользовательский IP! Например, для моих целей это крайне важно, так как приходится наблюдать за пользователями и вести подробные логи для отчётов.
Устанавливаем модуль RPAF, для чего его придётся найти в интернете отдельным пакетом под наш дистрибутив. Есть альтернативный путь: подключить хранилище Atomic repo и использовать yum. Затем настраиваем RPAF, создавая и редактируя /etc/httpd/conf.d/mod_rpaf.conf:
LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
# Enable reverse proxy add forward RPAFproxy_ips
YOUR_PROXY_SERVER_IP_LIST_OR_ONE_IP
# which ips are forwarding requests to us
RPAFsethostname Off
# let rpaf update vhost settings
# allows to have the same hostnames as in the "real"
# configuration for the forwarding Apache
RPAFproxy_ips 127.0.0.1
RPAFheader X-Real-IP
После конфигурации необходимо перезапустить Apache.
Конфигурация nginx
Описываем глобальный файл конфигурации /etc/nginx/ nginx.conf :
user apache;
worker_processes auto; разрешаем серверу выбирать количество процессов!
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events worker_connections 1024;
>
http include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
# Журналирование будет индивидуальное для всех сайтов:
# access_log /var/log/nginx/access.log main;
sendfile on;
client_max_body_size 24M;
#tcp_nopush on;
keepalive_timeout 65;
gzip on;
# Минимальная длина ответа, при которой модуль будет жать, в байтах
gzip_min_length 1100;
# Разрешить сжатие для всех проксированных запросов
gzip_proxied any;
# Запрещает сжатие ответа методом gzip для IE6
gzip_disable "msie6";
# Уровень gzip-компрессии
gzip_comp_level 8;
# 1) MIME-типы которые необходимо жать
#gzip_types text/plain text/html text/xml application/xml application/x-javascript text/javascript text/css text/json;
# 2) Если у вас появляются предупреждения, типа "duplicate MIME type text/html", то стоит исключить text/html
gzip_types text/plain text/xml application/xml application/x-javascript text/javascript text/css text/json;
# Хватаемся за соломинку:
#gzip_types text/html text/xml text/css application/x-javascript text/javascript;
include /etc/nginx/conf.d/*.conf;
>
Теперь конфигурируем виртуальные хосты! Причем, поступаем профессионально: конфигурационные файлы складываем в /etc/nginx/ conf.d : например, для сайта drach.pro заводим отдельный файл /etc/nginx/ conf.d/drach.pro.conf :
# A virtual host drach.pro
server
# listen drach.pro:80;
listen 80;
server_name drach.pro;
# Ведём журнал доступа:
access_log /var/log/nginx/drach.pro_access.log;
# Разделяем статику и динамку, статику храним в кэше 10 дней:
location ~* \.(jpg|jpeg|gif|png|ico|css|bmp|swf|js|doc|docx|pdf|xls|xlsx|rar|zip|tbz|7z|exe)$ root /var/www/html/drach.pro/;
expires 10d;
>
# htaccess и htpasswd не отдаем:
location ~ /\.ht deny all;
>
# Мы хотим видеть статистику при обращении к папке /stat
location = /stat stub_status on;
access_log off;
# allow xx.xx.xx.xx;
# deny all;
>
location / proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
log_not_found off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>
>
Конец. Достаточно перезапустить все службы и убедиться, что веб-сервер работает!
service httpd restart && service nginx restart
Отслеживаем доступ к серверу в реальном времени:
tail -f /var/log/nginx/drach.pro_access.log
tail -f /etc/httpd/logs/drach.pro_access.log
Ежели в консоли браузера появляется ERR_INCOMPLETE_CHUNKED_ENCODING (обычно это бывает, если файлы css и js генерируются "на лету"), необходимо проверить права и владельца директории /var/cache/nginx/proxy_temp. Также есть смысл убрать эти два расширения из разрешённых статических типов файлов для nginx.
Ежели в журнале ошибок появляется upstream response is buffered to a temporary file, следует в файл глобальной конфигурации nginx добавить proxy_max_temp_file_size 0; в секцию http.