Homelab Reverse Proxy Guide: HTTPS Without Unsafe Exposure

A reverse proxy routes selected public hostnames to specific applications and centralizes certificate handling. It reduces the number of entry points, but its firewall rules, backend isolation and application authentication still determine what an outside user can reach.

Tools like Caddy and Nginx Proxy Manager make the first version feel almost too easy. Caddy can automate HTTPS, and Nginx Proxy Manager gives a friendly UI for hosts and certificates. The danger is that easy publishing can turn into easy overexposure. The architecture matters more than the checkbox.

Design principle: Expose the proxy, not the network. Publish only services that are meant for external users, and keep admin interfaces behind enforced LAN/VPN access policy. Internal-only DNS is naming, not access control.

Decide What Belongs On The Public Edge

Service Type	Recommended Exposure	Reason
Family-facing media or photo portal	Maybe public through proxy, with strong auth and app hardening	Useful for nontechnical users, but still needs logs and patch discipline.
Admin panels	VPN only	The internet does not need your NAS, hypervisor, firewall, Docker, or backup console.
Internal dashboards	LAN/VPN access policy, with internal DNS	Convenience is not worth broad public attack surface.
Public website or blog	Public proxy or external host	Designed to be public, but should still be isolated from private lab systems.
Experimental apps	No public exposure until reviewed	Lab projects often have weak auth, debug modes, or poor update habits.

Reference Build

1. Register a domain or subdomain and point DNS records at your WAN address or a supported dynamic DNS target.
2. Forward TCP 443 to the proxy. Forward TCP 80 only when the selected ACME challenge or HTTP-to-HTTPS redirect needs it; a correctly configured DNS-01 flow may not.
3. Place the reverse proxy in a server or DMZ-like VLAN, not on the management VLAN.
4. Configure one hostname per service, such as photos.example.com or docs.example.com.
5. Use HTTPS certificates through Caddy automatic HTTPS, ACME DNS challenge, or Nginx Proxy Manager certificate management.
6. Allow the proxy to reach only the backend IPs and ports it serves.
7. Add application auth, single sign-on (SSO), multifactor authentication (MFA), or an auth gateway where the app supports it cleanly.
8. Log proxy requests and firewall Network Address Translation (NAT) hits. You need evidence when something looks strange.

Caddy Example

photos.example.com {
  reverse_proxy 10.10.20.41:2283
  encode zstd gzip
}

docs.example.com {
  reverse_proxy 10.10.20.52:8000
  encode zstd gzip
}

The site address tells Caddy which hostname to serve. reverse_proxy identifies the backend socket. The proxy terminates the client TLS connection and, in this example, opens a separate plaintext HTTP connection to a trusted backend network. If the proxy-to-backend path crosses an untrusted network, use a backend with valid HTTPS or another authenticated encrypted transport; do not disable certificate verification to make an error disappear.

For the official Linux Caddy service, first retain a known-good configuration privately, confirm console access, and review the exact file and reload action. This example assumes the service runs as caddy, uses /etc/caddy/Caddyfile, and has no extra environment or secret-provider setup. If those assumptions differ, validate with the actual service identity/environment before any reload; do not bypass a failed check.

(
  set -eu
  sudo -u caddy caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
  sudo systemctl reload caddy
  sudo systemctl status caddy --no-pager
  sudo journalctl -u caddy --since "10 minutes ago" --no-pager
)

validate checks whether Caddy can load the configuration. A reload applies a valid configuration without intentionally stopping the service. status and journalctl show service state and recent certificate or upstream errors. Package paths and service names can differ, so confirm them for your installation before running the example.

DNS and Certificate Choices

Automatic HTTPS still depends on correct domain control and reachability. With an ACME HTTP-01 challenge, the certificate authority fetches a token over port 80. With DNS-01, the client proves control by creating a DNS TXT record; this is useful for wildcard certificates and environments that should not expose port 80, but the DNS credential becomes a high-value secret.

• Give a DNS automation token permission only for the required zone and record operations.
• Keep the token in a protected secret store or service environment, not in screenshots or a public Caddyfile.
• Test renewal before the certificate approaches expiry and alert on renewal failure.
• Do not publish an internal admin hostname merely to obtain a public certificate. Internal certificate authority or VPN-only access may fit better.
• Remember that carrier-grade NAT or blocked inbound ports can prevent a direct public reverse proxy design. Use private VPN access or an intentionally selected tunnel design instead of weakening the firewall.

Firewall Rules

Rule	Source	Destination	Ports	Action
Internet to proxy	WAN	Reverse proxy IP	TCP 443; TCP 80 only for the selected challenge or redirect	Allow
Internet to anything else	WAN	Internal networks	Any	Deny
Proxy to backend app A	Proxy IP	App A IP	Specific app port	Allow
Proxy to backend app B	Proxy IP	App B IP	Specific app port	Allow
Proxy to management VLAN	Proxy IP	Management VLAN	Any	Deny and log

Internal DNS And Split Horizon

