aptalca

Yes, you can do that. Make sure that your unraid host is connected through a vpn client and your openvpnas container is in host mode. I do it in a similar fashion. My pfsense router is running an openvpn client that connects to PIA. Unraid uses that for all outbound connections. I also have openvpn-as container running on unraid. So when I vpn into home remotely, not only I can access all the local computers on the home lan, but my internet connection also goes through PIA thanks to the client on pfsense. I'm double vpn'ed and it works beautifully

Sure, remove the location block for "/" or that whole server block

No, that config passes through the real ip and other pertinent info in http headers so plex knows where they are coming from

If the containers are on separate servers, then simply use the host ip and port to reverse proxy

Normally with remote access, your server contacts the plex server and tells it what its public ip is so the plex server can let the clients know. I think plex is having issues with figuring out its public ip lately. With reverse proxy, you tell the plex server what the public domain is, and you can turn off the built in remote access service. Clients connect through your domain and letsencrypt/nginx container handles the ssl and proxy

For all those having issues with plex remote access, did you try reverse proxying? I had intermittent connection issues until I reverse proxied. No more connection problems. https://github.com/linuxserver/docker-letsencrypt/blob/master/root/defaults/proxy-confs/plex.subdomain.conf.sample

Binhex-medusa's internal port is 8081

a) is not supported by this image b) is currently not supported by letsencrypt due to the vulnerability

On it

I'm not going to argue this any further. The purpose of the first post in this thread is not to provide any instructions (it provides none, zero) but instead to provide links to the docs, the source and the images. The docs that are linked in the first post contain ALL of the information, they are platform agnostic and are kept up to date. They are the sole source of official info by the devs for ALL users, not just unraid. Putting instructions in the first post here would mean we have to keep info on multiple locations up to date. So no, we are not going to add any instructions to the first post of this thread.

What is critical information for you may not be as critical for someone else. Some people use this container to host a wordpress site, no reverse proxy needed. Some only reverse proxy. Some host a forum, some do all. Some run it on unraid, some on debian, some on rpi, some use portainer, some use docker compose and some use bash. You keep asking for step by step instructions but given the vast number of scenarios this container can be used in and for, and the vast number of apps/guis you can reverse proxy, it is not possible to cater to all (not even the majority) users with a step by step guide. "Everything" in that readme is critical information. It is all up front and center. We are of the belief that we should teach folks how to use something and provide the tools, so they can adapt it to their needs rather than spoonfeed them some information and expect them to copy paste. Teach a man to fish and all. You already followed existing guides (by others) and weren't satisfied. You won't be satisfied with a guide unless it was written specifically for you, with your software and hardware environment in mind and with the exact apps you want to reverse proxy. I suggest you contact the authors of those guides and videos with your requests. With regards to your redirect issue, it may be browser caching of 301 redirects. Try a different browser/machine and if it works, clear the cache of the first browser.

You should be able get around that specific limit by changing the subdomains

I host production websites on vps via this docker. Any delay the docker network may add is not noticeable

Did you try restarting your router? Is the delay present even when you connect from outside your lan, ie. on your phone using the cell data? To me it sounds like it's a lan related issue rather than nginx or docker

You can check the nginx logs in the config folder

You can use sub-subdomains with duckdns. They all automatically forward to your main subdomain ip. You do need to add those to your subdomains variable in the container settings, though

Why don't you use the preset conf for ombi? https://github.com/linuxserver/docker-letsencrypt/blob/master/root/defaults/proxy-confs/ombi.subfolder.conf.sample Also, I wouldn't recommend copying and pasting full configs. As you can see, you duplicated the default server parameter somehow. You can only have one default server per listening port per scheme

https://docs.docker.com/network/bridge/#differences-between-user-defined-bridges-and-the-default-bridge And here: https://blog.linuxserver.io/2017/10/17/using-docker-networks-for-better-inter-container-communication/ Github page tells you to read the preset conf readme: https://github.com/linuxserver/docker-letsencrypt/blob/master/README.md#site-config-and-reverse-proxy

You read it and still ignored it the first time. I doubt putting it in the first post would make a difference.

You have an extra "}" right above the sab location. Delete that and restart

Default goes in that location. Proxy-control is not one of the default ones and must have been user generated. The location should be referenced in the default site config. Post your log along with the default site config and we'll take a look

Please read the manual. We put a lot of time and effort into them: https://github.com/linuxserver/docker-letsencrypt/blob/master/root/defaults/proxy-confs/_readme#L21 It needs to be a "user defined" bridge network, not the default

Did you read and follow the readme in that folder?

It's already in there: https://github.com/linuxserver/docker-letsencrypt/blob/master/Dockerfile#L36

Make sure you're forwarding udp and not tcp And also make sure you're forwarding 1194 to 1194