Homelab Reverse Proxy Guide: HTTPS, DNS, and Caddy

A homelab reverse proxy gives many applications one organized front door. Instead of remembering 192.168.1.50:8096 for Jellyfin and another address for every service, you use names such as jellyfin.example.com. The proxy receives the request, handles HTTPS, and forwards it to the correct application.

This guide explains reverse proxies, DNS, and certificates without pretending that public exposure is required. It also shows why Caddy is a practical choice and how DashCaddy removes the repeated configuration around each new service.

What does a reverse proxy do in a homelab?

A reverse proxy sits between clients and backend applications. It provides three core functions:

1. Name-based routing: several services can share ports 80 and 443 because the requested hostname selects the backend.
2. TLS termination: HTTPS certificates and encryption are handled in one place rather than configured separately inside every app.
3. A policy boundary: logging, headers, authentication, and network rules can be applied before a request reaches a service.

The backend can still use a private address and port. The browser only needs to know the public or internal hostname served by the proxy.

Why Caddy is popular for home servers

Caddy combines a web server and reverse proxy with automatic HTTPS for qualifying hostnames. Its configuration is intentionally compact. A basic route can look like this:

jellyfin.example.com {
    reverse_proxy 192.168.1.50:8096
}

For a publicly validated domain, Caddy can obtain and renew certificates through ACME when DNS and network reachability meet the certificate authority's requirements. You still need correct DNS and an intentional exposure design; automatic HTTPS cannot repair a hostname that points to the wrong place.

Caddy also has an internal certificate authority for private names. Devices must trust that CA's root certificate before browsers will accept those certificates without warnings.

Decide whether the service should be public

Before touching DNS, classify the application.

Keep it private when possible

Administrative dashboards, hypervisor consoles, router interfaces, storage management, and container controls usually belong on the LAN or a private network. Remote access can use a VPN-style path such as WireGuard or Tailscale without publishing the management interface to everyone on the internet.

Publish only services intended for outside users

A family photo portal, media service, or public website may need broader access. Public exposure adds responsibility:

• patch the application and proxy;
• use application authentication;
• limit unnecessary routes and ports;
• monitor access and failures;
• maintain backups;
• understand how account recovery works.

A reverse proxy encrypts and routes traffic. It does not turn an insecure application into a secure one.

DNS patterns for a homelab reverse proxy

Public DNS

For a public service, create a record such as photos.example.com pointing to the address that reaches your proxy. Depending on your network, that may involve a home router, a tunnel, or a VPS relay. Certificate validation must be able to prove control of the name through the selected ACME challenge.

Internal DNS

For LAN-only services, local DNS can point grafana.home.example.com directly to the proxy's private address. This keeps local traffic local and avoids remembering ports.

Split DNS

Split DNS gives the same hostname different answers inside and outside your network. Internal clients reach the proxy over its LAN address, while external clients use the public path. This can avoid hairpin-routing problems and gives users one consistent URL.

Document which system is authoritative for each zone. Many "proxy problems" are actually stale or conflicting DNS records.

A safe manual Caddy workflow

If you manage Caddy directly, use a repeatable sequence:

1. Reserve a stable address for the proxy host.
2. Confirm the backend application is healthy on its private address.
3. Create the DNS record.
4. Add one Caddy site block with the correct backend port.
5. Validate the configuration before reloading it.
6. Test from an internal client.
7. If the service is public, test from a genuinely external network.
8. Verify login, uploads, WebSockets, and any native mobile clients.

Keep Caddy's data directory persistent. It contains certificate and state data that should survive container or package upgrades.

Common reverse proxy problems

502 Bad Gateway

A 502 usually means the proxy cannot reach the backend. Check whether the service is running, whether the address and port are correct, and whether Docker networks or host firewalls permit the connection. Debug the backend path before changing certificate settings.

The certificate will not issue

Check DNS first. Then verify that the selected ACME challenge can reach Caddy or update the required DNS record. Carrier-grade NAT, blocked inbound ports, and incorrect AAAA records can all make a correct Caddyfile appear broken.

The app redirects to HTTP or the wrong hostname

Some applications need to know their external URL or trust proxy headers. Caddy sets common forwarding headers, but the application may still require its own "external URL" or trusted-proxy setting.

The website loads but live updates fail

Many modern applications use WebSockets. Caddy supports WebSocket proxying, but an incorrect path, upstream address, or application base URL can still break the connection. Inspect the browser network panel and proxy logs rather than adding random headers.

It works outside but not on the LAN

Your router may not support hairpin NAT, or internal DNS may still point clients to the public address. Add an internal DNS override that sends local clients to the proxy's LAN address.

Reverse proxy security checklist

• Expose the proxy, not every backend port.
• Keep management interfaces private.
• Use HTTPS and do not normalize clicking through certificate warnings.
• Protect accounts with strong, unique credentials and MFA where available.
• Keep Caddy and backend applications updated.
• Review access logs without storing more sensitive data than you need.
• Rate-limit or add upstream protection when a public service attracts abuse.
• Back up proxy configuration and application data.
• Test certificate renewal and recovery before an expiration becomes urgent.

How DashCaddy helps with reverse proxy and HTTPS

The manual workflow repeats for every homelab application: choose a name, find the port, write a proxy route, coordinate DNS, obtain a certificate, and add the service to an inventory.

DashCaddy ties those steps to the application lifecycle. Its curated templates provide default application ports and health information; deployment and Caddy connectivity are managed from the same platform. DashCaddy's built-in CA supports private certificate workflows, while Caddy provides the proxy layer used to make services accessible through stable names.

For home lab users, the practical benefits are:

• fewer hand-edited routes that drift away from the running containers;
• one place to see the service, host, health, and access configuration;
• less repetitive certificate and proxy work when adding applications;
• a clearer path from one server to multiple hosts;
• APIs and MCP tools for supported automation without parsing configuration files.

You still choose which services should be reachable and who may access them. DashCaddy organizes the implementation; it does not make the exposure decision for you.

Frequently asked questions

Do I need a domain for a homelab reverse proxy?

Not always. Publicly trusted certificates normally use a domain you control. Private names can use an internal CA if you install its root certificate on your devices. A private network can also provide remote access without publishing the service.

Is Caddy better than Nginx or Traefik for a homelab?

All three can work. Caddy is attractive when concise configuration and automatic HTTPS are priorities. Nginx has a large ecosystem and extensive low-level control. Traefik is popular in label-driven container environments. Choose the model you can operate and recover.

Can one Caddy server proxy applications on several machines?

Yes, if the proxy can reach each backend over a trusted network path. Use stable addresses, restrict backend access, and monitor the inter-host connection.

Does a reverse proxy make an application safe to expose?

No. It provides routing and can provide TLS and policy controls, but the backend still needs secure authentication, updates, sensible configuration, and ongoing monitoring.

See how the reverse proxy fits into a complete beginner homelab setup, explore DashCaddy's features, or follow the installation guide.