February 14, 2026

Wireshark-Tutorial: HTTP, DNS, TCP-Handshake identifizieren

Dieses Wireshark-Tutorial zeigt Ihnen praxisnah, wie Sie in einem Mitschnitt zuverlässig HTTP, DNS und den TCP-Handshake identifizieren. Wireshark ist dabei mehr als ein „Paket-Viewer“: Mit den richtigen Filtern, etwas Struktur und einem klaren Blick auf typische Muster erkennen Sie in wenigen Minuten, ob eine Verbindung überhaupt zustande kommt, ob die Namensauflösung funktioniert und ob eine Web-Anfrage korrekt beantwortet wird. Gerade für Einsteiger wirkt ein Capture zunächst unübersichtlich, weil in modernen Netzwerken ständig Hintergrundverkehr läuft. In der Praxis reicht jedoch oft ein kleines Set an Vorgehensweisen: Sie grenzen den Mitschnitt auf die passende Netzwerkkarte ein, filtern nach IPs, Ports oder Protokollen und prüfen dann Schritt für Schritt die Reihenfolge der Ereignisse. Genau das lernen Sie hier: Wie sieht ein TCP-Verbindungsaufbau in Wireshark aus, woran erkennen Sie DNS-Queries und DNS-Responses, und wie unterscheiden Sie HTTP-Requests von HTTP-Responses – inklusive typischer Fehlerbilder wie Timeouts, NXDOMAIN, Retransmissions oder Reset-Paketen. Am Ende können Sie Web-Traffic gezielt „lesen“, ohne im Datenstrom zu ertrinken.

Table of Contents

Vorbereitung: Capture sauber starten, damit die Analyse stimmt

Bevor Sie nach HTTP, DNS oder einem TCP-Handshake suchen, stellen Sie sicher, dass Sie auf dem richtigen Interface mitschneiden. Auf vielen Systemen existieren mehrere Adapter: WLAN, Ethernet, VPN, virtuelle Interfaces oder Container-Netze. Der häufigste Anfängerfehler ist ein Capture auf dem falschen Adapter – die Folge ist ein scheinbar „leerer“ Mitschnitt oder Traffic, der nicht zum Problem passt.

Richtiges Interface wählen: Dort, wo der relevante Traffic wirklich fließt (z. B. WLAN-Adapter statt „Loopback“).
Capture Filter sparsam einsetzen: Wenn Sie unsicher sind, lieber ohne Capture Filter starten und später mit Display Filtern eingrenzen.
Namensauflösung in Wireshark: Bei Performanceproblemen kann die Anzeige von Hostnamen das Tool verlangsamen; bei Bedarf deaktivieren.
Kurze, gezielte Captures: Starten, Aktion ausführen (z. B. Website öffnen), Stoppen. So bleibt der Mitschnitt übersichtlich.

Eine gute Einstiegsquelle ist der Wireshark User’s Guide, insbesondere die Abschnitte zu Capture-Optionen und Filterlogik.

Wireshark-Oberfläche verstehen: Wo Sie HTTP, DNS und TCP finden

Wireshark teilt die Ansicht typischerweise in drei Bereiche. Wenn Sie diese drei Paneele bewusst nutzen, finden Sie Protokolle deutlich schneller.

Packet List: Oben sehen Sie alle Frames/Pakete als Liste. Spalten wie „Protocol“ und „Info“ liefern erste Hinweise.
Packet Details: In der Mitte finden Sie den Protokollbaum (z. B. Ethernet, IP, TCP, DNS, HTTP).
Packet Bytes: Unten stehen Rohdaten in Hex/ASCII – nützlich, wenn Sie Felder im Detail nachvollziehen möchten.

Wichtig: Wireshark ordnet Protokolle nicht „nach Lehrbuch“, sondern dekodiert die tatsächliche Kette. Für Webzugriffe ist das häufig Ethernet → IP → TCP → TLS/HTTP. DNS läuft meist über UDP (Port 53), manchmal über TCP (z. B. bei großen Antworten oder Zone-Transfers).

