Networking · Comparison · 10 min read

Port 80 and 443, and Why You Still Cannot Close 80

The same protocol on both ports, and a handshake in front of one of them. Here is what that changes, why the old port stays open anyway, and the firewall rule almost everyone gets wrong.

Written by Marko Ristic, Editor Updated Sep 12, 2026
443Where the site lives, over TCP and now UDP as well
80Where the redirect lives, and nothing else should
301The status code the redirect should use, not 302
0Bytes of the request an observer reads on 443
Short answer

Port 80 carries HTTP and port 443 carries HTTPS, which is the same HTTP inside TLS. A connection to 443 completes a handshake and checks a certificate before any request is sent. Port 80 survives to serve a redirect and the certificate renewal challenge, which is why closing it breaks things.

  • Both ports carry HTTP. Only 443 negotiates TLS first
  • The certificate is the half people forget: it proves the name
  • Port 80 still serves the redirect and the ACME challenge
  • HSTS is what stops browsers using port 80 at all
  • Port 443 carries UDP too, because HTTP/3 runs over QUIC
On this page

The differenceWhat actually differs between them

The protocol spoken on both ports is HTTP. A GET request for a web page looks identical either way. Everything that separates port 80 and 443 happens before the request and around it.

On port 80, the request goes out in the clear. The method, the path, the headers, the cookies and the response data all travel as readable text.

Anyone able to see the traffic can read that data, and anyone able to modify it can change it without either end noticing. That is the security problem HTTPS was created to solve, and it is why almost every site on the internet moved.

On port 443, a secure TLS handshake happens first. The client and the web server agree on a cipher, the server presents an SSL certificate signed by an authority the client trusts, and they establish keys. Only then does the HTTP request go, and every byte of data after that point travels inside the secure channel.

The certificate is the half people forget. Encryption without identity would secure a conversation with an attacker just as well as a conversation with your bank. The SSL certificate is what ties the encrypted channel to the name the client asked for, and it is why a certificate error is a hard stop rather than a warning.

Neither port changes what HTTP can do. No feature available over HTTPS is unavailable over HTTP at the protocol level. What changes is who else can read the data in the communication and whether users know which web server they are talking to.

Port 80Port 443
Protocol carriedHTTPHTTP
EncryptedNoYes
Server identity verifiedNoYes
Tamper evidentNoYes
TransportTCPTCP and UDP
Browser address barMarked not secureSecure
Share of internet trafficSmall and shrinkingNearly all of it

Keeping 80 openWhy port 80 cannot simply be closed

The obvious security step is to stop listening on 80 entirely and serve the site over HTTPS only. It is usually the wrong move, for two reasons that have nothing to do with encryption.

The redirect lives there. Type a bare domain into a browser and, unless the site is in the HSTS preload list, the first attempt often goes to port 80. With nothing listening, users get a connection refused rather than your website. Keeping 80 open with a permanent redirect to the secure HTTPS address is what turns that into a working visit.

SSL certificate renewal usually needs it. The most common way to prove control of a domain to a certificate authority is the ACME HTTP challenge, which asks for a file over port 80 at a fixed path.

Close the port and automatic renewal fails, quietly, until the certificate expires and every visitor gets a security warning. The DNS challenge avoids this and is the right answer when port 80 genuinely cannot be open, but it takes deliberate setup.

The correct configuration is not to close port 80 but to make it useless for anything else: listen on it, serve nothing but a redirect to HTTPS and the ACME challenge path, and let HSTS tell browsers not to come back to it.

HSTSHSTS, and how port 80 stops being used

HTTP Strict Transport Security is a response header sent over HTTPS that tells a browser to use the secure port for this domain for a stated period, without asking.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Once a browser has seen that header, it rewrites any http:// address for the domain internally and never opens the insecure port 80 connection at all. The redirect to HTTPS still exists for first time users and for anyone whose browser has forgotten, which is why the port stays open even on a site where almost nobody reaches it.

