HTTPS Port: 443, How It Works, and Why It Matters

HTTPS port is 443. HTTP is 80. The difference is TLS encryption on top of the HTTP protocol. The team that runs a web server exposes 443 for HTTPS and (optionally) 80 to redirect to 443. The team that exposes only 443 is fine - users will type the URL with https:// and modern browsers default to HTTPS anyway.

Port 443 vs port 80
What runs on 443
The TLS handshake
When to use custom ports
How firewalls handle 443
The HTTP -> HTTPS redirect
FAQ

Port 443 vs port 80

Port 80 is the original HTTP port - unencrypted, plain text. Port 443 is HTTPS - the same HTTP protocol wrapped in TLS encryption. Every modern web server runs both, but the team that runs only 443 has dropped support for unencrypted connections (and is correct to do so).

Sectigo’s guide explains the security angle. Port 80 over plain HTTP is a 2026 anti-pattern.

What runs on 443

Almost all encrypted web traffic. Specific services that run on 443:

HTTPS (web)
HTTPS proxy CONNECT (for forward proxies)
WebSocket Secure (wss://)
HTTP/3 (QUIC) - same port

The team that builds a web app runs 443. The team that runs anything else over TLS uses 443 by default unless there’s a reason to use a custom port.

The TLS handshake

When a client connects to port 443:

TCP handshake (SYN, SYN-ACK, ACK)
TLS handshake: client sends ClientHello with supported cipher suites, server responds with ServerHello + certificate.
Key exchange: client verifies cert, both derive session keys.
HTTP over TLS: encrypted application data flows.

The team that debugs ‘TLS handshake failed’ errors checks cert validity, cipher suite support, and TLS version. The team that uses TLS 1.3 (current default in most clients) has a faster handshake (1-RTT instead of 2-RTT).

When to use custom ports

Common cases for non-443 HTTPS:

Reverse proxy: backend on 8080, 8443 behind nginx/ALB.
Dev environments: 8443 to avoid sudo for low ports.
Internal services: 5443, 7443, etc. to avoid conflicts.

The team that uses 8443 for a dev server has no root requirement. The team that exposes 8443 to the public has an extra step for users - they have to type https://example.com:8443.

How firewalls handle 443

Most corporate firewalls allow outbound 443 by default (HTTPS is essential). Inbound 443 to a public web server is allowed. The team that runs a web server has 443 open. The team that runs an internal-only service uses a non-standard port + VPN or private network.

The HTTP -> HTTPS redirect

On port 80:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Every HTTP request gets a 301 to HTTPS. The team that runs both ports lets old links and bookmarks work; the user is redirected once. The team that only runs 443 has cleaner config but users with old http:// links get a connection error (most browsers auto-upgrade to HTTPS in 2026, so this is rare).

FAQ

Why is HTTPS port 443 and not something else?

IANA assigned port 443 to HTTPS in the late 1990s when SSL/TLS became standard. The number 443 has stuck ever since. The team that wants a custom port uses any unused port above 1024.

Can I run HTTPS on a port other than 443?

Yes. Any port can serve HTTPS - the protocol is determined by the TLS handshake, not the port number. The team that uses 8443 for dev or 4433 for staging is fine; the user has to know the port.

Is port 443 TCP or UDP?

TCP is standard. UDP/443 is used by HTTP/3 (QUIC) - the same port, different transport. The team that runs HTTP/3 listens on UDP 443 alongside TCP 443.

Do I need to open 443 on my firewall?

Yes, for inbound HTTPS. Most firewalls allow outbound 443 by default. The team that runs a public web server opens 443 inbound; internal-only services don’t need to.

What if 443 is blocked on a corporate network?

The team that runs HTTPS on a non-standard port (e.g., 8443) lets users on restricted networks connect. The trade-off: users must specify the port in the URL. The team that uses 443 only accepts that some corporate users cannot reach the service.

If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.

Useful related references: