Der Apache HTTP Server ist der Urvater aller modernen Webserver - und auch 2026 noch eine relevante Wahl. Seine Geschichte beginnt 1995, als eine Gruppe von Entwicklern den verwaisten NCSA HTTPd forkte und mit Patches versah. Der Name "Apache" entstand angeblich als Wortspiel: "A Patchy Server" - ein Server aus Patches zusammengeflickt. Ob das stimmt oder der Name die Native Americans ehren sollte, bleibt umstritten. Sicher ist: Apache wurde zum dominierenden Webserver des frühen Internets.

Heute, über 30 Jahre später, hat Apache seinen Thron an Nginx abgegeben. Mit einem Marktanteil von 24-35% (je nach Messmethode) ist Apache zwar rückläufig, aber immer noch die Nummer zwei. Besonders traditionelle Webhoster, Shared-Hosting-Umgebungen und Legacy-Systeme setzen weiterhin auf Apache. Der Grund: Kein anderer Webserver bietet die Flexibilität von .htaccess-Dateien, die es Kunden erlauben, ihre eigene Konfiguration zu verwalten - ohne Root-Zugang zum Server.

Wer nutzt Apache 2026? Vor allem Unternehmen mit gewachsener Infrastruktur, WordPress-Hoster mit Shared-Hosting-Modellen und Entwickler, die komplexe Rewrite-Regeln ohne Server-Neustart testen wollen. Wenn du verstehen willst, wann Apache noch die richtige Wahl ist, bist du hier richtig.

Technische Architektur: Wie Apache arbeitet

Um Apache zu verstehen, musst du die Multi-Processing Modules (MPMs) kennen. Sie bestimmen, wie Apache eingehende Anfragen verarbeitet.

Multi-Processing Modules (MPM)

Apache bietet drei MPMs zur Auswahl:

prefork MPM: Das klassische Modell. Für jede Verbindung wird ein eigener Prozess erstellt. Stabil und kompatibel mit nicht-threadsicheren Modulen wie mod_php, aber speicherhungrig. Bei 100 gleichzeitigen Verbindungen laufen 100 Apache-Prozesse.

worker MPM: Ein Hybrid-Modell. Mehrere Threads innerhalb weniger Prozesse bearbeiten Anfragen. Effizienter als prefork, aber nicht kompatibel mit mod_php. Gut für Setups mit PHP-FPM.

event MPM: Die modernste Variante. Basiert auf worker, nutzt aber einen dedizierten Thread für Keep-Alive-Verbindungen. Das verhindert, dass inaktive Verbindungen Worker-Threads blockieren. Für moderne Setups empfohlen.

# Aktives MPM prüfen (Debian/Ubuntu)
apachectl -V | grep MPM

# MPM wechseln
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
sudo systemctl restart apache2

Protokoll-Support

Apache unterstützt alle gängigen Protokolle:

HTTP/1.1: Der Standard, vollständig unterstützt
HTTP/2: Seit Apache 2.4.17 über mod_http2 verfügbar
HTTP/3: Experimenteller Support über externe Module, nicht produktionsreif
WebSocket: Über mod_proxy_wstunnel

Das Alleinstellungsmerkmal: .htaccess

Was Apache von allen anderen Webservern unterscheidet, ist die dezentrale Konfiguration über .htaccess-Dateien. Diese Dateien liegen im Document Root und werden bei jedem Request gelesen. Das erlaubt:

Rewrite-Regeln ohne Server-Neustart
Konfiguration ohne Root-Zugang
Verzeichnis-spezifische Einstellungen
Passwortschutz auf Verzeichnisebene

Der Preis: Performance. Apache muss bei jedem Request alle .htaccess-Dateien im Pfad lesen und parsen. Für High-Traffic-Seiten kann das zum Problem werden.

Die wichtigsten Module

Apache ist modular aufgebaut. Die wichtigsten Module:

mod_rewrite: URL-Umschreibung, das mächtigste und komplexeste Modul
mod_ssl: HTTPS-Unterstützung
mod_php: PHP direkt im Apache-Prozess (legacy, aber einfach)
mod_proxy: Reverse-Proxy-Funktionalität
mod_security: Web Application Firewall
mod_headers: HTTP-Header manipulieren

Apache installieren und konfigurieren

Die Installation von Apache ist auf allen Linux-Distributionen unkompliziert. Hier die Anleitungen für die gängigsten Systeme.

