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:

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