this post was submitted on 18 Feb 2026
23 points (100.0% liked)

Selfhosted

57906 readers
256 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

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?

Edit1: 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.

Edit2: After a discussion with a friend, I have slightly narrowed it down (maybe, I'm not sure) to a http/https issue. When I made this change, the login redirection works.

http://login.router.lan/ {
    reverse_proxy 192.168.1.1:80
}

But this means that all communication is over HTTP.

top 18 comments
sorted by: hot top controversial new old
[–] surewhynotlem@lemmy.world 1 points 2 days ago (1 children)

I don't know how to answer your question. But it might be that your router doesn't like being access as a url. I know I had to tell mine to accept login.router.net as itself.

I also just want to highlight:

The router and the host running Caddy, are different machines

This means your credentials are being passed in plain text over your network between caddy and the router. This might be OK to you. But wanted to highlight for anyone else reading.

[–] xavier666@lemmy.umucat.day 2 points 1 day ago

Hello there. I perfectly understand the risks of my setup. Since it's a commercial off-the-shelf router, i can't run a reverse proxy on it, so this is the best that i can do (other than VLANs). It's also a private network, so I guess it's fine.

I used a bit of AI which said that such embedded devices don't work with reverse proxies. Finding which exact parameters as respected by the router will be time-consuming and the end result is not that great.

[–] a14o@feddit.org 5 points 1 month ago (2 children)

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

[–] irmadlad@lemmy.world 2 points 1 month ago* (last edited 1 month ago)

Semi related, you can check the validity of Caddy entries into the caddyfile:

  • sudo caddy fmt --overwrite /etc/caddy/Caddyfile
  • caddy validate --config /etc/caddy/Caddyfile

Where /etc/caddy/Caddyfile points to your caddyfile.

[–] xavier666@lemmy.umucat.day 1 points 1 month ago

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.

[–] iamthetot@piefed.ca 3 points 1 month ago (1 children)

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!

[–] xavier666@lemmy.umucat.day 1 points 1 month ago (1 children)

Do none of you reverse proxy your local services? It’s wonderful!

Yes please! I don't want to type the port number when multiple services are running on the same server.

what cert are you using?

It's a self-signed local cert. I'm not using Let's Encrypt. Does it require a valid domain name to work?

[–] iamthetot@piefed.ca 2 points 1 month ago

The setup I have does require a domain name, yes. I DNS challenge through cloudflare at the moment to get a wildcard cert for *.domain.tld and use that for my local services, including my modem, to serve with https.

[–] mrnobody@reddthat.com 2 points 1 month ago (1 children)

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...

[–] xavier666@lemmy.umucat.day 2 points 1 month ago

I use wireguard when I'm outside. So I first turn wireguard and then access all my stuff.

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

Any way to trick my router login page? It's a TP-Link router

[–] lmr0x61@lemmy.ml 1 points 1 month ago

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.

[–] Decronym@lemmy.decronym.xyz 1 points 1 month ago* (last edited 1 month ago)

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 13 acronyms.

[Thread #102 for this comm, first seen 18th Feb 2026, 14:11] [FAQ] [Full list] [Contact] [Source code]

[–] UnpledgedCatnapTipper@piefed.blahaj.zone 1 points 1 month ago (1 children)

Does accessing your router page via caddy work when you're actually on your home network and not accessing it via wireguard? Have you tried a different web browser to rule out your LLM suggested cookie issues entirely?

[–] xavier666@lemmy.umucat.day 1 points 1 month ago (1 children)

Does accessing your router page via caddy work when you’re actually on your home network

Unfortunately no, which rules out an issue with wireguard.

Have you tried a different web browser to rule out your LLM suggested cookie issues

It's not the stale cookie issue which goes away when opening a website in incognito. I think it expects the cookie to have the original host information.

Let me paste the list of issues the LLM mentioned. The following section is from the LLM

<LLM>

  1. The router’s web UI expects the original hostname (e.g., 192.168.0.1) and builds redirects or CSRF tokens based on it. Caddy sends its own host (myproxy.example.com).
  2. Authentication cookies are set for the original domain and may be dropped or rewritten by the proxy, causing the server to think the user is unauthenticated.
  3. The router returns Location: http://192.168.0.1/... which points the browser back to the internal address, bypassing the proxy.
  4. Tokens are generated using the Origin or Referer header; the proxy changes these, making the token invalid on POST.
  5. The router forces HTTPS or blocks HTTP when it sees a mismatch, and Caddy may be terminating TLS while the upstream expects plain HTTP.
  6. Some admin UIs use WebSocket for status updates; if Caddy doesn’t forward the upgrade, the page may reload to the login screen.
  7. The router’s UI may be served from / but expects relative paths; Caddy’s uri rewrite can break those links.

</LLM>

It has also mentioned some solutions for each cause. But I don't want to blindly apply them without knowing what is wrong.

My best suggestion would be to try enabling web sockets and see if it changes anything. I did find a post for a similar issue that someone was having with a different reverse proxy, but I'm not sure if it'll be helpful.

https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2099

[–] osanna@thebrainbin.org 0 points 1 month ago (1 children)

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.

[–] xavier666@lemmy.umucat.day 2 points 1 month ago (1 children)

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.

[–] osanna@thebrainbin.org 2 points 1 month ago

no worries. Just wanted to warn you in case you didn't know. :)