Port 443: what the HTTPS port is for

10 min readUpdated Oct 2026

Port 443 is the standard network port for HTTPS: when an address starts with https:// and names no port, the browser connects to port 443. It sits in the SSL and TLS glossary because what runs on port 443 is TLS.

Registered to: the https service, on TCP and on UDP, in the IANA port registry ^[1]
Default for: https:// addresses that name no port; plain http:// defaults to port 80 ^[2]
Carries: HTTP/1.1 and HTTP/2 over TCP, HTTP/3 over QUIC on UDP ^[3]^[4]
Encrypts: nothing by itself: TLS does the encrypting, whatever the port number

What port 443 is

A port number tells a server which service a connection is for. The IANA port registry assigns 443 to https on both TCP and UDP ^[1], and the https scheme in RFC 9110 §4.2.2 makes TCP port 443 the default when an address gives no port ^[2]. The same default was set out earlier in RFC 2818, HTTP Over TLS, which RFC 9110 obsoletes ^[2]. So the answer to what port HTTPS uses is 443, and the default HTTPS port is the reason a browser never has to be told it.

The number does not do the encrypting. HTTPS, HTTP sent inside a TLS connection, is the protocol; 443 is only where it is expected. A server could run TLS on any port or run something unencrypted on 443. Port 22, registered to SSH ^[1], belongs to a separate protocol with its own encryption; how the two differ is on SSL vs SSH.

HTTPS on another port

HTTPS works on any port; 443 is only the default. Another port has to be written into every address, as in https://example.com:8443/, and a network that lets only ports 80 and 443 out will block it.

Port 443 and port 80

Port 80 is the default for http:// addresses, port 443 for https:// ^[2]. A site that serves HTTPS keeps port 80 open to redirect visitors to the same address on 443, so that an old link or a typed address without https:// still ends up encrypted.

Closing port 80 entirely breaks those first visits; leaving it open without a redirect serves the site unencrypted. Both ports open, with port 80 doing nothing but redirecting, covers both cases. HSTS then removes port 80 from later visits: a browser holding the site's policy rewrites http:// to https:// and an explicit port 80 to 443 before it sends anything (RFC 6797 §8.3) ^[7].

HTTPS port 443 over TCP and UDP

HTTP/1.1 and HTTP/2. Both run over TLS on TCP port 443. HTTP/2 keeps the https scheme and its default port, and the two sides agree on it inside the TLS handshake through ALPN, under the token h2 (RFC 9113 §3) ^[3].
HTTP/3. Runs over QUIC, whose packets travel in UDP datagrams (RFC 9000) ^[4]. A client can open QUIC to the port in the https:// address, 443 when none is given, or to a UDP port the server advertises in an Alt-Svc header with the h3 token (RFC 9114 §3.1) ^[4].
When UDP is blocked. RFC 9114 tells clients to try HTTP over TCP when a QUIC connection cannot be set up ^[4]. A firewall that allows only TCP 443 still lets the site load, over HTTP/2 or HTTP/1.1.
APIs and tunnels. An API at an https:// address uses 443 for the same reason a browser does: it is the scheme's default. A VPN or tunnel on TCP 443 passes a firewall rule that allows TCP 443 out, and looks like HTTPS to anything that reads only port numbers.

TLS ports for mail and other protocols

If you are after the TLS or SSL port of a protocol other than HTTPS, it has its own. Mail, LDAP and FTP have two ways of starting encryption: implicit TLS, where the connection is encrypted from the first byte on a dedicated port, and an upgrade, where the client connects in plain text on the usual port and then switches to TLS. RFC 8314 recommends implicit TLS for mail submission and access ^[5].

TLS ports for mail and other protocols
Protocol	Implicit TLS port	Upgrade on the plain port
HTTPS	443	none
SMTP submission	465	587, STARTTLS
SMTP relay	none	25, STARTTLS
IMAP	993	143, STARTTLS
POP3	995	110, STARTTLS
LDAP	636	389, StartTLS
DNS over TLS	853	none
FTP	990	21, AUTH TLS

Port numbers are from the IANA registry ^[1]; the upgrade commands, and port 853 for DNS over TLS, from the protocol standards ^[5]^[6].

Mail submission, relay and testing

Submission is how a mail client sends; relay is how mail servers pass messages to each other, always on port 25, because MX records have no way to name another port ^[5]. RFC 8314 finds no significant security difference between STARTTLS on 587 and implicit TLS on 465, provided the implementations are correct and both client and server require TLS before any mail is sent ^[5]. When a mail client offers SSL/TLS and STARTTLS, the first is implicit TLS and the second is the upgrade; what those labels mean is on SSL vs TLS. To test, connect directly for implicit TLS, the same way as to port 443, or add -starttls with the protocol ^[8]:

$ openssl s_client -connect mail.example.com:465 -servername mail.example.com
$ openssl s_client -connect mail.example.com:587 -starttls smtp -servername mail.example.com

More commands are on OpenSSL commands.

Port 443 behind a CDN or load balancer