Die schnellste Methode: Mit Display Filtern gezielt eingrenzen

In einem realen Netzwerk ist der Capture voll mit Hintergrundverkehr. Der Display Filter ist Ihr Hauptwerkzeug, um nur das zu sehen, was Sie interessiert. Nutzen Sie ihn wie eine Suchmaschine für Pakete.

DNS anzeigen: dns
HTTP anzeigen: http
TCP-Verkehr anzeigen: tcp
Traffic zu einer IP: ip.addr == 203.0.113.10
Traffic zu einem Port: tcp.port == 443 oder udp.port == 53

Die offizielle Referenz für Display Filter ist sehr hilfreich, wenn Sie gezielter werden möchten: Wireshark Display Filter Reference.

TCP-Handshake identifizieren: SYN, SYN/ACK, ACK sicher erkennen

Der TCP-Handshake ist die Grundlage für viele Diagnosen. Wenn er nicht klappt, ist HTTP meistens „Folgefehler“. Ein normaler Handshake besteht aus drei Schritten:

SYN: Client startet die Verbindung zum Server.
SYN/ACK: Server bestätigt und bietet die Verbindung an.
ACK: Client bestätigt – die Verbindung ist etabliert.

Praktische Filter für Handshake-Pakete

Nur SYN (Verbindungsstart): tcp.flags.syn == 1 and tcp.flags.ack == 0
SYN/ACK (Serverantwort): tcp.flags.syn == 1 and tcp.flags.ack == 1
ACK-Pakete (allgemein): tcp.flags.ack == 1

Handshake-Fehlerbilder, die Sie sofort erkennen können

SYN ohne SYN/ACK: häufig Firewall-Block, falsche Ziel-IP, Routingproblem oder Server down.
SYN/ACK kommt, aber kein abschließendes ACK: Rückwegproblem, Client-Firewall, Paketverlust oder lokale Störung.
RST (Reset): Verbindung wird aktiv abgelehnt, z. B. Port geschlossen oder Security-Policy greift.

Für RST-Pakete nutzen Sie den Filter tcp.flags.reset == 1. Wenn Sie zusätzlich Retransmissions sehen (tcp.analysis.retransmission), deutet das auf Paketverlust, Überlast oder Funkprobleme (WLAN) hin.

DNS identifizieren: Queries, Responses und typische Fehlercodes

DNS ist der „Startschuss“ vieler Webzugriffe: Erst wenn ein Domainname in eine IP-Adresse aufgelöst wurde, kann ein TCP-Handshake zum Ziel aufgebaut werden. In Wireshark erkennen Sie DNS am einfachsten mit dem Filter dns. Anschließend prüfen Sie pro DNS-Transaktion, ob eine passende Antwort kommt.

Wichtige DNS-Felder im Packet Details-Baum

Queries: Welcher Name wird abgefragt (Query Name)?
Record-Typ: A (IPv4), AAAA (IPv6), CNAME (Alias), MX (Mail), TXT (Text).
Response Code: NOERROR, NXDOMAIN, SERVFAIL.
Answers: Welche IPs oder Aliase werden geliefert?
Transaction ID: Hilft beim Zuordnen von Query und Response.

DNS-Fehlerbilder, die Sie in Wireshark schnell diagnostizieren

Keine Response: DNS-Server nicht erreichbar, Firewall blockt UDP/53, falscher DNS-Server, Paketverlust.
NXDOMAIN: Domain existiert nicht oder Tippfehler, falsche Suchdomäne, Split-DNS falsch konfiguriert.
SERVFAIL: DNS-Server hat intern ein Problem oder kann nicht rekursiv auflösen (Upstream-DNS/Resolver-Probleme).

Wenn Sie DNS-Verkehr nur für einen Hostnamen sehen möchten, können Sie im Filter nach dem Namen suchen, zum Beispiel: dns.qry.name contains “example.com”. Das ist besonders hilfreich, wenn viele Geräte parallel DNS nutzen.

HTTP identifizieren: Request, Response und Statuscodes verstehen

