Wireshark für Admins: Die 10 wichtigsten Display-Filter für den IT-Alltag

„Das Netzwerk ist langsam.“ Wenn du im IT-Support oder in der Administration arbeitest, ist dieser Satz vermutlich dein persönlicher Endgegner. Es ist die vage Beschreibung eines Problems, das alles sein kann: ein sterbender Switch-Port, ein überlasteter SQL-Server, ein falsch konfigurierter Virenscanner oder schlicht ein defektes Patchkabel. Und meistens beginnt damit das übliche Spiel: Das Netzwerkteam sagt „bei uns ist alles grün“, das Applikationsteam sagt „an uns liegt’s nicht“ – und der Anwender wartet weiter. Dieses Fingerpointing kostet Unternehmen oft mehr Zeit und Geld als das eigentliche Problem.

Monitoring-Tools wie Checkmk, PRTG oder Zabbix sagen dir, dass etwas nicht stimmt – Wireshark sagt dir, warum. Und vor allem: Es liefert Belege, die die Schuldfrage objektiv klären, statt sie im Kreis zu drehen.

Wer Wireshark zum ersten Mal öffnet, fühlt sich oft wie ein Pilot ohne Training in einem vollbesetzten Cockpit. Tausende Pakete rauschen pro Sekunde vorbei. Ohne die richtigen Filter suchst du nicht nach der Nadel im Heuhaufen – du suchst nach einer ganz bestimmten Nadel in einem Heuhaufen, der gerade von einem Wirbelsturm durchgeschüttelt wird.

In diesem Artikel zeige ich dir – basierend auf meiner täglichen Arbeit als freiberuflicher Netzwerkanalytiker – welche 10 Display-Filter du brauchst, um Performance-Probleme in Unternehmensnetzen innerhalb von Minuten einzugrenzen. Jeden Filter kannst du direkt per Klick kopieren, und am Ende der Liste findest du alle noch einmal kompakt als Spickzettel.

Das typische Phantom-Problem: Wenn alle Werte grün sind, aber nichts funktioniert

Stell dir vor, ein Anwender meldet, dass die ERP-Software sporadisch „hängt“. Ping zum Server: stabile 1 ms. CPU-Last: 5 %. Uplink-Auslastung: 10 %. Die Standard-Tools zeigen keine Fehler.

In meiner Praxis erlebe ich genau dieses Szenario regelmäßig. Viele Admins tauschen an diesem Punkt auf Verdacht Hardware oder erhöhen VM-Ressourcen – teures Raten ohne Datenbasis. Mit einer gezielten Netzwerkanalyse per Wireshark sehen wir stattdessen schnell, was wirklich passiert: Die Anwendung wartet auf eine Antwort, die nie ankommt. Oder TCP Retransmissions bremsen den Datenfluss massiv aus. Das Problem liegt im Protokollverhalten, nicht in der Bandbreite.

Capture Filter vs. Display Filter: Ein Unterschied, der entscheidet

Bevor wir zu den Filtern kommen, kurz das Wichtigste vorab. Wireshark kennt zwei Filtertypen – mit unterschiedlicher Syntax:

• Capture Filter: Bestimmen, was überhaupt aufgezeichnet wird. Sie nutzen die BPF-Syntax (wie tcpdump), z. B. host 192.168.1.10.
• Display Filter: Bestimmen, was du aus der aufgezeichneten Datenmenge siehst, z. B. ip.addr == 192.168.1.10 oder tcp.analysis.retransmission. Dein schärfstes Werkzeug – und Thema dieses Artikels.

Die beiden Syntaxen sind nicht austauschbar: host 192.168.1.10 färbt sich in der Display-Filter-Leiste rot, ip.addr == ... im Capture-Dialog ebenso.

Wann du lieber alles aufzeichnest: In vielen Fällen ist es die bessere Entscheidung, den Capture Filter ganz wegzulassen und den gesamten Traffic zu erfassen. Besonders bei Problemen, die durch Cross-Traffic ausgelöst werden – also wenn eine andere Applikation oder ein anderer Netzwerkteilnehmer die eigentliche Störung verursacht – siehst du das Zusammenspiel nur im vollständigen Mitschnitt. Auch bei Authentifizierungsproblemen ist das entscheidend: Hast du deinen Capture Filter nur auf die betroffene Applikation gesetzt, fehlt dir im Nachhinein der Kontext. Du siehst zum Beispiel, dass eine Verbindung abbricht, aber nicht, dass kurz davor eine LDAP- oder Kerberos-Anfrage ins Leere lief – ein typisches Muster, das ich in meinem Beitrag zu Verbindungsabbrüchen ausführlich beschreibe. Solche Zusammenhänge nachträglich zu rekonstruieren ist schwierig bis unmöglich.

