metajiji

Выглядит так, как будто nginx использует много cpu.
Конфиг не полный, поэтому предположу, что:
1. в конфигах много regex правил и они не оптимальны.
2. Порты до nginx зачем-то проброшены через docker-proxy(настоятельно рекомендую не делать проброс портов в продакшене вообще никогда!, Docker proxy написан на go и требует очень много CPU! Решение проблемы простое --net host, при создании контейнера с nginx.
3. Настроено gd сжатие через nginx, отсюда и трафик на cpu. Решение либо не генерить их на лету, либо отселять на другой хост.

Полный конфиг nginx можно увидеть командой nginx -T (пишу по памяти, проверьте справку:))

1) и 2) разные пользователи запустят скрипт, более ничего не произойдет. Проблемы могут быть, если этот скрипт пишет данные в файл. В таком случае данные в файле будут от последнего, кто запустил скрипт, а в случае записи в конец файла получим кашу :)
3) и 4) работа с базой по сети, там есть очередь коннектора и блокировок, причем это уже проблемы сервера, а не скрипта, можете не беспокоиться. Беспокоиться нужно если база в файле, например sqlite, msaccess, вот там блокировки нужно самостоятельно обрабатывать.

Вам нужно сделать 2 сервера для http м для https отдельно, в https сервере нужно прописать listen, настроить сертификаты... Ведь, чтобы клиент мог получить 301 код, ему нужно отправить запрос на сарвер, ваш сервер не слушает на https:)
И ещё я бы рекомендовал использовать так называемые именованные regexp, вместо $1

...
index index.php index.html index.htm;
location ~ \.php$ {
...
fastcgi_index  index.php;
}

Судя по конфигу, не указан index - документ по умолчанию. В случае использования nginx + php-fpm его указывать нужно в 2 местах, как в коде выше.

Кстати, конфиг слишком сложен и ужасен, уверен, что его можно сделать без этой кучи реврайтов, а так же без if констукций. Рекомендую почитать про try_files и поискать готовые конфиги nginx для DLE, уверен, они существуют и в более приятном виде.

По поводу слеша, все же просто:
try_files $uri $uri/ =404;
Но лучше, если само приложение будет понимать, что слешик, нужно добавить, если его вдруг нет, потому, что в текущей конфигурации все локейшены отдаются на совесть приложению.

Как вариант проксировать домен/локейшен с домена где нет https.

Попробуйте
http://wiki.nginx.org/HttpSubsModule

Или 100% вариант:

http://nginx.org/ru/docs/http/ngx_http_perl_module.html

1. логи анализировать через fail2ban, производительность будет удовлетворительная.
2,3,4,5 нагрузка на сервер может быть гораздо сильно снижена при использовании ipset

Если ip адреса или сети (банить лучше сразу целые сети - нагрузка меньше) заведомо известны и меняться не будет длительное время, есть смысл использовать route blackhole:
Например:
ip route add blackhole 127.0.0.1/32
Так же этот вариант приемлем, если фаерволл недоступен. Можно вообще использовать только этот вариант, без ipset+iptables. Естественно было бы неплохо сделать некий скирпт для суммаризации добавленных Ip.

Так же хочу отметить про netstat, вместо него лучше используйте ss он так же покажет лучшие результаты, чем netstat.

Добавлю в копилку еще вариант с expect или empty, если сильно принципиально вводить пароль :)

Согласно официальной документации рекомендуют использовать такую конструкцию:

server {
        listen 80;
        server_name example.com;
        return 301 https://$server_name$request_uri;  # enforce https
#        rewrite ^(.*) https://www.example.com$uri permanent;
}