Webserver-Audit (Apache/Nginx, PHP-FPM, MySQL): Performance & Sicherheit

Ihre Website ist langsam, wirft 502/504-Fehler oder hat Sicherheitslücken? Ihr Server läuft schon bei 50 gleichzeitigen Besuchern mit 100 % CPU-Last? Ich führe ein umfassendes technisches Audit Ihres Servers durch (Ubuntu/Debian, OVH/Scaleway, Contabo …), um die TTFB zu senken, die Last zu stabilisieren und die Sicherheit zu härten.

Das Audit deckt den gesamten technischen Stack ab: Netzwerkprotokolle (TLS/HTTP2), Webserver-Konfiguration (Nginx/Apache), PHP-FPM-Optimierung, Analyse langsamer MySQL-Abfragen, Systemhärtung und Einrichtung von Monitoring-Tools. Ergebnis: ein klarer, priorisierter Bericht – auf Wunsch setze ich die Korrekturen auch selbst um.

Warum ein Webserver-Audit?

Warnsignale, die Sie ernst nehmen sollten

Ihre Serverinfrastruktur zeigt Schwächen, wenn eines oder mehrere dieser Probleme auftreten:

Nachlassende Performance:

• Serverantwortzeit (TTFB) über 600 ms, obwohl das Ziel < 200 ms ist
• Die Website wird langsam oder unerreichbar, sobald der Traffic steigt (50–100 gleichzeitige Besucher)
• Seiten brauchen 5–10 Sekunden zum Laden, obwohl allein das HTML in < 1 Sekunde ausgeliefert werden sollte
• Die Core Web Vitals sind im roten Bereich (LCP > 4 s, TTFB > 800 ms)

Wiederkehrende Fehler:

• Fehler 502 Bad Gateway oder 504 Gateway Timeout mehrmals täglich
• Fehler 500 Internal Server Error ohne erkennbare Ursache in den Anwendungslogs
• PHP-FPM-Verbindungen, die an ihre Grenze stoßen („max children reached“)
• MySQL lehnt neue Verbindungen ab („Too many connections“)

Stabilitätsprobleme:

• Der Server muss häufig neu gestartet werden (mehrmals pro Woche)
• CPU- oder RAM-Auslastung dauerhaft bei 90–100 %, ohne dass Traffic-Spitzen das erklären
• PHP-FPM- oder MySQL-Prozesse werden zufällig beendet (OOM Killer)
• Die Logs zeigen täglich Dutzende langsamer Abfragen (> 2 Sekunden)

Sicherheitslücken:

• Abgelaufenes SSL/TLS-Zertifikat oder schwache Konfiguration (veraltete Ciphers, kein HSTS)
• Keine Firewall konfiguriert oder zu freizügige Regeln
• Kein Schutz vor Brute-Force-Angriffen (fail2ban fehlt)
• Veraltete, ungepatchte Versionen von PHP, MySQL oder dem Betriebssystem
• SSH-Zugang als root mit Passwort (statt SSH-Schlüsseln)

Geschäftliche Auswirkungen dieser Probleme

Ein schlecht konfigurierter Server hat direkte und messbare Folgen für Ihr Geschäft:

Umsatzverluste: Eine Website, die 5 Sekunden zum Laden braucht, verliert 20 % ihrer Besucher (Google-Studie). Bei einem Onlineshop mit 50.000 €/Monat entspricht das einem monatlichen Umsatzausfall von 10.000 €.

SEO-Nachteile: Google straft langsame Websites in seinem Algorithmus ab. Eine Seite, deren Ladezeit von 2 auf 5 Sekunden steigt, kann innerhalb weniger Monate 30–50 % ihres organischen Traffics verlieren.

Aufgeblähte Infrastrukturkosten: Ein schlecht optimierter Server erfordert oft ein teures Hardware-Upgrade (von 4 auf 8 CPUs, doppelter RAM), obwohl eine einfache Software-Optimierung das Problem für ein Zehntel des Preises lösen würde.

Hackerrisiko: 43 % der Cyberangriffe zielen auf KMU (Verizon-Report 2024). Ein nicht gehärteter Server ist ein Einfallstor für Phishing, den Diebstahl von Kundendaten oder Ransomware.

Was ich im Detail analysiere

Mein Server-Audit umfasst 7 wesentliche technische Ebenen – mit Vorher-nachher-Messungen, um die Verbesserungen zu beziffern.

1. Netzwerk & Protokoll

Was ich prüfe:

• TLS/HTTPS-Konfiguration: Protokollversion (mindestens TLS 1.2, idealerweise 1.3), sichere Cipher-Suites, vollständige Zertifikatskette
• Security-Header: HSTS, CSP, X-Frame-Options, X-Content-Type-Options
• HTTP/2 oder HTTP/3 aktiviert für Multiplexing und Header-Komprimierung
• Gzip/Brotli-Komprimierung für HTML/CSS/JS/JSON konfiguriert
• DNS: Auflösungszeit, DNSSEC-Konfiguration falls zutreffend

Was das zeigt: Veraltete Ciphers (RC4, 3DES) machen Ihre Website anfällig für Angriffe wie BEAST oder POODLE. Fehlendes HTTP/2 kostet bei ressourcenreichen Seiten 20–30 % Geschwindigkeit. Eine hohe DNS-TTFB (> 100 ms) bremst systematisch alle Anfragen.