Wann ein Capture Filter sinnvoll ist: In stabilen, hochausgelasteten Umgebungen, in denen du das Problem bereits gut eingegrenzt hast, kann ein Capture Filter die Datenmenge erheblich reduzieren. Eine PCAP-Datei, die unkontrolliert wächst, wird schnell unhandlich – und ein Wireshark, das beim Öffnen einer 10-GB-Datei in die Knie geht, hilft niemandem. Wenn du weißt, dass du nur den Verkehr zwischen einem Client und einem bestimmten Server brauchst, spart host 10.1.1.5 viel Speicherplatz und hält die Analyse übersichtlich. Gerade wenn du gezielt Paketverluste oder ein TCP-Window-Problem zwischen zwei bekannten Hosts eingrenzt, ist ein enger Capture Filter das richtige Mittel.

Der Mittelweg für sporadische Fehler: der Ringpuffer. Tritt ein Problem nur ab und zu auf, willst du weder eine riesige Datei füllen noch den entscheidenden Moment verpassen. Die Lösung ist ein Mitschnitt mit dumpcap – dem schlanken Aufzeichnungsprogramm, das im Wireshark-Installationsverzeichnis mitkommt:

dumpcap schreibt damit Dateien von je rund 100 MB und behält immer die letzten 50 – ältere werden automatisch überschrieben. Der Mitschnitt kann so tagelang laufen, ohne die Platte zu füllen. Wie weit der Puffer zurückreicht, hängt von der Last ab; Dateigröße und -anzahl passt du entsprechend an. Die Nummer der richtigen Schnittstelle zeigt dir dumpcap -D. Wichtig: Lass dir vom Anwender die genaue Uhrzeit des nächsten Auftretens geben – dann weißt du, welche Datei du öffnen musst.

Die Faustregel: Im Zweifel alles aufzeichnen und per Display Filter analysieren. Zu viele Daten lassen sich eingrenzen – zu wenige Daten lassen sich nicht rekonstruieren.

Display-Filter verändern die Daten nicht – sie machen sie sichtbar. Für ihren effektiven Einsatz brauchst du ein solides Verständnis von TCP/IP: Wie sieht ein Three-Way-Handshake aus? Wie funktioniert Window Scaling? Warum ist ein TCP-Reset oft der digitale Hilferuf einer überlasteten Anwendung?

Die 10 wichtigsten Wireshark Display-Filter für die Praxis

1. TCP Retransmissions aufspüren

Der wichtigste Filter für die Diagnose von Paketverlusten. Geht ein Paket im Netz verloren, bemerkt TCP das und sendet es erneut – mit messbaren Wartezeiten als Konsequenz.

Warum das wichtig ist: Schon eine Verlustrate von 1–2 % kann den Durchsatz einer TCP-Verbindung um ein Vielfaches einbrechen lassen, weil TCP bei jedem Verlust sein Sendefenster drosselt. Wie stark, zeigt eine bekannte Faustformel (nach Mathis et al.):

Max. Durchsatz ≈ (MSS / RTT) × (1,22 / √Verlustrate)

Ein Rechenbeispiel: Bei einer Segmentgröße (MSS) von 1460 Byte, 10 ms Round Trip Time und 1 % Paketverlust kommt eine einzelne TCP-Verbindung auf rund 14 Mbit/s – auf einer Gigabit-Leitung. Die Bandbreite ist da, sie wird nur nicht genutzt. Die Formel beschreibt das klassische Verhalten von TCP Reno; CUBIC und vor allem BBR reagieren anders auf Verluste. Wie sich die Algorithmen unterscheiden, erkläre ich in meinem Beitrag zu TCP Congestion Control mit Reno, CUBIC und BBR.

Retransmissions sind oft das erste sichtbare Symptom eines tieferliegenden Problems – und häufig begleitet von Duplicate ACKs und Out-of-Order-Paketen, die zusammen ein klares Bild ergeben (mehr dazu bei Filter 7).

Achte auf den Messpunkt: Wireshark markiert eine Retransmission, sobald es dasselbe Segment ein zweites Mal sieht. Siehst du Original und Wiederholung, ging das Original erst hinter deinem Messpunkt verloren – der Verlust liegt zwischen Messpunkt und Empfänger. Ging es dagegen schon vor dem Messpunkt verloren, meldet Wireshark zuerst eine Lücke („Previous segment not captured“), die du mit tcp.analysis.lost_segment findest. Aber Vorsicht: Dieselbe Meldung entsteht, wenn dein Mitschnitt selbst Pakete verpasst hat – etwa an einem überlasteten SPAN-Port – und ganz am Anfang eines Mitschnitts ist sie normal.

Praxis-Tipp: Treten Retransmissions nur bei einem bestimmten Ziel auf? Dann liegt das Problem wahrscheinlich auf dem Weg dorthin – Router, Firewall, WAN-Strecke. Treten sie überall auf? Prüfe die lokale NIC oder den Switch-Stack. Wie du Paketverluste methodisch misst und lokalisierst, zeige ich dir in meinem Guide Packet Loss messen und analysieren mit Wireshark.

2. IP-Adressen filtern: Den Verdächtigen isolieren

Simpel, aber hocheffektiv. Zeigt dir den gesamten Datenverkehr – ein- und ausgehend – eines bestimmten Geräts. Für IPv6 heißt das Feld ipv6.addr.

Erweiterung: Nutze ip.src == ... für Quelladressen oder ip.dst == ... für Zieladressen. Für die Analyse zwischen zwei Hosts: ip.addr == 10.0.0.1 && ip.addr == 10.0.0.2. Noch schneller geht es per Rechtsklick auf ein Paket → Conversation Filter → TCP: Wireshark baut dir dann einen Filter wie tcp.stream eq 5, der genau diese eine Verbindung zeigt.

Achtung, Stolperfalle beim Ausschließen: ip.addr ist ein Feld mit zwei Werten – es steht gleichzeitig für Quell- und Zieladresse. Genau das hat früher zu einem der häufigsten Anfängerfehler geführt: ip.addr != 192.168.1.10 bedeutete in älteren Wireshark-Versionen (bis 3.4) „irgendeine der beiden Adressen ist ungleich“ – und zeigte damit praktisch alle Pakete an, auch die des Hosts, den du loswerden wolltest. Seit Wireshark 3.6 verhält sich != wie erwartet. Am sichersten – und in jeder Version eindeutig – ist die geklammerte Negation:

Die Klammern machen den Filter außerdem für Kollegen lesbar, die später deinen Trace öffnen. Dieselbe Logik gilt für alle Felder mit Quell- und Zielwert wie tcp.port, udp.port oder eth.addr.

3. TCP Resets: Verbindungsabbrüchen auf den Grund gehen

Ein TCP Reset (RST) ist das sofortige, harte Beenden einer Verbindung – ohne Vorwarnung.

Häufige Ursachen: Eine Firewall lehnt die Verbindung aktiv ab, auf dem Zielport lauscht kein Dienst, oder eine Anwendung bricht die Verbindung ab bzw. stürzt ab. Schau dir immer an, wer das RST sendet – Client, Server oder ein Gerät dazwischen. Ein bewährter Trick: Vergleiche die TTL des RST-Pakets (ip.ttl) mit der TTL der übrigen Pakete desselben Absenders. Weicht sie deutlich ab, stammt das RST sehr wahrscheinlich nicht vom Server, sondern von einer Firewall oder einem Proxy, der im Namen des Servers antwortet.

Aus der Praxis: Ein Kunde klagte über Verbindungsabbrüche zum SQL-Server. Der Filter zeigte massenhaft RST-Pakete von der Firewall-IP. Ursache: Ein IPS-Modul stufte legitime SQL-Abfragen fälschlicherweise als SQL-Injection ein. Ergebnis: Ursache nach wenigen Stunden Analyse belegt – statt tagelanger Diskussionen zwischen Datenbank- und Netzwerkteam. Wie du solche Verbindungsabbrüche systematisch analysierst – von RST-Paketen über Timeouts bis zu Firewall-bedingten Abbrüchen – beschreibe ich in einem eigenen Beitrag.

4. Antwortzeiten messen: Netzwerk oder Anwendung?

Zeigt alle Pakete, bei denen seit dem vorherigen Paket im selben TCP-Stream mehr als 500 ms vergangen sind. Bleibt der Filter wider Erwarten leer, prüfe in den TCP-Protokolleinstellungen, ob „Calculate conversation timestamps“ aktiviert ist – ohne diese Option berechnet Wireshark das Feld nicht.

