Just Dashboard / Docs
Operate the server

Proxy and TLS

Manage reverse-proxy sites, certificates, streams, ports, and TLS checks.

Proxy & TLS shows the reverse proxy running on the host and the addresses it serves. It sits in the sidebar's Network group, beside Network, and has eight pages: Overview, Sites, Certificates, TLS report, Streams, Ports, Traffic, and Configuration. It covers nginx sites, certificate inventory and issuance, TCP/UDP streams, listening ports, request traffic, and a live TLS report. Routes owned by another component, such as the Docker Caddy ingress, are listed for visibility without an nginx editor.

Check the current state

Open Proxy & TLS → Overview. The engine line shows nginx or Caddy with its version, service state, and certbot renewal, followed by counts that each open their page: sites and how many use TLS, disabled sites, certificates that are not valid, streams nginx does not read, and internet-facing ports. A count whose source could not be read says so instead of showing zero. Below it, a picture wires each domain through the proxy to the application behind it, then come live traffic, the hour's requests, each certificate's days left, recent nginx errors, the configured Routes with Check upstreams, and the engine's own log.

The overview has no automatic attention list; read the counts and the panels themselves. Test config checks the configuration on disk without reloading it. Reload or restart only after you understand the test result and the effect on active traffic. Administrators can open Alerts to send notifications to the channels deployments use when a certificate is expiring or expired, a renewal fails, a site serves a different certificate than it should, the engine stops, an upstream goes down, or a watched endpoint becomes unreachable, untrusted, or falls below a chosen TLS grade.

Add a site

  1. Open Sites → New site. Choose what it serves: An app, Files, PHP, or A redirect, then the server names and destination. A reverse-proxy site usually forwards requests to a service already running on this host.
  2. Set HTTPS under Encryption, then Who may reach it: an allow list, a password, a shared access list, client certificates, or single sign-on through Authelia, Authentik, oauth2-proxy, or another auth server, on every path or chosen ones. Hardening can refuse AI crawlers, scanners, and hotlinked media, and Pages & files can serve a security.txt and robots.txt. Put WebSocket or custom directives under Anything else. If the site names a certificate the dashboard has not found, follow the issuance link before depending on TLS.
  3. Review the rendered configuration and save. The dashboard links the site and tests it with nginx -t before reloading, and restores the previous file and link if the test fails. A site saved disabled is tested as it would be enabled, in a copy of the configuration, so it does not fail later on the day someone enables it.
  4. Open the site from the list, then check its logs or TLS report. Editing a hand-written nginx file can be less predictable than editing a dashboard-created one; read the warning that lists lines the form cannot hold, and move them into the extra configuration before saving.

A site's menu also offers Edit, Raw config, Duplicate, Enable or Disable, Start maintenance, Rename, Download, Purge cache, History, and Delete. The copies a delete leaves behind are listed under Deleted & backups, where a restore is tested before it is applied. nginx sites-available and conf.d layouts differ: a conf.d site has no separate link, so it is switched off by renaming the file, and a save cannot enable it in the same step. An allow list does not restrict a redirect site, because nginx answers its return before access rules apply.

Issue and verify a certificate

Open Certificates to inspect installed certificates, expiry, the sites using each one, watched domains, and automatic renewal with its recent activity. Issue certificate requests one from Let's Encrypt (or another ACME directory) through certbot; its menu also offers From the local CA, Self-signed, and Signing request for a CA, and Import adds an existing certificate. Issuance starts with Test run first selected, which goes through the whole exchange against a staging authority and saves nothing, because the real authority allows only a few failed attempts an hour.

Choose how to prove control: Through nginx, A folder your web server already serves, Standalone, or DNS. HTTP validation needs a domain that reaches the host. Wildcards and domains behind a CDN need DNS validation; choose a supported DNS provider and provide its credential, which is saved to a root-only file and never shown again. A saved credential helps dashboard-managed issuance and renewal, but an external host timer needs the matching provider environment configured separately.

Run TLS report for the domain after activation. It probes what the domain actually serves, which can differ from the certificate files on disk if a proxy has not reloaded. A protocol version the scanner could not test is reported as unknown, with the reason, rather than as absent. Scanning needs an administrator.

Streams, ports, and traffic

Use Streams for nginx TCP/UDP stream routes. A stream needs nginx's stream module and a top-level stream block that includes the stream directory; where either is missing, an administrator can install the module and add the include from the page, which nginx tests before it stays. Ports identifies the listening process behind each port and how far it can be reached. Traffic breaks down each site's requests, and Configuration shows the effective nginx configuration with its files, lint results, and history.

On this page