Port 443 is the default TCP port for HTTPS traffic. Every time a browser connects to a website using https:// and you do not specify a port number in the URL, port 443 is where the connection goes. The browser initiates a TCP connection to the server on port 443, completes a TLS handshake to establish encryption, and then sends HTTP requests through that encrypted channel.
That is the simple definition. The more interesting reality is that port 443 has become one of the most strategically important port numbers on the internet, far beyond its original purpose of serving web pages securely. Because blocking port 443 breaks ordinary web browsing, no corporate network, ISP, or national firewall can block it without making the internet unusable. This has made port 443 the default channel for DNS over HTTPS, many VPN implementations, API traffic, and essentially any protocol that needs to traverse firewalls reliably.
This article covers what port 443 is, how HTTPS traffic works through it, how it compares to port 80, which other uses of port 443 matter, and the practical configuration side for servers.
What a Network Port Is and Why 443 Was Assigned to HTTPS
A port number is a 16-bit integer from 0 to 65535 that operating systems use to direct incoming network traffic to the correct application. A server may be running a web server, a database, an SSH daemon, and a mail server simultaneously, all on the same IP address. Port numbers tell the OS which application should handle each incoming connection. An incoming packet for port 22 goes to the SSH daemon. An incoming packet for port 443 goes to the web server.
Port numbers from 0 to 1023 are called well-known ports and are assigned by the Internet Assigned Numbers Authority (IANA). These assignments require IANA approval and are reserved for widely used protocols. Port 443 was formally assigned to HTTPS in RFC 2818 (HTTP over TLS, published in 2000), though HTTPS over port 443 was in practice before this standardization.
Port 80 is the well-known port for plain HTTP. HTTPS on port 443 is essentially HTTP on port 80 but with a TLS handshake first. The separation into two distinct ports reflects the fact that the two protocols differ enough in their connection setup to warrant distinct identifiers, and tools that handle network traffic need to know whether to attempt TLS negotiation.
| Port | Protocol | Encrypted | Default for | What happens on connection |
| 80 | HTTP | No | http:// URLs | Browser sends HTTP request directly; no handshake required |
| 443 | HTTPS | Yes (TLS) | https:// URLs | Browser performs TLS handshake first, then sends HTTP request inside encrypted tunnel |
| 8080 | HTTP alternate | No | Development / proxy | Same as 80; used when 80 is occupied or requires root privileges |
| 8443 | HTTPS alternate | Yes (TLS) | Development / non-root HTTPS | Same as 443; used when 443 is occupied or requires root privileges |
How HTTPS Traffic Flows Through Port 443
Understanding the sequence of a port 443 connection clarifies the relationship between the port, TLS, the SSL certificate, and the HTTP content.
Step 1: TCP connection to port 443
The browser sends a TCP SYN packet to the server’s IP address on destination port 443. The server responds with SYN-ACK. The browser completes the three-way handshake with ACK. A TCP connection exists. No data has been exchanged yet beyond the handshake flags. This step is identical to a connection to port 80 except for the destination port number.
Step 2: TLS handshake
Immediately after the TCP connection is established, the browser sends a TLS ClientHello message. This begins the TLS handshake: the browser and server negotiate a TLS version and cipher suite, the server presents its SSL certificate, the browser validates the certificate chain, and both sides derive session encryption keys. This is the step where the SSL certificate matters. Port 443 does not itself encrypt anything; TLS does. Port 443 is simply the agreed address where this TLS-encrypted HTTP service listens.
Step 3: HTTP over the encrypted channel
Once the TLS handshake completes, the browser sends HTTP requests inside the encrypted TLS records. To any observer watching network traffic, the traffic to port 443 appears as a series of encrypted records. The URL path, the request headers, the cookies, the response body, and all other application-layer content are inside the encryption. The observer can see the server’s IP address, the destination port (443), and the certificate details (including the domain name unless ECH is in use), but nothing from the HTTP layer itself.
Port 443 is not the source of HTTPS security. The TLS protocol and the SSL certificate are. Port 443 is simply the conventional address where the TLS-protected HTTP service lives. You could technically run HTTPS on port 8443 or any other port and it would be equally secure. The reason port 443 matters is convention and firewall rules: all firewalls allow port 443 because blocking it would break normal web browsing.
Port 443 Versus Port 80: The Security Difference
Both ports carry HTTP traffic. The difference is entirely in the presence of TLS.
Traffic on port 80 is plaintext. Any device in the network path, including routers, ISPs, and anyone on the same Wi-Fi network, can read the content of every request and response. This includes login form submissions, search queries, cookies, and any data the page exchanges with the server. HTTP on port 80 was the standard for the entire early web and is still used for non-sensitive content on some sites.
Traffic on port 443 is encrypted end-to-end with TLS. An observer in the network path sees encrypted records. They cannot read the content without the server’s private key. Google has counted HTTPS as a ranking signal since 2014, which accelerated the migration of the web from port 80 to port 443 significantly. As of 2025, over 95 percent of web traffic by volume flows over HTTPS.
Modern best practice is to have port 80 accept connections only to immediately redirect them to port 443, not to serve any content over plain HTTP. The HTTP to HTTPS redirect ensures visitors who type a URL without https:// are upgraded to the secure connection automatically. HSTS (HTTP Strict Transport Security) takes this further by instructing browsers to always connect on port 443 for a domain, refusing to use port 80 even if instructed.
Why Port 443 Is the Internet’s Most Important Port Number
Port 443 has a unique property that no other port number shares: it cannot be blocked without breaking the web. A firewall that blocks port 443 prevents all HTTPS connections, which means no banking, no shopping, no cloud services, no SaaS applications. No corporate network, school network, or national filtering infrastructure can close port 443 without making the internet useless for its users.
This creates a strategic value that the broader internet engineering community has deliberately exploited. If you need a protocol to traverse any firewall in the world reliably, run it over port 443 with TLS. The protocol being carried does not have to be HTTP.
DNS over HTTPS (DoH)
Traditional DNS queries go over UDP port 53, where they are plaintext and can be read, logged, and blocked by network observers. DNS over HTTPS sends DNS queries as HTTP requests over a TLS connection on port 443 to a DNS resolver. The queries are encrypted and look like ordinary HTTPS web traffic. Cloudflare’s 1.1.1.1 and Google’s 8.8.8.8 both operate DoH resolvers on port 443. ISPs and network administrators cannot distinguish DoH traffic from regular HTTPS without deep packet inspection.
VPNs tunneling over port 443
Many VPN services offer port 443 as a connection option specifically because it evades firewall restrictions. A corporate firewall may block all VPN-specific ports (OpenVPN’s default port 1194, WireGuard’s default port 51820) but cannot block port 443. The VPN traffic wrapped in TLS on port 443 is indistinguishable from ordinary HTTPS to a firewall performing only port-level inspection. This is how VPNs remain functional in restrictive network environments.
QUIC and HTTP/3 falling back to port 443
HTTP/3 runs over QUIC, which uses UDP rather than TCP. The default port for HTTP/3 is also 443 but over UDP instead of TCP. When a browser attempts an HTTP/3 connection on UDP port 443 and it is blocked or the network does not support UDP, the connection falls back to TCP port 443 for HTTP/2 or HTTP/1.1 over TLS. This fallback behavior means HTTP/3’s adoption has been relatively smooth: users on networks that block UDP simply use the TCP fallback transparently.
APIs and non-browser HTTPS traffic
REST APIs, webhook endpoints, payment gateway callbacks, cloud service APIs, and any other application-to-application communication over HTTPS all use port 443. The port is not just for browser-to-server communication. Any system that makes HTTPS requests uses port 443 by default. This means port 443 carries a substantial portion of total internet traffic that has nothing to do with web browsers.
Port 443 and SSL Certificates: The Relationship
SSL certificates are not bound to port numbers. A certificate issued for yourdomain.com will work whether HTTPS runs on port 443, port 8443, or any other port. The certificate validates the server’s identity based on the domain name, not on which port the connection arrived at.
That said, port 443 and SSL certificates are tightly coupled in practice because port 443 is where the TLS connection is established and the certificate is presented. If port 443 is closed on a server, no visitor can complete a TLS handshake to that server’s default HTTPS address, and the certificate is effectively unused from the visitor’s perspective.
SNI (Server Name Indication) works on port 443 to allow multiple SSL certificates on the same IP address. A server listening on port 443 can serve different certificates to different visitors based on the domain name sent in the TLS ClientHello. This is how shared hosting providers, CDNs, and multi-domain servers handle HTTPS for many domains on a single IP without needing a dedicated IP per certificate.
Configuring a Web Server to Listen on Port 443
A server does not automatically serve HTTPS just because it has an SSL certificate installed. The web server software must be configured to listen on port 443 and to use the certificate. The firewall must allow inbound connections on port 443. Both conditions must be met for HTTPS to be accessible.
Nginx configuration
The listen directive in an Nginx server block specifies the port. For HTTPS, the block should listen on port 443 with the ssl parameter and reference the certificate files.
| # /etc/nginx/sites-available/yourdomain.com
server { listen 443 ssl; listen [::]:443 ssl; server_name yourdomain.com www.yourdomain.com;
ssl_certificate    /etc/ssl/certs/yourdomain.com.fullchain.crt; ssl_certificate_key /etc/ssl/private/yourdomain.com.key; ssl_protocols      TLSv1.2 TLSv1.3;
# HTTP to HTTPS redirect (in a separate server block for port 80): # listen 80; # return 301 https://$host$request_uri; } |
Apache configuration
Apache uses a VirtualHost block with port 443 specified. The SSLEngine directive activates TLS for that virtual host.
In Apache configuration: VirtualHost *:443 with SSLEngine on, SSLCertificateFile pointing to the full chain file, and SSLCertificateKeyFile pointing to the private key. Apache 2.4.8 and later can use a single SSLCertificateFile containing both the certificate and the intermediate certificate concatenated together.
Verifying port 443 is open and accessible
After configuring the web server, confirm the port is reachable from outside the server. From any external machine: run the command nc -zv yourdomain.com 443 on Linux or Mac, or telnet yourdomain.com 443 on Windows. A successful connection confirms port 443 is open and the server is accepting connections. For a full TLS validation, run openssl s_client -connect yourdomain.com:443 which also shows the certificate the server presents.
Firewall rules for port 443
On Linux servers using UFW: run sudo ufw allow 443/tcp. Using iptables: run sudo iptables -A INPUT -p tcp –dport 443 -j ACCEPT. On cloud providers (AWS, Google Cloud, Azure), the equivalent is adding an inbound rule for TCP port 443 in the security group or firewall rule set for the instance. Without this rule, the server process may be listening on port 443 but external connections cannot reach it.
Port 443 Is Open but That Does Not Mean It Is Secure
A common misunderstanding: opening port 443 and installing an SSL certificate does not automatically mean the server is secure. Port 443 is the channel; TLS is the encryption; the certificate is the identity. All three must be correctly configured.
A server on port 443 with TLS 1.0 enabled and RC4 cipher suites is technically running HTTPS but is vulnerable to known attacks against those deprecated configurations. A server with an expired certificate exposes visitors to identity verification failure. A server with an incomplete certificate chain causes connection errors in tools that do strict chain validation. A server with a misconfigured HTTP to HTTPS redirect leaks the first request over plain HTTP before the redirect fires.
The SSL Labs test at ssllabs.com/ssltest evaluates the complete configuration of a port 443 endpoint: certificate validity, chain completeness, TLS versions and cipher suites, HSTS header, and OCSP stapling. An A+ grade means the port 443 configuration is correctly hardened. Anything below A warrants investigation of the specific issues the report identifies.
Frequently Asked Questions
What is port 443 and what is it used for?
Port 443 is the default TCP port for HTTPS traffic. When a browser connects to a website using https:// without specifying a port number, it connects to port 443 on the server. The browser performs a TLS handshake on port 443 to establish an encrypted connection, verifies the server’s SSL certificate, and then sends HTTP requests inside the encrypted channel. Port 443 is also used for DNS over HTTPS, VPN connections that need to traverse firewalls, API traffic, and any other application that runs over HTTPS.
What is the difference between port 443 and port 80?
Both carry HTTP traffic between browsers and web servers. Port 80 carries plain HTTP with no encryption. Anyone in the network path can read the content of port 80 traffic. Port 443 carries HTTPS: HTTP wrapped in TLS encryption. The content of port 443 traffic is encrypted and cannot be read by observers in the network path. Modern websites use port 80 only for redirecting visitors to port 443, not for serving content.
Why can’t port 443 be blocked?
It can be blocked technically, but blocking it makes the web unusable. Port 443 is the default port for HTTPS, which means blocking it prevents all encrypted web browsing. Banks, email services, cloud applications, and essentially all modern web services use HTTPS on port 443. No corporate network, school network, or ISP can block port 443 without making their users unable to use the internet productively. This is why VPNs and DNS over HTTPS both use port 443 as a reliable fallback: the port will be open on virtually any network.
Does an SSL certificate need to be on port 443?
No. An SSL certificate is associated with a domain name, not a port number. You can run HTTPS on port 8443, port 10443, or any other port and use the same certificate. The certificate validates the server’s identity based on the domain name in the TLS connection regardless of which port the connection uses. Port 443 is where HTTPS conventionally runs because it is the IANA-assigned default, but the certificate itself has no port binding.
What is port 8443 and when should I use it?
Port 8443 is the common alternative to port 443 for HTTPS. It is typically used when port 443 is already occupied by another process, when running a development server without root privileges (ports below 1024 require root on Linux, while 8443 does not), or for a secondary HTTPS endpoint on a server that is already serving a primary application on 443. Browsers do not connect to port 8443 by default; users must specify it explicitly in the URL as https://yourdomain.com:8443. HTTPS on port 8443 is as secure as HTTPS on port 443; the security comes from TLS, not from the port number.
How do I check if port 443 is open on my server?
From any external computer, run nc -zv yourdomain.com 443 on Linux or Mac, or use telnet yourdomain.com 443 on Windows. If the connection establishes, port 443 is reachable. For a more detailed check that also validates the TLS configuration and certificate, run openssl s_client -connect yourdomain.com:443 which shows the certificate chain and the negotiated TLS version and cipher suite. The SSL Labs test at ssllabs.com/ssltest provides a comprehensive web-based check including security grade and specific configuration recommendations.
What happens if port 443 is blocked on my server?
Visitors cannot establish HTTPS connections to the server. Their browsers will show a connection error, typically ERR_CONNECTION_REFUSED or ERR_CONNECTION_TIMED_OUT, not an SSL certificate error. The certificate is never seen because the TLS handshake cannot start without a TCP connection to port 443. If you have installed an SSL certificate but the site is not loading over HTTPS, check whether port 443 is open in both the server’s software firewall (UFW, iptables, or Windows Defender Firewall) and any network-level firewall or security group rules from your hosting provider or cloud platform.
