KeyHelp: Zusätzliche Apache-Anweisungen je Domain für Header, Rewrite und Caching nutzen

Manche Einstellungen gehören nicht in die .htaccess einer Website, sondern direkt in die Webserver-Konfiguration: Sicherheits-Header, die immer gesendet werden sollen, Umleitungen alter Adressen oder Cache-Regeln für statische Dateien. KeyHelp bietet dafür je Domain das Feld „Zusätzliche Apache-Anweisungen“ und für den ganzen Server die „Globalen Webserver-Direktiven“. Diese Anleitung zeigt, wo Sie beides finden, in welcher Datei die Anweisungen landen, warum es ein HTTP- und ein HTTPS-Feld gibt und was passiert, wenn sich ein Tippfehler einschleicht. Sie richtet sich an Administratoren eines Servers, der wie in KeyHelp installieren und absichern eingerichtet ist. Getestet haben wir mit KeyHelp 26.1.1 auf Debian 12.

Voraussetzungen

• Admin-Zugang zu KeyHelp. Getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12 mit Apache 2.4. Im Kundenbereich fehlt der Reiter „Apache-Einstellungen“, eine Berechtigung dafür gibt es in der Kundenverwaltung nicht.
• Eine angelegte Domain. Wie Sie Domains und Subdomains anlegen, steht in KeyHelp: Domains und Subdomains anlegen.
• SSH-Zugang als root, um die erzeugten Dateien zu prüfen und im Notfall einen Syntaxfehler zu beheben. Ohne Shell können Sie einen kaputten Webserver nicht mehr über das Panel reparieren, dazu mehr in Schritt 5.
• Grundkenntnisse der Apache-Syntax. Die Module headers, rewrite, expires und deflate waren im Test ab Werk geladen (apache2ctl -M).

Schritt 1: Den Reiter „Apache-Einstellungen“ öffnen

Öffnen Sie im Admin-Bereich „Domains“ und klicken Sie beim gewünschten Eintrag auf das Stiftsymbol. Die Seite „Domain bearbeiten“ hat die Reiter „Allgemein“, „Sicherheit“, „E-Mail“, „Interpreter“, „Apache-Einstellungen“ und „Erweiterte Einstellungen“. Im Reiter „Apache-Einstellungen“ steht der Abschnitt „Zusätzliche Apache-Anweisungen“ mit zwei Editorfeldern: „Anweisungen für HTTP“ und „Anweisungen für HTTPS“. Der Hinweistext lautet: „Die hier eingegebenen Anweisungen werden den Virtual-Host-Containern der Domain hinzugefügt.“ Darunter folgt in Rot: „Vergewissern Sie sich, dass die Direktiven die richtige Syntax haben. Eine falsche Syntax verhindert, dass der Webserver neu gestartet werden kann.“ Diese Warnung ist ernst gemeint, Schritt 5 zeigt, warum.

Wichtig: Domain und www-Subdomain sind in KeyHelp getrennte Einträge mit eigenen Feldern. Anweisungen für kunde1.example.de gelten nicht automatisch für www.kunde1.example.de. Im Test lieferte die www-Adresse die neuen Header nicht, während die Hauptdomain sie bereits sendete. Tragen Sie die Anweisungen deshalb auch bei der www-Subdomain ein. Leitet die www-Subdomain ohnehin per 301 auf die Hauptdomain um, wie in KeyHelp: Weiterleitungen und www einrichten beschrieben, ist das unkritisch.

Verifizieren: Der Reiter „Apache-Einstellungen“ ist sichtbar und zeigt zwei leere Editorfelder. Melden Sie sich zum Vergleich als Kunde an: Dort fehlt der Reiter.

Schritt 2: Header, Rewrite und Caching eintragen

Für den Test haben wir in „Anweisungen für HTTP“ drei typische Aufgaben kombiniert: Sicherheits-Header, eine Umleitung von /alt/ nach /neu/ und Browser-Caching für CSS und PNG.

# Sicherheits-Header
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

# Alte Adresse umleiten
RewriteEngine On
RewriteRule ^/alt/(.*)$ /neu/$1 [R=301,L]