Einsatzbereich: Ideal, um die Schuldfrage zu klären. Wenn der Client eine Anfrage schickt, der Server sie per TCP-ACK bestätigt, aber erst nach 800 ms mit Daten antwortet, hast du einen starken Beleg: Das Netzwerk hat das Paket zügig zugestellt, aber die Anwendung oder Datenbank auf dem Server ist der Bottleneck. Zur Gegenprobe vergleichst du die Wartezeit mit der Round Trip Time aus dem Handshake – liegt die bei 1 ms, ist die Sache eindeutig. Wie du die RTT sauber misst, zeige ich in meinem Beitrag zu hoher Latenz im Firmennetz.

Kleiner Stolperstein: Kommt das reine ACK nicht sofort, sondern nach typischerweise 40 bis 200 ms, ist das meist Delayed ACK – der Empfänger wartet bewusst kurz, ob er die Bestätigung mit Daten kombinieren kann. Das ist normales Verhalten und kein Netzwerkproblem.

Wichtig bei der Interpretation: Nicht jede lange Pause ist ein Problem. Der Filter trifft auch Pausen, in denen schlicht der Anwender nichts getan hat, Keep-Alives und wiederholte Verbindungsversuche. Entscheidend ist die Richtung: Wartet der Client auf den Server – oder der Server auf den Client? Mit dieser Variante blendest du reine ACKs und Keep-Alives aus und siehst nur Pakete mit echten Nutzdaten:

Am besten legst du tcp.time_delta zusätzlich als Spalte an und liest die Treffer im Kontext des Streams – wie das geht, erkläre ich in Wie lese ich einen TCP Stream richtig?

Wie mächtig dieser eine Filter in der Praxis ist, zeigen zwei meiner Praxisfälle: Bei den sequentiellen Datenbank-Requests nach dem N+1-Query-Muster war nicht das Netzwerk schuld, sondern eine Anwendung, die tausende Einzelabfragen nacheinander abschickte. Und beim SQL-Zugriff über eine WAN-Strecke bremste ebenfalls die Applikation – nicht die Leitung.

5. DNS-Fehler aufdecken

Hinter vielen vermeintlichen Netzwerkfehlern steckt ein DNS-Problem. Dieser Filter zeigt alle DNS-Antworten ohne „No error“-Status – z. B. „No such name“ (NXDOMAIN), „Server failure“ oder „Refused“.

Nicht jeder Treffer ist ein Fehler: Gerade in Active-Directory-Umgebungen erzeugt die DNS-Suffix-Suchliste reihenweise NXDOMAIN-Antworten, weil der Client einen kurzen Namen nacheinander mit mehreren Suffixen ausprobiert. Interessant wird es, wenn ein Name am Ende gar nicht aufgelöst wird – oder jede Auflösung erst nach mehreren Fehlversuchen klappt und dadurch spürbar Zeit kostet.

Der übersehene Fall – gar keine Antwort: Ein Server braucht 5 Sekunden zum Starten einer Applikation? Oft versucht er, einen Hostnamen aufzulösen, dessen DNS-Server nicht antwortet – und wartet auf den Timeout. Dieser Fall taucht im rcode-Filter nicht auf, weil es gar keine Antwort gibt, deren Fehlercode man filtern könnte. Dafür brauchst du:

Das zeigt alle DNS-Anfragen, zu denen im Mitschnitt keine Antwort existiert. Langsame, aber erfolgreiche Antworten findest du mit dns.time > 0.5.

Genau deshalb ist es wichtig, beim Mitschneiden nicht zu früh zu filtern: Hättest du nur den Traffic der betroffenen Applikation aufgezeichnet, wäre die DNS-Anfrage – die auf einem anderen Port läuft – gar nicht im Capture gelandet.

6. HTTP-Fehlercodes filtern

Wenn Webdienste oder APIs Probleme machen, zeigt dir dieser Filter sofort alle Client-Fehler (4xx) und Server-Fehler (5xx).

Nutzen: Du siehst sofort, ob ein Webserver 404 Not Found oder 500 Internal Server Error zurückgibt – ohne mühsam Logfiles zu wälzen. Und anders als im Server-Log siehst du hier auch, welcher Client betroffen war. Wie lange eine Antwort gedauert hat, zeigt das Feld http.time – mit http.time > 1 findest du alle Antworten über einer Sekunde.

