WordPress belauschen — mit wem und über was redet mein Server eigentlich so?

Eine frische WordPress-Installation. Kein Tracking-Plugin, kein Page-Builder, kein Jetpack. Nur Core, das Standard-Theme, ein einziger Beitrag. Schon in der ersten halben Stunde nach dem Aufruf der Startseite gehen Anfragen an drei bis fünf verschiedene Hosts hinaus. Manche erwartbar, andere weniger.

Es lohnt sich, einmal hinzuhören. Ein WordPress-Server ist kommunikativer, als die meisten Betreiber denken. Er redet mit Update-Servern, Plugin-Lizenz-Endpunkten, Spam-Filter-APIs und Backup-Targets in der Cloud. Manchmal auch mit Telemetrie-Servern, von denen du nichts wusstest. Wer einmal lauscht, versteht sein eigenes Setup besser. Und kann gezielt entscheiden, was bleiben darf.

Dieser Beitrag zeigt vier Wege, einem WP-Server beim Telefonieren zuzusehen. Vom Proxyman auf dem eigenen Rechner bis zum eBPF-Tracer, der dir den Klartext aus den TLS-Aufrufen zieht, ohne selbst Proxy zu sein. Jeder Weg hat einen anderen Anwendungsbereich und einen anderen blinden Fleck.

Warum sich das Lauschen lohnt

Es geht in diesem Beitrag um den Verkehr, den der Server selbst erzeugt. Also um das, was PHP, WP-Cron und die installierten Plugins beim Rendern, beim Speichern oder im Background-Job nach draußen schicken. Nicht um Embeds oder Schriftarten, die der Browser des Besuchers von Drittservern lädt. Das ist ein anderes Thema mit eigenen Werkzeugen.

Vier Gründe, warum sich der Blick auf den Server-Traffic lohnt:

Backend-Latenz. Sobald ein Plugin synchron auf eine externe API wartet, wartet der Besucher mit. Lizenzserver beim Speichern eines Beitrags, Spam-Check während des Kommentar-Versands, Update-Checks beim Admin-Login: jede dieser Verbindungen kostet eine TCP- und TLS-Runde plus die Antwortzeit der Gegenseite. Wenn die Gegenseite zickt, hängt dein Backend. Ich habe Setups gesehen, in denen ein Plugin-Lizenzserver eine Sekunde brauchte, bevor das Speichern weiterging.

Privatsphäre und DSGVO. Sobald dein WordPress serverseitig Daten an Drittsysteme schickt, bist du in Auftragsverarbeiter-Territorium. Akismet bekommt Kommentar-Inhalte und IP-Adressen. Newsletter-Plugins schicken Abonnenten-Daten an Mailchimp oder Brevo. Backup-Plugins laden Datenbank-Dumps zu Dropbox, S3 oder Google Drive. Du musst wissen, was passiert, bevor du eine saubere Datenschutzerklärung schreiben kannst.

Schadsoftware-Erkennung. Ein kompromittiertes Plugin telefoniert oft nach Hause, lange bevor es Schadcode ausführt. Ungewöhnliche Hostnamen im Outbound-Log sind ein Frühwarnsystem. Nicht perfekt, aber besser als nichts.

Abhängigkeiten verstehen. Du willst wissen, wovon dein Setup abhängt. Wenn api.wordpress.org morgen für drei Stunden ausfällt, was bricht dann? Wenn der Stripe-Endpoint langsam antwortet, was passiert mit deiner Checkout-Strecke? Wer diese Fragen beantworten kann, hat sein eigenes System verstanden.

Weg 1: Proxyman oder mitmproxy auf dem eigenen Rechner

Die einfachste Variante. Du nimmst einen Proxy-Server auf deinem Mac oder Linux-Rechner und biegst den ausgehenden Traffic des WordPress-Servers dorthin um.

