Self-hosted HTTP Tunnels With SSH And Nginx

TL;DR

Prime Big Deal Days · Oct 6–7Offer from Amazon

Get monitors, keyboards and dev gear delivered free — and shop member deals

• Fast, free delivery on millions of items
• Access to Prime Big Deal Days deals on October 6–7
• Prime Video, Amazon Music and more included

Start your free Prime trial →Free trial for eligible customers · Cancel anytime

As an affiliate, we earn on qualifying purchases.Hide

A technical report by Vincent Bernat explains how to expose a local web service through a self-hosted HTTPS address using OpenSSH reverse forwarding and Nginx. The setup assigns a remote port, routes traffic to it through Nginx, and can add expiring access links; it is a how-to, not a report of a new commercial product or service launch.

Vincent Bernat has published a 2026 technical walkthrough showing how to share a web service running on a local computer through a public HTTPS address, using OpenSSH and Nginx rather than a hosted tunnel provider. The approach combines SSH reverse forwarding with Nginx proxying and optional expiring access links, giving administrators a self-managed alternative for sharing previews and other local web applications.

The connection begins with OpenSSH reverse forwarding: the user asks the remote server to allocate a free port and forward it to a service on the user’s machine. In Bernat’s example, the local application listens on port 8080; SSH requests a remote port by specifying zero, and reports the port the server assigns. Nginx then accepts HTTPS requests for a hostname built from that port and proxies them to the corresponding local port on the server.

To make those addresses work, the operator needs a wildcard DNS record directing the relevant subdomain to the SSH host and a wildcard TLS certificate. Bernat describes using Let’s Encrypt with a DNS-based ACME challenge. These pieces are part of the operator’s infrastructure: the article does not describe a hosted service that readers can use without configuring their own server and domain.

The report also adds link-based access control with Nginx’s secure_link module. A generated URL includes a hash and expiration time in its HTTP Basic Authentication username; Nginx checks the hash against a secret, the requested port and the expiration. Invalid or missing credentials receive a 401 response, while an expired link receives a 410 response. Bernat’s helper script finds forwarded ports associated with SSH sessions, generates the links and keeps the session running.

A Tunnel Without a Hosted Broker

This approach gives technically capable operators a way to share a local preview without routing it through a third-party tunnel provider. That can matter when a reviewer needs temporary access to a work-in-progress site, or when an organization wants control over the public endpoint, DNS and server configuration. The trade-off is responsibility: the operator must maintain the SSH host, Nginx, certificates and DNS, and make choices about who can reach the forwarded service.

The access link adds a time limit and makes the link harder to use without its credential, but it should not be mistaken for a complete identity or authorization system. The report’s configuration uses a shared secret to validate generated links; anyone who obtains a valid link may be able to access the exposed service until it expires. Readers should treat the link as a bearer credential and avoid forwarding it beyond its intended audience.

How the SSH Forward Becomes HTTPS

HTTP tunnels connect a service bound to a local machine with a network address another person can open. Bernat frames the use case as sharing a preview that is available only on localhost:8080. He compares hosted options such as ngrok and Cloudflare Quick Tunnels with self-hostable tools that may require a dedicated client or a particular SSH server, then demonstrates a design based on standard OpenSSH and Nginx.

The components have separate roles. SSH creates the remote forwarding port; DNS maps the wildcard subdomain to the server; Nginx terminates HTTPS and proxies the request; and the local web application answers through the established SSH connection. The helper script addresses a practical inconvenience in the manual method: OpenSSH does not expose its allocated ephemeral port in an environment variable, so the script inspects SSH session processes and listening sockets to find it.

Security Depends on Deployment

The report provides a configuration example, not an independent security audit or a comparative test against hosted tunnel services. It does not establish how the method performs under different traffic loads, how it behaves in every OpenSSH or Nginx deployment, or whether it meets any particular organization’s security requirements. Those outcomes depend on server configuration and maintenance.

Bernat’s example includes a shared secret directly in the Nginx configuration and the link-generation script. Operators would need to protect and manage that secret, use an appropriately strong value, and decide how to revoke access before an expiration time. The report does not describe a separate user-management system, logging policy or automatic revocation mechanism. Its example’s one-day link lifetime is a configuration choice, not a universal default.

Operators Must Test Their Setup

The report does not announce a product launch or a scheduled follow-up. Anyone adopting the method would next need to configure their own SSH server, Nginx virtual host, wildcard DNS and certificate issuance, then test forwarding and access control with the applications they intend to expose. They should also review firewall rules, credential handling, certificate renewal and the server’s logging and update practices.

Further details may come from operators adapting the example to their environments, but no such deployment results are established in the report. The immediate next step is practical validation: confirm that the assigned SSH port maps to the expected hostname, that HTTPS certificates are served correctly, and that valid, invalid and expired links receive the intended responses.

Key Questions

What does the self-hosted tunnel do?

It makes a service running on a local machine reachable through a public HTTPS address. OpenSSH forwards traffic to the server, and Nginx proxies requests from the matching hostname to the forwarded port.

Does this require a commercial tunnel provider?

No. Bernat’s design uses an SSH server and Nginx managed by the operator, along with DNS and a TLS certificate. It still requires a publicly reachable server and operational maintenance.

How does the example restrict access?

It uses Nginx’s secure_link module to validate a hash and expiration time carried in the URL’s Basic Authentication username. The example returns 401 for missing or invalid credentials and 410 for expired links.

Is an expiring link the same as user authentication?

No. The report’s link acts as a bearer credential: someone who obtains a valid link may use it until expiration. It does not describe individual accounts or a separate identity-management system.

What remains for an operator to configure?

The operator must supply the SSH host, Nginx configuration, wildcard DNS, TLS certificate setup and protected signing secret. The report recommends a helper script for finding allocated ports and generating links, but deployments still need testing and ongoing maintenance.

Source: hn