Einschränkung: Das funktioniert nur bei unverschlüsseltem HTTP – also typischerweise bei internen APIs, Health-Checks oder dem Verkehr hinter einem Load Balancer mit TLS-Terminierung. Bei HTTPS brauchst du die Session-Keys (siehe Filter 10).

7. Duplicate ACKs: Der Vorbote von Retransmissions

Wenn der Empfänger ein Paket erhält, aber eine Lücke in den Sequenznummern bemerkt, schickt er Duplicate ACKs: „Mir fehlt da was!“

Bedeutung: Duplicate ACKs sind oft der direkte Vorbote von Retransmissions. Klassisch lösen drei Duplicate ACKs den TCP Fast Retransmit aus – der Sender schickt das fehlende Paket sofort erneut, ohne auf den Timeout zu warten. Die Ursache ist häufig ein überlasteter Switch- oder Router-Puffer, der Pakete verwirft. Aber Vorsicht: Auch umsortierte Pakete (Out-of-Order), etwa durch Lastverteilung über mehrere Leitungen, erzeugen Duplicate ACKs – ganz ohne Verlust. Wie du diese Fälle auseinanderhältst und was du in der Praxis daraus ableitest, erkläre ich ausführlich in meinem Beitrag TCP Retransmissions, Duplicate ACKs und Out-of-Order – was die Unterschiede wirklich bedeuten.

8. TCP Window Size: Wenn der Empfänger nicht hinterherkommt

Das TCP Window gibt an, wie viele Daten ein Empfänger gerade noch puffern kann. Sinkt es gegen null (Zero Window), sagt der Empfänger: „Stopp – mein Puffer ist voll.“

Warum der Zusatz mit dem Reset-Flag? RST-Pakete tragen fast immer ein Window von 0 und würden die Trefferliste sonst mit Fehlalarmen füllen. Außerdem gilt: tcp.window_size ist der skalierte Wert – korrekt berechnen kann Wireshark ihn nur, wenn der Verbindungsaufbau (SYN/SYN-ACK) im Mitschnitt enthalten ist. Fehlt er, rechnet Wireshark mit dem unskalierten Rohwert, und der Filter schlägt bei eigentlich großen Fenstern an.

Noch präziser: Mit tcp.analysis.zero_window filterst du direkt auf die Pakete, in denen Wireshark ein Zero Window erkannt hat – ohne selbst einen Schwellwert wählen zu müssen. Die Gegenseite zeigt tcp.analysis.window_full: Hier hat der Sender das angebotene Fenster komplett ausgeschöpft und muss warten.

Analyse: Ein kleines oder geschlossenes Fenster bedeutet: Die empfangende Anwendung holt die Daten nicht schnell genug aus dem TCP-Empfangspuffer ab. Ursache kann CPU-Last sein, genauso aber langsames Storage, ein blockierter Thread oder schlicht Anwendungslogik, die erst etwas anderes erledigt – wie stark ein einzelner Thread eine ganze Anwendung ausbremsen kann, zeigt mein Praxisfall zu Single-Threading als Performance-Killer. Oft ist das Muster bei trägen Terminalserver-Sitzungen oder Datenbank-Clients zu sehen – und ein klarer Hinweis, dass das Netzwerk nicht der Engpass ist. Das Konzept hinter Window Size und Window Scaling – inklusive der Frage, warum falsche Scaling-Faktoren die Performance heimlich drosseln – erkläre ich in meinem Beitrag TCP Window Size und Window Scaling einfach erklärt.

9. SYN ohne Antwort: Wenn der Server schweigt

Dieser Filter zeigt alle Verbindungsversuche (SYN-Pakete) im Mitschnitt – erfolgreiche wie gescheiterte. Das ist der Überblick: Wer versucht, sich wohin zu verbinden?

Die gescheiterten Versuche herausfiltern: Bekommt ein Client auf sein SYN keine Antwort, wiederholt er es – je nach Betriebssystem typischerweise nach etwa einer Sekunde, dann nach zwei, dann nach vier. Genau diese Wiederholungen markiert Wireshark als Retransmission – und damit findest du gezielt die Verbindungsversuche, die ins Leere laufen:

Eine Einschränkung: Manche Anwendungen starten jeden neuen Versuch mit einem neuen Quellport. Für Wireshark ist das dann jedes Mal eine neue Verbindung, und die Wiederholung wird nicht als Retransmission markiert. Siehst du also viele einzelne SYNs zum selben Ziel ohne Antwort, prüfe den ersten Filter mit Blick auf die Zieladresse.