Das funktioniert immer dann, wenn der Server deinen Rechner erreichen kann. Lokale VM, Docker-Container auf dem MacBook, ein LAN-Server. Sobald der Server irgendwo bei Hetzner oder AWS steht, scheitert dieser Weg. Dazu kommt Weg 2.

Proxyman und Charles sind die GUI-Klassiker, beide gibt es für Windows, macOS und Linux. Lizenz, schönes Interface, automatisches CA-Management. mitmproxy ist Open Source, läuft im Terminal oder mit mitmweb als Browser-UI. Skriptbar über mitmdump -s addon.py, ideal wenn du den Mitschnitt durch eine Pipeline jagen willst.

Auf macOS tragen Proxyman und Charles ihre Adresse beim Start automatisch in die System-Proxy-Settings ein. Native Mac-Apps und Browser respektieren diese Settings ohne weiteres Zutun. Wenn dein WordPress lokal läuft, etwa über ddev, Docker Desktop oder Laravel Valet, kommst du oft schon allein damit klar: Docker Desktop für Mac kann konfiguriert werden, die System-Proxy-Settings auch in seine Container weiterzureichen (Settings → Resources → Proxies → Use system settings). Dann sieht Proxyman auch den Outbound-Traffic, den ein Container-WordPress erzeugt, ohne dass du in wp-config.php etwas anfassen musst.

Sobald aber der Container die System-Proxy nicht übernimmt oder dein WordPress auf einem Linux-Server irgendwo im Netz liegt, brauchst du die explizite Konfiguration. WordPress hat dafür eigene Konstanten in wp-config.php:

define('WP_PROXY_HOST', '192.168.1.42');
define('WP_PROXY_PORT', '8080');
define('WP_PROXY_BYPASS_HOSTS', 'localhost, 127.0.0.1');

Beachte: Die üblichen Linux-Umgebungsvariablen http_proxy und https_proxy ignoriert PHPs cURL-Extension komplett, Guzzle ebenfalls. Die WP_PROXY_*-Konstanten sind der für WordPress vorgesehene Weg.

Dazu die CA des Proxy-Tools ins System-Trust, sonst zerbricht jede TLS-Verbindung am Zertifikatscheck:

sudo cp mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/mitmproxy.crt
sudo update-ca-certificates

Hier liegt der erste blinde Fleck dieses Weges: Die WP_PROXY_*-Konstanten greifen nur bei der WordPress-eigenen HTTP-API. Sie wirken auf jeden Aufruf, der über wp_remote_get, wp_remote_post oder die WP_Http-Klasse läuft. Plugins, die stattdessen Guzzle einsetzen oder direkt curl_init aufrufen, gehen am Proxy vorbei. Du siehst sie auf dem Mitschnitt nicht.

In der Praxis ist das mehr als ein Randfall. Größere Plugins bringen oft eigene HTTP-Stacks mit, weil sie Funktionen brauchen, die die WP-API nicht abdeckt: Streaming-Uploads, Multipart-Bodies mit Sonderfällen, Retry-Logik, eigene Connection-Pools. Was du auf diesem Weg siehst, ist der WordPress-Anteil des Server-Traffics, nicht der gesamte.

Bevor du auf Weg 2 wechselst, lohnt sich ein Blick in den Plugin-Code. Ein grep über wp-content/plugins/ zeigt, wer an der WP-Http vorbei arbeitet:

grep -rnE "curl_init|curl_exec|GuzzleHttp\\Client|new Client(" wp-content/plugins/ 
  | grep -v /vendor/

Hast du den oder die Verursacher gefunden, kannst du ihnen den Proxy oft an Ort und Stelle mitgeben, ohne den Plugin-Code zu patchen. Guzzle liest standardmäßig die Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY, libcurl tut das ebenfalls, sofern dein PHP-Build die Werte durchreicht. Mit drei Zeilen oben in wp-config.php deckst du beide Wege ab:

// in wp-config.php, vor der WP_PROXY_HOST-Definition
putenv('http_proxy=http://192.168.1.42:8080');
putenv('https_proxy=http://192.168.1.42:8080');
$_SERVER['HTTPS_PROXY'] = 'http://192.168.1.42:8080';

