Шаблон конфига NGiNX для связи с Apache, установленных сервере с Debian 9

После того, как в конфиге NGiNX (файл nginx.conf) прописано проксирование Apache на порту 8080 и созданы папки для хранения шаблонов и виртуальных хостов NGiNX, нужно завершить конфигурацию связки NGiNX и Apache. Для этого создадим файл шаблона с основными опциями подключения к вышестоящему серверу и работой со статическим содержимым. Файл этот положим в привязанную в конфиге папку /etc/nginx/templates и назовём его apache24.conf для ясности. Но обо всём по порядку...



Создание файла шаблона конфига NGiNX (apache24.conf)

Что, что а файлы создавать мы уже умеем и для этого воспользуемся утилитой touch:

root@server:~# touch /etc/nginx/templates/apache24.conf

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

Параметры соединения с вышестоящим сервером в шаблоне конфига NGiNX (apache24.conf)

Пропишем в созданный файл apache24.conf параметры соединения с вышестоящим сервером:

location / {
  proxy_pass http://apache24;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $remote_addr;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_connect_timeout 120;
  proxy_send_timeout 120;
  proxy_read_timeout 180;
}
  • proxy_pass перенаправляет все запросы apache24

Помним, что в nginx.conf у нас есть секция, прописывающая проксирование запросов на порт 8080. Конкретно эта запись:

upstream apache24 {
 server 127.0.0.1:8080;
}

  • proxy_set_header служит для изменения HTTP-заголовков страниц так, чтобы Apache смог их правильно обработать
    • proxy_set_header X-Forwarded-Proto $scheme; — важная строка (!) для передачи параметров запроса от NGiNX к Apache, которая позволяет снять проблему перехода с http на https в CMS Joomla! И, хотя Apache по факту продолжает работать по протоколу http, обрабатывая запросы NGiNX и отдавая ему ответы, но передаваемые в переменной $scheme параметры, позволяют скриптам правильно определить то, что работа с конечным клиентом производится по защищённому протоколу https.
      • Примечательным является то, что php-переменные окружения содержат реальные данные о http соединении:
        • REQUEST_SCHEME http
        • SERVER_PROTOCOL HTTP/1.0
      • Однако, это позволяет передать другую переменную, которая позволяет скриптам на php правильно определить протокол, с которым нужно работать, обрабатывая запрос:
        • HTTP_X_FORWARDED_PROTO https
      • Тем самым достигается сборка правильных URL с правильным указанием протокола соединения, устраняет проблему работы с внешними сервисами, взаимодействие с которыми производится с помощью php, работающим за проксирующим NGiNX под управлением Apache.
      • Таким образом мне удалось исправить работу Joomla с множественными редиректами, наладить работу центра обновлений Joomla и расширений к ней, а также добиться правильных URL в модуле сборки карты сайта.
    • proxy_set_header X-Forwarded-For $remote_addr; — пробрасывает через NGiNX в Apache реальный IP пользователя, тем самым позволяя управлять действиями пользователей по IP в файле .htaccess и видеть в логах Apache реальные IP'ы. Без этого, у всех запросов к Apache вместо реального IP пользователей определяется IP NGiNX, а он один и локальный 127.0.0.1 (и не несёт в себе никакой информации о пользователе, - только общую информацию о запросах NGiNX, а этого зачастую мало).
  • proxy_connect_timeout задаёт тайм-аут соединения с прокси-сервером
  • proxy_send_timeout задаёт тайм-аут передачи данных прокси-серверу
  • proxy_read_timeout задаёт тайм-аут приёма (чтение) данных от прокси-сервера

Параметры для работы со статическим содержимым в шаблоне конфига NGiNX (apache24.conf)

Для работы со статическим содержимым пропишем ниже в шаблоне конфига NGiNX (apache24.conf) следующую информацию:

location ~* \.(gif|jpeg|jpg|txt|png|tif|tiff|ico|jng|bmp|doc|pdf|rtf|xls|ppt|rar|rpm|swf|zip|bin|exe|dll|deb|cur)$ {
  access_log off;
  expires 3d;
}
  • В первой строке содержатся расширения файлов, которые будут отдаваться напрямую NGiNX без передачи их Апачу (для этого всё и делается).
  • Команда access_log off; отключает запись в лог NGiNX (чтобы не писать всё подряд). Однако её можно выставить в положение access_log on; если по какой-то причине требуется вести логи всего того, что отдаёт сервер (например, на время отладки работы сервера).
  • Опция expires 3d; задаёт время кэширования переданных статических файлов браузером на стороне пользователя. Это позволит не отдавать каждый раз однотипные данные одному и тому же пользователю, — они будут храниться у него в кэше браузера и показываться на странице без загрузки по сети.

Параметры для работы со стилями и скриптами в шаблоне конфига NGiNX (apache24.conf)

Отдельно пропишем правила работы со скриптами JavaScript и стилями css:

location ~* \.(css|js)$ {
  access_log off;
  expires 180m;
}

Отличие от предыдущей сессии только в том, что для скриптов JavaScript и стилей css время кэширования браузером делаем меньше: 3 часа. Этого достаточно, чтобы не гонять по сети лишние данные, пока пользователь находится на сайте, но не так долго, как у статических файлов, чтобы вносимые изменения всё же обновлялись автоматически, а без необходимости нажимать Ctrl + F5 (об этом пользователи просто могут не только не догадываться, но и не знать, а хотелось бы, чтобы новые стили и обработчики JS в браузере у пользователей были актуальными).

Запрет доступа к ht-файлам, в которых содержатся конфигурационные директивы Apache, в шаблоне конфига NGiNX (apache24.conf)

Ну и под конец, запретим доступ к ht-файлам (типа .htaccess и подобных), в которых содержатся конфигурационные директивы Apache. Конечным пользователям их видеть не нужно, а Apache и так их обработает и подхватит при работе, если они есть:

location ~ /\.ht {
  deny all;
}

Резюме

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

Заберите ссылку на статью к себе, чтобы потом легко её найти!
Раз уж досюда дочитали, то может может есть желание рассказать об этом месте своим друзьям, знакомым и просто мимо проходящим?
Не надо себя сдерживать! ;)

Старт! Горячий старт на просторы интернета
Старт! Горячий старт на просторы интернета
Старт! Меню