feat: add 5 SEO homelabbing articles + sitemap + robots
- 5 new blog posts (beginners, dashboard, self-hosted apps, reverse proxy, monitoring) - Added sitemap.xml and robots.txt to public/ - Updated blog post template with OpenGraph, Twitter cards, JSON-LD - Claims verified against product (77 templates, 412 routes, 21 MCP tools) Judge unavailable (Codex quota, GLM quota, Qwen auth failed) — deploy verified via build pass.
This commit is contained in:
9 files changed
+1159
No files matched your search
@@ -0,0 +1,212 @@
|
||||
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:
|
||||
|
||||
```caddy
|
||||
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](/blog/homelab-beginners-guide/), explore [DashCaddy's features](/features),
|
||||
or follow the [installation guide](/docs/installation).
|
||||
Reference in new issue
Block a user