HTTP ist auf Port 80 unverschlüsselt und daher in Wireshark direkt lesbar. Sie erkennen HTTP-Pakete am Filter http oder häufig schon in der „Protocol“-Spalte. Öffnen Sie dann im Detailbereich den HTTP-Block und achten Sie auf Method, Host, URI und Statuscodes.

HTTP-Requests erkennen

Methoden: GET, POST, PUT, DELETE, HEAD.
Host-Header: Der angefragte Hostname (bei virtuellen Hosts entscheidend).
Pfad/URI: Welche Ressource wird angefordert (z. B. /login, /api/v1)?
Header: User-Agent, Accept, Content-Type, Authorization.

HTTP-Responses erkennen

Statuscodes: 200 (OK), 301/302 (Redirect), 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), 500 (Server Error).
Content-Type: z. B. text/html, application/json.
Content-Length: Größe der Antwort (hilfreich bei Abbrüchen).

Wichtiger Hinweis zu HTTPS

Viele Webseiten verwenden HTTPS (Port 443). Dann sehen Sie ohne Entschlüsselung in der Regel keinen HTTP-Inhalt, sondern TLS. In einem reinen HTTPS-Capture erkennen Sie zwar den TCP-Handshake und den TLS-Handshake, aber nicht die HTTP-Header. Für Labor- oder Debug-Szenarien ist eine kontrollierte TLS-Entschlüsselung möglich (z. B. via Key Log File), allerdings nur mit entsprechender Berechtigung und unter Einhaltung von Datenschutz- und Sicherheitsvorgaben. Hilfestellungen dazu finden Sie in der Wireshark-Dokumentation.

Ein praxisnaher Ablauf: Von DNS zu TCP zu HTTP in der richtigen Reihenfolge

Wenn Sie eine Website öffnen und den Ablauf nachvollziehen möchten, hat sich diese Reihenfolge bewährt. Sie verhindert, dass Sie sich in Details verlieren, obwohl die Ursache weiter unten liegt.

DNS prüfen: Gibt es eine Query und eine Response? Stimmt die IP-Adresse?
TCP-Handshake prüfen: Sehen Sie SYN → SYN/ACK → ACK zur Ziel-IP und zum Zielport?
HTTP prüfen: Sehen Sie einen Request und eine Response? Welcher Statuscode kommt zurück?

In Wireshark können Sie diesen Ablauf besonders schnell prüfen, wenn Sie die Display Filter nacheinander anwenden: zuerst dns, dann tcp.flags.syn == 1 (oder tcp) und schließlich http.

Konkretes Beispiel: „Webseite lädt nicht“ in 3 Minuten eingrenzen

Angenommen, ein Nutzer meldet: „Die Seite öffnet nicht.“ Sie starten einen kurzen Capture und führen den Seitenaufruf einmal durch. Danach gehen Sie so vor:

Schritt 1: Filter dns setzen. Sehen Sie eine Query für die Domain? Kommt eine Response mit NOERROR?
Schritt 2: Aus der DNS-Response die Ziel-IP notieren und Filter ip.addr == x.x.x.x anwenden.
Schritt 3: Filter tcp.flags.syn == 1 ergänzen oder gezielt tcp.port == 443 bzw. tcp.port == 80 prüfen.
Schritt 4: Wenn Handshake ok: Bei HTTP (Port 80) Filter http nutzen und Statuscodes prüfen.
Schritt 5: Bei HTTPS (Port 443) auf TLS-Handshake und Timing achten (ClientHello/ServerHello, Zertifikat, Alerts).

So erkennen Sie sehr schnell, ob die Ursache in DNS, Transport oder Anwendung liegt.

„Follow Stream“ richtig nutzen: HTTP-Sitzungen nachvollziehen

Bei unverschlüsseltem HTTP ist „Follow TCP Stream“ eine der effektivsten Funktionen, um den gesamten Request-Response-Dialog in einem Fenster zu sehen. Klicken Sie dazu ein HTTP-Paket an, dann:

Rechtsklick → Follow → TCP Stream

