Или обработчик формы их всё-таки использует, и тогда исправляйте логику в том месте, где обрабатываются статичные формы. Для статичных форм TOTAL_FORMS ведь не нужны, так?
На сколько я предугадываю вообще не показанный окончательный HTML/JS-код страницы с формами, formNum прекрасно инициируется/контролируется БЕЗ использования totalForms и этих скрытых полей. Имхо их можно просто стереть из кода...
Тоесть поля добавляются корректно, у них уникальные идентификаторы?
Тогда проверяйте в браузере, при submit-е формы эти поля передаются в запросе к серверу?
Если передаются - терзайте скрипт, принимающий данные, debug-те то, что ему прилетело в запросе...
Хммм, а у вас идентификаторы полей генерируются именно в виде "form-0-common_name" и т.д.?
Потому что скрипт нацелен именно на такие идентификаторы, именно их он будет инкрементировать.
Нужно смотреть в браузере, как поля создаются, инкрементируются их id или нет...
А у самого 10.128.0.4 дефортный шлюз случаем не 10.128.0.1 ли?
Ну и стоит проверить содержимое `ip rules`, на всякий случай.
И посмотреть tcpdump на обоих шлюзах, что-бы точно удостовериться именно в таком пути трафика.
Ну создавайте /tmp/php_12.34.56.78.lock файл, в названии которого 12.34.56.78 - это IP-адрес из $_SERVER['REMOTE_ADDR']. Есть такой файл - выдаём ошибку, нет такого файла - создаём и сразу работаем, по окончании - стираем. Всё.
P.S. И не забываем регулярно чистить директорию от старых неудачно сохранившихся файлов.
Так /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-скриптах.