Port 443 is both TCP and UDP. Traditionally, port 443 was exclusively a TCP port, used for HTTPS traffic secured by TLS. That changed with the arrival of HTTP/3, which runs over QUIC, a transport protocol built on UDP. Today, a fully modern web server listens on port 443 for TCP connections from older clients and UDP connections from newer ones, often simultaneously. The story of how a single port number ended up straddling two fundamentally different transport protocols is tied to the broader evolution of how encrypted web traffic moves across the internet.
The TCP Side of Port 443
For most of the web’s history, port 443 meant one thing: HTTPS over TCP. When you visit a website that starts with “https://”, your browser opens a TCP connection to the server’s port 443, performs a TLS handshake to establish encryption, and then sends HTTP requests back and forth over that encrypted channel. This has been the standard since the mid-1990s, and it remains the most common use of port 443 today.
TCP provides reliable, ordered delivery. Every packet sent is acknowledged, and if one goes missing, it gets retransmitted before the data stream moves on. This reliability made TCP the natural choice for web traffic, where you need every byte of an HTML page, image, or script to arrive intact. The combination of TCP for transport, TLS for encryption, and HTTP for application-layer communication became the backbone of secure web browsing, and port 443 became synonymous with all three layers working together.
HTTP/1.1 and HTTP/2 both operate this way. HTTP/2 introduced multiplexing, which lets multiple requests and responses share a single TCP connection rather than queuing up one at a time. But underneath, it is still TCP on port 443 with TLS encryption layered on top. The vast majority of encrypted web traffic you encounter still follows this model.
Why UDP Entered the Picture
TCP’s reliability comes with a cost. Because it guarantees ordered delivery, a single lost packet stalls everything behind it until the missing data is retransmitted. This is called head-of-line blocking, and it becomes a real problem on connections with even modest packet loss. HTTP/2’s multiplexing made this worse in a subtle way: if you have five streams sharing one TCP connection and a packet from stream two gets lost, streams one, three, four, and five all have to wait too, even though their data arrived fine.
Engineers at Google began working on a solution in the early 2010s. The result was QUIC, a transport protocol that runs over UDP instead of TCP. UDP itself provides no reliability guarantees; it just fires packets and moves on. But QUIC builds its own reliability, encryption, and flow control on top of UDP, essentially reimplementing the features that matter from TCP while shedding the ones that cause problems. Each stream in a QUIC connection is independent, so a lost packet on one stream does not block the others.
QUIC also bakes TLS 1.3 encryption directly into its handshake. With traditional HTTPS over TCP, you first complete a TCP handshake (one round trip), then a TLS handshake (another round trip or two), before any actual data flows. QUIC combines these steps, often establishing both the transport connection and the encryption in a single round trip. For repeat visitors, it can sometimes resume a connection with zero round trips.
HTTP/3 and QUIC on Port 443
HTTP/3 is the version of HTTP designed specifically to run over QUIC. When people say “port 443 uses UDP,” they are almost always talking about HTTP/3 traffic carried by QUIC. The Internet Engineering Task Force (IETF) standardized QUIC and HTTP/3 in 2021, and adoption has been growing steadily since. QUIC is already widely deployed and is positioned to become the default transport for HTTP/3 traffic.1ACM SIGMETRICS Performance Evaluation Review. Understanding the Modern Internet’s Heterogeneous Congestion Control Landscape
A key design decision was to have HTTP/3 use the same port number, 443, that HTTPS already occupied. This was practical: firewalls and network equipment worldwide already permit traffic on port 443. Choosing a new port would have meant years of waiting for network administrators to open it. By reusing 443, QUIC traffic could flow through most existing network configurations without changes, though it arrives as UDP packets rather than TCP.
The protocol also redesigned how HTTP headers are compressed for transport. QPACK, the header compression scheme for HTTP/3, was built to handle the fact that UDP packets can arrive out of order. It adapts concepts from the earlier HPACK compression used in HTTP/2 but is specifically designed to keep working correctly when delivery order is not guaranteed, balancing compression efficiency against the risk of head-of-line blocking under packet loss.2RFC Editor. QPACK: Header Compression for HTTP/3
How Your Browser Decides Which Protocol to Use
When you type a URL into your browser, the browser does not just guess whether to use TCP or UDP. There is a negotiation process. The first visit to a site almost always starts over TCP, because the browser has no way of knowing whether the server supports HTTP/3 until it asks. During that initial TCP-based response, the server can include an “Alt-Svc” (Alternative Services) header that tells the browser: “Hey, you can also reach me using HTTP/3 over QUIC on the same port.”
The Alt-Svc mechanism uses an identifier called “h3” to signal HTTP/3 availability, which in turn tells the browser that QUIC transport is an option. The browser then attempts a QUIC connection on subsequent requests.3IETF Datatracker. An Alt-Svc Parameter for QUIC Versions If the QUIC connection succeeds, future visits to that site use UDP. If it fails, perhaps because a firewall or middlebox is blocking UDP on port 443, the browser falls back to the TCP connection without the user ever noticing.
This fallback behavior is important. It means that even though port 443 now supports both protocols, the experience is seamless. You do not need to configure anything. Your browser handles the detection, the upgrade attempt, and the fallback silently. From the user’s perspective, the page just loads.
When UDP on Port 443 Gets Blocked
Not every network treats UDP port 443 the same way it treats TCP port 443. Many corporate firewalls, university networks, and public Wi-Fi hotspots have been configured over decades to permit only TCP on port 443, since that was all HTTPS ever used. UDP traffic on that port may be silently dropped or actively blocked. Some middleboxes, the inline devices that inspect, filter, or modify traffic in transit, simply do not know what to do with UDP packets on a port they associate exclusively with TCP-based HTTPS.
This is one reason the fallback mechanism exists. Browser vendors anticipated that QUIC would face resistance on certain networks. In practice, if your browser detects that UDP on port 443 is not getting through, it switches back to TCP within seconds. The page still loads securely; you just do not get the performance benefits of QUIC.
For network administrators, this dual-protocol reality creates new considerations. If you are writing firewall rules, you now need to decide whether to allow UDP traffic on port 443. Blocking it does not break anything for end users, since the TCP fallback handles it gracefully, but it does prevent them from benefiting from HTTP/3’s performance improvements. On the other hand, some organizations block QUIC deliberately because their network inspection tools cannot yet decrypt or analyze UDP-based HTTPS traffic the way they can with TCP-based connections.
Performance Differences Between the Two
The performance gap between HTTP/3 over UDP and HTTP/2 over TCP is most dramatic in challenging network conditions. On a clean, low-latency, low-loss connection like a wired office network, the difference is modest. Where QUIC really shines is on lossy or high-latency links, which describes a lot of real-world mobile and wireless usage.
Research comparing the two protocols has found that HTTP/3 can deliver substantial improvements in degraded conditions. One study found that HTTP/3 showed up to about 80% improvement under extreme packet loss scenarios compared to HTTP/2, and even larger gains in connection migration situations, where a device switches networks mid-session (like moving from Wi-Fi to cellular).4arXiv. Performance Comparison of HTTP/3 and HTTP/2 with Proxy Integration Connection migration is something QUIC handles natively because connections are identified by a connection ID rather than by the source IP address and port. When your phone switches from one network to another, a QUIC connection can survive the transition. A TCP connection cannot; it dies and must be re-established from scratch.
On fast, reliable networks, the story is more nuanced. QUIC’s userspace implementation means the protocol is processed by application code rather than by the operating system’s kernel, where TCP processing has been optimized for decades. This can introduce overhead on high-speed links where TCP is already performing near its ceiling. The advantage of QUIC is not raw throughput on a pristine connection; it is resilience and responsiveness on imperfect ones.
Congestion Control in Userspace
One underappreciated aspect of QUIC running over UDP is that it moves congestion control out of the operating system and into the application. With TCP, the kernel handles congestion control using algorithms like CUBIC or BBR. These are well-tested but updating them requires OS-level changes, which roll out slowly.
QUIC’s congestion control lives in the application layer. Google introduced BBR, a congestion control algorithm that departs from traditional loss-based approaches, and deployed it widely as part of its QUIC implementation.1ACM SIGMETRICS Performance Evaluation Review. Understanding the Modern Internet’s Heterogeneous Congestion Control Landscape Because QUIC runs in userspace, developers can experiment with and deploy new congestion control strategies without waiting for operating system vendors to push updates. This flexibility is one reason the protocol ecosystem is evolving faster than it did in the TCP era.
The flip side is fragmentation. Different QUIC implementations may use different congestion control algorithms, and their behavior on the same network can vary. For most users, this is invisible. But for anyone running infrastructure or debugging performance issues, understanding which QUIC stack a particular server or client uses can matter.
What This Means for Server Operators
If you run a web server, supporting both TCP and UDP on port 443 typically means running a web server or reverse proxy that speaks both HTTP/2 (over TCP with TLS) and HTTP/3 (over QUIC/UDP). Popular web servers like Nginx, Caddy, and LiteSpeed have added HTTP/3 support, though the maturity of these implementations varies. You need to configure your server to listen on port 443 for both TCP and UDP, and to advertise HTTP/3 availability via the Alt-Svc header so that browsers know to try it.
On the infrastructure side, load balancers need to handle UDP traffic on port 443 in addition to TCP. Some older load balancers were designed exclusively for TCP and do not understand QUIC’s connection ID-based routing, which can cause issues when a connection migrates or when traffic needs to be distributed across multiple backend servers. Cloud providers have been adding QUIC-aware load balancing, but it is worth verifying that your particular setup supports it before enabling HTTP/3.
TLS certificate management does not change. QUIC uses TLS 1.3 for its encryption, so the same certificates you use for HTTPS over TCP work for HTTP/3 over UDP. You do not need separate certificates for the two protocols.
Common Misconceptions About Port 443 and Protocols
One widespread confusion is the idea that UDP on port 443 means unencrypted or less secure traffic. This is understandable, because UDP by itself provides no security. But QUIC is encrypted by default, with TLS 1.3 built into the protocol at the transport layer. In fact, QUIC encrypts more of the connection metadata than TCP-based HTTPS does. With traditional HTTPS, the TCP headers and even some TLS handshake parameters are visible to network observers. QUIC encrypts nearly everything beyond the very basic packet header.
Another misconception is that HTTP/3 will replace HTTP/2 overnight. In practice, the coexistence of both protocols on port 443 is likely to persist for years. Not every server supports HTTP/3, not every network allows UDP on port 443, and not every client implements QUIC. The dual-protocol setup on port 443 is the transitional architecture, and transitions on the internet move slowly.
A third point of confusion involves DNS. Some people conflate DNS-over-HTTPS (DoH) with HTTP/3, since both involve encrypted traffic on port 443. DoH sends DNS queries inside regular HTTPS requests; it can use either HTTP/2 over TCP or HTTP/3 over UDP, but it is a separate concern from whether your regular web browsing uses TCP or UDP on port 443. The protocol choice for DoH follows the same negotiation logic as any other HTTPS connection.
How to Check Which Protocol You Are Using
If you are curious whether your connection to a given site is using TCP or UDP on port 443, most modern browsers make it possible to find out. In Chrome, you can open Developer Tools (F12), go to the Network tab, and look at the “Protocol” column. If it says “h3,” you are using HTTP/3 over QUIC (UDP). If it says “h2,” you are on HTTP/2 over TCP. Firefox has a similar display in its network inspector.
On the server side, tools like “ss” or “netstat” on Linux can show you listening sockets. If your server is configured for HTTP/3, you will see it listening on both TCP and UDP port 443. Packet capture tools like Wireshark have added QUIC dissection support, so you can inspect the actual UDP packets and see the QUIC framing inside them. This is helpful for debugging connection issues or verifying that HTTP/3 is working as expected.
For a quick check without any tools, sites like Cloudflare’s and Google’s homepages are good test cases, since both have supported HTTP/3 for years. If your browser shows “h3” for those sites but “h2” for others, the others either have not enabled HTTP/3 or your connection to them is falling back to TCP for some network-related reason.
Other Protocols That Use Port 443
While HTTPS and HTTP/3 are by far the dominant users of port 443, a handful of other protocols piggyback on this port to take advantage of its near-universal firewall permissiveness. Some VPN protocols, including certain configurations of OpenVPN and WireGuard, can be configured to use port 443 so their traffic blends in with regular HTTPS and is less likely to be blocked. WebSocket connections, which provide full-duplex communication channels between browsers and servers, also typically run over port 443 since they begin life as an HTTP upgrade request.
This shared use occasionally creates headaches for network operators trying to classify traffic. A UDP packet on port 443 could be HTTP/3, a VPN tunnel, or something else entirely. Deep packet inspection tools can sometimes distinguish between these by looking at the initial bytes of the connection, but the increasing prevalence of encryption makes this harder. The trend is moving toward more, not fewer, protocols sharing port 443, precisely because it is the one port that almost every network on earth leaves open.