Okay, dann anders.
Hast du Zugriff auf den Server wo NGINX läuft ?
Wenn ja, schalte erstmal die Access-Logs aus - das ist bei einem Flood gift.
2. Schau dir mal den User-Agent an der da zugreift - wenn das jetzt ein Bot ist oder sowas kannst du das relativ easy via return 444; in Nginx filtern und sperren.Sonst würde ich mal kurzzeitig CloudFlare auf CaptchaOnly stellen und schauen wie CF damit umgeht
Vollzugriff ist vorhanden.
Die User-Agents waren am Anfang immer gleich und hatte ich dann auch komplett geblockt, jetzt sind das unterschiedliche Client-Agents. Somit nicht möglich, diese zu blocken.
CloudFlare hab ich vorhin mal Unter Attack gestellt, war sofort ruhe. Aber das kann doch nicht die Lösung sein. 
Ich würde auf Apache verzichten und ausschließlich nginx verwenden. Nginx bekommt das zum einen selbst ganz gut gebacken und ist zweitens deutlich effizienter.
Desweiteren ist leider relativ wenig von der Konfiguration der Webserver und php-fpm oder was auch immer du verwendest bekannt. Die Tatsache das der Server viel RAM hat macht tatsächlich wenig aus, wenn du die power nicht nutzt. Im übrigen würde mich noch brennend interessieren was in der nginx.conf steht.
Ich probier das mal aus, danke für den Tipp.
#user nginx;
worker_processes 1;
#error_log /var/log/nginx/error.log;
#error_log /var/log/nginx/error.log notice;
#error_log /var/log/nginx/error.log info;
#pid /var/run/nginx.pid;
include /etc/nginx/modules.conf.d/*.conf;
events {
worker_connections 10000;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#tcp_nodelay on;
#gzip on;
#gzip_disable "MSIE [1-6]\.(?!.*SV1)";
server_tokens off;
include /etc/nginx/conf.d/*.conf;
# plesk recommended settings
proxy_send_timeout 1200s;
proxy_read_timeout 1200s;
fastcgi_send_timeout 1200s;
fastcgi_read_timeout 1200s;
}
# override global parameters e.g. worker_rlimit_nofile
include /etc/nginx/*global_params;Jetzt nutzt du schon Cloudflare und nutzt die Cache funktion scheinbar nicht. Da du ja geschrieben hast das dir das zu gefährlich ist pauschal zu cachen via Cloudflare wäre die Überlegung doch nahe mittels entsprechender Header z.B. Bilder, CSS und JS auf Langzeit zu cachen und dynamischen Inhalt für 5 Sekunden oder was in dem Dreh. Da kann man je nach Seite bestimmt nochmal deutlich optimieren durch entsprechende Weiterentwicklung. Würde ja schon reichen wenn man die Kommentare via XHR nachlädt (ohne Cache Funktion) und den Rest einfach für 1h oderso cached.
Das werde ich mir auch anschauen müssen, dass CloudFlare so ziemlich den kompletten Cache übernimmt. Ich möchte aber nicht unbedingt immer von CloudFlare abhängig sein: Auf dem Server selbst bekommt man so eine optimale Lösung sowieso nicht hin, oder? Zudem weil CloudFlare ja so eine riesen Infrastruktur hat ...
Übrigens: du kannst dir ja mal anschauen von welchen IP's die Anfragen ursprünglich abgesendet werden. Steht in $_SERVER["HTTP_CF_CONNECTING_IP"] Variable.
Hab ich nun in den access logs eingebaut, dass die Client-IPs angezeigt werden.
Sich den Useragent mal anzuschauen könnte vielleicht hilfreich sein, ist es aber in den wenigsten Fällen. Welcher Angreifer ist so blöd und nimmt einen UA mit dem er identifizierbar und problemlos sperrbar ist? Sofern man ne Message hinterlassen will gepaart mit nem Angriff reicht auch ne Mail + der Angriff.
Das war vorher tatsächlich der Fall, da wurde immer ein unreaslistischer User-Agent genutzt. Jetzt sind die leider zufällig und völlig ok.
