Homelab Reverse Proxy Guide: HTTPS Without Unsafe Exposure

A reverse proxy is the difference between "I opened ten random ports" and "I have one controlled front door." It lets you publish selected services over HTTPS, centralize certificate handling, route traffic by hostname, add authentication where appropriate, and keep most of the lab private.

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 VPN or internal-only DNS.

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	Internal DNS or VPN only	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.

Validate configuration before reloading a packaged Caddy service:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
sudo systemctl status caddy --no-pager
sudo journalctl -u caddy --since "10 minutes ago"

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	80, 443	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

For internal users, split DNS keeps the experience clean. Inside the LAN or VPN, app names can resolve to the internal proxy or internal service address. Outside the LAN, only public services resolve publicly. This avoids hairpin NAT surprises and keeps private names private.

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.

Rollback removes exposure before it repairs convenience. Disable the public DNS record, close the WAN NAT rule, restore the last known-good proxy configuration, and confirm the backend is still reachable only from the LAN or VPN. Keep a console or local admin path that does not depend on the public proxy. Preserve logs before deleting failed configuration so the cause can be reviewed.

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

A reverse proxy should make public access cleaner and private access stricter. If the proxy makes it easier to publish the right things and harder to accidentally expose the wrong things, you are using it well.

This reverse-proxy guide occupies the public-exposure step of the TechGeeks homelab foundation. Establish private VPN administration and internal segmentation first; then publish only the application paths that have an explicit public-user requirement, while keeping DNS, identity, backend isolation, logging, and recovery under separate control.