| Port | 443 |
|---|---|
| Transport | TCP and UDP |
| Service | HTTPS — Web over TLS; UDP for HTTP/3 (QUIC) |
| Category | Web / HTTP |
| Range | well-known (0–1023, needs root to bind on Unix) |
| Encrypted | Yes, always (TLS or equivalent) |
| Exposure | Designed to face the internet |
Port 443 HTTPS · TCP and UDP
HTTPS: HTTP over TLS, the port the web runs on. Since HTTP/3, UDP 443 carries QUIC as well, so a firewall that allows only TCP 443 forces browsers to fall back to HTTP/2.
What runs on port 443
HTTPS: HTTP over TLS, the port the web runs on. Since HTTP/3, UDP 443 carries QUIC as well, so a firewall that allows only TCP 443 forces browsers to fall back to HTTP/2. Almost everything else now tunnels over 443 too (APIs, WebSockets, VPNs, DNS over HTTPS), which is why "only 443 is open" rarely means only web traffic.
Software that uses it: nginx · Apache · Caddy · HAProxy · Cloudflare and other CDNs · Traefik · IIS
Should port 443 be open?
Designed to face the internet. This port exists to be reachable from anywhere, so the usual question is not whether to open it but how the service behind it is configured and patched.
- Allow UDP 443 outbound if you want HTTP/3 to work for your users.
- openssl s_client -connect host:443 -servername host shows the certificate chain and the negotiated protocol.
- Test the configuration with our HTTP headers analyzer and SSL certificate decoder.
Check port 443
# on the host: is anything listening, and which process? ss -ltnp 'sport = :443' ss -lunp 'sport = :443' sudo lsof -i :443 # from another machine: is it reachable? nc -zv host 443 nmap -p 443 host nc -zuv host 443 sudo nmap -sU -p 443 host curl -v telnet://host:443 # raw TCP connect test, Ctrl-C to leave
A port that answers from the internet when it should not is the finding; nmap from a machine outside your network (or a VPS) is the honest test, because scans from inside the LAN pass the firewall you are trying to verify.
Allow or block port 443
# ufw (Ubuntu/Debian)
sudo ufw allow from 10.0.0.0/8 to any port 443 proto tcp
sudo ufw allow from 10.0.0.0/8 to any port 443 proto udp
sudo ufw deny 443/tcp
sudo ufw deny 443/udp
# nftables
nft add rule inet filter input ip saddr 10.0.0.0/8 meta l4proto { tcp, udp } th dport 443 accept
nft add rule inet filter input meta l4proto { tcp, udp } th dport 443 drop
# iptables (legacy)
iptables -A INPUT -p tcp --dport 443 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP
iptables -A INPUT -p udp --dport 443 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p udp --dport 443 -j DROP
# firewalld
sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.0.0.0/8 port port=443 protocol=tcp accept' Replace 10.0.0.0/8 with the networks that need access. Allowing by source address is the rule that matters; "allow 443" with no source is just "open".
Putting it behind nginx
server {
listen 443 ssl;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:443;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
} Then make the application listen on 127.0.0.1:443 only. Test which location block a request hits with the nginx location tester.
Related ports
Part of the port number reference. Ports are 16-bit numbers; see also the subnet calculator and the packet decoder, which shows ports inside TCP and UDP headers.
Questions
Is port 443 TCP or UDP?
Both. HTTPS uses TCP and UDP on 443: Web over TLS; UDP for HTTP/3 (QUIC).
Is port 443 encrypted?
Yes, always (TLS or equivalent). The port number does not make it safe by itself: certificate validation, authentication and patching still decide.
How do I check whether port 443 is open?
On the server, ss -ltnp (or -lunp for UDP) shows whether something listens on 443 and which process. From another machine, nc -zv host 443 or nmap -p 443 host tests reachability. "Open" in a scan means something answered; a firewall usually makes the port filtered (no answer) rather than closed (RST).
Can HTTPS run on a different port?
Yes; the number is a convention, not a requirement. Changing it reduces log noise from scanners but does not add security, and every client, firewall rule and monitoring check then needs the new number. Keep the default unless you have a concrete reason.