Just got it working, it was indeed a DNS issue. When launching the docker container I added the --add-host name:ip option to add an entry to the hosts file that pointed to the internal ip of our nextcloud server and that made it properly work.
@travisdh1 Are there any benefits of configuring your own reverse-proxy if it's running behind CloudFlare that is essentially the one already? I know they offer their own Origin CA certs that you can install on your web servers to encrypt the traffic between CF and your cloud. As long as you're happy to stick with CloudFlare, there will be no need to run cron jobs with certbot renewals every 3 months.
As @JaredBusch said, you can run self-signed certs with CloudFlare just fine. This was for my home lab, so I purposely do things the hard way sometimes, just to see what it's like. That's why I originally tackled this anyway. Running a reverse proxy mostly so I don't have to pay for nearly 30 IP addresses on the box I rent for it.
Not sure how I should have things configured. I believe that I followed all of the instructions properly, but it is not working and there are no really clear instructions for a dual server scenario. All of the official stuff lists single server and Apache.
The one thing I remember having issues with was that it wants to communicate over the same "channel" in between the Collabora and NextCloud servers, so if the external browser connection is https, then it's not happy and throws errors if the back end isn't communicating over https as well. Getting that https channel setup with the recommended Drupal container and instructions for that didn't seem to work, and was such a pain I gave up trying to get it fixed at the time.
The free license is limited to five locks per day which means the free edition defends your system against five unique attacks per day. [...] The free license does not contain reporting (like the PRO edition does).
Also, no official support for Windows Server 2016.