Two details matter when setting it.

Start with a short max-age. The header cannot be taken back early. A year long policy on a domain whose SSL certificate later breaks locks visitors out of the website for a year.

includeSubDomains covers everything under the name. That includes internal hostnames and anything on a subdomain with no HTTPS of its own, which is the usual way this security setting causes an outage.

Preloading, where the domain is built into the browser rather than learned from a header, removes the first insecure communication entirely. It is also slow to reverse, so it belongs on a domain whose HTTPS is settled.

HTTP/3 and QUICHTTP/3 makes 443 a UDP port too

For most of the web's history, port 443 meant TCP 443 and nothing else. HTTP/3 changed that, and it is the one recent change to how these two ports behave on the network.

HTTP/3 runs over QUIC, which is a transport protocol built on UDP rather than TCP, and it uses the same port number, 443. The browser tries QUIC over UDP 443 and falls back to TCP 443 if the connection does not succeed, so both ports 443 carry the same secure traffic.

The practical consequence is a firewall rule on your network. A firewall rule that permits TCP 443 outbound and says nothing about UDP does not break anything: browsers fall back and the web pages load.

It does mean your users silently lose the newer protocol, and that no HTTP/3 traffic will ever appear in your logs. Permitting UDP 443 alongside TCP is the deliberate choice, and blocking it is also a defensible choice as long as it is a choice.

Firewall policyWhat to allow, and what to check

RuleDirectionWhy
TCP 443OutboundAlmost everything users do on the internet
UDP 443OutboundHTTP/3. Blocking it is silent, so make it a decision
TCP 80OutboundCertificate validation and the services that still need plain HTTP
TCP 443Inbound to your sitesWhere the site is actually served
TCP 80Inbound to your sitesThe redirect and the ACME challenge path, nothing else
UDP 443Inbound to your sitesOnly if you are serving HTTP/3 deliberately

Allow outbound TCP 443 and, deliberately, UDP 443. Both carry HTTPS. Decide about HTTP/3 rather than defaulting into blocking it.

Allow outbound TCP 80. Some services still need plain HTTP, SSL validation among them, and blocking it breaks more than it secures.

Publish inbound 443 for your own sites, with 80 alongside it. Serving an HTTPS redirect and the ACME path is the entire job of the inbound port 80 rule.

Check what the SSL certificate actually covers. A certificate valid for example.com and not www.example.com produces a security error only some visitors see, which is how these run for weeks.

Watch the expiry. Automatic SSL renewal fails silently more often than it fails loudly, and the most common cause is a change that broke the port 80 path the challenge uses.

Do not assume 443 means safe. A certificate proves the name matches. It says nothing about who registered that name or what they do with your data, which is why phishing sites have valid certificates.

PitfallsWhere people go wrong

Closing port 80 as a security measure. It breaks the HTTPS redirect for anyone typing a bare address and usually breaks SSL renewal at the same time.

Serving real web content on port 80. If a page loads over both ports, search engines see duplicates and visitors get an unencrypted version of the site. Port 80 should answer with a redirect and nothing else.

Redirecting to HTTPS with a 302. The move from HTTP to HTTPS is permanent, so the redirect should be a 301. A temporary redirect tells crawlers the arrangement may change.

Setting HSTS with a long max-age immediately. It cannot be shortened for browsers that already have it. Start small and increase.

Assuming a padlock means the site is trustworthy. The SSL certificate authenticates the domain name, not the intentions of whoever owns it or what happens to your data afterward.

Blocking UDP 443 without meaning to. Browsers fall back quietly, so nothing breaks and nobody learns that HTTP/3 has been off for two years.

Forgetting internal services when enabling includeSubDomains. An internal hostname under the same domain with no HTTPS becomes unreachable for every user, and the failure looks like a network problem.

