aptalca

Funny you ask for info. We need a lot more info from you

Post a screenshot of your container settings

Read the last couple pages

Arch packages won't work, the others are docker images We don't compile nginx or the modules, because that would be a support and maintenance nightmare. If new packages are needed, you can PR to alpine. That's what I do: https://github.com/alpinelinux/aports/pull/6762 https://github.com/alpinelinux/aports/pull/7710

No brotli package on alpine: https://pkgs.alpinelinux.org/packages?name=*brotli*&branch=v3.9&arch=x86_64

Ironically, macvlan blocks host connections for security as well

With macvlan but it blocks the connection between the host and the container. Why do you need to give it a different IP?

That's macvlan and it blocks the connection between the host and the container

Another user had issues with adguard blocking it. Your issue is likely similar, possibly pi-hole

If there is no setting for http auth, that usually means it doesn't work with it. Nextcloud has its own auth built in so likely it collides with http auth. Do you mean br0? That's macvlan, not bridge, and it blocks connections between host and the containers on it. But I'm making assumptions because you are not providing enough info to understand the situation.

Edited my post above to add info on how to get redirect to www working. What you want to do is, only catch the naked domain and redirect it to www. You don't want ombi.domain.com to redirect to www.domain.com

Change that section back to the defaults: https://github.com/linuxserver/docker-letsencrypt/blob/master/root/defaults/default#L5-L10 Right now it is only catching www.domain.com and it's redirecting it to www.domain.com on 443. The defaults catch everything and redirect it to the https version of whatever's requested. Then you can create a second block where it listens on 443, the server name is domain.com and redirects to www.domain.com

Ie. nextcloud.subdomain.conf

Yes, edit the proxy confs to uncomment the relevant lines. Instructions in there. If you're going to use http auth, first generate the .htpasswd as described in the readme

The webserver is published in two ways: 1. Through the admin gui port (defined in container settings) 2. On the tcp and udp connection ports. You should disable the second one in the openvpn-as gui. And do not make the 943 port available on the internet. That way the gui will only be available on lan

Check your mtu settings on your router

You can set it to anything you like. But that folder has to be mapped in container settings and in nginx you will use the container side of the mount. So if you map /mnt/user/webfiles as /webfiles in container settings, set the root to /webfiles so it will use that share

Stop the container

Did you read the post before yours?

Guys, it's all in the official readme on GitHub and docker hub. Use bridge networking, don't set the interface variable, make sure your port mapping is correct (@syniex yours is not) and add the cap-add statement. The unraid template was updated a long time ago but you may have to update it manually for existing setups. Or, you can remove the container (keep the appdata config folder) and recreate from a fresh new template from the community apps with the same appdata folder.

Bridge networking? Post your container settings

Try inside the http block

That's an unrelated issue due to the alpine lua package. No fix for that yet, but it's not the cause of your proxy issue

Perhaps you can add it to nginx.conf outside of all the server blocks so it gets inherited by them Pay attention to all the "include" statements. They literally mean copy and paste that file right here. That's how nginx starts with the main nginx.conf, imports all the included files and creates a giant config file that it then sorts through

From a networking perspective, yes, you can access other subnets. I have devices on vlans on different subnets and I define those subnets in openvpn-as gui settings as accessible and I can access them. One thing you need to keep in mind is the "security" feature of macvlan. If you used that for any containers, they won't be accessible by the host or anything that uses the host's network interface