Hello all,
I figured that a chunk of the selfhost community is using Caddy, so decided to post my query here. I am a novice in Caddy, so I might be saying some incorrect terms.
Some information
- The router and the host running Caddy, are different machines
- The router page is running HTTP, but I am accessing it via HTTPS through Caddy
- Caddy is running via Docker.
I have a couple of services running on a host, so I access them via Caddy’s reverse proxy. Now I am also trying to access my router login via the same reverse proxy. This is what the router entry in the caddyfile looks like
.
.
{
local_certs
}
login.router.lan {
reverse_proxy 192.168.1.1:80
}
.
.
With this entry, I can access the login page. However, when I enter the password, I feel like it’s attempting to login but then it just comes back to the original login page. When I access it directly, the login is successful. I also have Pihole running and the Pihole login process works fine. So I suspect that the router login page is expecting some extra information from Caddy to forward it to the login page.
After some searching online and some LLM wrangling, I figured it’s some cookie issue or my login page is expecting a certain host.
What should I add to my Caddyfile so that the login redirect works?
Edit: Clarification! Everything is behind wireguard. Nothing is exposed to public (other than wireguard). I only access it within my home. The router login page cannot be accessed from outside.
You must log in or # to comment.
Seems like the router doesn’t like how the headers are passed on. You could try:
login.router.lan { reverse_proxy 192.168.1.1:80 { header_up Host {upstream_hostport} } }https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#headers
I have tried this, but unfortunately, it did not work. I have tried this suite of commands
login.router.lan { reverse_proxy 192.168.1.1:80 { # Preserve original host and scheme header_up Host {upstream_hostport} header_up X-Forwarded-Proto {http.request.scheme} header_up X-Forwarded-Host {http.request.host} header_up X-Forwarded-For {http.request.remote.host} # Keep cookies intact header_up Cookie {http.request.header.Cookie} header_down Set-Cookie {http.response.header.Set-Cookie} # Preserve Origin/Referer for CSRF tokens header_up Origin https://{http.request.host} header_up Referer https://{http.request.host}{http.request.uri.path} } }Info: My caddy uses HTTPS but the router login page is HTTP. Not sure if this is relevant.
Semi related, you can check the validity of Caddy entries into the caddyfile:
sudo caddy fmt --overwrite /etc/caddy/Caddyfilecaddy validate --config /etc/caddy/Caddyfile
Where
/etc/caddy/Caddyfilepoints to your caddyfile.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System HTTP Hypertext Transfer Protocol, the Web HTTPS HTTP over SSL IP Internet Protocol SSL Secure Sockets Layer, for transparent encryption TLS Transport Layer Security, supersedes SSL nginx Popular HTTP server
6 acronyms in this thread; the most compressed thread commented on today has 6 acronyms.
[Thread #102 for this comm, first seen 18th Feb 2026, 14:11] [FAQ] [Full list] [Contact] [Source code]
I don’t have anything to help you, other than to say you’re probably onto it being something specific about your router wanting more info from the reverse proxy. I have an actiontec modem I proxy behind nginx proxy manager and it works fine without any additional configuration, though.
What I really wanted to comment on was my surprise that everyone in a self hosting community assumed you were exposing that to the public when you absolutely did not say anything that implied it. Do none of you reverse proxy your local services? It’s wonderful!
Edited to add: actually, what cert are you using? I recently switched to a wildcard cert via DNS challenge from Let’s Encrypt and everything has worked better since then.
I have to echo what others have said, and tell you exposing your router’s login to the public internet is very risky (if you’re referring to the WiFi router in your home). I would strongly recommend some other solution to whatever broader problem you’re trying to solve with this—why do you need to access your router login from outside your home? Can the logging in (and presumably tinkering) be done at home? Definitely things to think through before proceeding.
Why are you exposing your router login to the open web?? No bueno!
I take it you’re hitting that page via browsing to your public IP or domain name you setup? I’m no expert but it sounds like you’re using a self signed cert and using https to login to your router and it doesn’t like that…
I don’t know, but I expect it’s having an issue because i assume the port is forwarded from your router to your caddy, but then the caddy server it redirecting back to the router. I don’t know how you’d get around this. but that might be a starting point for your research.
ETA: Also, it’s a bad idea to expose your consumer grade router to the internet. VERY bad idea.
Nothing is exposed to public, other than my wireguard port. I’m running caddy internally. All DNS entries are local only. The router login page cannot be accessed from outside.
