HTTP port guide: web traffic on port 80

HTTP is the request and response protocol used by browsers, APIs, webhooks, health checks, and many internal services. On port 80, the client connects over TCP, sends an HTTP request, and receives headers and a response body without a TLS handshake first.

Because traffic is not encrypted, anyone who can observe the network path may see URLs, cookies, headers, form data, and response content unless the application adds its own protection. For public websites and authenticated applications, port 80 should normally redirect to HTTPS instead of serving private content directly.

Port 80 is plain HTTP. Port 443 is HTTPS, which means HTTP carried inside a TLS-encrypted session. The user experience may look similar in a browser, but the security model is different: HTTPS validates the server certificate and encrypts traffic in transit.

Most production sites use both ports together. Port 80 accepts old links, certificate challenges, and first-time browser requests, then sends a 301 or 308 redirect to the HTTPS URL on 443. After that, HSTS can tell browsers to prefer HTTPS automatically.

Keep port 80 open when you need HTTP-to-HTTPS redirects, Let's Encrypt HTTP-01 challenges, load balancer health checks, CDN origin checks, simple internal status endpoints, or compatibility with older systems that cannot start directly on HTTPS.

Close or restrict port 80 when the service is private, when all clients are controlled and can use HTTPS directly, or when plain HTTP creates unnecessary exposure. If you do keep it open, keep the behavior narrow and predictable: redirect, challenge, or health check rather than full application access.

Before opening TCP 80, confirm that the intended web server, reverse proxy, ingress controller, CDN origin, or load balancer is listening on the correct interface. Decide whether port 80 should serve content, redirect to 443, answer health checks, or respond only to certificate validation paths.

A port checker confirms network reachability, but it does not tell you whether your redirect chain, cache headers, virtual host routing, or certificate automation is correct. Test both the TCP path and the HTTP behavior with a browser, curl, and server logs.

On Windows Server, run IIS, Nginx, Apache, Caddy, or another web server, bind the site to TCP 80, and allow inbound HTTP traffic in Windows Defender Firewall. Cloud servers also need matching cloud firewall or security group rules.

On Linux, configure Nginx, Apache, Caddy, a container port publish, or an ingress controller to listen on 80, then allow TCP 80 in ufw, firewalld, nftables, iptables, or the provider firewall. Containers and Kubernetes services must publish or route the port at the host, load balancer, or ingress layer.

On macOS, port 80 is most often used for local development or lab services. Privileged ports may require elevated permissions, and local firewall or router rules still determine whether other machines can reach the service.

Start with an external port check against the public hostname or IP address and port 80. If the result is open, remote clients can establish a TCP connection. Then run curl -I http://example.com to inspect status codes, redirects, server headers, and cache behavior.

On the server, check listeners with ss -tlnp, netstat, lsof, or PowerShell. For reverse proxies and cloud deployments, compare host firewall rules, cloud security groups, load balancer listeners, container port mappings, and application logs because any layer can block or misroute HTTP.

If port 80 shows closed, the web server may be stopped, listening on localhost only, using a different port, or blocked by the host firewall. If it times out, packets may be dropped by a cloud firewall, router NAT rule, ISP filter, CDN setting, or upstream security policy.

If port 80 is open but the page is wrong, inspect virtual host order, Host header routing, default server blocks, proxy upstreams, container mappings, and DNS records. If redirects loop, compare HTTP and HTTPS virtual hosts and make sure the proxy passes the original scheme correctly.

Use port 80 intentionally. Redirect application traffic to HTTPS, avoid credentials and sensitive data on plain HTTP, and keep only the endpoints that need to remain reachable. For public sites, pair the redirect with valid certificates on 443 and HSTS after you confirm HTTPS is stable.

Log requests to port 80, watch for unexpected paths, and remove legacy endpoints that no longer need plain HTTP. If port 80 is only for ACME or health checks, restrict responses to those paths so the service is easier to reason about and monitor.