443
Port 443 · HTTPS
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.
Find what is using port 443
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.
- macOS
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.
- Linux
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.
- Linux
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`.
- Windows
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`.
Check it from outside the machine
`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.
Why a connection to 443 fails
| 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. |
What runs on port 443
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.
Should port 443 face the internet?
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.
- Service
- HTTPS
- Transport
- TCP/UDP
- Registry
- IANA assigned
- Category
- Web & HTTP
Tools on this site
All of these run in your browser — nothing is uploaded.
Related ports
Ports people usually end up checking in the same session as 443.