Diagnose: Der Klassiker für „Server nicht erreichbar“. Du siehst das SYN, aber kein SYN-ACK kommt zurück – entweder verwirft eine Firewall das Paket stillschweigend, ein Routing-Problem verhindert die Zustellung, oder der Ziel-Host ist gerade nicht erreichbar. Kommt dagegen ein RST zurück, ist das Ziel erreichbar, aber auf dem Port lauscht nichts – oder eine Firewall lehnt aktiv ab (siehe Filter 3).

Für einen echten Beweis brauchst du allerdings einen zweiten Messpunkt: Kommt das SYN beim Server an und nur das SYN-ACK nicht zurück, liegt das Problem auf dem Rückweg – etwa bei asymmetrischem Routing. Erst der Mitschnitt auf beiden Seiten macht aus einem starken Indiz einen belastbaren Befund. Wie der TCP-Handshake im Detail funktioniert und was jede Abweichung bedeutet, habe ich in einem eigenen Grundlagenartikel beschrieben.

Kleiner Syntax-Hinweis: Im Netz findest du oft die Variante !tcp.flags.ack == 1. Die liefert dasselbe Ergebnis – == 0 ist aber auf einen Blick lesbarer und lässt keinen Zweifel, worauf sich die Negation bezieht.

10. Paket-Inhalte durchsuchen

Manchmal muss man tiefer graben. Dieser Filter durchsucht die gesamten Paketdaten nach einem bestimmten String.

Zwei Details, die oft für Verwirrung sorgen: Der Suchbegriff gehört in Anführungszeichen – ohne sie lehnen aktuelle Wireshark-Versionen den Filter ab oder interpretieren das Wort als Feldnamen. Und contains unterscheidet Groß- und Kleinschreibung: „Google“ wird mit „google“ nicht gefunden. Unabhängig von der Schreibweise suchst du mit frame matches "google" – der Operator matches arbeitet mit regulären Ausdrücken und ignoriert Groß- und Kleinschreibung standardmäßig.

Wichtiger Hinweis: Das funktioniert nur bei unverschlüsseltem Verkehr (HTTP, SMTP, unverschlüsselte Datenbankprotokolle). Bei TLS-Traffic siehst du nur Zeichensalat – es sei denn, du hinterlegst die Session-Keys über die SSLKEYLOGFILE-Variable in Wireshark. Einiges bleibt aber auch verschlüsselt sichtbar: Den aufgerufenen Hostnamen findest du in der Regel im TLS-Handshake, z. B. mit tls.handshake.extensions_server_name contains "google". Wie viel der Handshake sonst noch verrät – etwa Zertifikatsdetails – zeigt mein Praxisfall zu TLS-Zertifikatsfehlern in einer VoIP-Umgebung: Dort verriet Wireshark die Fehlerursache, während die Konsole des Systems komplett schwieg.

Bonus: Der Alles-auf-einen-Blick-Filter

Wenn du einen unbekannten Trace zum ersten Mal öffnest und schnell wissen willst, ob überhaupt etwas im Argen liegt: Dieser Filter zeigt dir alle Pakete, die Wireshark selbst als auffällig markiert hat – Retransmissions, Duplicate ACKs, Zero Windows, Out-of-Order und mehr. Die Window Updates blenden wir aus, weil sie normal und harmlos sind.

Mein Standard-Einstieg in fast jede Analyse: Ist die Trefferliste leer, liegt das Problem sehr wahrscheinlich nicht auf der TCP-Transportebene. Dann lohnt sich der Blick auf Antwortzeiten (Filter 4) und DNS (Filter 5) – und du sparst dir stundenlanges Suchen am falschen Ort. Gibt es Treffer, verschafft dir Analyze → Expert Information (in der deutschen Oberfläche „Experteninformationen“) eine nach Kategorien gruppierte Übersicht: wie viele Retransmissions, wie viele Zero Windows, in welchen Verbindungen.

Spickzettel: Alle Filter auf einen Blick

Zum schnellen Nachschlagen – sortiert nach der Frage, die du gerade beantworten willst:

Die drei häufigsten Ursachen in meinen Projekten

Duplex-Mismatch und defekte Kabel führen zu massiven Paketverlusten. Wireshark zeigt viele Retransmissions ohne klare Richtung – die eigentlichen CRC-Fehler siehst du dagegen nicht im Trace, weil die Netzwerkkarte fehlerhafte Frames verwirft, bevor Wireshark sie erfasst. Die Bestätigung liefern die Fehlerzähler am Switch-Port. Wie du solche Paketverluste sauber lokalisierst und von anderen Ursachen abgrenzt, zeigt mein Packet-Loss-Guide.