# Browser-Caching für statische Dateien
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 7 days"
  ExpiresByType image/png "access plus 30 days"
</IfModule>

Zwei Unterschiede zur .htaccess sollten Sie kennen. Erstens beginnt das Muster einer RewriteRule im VirtualHost mit einem Schrägstrich (^/alt/), in einer .htaccess dagegen ohne. Wer Regeln aus einer .htaccess kopiert, muss sie anpassen. Zweitens setzt Header always den Header auch bei Fehlerseiten und Umleitungen, nicht nur bei erfolgreichen Antworten. Im Test trug sogar die Antwort 403 Forbidden alle drei Header.

Klicken Sie auf „Speichern“. KeyHelp meldet „Die Domain kunde1.example.de wurde aktualisiert.“ und schreibt die Konfiguration beim nächsten Wartungslauf, im Test nach etwa einer Minute.

Verifizieren: Auf dem Server prüfen Sie die Wirkung mit curl:

curl -sI -H "Host: kunde1.example.de" http://127.0.0.1/alt/seite.html
curl -sI -H "Host: kunde1.example.de" http://127.0.0.1/s.css

Der erste Aufruf lieferte HTTP/1.1 301 Moved Permanently mit Location: http://kunde1.example.de/neu/seite.html und den drei Headern, der zweite Cache-Control: max-age=604800 und ein Expires-Datum sieben Tage in der Zukunft.

Schritt 3: Verstehen, wo KeyHelp die Anweisungen ablegt

KeyHelp legt für jede Domain mit Inhalt im Feld eine eigene Datei an, benannt nach Benutzer, Domain und Protokoll:

ls /etc/apache2/keyhelp/custom_vhosts/
kunde1_kunde1.example.de_http.conf

In der Kundendatei /etc/apache2/keyhelp/vhosts/kunde1.conf steht am Ende des VirtualHost von kunde1.example.de der passende Verweis, direkt nach den globalen Direktiven:

  # Include global directives
  IncludeOptional /etc/apache2/keyhelp/global_directives.conf

  # Include custom HTTP directives
  Include /etc/apache2/keyhelp/custom_vhosts/kunde1_kunde1.example.de_http.conf
</VirtualHost>

Daraus folgen drei praktische Regeln. Die Anweisungen stehen im VirtualHost-Kontext, also gelten <Directory>-, <Location>- und <FilesMatch>-Blöcke. Ändern Sie diese Dateien nie direkt, denn der Kopf der Kundendatei warnt „DO NOT CHANGE ANYTHING IN THIS FILE!“, und KeyHelp überschreibt sie beim nächsten Speichern. Und weil die Datei per Include statt IncludeOptional eingebunden wird, darf sie nicht einfach gelöscht werden, sonst startet Apache nicht.

Verifizieren: grep -n custom /etc/apache2/keyhelp/vhosts/kunde1.conf zeigt die Include-Zeile, cat auf die Datei in custom_vhosts zeigt Ihren Text unverändert.

Schritt 4: HTTP oder HTTPS, das richtige Feld wählen

Die beiden Felder gehören zu zwei verschiedenen VirtualHosts, und welcher davon die Website ausliefert, hängt vom Reiter „Sicherheit“ ab. Im Test haben wir beide Zustände geprüft:

• Ohne Zertifikat („Kein Zertifikat“) liefert der VirtualHost auf Port 80 die Website aus und bindet das HTTP-Feld ein. Der VirtualHost auf Port 443 besteht nur aus Redirect 302 / http://kunde1.example.de/. Ein Eintrag im HTTPS-Feld wird gespeichert, aber nicht in eine Datei geschrieben.
• Mit Zertifikat und „Sichere Verbindung erzwingen“ dreht sich das um. Nachdem wir das Zertifikat „default“ zugewiesen hatten, entstand kunde1_kunde1.example.de_https.conf, eingebunden im VirtualHost auf Port 443. Der VirtualHost auf Port 80 enthielt nur noch Redirect 301 / https://kunde1.example.de/, das HTTP-Feld war dort nicht mehr eingebunden. Unsere Header aus Schritt 2 kamen per HTTPS also nicht mehr an, nur der Testheader aus dem HTTPS-Feld.

