DPTCloud
Back to articles
Technology Insight

Maximizing Infrastructure Efficiency: Implementing Caddy v3 as a Reverse Proxy with Layer 4 Multiplexing for Co-located Web and SSH Services on Port 443

June 7, 2026

Introduction to Network Optimization via Port Multiplexing

In modern enterprise networking, security teams frequently implement stringent firewall policies that restrict outbound and inbound traffic to a handful of essential ports. Among these, Port 443 (HTTPS) is almost universally left open to facilitate secure web browsing. However, this strict filtering poses a significant challenge for system administrators and DevOps engineers who require remote administrative access via SSH (typically Port 22) from restricted environments.

Traditionally, overcoming this barrier meant deploying complex VPNs or utilizing cumbersome HTTP tunnels. Layer 4 multiplexing offers a elegant, high-performance alternative. By inspecting incoming packets at the transport layer before the TLS handshake or SSH negotiation fully completes, a multiplexer can intelligently route traffic to the appropriate backend service based on the protocol signatures. With the release of Caddy v3, achieving this level of sophisticated traffic routing has become more accessible and maintainable than ever before.

This technical guide provides a comprehensive, production-ready blueprint for configuring Caddy v3 as both an HTTP(S) reverse proxy and a Layer 4 multiplexer, allowing you to run your corporate website and your secure SSH management gateway simultaneously on Port 443.

---

Understanding the Architecture: How Layer 4 Multiplexing Works

Before diving into the configuration files, it is crucial to understand how Caddy v3 handles traffic under this paradigm. Standard reverse proxies operate at Layer 7 (the Application Layer), meaning they terminate the TLS connection, read the HTTP headers (such as the Host header), and route the request accordingly. This approach fails for non-HTTP traffic like SSH.

Layer 4 multiplexing operates at the Transport Layer (TCP/UDP). It utilizes "protocol sniffing" to inspect the initial bytes of an incoming connection without decrypting the payload.

When a client connects to your server on Port 443, Caddy's Layer 4 module evaluates the connection packet:

  • If the connection matches the SSH handshake signature (which typically begins with an ASCII string like SSH-2.0-...), Caddy transparently forwards the raw TCP stream to your local SSH daemon (Port 22).
  • If the connection matches a TLS client hello (indicating standard HTTPS traffic), Caddy passes the stream to its internal HTTP/TLS processing engine, where certificates are managed and standard Layer 7 reverse proxying occurs.

This design ensures zero performance degradation for web traffic while granting seamless, firewall-resistant SSH access over the exact same IP and port.

---

Prerequisites and Environment Preparation

To successfully implement this architecture, ensure your environment meets the following baseline requirements:

  1. A Linux Server: Ubuntu 22.04 LTS or newer is highly recommended.
  2. Caddy v3 Installed with the Layer 4 App: The standard distribution of Caddy does not always include the non-HTTP Layer 4 features by default. You must use a custom build compiled with the [github.com/caddyserver/l4](https://github.com/caddyserver/l4) plugin. This can be easily obtained via xcaddy or downloaded directly from the official Caddy build server.
  3. A Fully Qualified Domain Name (FQDN): Pointing to your server's public IP address (e.g., example.com).
  4. SSH Daemon Configuration: Ensure your SSH server is running locally and listening on a non-conflicting port, such as the standard Port 22 or a localhost-only binding for enhanced security.
---

Step-by-Step Configuration of Caddy v3

Caddy v3 utilizes a highly structured configuration syntax. To implement Layer 4 multiplexing along with standard HTTPS reverse proxying, we will structure our Caddyfile or JSON configuration to initialize the layer4 app block before standard HTTP processing occurs.

### 1. The Global Block and Layer 4 Setup

Create or open your configuration file (typically /etc/caddy/Caddyfile). We begin by defining the top-level Layer 4 routing logic. Because Caddyfiles focus primarily on HTTP, using native JSON representation or the advanced Caddyfile block structure with the l4 plugin is necessary. Here is the production-grade configuration block:

{
	# Global options can be defined here
	order l4 first
}

# Layer 4 routing block
:443 {
	l4 {
		# Match SSH traffic based on protocol sniffing
		@ssh ssh
		route @ssh {
			forward_remote 127.0.0.1:22
		}

		# Default route: Handle everything else as standard TLS/HTTPS
		route {
			forward_remote 127.0.0.1:8443
		}
	}
}

In this configuration, Caddy listens on external Port 443. The @ssh ssh matcher sniffs the stream. If it detects an SSH client, it forwards the traffic to 127.0.0.1:22. All other traffic is assumed to be HTTPS and is internally passed to a secondary internal port, 8443, where Caddy’s traditional web server application handles it.

### 2. Configuring the Standard Web and Reverse Proxy Block

Now that the Layer 4 multiplexer is handling the initial sort, we configure the local port 8443 to handle standard web traffic, manage automatic Let's Encrypt or ZeroSSL TLS certificates, and act as a reverse proxy for your backend web application.

# Internal HTTPS handler
:8443 {
	tls [email protected]

	# Example Backend Web Application
	reverse_proxy 127.0.0.1:8080 {
		header_up Host {upstream_hostport}
		header_up X-Real-IP {remote_host}
		header_up X-Forwarded-For {remote_host}
		header_up X-Forwarded-Proto https
	}
}

Important Security Consideration: Ensure that your server's host firewall (e.g., UFW or iptables) allows public incoming connections only on Port 443 and Port 80 (for ACME challenge verification). Ports 22, 8443, and 8080 should be locked down to local traffic only to prevent external attackers from bypassing Caddy's multiplexing layer.

---

Testing and Connecting to Your Unified Port

Once you have saved your configuration, validate and restart Caddy to apply the changes:

caddy validate --config /etc/caddy/Caddyfile
systemctl restart caddy
### Connecting via SSH over Port 443

To verify that multiplexing is functioning correctly, attempt to connect to your server using SSH specified to Port 443 from an external machine:

ssh -p 443 [email protected]

If successfully configured, Caddy will recognize the SSH handshake, forward the bytes to Port 22, and you will be prompted for your SSH credentials as normal. Concurrently, navigating to [https://example.com](https://example.com) in any web browser will seamlessly render your web application via the Layer 7 reverse proxy block, fully encrypted with automatic TLS certificates.

---

Conclusion and Operational Best Practices

By leveraging the power of Caddy v3 and its Layer 4 multiplexing capabilities, you successfully eliminate the need for running multiple outward-facing network daemons on distinct ports. This dramatically simplifies your external attack surface while empowering your remote engineering teams to bypass strict, restrictive firewalls effortlessly.

As you transition this setup into production, keep the following operational best practices in mind:

  • Automate Backups: Ensure your Caddyfile and custom binary build scripts are stored in a centralized version control system.
  • Monitor Resource Utilization: Layer 4 multiplexing introduces minimal overhead, but tracking CPU usage during sudden spikes in concurrent connections is highly recommended.
  • Implement Rate Limiting: Use Caddy plugins or fail2ban on your local SSH daemon to protect your single open port against automated brute-force attacks.