However, in the case of vaultwarden, if you connect to the domain (vault.mydomain.com ) specified in ‘vaultwarden.subdomain.conf’, it will automatically go to WordPress in the root domain (mydomain.com ).
Attempted to resolve the issue:
Generate swag certificate as Cloudflare Wildcard.
As noted in ‘vaultwarden.subdomain.conf’, the container name of the vaultwarden is vaultwarden, and the WebSocket variable is also activated.
There was a correction in “nginx.conf”. Modified ‘client_max_body_size’ in ‘main server block’ to 1024M.
The reverse proxy works the same way for other containers, but I don’t know why. I don’t know exactly which problem it is, but I’m asking if there’s anything I missed out on the swag setting.
The only modification made in ‘vaultwarden conf’ is the subdomain CNAME, which was recognized normally through the auto reload of docker mods, and there was no problem with the nginx reload that was done manually. Of course, I deleted ‘.sample’ after ‘conf’ in the file name.
I’ll try again step by step tomorrow. Thank you for your advice.
Please let me know if there should be other additional logs, etc.
Post the output of docker exec swag ls -al /config/nginx/proxy-confs/vaultwarden.subdomain.conf
and docker exec swag cat /config/nginx/proxy-confs/vaultwarden.subdomain.conf
$ docker exec swag ls -al /config/nginx/proxy-confs/vaultwarden.subdomain.conf
-rw-rw-r-- 1 abc abc 3423 Jun 2 08:11 /config/nginx/proxy-confs/vaultwarden.subdomain.conf
$ docker exec swag cat /config/nginx/proxy-confs/vaultwarden.subdomain.conf
## Version 2023/05/31
# make sure that your vaultwarden container is named vaultwarden
# make sure that your dns has a cname set for vaultwarden
# set the environment variable WEBSOCKET_ENABLED=true on your vaultwarden container
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name vault.*;
include /config/nginx/ssl.conf;
client_max_body_size 128M;
# enable for ldap auth (requires ldap-location.conf in the location block)
#include /config/nginx/ldap-server.conf;
# enable for Authelia (requires authelia-location.conf in the location block)
#include /config/nginx/authelia-server.conf;
# enable for Authentik (requires authentik-location.conf in the location block)
#include /config/nginx/authentik-server.conf;
location / {
# enable the next two lines for http auth
#auth_basic "Restricted";
#auth_basic_user_file /config/nginx/.htpasswd;
# enable for ldap auth (requires ldap-server.conf in the server block)
#include /config/nginx/ldap-location.conf;
# enable for Authelia (requires authelia-server.conf in the server block)
#include /config/nginx/authelia-location.conf;
# enable for Authentik (requires authentik-server.conf in the server block)
#include /config/nginx/authentik-location.conf;
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app vaultwarden;
set $upstream_port 80;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
location ~ ^(/vaultwarden)?/admin {
# enable the next two lines for http auth
#auth_basic "Restricted";
#auth_basic_user_file /config/nginx/.htpasswd;
# enable for ldap auth (requires ldap-server.conf in the server block)
#include /config/nginx/ldap-location.conf;
# enable for Authelia (requires authelia-server.conf in the server block)
#include /config/nginx/authelia-location.conf;
# enable for Authentik (requires authentik-server.conf in the server block)
#include /config/nginx/authentik-location.conf;
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app vaultwarden;
set $upstream_port 80;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
location ~ (/vaultwarden)?/api {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app vaultwarden;
set $upstream_port 80;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
location ~ (/vaultwarden)?/notifications/hub {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app vaultwarden;
set $upstream_port 3012;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
location ~ (/vaultwarden)?/notifications/hub/negotiate {
include /config/nginx/proxy.conf;
include /config/nginx/resolver.conf;
set $upstream_app vaultwarden;
set $upstream_port 80;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
}
}
Make sure you restart the container, try to access https://vault.domain.com from outside of your lan, preferably on a cell phone with wifi turned off, and in incognito. The issue may also have been browser cache.
This reply is a wrong solution. Please refer to the article below.
The problem has been resolved. Let me explain the process.
First of all, the problem with the browser cache was correct. However, a more serious problem occurred with Docker Mods’ Auto Proxy.
In the process of rebooting the server, I found that Auto Proxy reloads configurations that have already been proxied from the Swag container.
At first, I didn’t think much of this, but there was a problem that the proxy that was working properly on the top did not proxy after a Swag container restart, or after a server reboot.
I deleted Auto Proxy from Docker Mods, and now all proxies work fine. (Advice on browser cache was also a big help)
I’m not sure how these problems appear, and it might be just for me. But if anyone has the same problem, I hope this article helps.
Try connecting as a client on a different network from the existing environment.
If you are using Docker Mods Auto Proxy, and the proxy hangs up every reboot or reload, disable it.
I’m confused. You never mentioned you were using auto proxy. Based on the command output you provided, vaultwarden was proxied manually. Was it proxied through auto proxy as well?
When I create the container for the first time, it seems to be proxyed normally through auto proxy. However, in my case, there was a problem with the browser cache, so I couldn’t access it at the time of initial creation, and I think there was an unknown problem as the auto proxy mentioned above was regenerated for some reason during the reload or reboot of the swag container.
I don’t know how to explain it because I don’t know the relevant knowledge. I’m sorry.
If you’re using auto proxy, you don’t need to create a proxy conf manually. Auto proxy handles that. You can delete the vaultwarden.subdomain.conf you created.
The reason it didn’t work for you the first time is because auto proxy by default sets the server name to containername.domain.com so you had to access it at https://vaultwarden.domain.com
You can override the server name with another label that is listed in the auto proxy readme
Are you saying that if you specify the desired CNAME in the docker-compose.yml labels: (according to the Github document, swag_url, or swag_address?), instead of modifying the CNAME inside after the conf creation, the auto proxy will reflect it on its own?
It was my mistake. Thank you very much for your detailed explanation. I will correct the above article.
I don’t know what you mean by that. There is nothing for you to modify. The confs that the auto proxy mod creates are inside the container and are not user accessible. Auto proxy settings are handled entirely by labels in the proxied container.
Yes, you would need to set the label swag_url=vault.domain.com (change it to whatever url oyu’d like to access it at).
I thought the role of auto proxy was to create a ‘conf sample’ of proxy-confs folder in the swag config folder, and I thought I was modifying it manually, so I was doing that.
Ah, gotcha. No, the proxy conf samples are included with SWAG. The default behavior is that you would rename them to activate and edit as necessary.
Auto proxy is an optional mod that automates activation and editing of the confs so you don’t have to do it manually. You just add the labels to the other containers and that’s it.