Die putenv-Aufrufe holen Guzzle und libcurl ab, der $_SERVER-Eintrag deckt Plugins, die die Umgebung über das Superglobal lesen. Zusammen mit den WP_PROXY_*-Konstanten von oben siehst du damit den allergrößten Teil der Plugins im Mitschnitt. Was übrig bleibt, sind Plugins, die ihre cURL-Aufrufe so abschotten, dass weder Konstanten noch Umgebung helfen. Die siehst du erst auf Weg 2.

Ein Detail aus der Praxis: Nach update-ca-certificates einmal systemctl restart php8.2-fpm ausführen. Die laufenden PHP-FPM-Worker behalten ihren TLS-Kontext aus dem Initial-Start und sehen die neue CA erst nach Reload. Sonst rätselst du über Zertifikatsfehler, die längst nicht mehr da sind.

Weg 2: Server steht im Netz, lokales Mitlesen geht nicht

Sobald der Server in der Cloud liegt und nicht zu deinem Proxyman zu Hause sprechen darf, brauchst du andere Werkzeuge. Du kannst entweder den Mitschnitt zu dir holen oder direkt auf dem Server arbeiten.

Variante A: tcpdump auf dem Server, Auswertung lokal. Der konservative Weg. Du loggst die Pakete in eine pcap-Datei und analysierst sie zu Hause in Wireshark. Du siehst SNI, DNS-Anfragen, Paketgrößen, Antwortzeiten. Du siehst keinen Klartext.

# Mitschneiden, bis du Strg+C drückst
sudo tcpdump -i any -w /tmp/wp.pcap 'port 80 or port 443 or port 53'

# Lokal in Wireshark öffnen oder via tshark filtern
tshark -r /tmp/wp.pcap -Y 'tls.handshake.extensions_server_name' 
       -T fields -e tls.handshake.extensions_server_name | sort -u

Die letzte Zeile gibt dir eine sortierte Liste aller Hostnamen, mit denen dein Server gesprochen hat. Erstaunlich oft ein erster Aha-Moment. Auf einem meiner Setups sah das so aus:

api.uptimerobot.com
api.wordpress.org
de.planetwp.org
de.wordpress.org
noc1.wordfence.com
w01xxxxx.kasserver.com

Sechs Hosts. Was sie sind:

• api.uptimerobot.com — ein Plugin redet mit dem UptimeRobot-Backend.
• api.wordpress.org — Update-Checks für Core, Themes, Plugins.
• de.planetwp.org — der deutschsprachige WordPress-News-Feed des Backend-Dashboards.
• de.wordpress.org — der deutschsprachige WordPress.org-Mirror, von dem auch die Übersetzungen kommen.
• noc1.wordfence.com — der Definitionsserver des Wordfence-Plugins.
• w01xxxxx.kasserver.com — ein interner Endpoint des Hosters, hier All-Inkl.

Drei der sechs Calls hätte ich aus dem Kopf nicht aufzählen können, jetzt stehen sie in einer Liste und lassen sich einsortieren.

Variante B: mitmproxy direkt auf dem Server, transparent. Ambitionierter, aber liefert Klartext. Du installierst mitmproxy auf dem Server. Per iptables biegst du den ausgehenden Traffic der www-data-UID auf Port 8080 um, dort lauscht mitmproxy:

# Nur ausgehender Traffic des WP-Users auf 443 wird umgeleitet
sudo iptables -t nat -A OUTPUT 
  -p tcp --dport 443 
  -m owner --uid-owner www-data 
  -j REDIRECT --to-ports 8080

# mitmproxy als transparenter Proxy
sudo mitmweb --mode transparent --listen-port 8080 --showhost

Das System-Trust auf dem Server muss die mitmproxy-CA enthalten, sonst zerbrechen die TLS-Verbindungen am Zertifikatscheck. Achtung: das ist eine Eingriffsoperation. Vorher Backup, hinterher iptables-Regel sauber wieder runter.

