Caddy Reverse Proxy
ReviewAudited by ClawScan on May 10, 2026.
Overview
This is a coherent Caddy reverse-proxy guide, but it includes security-sensitive gateway and credential changes and one networking recommendation that could expose local apps beyond the intended private proxy.
Review and adapt the networking instructions before use. Prefer binding local apps to localhost, verify Caddy is actually limited to your Tailscale/private interface, protect the Vercel API token, and enable OpenClaw allowInsecureAuth only if you understand and accept the reduced authentication boundary.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A local dev app could become reachable directly on its raw port, bypassing Caddy, TLS, and any proxy-level controls.
For a same-host Caddy route using localhost, binding the app to all interfaces is broader than needed and may expose the app directly on LAN, Tailscale, or public interfaces outside Caddy's HTTPS/proxy boundary.
Designed for Tailscale-only access (no public exposure)... reverse_proxy to localhost:<port> ... **Bind to 0.0.0.0** so Caddy can proxy to it.
Bind apps to 127.0.0.1/localhost when Caddy runs on the same machine; use 0.0.0.0 only with a firewall or container/network design that explicitly requires it.
If the gateway is exposed more broadly than intended or a token leaks, access to the control UI may be easier than with device-key authentication.
The OpenClaw gateway integration intentionally weakens the normal device-auth boundary for proxied control UI clients. It is disclosed and purpose-aligned, but it affects a sensitive agent gateway interface.
`allowInsecureAuth: true` — The gateway normally requires device-key authentication... This setting allows token-only authentication.
Use this setting only when required, keep the gateway restricted to trusted Tailscale/private clients, tightly limit allowedOrigins and trustedProxies, and revert the setting if proxying no longer needs it.
If this token is exposed, someone could potentially alter DNS records or interfere with certificate issuance for the configured domain.
A Vercel DNS token is expected for DNS-01 certificate automation, but it is a long-lived credential with DNS-account impact and should be treated as sensitive.
**Vercel API Token:** Create a long-lived `vcp_*` token... no expiration — must be revoked if exposed.
Use the least-privileged token available, store it in a file with restrictive permissions, avoid pasting it into shell history, and revoke/rotate it if exposed.
A future plugin change or compromised dependency could affect the Caddy binary users build and run.
The guide asks users to build a custom Caddy binary from an external GitHub plugin without pinning a commit or version. This is normal for custom Caddy builds but has provenance and repeatability risk.
xcaddy build --with github.com/caddy-dns/vercel
Pin plugin versions or commits, review the plugin source, and build from trusted repositories.
Caddy and app services may continue running in the background until explicitly disabled.
The documentation creates long-running services that start automatically and may survive logout. This persistence is expected for a reverse proxy, but users should understand it.
RunAtLoad ... KeepAlive ... Restart=always ... systemctl --user enable --now caddy ... loginctl enable-linger $(whoami)
Only enable persistent services you want running continuously, and document how to stop, disable, or remove them.