The gateway timeout is likely from nginx. You can either try to find a way to not use nginx for Duplicati, or reduce the number of kept backups to a number that can be read before nginx timeout, or raise timeout.
Search finds there are lots of articles on the latter, such as How to Increase Request Timeout in NGINX.
There might be some other workarounds, e.g. one can recreate (by The REPAIR command) a database with a specific version (0 would be the latest), and possibly that wouldn’t get a web timeout. You can test. Doing it this way is a little more dangerous if the original system still exists, as you never want a backup running from two different source systems into the same destination folder. They will confuse each other.
EDIT:
What is this referring to? If you open a new tab to About → Show log → Information before trying the direct restore, you should be able to see it downloading dlist files one by one. It needs all before it can send the response that lists them in the restore dropdown. In your case, it might have still been listing at the timeout.
By the way, if you use F12 developer tools, the request that gets the slow response with the version info is:
http://localhost:8200/api/v1/backup/<GUID>/filesets
without my artificial throttle, my backup gives a response in 29 seconds instead of the 40 minutes throttled.
I don’t use nginx, but possibly you can customize the longer timeout around the requests that are too slow.