I use Caddy to get rid of the annoying "insecure self-signed certificate" warning from the browser when I'm using my self-hosted services. Thanks to that, I can use DNS challenge to convert https://192.168.0.23 into https://truenas.selfhosted.com with a valid certificate and without opening any ports. I only have to add this to my Caddyfile:
TrueNAS.SelfHosted.com {
tls {
dns cloudflare {env.CF_API_TOKEN}
}
reverse_proxy https://192.168.0.23:443 {
transport http {
tls
tls_insecure_skip_verify
}
}
}
I've been doing for a while. I have a subdomain for all my local services, including my Modem and my Router.
I recently acquired a Flint 2 (GL-MT6000).
All the subdomains for all my other services work fine.
For the new router, I thought everything was going to be as simply as adding this:
Router.SelfHosted.com {
tls {
dns cloudflare {env.CF_API_TOKEN}
}
reverse_proxy https://192.168.0.1:443 {
transport http {
tls
tls_insecure_skip_verify
}
}
}
That used to work with my previous router (ER605) but now for some reason it doesn't work for my Flint 2. I only get a blank page that says Admin Panel and with this source code.
<!DOCTYPE html><html lang=""><head><meta charset="utf-8"><meta name="robots" content="noindex, nofollow"><meta http-equiv="Cache-Control" content="no-cache,no-store,must-revalidate"><meta http-equiv="pragma" content="no-cache"><meta http-equiv="expires" content="0"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,minimum-scale=1,user-scalable=no"><link rel="icon" href="/favicon.ico"><title>Admin Panel</title><link href="/js/app.a1621a75.js" rel="preload" as="script"></head><body><noscript><strong>We're sorry but gl-ui doesn't work properly without JavaScript enabled. Please enable it to continue.</strong></noscript><div id="app"></div><script src="/js/app.a1621a75.js"></script></body></html>
It appears you're running into a common issue when reverse-proxying web interfaces that are built as single-page applications (SPAs). The blank page with the title "Admin Panel" is a strong indicator that the router's web interface is loading the initial HTML but failing to load the necessary JavaScript application to render the rest of the page.
Here's a breakdown of why this is happening and how to fix it:
The Problem: Asset Loading and Host Headers
The core of the issue likely lies in how the Flint 2's web interface is coded. When you access Router.SelfHosted.com, Caddy forwards the request to https://192.168.0.1. However, the web server on the router might still think it's being accessed directly.
The blank page's source code you've provided contains a crucial clue:
...
These lines tell the browser to fetch the main JavaScript application from /js/app.a1621a75.js. The problem is that without proper configuration in your reverse proxy, the router's web server might be generating these paths incorrectly, or your browser is trying to fetch them from Router.SelfHosted.com/js/... and something is getting lost in translation.
The most common culprit is the Host header. By default, reverse_proxy in Caddy passes the original Host header (Router.SelfHosted.com) to the backend service. Some web servers are strict about this and expect the Host header to match what they're configured with (192.168.0.1).
The Solution: Modify the Caddyfile
To resolve this, you need to tell Caddy to explicitly set the Host header to what the Flint 2 router expects. You can do this by adding a header_up directive to your Caddyfile.
Here is the updated Caddyfile block for your router:
header_up Host {http.reverse_proxy.upstream.hostport}: This directive modifies the Host header of the request that Caddy sends to your Flint 2 router.
{http.reverse_proxy.upstream.hostport} is a Caddy placeholder that will be replaced with the address of the upstream service, which in this case is 192.168.0.1.
By making this change, when you go to Router.SelfHosted.com, Caddy will forward the request to https://192.168.0.1 and tell the router that it is being accessed via 192.168.0.1. This should allow the router's web server to correctly generate the paths for its JavaScript and other assets, enabling the admin panel to load properly in your browser.
Since the initial fix didn't work, it means the Flint 2's web interface is more particular than most. The issue is almost certainly related to how the router's web application generates its internal API and asset links.
The next step is to get more information from your browser. This will tell us exactly what's failing.
Check the Browser's Developer Console
When you have the blank "Admin Panel" page open, use your browser's developer tools to find the specific error.
How to Open: Press F12 (or Ctrl+Shift+I on Windows/Linux, Cmd+Opt+I on Mac).
What to Look For:
Click on the "Console" tab. Look for any errors, especially red ones. They often mention CORS policy, Content Security Policy (CSP), or 404 Not Found.
Click on the "Network" tab. Refresh the page (F5). Look for any rows that are red, indicating a failed request. Check the "Status" column for codes like 404 or 502.
My suspicion is that you will see an error related to a failed API call or WebSocket connection. The Flint 2 admin panel, like many modern interfaces, relies on these to function.
A More Comprehensive Caddyfile
Based on common issues with proxying complex web apps like those on GL.iNet routers, the application likely needs more context about the original request.
Try this more robust Caddyfile configuration. It passes several additional headers to make the reverse proxy more "transparent" to the router's web server. Router.SelfHosted.com {
tls {
dns cloudflare {env.CF_API_TOKEN}
}
header_up Host {http.reverse_proxy.upstream.hostport}: As before, this sets the Host header to 192.168.0.1, which is often required.
header_up X-Forwarded-Host {host}: This explicitly tells the router that the original host the browser tried to connect to was Router.SelfHosted.com. Some applications use this header to generate correct URLs.
header_up X-Forwarded-Proto {scheme}: This tells the router that the original connection was made using https. This can prevent issues where the application tries to redirect you from HTTPS to HTTP.
Please try this updated configuration. If it still results in a blank page, the errors you find in the developer console will be the key to solving it.