Debian / Ubuntu

Auf Debian-basierten Systemen heißt das Paket apache2:

sudo apt update
sudo apt install apache2
sudo systemctl enable apache2
sudo systemctl start apache2

Nach der Installation läuft Apache automatisch und ist unter http://localhost erreichbar. Du siehst die Standard-Willkommensseite.

CentOS / RHEL / Fedora

Auf Red Hat-basierten Systemen heißt das Paket httpd:

sudo dnf install httpd
sudo systemctl enable httpd
sudo systemctl start httpd

Falls du eine ältere CentOS-Version mit yum verwendest, ersetze dnf durch yum.

Wichtige Verzeichnisse und Dateien

Nach der Installation findest du die wichtigsten Dateien hier:

Pfad (Debian/Ubuntu)	Pfad (RHEL/CentOS)	Beschreibung
`/etc/apache2/apache2.conf`	`/etc/httpd/conf/httpd.conf`	Haupt-Konfigurationsdatei
`/etc/apache2/sites-available/`	`/etc/httpd/conf.d/`	VirtualHost-Konfigurationen
`/etc/apache2/sites-enabled/`	-	Aktivierte Sites (Symlinks)
`/etc/apache2/mods-available/`	-	Verfügbare Module
`/var/log/apache2/`	`/var/log/httpd/`	Access- und Error-Logs
`/var/www/html/`	`/var/www/html/`	Standard Document Root

VirtualHost-Konfiguration

Ein VirtualHost definiert, wie Apache Anfragen für eine Domain bearbeitet. Hier ein vollständiges Beispiel:

# /etc/apache2/sites-available/meine-website.conf
<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    ServerAdmin webmaster@example.com

    DocumentRoot /var/www/meine-website

    <Directory /var/www/meine-website>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    # Logging
    ErrorLog ${APACHE_LOG_DIR}/meine-website-error.log
    CustomLog ${APACHE_LOG_DIR}/meine-website-access.log combined
</VirtualHost>

Was bedeuten die Direktiven?

ServerName: Die Hauptdomain für diesen VirtualHost
ServerAlias: Zusätzliche Domains (z.B. www-Variante)
DocumentRoot: Wo liegen die Dateien
Options -Indexes: Keine Verzeichnislistings anzeigen
AllowOverride All: .htaccess-Dateien vollständig erlauben
Require all granted: Zugriff für alle erlauben

Um die Site zu aktivieren (Debian/Ubuntu):

sudo a2ensite meine-website.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Das richtige MPM wählen

Die MPM-Wahl hängt von deinem Setup ab:

Verwende prefork wenn:

Du mod_php nutzt (legacy PHP-Integration)
Du maximale Kompatibilität brauchst
Speicher keine knappe Ressource ist

Verwende event wenn:

Du PHP-FPM nutzt (empfohlen)
Du viele gleichzeitige Verbindungen erwartest
Du moderne Performance brauchst

# Event MPM mit PHP-FPM einrichten (Debian/Ubuntu)
sudo a2dismod mpm_prefork php8.3
sudo a2enmod mpm_event proxy_fcgi setenvif
sudo a2enconf php8.3-fpm
sudo systemctl restart apache2

Performance: Benchmarks und Realität

Apache hat einen Ruf als langsamer Webserver. Das ist nur teilweise gerechtfertigt - es kommt stark auf die Konfiguration an.

Vergleich zu Nginx

Bei reinen Benchmarks mit statischen Dateien ist Apache typischerweise 30-50% langsamer als Nginx. Die Gründe:

Nginx nutzt ein Event-basiertes Modell von Grund auf
Apache parst bei jedem Request .htaccess-Dateien (wenn aktiviert)
Apache-Prozesse verbrauchen mehr Speicher

Metrik	Apache (event MPM)	Nginx
Statische Files (RPS)	8.000-15.000	15.000-25.000
Speicher pro Verbindung	~10-20 MB	~2-3 MB
HTTP/3 Support	Experimentell	Stabil
.htaccess Support	Ja	Nein

Wo Apache punktet

Apache ist nicht generell langsam. In bestimmten Szenarien ist er durchaus konkurrenzfähig:

Dynamische Inhalte mit mod_php: Wenn PHP ohnehin der Bottleneck ist, macht der Webserver kaum einen Unterschied. mod_php startet PHP-Prozesse schneller als der Umweg über PHP-FPM.

