After updating Duplicati to version 2.2.0.0_stable_2025-10-23 on DSM 7.1.1 Docker, you can log in via the domain name using the new UI for a short time. However, when you log out and attempt to log in again, clicking the “Login” button after entering the password yields no response. Restarting the container does not resolve the issue, and switching back to the old UI also results in no response when trying to log in.
The user’s issue is with the reverse proxy login. The reverse proxy is the Lucky plugin installed on OpenWrt. They have tried logging in using /login.html, which works fine, and direct IP login is also functional. They believe this is related to the reverse proxy. On another FNOS device, the same issue occurs after updating Duplicati deployed via Docker.
(Note: “FNOS” is kept as-is as it appears to be a proper noun, possibly a device or system name. If it’s an acronym, please provide the full form for a more accurate translation.)
Reverse proxy has caused problems. The dev is more familiar with them.
“Lucky” doesn’t ring a bell with me, nor can Google figure out what that is.
So far, I’m finding a Google AI Overview with a different exact name, and
OpenWrt’s LuCI web interface can be used to manage and configure various services, including those that can function as a reverse proxy. While LuCI itself doesn’t have a built-in “reverse proxy” plugin in the generic sense, you can install and configure web servers like Nginx or Caddy through LuCI, and then use their functionalities to set up reverse proxying.
Another AI Overview:
Synology provides a built-in reverse proxy feature in its DiskStation Manager (DSM) operating system, located under Control Panel > Application Portal > Reverse Proxy. This allows users to route web traffic to different applications or services based on hostnames and ports, simplifying access and enhancing security by exposing only a few ports to the internet. Users can also install alternative reverse proxy solutions, like NGINX Proxy Manager, using the Container Manager (formerly Docker) package.
So it’s not clear to me exactly where the reverse proxy is, what it is, and how “Lucky” fits in.
Does “direct” mean without any proxy interfering? They might need port 8200 along with IP.
There is also a security feature in Settings and server startup options that limits hostnames.
--webservice-allowed-hostnames: The hostnames that are accepted, separated with semicolons. If any of the hostnames are "*", all hostnames are allowed and the hostname checking is disabled.
This avoids DNS rebinding attacks. It might be why they used IP:8200 and not hostname:8200.
I mention this also in case it can offer some relief until networking and proxying is sorted out.
You can possibly also get user to gather output from browser tools, as the cited issue seeks.
There might not be any change for this, since nobody knows the details yet.
Often a proxy config change is needed, for example proxy websockets now.
I tried looking for Lucky reverse proxy setup details, but I couldn’t find much.
If anyone can point to exact page (even if it’s in Chinese), that might help us.
Or maybe the developer can guess based on the symptoms provided so far,
however ultimately someone may need to test changes to the proxy config…
