Ein Wiki privater Natur

ISPConfig Tips

Mehrere php Versionen für einen Kunden bereit stellen

https://www.howtoforge.com/ispconfig-php-debian/

https://www.howtoforge.com/ispconfig-php-ubuntu/

https://www.howtoforge.com/ispconfig-php-debian/#-install-php--10

Individuelle php Versionen.

Auf der Webseite immer zwischen fastcgi und fpm umschalten, wenn man die php Version geändert hat

Guter einfacher Test:

<?php
 phpinfo();  // allg. Informationen zur PHP-Installation
?>

FastCGI und PHP-FPM sind beides Mechanismen, um die Ausführung von PHP-Skripten auf einem Webserver zu verwalten. Hier ist der Unterschied:
FastCGI: FastCGI (Fast Common Gateway Interface) ist ein Protokoll, das es ermöglicht, PHP-Skripte außerhalb des Webserver-Prozesses auszuführen. Es ermöglicht eine getrennte Verwaltung der PHP-Prozesse und bietet dadurch bessere Skalierbarkeit und Performance. FastCGI wird oft in Kombination mit Webservern wie Apache oder Nginx verwendet.
PHP-FPM: PHP-FPM (PHP FastCGI Process Manager) ist eine spezifische Implementierung von FastCGI für PHP. Es ist ein Prozessmanager, der die Verwaltung und Steuerung der PHP-Prozesse übernimmt. PHP-FPM bietet zusätzliche Funktionen wie Pooling, um die Anzahl der PHP-Prozesse zu steuern, und ermöglicht die Konfiguration von Ressourcenlimits für einzelne Prozesse. PHP-FPM ist standardmäßig in PHP 5.3 und höher enthalten.
In Bezug auf PHP 8.3: PHP 8.3 unterstützt sowohl FastCGI als auch PHP-FPM. Du kannst wählen, welchen Mechanismus du verwenden möchtest, abhängig von deinen spezifischen Anforderungen und der Konfiguration deines Servers.

Soweit die KI.

Was bringt es nun?

FastCGI FPM/FastCGI FPM
"transactions": 16000, "transactions": 16000, 〰
"availability": 100.00, "availability": 100.00, 〰
"elapsed_time": 249.07, "elapsed_time": 195.81, ✅
"data_transferred": 80.72, "data_transferred": 80.72, 〰
"response_time": 0.14, "response_time": 0.11, ✅
"transaction_rate": 64.24, "transaction_rate": 81.71, ✅
"throughput": 0.32, "throughput": 0.41, ✅
"concurrency": 8.81, "concurrency": 9.35, ✅
"successful_transactions": 16000, "successful_transactions": 16000, 〰
"failed_transactions": 0, "failed_transactions": 0, 〰
"longest_transaction": 11.10, "longest_transaction": 10.24, ✅
"shortest_transaction": 0.07 "shortest_transaction": 0.07 〰

〰 entspricht Gleich
✅ entspricht Besser

Der Sieger sollte klar sein.
Prüfmethode war siege -c 10 -r 100 https://zockertown.de/s9y

Lets encrypt

tips

ISPConfig Let's Encrypt: SSL-Haken verschwindet nach dem Speichern
Symptom
Nach dem Anlegen einer neuen Website oder beim Nachholen von SSL wird das Zertifikat erstellt, aber im ISPConfig-Interface erscheint der Let's Encrypt-Schalter automatisch wieder als deaktiviert. Die Seite hat ein gültiges Cert (curl funktioniert), aber die Automatisierung zum Renewal ist gestört.

Screenshot des Problems:
bildschirmfoto_vom_2026-10-20_18-32-33.png
SSL: ✓
Let's Encrypt:

Ursache

ISPConfig setzt den LE-Haken zurück, wenn:

Der SSL-vHost nicht vollständig generiert war (Cron-Job lief noch nicht durch)
Die HTTP-01-Challenge blockiert war (Firewall/Rewrite-Regeln)
Die Website mit konkreter IP statt * angelegt wurde (SNI-Probleme bei Subdomains)
Das Cert existiert, die Datei ist da – aber der CronJob, der das Renewal auslöst, wird für diese Domain nicht mehr angestoßen.

Lösung (Zweistufen-Verfahren)

Nicht beide Haken gleichzeitig setzen!

Schritt Aktion Warten
1 Nur "SSL" anhaken → speichern 1 Minute (Cron)
2 Prüfen: grep SSLCertificateFile /etc/apache2/sites-available/XXX.vhost
3 "Let's Encrypt" nachziehen → speichern 1 Minute (Cron)
4 Prüfen: curl -s https://domain/healthcheck
Wichtig: Wenn nach Schritt 3 der Haken wieder weg ist → einfach nochmal speichern (dritter Durchgang). Die zweite Speicherung wird oft stabil.

Diagnose-Befehle

Zertifikat existiert?

ls -la /var/www/clients/client*/web*/ssl/ | grep domain

Apache zeigt das richtige Cert?

openssl s_client -connect [domain]:443 -servername [domain] </dev/null 2>/dev/null | \ openssl x509 -noout -subject

Cron-Job wurde ausgeführt?

tail -20 /var/log/ispconfig/cron.log | grep -i letsencrypt

Warnhinweis
Falls nach Schritt 1 das Cert bereits in der ssl/-Verzeichnis liegt (vom vorherigen Versuch): ISPConfig nutzt diese Datei bei Schritt 2 weiter, wenn der LE-Job startet. Es entsteht kein neues Cert, die alte Generation bleibt bestehen. Erst nach Ablauf (90 Tage bei Let's Encrypt) wird ein Renewal versucht.

Prävention
IP-Feld bei Subdomains immer auf * lassen
Firewall lässt Port 80 durch (HTTP-01-Challenge)
.htaccess erlaubt /.well-known/acme-challenge/
Nach Änderung der Subdomain-Struktur alle betroffenen Websites nach dem Verfahren durchgehen