Kurzanleitungen

Schnellweg: Problem erkennen → Einstellung ändern → Ergebnis kontrollieren. Für Details führt jeder Block zur vollständigen Anleitung.

Apache

Problem: Das normale Access-Log enthält die Besucher-IP.

Einstellung: Access-Log deaktivieren oder ein eigenes LogFormat ohne %h/%a verwenden.

LogFormat "%t "%r" %>s %b" wsn_noip
CustomLog /var/log/apache2/example-access.log wsn_noip

Kontrolle: Eigene Testanfrage erzeugen und Access- sowie Error-Log getrennt prüfen. Vollständige Anleitung

nginx

Problem: $remote_addr oder Forwarded-IP-Header landen im Access-Log.

Einstellung: access_log off; oder ein Logformat ohne Clientadresse und IP-Header einsetzen.

Kontrolle: Testaufruf durchführen und neue Logzeilen prüfen. Vollständige Anleitung

Caddy

Problem: Aktiviertes Request-Logging kann Clientadressen enthalten.

Einstellung: Request-Logging nur bei Bedarf aktivieren; andernfalls IP-Felder entfernen oder ausreichend maskieren.

Kontrolle: remote_ip und bei Trusted Proxies zusätzlich client_ip prüfen. Vollständige Anleitung

Traefik / HAProxy

Problem: Der Reverse Proxy sieht die Besucher-IP und kann sie protokollieren oder an den Origin weiterreichen.

Einstellung: Client-IP-Felder aus Access-Logs entfernen und Forwarded-IP-Header nur weiterreichen, wenn der Origin sie wirklich benötigt.

Kontrolle: Proxy-Log und Origin-Log mit demselben Testaufruf vergleichen. Traefik · HAProxy

Cloudflare / CDN

Problem: Der Proxy verarbeitet die IP und kann sie über Header bis zum Origin durchreichen.

Einstellung: Besucher-IP-Header entfernen, wenn die Anwendung sie nicht benötigt.

Kontrolle: Origin auf CF-Connecting-IP, X-Forwarded-For und ähnliche Header prüfen. Vollständige Anleitung

WordPress

Problem: Plugins für Statistik, Sicherheit, Formulare oder Kommentare können eigene Kennungen und Logs anlegen.

Einstellung: Nicht benötigte Plugins/Funktionen deaktivieren und IP-, Session- sowie externe Tracking-Funktionen einzeln minimieren.

Kontrolle: Testaktion auslösen und Datenbank, Plugin-Logs, Browser-Speicher und Netzwerkrequests prüfen. WordPress-Selbsttest

Statistik

Problem: „Cookielos“ kann trotzdem tägliche Hashes, Sessions oder andere Besucherkennungen bedeuten.

Einstellung: Nur benötigte Metriken aktivieren; dauerhafte IDs, Profile und unnötige Unique-Visitor-Funktionen vermeiden.

Kontrolle: Browser-Speicher, Analytics-Requests und serverseitige Daten gemeinsam prüfen. Grundlagen

Formulare / CAPTCHA

Problem: Formular-, Spam- und CAPTCHA-Dienste können IP, Browserdaten oder Drittanbieter-Requests erzeugen.

Einstellung: Erst lokale Verfahren wie Honeypot, Zeitprüfung und serverseitige Validierung verwenden; externe Challenges nur bei tatsächlichem Bedarf.

Kontrolle: Formular mit frischer Browsersitzung testen und Netzwerk, Datenbank, Mail- und Serverlogs prüfen. Vollständige Anleitung

Shared Hosting

Problem: Webserverlogs liegen teilweise außerhalb der eigenen Anwendungskontrolle.

Einstellung: Im Kundenmenü Logfiles, Besucherstatistik, WebAnalytics und IP-Anonymisierung prüfen und unnötige Funktionen abschalten.

Kontrolle: Anbieterlogs nach einem eigenen Testaufruf prüfen und Provider-Sicherheitslogs getrennt dokumentieren. Hostingvergleich

Abschlusskontrolle

Problem: Eine einzelne saubere Ebene beweist noch keine datensparsame Gesamtkette.

Einstellung: Browser → Drittanbieter → Proxy/CDN → Webserver → Anwendung → Datenbank → Security/Hoster nacheinander prüfen.

Kontrolle: Mit frischer Browsersitzung erneut testen und nur die eigene Test-IP beziehungsweise eigene Testdaten verfolgen. Selbsttest öffnen