Überlastete Sicherheits-Appliances: Firewalls mit Deep Packet Inspection werden zum Bottleneck, wenn der Durchsatz steigt. Erkennbar an steigenden tcp.time_delta-Werten, sobald der Verkehr durch die Firewall läuft – kombiniert mit sporadischen Verbindungsabbrüchen, die auf den ersten Blick keinem klaren Muster folgen.

Fehlkonfigurierte MTU: Wenn Pakete zu groß für einen VPN-Tunnel sind und nicht fragmentiert werden dürfen, meldet der Router das eigentlich per ICMP („Fragmentation needed“). Wird diese Meldung aber von einer Firewall blockiert, verschwinden die großen Pakete einfach – während kleine Pakete und der Verbindungsaufbau tadellos funktionieren. Einer der frustrierendsten Fehler im WAN-Umfeld, der sich oft als scheinbar zufälliger Paketverlust tarnt. Kommen die ICMP-Meldungen durch, findest du sie mit icmp.type == 3 && icmp.code == 4 (bei IPv6: icmpv6.type == 2, „Packet Too Big“); fehlen sie, sind wiederholt übertragene Pakete in voller Größe das typische Muster.

Best Practices für den professionellen Wireshark-Einsatz

An der richtigen Stelle mitschneiden: Bei Problemen zwischen Client und Server idealerweise an beiden Enden gleichzeitig mitschneiden. So erkennst du sofort, ob ein Paket unterwegs verloren ging oder vom Empfänger ignoriert wurde. Achte dabei darauf, dass beide Messpunkte per NTP synchronisierte Uhren haben – sonst vergleichst du Zeitstempel, die nicht zusammenpassen.

Coloring Rules und Spalten nutzen: Wireshark färbt Pakete standardmäßig ein. Passe diese Regeln an deine häufigsten Filter an – so erkennst du kritische Muster auf einen Blick, ohne aktiv filtern zu müssen. Häufig genutzte Filter kannst du außerdem als Filter-Buttons neben der Filterleiste speichern, und Felder wie tcp.time_delta oder tcp.stream per Rechtsklick → „Als Spalte anwenden“ dauerhaft einblenden.

Datenschutz von Anfang an mitdenken: Ein vollständiger Mitschnitt enthält personenbezogene Daten – IP-Adressen, Benutzernamen, im Klartext oft auch Inhalte. Kläre deshalb vor dem Mitschneiden ab, wer informiert sein muss (Datenschutz, je nach Unternehmen auch Betriebsrat), speichere Traces nur so lange wie nötig und verschicke sie nicht unverschlüsselt per Mail. Das schützt dich – und erhöht die Akzeptanz, wenn du beim nächsten Mal wieder mitschneiden musst.

Baseline aufnehmen: Mache eine Netzwerkanalyse, wenn alles ruhig läuft. Nur wer den Normalzustand seines Netzes kennt, kann Abweichungen im Fehlerfall sicher als Problem identifizieren. Wie du dabei Schritt für Schritt vorgehst, beschreibe ich in meiner 5-Schritte-Methodik zur systematischen Fehlereingrenzung.

Fazit: Datenbasiert entscheiden statt auf Verdacht handeln

Wireshark ist kein Tool, das man nebenbei lernt – es erfordert Übung und ein solides Verständnis der Protokolle. Aber was im Trace steht, ist tatsächlich passiert: Pakete lügen nicht. Wer die zehn Filter aus diesem Artikel beherrscht, kann einen Großteil der gängigen Performance-Probleme in kurzer Zeit eingrenzen – und vor allem: mit Belegen argumentieren statt zu raten. Das beendet nicht nur die Fehlersuche schneller, sondern auch das Fingerpointing zwischen Teams.

Meine Empfehlung: Warte nicht auf den nächsten Notfall. Installiere Wireshark in einer Testumgebung, ruf eine Webseite auf und probiere die Filter aus. Schau dir an, wie ein normaler TCP-Verbindungsaufbau aussieht – dann erkennst du Abweichungen sofort. Einen guten Einstieg in den gesamten Analyse-Workflow bietet mein Beitrag zur Wireshark-Netzwerkanalyse für Performance-Fehler. Wie so eine Analyse in echten Projekten aussieht – inklusive Traces, Denkweise und Ergebnis – zeigen meine Praxisfälle zum N+1-Query-Muster und zu TLS-Zertifikatsfehlern im VoIP-Umfeld.

