80 HTTP TCP Flagship

What it's for

Port 80 is the default port for unencrypted HTTP traffic — every time you type a URL without https:// (or a browser silently falls back), the request goes to port 80 unless another port is explicitly specified. It's arguably the single most important port on the internet: the entire web ran on it exclusively for its first two decades.

Today, port 80 is increasingly used only as a stepping stone. Most production sites bind port 80 solely to issue a 301 redirect to the HTTPS version on port 443, rather than serving actual content over it — plaintext HTTP is considered insecure for anything beyond that redirect.

Protocol basics

• Protocol: TCP. HTTP needs reliable, ordered delivery for request/response semantics, so it sits on top of TCP (HTTP/3 is the exception, running over QUIC/UDP instead, but that's a different port story entirely).
• No encryption by default. Anything sent over port 80 — headers, cookies, form data — is visible to anyone who can observe the network path, including ISPs, coffee-shop Wi-Fi operators, and anyone performing a man-in-the-middle attack.
• Stateless request/response. Each HTTP request on port 80 is independent; persistence (login sessions, carts) is layered on top via cookies, not the port or protocol itself.
• Keep-alive connections. Modern HTTP/1.1+ keeps the TCP connection on port 80 open across multiple requests rather than opening a new connection per request, reducing handshake overhead.

Security considerations

• Never send sensitive data over plain port 80. Passwords, session tokens, and personal data should only ever traverse port 443 (HTTPS). If your app still accepts credentials over port 80, that's a real vulnerability, not just a best-practice nitpick.
• Redirect, don't disable. The standard pattern is to keep port 80 open specifically so you can serve a 301 Moved Permanently redirect to https://, rather than closing it entirely — closing it can break clients that haven't upgraded their bookmarks/links yet.
• HSTS (Strict-Transport-Security header) tells browsers to skip port 80 entirely on future visits and go straight to HTTPS, closing the brief window where an attacker could intercept the initial plaintext request.
• Let's Encrypt / ACME challenges commonly use port 80 briefly during certificate issuance (HTTP-01 challenge type) — this is a legitimate, narrow use of the port even on an otherwise HTTPS-only site.

Troubleshooting

Connection refused on port 80:

• No web server (Nginx, Apache, etc.) is running, or it's not configured to listen on port 80
• A firewall or cloud security group is blocking inbound traffic on 80

Site loads over HTTP but not HTTPS (or vice versa):

• Check that both port 80 and 443 are open in your firewall/security group — they're independent rules
• Verify your redirect configuration isn't creating a loop (HTTP → HTTPS → HTTP)

"This site can't provide a secure connection" but HTTP works fine:

• Nothing is listening on port 443 at all, or the TLS certificate is missing/invalid — this is a 443 problem, not a port 80 problem, even though the symptom shows up when a browser tries to upgrade

Works locally, not in production:

• Cloud load balancers or reverse proxies often terminate TLS themselves and forward to your app over plain HTTP internally — a "port 80 works" result inside your infrastructure doesn't mean the public-facing connection is insecure, just that termination happens upstream

Comparison / FAQ

Should I close port 80 entirely and only use HTTPS?

Generally no — keep it open but configured to redirect to HTTPS. Closing it entirely can break older clients, bookmarks, and links that haven't been updated to https://, and it's also needed for Let's Encrypt's HTTP-01 domain validation challenge.

Why do browsers show a "Not Secure" warning for port 80 sites?

Because any data sent over unencrypted HTTP — including form submissions — can be intercepted or modified in transit. Modern browsers flag this explicitly to push the web toward universal HTTPS adoption.

Is port 80 traffic ever legitimately unencrypted in production?

Yes, in two common cases: the redirect-to-HTTPS response itself (which carries no sensitive data), and internal traffic behind a load balancer that already terminated TLS — the "plaintext" hop only exists within a trusted private network.

Can I run a site on port 80 without HTTPS at all in 2026?

Technically yes, but browsers increasingly penalize it (warnings, some features like clipboard access and service workers are disabled on non-HTTPS origins), and it's a poor practice for anything beyond a purely static, non-sensitive test page.