Messbare Wirkung: Umstieg auf TLS 1.3 + HTTP/2 + Brotli = 25–40 % kürzere Gesamtladezeit und Note A+ bei SSL Labs.

2. Nginx-/Apache-Konfiguration

Was ich prüfe:

• Statischer Cache: Direktiven expires, cache-control, etag für Bilder/CSS/JS
• Komprimierungs-Header: gzip_types, brotli_types
• Logs: angepasstes Format mit $request_time und $upstream_response_time zum Debuggen
• Rate Limiting: Schutz vor Scrapern und aggressiven Bots
• Einfache WAF: ModSecurity oder Nginx limit_req, um gängige Angriffsmuster zu blockieren
• Konfigurationsdateien: worker_processes, worker_connections, keepalive_timeout, client_max_body_size

Was das zeigt: worker_connections mit 768 statt 4096 begrenzen künstlich die Zahl gleichzeitiger Verbindungen. Ohne statischen Cache muss der Browser die Assets bei jedem Besuch neu herunterladen. Ein client_max_body_size von 2M blockiert den Upload von Mediendateien.

Messbare Wirkung: Optimale Konfiguration = 50–60 % weniger Bandbreite dank Browser-Cache + Kapazität für 4-mal so viele gleichzeitige Verbindungen.

3. PHP-FPM: der unsichtbare Flaschenhals

Was ich prüfe:

• Strategie der Prozessverwaltung: pm = dynamic vs. static vs. ondemand
• Dimensionierung: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers
• Limits: pm.max_requests (Recycling der Worker), request_timeout, request_terminate_timeout
• Opcache: opcache.memory_consumption, opcache.interned_strings_buffer, opcache.max_accelerated_files, Trefferquote
• PHP-Limits: memory_limit, max_execution_time, post_max_size, upload_max_filesize
• Slow-Logs: Aktivierung und Analyse langsamer PHP-Anfragen (> 1 s)

Was das zeigt: Das ist DER Engpass Nr. 1 auf 80 % der Server. Typisches Beispiel: pm.max_children = 5 auf einem Server mit 4 CPUs → ab 6 gleichzeitigen Anfragen landen die folgenden in der Warteschlange, was Timeouts verursacht.

Ein schlecht konfigurierter Opcache (zu klein, kein Preloading unter PHP 8.x) zwingt PHP, die Skripte bei jeder Anfrage neu zu kompilieren – das vervielfacht die CPU-Last um den Faktor 5–10.

Messbare Wirkung: Umstellung von pm.max_children = 5 auf pm.max_children = 40 (dimensioniert nach verfügbarem RAM) + optimierter Opcache = 70 % weniger TTFB + keine „502 Bad Gateway“-Fehler mehr.

Konkretes Beispiel: WordPress-Website mit WooCommerce, 4 GB RAM, pm.max_children = 5 (Standard).

• Vorher: 502-Fehler ab 8 gleichzeitigen Besuchern, TTFB 3–6 Sekunden
• Nachher: pm.max_children = 30, pm = dynamic, Opcache aktiviert → TTFB 0,4 s, kein einziger 502-Fehler bis 100 gleichzeitige Besucher

4. Datenbank MySQL / MariaDB

Was ich prüfe:

• Verbindungskonfiguration: max_connections, wait_timeout, interactive_timeout
• Buffer und Cache: innodb_buffer_pool_size, query_cache_size (bei MySQL < 8.0), tmp_table_size
• Slow Query Log: Aktivierung und Analyse von Abfragen > 1 Sekunde
• Fehlende Indizes: EXPLAIN auf die häufigsten Abfragen, um Full Table Scans zu erkennen
• Sperren: Erkennung von Deadlocks und lang laufenden Transaktionen
• Tabellenoptimierung: Fragmentierung, ungenutzte Tabellen, ANALYZE TABLE

Was das zeigt: Ein innodb_buffer_pool_size von 128 MB (Standard) auf einem Server mit 16 GB RAM = MySQL kann häufig genutzte Daten nicht cachen und greift ständig auf die Festplatte zu.

Abfragen ohne Index zwingen MySQL, 500.000 Zeilen statt 10 zu durchsuchen – das verlängert die Ausführungszeit um den Faktor 5.000 (von 0,001 s auf 5 s).

Messbare Wirkung: innodb_buffer_pool_size auf 70 % des RAM angepasst + 3–5 strategische Indizes = 80 % weniger Slow Queries + Seitenantwortzeit gedrittelt.

5. Anwendungs-Performance & TTFB

Was ich messe:

• TTFB (Time To First Byte) von verschiedenen geografischen Standorten aus: Ziel < 200 ms für Europa
• LCP (Largest Contentful Paint): Ziel < 2,5 s
• Reine HTML-Generierungszeit (ohne Assets): sollte bei einer dynamischen Seite < 400 ms liegen
• Anzahl der SQL-Abfragen pro Seite: mehr als 50 Abfragen = N+1-Problem, das untersucht werden muss
• Größe und Gewicht der Assets: nicht optimierte Bilder, nicht minifiziertes JS/CSS
• Strategie für den Anwendungs-Cache: Redis/Memcached, statischer HTML-Cache (Varnish, nginx fastcgi_cache)

Was das zeigt: Eine TTFB von 2–4 Sekunden bedeutet, dass der Server so lange braucht, um überhaupt anzufangen, Daten zu senden. Selbst mit Glasfaseranschluss wartet der Nutzer. Ursache ist oft eine Kombination aus langsamem PHP + nicht optimierten MySQL-Abfragen + fehlendem Cache.