Variante C: ecapture für eine schnelle Hostnamen-Übersicht. ecapture ist ein Open-Source-Tool, das via eBPF in die TLS-Bibliothek hakt und Daten aus SSL_read und SSL_write ausliest, bevor sie verschlüsselt werden. Keine CA, kein iptables-Eingriff, keine Verbindungs-Umlenkung. Im Default-Modus zeigt es pro Verbindung den Ziel-Hostnamen plus die ersten Bytes der Anwendungsdaten:

# Auf den Traffic des Webserver-Users hören
sudo ecapture tls --uid $(id -u www-data)

Die Ausgabe ist hex-dump-artig und nicht für längere Body-Analysen gedacht, aber für eine schnelle Inventur „mit wem redet mein Webserver gerade” reicht sie. Der Aufruf funktioniert sowohl bei PHP-FPM als auch bei Apache mit mod_php, weil der UID-Filter unabhängig vom Prozess-Layout ist.

Wer den Klartext der Anwendungsschicht sauber in Wireshark sehen will, kommt aus zwei Gründen schnell an Grenzen. Erstens schreibt ecapture v2.3.0 im Keylog-Modus alle Session-Keys ohne Zeilenumbrüche aneinander, das NSS-SSLKEYLOGFILE-Format erwartet aber pro Key eine eigene Zeile. Zweitens werden die Secrets in einen Fixed-Size-Buffer mit Padding-Nullen geschrieben, was Wireshark nicht akzeptiert. Beides lässt sich mit sed-Workarounds reparieren. Was sich nicht reparieren lässt: in Container- oder Docker-Setups passen die Keys aus den eBPF-Hooks nicht zwingend zu den TLS-Sessions, die ein paralleles tcpdump einsammelt, weil ecapture vom Host aus andere Prozesse sieht als der Capture-Punkt am Interface. Wer in solchen Setups Klartext-Body braucht, ist mit Variante B (mitmproxy transparent auf dem Server) besser bedient.

Voraussetzung: halbwegs aktueller Linux-Kernel mit BPF-Support, Root und ein Webserver, der gegen die System-OpenSSL gelinkt ist. ecapture unterstützt darüber hinaus BoringSSL und GnuTLS.

Weg 3: Mit WordPress-Bordmitteln lauschen

Wenn dich der Netzwerk-Layer nicht reizt, kannst du auf Anwendungsebene einsteigen. WordPress hat eine eigene HTTP-API namens WP_Http, durch die fast alle ausgehenden Calls von Core, Themes und Plugins laufen. An diese API kannst du dich anhängen — und überhaupt sind die WordPress-eigenen APIs immer der robustere Weg, mit dem System zu arbeiten (dazu habe ich an anderer Stelle ausführlicher geschrieben).

Das fertige Werkzeug heißt Log HTTP Requests, ein Plugin von Mark Wilkinson. Installieren, aktivieren, eine neue Übersicht im Admin-Bereich anschauen. Jede Anfrage steht dort mit URL, aufrufendem Plugin, Antwortzeit und HTTP-Status. Genug, um in fünf Minuten zu sehen, welches Plugin am gesprächigsten ist.

Einen Schritt weiter geht Snitch. Es protokolliert ausgehende WordPress-HTTP-Calls wie Log HTTP Requests und kann zusätzlich einzelne Hosts per Klick auf eine Sperrliste setzen. Weitere Anfragen dorthin unterbleiben dann. Das ist hilfreich, wenn du im Mitschnitt einen Endpoint findest, der nichts zur eigenen Anwendung beiträgt, und ihn ohne pre_http_request-Code direkt stilllegen willst. Snitch hängt am selben Hook wie das Mu-Plugin und hat darum dieselben blinden Flecken bei Guzzle und direktem cURL.

Wer das selbst bauen will, schreibt sich ein Mu-Plugin in wp-content/mu-plugins/log-http.php:

<?php
add_filter('pre_http_request', function ($preempt, $args, $url) {
    error_log(sprintf(
        '[WP HTTP] %s -> %s (timeout=%ds)',
        $args['method'] ?? 'GET',
        $url,
        $args['timeout'] ?? 5
    ));
    return $preempt;
}, 10, 3);

Das landet in error_log und damit in der PHP-Log-Datei. Vier Zeilen Logik, keine Plugin-Abhängigkeit. Läuft auch in produktiven Setups, in denen du keine Admin-Plugins mehr installieren willst.

Was diese Methode nicht sieht: cURL- oder Guzzle-Aufrufe eines Plugins, die WP_Http umgehen. Das ist derselbe blinde Fleck wie in Weg 1. pre_http_request ist ein Filter der WordPress HTTP-API und feuert ausschließlich für ihre eigenen Aufrufe. Für ein Plugin, das mit Guzzle oder direktem curl_init arbeitet, schlägt der Hook nie an. Diese Calls bekommst du nur auf dem Netzwerk-Layer zu fassen, also mit Weg 2.

Weg 4: DNS-Layer

Wenn du in deinem Heimnetz oder im Server-VLAN ein Pi-hole oder einen dnsmasq mit Query-Logging betreibst, hast du die Hostnamen-Liste praktisch geschenkt. Jede Auflösung wird mitgeloggt, sortierbar nach Domain und Zeit.

Der Vorteil: passiv, kein TLS-Eingriff, kein zusätzlicher Prozess auf dem Server, kein CA-Vertrauen. Der Nachteil: du siehst nur, mit wem dein Server reden wollte, nicht was. Für eine Erstinventur reicht das oft.

Auf einem Server, der Systemd-Resolved benutzt, lässt sich das Logging für eine begrenzte Zeit aktivieren:

sudo resolvectl log-level debug
sudo journalctl -fu systemd-resolved | grep "Looking up"

Aufpassen: produktiv wieder abschalten, sonst füllt das Log schnell die Platte.

Ein blinder Fleck dieses Weges: Wer eine IP statisch im Code anspricht, fragt nie einen Resolver. Im DNS-Log taucht so ein Call nicht auf. In gut gepflegten Plugins ist das die Ausnahme, in Schadcode dagegen das Standardvorgehen. Command-and-Control-Server liegen oft direkt als IP im Code, weil eine DNS-Auflösung das Entdeckungsrisiko erhöhen würde. Auch manche Backup-Plugins steuern S3 oder vergleichbare Endpoints über statische IPs an. Wenn du deinen Mitschnitt darauf abklopfen willst, hilft dir nur der Netzwerk-Layer aus Weg 2: tcpdump und Wireshark zeigen jedes Paket an seiner Ziel-IP, mit oder ohne vorherige DNS-Anfrage.

Was redet ein WordPress-Server so?

Eine typische Liste aus einem mittleren Setup mit zehn bis fünfzehn Plugins. Wichtig: das hier sind nur Server-Calls, also Anfragen, die PHP oder WP-Cron selbst rausschickt. Was der Browser des Besuchers an Drittservern abruft, steht auf einem anderen Blatt. Die Werkzeuge aus diesem Beitrag sehen davon nichts, weil dieser Verkehr nie über deinen Server läuft.

