In Wireshark, how do you choose the capture interface, and why does traffic to a service on 127.0.0.1 never appear on the Ethernet adapter?
answer
- where the packets actually pass
- welcome-screen activity sparklines
- dumpcap -D numbers every interface
- loopback is delivered inside the OS
- Npcap on Windows
basics
~20 sCapture on the interface the flow really crosses; the welcome screen's activity sparklines and dumpcap -D show which interfaces are live. Traffic to 127.0.0.1 is delivered inside the operating system and never reaches the Ethernet adapter, so capture it on the loopback interface.
solid answer
~50 sWireshark only sees packets that cross the interface you pick, so the first question is where the flow goes. The welcome screen lists every interface with a sparkline of activity, hovering shows its addresses, and `dumpcap -D` (or `tshark -D`) prints the same list with numbers you can pass to `-i`. A request from one process to another on the same host addressed to `127.0.0.1` is handed over inside the network stack and is never queued to the Ethernet driver, so you capture it on the loopback interface: `lo` on Linux, `lo0` on macOS, Npcap's loopback-capture adapter on Windows. On a bond or VLAN host, pick the logical interface that carries the flow. With no `-i` at all, dumpcap takes the first non-loopback interface, which on a multi-homed server is often not the one you meant.
go deeper
Recall that a capture only contains what crossed the chosen interface, that localhost traffic lives on the loopback interface, and how the welcome screen or dumpcap -D shows which interface is live.
Explain how bonds, VLAN sub-interfaces and forwarding hosts change which interface carries a flow, why multi-interface captures are pcapng, and what dumpcap does when no -i is given.
Show the habit of mapping the flow before capturing: on a multi-homed or forwarding host, pick both legs deliberately and treat an empty capture as evidence about the capture point first.
Frame interface choice as part of a capture plan: which hosts and interfaces are standard capture points, who may capture there, and when host capture should give way to mirrored or tapped feeds.
## Why the interface decides what you can see Wireshark does not watch "the network". It reads packets from a **capture source** — a network interface, a pipe, or several interfaces at once — through the capture library (libpcap on Linux and macOS, **Npcap** on Windows) and its privileged helper **dumpcap**. A packet that never crosses the chosen interface cannot appear in the capture, however good your filters are. So the first decision in any capture is not a filter but a location: *which interface does this flow cross on this host?* ## Finding the right interface - The **welcome screen** lists every capture interface with a **sparkline** of current activity. An interface that stays flat while you reproduce the problem is the wrong one. - **Hovering** over an interface shows its IPv4 and IPv6 addresses, which ties a name such as `ens192` to the subnet you expect. - **Capture > Options** shows the same list as a table — interface, traffic, link-layer header, promiscuous mode, snapshot length, buffer, monitor mode and capture filter — each set per interface. - The **Link-layer Header** column is a quick sanity check: Wireshark also lists USB, Bluetooth and other non-network capture sources on most systems, and an interface whose header type is not what you expect (Ethernet on a wired port, for instance) is probably not the one you meant. - On the command line, `dumpcap -D` or `tshark -D` prints a **numbered list**. `-i` accepts the name or the number, which saves typing the long GUID-based names Windows interfaces carry. - With **no `-i`**, dumpcap picks the **first non-loopback interface** in the list, and the loopback one only if nothing else exists. That is convenient on a laptop and frequently wrong on a server with several networks. ## Loopback traffic never reaches the adapter When a client and a server on the same host talk over `127.0.0.1` (or `::1`), the operating system hands each packet from one socket to the other internally. Nothing is queued to the Ethernet driver, so no setting on that adapter — promiscuous mode included — can make it visible. Capture on the loopback interface instead: | Operating system | Where loopback traffic is captured | |---|---| | Linux | the `lo` interface | | macOS | the `lo0` interface | | Windows | the loopback-capture adapter that Npcap provides | The same reasoning often covers a request to the host's *own* external address: many network stacks route it internally too, so if it is missing on the NIC, try loopback before concluding it was never sent. ## Logical interfaces: bonds, VLANs and forwarding hosts - On a **bond** (link aggregation), each member carries only its share of the flows. Capture on the bond interface to see all of them, or on one member only when that physical link is the suspect. - On **VLAN sub-interfaces**, a sub-interface shows only its own VLAN. The parent shows every VLAN, and whether the 802.1Q tag appears depends on the driver and its offload settings. - On a host that **forwards** traffic — a router, a proxy, a VPN gateway — a flow arrives on one interface and leaves on another. Select both; Wireshark writes them into one pcapng file, so you can see whether what arrived was ever sent on. - Traffic between *other* machines on a switched network does not reach your interface at all. Getting it there is a port-mirroring or tap question, not an interface choice. ## Windows in Wireshark 4.6 On Windows, live capture depends on **Npcap**, and the Wireshark 4.6 installers ship Npcap 1.83. Wireshark 4.6 removed support for **WinPcap and AirPcap**, so a machine still relying on WinPcap must move to Npcap (uninstalling WinPcap if necessary) before it can capture. An interface can also be missing from the list because it was hidden in **Manage Interfaces** or is inaccessible to Wireshark. ## A quick checklist 1. Write the flow down: source, destination, and whether both ends are on this host. 2. Same host: use the loopback interface. Different hosts: use the interface whose sparkline moves when you reproduce. 3. Confirm with the hover addresses or `dumpcap -D`, start the capture, and reproduce once more. 4. If the packets still do not appear, the problem is *where* you capture, not *how*: move the capture point rather than tweaking options.
- Why would you capture on two interfaces at once, and what does that require of the output file?When a flow enters on one interface and leaves on another — a router, a reverse proxy, a VPN gateway — capturing both legs shows whether a packet that arrived was ever forwarded, and how long the host held it. Select several interfaces on the welcome screen or in Capture Options, or repeat `-i` for dumpcap. The result is always pcapng, because only pcapng can describe several interfaces, each with its own link-layer type, in one file.
- dumpcap -D on a Windows host prints long names containing GUIDs; how do you pass one to -i reliably?Pass the number dumpcap prints in front of the interface: `-i` accepts either that index or the full name. The numbering reflects the machine's current interface list, so re-run `dumpcap -D` after adapters are added or removed instead of hard-coding an index in a script.
saying these in an interview costs you the question
- Capturing on the Ethernet adapter will show requests sent to localhost.
- Promiscuous mode makes loopback traffic visible on the network card.
- Wireshark captures every interface on the host unless you restrict it.
- Capturing on one member of a bond shows all of the bond's traffic.
- Wireshark 4.6 on Windows can still capture through WinPcap.