Für die Praxis heißt das: Bei einer Website mit Zertifikat gehören Header, Rewrite und Caching ins Feld „Anweisungen für HTTPS“. Das HTTP-Feld brauchen Sie dann nur noch für Sonderfälle, etwa eine Ausnahme von der HTTPS-Umleitung. Wer unsicher ist, trägt dieselben Anweisungen in beide Felder ein.

Verifizieren: curl -skI --resolve kunde1.example.de:443:127.0.0.1 https://kunde1.example.de/ zeigt die Header aus dem HTTPS-Feld. ls /etc/apache2/keyhelp/custom_vhosts/ listet nach der Zertifikatszuweisung die Datei mit Endung _https.conf.

Schritt 5: Syntaxfehler erkennen und beheben

Wir haben bewusst einen Fehler eingebaut und ans HTTP-Feld die Zeile Header always sett X-Test "1" angehängt. KeyHelp hat das Formular ohne Einwand gespeichert und wieder „Die Domain kunde1.example.de wurde aktualisiert.“ gemeldet. Eine Minute später stand im Admin-Bereich unter „Ereignis-Protokolle“ ein Eintrag der Stufe „Kritisch“:

Apache reported syntax errors.
AH00526: Syntax error on line 16 of /etc/apache2/keyhelp/custom_vhosts/kunde1_kunde1.example.de_http.conf:
first argument must be 'add', 'set', 'setifempty', 'append', 'merge', 'unset', 'echo', 'note', 'edit', or 'edit*'.
Action 'configtest' failed.

KeyHelp lädt Apache in diesem Fall nicht neu. Der laufende Webserver arbeitet mit der alten Konfiguration weiter, alle Websites und das Panel bleiben erreichbar. Das wirkt harmlos, ist aber eine Falle: Ab jetzt wird keine Änderung an irgendeiner Domain mehr wirksam, und beim nächsten Neustart, etwa nach einem Kernel-Update, startet Apache gar nicht. Im Test endete systemctl restart apache2 mit „Job for apache2.service failed“, danach waren alle Websites und das Panel weg.

Die Reparatur in dieser Reihenfolge:

1. Per SSH die fehlerhafte Zeile in der Datei unter /etc/apache2/keyhelp/custom_vhosts/ entfernen, die Zeilennummer steht in der Meldung.
2. apache2ctl configtest ausführen, bis „Syntax OK“ erscheint.
3. Apache mit systemctl start apache2 starten (bzw. systemctl reload apache2, falls er noch läuft).
4. Im Panel denselben Fehler im Feld korrigieren und speichern. Sonst schreibt KeyHelp die kaputte Zeile beim nächsten Wartungslauf wieder hinein.

Verifizieren: apache2ctl configtest meldet „Syntax OK“, systemctl is-active apache2 meldet „active“, und im Ereignisprotokoll kommt kein neuer kritischer Eintrag hinzu. Machen Sie es sich zur Gewohnheit, nach jeder Änderung in diesen Feldern einmal apache2ctl configtest laufen zu lassen.

Schritt 6: Globale Direktiven für alle Domains

Soll ein Header für jede Website des Servers gelten, müssen Sie ihn nicht in jede Domain eintragen. Unter „Konfiguration“, „Webserver“ gibt es das Feld „Globale Webserver-Direktiven“ mit dem Text: „Hier können Sie globale Webserver-Direktiven hinzufügen, die in den Virtual-Host-Container jeder Domain eingebunden werden.“

KeyHelp schreibt den Inhalt nach /etc/apache2/keyhelp/global_directives.conf. Diese Datei steht in jedem VirtualHost vor den domainspezifischen Anweisungen. Im Test kam ein globaler Testheader bei der Systemdomain kunde1.server.example.de, bei der www-Subdomain und per HTTPS bei kunde1.example.de an. Ein Fehler hier trifft allerdings alle Websites gleichzeitig, testen Sie neue globale Regeln daher zuerst in einer einzelnen Domain.

Verifizieren: cat /etc/apache2/keyhelp/global_directives.conf zeigt den Inhalt, ein curl -sI auf eine beliebige Domain des Servers liefert den Header.

Typische Fehler

