HTTP / HTTPS
Private reverse proxy with optional TLS termination at the site edge over the Pangolin tunnel
Private HTTP/HTTPS resources expose web applications over the Pangolin tunnel with a fully qualified domain name. Unlike public HTTP/HTTPS resources, nothing is reachable from the public internet—a user must connect with the Pangolin client first.
Once connected, users open the resource in a normal web browser at a URL like https://my-app.internal.example.com. The Pangolin client resolves the hostname privately, traffic travels over the peer-to-peer tunnel, and the site connector terminates TLS and runs a reverse proxy to the backend.
Benefits
- Web apps get a real hostname on your domain and a valid TLS certificate, so browsers show no certificate warnings.
- Users browse on the default port with a clean URL, with no port numbers or IP addresses to remember.
- Nothing is reachable from the public internet. The hostname only resolves for connected clients with access.
- Identity comes from the client connection, so users don't see an extra login page in front of the app.
- Traffic travels peer-to-peer from the client to the site, and TLS terminates at the site, close to the app.
Use Cases
- Publish internal tools such as wikis, Grafana, or admin panels only to employees on the Pangolin client.
- Serve a self-hosted app over HTTPS when it only speaks plain HTTP on the local network.
- Replace a public resource for sensitive apps that should never have a public login page.
- Give contractors browser access to a staging site without exposing it to the internet.
How Private HTTP Resources Work
- You assign a hostname on a domain configured in Pangolin and set the destination host, port, and scheme.
- The Pangolin control plane provisions routing and pushes a certificate for that hostname to the site.
- A connected user with access opens the URL. The Pangolin client resolves the hostname privately and sends the request over the tunnel to the site.
- A reverse proxy on the site terminates TLS and proxies the request to the destination.
For a deep dive into how private HTTPS reverse proxying works—including DNS hijacking, overlay addressing, certificate push, and the embedded edge proxy—see Building a Peer-to-Peer Alternative to Cloudflare Tunnels.
Hostname, DNS, and TLS
When you create a private HTTP/HTTPS resource, you assign a domain name. That hostname must be a domain you have already added and configured in Pangolin (see Domains). This is analogous to an alias in that the client resolves the name through Pangolin and traffic is steered to the correct site, but it is not the same system: the name must be a real domain managed in your organization, not an arbitrary internal alias.
Enable SSL on the resource so Pangolin obtains and serves a valid certificate for that hostname. When a connected user opens the site in a browser, a reverse proxy running on the site terminates TLS and proxies the request downstream to your destination. The Pangolin control plane provisions routing and pushes certificates to the site connector, so users get normal HTTPS without certificate warnings.
Destination Fields
The destination block for a private HTTP resource is closer to a target on a public resource than to a plain private resource: in addition to the upstream hostname or IP, you set a destination port and a scheme (http or https). Those values are required so the site knows how to open the connection to the backend after TLS is terminated at the proxy.
Compared to an IP Resource and an Alias
You can approximate private browsing with a standard private resource by pairing an IP or internal hostname with an alias and a port. In practice you would still visit something like https://your-alias.example:8443/ (or HTTP without a trusted name), and the browser will not show a normal publicly trusted certificate for that pattern the way it does for a first-class HTTPS hostname. Private HTTP is meant for the case where you want a real FQDN on your Pangolin domain with valid TLS and default ports, similar to a public resource, while keeping the surface client-only.
Compared to a Public Resource
A public resource is reachable from the internet; Pangolin sits in front with authentication (for example platform SSO or other methods) so unauthenticated requests are blocked at the edge—the “bouncer” in front of a public site.
Private HTTP does not use that public forward-auth model for reachability. The hostname does not grant access from the open internet at all. The user must connect with the Pangolin client first, like a VPN, before the domain resolves and the reverse proxy will serve the app. Instead of a login page at the edge, Pangolin uses the user's active client connection to determine their identity and enforces private resource access rules (users, roles, machines) from that session. The network path is client-attached only.
When the connected client maps to a user, Pangolin forwards that identity to the upstream app as Remote-User, Remote-Email, Remote-Name, and Remote-Role — the same forwarded headers public resources use.
Was this page helpful?