Use split DNS to direct LAN/VPN clients to the intended internal proxy. Do not point them directly at a backend when that would bypass proxy authentication or policy. DNS records do not make a reachable service private: enforce the same LAN/VPN boundary at the firewall and application, and check both IPv4 and IPv6.

Header trust caution: If an app trusts X-Forwarded-For, X-Real-IP, or similar headers, make sure only the proxy can reach the app directly. Otherwise clients may spoof identity or source context.

Application Hardening Still Matters

HTTPS protects traffic between endpoints and authenticates the hostname when certificate validation succeeds. It does not fix a weak password, missing authorization check, vulnerable application, exposed debug route, unsafe upload handler, or stolen session. Keep the backend supported, enable its own authentication, use MFA when available, rate-limit at the application or identity layer where appropriate, and review account recovery.

Do not add copied security-header snippets blindly. Content Security Policy, cross-origin rules, WebSocket upgrades, callback URLs, upload limits, and long-running requests are application-specific. Start from the application's reverse-proxy documentation, change one behavior at a time, and test login, logout, password recovery, upload, download, streaming, mobile clients, and WebSockets when the service uses them.

Validation Checklist

• A port scan from a network outside the home shows only intended public ports.
• Each public hostname serves a valid certificate for the intended name and reaches the intended backend.
• An unknown hostname does not fall through to a sensitive default backend.
• Backend apps are not reachable directly from the internet or an untrusted client VLAN.
• The proxy cannot reach the management VLAN or unrelated backend ports.
• Logs show client IP behavior clearly enough for troubleshooting without trusting arbitrary incoming forwarding headers.
• A private-only app remains unreachable offsite unless connected through VPN.
• Certificate renewal, proxy restart, backend restart, and firewall reboot preserve the intended state.

Troubleshooting and Rollback

Symptom	Likely Layer	First Check
DNS name does not resolve	Authoritative DNS, dynamic DNS, or cached record	Query the authoritative record and compare public resolvers; confirm the address matches the current WAN endpoint.
Certificate issuance fails	ACME challenge, reachability, DNS API, or rate limit	Read the exact challenge error and verify only that challenge path. Do not repeatedly retry without correcting it.
502 or 503 response	Proxy-to-backend reachability, port, protocol, or backend health	From the proxy host, test the configured backend address and inspect both proxy and application logs.
Redirect loop or broken login	Scheme/host forwarding, application base URL, or auth gateway	Compare external URL, forwarded headers, callback URL, and application proxy-awareness settings.
Real client address is wrong	Trusted proxy chain	List every proxy hop and trust forwarding headers only from known immediate proxies.
Large upload or stream fails	Timeout, body-size limit, buffering, or backend behavior	Test a small request, then inspect proxy and app limits before increasing them.

Close the approved WAN exposure paths first, including IPv4 NAT and IPv6 ingress rules, and verify offsite access is denied. Then withdraw public DNS and restore the known-good proxy configuration; cached DNS or direct-IP requests make record deletion insufficient. Confirm the backend remains restricted to its approved paths. Keep console access independent of the proxy and preserve logs for diagnosis.

Useful Gear And Buyer Notes

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

Need	Good Choice	Why It Fits	Affiliate Link
Small proxy host	N100/N150 mini PC or existing VM host	A reverse proxy is light, but a dedicated low-power host or VM keeps the role clean.	Search Amazon: N100 mini PC
Security key	YubiKey or FIDO2 hardware key	Useful for protecting DNS registrar, Cloudflare, GitHub, and admin identities.	Search Amazon: YubiKey 5C NFC
UPS	APC or CyberPower UPS	Keeps DNS, gateway, and proxy stable through short outages.	Amazon: CyberPower CP1500PFCLCD
Known-good cabling	Cat6 patch cables	Public-facing troubleshooting should not begin with mystery patch leads.	Amazon: Cable Matters Cat6 10-pack

Common Mistakes

• Putting every service behind the proxy just because it works.
• Publishing admin interfaces that should live behind VPN.
• Leaving backend apps reachable directly from other untrusted VLANs.
• Skipping logs until after the first weird request storm.
• Treating HTTPS as authentication. Encryption is not permission.

References

• Caddy Reverse Proxy Quick Start
• Caddy Automatic HTTPS
• Caddy reverse_proxy directive and trusted header behavior
• Let's Encrypt Challenge Types
• Nginx Proxy Manager Guide
• RFC 1918 Private Address Space
• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy

What This Does Not Prove

This guide is documentation-backed and provides an implementation and test plan. A valid certificate does not prove authorization, backend isolation, safe forwarding-header trust, successful renewal, or application compatibility. This revision does not report a TechGeeks port scan, certificate-renewal test, penetration test, uptime measurement, or application compatibility result. Verify the current Caddy or Nginx Proxy Manager release, backend proxy requirements, ACME behavior, registrar controls, and firewall syntax before implementation.

Related TechGeeks resources

• WireGuard VPN for private remote administration
• Homelab VLAN design and network segmentation

Final Thought

Publish a service only after its authentication, backend restrictions, certificate handling and exposure rollback pass the listed checks. Keep administrative access independent of the public proxy so a proxy failure does not prevent recovery.