ky0

location /private {
...
}

Выглядит как работа не для веб-сервера, а для бэкенда.

В proxy_pass у вас схема HTTPS, а судя по логу бота, внутри там HTTP.

Network: use --host to expose

Ошибка в конфиге демонстрируется с помощью nginx -t. Кривота в конфиге - другое дело.

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

"Подключение не защищено" - в смысле невалидного сертификата или mixed content?

Пора писать трактат "о роли терминирующих слэшей в локейшенах и прокси-пассах".

Без использования кипалайва каждый коннект проходит все стадии SSL-хэндшейка - скорее всего нагрузка именно из-за этого. Попробуйте включить кипалайв и сравнить результаты.

"Часть опций" при прямом доступе к конфигу ограничить не получится - одинаковые директивы ниже по конфигу имеют более высокий приоритет. Придётся колхозить скрипт, который разрешал бы менять только нужное + проверять конфиг на валидность.

Вообще, имхо, идея не очень. Лучше сделать общий веб-сервер, и проксировать с него запросы на отдельные для каждого пользователя, которые те смогут ломать как им заблагорассудится.

В верстальщике у вас баг, а не в нгинксе.

Ограничить доступ по расширению файла легко - достаточно добавить соответствующий локейшен.

Релевантная статья: https://habr.com/ru/company/southbridge/blog/329876/

Вангую, что где-то стоит return, которому на deny начхать.

А где настройки шифрования-то? Сертификат, ключ и т. д?

В robots.txt можно указать лимиты на частоту запросов - кто это не учитывает, тот сам виноват.

У вас технический вопрос или организационный? Какую частоту запросов считать "слишком большой", никто кроме вас не скажет - это индивидуально. Посчитать это можно, проанализировав access-логи.