• „Apache reported syntax errors.“ im Ereignisprotokoll: Tippfehler im Feld. Vorgehen wie in Schritt 5, nicht erst beim nächsten Neustart darauf stoßen.
• Header kommen per HTTPS nicht an: Sie stehen im HTTP-Feld, die Domain hat aber ein Zertifikat mit „Sichere Verbindung erzwingen“. Anweisungen ins HTTPS-Feld übernehmen.
• Rewrite-Regel greift nicht: Muster aus einer .htaccess ohne führenden Schrägstrich übernommen. Im VirtualHost lautet es ^/alt/.
• Header doppelt in der Antwort: Die .htaccess des Kunden setzt denselben Header mit Header set. Im Test kamen dann X-Frame-Options: SAMEORIGIN und X-Frame-Options: DENY gleichzeitig an, Browser werten das unterschiedlich aus.
• www-Variante ohne Header: Die www-Subdomain hat eigene Felder, siehe Schritt 1.
• Änderung wirkt nicht sofort: KeyHelp schreibt die Dateien im Wartungslauf. Eine Minute warten, dann prüfen.

Häufige Fragen

Kann ein Kunde die Anweisungen per .htaccess aushebeln?

Teilweise. Die Rewrite-Regel aus dem VirtualHost hatte im Test Vorrang, eine abweichende Regel in der .htaccess für denselben Pfad kam nicht zum Zug. Bei Headern ist es anders: Header unset X-Frame-Options in der .htaccess blieb wirkungslos, Header always unset X-Frame-Options entfernte den Header dagegen vollständig, und Header always set überschrieb ihn. Serverseitige Header sind also ein guter Standard, aber keine Sperre gegen einen Kunden, der seine .htaccess gezielt ändert.

Können Kunden die Felder selbst bearbeiten?

Nein. Im Kundenbereich zeigt „Domain bearbeiten“ nur „Allgemein“, „Sicherheit“, „E-Mail“ und „Interpreter“. Kunden bleiben auf die .htaccess beschränkt.

Wird die Syntax beim Speichern geprüft?

Nein. Die Prüfung läuft erst im Wartungslauf mit configtest. Das Ergebnis sehen Sie nur im Ereignisprotokoll.

Bleiben die Anweisungen bei einer Änderung der Domain erhalten?

Ja. Im Test standen die Anweisungen nach Zertifikatswechsel und erneutem Speichern unverändert im Formular, und die Datei unter custom_vhosts wurde nach jedem Neuschreiben der Konfiguration wieder eingebunden.

Testumfang

Wir haben auf KeyHelp 26.1.1 Header, eine Rewrite-Regel und Expires-Regeln je Domain sowie globale Direktiven eingetragen und mit curl, in den erzeugten Dateien und im Ereignisprotokoll geprüft, mit und ohne Zertifikat. Auffällig: Ein Syntaxfehler wird ohne Warnung gespeichert und legt Apache beim nächsten Neustart lahm. Nginx-Setups und Let's-Encrypt-Zertifikate haben wir nicht geprüft. Testen Sie jede Änderung mit apache2ctl configtest.

Fazit

Die „Zusätzlichen Apache-Anweisungen“ sind der saubere Ort für Regeln, die unabhängig von der .htaccess gelten sollen. Entscheidend sind drei Punkte: bei Domains mit Zertifikat das HTTPS-Feld nutzen, die www-Subdomain mitpflegen und nach jeder Änderung die Syntax prüfen, weil KeyHelp das nicht beim Speichern tut. Für Regeln, die überall gelten sollen, sind die globalen Webserver-Direktiven die bessere Wahl, mit entsprechend größerer Sorgfalt.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern: das kostenlose Hosting-Panel für eigene Server
• KeyHelp: Domains und Subdomains anlegen und Domain-Ziel sowie Verzeichnis richtig wählen
• KeyHelp: Weiterleitungen mit 301 und 302 und www einrichten
• KeyHelp: SSL-Zertifikate mit Let's Encrypt und eigener CA einrichten und überwachen
• KeyHelp Knowledge Base: Domain bearbeiten
• Keyweb: KeyHelp, alle Funktionen im Überblick