• api.wordpress.org — Update-Checks für Core, Plugins, Themes. Laufen als WP-Cron-Job zweimal täglich und werden bei Admin-Aufrufen ausgelöst, sobald der Cron fällig ist. In aktiven Setups sehr häufig. Der Update-Check ist nicht klein: bei einer Site mit etwa zehn Plugins gehen schnell 30 bis 50 KB Plugin-Inventar pro Anfrage raus, mit Pluginnamen, Versionen, Beschreibungen und URIs.
• downloads.wordpress.org — beim eigentlichen Update einer Komponente.
• wordpress.org/news/feed/ und bei deutscher Lokalisierung zusätzlich de.planetwp.org und de.wordpress.org — die News-Feeds des Backend-Dashboards. Werden beim Aufruf der Admin-Startseite synchron geholt, wenn der Transient leer ist.
• *.akismet.com — wenn Akismet installiert ist. Bei jedem Kommentar geht eine API-Anfrage mit Inhalt, Autor und IP zur Klassifizierung raus.
• api.stripe.com, api.paypal.com und Verwandte — sobald WooCommerce oder ein anderes Shop-Plugin Zahlungen abwickelt. Server-zu-Server. Die Antwortzeit dieser Endpoints ist direkt deine Checkout-Latenz.
• Lizenzserver kommerzieller Plugins — Elementor Pro, ACF Pro, Gravity Forms, Yoast Premium, alles mit Premium-Lizenz. Pingen typischerweise einmal täglich, manche bei jedem Save.
• Backup-Plugins zu ihren Cloud-Targets — UpdraftPlus zu Dropbox, Google Drive oder S3, BackWPup zu eigenen Endpunkten. Während des Backups Megabytes an ausgehendem Traffic.
• Newsletter- und CRM-Plugins — Mailchimp-, Brevo-, ActiveCampaign-Endpoints, sobald sich jemand einträgt oder ein Workflow läuft.
• SMTP-API-Versender — Mailgun, SendGrid, Postmark, Amazon SES, wenn so konfiguriert. Pro versendeter Mail eine HTTPS-Verbindung.
• Sicherheits-Plugins — Wordfence holt Definitionen von noc1.wordfence.com, Sucuri pingt eigene Endpunkte, iThemes Security tut Ähnliches.
• public-api.wordpress.com — Jetpack-Server-Sync, wenn Jetpack aktiv ist. Settings, Plugin-Status, manche Module synchronisieren sich serverseitig.
• WP-Cron-Aufrufe an externe Systeme — alles, was per wp_schedule_event registriert wurde, vom Affiliate-Pixel bis zum Wechselkurs-Sync.

Beim ersten Lauschen tauchen meist drei oder vier Hosts auf, mit denen man nicht gerechnet hat. Oft ein Page-Builder, der bei jedem Save seinen Lizenzserver pingt. Oder ein Backup-Plugin, das stündlich Heartbeats sendet. Oder ein älteres Plugin, dessen Update-Mechanismus an einer fremden Domain hängt, die der Original-Autor längst nicht mehr besitzt. Letzteres ist der Befund, der einen wirklich aufrütteln sollte.

Was du daraus machst

Drei Reaktionen, je nach Befund:

Bewusst zulassen. Update-Checks zu api.wordpress.org willst du behalten. Plugin-Updates sind Sicherheits-Updates. Stripe-Calls beim Checkout sind das eigentliche Geschäft. Hier ist Lauschen reine Inventur.

Eindämmen. Das Dashboard-Widget mit dem WordPress-News-Feed lädt synchron, wenn der Transient leer ist. Wer es entfernen möchte:

// in wp-content/mu-plugins/no-phone-home.php
add_action('wp_dashboard_setup', function () {
    remove_meta_box('dashboard_primary', 'dashboard', 'side');
});

WP-Cron läuft per Default bei jedem Frontend-Aufruf. Wenn ein Hook eine externe API ruft, hängst du im schlechtesten Fall mitten in der Auslieferung einer Seite. Ablösung über echten System-Cron:

// in wp-config.php
define('DISABLE_WP_CRON', true);

# Crontab des Webusers, alle fünf Minuten
*/5 * * * * curl -s https://example.com/wp-cron.php?doing_wp_cron > /dev/null

Damit laufen Hintergrund-Jobs aus der Anfrage-Strecke raus, und ihre Server-Calls bremsen nichts mehr aus.

Abschalten. Wenn ein Plugin bei jedem Save seinen Lizenzserver pingt, hilft ein zielgenauer Block über den pre_http_request-Filter. Damit fängst du eine bestimmte URL ab und gibst eine künstliche Antwort zurück, ohne den Request rauszuschicken:

add_filter('pre_http_request', function ($preempt, $args, $url) {
    if (str_contains($url, 'license-server.example.com')) {
        return ['response' => ['code' => 200], 'body' => '{"status":"ok"}'];
    }
    return $preempt;
}, 10, 3);

Vorsicht beim Body. Eine HTTP-200-Antwort mit {"status":"ok"} reicht in den seltensten Fällen aus. Plugins erwarten je nach Implementierung bestimmte JSON-Felder zurück: Lizenzkey, Ablaufdatum, Aktivierungs-ID, gelegentlich eine Signatur. Bevor du einen Endpoint scharf abschaltest, lässt du den echten Request einmal durchlaufen und loggst die Antwort, etwa über das Log-Mu-Plugin von oben oder direkt im pre_http_request-Filter. Aus dieser Antwort baust du dann das Mock zusammen. Sonst hast du das Plugin nicht beruhigt, sondern in einen anderen Fehlerzustand geschoben.

Das ist ein scharfes Werkzeug. Lizenzprüfungen abzuschalten verstößt je nach Plugin gegen die Lizenzbedingungen. Für tote Update-Endpoints, deren Domain niemandem mehr gehört, ist es trotzdem das richtige Mittel. Genauso für Telemetrie, die du nicht haben willst.

Ersetzen. Ein Plugin, dessen Update-Server nicht mehr existiert, gehört durch eine gepflegte Alternative ersetzt. Ein Backup-Plugin, das zu einem Cloud-Provider in den USA schreibt, durch eines mit europäischem Target. Ein Mail-Versender mit fragwürdiger AVV durch einen seriösen.

Bei jedem dieser Schritte lohnt es sich, vor und nach der Änderung kurz zu lauschen. So siehst du, ob die Maßnahme tatsächlich greift. Manche Plugins bauen ihre Calls so trickreich, dass pre_http_request sie nicht erwischt, weil sie an WP_Http vorbei direkt cURL aufrufen. Solche Fälle siehst du erst auf der Netzwerkschicht.

Lauschen ist Inventur

Hör einmal eine halbe Stunde mit. Egal ob mit Proxyman, mitmproxy oder dem Mu-Plugin von oben. Du wirst überrascht sein, wer alles mitredet. Und du wirst Plugins anders aussuchen, sobald du weißt, wie sie sich im Netzwerk verhalten.

Wenn dein WP-Server irgendwo in der Cloud steht und du keinen lokalen Proxy erreichen kannst, ist tcpdump plus eine pcap-Datei der schnellste Einstieg. Für Klartext-Mitschnitte direkt auf dem Server ist mitmproxy als transparenter Proxy der zuverlässige Weg. Und auf der WordPress-Seite reichen vier Zeilen PHP, um ein eigenes Audit-Log zu starten.

Lauschen ist Inventur. Und Inventur ist die Grundlage für jede sinnvolle Optimierung, egal ob es um Performance, DSGVO oder Sicherheit geht.

Links und weiterführende Quellen

Werkzeuge

• mitmproxy: https://docs.mitmproxy.org/stable/
• ecapture: https://github.com/gojue/ecapture
• Charles Proxy: https://www.charlesproxy.com/
• Proxyman: https://proxyman.io/
• Plugin „Log HTTP Requests”: https://wordpress.org/plugins/log-http-requests/
• Plugin „Snitch” (loggen plus blocken): https://wordpress.org/plugins/snitch/

WordPress-Hooks und HTTP-API

• pre_http_request: https://developer.wordpress.org/reference/hooks/pre_http_request/
• WP_Http-Klasse: https://developer.wordpress.org/plugins/http-api/

Linux-Werkzeuge

• tcpdump-Manpage: https://www.tcpdump.org/manpages/tcpdump.1.html
• iptables OWNER-Match: https://ipset.netfilter.org/iptables-extensions.man.html
• Wireshark / tshark: https://www.wireshark.org/docs/