443
The HTTPS port — and, since HTTP/3, a UDP port as well, so a TCP-only check can tell you nothing is listening while half your traffic is being served.
Run the line for your platform. Each one names the process holding the port and the address it bound to, which is usually the whole answer.
sudo lsof -nP -i :443`-i :443` without a protocol on purpose, so both TCP and UDP sockets appear and you see any HTTP/3 listener as well. `-n` and `-P` keep hosts and ports numeric. The NODE column is the protocol — `TCP` or `UDP` — and TYPE is only the address family (`IPv4` / `IPv6`), so two IPv4 rows can still be one of each. The NAME column carries the bound address — `127.0.0.1:443` serves only this machine while `*:443` serves every interface. TCP rows end in `(LISTEN)`; UDP rows have no state, which is expected. Add `-sTCP:LISTEN` only if you want to exclude established client connections, and remember that doing so also hides UDP entirely. Without `sudo` a root-owned proxy will not show at all.
sudo ss -tulnp 'sport = :443'`-t` and `-u` cover TCP and UDP, `-l` limits it to listening sockets, `-n` keeps ports numeric and `-p` names the owner. Two rows for the same port is the normal shape of an HTTP/3-enabled server, not a conflict. The address column decides everything else: `0.0.0.0:443` is every IPv4 interface, `[::]:443` is the IPv6 wildcard which usually accepts IPv4 as well, and `127.0.0.1:443` explains a site that works over an SSH tunnel and nowhere else. Process names read as `users:(("nginx",pid=1042,fd=8))`; without `sudo` that column is blank for processes you do not own.
sudo netstat -tulnp | grep ':443 'The net-tools equivalent for containers and older images. Same flag meanings, and the PID/Program name column requires superuser privileges for sockets you do not own — its own man page adds that the value is not trustworthy. Keep the trailing space in the pattern: without it `:443` also matches `:4433`, a very common local TLS test port, and `:44300`.
netstat -ano | findstr :443`-a` includes listening TCP and UDP ports, `-n` keeps them numeric and `-o` appends the owning PID, which `tasklist /FI "PID eq 1234"` resolves to a name. A PID of 4 means the kernel HTTP.sys driver holds the port for IIS or another registered application — inspect it with `netsh http show servicestate` rather than trying to kill it. Because `findstr` matches substrings, `:443` also matches `:4433` and `:44300`, so confirm the Local Address ends in exactly `:443`.
`nmap -Pn -p 443 --reason example.com` covers the TCP side: `open` means the handshake completed, `closed` means a reset came back so the host is reachable with nothing listening, and `filtered` means the packet vanished into a firewall. `--reason` prints which of those was actually observed rather than inferred, and `-sV` makes nmap negotiate TLS and report the server and certificate details. For HTTP/3 add a separate `nmap -Pn -sU -p 443 example.com`, and expect `open|filtered` — UDP silence is ambiguous by nature, so nmap declines to guess. When the port is open and something still fails, stop scanning and run `openssl s_client -connect example.com:443 -servername example.com`, which shows the certificate chain, the negotiated protocol version and exactly where a handshake breaks. Scan only hosts you are responsible for.
| What you see | What it means |
|---|---|
curl: (60) SSL certificate problem: unable to get local issuer certificate | The connection and the handshake reached the point of validating the chain, so the port and the network are fine. The server is not sending the intermediate certificate it needs to send. Browsers frequently hide this because they cache intermediates from other sites, which is why it usually surfaces first in an API client or a CI job. Fix the chain the server presents rather than adding a flag to skip verification. |
curl: (60) SSL: no alternative certificate subject name matches target host name 'example.com' | You reached a server on 443 and it answered with a certificate for a different name. Usually SNI: the client did not send the hostname, or the request landed on the default virtual host because that name is not configured. Reproduce it precisely with `openssl s_client -connect <ip>:443 -servername example.com` and compare against the same command without `-servername`. |
curl: (35) error:0A000410:SSL routines::sslv3 alert handshake failure | TCP succeeded, TLS did not. The two sides share no acceptable protocol version or cipher — typically an old client against a server that has disabled TLS 1.0 and 1.1, or a server demanding a client certificate that was not offered. Nothing about the port needs changing; the negotiation parameters do. |
curl: (7) Failed to connect to example.com port 443: Connection refused | A reset came straight back: the host is up and nothing holds port 443. The web server or load balancer is stopped, is listening only on port 80, or is bound to loopback. Run the platform probe on the server and read the bound address before assuming a firewall is involved. |
The browser hangs and finally shows ERR_CONNECTION_TIMED_OUT | Nothing answered, so a filter is dropping the packet rather than refusing it — a cloud security group, a host firewall or a network ACL. The long wait is the signature: refusals are instant. Check the rule set from the direction of the client, since an outbound rule on your side produces exactly the same symptom as a missing inbound rule on theirs. |
listen EADDRINUSE :::443, or EACCES permission denied on 443 | Two different problems with similar-looking messages. EADDRINUSE means another process holds the port — run the probe and read the bound address, since a wildcard listener blocks any specific-address bind. EACCES means the port is privileged: 443 is below 1024, so an unprivileged process is refused before the port's availability is even checked. |
The site loads but HTTP/3 never engages, or QUIC connections stall and fall back | UDP 443 is not reachable even though TCP 443 is. Many firewalls and security groups are written for TCP only, so the browser tries QUIC, waits, and falls back to TCP with a latency cost that looks like an unexplained slowdown. Probe with `-u` on Linux or without a protocol filter on macOS, and allow or block UDP 443 as a deliberate decision. |
IANA registers `https` on port 443 for both TCP and UDP, describing it as "http protocol over TLS/SSL" and citing RFC 9110. The TCP registration is the familiar one: TLS over TCP, carrying HTTP/1.1 or HTTP/2. The UDP registration is what HTTP/3 uses, since QUIC runs over UDP and terminates on the same port number. That has a practical consequence people trip over constantly: a server can be listening on 443 twice, once per transport, and a probe filtered to TCP shows only half the picture. If browsers are getting HTTP/3 and your `ss -tlnp` output looks incomplete, add `-u`. Above the transport, port 443 is where TLS happens (RFC 8446 for TLS 1.3), and the extension that shapes most real-world confusion is SNI (RFC 6066): the client names the host it wants inside the handshake, so one IP address and one port serve many sites with many certificates. That is why a connection can succeed at the network level and still hand you the wrong certificate — you reached the right socket and the wrong virtual host. Encrypted DNS also lives here as DNS over HTTPS, which is deliberate: it is indistinguishable from ordinary web traffic. The best single diagnostic on this port is not a scan but `openssl s_client -connect example.com:443 -servername example.com`, which completes a real handshake and prints the chain the server actually sent.
This is the port you are supposed to expose, so the security question moves up the stack rather than away. Inbound, the risks are what sits behind it: an expired or mismatched certificate, an admin interface published under the same virtual host, a proxy that terminates TLS and forwards plaintext across a network segment you do not fully trust, or an origin server that is separately reachable on port 80 and answers there too. Keep the certificate chain complete — a missing intermediate works in browsers that cache it and fails in every non-browser client, which is a genuinely nasty way to break an API. Outbound is the part most policies get wrong: because 443 is universally allowed, it is the default escape hatch for tunnels, VPNs and SSH-over-TLS, so an egress rule permitting 443 to any destination is effectively permitting everything. Restrict outbound 443 by destination where it matters, and inspect it if your threat model requires it. Finally, allow both TCP and UDP 443 deliberately or block UDP deliberately; leaving UDP 443 half-open produces clients that try HTTP/3, fail, and silently fall back with a latency penalty nobody can explain.
All of these run in your browser — nothing is uploaded.
Ports people usually end up checking in the same session as 443.
Almost always permissions. lsof and ss list the socket but hide the owning process when it belongs to another user, so a server started by a system account, by a container runtime or by launchd shows up as an anonymous listener until you re-run the command with sudo. On Windows the opposite happens: netstat shows nothing at all, yet a bind still fails, which means the port sits inside a range that Hyper-V, WSL2 or Docker Desktop reserved at boot.
Look at what it is first. An orphaned dev server is safe to kill; a database with a write in flight is not, and neither is a system service that something else depends on. If the owner is a container, stop the container instead — killing the process the host sees only makes the runtime restart it. When the process is something you need, moving your own service to another port is the faster fix.
The listener bound to 127.0.0.1 rather than 0.0.0.0. The probes on every page print the bound address next to the process for exactly this reason: a loopback bind is reachable from the machine itself and from nowhere else, no matter how the firewall is configured. Many frameworks made that the default deliberately, so it is usually a flag rather than a bug. If the address is already 0.0.0.0 and it still fails, the next suspect is a host firewall or a cloud security group.
Barely. Internet-wide scanners sweep the whole port range continuously, so an unusual number buys hours, not safety, and it costs you every colleague who now has to remember it. It does cut the noise in your logs from opportunistic scans of the default port, which is a real if modest benefit. Authentication, a firewall that restricts source addresses, and not exposing the service at all are the measures that actually change the outcome.
Still stuck on port 443? browse every port in the reference — or go back to the failure message you actually got, above.