Und wenn du gerade mitten in so einem Fall steckst: Vielleicht wälzt du als Admin seit Tagen Traces, ohne dass sich die Ursache zeigt. Vielleicht musst du als Applikationsverantwortlicher belegen, dass deine Software nicht das Problem ist. Oder du willst als IT-Leiter einfach, dass das Thema nach Wochen endlich vom Tisch ist. Dann melde dich für ein kostenloses Erstgespräch – wir klären gemeinsam, wo du stehst und ob eine Paketanalyse der richtige nächste Schritt ist.

FAQ – Häufig gestellte Fragen

1. Warum sehe ich so viele „Checksum Errors“ in Wireshark?

Das liegt meist am Checksum Offloading: Bei ausgehenden Paketen des Rechners, auf dem Wireshark läuft, berechnet erst die Netzwerkkarte die Prüfsumme – Wireshark greift das Paket aber vorher ab. Das ist kein echtes Netzwerkproblem, sondern ein Artefakt der Messung. In aktuellen Wireshark-Versionen ist die Prüfsummenvalidierung standardmäßig ohnehin deaktiviert; siehst du die Fehler trotzdem, wurde sie in den Protokolleinstellungen (IP, TCP, UDP) aktiviert und kann dort wieder abgeschaltet werden.

2. Warum sehe ich Pakete, die viel größer als 1500 Byte sind?

Auch das ist ein Offloading-Effekt, diesmal Segmentation Offloading (unter Windows „Large Send Offload“): Schneidest du direkt auf einem Server oder Client mit, übergibt das Betriebssystem große Datenblöcke an die Netzwerkkarte, die sie erst danach in Pakete passender Größe zerlegt. Wireshark sieht den Block vorher – auf der Leitung existieren diese Riesenpakete so nicht. Beim Empfang kann derselbe Effekt umgekehrt auftreten, wenn die Karte Pakete zusammenfasst. Für eine saubere Bewertung auf Paketebene ist ein Mitschnitt per SPAN-Port oder TAP deshalb oft aussagekräftiger als einer auf dem betroffenen System selbst.

3. Kann Wireshark auch verschlüsselten HTTPS-Traffic lesen?

Ja – aber nur unter bestimmten Voraussetzungen. Der praktikable Weg ist die SSLKEYLOGFILE-Variable: Browser und viele andere Anwendungen schreiben damit ihre Session-Keys in eine Datei, die du in Wireshark einbindest. Der private Schlüssel des Servers allein hilft heute meist nicht mehr weiter, weil er nur beim veralteten RSA-Schlüsselaustausch funktioniert – bei TLS 1.3 und modernen Cipher Suites mit (EC)DHE bringt er nichts.

4. Wo platziere ich den Analyse-Rechner am besten?

Am einfachsten an einem Mirror-Port (SPAN-Port) deines Switches, der den Traffic des Ziel-Ports auf deinen Rechner spiegelt. Beachte dabei: Unter hoher Last kann ein SPAN-Port selbst Pakete verwerfen, und fehlerhafte Frames gibt er in der Regel nicht weiter. Präziser arbeitet ein Netzwerk-TAP, der physisch in die Leitung eingeschleift wird und den Datenverkehr passiv abgreift. Für den Einbau brauchst du eine kurze Unterbrechung der Leitung – danach beeinflusst er den Netzwerkbetrieb nicht mehr. Welche Platzierung für welches Szenario sinnvoll ist, erkläre ich in meinem Überblick zur strukturierten Netzwerkanalyse mit Wireshark.

5. Wann lohnt sich externe Unterstützung bei der Netzwerkanalyse?

Als Faustregel: Wenn ein Problem trotz interner Analyse länger als ein bis zwei Wochen ungelöst bleibt, mehrere Teams sich gegenseitig die Verantwortung zuschieben oder geschäftskritische Anwendungen betroffen sind. Die Kosten eines externen Analysetages sind fast immer deutlich geringer als die Produktivitätsverluste durch ein wochenlang ungelöstes Performance-Problem – vom internen Aufwand für Trial-and-Error-Maßnahmen ganz zu schweigen. Ob dein Fall dazugehört, lässt sich in einem kostenlosen Erstgespräch meist schnell klären.