One Port Number, Two Owners

Start with the socket, not the number

443 is not one resource. The kernel keeps separate TCP and UDP socket spaces, so one process can own 443/tcp while another owns 443/udp. This is normal: an HTTPS server may listen on TCP while a QUIC-based service uses UDP on the same numeric port.

The useful inventory entry is not "443 is open." It is closer to "TCP 443, IPv4 and IPv6 wildcard, owned by the web server" or "UDP 443, IPv6 wildcard, owned by a transport daemon." That wording is specific enough to review and reproduce.

sudo ss -H -lntp 'sport = :443'
sudo ss -H -lnup 'sport = :443'

TCP listeners have a LISTEN state. UDP sockets do not. An empty TCP query says nothing about UDP, and vice versa.

Record the bind address and family

127.0.0.1:443, 0.0.0.0:443, and [::]:443 have different exposure. A loopback listener is reachable only on the host. A wildcard listener may be reachable from the network, subject to firewall and routing rules.

On Linux, an IPv6 wildcard may also accept IPv4 traffic depending on net.ipv6.bindv6only and the application's socket options.

sysctl net.ipv6.bindv6only
sudo lsof -nP -iTCP:443 -sTCP:LISTEN
sudo lsof -nP -iUDP:443

Do not infer ownership from a configuration file alone. Check the live socket after every reload or restart.

Firewalls match the transport too

A rule allowing tcp dport 443 does not allow UDP. With nftables, state the protocol explicitly.

tcp dport 443 ct state new accept
udp dport 443 ct state new accept

sudo nft -a list chain inet host_firewall input
sudo nft -c -f /etc/nftables.conf

The first command shows runtime rules. The second checks the saved ruleset. Both matter: a valid file may not match the live kernel state, and a live rule disappears after reboot if it was never persisted. Provider firewalls and security groups form another layer.

Test with the protocol that owns the port

A TCP connect test is decisive for a TCP listener. UDP has no connection handshake, so a generic probe often returns open|filtered. Use the real client protocol and capture traffic when the result is unclear.

nc -vz example.net 443
sudo tcpdump -ni any 'tcp port 443 or udp port 443'

For UDP, confirm three events: the request reaches the host, the service receives it, and a valid response leaves. A packet capture plus the application log usually settles the question faster than repeated port scans.

Change checklist

Name the port as number/transport.
Record IPv4, IPv6, bind address, and owning process.
Check the live socket and the saved service configuration.
Review host and provider firewall rules separately.
Run an application-level test from an external network.
Repeat listener and firewall checks after reboot.