Komplexe Rewrite-Regeln: mod_rewrite ist mächtiger und flexibler als Nginx-Rewrites. Manche Patterns sind in Apache einfacher umzusetzen.

Geringe Besucherzahlen: Unter 10.000 Besuchern pro Tag merkst du keinen Unterschied zwischen Apache und Nginx.

Performance-Tuning

Wenn du Apache schneller machen willst, hier die wichtigsten Stellschrauben:

1. AllowOverride deaktivieren

Wenn du keine .htaccess-Dateien brauchst, schalte sie ab:

<Directory /var/www>
    AllowOverride None
</Directory>

Das spart das Parsen von .htaccess-Dateien bei jedem Request.

2. KeepAlive optimieren

# In apache2.conf oder httpd.conf
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

3. MPM-Parameter tunen

# Für event MPM
<IfModule mpm_event_module>
    StartServers             3
    MinSpareThreads         75
    MaxSpareThreads        250
    ThreadsPerChild         25
    MaxRequestWorkers      400
    MaxConnectionsPerChild   0
</IfModule>

4. PHP-FPM statt mod_php verwenden

Mit PHP-FPM kannst du das event MPM nutzen, das deutlich effizienter ist als prefork.

Typische Einsatzszenarien

Apache glänzt in bestimmten Szenarien. Hier die häufigsten mit Konfigurationsbeispielen.

Shared Hosting: Der Klassiker

Das Hauptargument für Apache ist Shared Hosting. Hunderte Kunden auf einem Server, jeder mit eigenen Anforderungen. .htaccess macht das möglich:

# Beispiel .htaccess eines Kunden
# HTTPS erzwingen
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# WordPress Permalinks
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# PHP-Einstellungen
php_value upload_max_filesize 64M
php_value post_max_size 64M

Der Kunde braucht keinen Root-Zugang und keine Admin-Hilfe. Er legt eine Datei ab, und die Konfiguration greift sofort.

WordPress mit mod_php

Das einfachste Setup für WordPress - und immer noch bei vielen Hostern Standard:

<VirtualHost *:80>
    ServerName wordpress.example.com
    DocumentRoot /var/www/wordpress

    <Directory /var/www/wordpress>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    # PHP-Handler (mod_php)
    <FilesMatch \.php$>
        SetHandler application/x-httpd-php
    </FilesMatch>
</VirtualHost>

mod_rewrite für SEO

mod_rewrite ist das mächtigste URL-Rewriting-Tool. Hier typische SEO-Regeln:

# .htaccess
RewriteEngine On

# HTTPS erzwingen
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# www zu non-www umleiten
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

# Trailing Slash entfernen
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.+)/$
RewriteRule ^ %1 [L,R=301]

# Kleinschreibung erzwingen
RewriteMap lowercase int:tolower
RewriteCond %{REQUEST_URI} [A-Z]
RewriteRule (.*) ${lowercase:$1} [R=301,L]

Apache als Reverse Proxy

Mit mod_proxy kann Apache Anfragen an Backend-Server weiterleiten:

<VirtualHost *:80>
    ServerName app.example.com

    ProxyPreserveHost On
    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/

    # WebSocket-Support
    RewriteEngine On
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteCond %{HTTP:Connection} upgrade [NC]
    RewriteRule ^/?(.*) "ws://localhost:3000/$1" [P,L]
</VirtualHost>

Für Load Balancing:

<Proxy "balancer://mycluster">
    BalancerMember "http://10.0.0.1:8080" loadfactor=1
    BalancerMember "http://10.0.0.2:8080" loadfactor=1
    ProxySet lbmethod=byrequests
</Proxy>

<VirtualHost *:80>
    ServerName app.example.com
    ProxyPass / balancer://mycluster/
    ProxyPassReverse / balancer://mycluster/
</VirtualHost>

Sicherheit: Apache richtig absichern

Apache bietet umfangreiche Sicherheitsfunktionen. Hier die wichtigsten Maßnahmen.

mod_security: Web Application Firewall

mod_security ist eine vollwertige WAF, die Angriffe wie SQL Injection und XSS blockt:

# Installation
sudo apt install libapache2-mod-security2
sudo a2enmod security2

# OWASP Core Rule Set aktivieren
sudo apt install modsecurity-crs
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

In /etc/modsecurity/modsecurity.conf:

