nokimaro

Могу порекомендовать доклад от 2GIS и их вариант с написанием lua-модуля для nginx (opernresty)
https://www.youtube.com/watch?v=pYxnW7kYcbU

Доклад как минимум полезен тем, что там есть полезная информация о том как выявлять парсеры и что с этим делать.

1. Можно задать в скриптах - umask(), но нужно быть предельно осторожным и понимать что вы делаете

2. В php-fpm.conf так же можно задать umask = 0002 (для получения 664) см. Как изменить umask для пользователя www-data в debian 7?

3. Значение umask "по умолчанию" так можно задать для пользователя командой umask (например через ~/.bashrc), для случаев когда вы выполняете в консоли artisan команды авторизовавшись под dev-my см. Как поставить umask по-умолчанию?

Я бы начал с того что включил slow_query_log в MySQL

Если считаете что дело не в БД, то нужно глубже зарываться в мониторинг сервера (cpu, inodes)
Так же сессии в файлах могут стать причиной такой проблемы, и тормозящий запрос именно тот на который выпадает запуск GC.
Ну и логи php-fpm обязательно посмотреть, нету ли сообщений о том что не хватает воркеров, так как в зависимости от настроек fpm может быть затуп в момент когда создаются новые воркеры при динамическом пуле или затуп от того что кончается лимит воркеров.

Спам запросов из браузера + сессии тоже может быть причиной проблемы из-за блокировок сессий.

А откуда такая уверенность что проблема в PDO и в соединении с базой?
Судя по ошибке это может быть проблема в настройке nginx->fpm
Нормально ли запускаются скрипты если в нём убрать любое использование PDO?

прямой аналог mod_status апача ngx_http_stub_status_module
https://nginx.org/ru/docs/http/ngx_http_stub_statu...

https://www.nginx.com/blog/monitoring-nginx/

Вам скорее надо копать в сторону SSO (Single Sign-On) https://ru.wikipedia.org/wiki/SSO
Как пример реализации можно рассмотреть Google, когда авторизация проводится на accounts.google.com, при этом позволяет получить доступ в ваш аккаунт (закрытая часть) на gmail.com и youtube.com

Копать стоит в инвалидацию кеша путём смены url до .js для каждой новой версии файла.
Когда вместо script.js у вас будет некое версионирование
Например script.vXXX.js либо используют хеш от содержимого script.MD5(от содержимого скрипта).js = script.adadadasdadadsd.js и соотв-но при модификации скрипта будет меняться и url

Этот подход лучше всех остальных, так как позволяет реализовать инвалидацию кеша css/js при изменении файла, а так же эффекивно кешировать на клиенте (можно будет сразу на год)

За примером далеко ходить не надо, откройте исходный код этой страницы и увидите как пример использования этого подхода
https://qna.habr.com/frontend.5e15b533-1a38-4c3c-b...
https://qna.habr.com/frontend.5e15b533-1a38-4c3c-b...

Конфиг верный, но вы вписали проверку не туда.
Нужно вписать это в https-секцию там где у вас listen 443 и тд

Сейчас же проверка вписана в http секцию, и оно даже защищает от хотлинка по http, но не отрабатывает так как раньше срабатывает строка с редиректом http -> https. return 301 https://site.com$request_uri;

Чтобы небыло проблем с https то нужен валидный SSL сертификат, который для ip (без домена) получить очень проблематично.

В вашем случае самый оптимальный вариант такой
1. сделать субдомен и с валидным https сертификатом например iframe.mydomain.ru
2. в настройках nginx для server_name iframe.mydomain.ru делаем проксирование запросов на ваше java-приложение на нужном порту

location / {
    proxy_pass http://172.16.0.68:8085;
}

3. iframe соотв-но встраиваете как src="https://iframe.mydomain.ru/..."
Это решит вопросы и с https, вопросы cross domain доступа, а так же позволит не светить 8085 портом в мир, так как проксировать можно в рамках локальной сети.