THE SAME REQUEST, SENT TWO WAYSPORT 80, HTTPTCP CONNECTHTTP REQUEST, IN THE CLEARANYONE ON THE PATH READS ALL OF ITThe address, the headers, the cookies and the page body, as readable text.PORT 443, HTTPSTCP CONNECTTLS HANDSHAKE, CERT CHECKONLY THE ADDRESS AND HOST NAME LEAKThe same HTTP request follows, inside the encrypted channel, and reads as noise.Port 80 still listens, and answers with one thing: a 301 to the HTTPS address.Close it entirely and bare addresses stop working, and certificate renewal fails silently.
The difference is a sequence, not a property. Two extra steps happen on 443 before the request that both ports carry identically.

ComparisonThe two ports side by side, and the three rows that settle it

CriterionPort 80Port 443
ProtocolHTTPHTTPS, which is HTTP inside TLS
Traffic readable in transitYesNo
Certificate requiredNoYes
Detects tamperingNoYes
Runs over UDP as wellNoYes, for HTTP/3
Needed for ACME HTTP validationYesNo
Should serve site contentNoYes
Safe to close entirelyNoNothing works without it

Read the last three rows together and the answer to the question people arrive with becomes clear: of the two ports, 443 is where the website and its data live, and 80 is a doorway that has to stay unlocked so visitors and certificate authorities can find the secure one.

FAQFrequently asked questions

What is the difference between port 80 and port 443?

Both carry HTTP. Port 443 negotiates TLS first, so the data is encrypted and the web server has proved its identity with an SSL certificate. Port 80 does neither.

Is port 443 just port 80 with encryption?

Effectively yes, with the addition that matters most: the certificate. Encrypting data without an identity check would secure a conversation with an attacker just as well.

Can I close port 80?

Not usually. Users typing a bare address arrive there first, and the standard ACME HTTP challenge for SSL renewal uses it. Serve an HTTPS redirect on it instead of closing it.

What should port 80 serve?

A permanent redirect to the HTTPS address, and the ACME SSL challenge path. Nothing else.

Why is my site reachable over both HTTP and HTTPS?

Because port 80 is serving content rather than redirecting to HTTPS. Search engines will treat it as a duplicate, and users may stay on the unencrypted version.

Does port 443 use UDP?

Yes, for HTTP/3, which runs over the QUIC protocol. Browsers try UDP 443 and fall back to TCP 443 if it fails, so a firewall blocking that traffic does it silently.

What is HSTS?

A security header sent over HTTPS telling a browser to use HTTPS for the domain from now on. Once it is seen, the browser stops making the insecure port 80 request at all.

Why does my certificate keep expiring?

Almost always because automatic renewal broke, and the most common cause is a change that closed or redirected the port 80 path the ACME challenge needs.

Does HTTPS slow a site down?

Not meaningfully on modern hardware. The handshake costs a round trip, session resumption removes most of that, and HTTP/2 and HTTP/3 both require HTTPS in practice and move data faster than HTTP/1.1 over port 80.

Can I run HTTPS on a different port?

Yes. Port 443 is a convention on the internet, not a requirement, and 8443 is common for management interfaces. Browsers assume 443 unless the address says otherwise.

Does a padlock mean a site is safe?

No. It means the connection is secure and the SSL certificate matches the name in the address bar. It says nothing about what the site does with your data, and phishing sites obtain valid certificates routinely.

Do I still need an HTTPS redirect if I have HSTS?

Yes. A browser that has never visited the site has not seen the security header yet, so the first request can still arrive on port 80.

What port numbers are these, exactly?

Both ports are well known ports, which means they are assigned by IANA and sit in the range that requires privilege to bind to. The port number page covers what that range means.

Read next · Ports What Is a Port Number? These are two well known ports, and that range has rules of its own about who may bind to it. Open this next12 min
Also worth reading
One packet a weekA short, illustrated explainer every Tuesday. No vendor pitches, unsubscribe in one click.