When a site sits behind a CDN or a load balancer, visitors connect to port 443 on the edge, not on the origin server. The edge presents the certificate and terminates TLS there. The connection from the edge to the origin is a separate one, which may use 443 with its own certificate or another port entirely, depending on how the two are set up.

That is why a site can work for visitors over HTTPS while the origin's port 443 is closed, and why opening 443 in the origin's firewall changes nothing a visitor sees when all traffic arrives through the edge. It is also why, for an app that pins the server's certificate, the pin has to match what the edge presents, not the origin's certificate.

How to check whether port 443 is open

From another machine, test the connection and the TLS handshake separately:

$ nc -vz example.com 443
$ openssl s_client -connect example.com:443 -servername example.com
$ curl -vI https://example.com/

Connection refused or timed out. Nothing is listening on 443, or a firewall drops the traffic before it reaches the server.
Connects, but the handshake fails. The port is open, and the problem is TLS: no certificate configured, or the server speaks plain HTTP on 443.
Handshake succeeds, browser still warns. The port is fine; the certificate is the problem. Start from the exact code on SSL errors.

On the server itself, opening the port means two separate things: a firewall rule that allows TCP 443 (and UDP 443 for HTTP/3), and a web server configured to listen there with a certificate.

Common port 443 mistakes

Plain HTTP on port 443. The server answers on 443 without TLS. In our test against a plain HTTP server, openssl s_client (OpenSSL 3.0) stopped with wrong version number, Chrome showed ERR_SSL_PROTOCOL_ERROR, its generic SSL protocol error, and Firefox showed SSL_ERROR_RX_RECORD_TOO_LONG ^[9].
The firewall is open, the cloud rule is not. A host firewall allows 443 while the provider's security group or network rule still blocks it, or the other way round.
Only IPv4 opened. The site has an IPv6 address in DNS, but 443 is open only on IPv4, so visitors on IPv6 networks time out.
TCP open, UDP closed. The site advertises HTTP/3, but UDP 443 is blocked. Pages still load over TCP ^[4], so this one shows up only as HTTP/3 never being used.
A certificate for the wrong name. Port 443 answers with a default certificate because the requested name is not configured; see SNI.

FAQ

What is port 443 used for?

Port 443 is the default port for HTTPS, the encrypted version of HTTP. Browsers connect to it whenever an address starts with https:// and names no other port.

Is port 443 TCP or UDP?

Both. HTTPS over HTTP/1.1 and HTTP/2 uses TCP 443; HTTP/3 runs over QUIC on UDP 443, unless the server advertises another UDP port. IANA registers 443 to https on both.

How do I open port 443?

Allow inbound TCP 443, and UDP 443 if you serve HTTP/3, in the server's firewall and any cloud security group, then configure the web server to listen on 443 with a certificate. Test from another machine with nc or openssl s_client.

Is port 443 always secure?

No. The port number does not encrypt anything; TLS does. Port 443 carries HTTPS by convention, but a server could run anything on it, and an HTTPS site on 443 can still have an invalid certificate.

What is the difference between port 80 and 443?

Port 80 is the default for unencrypted HTTP and port 443 for HTTPS. A site on HTTPS keeps 80 open only to redirect visitors to HTTPS on 443.

What port does SMTP use for SSL?

Port 465 for implicit TLS, where the connection is encrypted from the start, and port 587 for STARTTLS, where it is upgraded after connecting. Both are for sending mail from a client; servers exchange mail on port 25, where TLS starts with STARTTLS.

The protocol on top of the port is covered under TLS, and the browser messages that appear when it fails under SSL errors. The rest of the vocabulary is in this glossary.

Sources

IANA, Service Name and Transport Protocol Port Number Registry: https, http, ssh, submissions, submission, smtp, imaps, imap, pop3s, pop3, ldaps, ldap, domain-s, ftps, ftp.
IETF, RFC 9110, HTTP Semantics, §4.2.1 and §4.2.2; RFC 2818, HTTP Over TLS.
IETF, RFC 9113, HTTP/2, §3.
IETF, RFC 9114, HTTP/3, §3.1; RFC 9000, QUIC.
IETF, RFC 8314, Use of TLS for Email Submission and Access; RFC 6409, Message Submission for Mail; RFC 3207, SMTP Service Extension for Secure SMTP over TLS.
IETF, RFC 4513, LDAP Authentication Methods and Security Mechanisms (StartTLS); RFC 4217, Securing FTP with TLS (AUTH TLS); RFC 7858, DNS over TLS.
IETF, RFC 6797, HTTP Strict Transport Security, §8.3.
OpenSSL, openssl-s_client manual page, option -starttls.
Chromium, net/base/net_error_list.h (SSL_PROTOCOL_ERROR); OpenSSL, crypto/err/openssl.txt (wrong version number); Mozilla NSS, lib/ssl/SSLerrs.h (SSL_ERROR_RX_RECORD_TOO_LONG); a plain HTTP server contacted with OpenSSL 3.0, Chrome and Firefox in our test setup.