Messbare Wirkung: Kombinierte Optimierung (PHP-FPM + MySQL + Redis-Cache) = TTFB sinkt von 2,8 s auf 0,3 s, LCP von 6 s auf 2,1 s → die Core Web Vitals erreichen „Good“.

6. Systemsicherheit & Härtung

Was ich prüfe:

• Firewall: UFW oder iptables konfiguriert, minimal geöffnete Ports (22, 80, 443), Blockieren von Portscans
• Fail2ban: Schutz von SSH, HTTP und MySQL vor Brute-Force-Angriffen
• SSH-Zugang: Root-Login deaktiviert, Authentifizierung nur per SSH-Schlüssel, nicht standardmäßiger Port
• Benutzer und Berechtigungen: keine Dienste unter root, Trennung der Benutzer für Web/DB
• Updates: PHP, MySQL und Betriebssystem aktuell und mit Sicherheitspatches
• Backups: Häufigkeit, Aufbewahrung, Wiederherstellungstest, Speicherung außerhalb des Servers
• Log-Rotation: logrotate konfiguriert, Komprimierung, automatisches Löschen alter Logs
• Einbruchserkennung: Erkennung veränderter Dateien, Überwachung der Systemintegrität

Was das zeigt: Bei 80 % der auditierten Server fehlt fail2ban oder ist falsch konfiguriert – Tausende SSH-Anmeldeversuche pro Tag sind die Folge. Fehlende getestete Backups = Risiko eines totalen Datenverlusts bei einem Festplattenausfall oder Ransomware.

Messbare Wirkung: Vollständige Härtung = 95 % weniger Einbruchsversuche (fail2ban-Logs) + gesicherte Wiederherstellung in < 2 Std. bei einem schweren Vorfall.

7. Observability & Monitoring

Was ich einrichte:

• Log-Analyse: PHP-Fehler, Nginx-Fehler, MySQL Slow Queries, Systemfehler
• Server-Metriken: CPU, RAM, Festplatte, Netzwerk, Swap
• Einfaches Alerting: E-Mail/SMS, wenn CPU > 90 % für 5 Min., Festplatte > 85 %, Dienst ausgefallen
• Tools: Netdata (schlank, kostenlos) oder New Relic (wenn Budget vorhanden)
• Einfaches Dashboard: Serverzustand auf einen Blick

Wirkung: Proaktive Erkennung: Die Warnung kommt 10 Minuten bevor der Server ausfällt, statt dass Sie das Problem durch verärgerte Kunden erfahren. Senkung der MTTR (Mean Time To Repair) von 2 Stunden auf 15 Minuten.

Meine vollständige Methodik

Phase 1: Zugang & Voranalyse (30 Min.)

Zugang:

• SSH-Verbindung (bereitgestellter Public Key) oder Zugang zum Panel OVH/Plesk/ISPConfig
• Lesezugriff auf die Logs (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
• MySQL-Zugangsdaten mit Lesezugriff zur Analyse der Slow Queries

Erste Datenerhebung:

• Bestandsaufnahme: Versionen von PHP, MySQL, System, Webserver
• Statistiken: Uptime, Load Average, aktuelle CPU-/RAM-/Festplattenauslastung
• Schnelle Durchsicht der Logs: Erkennen wiederkehrender Fehler

Phase 2: Performance- & Lasttests (1 Std.)

Baseline-Messungen:

• TTFB von 3 verschiedenen Standorten (Europa, USA, Asien) mit curl/webpagetest
• Lasttest: Simulation von 10, 50, 100 gleichzeitigen Nutzern mit Apache Bench oder k6
• PHP-Profiling: Aktivierung von Xdebug oder Blackfire, um langsame Funktionen zu identifizieren
• MySQL-Analyse: Top 20 der langsamen Abfragen mit pt-query-digest (Percona Toolkit)

Engpässe identifizieren: Der Lasttest zeigt genau, wo es bricht: Ist PHP-FPM überlastet? Sperrt MySQL? Lagert der RAM in den Swap aus?

Phase 3: Sicherheitsanalyse (45 Min.)

Schwachstellen-Scan:

• SSL-Test: ssllabs.com, testssl.sh, um TLS-Schwächen aufzudecken
• Scan offener Ports: nmap, um unnötig exponierte Dienste zu erkennen
• CVE-Prüfung: veraltete PHP-/MySQL-Versionen mit bekannten Schwachstellen
• Datei-Audit: Dateien mit 777-Berechtigungen, mögliche Backdoor-Skripte

Konfigurations-Review:

• Analyse von /etc/ssh/sshd_config, Firewall-Regeln, fail2ban-Jails
• Prüfung, ob Backups vorhanden und gültig sind

Phase 4: Analyse der Konfigurationen (1 Std.)

Deep Dive in die Konfigurationen:

• Nginx/Apache: zeilenweise Durchsicht der Konfigurationsdateien + Benchmarks
• PHP-FPM: Berechnung des gesamten Speicherverbrauchs (pm.max_children * memory_limit) im Vergleich zum verfügbaren RAM
• MySQL: Analyse der my.cnf, Empfehlungen von MySQLTuner
• System: Konfiguration der Limits (ulimit), Swap, Kernel-Parameter

Phase 5: Erstellung des Berichts (1–2 Std.)

Aufbau des Berichts:

1. Executive Summary (2 Seiten)

• Die 3 identifizierten kritischen Probleme
• Geschätzte geschäftliche Auswirkungen (z. B. Verlust von 15 % des SEO-Traffics, 25 % der Besucher springen ab)
• Budget für Korrekturen: 0–500 € (Konfiguration), 500–1.500 € (komplexe Optimierungen), > 1.500 € (Migration/Hardware-Upgrade)

2. Detaillierte Diagnosen (5–10 Seiten)

• Jedes Problem dokumentiert mit Screenshots, Log-Auszügen, Metriken
• Verständliche technische Erklärung (kein unnötiger Fachjargon)
• Schweregrad: Kritisch / Wichtig / Chance

3. Priorisierter Maßnahmenplan (2–3 Seiten) Tabelle: Maßnahme | Geschätzte Wirkung | Komplexität | Zeit | Kosten

Beispiel:

• pm.max_children von 5 auf 30 erhöhen | 70 % weniger 502-Fehler | Gering | 10 Min. | Inklusive
• 3 MySQL-Indizes auf der Tabelle orders hinzufügen | Abfragen 50-mal schneller | Mittel | 1 Std. | Inklusive
• Migration auf einen Server mit 8 GB RAM | Hält die 3-fache Last aus | Hoch | 4 Std. | 150 € Migration

4. Langfristige Empfehlungen

• Plan für kontinuierliches Monitoring
• Empfohlene Update-Häufigkeit
• Verbesserungs-Roadmap über 6–12 Monate

Konkretes Kundenbeispiel: Onlineshop mit WooCommerce

Ausgangslage

Kunde: Onlineshop für Kunsthandwerk, 500–800 Besucher/Tag, 5.000 Produkte, durchschnittlicher Warenkorb 85 €.

Infrastruktur:

• VPS OVH Comfort (4 vCPU, 4 GB RAM)
• Ubuntu 20.04, Nginx 1.18, PHP 7.4, MySQL 5.7
• WordPress 6.1 + WooCommerce 7.5 + 15 aktive Plugins

Gemeldete Symptome

• Tägliche Verlangsamungsspitzen zwischen 14 und 16 Uhr (Mittagspause = maximaler Traffic)
• 502-Bad-Gateway-Fehler 2–3 Mal täglich, die einen Neustart von PHP-FPM erforderten
• Produktseiten mit 6–8 Sekunden Ladezeit
• Die Google Search Console meldet „Poor“ für 70 % der Seiten (LCP > 4 s)
• Absprungrate in 3 Monaten von 45 % auf 62 % gestiegen
• Geschätzter Verlust: 200–300 €/Tag an entgangenen Verkäufen

Diagnosen des Audits (2 Std. 30 Min.)

1. PHP-FPM: katastrophale Konfiguration

pm = dynamic
pm.max_children = 5 ATTENTION: (CRITIQUE)
pm.start_servers = 2
memory_limit = 128M

Rechnung: 5 Kindprozesse × 128 MB = max. 640 MB für PHP, obwohl 4 GB RAM verfügbar sind → ab 6 gleichzeitigen Anfragen Warteschlange → 502-Timeout

2. MySQL: langsame Abfragen und fehlende Indizes

• 847 Abfragen > 2 Sekunden in den letzten 24 Std.
• Abfrage auf wp_postmeta ohne Index: 3,8 s, um nach meta_key zu filtern
• innodb_buffer_pool_size = 128M (Standard), obwohl die Datenbank 2,1 GB groß ist

3. PHP-Opcache: deaktiviert

• PHP kompiliert bei jeder Anfrage alle WordPress-/WooCommerce-Dateien neu
• Unnötige CPU-Last um den Faktor 8–10 erhöht

4. Kein Anwendungs-Cache

• Kein HTML-Cache-Plugin (WP Super Cache, W3 Total Cache)
• Jede Seite wird bei jedem Besuch neu berechnet, selbst für nicht angemeldete Besucher

5. Schwache Sicherheit

• Fail2ban nicht installiert: 3.200 SSH-Anmeldeversuche pro Tag
• PHP 7.4: 12 ungepatchte kritische CVEs (PHP 8.1 verfügbar)

Umgesetzte Korrekturen (3 Std.)

PHP-FPM (15 Min.)

pm.max_children = 30 (4GB RAM / 130MB par enfant)
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

Opcache (5 Min.)

opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 0 (prod)
opcache.enable_cli = 1

MySQL (45 Min.)

-- Ajout index manquant
ALTER TABLE wp_postmeta ADD INDEX meta_key_value (meta_key, meta_value(20));
-- Configuration
innodb_buffer_pool_size = 2G (50% de la RAM)
max_connections = 200
query_cache_size = 0 (inutile MySQL 5.7+)

Anwendungs-Cache (30 Min.)

• Installation von WP Rocket (Lizenz des Kunden)
• Konfiguration: HTML-Cache, CSS/JS-Minifizierung, Lazy Loading für Bilder
• Cache-Generierung für die Top 500 Seiten

Sicherheit (1 Std.)

• Update von PHP 7.4 → 8.1
• Installation von fail2ban mit Jails für SSH + HTTP
• SSH-Härtung: root deaktiviert, nur Schlüssel
• Automatische tägliche Backups nach S3

Gemessene Ergebnisse (7 Tage danach)

Performance:

• TTFB: ~~3,2 s~~ → 0,4 s (−87 %)
• LCP: ~~6,1 s~~ → 2,0 s (−67 %)
• Produktseite: ~~7,2 s~~ → 1,8 s (−75 %)
• Core Web Vitals: ~~12 % Good~~ → 89 % Good

Stabilität:

• 502-Fehler: ~~2–3/Tag~~ → 0 in 7 Tagen
• Load Average: ~~4,5~~ → 0,8 (bei 4 CPUs)
• RAM-Auslastung: ~~92 %~~ → 65 %

Geschäftlich:

• Absprungrate: ~~62 %~~ → 48 % (−14 Prozentpunkte)
• Verweildauer: +22 %
• Conversions: +18 % (berechnet über 7 Tage im Vergleich zur Vorwoche)
• Schätzung: +280 €/Tag Umsatz, also +8.400 €/Monat

Sicherheit:

• Blockierte SSH-Versuche: 3.200/Tag → 0 (IPs automatisch gesperrt)
• CVE-Schwachstellen: ~~12 kritische~~ → 0

Gesamtkosten: Audit (490 €) + Umsetzung (350 €) + WP-Rocket-Lizenz (59 €/Jahr) = 899 € netto ROI: Nach 3 Tagen Mehrumsatz amortisiert

Server-Audit im Vergleich zu anderen Audits

Es ist wichtig, die verschiedenen Arten von Web-Audits klar zu unterscheiden, da sie nicht dieselben Aspekte abdecken:

Mein Rat: Wenn Ihre Website lahmt, beginnen Sie immer mit dem Server-Audit. Es bringt nichts, Ihre Bilder zu optimieren, wenn Ihre TTFB wegen eines falsch konfigurierten PHP-FPM bei 4 Sekunden liegt.

Checkliste: Brauchen Sie ein Server-Audit?

Beantworten Sie die folgenden Fragen ehrlich. Wenn Sie 3 oder mehr Kästchen ankreuzen, ist ein Server-Audit dringend zu empfehlen.

• [ ] Meine Website braucht bei guter Verbindung mehr als 3 Sekunden zum Laden
• [ ] Ich habe mindestens einmal pro Woche 502-, 504- oder 500-Fehler
• [ ] Mein Server muss mindestens einmal im Monat manuell neu gestartet werden
• [ ] Ich kenne den Wert von pm.max_children in meinem PHP-FPM nicht
• [ ] Meine Website wird bei 50+ gleichzeitigen Besuchern deutlich langsamer
• [ ] Ich habe meine MySQL-Datenbank noch nie optimiert
• [ ] Mein SSL-Zertifikat hat bei SSL Labs eine Note < A
• [ ] Ich habe seit über 6 Monaten kein System- oder PHP-Update durchgeführt
• [ ] Ich habe kein getestetes automatisches Backup-System
• [ ] Mein Hoster hat mich schon wegen „übermäßiger Ressourcennutzung“ kontaktiert
• [ ] Die Google Search Console zeigt „Poor“ für meine Core Web Vitals
• [ ] Meine Absprungrate ist in den letzten Monaten ohne erkennbaren Grund um mehr als 10 % gestiegen

Auswertung:

• 0–2 Kreuze: Ihr Server scheint in Ordnung zu sein, eine vorbeugende Prüfung alle 12–18 Monate ist aber dennoch empfehlenswert
• 3–5 Kreuze: Audit innerhalb von 1–2 Monaten empfohlen – wahrscheinlich gibt es einfache Quick Wins
• 6+ Kreuze: Audit dringend – Sie verlieren vermutlich jeden Tag Kunden und Umsatz

Leistungsumfang & Ablauf

Was Sie erhalten

1. Vollständiger Audit-Bericht (PDF, 15–25 Seiten)

• Executive Summary mit den 3 kritischsten Problemen
• Detaillierte Diagnosen mit Screenshots und Log-Auszügen
• Maßnahmenplan, priorisiert nach Wirkung/Komplexität
• Langfristige Empfehlungen

2. Optimierte Konfigurationsdateien

• Kommentierte, einsatzbereite Nginx-/Apache-Konfigurationen
• Für Ihren Server dimensionierter PHP-FPM-Pool
• Optimierte MySQL-Datei my.cnf
• Einfache Monitoring- und Alerting-Skripte

3. Prozessdokumentation

• Checkliste für das Ausrollen der Korrekturen
• Rollback-Anleitung für den Problemfall
• Verfahren zur Wiederherstellung von Backups

4. Nachbetreuung (optional)

• Zugang zum Monitoring-Dashboard für 30 Tage
• 7 Tage E-Mail-Support für Fragen
• 30-minütige Schulung (Konfiguration, Lesen der Metriken)

Typischer Ablauf

Tag 0: Erstkontakt

• 15-minütiges Briefing per Telefon oder Video, um Ihre Probleme zu verstehen
• Versand eines technischen Vorab-Fragebogens
• Angebot innerhalb von 24 Std.

Tag 1 bis 2: Zugang & Vorbereitung

• Einrichtung der SSH-/Panel-Zugänge
• Installation nicht-invasiver Monitoring-Tools, falls gewünscht
• Erfassung der Logs und Baseline-Metriken

Tag 3: Audit (2–4 Stunden)

• Gründliche Analyse aller Ebenen (Netzwerk, Server, PHP, MySQL, Sicherheit)
• Lasttests, um die Grenzen zu ermitteln
• Dokumentation der Befunde in Echtzeit

Tag 4 bis 5: Bericht & Präsentation

• Erstellung des vollständigen Berichts
• 30–45-minütige Videokonferenz zur Präsentation der Befunde und Empfehlungen
• Beantwortung Ihrer technischen Fragen

Tag 6 (optional): Umsetzung der Korrekturen

• Vollständiges System-Backup vor dem Eingriff
• Umsetzung der Optimierungen nach Priorität
• Regressionstests nach jeder Änderung
• Messungen nach dem Eingriff: Prüfung, ob die Ziele erreicht wurden

Tag 7: Abnahme & Abschluss

• Abnahmebericht mit Vorher-nachher-Metriken
• Wissenstransfer und kurze Schulung
• Abschließende Dokumentation + 7 Tage Support

Typische Ergebnisse nach Audit + Optimierung

Auf Grundlage von über 40 seit 2020 durchgeführten Server-Audits sind dies die durchschnittlich festgestellten Verbesserungen:

Performance

• TTFB um 30 bis 70 % reduziert: im Schnitt von 1,5–3 s auf 0,3–0,8 s
• LCP um 40–60 % verbessert: Die meisten Websites wechseln von „Poor“ zu „Good“ (< 2,5 s)
• Lastkapazität um den Faktor 3–5 erhöht: Ein Server, der bei 30 gleichzeitigen Besuchern abstürzte, verkraftet jetzt 100–150
• Keine 5xx-Fehler mehr: 90 % der Websites haben nach der Optimierung keinen einzigen 502/504-Fehler mehr

Sicherheit

• Über 95 % weniger Einbruchsversuche dank fail2ban
• Kleinere Angriffsfläche: Schließen unnötiger Ports, Sicherheitsupdates eingespielt
• SSL-Note steigt von B/C auf A+ durch TLS-Härtung
• Verbesserte Compliance: DSGVO (Verschlüsselung, Backups), PCI DSS (bei E-Commerce)

Kosten

• 30–50 % Einsparung bei der Infrastruktur: Ein teures Server-Upgrade wird oft überflüssig
• 70–80 % weniger Wartungsaufwand: weniger Feuerwehreinsätze, proaktives Monitoring
• Durchschnittlicher ROI: 3–6 Monate für einen Onlineshop (durch höhere Conversions)

SEO & Conversion

• 15–30 % mehr organischer Traffic dank der Core Web Vitals (Google-Rankingfaktor)
• Absprungrate sinkt um 10–20 Prozentpunkte: Besucher springen nicht mehr wegen langer Ladezeiten ab
• Conversion-Rate steigt um 10–25 %: Eine schnelle Website konvertiert besser

Abgedeckte Umgebungen

Betriebssysteme

• Ubuntu 18.04, 20.04, 22.04, 24.04 LTS
• Debian 10, 11, 12
• Andere Linux-Distributionen auf Anfrage (CentOS, Rocky Linux, Alpine)

Hoster & Infrastrukturen

• OVH / OVHcloud (VPS, Dedicated, Public Cloud)
• Scaleway (Instances, Elastic Metal)
• Contabo (VPS, Dedicated)
• Hetzner (Cloud, Dedicated)
• DigitalOcean, Linode, Vultr
• Dedizierte On-Premise-Server

Verwaltungspanels

• Plesk Obsidian
• ISPConfig 3.x
• cPanel/WHM (weniger Erfahrung, aber machbar)
• Manuelle Konfiguration (ohne Panel): bevorzugt für maximale Performance

Webserver

• Nginx 1.18+ (für Performance empfohlen)
• Apache 2.4+ mit MPM Event oder Worker
• OpenLiteSpeed (auf Anfrage)
• Hybride Konfigurationen (Nginx als Reverse Proxy + Apache-Backend)

PHP

• PHP 7.4, 8.0, 8.1, 8.2, 8.3 (alle FPM-Versionen)
• Unterstützung mehrerer gleichzeitiger PHP-Versionen
• Erweiterungen: opcache, APCu, Redis, Memcached, imagick usw.

Datenbanken

• MySQL 5.7, 8.0+
• MariaDB 10.3, 10.5, 10.6, 10.11+
• PostgreSQL (auf Anfrage, weniger Erfahrung als mit MySQL)

Gängige Webanwendungen

• WordPress / WooCommerce (80 % meiner Erfahrung)
• Magento 2.x
• PrestaShop 1.7, 8.x
• Drupal 9, 10
• Laravel, Symfony, CodeIgniter (PHP-Frameworks)
• Individuelle PHP-Anwendungen

Preise & Fristen

Audit-Pakete

Audit Essentiel – 390 € netto

• Einfacher Server: 1 Website, Standard-Stack (Nginx/Apache + PHP + MySQL)
• 2–3 Std. Analyse
• Bericht mit 10–15 Seiten und priorisiertem Maßnahmenplan
• Optimierte Konfigurationsdateien inklusive
• Ideal für: Unternehmenswebsite, Blog, kleinen Onlineshop (< 1.000 Besucher/Tag)

Audit Avancé – 690 € netto

• Komplexer Server: mehrere Websites, individuelle Konfigurationen, hoher Traffic
• 4–6 Std. gründliche Analyse
• Bericht mit 20–30 Seiten + Lasttests + Anwendungs-Profiling
• Architekturempfehlungen (Redis, CDN, Load Balancing)
• 1-stündige Videopräsentation der Befunde
• Ideal für: mittlere/große Onlineshops, SaaS, Branchenanwendungen

Audit + Umsetzung – nach Angebot (typischerweise 900–1.500 € netto)

• Audit Avancé + ich setze die Korrekturen selbst um
• Vollständiges Backup vor dem Eingriff
• Regressionstests
• Vorher-nachher-Messungen mit Abnahmebericht
• 7 Tage Support nach dem Eingriff
• Ideal, wenn: Sie intern keine Systemkompetenzen haben

Notfall-Audit (< 24 Std.) – Preis × 1,5

• Einsatz innerhalb von 24 Std. (an Werktagen)
• Express-Bericht innerhalb von 48 Std.
• Ideal für: laufende Krise, Website down, kürzlicher Hackerangriff

Zusatzoptionen

• Schulung (1 Std.): +150 € netto
  • Lesen der Metriken, Nutzung des Monitorings, vorbeugende Wartung
• Monatlicher Wartungssupport: ab 200 € netto/Monat
  • Monatliche Sicherheitsupdates
  • Monitoring rund um die Uhr (24/7) mit Alerting
  • Korrigierende Eingriffe inklusive (bis zu 2 Std./Monat)
• Folge-Audit (nach 6 Monaten): −50 % auf den ursprünglichen Preis
  • Prüfung, ob die Optimierungen dauerhaft wirken
  • Anpassungen bei verändertem Traffic

Standardfristen

• Angebot: innerhalb von 24 Std. nach dem ersten Briefing
• Zugang & Vorbereitung: Tag 1 bis 2
• Audit: Tag 3 (2–4 Std. konzentrierte Arbeit)
• Lieferung des Berichts: Tag 4 bis 5
• Umsetzung (optional): Tag 6
• Abschließende Abnahme: Tag 7

Gesamtdauer: durchschnittlich 7 Werktage, im Notfall 3–4 Tage.

In allen Preisen enthalten

Vollständige Analyse der 7 Ebenen (Netzwerk, Server, PHP, MySQL, Sicherheit, Performance, Monitoring) Detaillierter PDF-Bericht mit Screenshots und umsetzbaren Empfehlungen Optimierte, einsatzbereite Konfigurationsdateien 30-minütige Videopräsentation der Befunde (ab Paket Avancé) 1 Runde Rückfragen per E-Mail nach der Lieferung

Zahlungsmöglichkeiten

• Banküberweisung (IBAN auf der Rechnung)
• Kreditkarte über Stripe (sicherer Zahlungslink)
• PayPal (französische Unternehmen)

Konditionen: 50 % bei Auftragserteilung (nach Annahme des Angebots), 50 % bei Lieferung des Berichts.

Häufige Fragen

Was genau umfasst das Webserver-Audit?

Das Audit analysiert 7 technische Ebenen: Netzwerkprotokoll (TLS/HTTP2), Webserver-Konfiguration (Nginx/Apache), PHP-FPM-Optimierung (pm.*, opcache), MySQL-Datenbank (langsame Abfragen, fehlende Indizes), Systemsicherheit (fail2ban, Firewall, Updates), Anwendungs-Performance (TTFB, Core Web Vitals) und Monitoring (Logs, Metriken, Alerting). Sie erhalten einen detaillierten Bericht mit priorisiertem Maßnahmenplan.

Können Sie die gefundenen Probleme beheben oder nur aufzeigen?

Beides ist möglich. Die Pakete „Audit Essentiel“ und „Avancé“ identifizieren die Probleme und liefern optimierte Konfigurationsdateien, die Ihr Technikteam ausrollen kann. Das Paket „Audit + Umsetzung“ umfasst die Umsetzung der Korrekturen durch mich – mit vorherigem Backup, Regressionstests und Vorher-nachher-Messungen. Diese Option empfehle ich, wenn Sie intern keinen Systemadministrator haben.

Wie lange dauert ein Audit und was kostet es?

Basis-Audit ab 390 € netto für einen einfachen Server, durchgeführt innerhalb von 7 Werktagen (Notfall in 24 Std. gegen Aufpreis möglich). Das Paket „Audit + Umsetzung“ gibt es nach Angebot (typischerweise 900–1.500 € netto), je nach Komplexität. Ein kostenloses 15-minütiges Erstbriefing ermöglicht ein genaues Angebot innerhalb von 24 Std.

Muss ich meine Website während des Audits abschalten?

Nein, das Audit ist nicht invasiv. Die Analyse erfolgt überwiegend lesend per SSH (Logs, Konfigurationen, Metriken). Lasttests werden mit Ihnen abgestimmt und können auf Wunsch in verkehrsarme Zeiten gelegt werden. Nur die Umsetzung der Korrekturen (optionales Paket) kann 2–5 Minuten Ausfallzeit für den Neustart von Diensten (PHP-FPM, MySQL) erfordern – das wird im Voraus geplant.

Mein Server läuft bei OVH/Scaleway/einem anderen Anbieter – ist das ein Problem?

Überhaupt nicht. Ich arbeite regelmäßig mit OVH, Scaleway, Hetzner, Contabo, DigitalOcean und anderen gängigen Hostern. Das Audit ist unabhängig vom Hoster möglich, solange ich SSH- oder Panel-Zugang habe (Plesk, ISPConfig). Ist Ihr Hoster sehr speziell (z. B. Managed Hosting auf AWS mit Einschränkungen), klären wir die Machbarkeit in einem Vorab-Briefing.

Was passiert, wenn Sie kritische Sicherheitslücken finden?

Ich warne Sie sofort (noch vor Abschluss des gesamten Audits), wenn ich eine aktiv ausnutzbare kritische Schwachstelle entdecke (Backdoor, PHP-Version mit kritischer, aktiv ausgenutzter CVE, völlig offener Server). Der Bericht enthält anschließend einen priorisierten Maßnahmenplan mit den dringenden Korrekturen ganz oben. Mit dem Paket „Audit + Umsetzung“ kann ich die Sicherheitspatches sofort nach ihrer Identifizierung vorrangig einspielen.

Umfasst das Audit auch die Optimierung meines Anwendungscodes?

Das Server-Audit konzentriert sich auf Infrastruktur und Systemkonfiguration (Server, PHP, MySQL). Ich kann feststellen, dass eine Seite 150 SQL-Abfragen ausführt oder bestimmte PHP-Funktionen langsam sind (per Profiling), aber die detaillierte Optimierung des Anwendungscodes (Refactoring, Umschreiben komplexer Abfragen) gehört in ein eigenes Anwendungs-Audit. Da jedoch 80 % der Performance-Probleme auf die Serverkonfiguration zurückgehen, löst das Audit die Mehrheit der Fälle.

Geben Sie eine Ergebnisgarantie?

Ich garantiere, dass der Bericht umsetzbare und messbare Empfehlungen enthält. Beim Paket „Audit + Umsetzung“ verpflichte ich mich zu konkreten Zielwerten, die wir vorab gemeinsam festlegen (z. B. TTFB < 400 ms, 0 Fehler 502 über 7 Tage, Core Web Vitals „Good“ auf 80 %+ der Seiten). Werden die Ziele nach dem Eingriff nicht erreicht, optimiere ich ohne Aufpreis weiter, bis Sie zufrieden sind.

Kann ich einen Beispiel-Auditbericht erhalten?

Ja, auf Anfrage per E-Mail sende ich Ihnen gern einen anonymisierten Bericht (Kundendaten unkenntlich gemacht), der Ihnen eine genaue Vorstellung von Detailtiefe und Format vermittelt. Schreiben Sie mir an [Ihre E-Mail] mit dem Betreff „Beispiel Auditbericht“.

Bieten Sie Nachbetreuung oder Wartung nach dem Audit an?

Ja, es gibt mehrere Optionen:

• Support nach dem Audit inklusive: 7 Tage Fragen und Antworten per E-Mail nach der Lieferung
• Folge-Audit nach 6 Monaten: −50 % auf den ursprünglichen Preis, um zu prüfen, ob alles dauerhaft hält
• Monatliche Wartung: ab 200 €/Monat inklusive Sicherheitsupdates, Monitoring rund um die Uhr (24/7) und korrigierender Eingriffe (bis zu 2 Std./Monat)

Meine Website läuft mit WordPress/Shopify/einem anderen CMS – ändert das etwas?

Das Server-Audit ist CMS-unabhängig, da es sich auf die Systemebene konzentriert (Linux, Nginx, PHP, MySQL). Meine umfangreiche Erfahrung mit WordPress/WooCommerce (80 % meiner Audits) erlaubt es mir jedoch, weiter zu gehen: Ich kann problematische Plugins prüfen, die WP-Datenbank optimieren (wp_options, Transients), einen Objekt-Cache (Redis) konfigurieren usw. Bei gehostetem Shopify ist ein Server-Audit nicht möglich (die Infrastruktur wird von Shopify verwaltet), ich kann aber individuelle Shopify-Apps prüfen, sofern sie auf Ihrem Server gehostet werden.

Welche Zugänge zu meinem Server benötigen Sie?

Mindestanforderungen:

• SSH-Zugang (Benutzerkonto mit sudo oder root, falls akzeptiert) über einen von mir bereitgestellten Public Key
• Lesezugriff auf die Logs (/var/log/nginx, /var/log/php-fpm, /var/log/mysql)
• MySQL-Zugangsdaten mit Lesezugriff zur Analyse der Slow Queries

Optional (aber empfohlen):

• Zugang zum Panel (Plesk, ISPConfig), falls vorhanden
• CMS-Zugangsdaten (WordPress-Admin), um unter realen Bedingungen zu testen
• Zugang zu Google Search Console / Analytics, um die Ergebnisse mit Geschäftskennzahlen abzugleichen

Sicherheit: Alle bereitgestellten Zugänge werden nach dem Audit sofort gelöscht (spätestens innerhalb von 48 Std.). Auf Wunsch kann eine Geheimhaltungsvereinbarung (NDA) unterzeichnet werden.

Wenn Sie nach ergänzenden Lösungen suchen, sehen Sie sich auch Folgendes an:

• Sicherheits-Audit für Websites: Fokus auf die Anwendung (XSS-/CSRF-/SQLi-Schwachstellen, veraltete Plugins, DSGVO-Konformität)
• Hilfe bei gehackten Websites: Notfalleinsatz nach einem Hack (Entfernen von Backdoors, Wiederherstellung)
• Core-Web-Vitals-Optimierung: Verbesserung von LCP/FID/CLS im Frontend
• Optimierung der Website-Geschwindigkeit: ganzheitliche Optimierung (Frontend + Backend)
• Fehlerbehebung und Optimierung von Websites: Überblick über meine Leistungen zur Fehlerbehebung
• Performance und Geschwindigkeit: Ressourcen und Leitfäden zur Web-Optimierung
• Sicherheit und Compliance: Ressourcen-Center zur Sicherheit (DSGVO, SSL, Backups)

Bereit, Performance und Sicherheit Ihres Servers zu steigern? Fordern Sie Ihr kostenloses Audit an