SecRuleEngine On
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

SSL/TLS mit Let's Encrypt

Die Einrichtung von HTTPS ist mit Certbot ein Kinderspiel:

sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

Certbot modifiziert automatisch deine VirtualHost-Konfiguration und richtet einen Cronjob für die automatische Erneuerung ein.

Directory-Schutz mit .htaccess

Verzeichnisse mit Passwort schützen:

# .htaccess
AuthType Basic
AuthName "Geschützter Bereich"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Passwort-Datei erstellen:

sudo htpasswd -c /etc/apache2/.htpasswd benutzername

Security Headers

Schütze deine Besucher mit HTTP-Headern in .htaccess oder der VirtualHost-Konfiguration:

# Security Headers
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set X-XSS-Protection "1; mode=block"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"

# HSTS (nur mit HTTPS!)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Vor- und Nachteile von Apache

Vorteile

.htaccess: Dezentrale Konfiguration ohne Root-Zugang Das Killerfeature für Shared Hosting. Kunden können eigene Rewrite-Regeln, PHP-Einstellungen und Zugriffskontrollen definieren - ohne Hilfe des Administrators.

Riesige Modulbibliothek Für fast jeden Anwendungsfall gibt es ein Apache-Modul. Von mod_security über mod_pagespeed bis zu mod_brotli - die Auswahl ist enorm.

Hervorragende Dokumentation 30 Jahre Entwicklung bedeuten 30 Jahre Dokumentation. Für jedes Problem findest du eine Lösung - auf Apache.org, Stack Overflow oder in unzähligen Tutorials.

mod_php für einfaches PHP-Setup PHP direkt im Apache-Prozess ist zwar nicht mehr State of the Art, aber unschlagbar einfach einzurichten.

Breite Hosting-Unterstützung Praktisch jeder Webhoster unterstützt Apache. Viele Control Panels wie cPanel oder Plesk setzen Apache voraus.

Nachteile

Höherer Speicherverbrauch als Nginx Bei vielen gleichzeitigen Verbindungen verbraucht Apache deutlich mehr RAM. Das kostet Geld in Cloud-Umgebungen.

Langsamer bei statischen Inhalten Bei reinen Benchmarks ist Apache 30-50% langsamer als Nginx bei statischen Dateien.

.htaccess-Parsing kostet Performance Das Feature, das Apache einzigartig macht, ist auch sein Achillesferse. Bei jedem Request werden alle .htaccess-Dateien im Pfad gelesen.

HTTP/3 noch experimentell Während Nginx stabilen HTTP/3-Support bietet, ist Apache hier hinterher.

Marktanteil sinkt kontinuierlich Der Trend geht zu Nginx und Cloudflare. Apache wird langsam zum Legacy-System.

Fazit: Wann Apache die richtige Wahl ist

Apache ist 2026 nicht mehr die erste Wahl für neue Projekte - aber er ist auch nicht obsolet. In bestimmten Szenarien ist Apache nach wie vor die beste Option.

Wähle Apache wenn:

Du Shared Hosting betreibst und .htaccess brauchst
Du Legacy-Systeme verwaltest, die Apache voraussetzen
Dein Team Apache-Expertise hat und keine Zeit zum Umlernen
Du komplexe Rewrite-Regeln mit mod_rewrite brauchst
Du ein einfaches PHP-Setup mit mod_php willst

Wähle einen anderen Webserver wenn:

Du hohen Traffic mit statischen Inhalten erwartest
Du ein neues Projekt startest ohne .htaccess-Anforderung
Ressourceneffizienz wichtig ist (Cloud, Container)
Du HTTP/3 in Produktion nutzen willst

Apache ist wie ein zuverlässiger Oldtimer: Nicht mehr das schnellste Fahrzeug auf der Straße, aber bewährt, gut dokumentiert und für bestimmte Strecken immer noch die richtige Wahl.

Zurück zum Webserver-Vergleich 2026

Weiterführende Ressourcen

Hier findest du weitere Informationen zu Apache und verwandten Themen:

Apache HTTP Server Dokumentation - Die offizielle Referenz
Nginx als Alternative - Der Marktführer im Detail
LiteSpeed: Der schnellere Apache - Apache-kompatibel, aber performanter

Letzte Aktualisierung: März 2026

Apache HTTP Server 2026: Der Klassiker im modernen Einsatz