“Connections named to their program.” Here’s what that actually means.
A connections list is only useful if you can trust the names in it. Ferrite doesn’t guess which program opened a connection, and it says so when it can’t tell. Two separate mechanisms sit behind the list: one names the program, the other names the protocol.
Where the program name comes from
Ferrite’s background service sees each connection at its first packet. A packet does not say which program sent it, so Ferrite asks Windows. Windows keeps a live table of every TCP and UDP endpoint and the process that owns it (the same table the built-in netstat reads), and Ferrite checks that table every quarter second. The process ID in it is the number Windows itself assigns as the owner, not something inferred from timing, and Ferrite turns it into the program’s executable path.
So a connection appears first and gets its name a moment later. In two live samples on our own PC (25 September 2026), none of 66 new connections carried a name at the instant it appeared; of the 24 that were named, 23 got their name between 0.35 and 3.3 seconds later and one after 12. The rest never did, and those were Windows’ own background lookups (NetBIOS, DNS, DNS-over-TLS). The app waits a few seconds for a name before it logs a row as it is.
When it says “Unknown program”
When Ferrite can’t name the program, the row says Unknown program. It never guesses. That happens when:
- a connection opens and closes between two checks, so it was never in the table;
- the program has already exited, or Windows refuses to say who owns the connection;
- the connection is one of Windows’ own background lookups that carry no owner Ferrite can read.
Two things are left out on purpose: traffic on your own PC’s loopback (a program talking to itself) is not shown by default, and Ferrite’s own programs are left unnamed on purpose, so a “block all” rule can never cut off Ferrite’s own traffic. Traffic from WSL2 and Hyper-V virtual machines is named as the process that relays it.
A row is also “live” only approximately: Ferrite marks a connection closed once it has been idle for five minutes.
Where the protocol name comes from
Ferrite names 100 application protocols (HTTPS, QUIC, SSH, DNS, SMB and more), and it does so on every plan, Free included. Most of those names come from the conventional port (port 443 is HTTPS, port 22 is SSH), which is quick and reads nothing. For a number of others Ferrite also checks the connection’s first bytes, such as a TLS handshake, an HTTP request line or an SSH banner. A name that comes from the port is a convention, not proof of what is inside.
What Pro adds: reading inside
For 30+ of those protocols, Pro’s deep inspection goes further and reads what the connection says in the clear:
- TLS (HTTPS): the server name (SNI), version and ALPN, the JA3 and JA4 fingerprints, and, for TLS 1.2 and older, the certificate’s subject;
- HTTP (unencrypted only): host, method, path, user agent and status, plus the JA4H fingerprint;
- DNS: the name asked for and the answers;
- SSH: the banner; QUIC: the server name and fingerprint from its first packet;
- and more of the same kind for mail, file-transfer, remote-desktop and industrial protocols.
With those fields Pro also lets you write rules on what Ferrite finds (a server name, a fingerprint, a payload pattern). On Free the same fields are not shown and the rule editor does not offer them.
What this does not do: Ferrite does not decrypt your HTTPS. A TLS connection shows its handshake, never its contents. Protocols that are encrypted from the first byte, such as WireGuard, are recognized by the shape of their messages and nothing inside them is read.
Where this leaves you
Knowing which program made a connection, and what protocol it is speaking, is the same on every plan. A name can be late and, rarely, missing, and the list says so. What Pro adds is the reading inside, and the rules on it.