Wireshark zeigt Ihnen dann den kompletten Datenstrom (Client/Server farblich getrennt). Das ist ideal, um Redirect-Ketten, Header oder Fehlermeldungen im Body zu prüfen. Bei HTTPS ist diese Funktion ohne Entschlüsselung meist nur begrenzt hilfreich, weil die Payload verschlüsselt ist.

Timing verstehen: Handshake- und DNS-Latenzen sauber interpretieren

Viele Probleme sind nicht „komplett kaputt“, sondern „zu langsam“. Wireshark bietet Zeitstempel pro Paket. Besonders nützlich sind die Differenzen zwischen DNS Query und DNS Response sowie zwischen TCP SYN und SYN/ACK (als grober RTT-Indikator). Eine einfache Umrechnung, die in der Praxis häufig gebraucht wird, ist Sekunden zu Millisekunden:

$t (ms) = t (s) \times 1000$

Wenn Sie also eine Delta-Zeit von 0,180 s sehen, entspricht das 180 ms. Für DNS sind 10–50 ms im lokalen Netz häufig unauffällig, während mehrere hundert Millisekunden oder Timeouts verdächtig sind (abhängig von Umgebung, VPN, Mobilfunk und Resolver-Architektur).

Häufige Stolpersteine in Wireshark und wie Sie sie vermeiden

Wireshark ist sehr präzise, aber Ihr Blick auf die Daten kann durch typische Effekte verfälscht werden. Diese Fallstricke begegnen in der Praxis besonders oft:

Falscher Capture-Punkt: Ein Capture am Client zeigt nur, was dort ankommt. Probleme „dazwischen“ können unsichtbar bleiben, wenn Sie nicht am richtigen Punkt mitschneiden.
Offloading-Effekte: Manche NICs zeigen Checksummen „falsch“ an, obwohl sie on-the-fly korrigiert werden. Prüfen Sie bei Zweifeln Offloading-Einstellungen.
Zu viel Hintergrundtraffic: Nutzen Sie IP-Filter, Port-Filter und Zeitfenster (kurzer Capture), statt im gesamten Datenstrom zu suchen.
HTTPS-Inhalte fehlen: Das ist normal. Konzentrieren Sie sich dann auf DNS, TCP, TLS-Metadaten und Serververhalten.
DNS-Caching: Wenn ein Name bereits im Cache ist, sehen Sie beim zweiten Aufruf eventuell keine DNS-Query. Für Tests Cache bewusst leeren oder neuen Namen verwenden.

Praktische Filter-Sammlung für den Alltag

Diese Filter decken die meisten Einsteiger- und Mittelstufenfälle ab und helfen Ihnen, HTTP, DNS und den TCP-Handshake zielsicher zu identifizieren:

Nur DNS: dns
Nur DNS zu einem Namen: dns.qry.name contains “example.com”
Nur UDP-DNS: udp.port == 53
Nur TCP-Verkehr: tcp
Nur SYN (Handshake-Start): tcp.flags.syn == 1 and tcp.flags.ack == 0
Nur RST (Abbruch): tcp.flags.reset == 1
Retransmissions: tcp.analysis.retransmission
HTTP (Port 80): http or tcp.port == 80
HTTPS (Transportebene): tcp.port == 443
Traffic zu einer IP: ip.addr == 203.0.113.10

Statistiken nutzen: Conversations und Endpoints als Turbo

Wenn Sie nicht wissen, welche Hosts gerade relevant sind, helfen Wireshark-Statistiken enorm. Besonders nützlich sind:

Statistics → Conversations: Zeigt, welche IPs/Ports miteinander sprechen und wie viel Daten fließen.
Statistics → Endpoints: Übersicht über aktive Endpunkte (MAC, IP) im Capture.
Statistics → I/O Graphs: Visualisiert Traffic-Spitzen und Zeitverläufe (gut bei „sporadisch langsam“).

Damit finden Sie oft schneller die relevante Verbindung, als wenn Sie von Hand durch die Packet List scrollen.

Weiterführende Quellen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.