Так /index.php?foo=1 - это окончательное значение $request_uri, после всех манипуляций в nginx (а имено: try_files $uri /index.php?$args).
Nginx получает запрос, меняет его согласно настройкам, и пишет в лог, что-бы было понятно, какой окончательный запрос был обработан. А первоначальный запрос - ну вот так, как вы указали...
У вас HTTP и HTTPS по VirtualHost-ам разведены? Из приведённых конфигов (в том виде, как их показывает Habr) этого не видно.
RewriteCond с точным номером порта не приведёт к зацикливанию HTTPS запросов (ну вдруг из-за ошибки конфигурации HTTPS-запросы тоже в этот RewriteRule попадают).
К этому очень полезному ответу добавлю...
А обязательно для фильтрации использовать preg_match()? В $_POST['request'][0] хранится имено regex, или простой текст? Если второе - то банальный strstr() ускорит работу...
Судя по логам, у вас 2 пакета недоустановились, atop и vesta-nginx.
Можно и их попытаться переустановить apt reinstall -y atop vesta-nginx curl
но эта команда может поломать работу nginx, а это на продакшене весьма чревато...
А ещё можно проверять наличие конкретно самой строки: nginx -V 2>&1 | egrep -o "--with-compat"
Так выведет только "--with-compat", удобно использовать в переменных в BASH-скриптах.
HLS live-трасляция из ffmpeg посредством nginx. Это и m3u8, и одинаковая картинка на всех экранах в реальном времени, и (в принципе) возможность её поменять в любую секунду через входной видеопоток/плейлист.
Ankhena, для PHP это нормально, переменные внутри текстовых строк обрабатываются без проблем. К тому же ТС и не жалуется на отсутствие значений из этих переменных. Ему значения из $('input[name="material"]:checked').val() не прилетают.
Так потрудитесь сформулировать вопрос, потом перечитайте его, исправьте ошибки, ещё раз перечитайте, дайте прочитать другому человеку, объясните ему что имелось ввиду, исправьте вопрос, и потом думайте, постить ли уже вопрос на Хабр, или и так понятно где была ошибка...