Comment on Caddy reverse proxy fails with a login page
xavier666@lemmy.umucat.day 5 days agoDoes 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>
- 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).
- 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.
- The router returns Location: 192.168.0.1… which points the browser back to the internal address, bypassing the proxy.
- Tokens are generated using the Origin or Referer header; the proxy changes these, making the token invalid on POST.
- The router forces HTTPS or blocks HTTP when it sees a mismatch, and Caddy may be terminating TLS while the upstream expects plain HTTP.
- Some admin UIs use WebSocket for status updates; if Caddy doesn’t forward the upgrade, the page may reload to the login screen.
- 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.
UnpledgedCatnapTipper@piefed.blahaj.zone 5 days ago
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