It almost works and I can access the webgui, but many functions on this page does not work at all(eg: settings page cannot be called out). The problem disappears when I directly access via IP:8384
I guess the problem may come from the NextCloud, which contains a lot of re-write rules, also I opened the pretty url function.
There are many other services on my NAS, which all support base uri, and they work fine using the apache2 config:
And everything works fine for jellyfin and transmission.
It there anything I missed or is there any possibility that syncthing web GUI will add base uri function?
It looks like some REST requests are getting HTML responses with the word Nextcloud in them. I don’t know what the problem is, but I think it’s something about your setup that is not just reverse-proxying the Syncthing UI but also doing other things.
I think that the very complex nextcloud rewrite rules change many url to it’s own place as soon as there is no /syncthing string in the url (maybe not all components in this page request url contains /syncthing, in this case the reverse-proxy will not work for those url), thus, the only solution to solve this is to add base uri function to syncthing Web GUI, thus when I set the base uri to “/syncthing”, all resources will be redirected by the reverse proxy rules.
Many other services that support base uri, like jellyfin, transmission, nps, they all works pretty on my server by the config list above.
I just don’t understand why such a mature software like syncthing does not support base uri function, I am sure once this function is available, my problem will go. Base uri is also very helpful when people want to open multiple instance of Syncthing, and it won’t take much work to develop as it’s just adding a relative path to all url.
There is no point for having base urls unless you’re planning to put stuff behind a proxy. If you are putting stuff behind a proxy, every single one that I’ve seen already supports putting stuff behind base urls, hence this is exactly the reason why we don’t need to do it, as it’s already done in the proxy.
The problem is that your nextcloud stuff is getting in the way, so I think the better question to ask is why does such mature software like nextcloud rely on such aggressive rewrite rules that break simple reverse proxy functionality.
I am fairly certain even if we had a base urls, your rewrite rules would still hi-jack the requests and send them to next cloud, as the problem here is not related to what the base url is, but given this url, which backend does the request get sent to.