thatonethur Posted July 31, 2023 Share Posted July 31, 2023 (edited) Trying to rack my brain as to what changed as SWAG as worked perfect for years. My scenario: Multiple dockers (primarily used for Plex and Emby) proxied using SWAG (latest version). Local SWAG docker is on separate "proxynet" network per SpaceInvaderOne's video and points to local port of 3553. From my router/firewall, I port forward inbound traffic to 3553 docker IP (which is same as Unraid box) NOTE: I have another docker container that connects directly to a specific port and while 443 is timing out, the other specific port is working just fine. This narrows down the issue to SWAG specifically for me. Problem is that I can check my port 443 on home IP address and it works, and then 3 minutes later the connection is refused for another 2-3 minutes and then it's back up accepting connections again for the next 5 minutes and this pattern repeats. It alternates from connection succeeded to connection refused. I've seen nothing in the SWAG logs or Firewall logs for that matter, that is jumping out at me. I think my next step will be to delete the container and start from scratch. I had a failure on an ssd that config was stored on a few weeks ago and while every single other docker worked just fine when i restored data to it, perhaps something was missed. Any ideas? Edited July 31, 2023 by thatonethur other docker container with direct firewall bypass Quote Link to comment
Smith007 Posted July 31, 2023 Share Posted July 31, 2023 4 hours ago, alturismo said: may start reading your options docker, edit ... But this is to set up "internal" docker IP, isn't it? What I'm missing is how to assign additional docker host IPs, and how to steer containers to bind only to particular host IP (from those additional ones). Or am I mixing it all completely? 4 hours ago, alturismo said: also, this is not swag docker related, rather post or search in the general part/s. I know, and apologise. I wanted to start new general topic in Docker Containers forum, but there is no way to post there. Please move my questions to whatever place it fit best. Also - many thanks for helping me . Quote Link to comment
alturismo Posted July 31, 2023 Share Posted July 31, 2023 43 minutes ago, Smith007 said: But this is to set up "internal" docker IP, isn't it? nope, this is what you would like todo, let the docker run on its own network stack on a sep ip in your LAN enviroment ... Quote Link to comment
Smith007 Posted July 31, 2023 Share Posted July 31, 2023 1 hour ago, alturismo said: nope, this is what you would like todo, let the docker run on its own network stack on a sep ip in your LAN enviroment ... OK, I figured it out... First I needed to add additional 192.168.1.11/24 IP to default br0. Currently I'm doing in using sh commands, but looking for a way to make this change permanent, in a proper Unraid way - asked a question here. Then, in SWAG settings (or any other container) I defined the following port mappings: and voila - I have SWAG listening on 80/443 native ports, on dedicated IP. Quote tcp 0 0 192.168.1.11:443 0.0.0.0:* LISTEN 8444/docker-proxy tcp 0 0 192.168.1.11:80 0.0.0.0:* LISTEN 8456/docker-proxy Easy enough, all works like a charm . Any disadvantages of this solution I should consider? Quote Link to comment
alturismo Posted July 31, 2023 Share Posted July 31, 2023 Just now, Smith007 said: Any disadvantages of this solution I should consider? you can remove the weird entries you did in ports they are obsolete (as i described earlier before ...) Quote Link to comment
Smith007 Posted July 31, 2023 Share Posted July 31, 2023 56 minutes ago, alturismo said: you can remove the weird entries you did in ports they are obsolete (as i described earlier before ...) I'm not sure what you mean... Quote Link to comment
alturismo Posted July 31, 2023 Share Posted July 31, 2023 21 minutes ago, Smith007 said: I'm not sure what you mean... Quote Link to comment
Smith007 Posted July 31, 2023 Share Posted July 31, 2023 26 minutes ago, alturismo said: Yes but not sure why you considered them obsolete... Quote Link to comment
alturismo Posted July 31, 2023 Share Posted July 31, 2023 4 minutes ago, Smith007 said: Yes but not sure why you considered them obsolete... because since you run the docker on its own ip on its own stack ... you can enter whatever you want, it wont affect it anyhow ... it ll always listen on the running app native port(s) ... Quote Link to comment
danioj Posted July 31, 2023 Share Posted July 31, 2023 7 hours ago, thatonethur said: Trying to rack my brain as to what changed as SWAG as worked perfect for years. My scenario: Multiple dockers (primarily used for Plex and Emby) proxied using SWAG (latest version). Local SWAG docker is on separate "proxynet" network per SpaceInvaderOne's video and points to local port of 3553. From my router/firewall, I port forward inbound traffic to 3553 docker IP (which is same as Unraid box) NOTE: I have another docker container that connects directly to a specific port and while 443 is timing out, the other specific port is working just fine. This narrows down the issue to SWAG specifically for me. Problem is that I can check my port 443 on home IP address and it works, and then 3 minutes later the connection is refused for another 2-3 minutes and then it's back up accepting connections again for the next 5 minutes and this pattern repeats. It alternates from connection succeeded to connection refused. I've seen nothing in the SWAG logs or Firewall logs for that matter, that is jumping out at me. I think my next step will be to delete the container and start from scratch. I had a failure on an ssd that config was stored on a few weeks ago and while every single other docker worked just fine when i restored data to it, perhaps something was missed. Any ideas? Your post made me check my instance and the result was the same as yours. Swag not working. I don’t run anything fancy with mine, just host a basic text landing page. Anyway, immediately disabled my port forwarding and firewall rules while I investigated. Turns out, my custom network “proxynet” (we must have followed the same guide) has disappeared. Now, like you, I have had a docker config issue in the last few weeks which caused me to delete and recreate my docker image and subsequently reinstall on my containers. Figured all would be ok as config was intact. All I can think of is that this process has resulted in that custom network (done via command line if I remember) did not survive the docker image getting recreated. I’m pretty sure that once I recreate the custom proxynet network again and re-enable the port forwarding and firewall rules I’ll be back up and running. Will try that tomorrow and report back. Quote Link to comment
Smith007 Posted July 31, 2023 Share Posted July 31, 2023 4 minutes ago, alturismo said: because since you run the docker on its own ip on its own stack ... you can enter whatever you want, it wont affect it anyhow ... it ll always listen on the running app native port(s) ... Previously it was listening in 192.168.1.10 ports 180/1443. Now it listens on 192.168.1.11 ports 80/443, as I wanted it to... How it is not affecting it anyhow? I must be missing something... Quote Link to comment
alturismo Posted July 31, 2023 Share Posted July 31, 2023 3 hours ago, Smith007 said: Previously it was listening in 192.168.1.10 ports 180/1443. Now it listens on 192.168.1.11 ports 80/443, as I wanted it to... How it is not affecting it anyhow? I must be missing something... as mentioned ... THIS is what your container makes it listening on .11 (just different ip there, here its listening on .99 while Unraid ist on .2) port mappings down under are useless as obsolete ... but lets quit this now as it is not swag related at all, basic docker setup ... Quote Link to comment
alturismo Posted July 31, 2023 Share Posted July 31, 2023 1 hour ago, sirkuz said: Anyone else seeing this kind of issue or know how to resolve? can you ping the other dockers from swag console ? is host access still enabled in docker settings ? may restart docker service in terms you had a reboot between too ... known issue .... with enabled host access. Quote Link to comment
sirkuz Posted July 31, 2023 Share Posted July 31, 2023 10 minutes ago, alturismo said: can you ping the other dockers from swag console ? is host access still enabled in docker settings ? may restart docker service in terms you had a reboot between too ... known issue .... with enabled host access. dug a bit deeper on it and seems like its unraid networking related to the vlan bridge I have on an interface not routing properly. Disregard please (sorry I deleted the question before I saw a response). Quote Link to comment
sirkuz Posted July 31, 2023 Share Posted July 31, 2023 16 minutes ago, alturismo said: can you ping the other dockers from swag console ? is host access still enabled in docker settings ? may restart docker service in terms you had a reboot between too ... known issue .... with enabled host access. and yep... cycling the docker service did the trick 1 Quote Link to comment
Smith007 Posted July 31, 2023 Share Posted July 31, 2023 3 hours ago, alturismo said: as mentioned ... THIS is what your container makes it listening on .11 (just different ip there, here its listening on .99 while Unraid ist on .2) But I didn't put anything in the Fixed IP Address field... anyway, see the below :). 3 hours ago, alturismo said: port mappings down under are useless as obsolete ... but lets quit this now as it is not swag related at all, basic docker setup ... Agreed. I'm happy I got it working exactly the way I wanted it. Thanks again! Quote Link to comment
thatonethur Posted August 3, 2023 Share Posted August 3, 2023 On 7/31/2023 at 7:10 AM, danioj said: Your post made me check my instance and the result was the same as yours. Swag not working. I don’t run anything fancy with mine, just host a basic text landing page. Anyway, immediately disabled my port forwarding and firewall rules while I investigated. Turns out, my custom network “proxynet” (we must have followed the same guide) has disappeared. Now, like you, I have had a docker config issue in the last few weeks which caused me to delete and recreate my docker image and subsequently reinstall on my containers. Figured all would be ok as config was intact. All I can think of is that this process has resulted in that custom network (done via command line if I remember) did not survive the docker image getting recreated. I’m pretty sure that once I recreate the custom proxynet network again and re-enable the port forwarding and firewall rules I’ll be back up and running. Will try that tomorrow and report back. So my proxynet network still exists. I have no idea how to explain that it's constantly bouncing up and down status. I started using Uptimerobot to monitor if it's up and down and I can say that it bounces between up and down at least 30 times per day. Quote Link to comment
MikaelTarquin Posted August 10, 2023 Share Posted August 10, 2023 On 2/12/2023 at 5:39 AM, vurt said: I did, and modified the conf like this but it didn't work, still asked for password: # OPDS feed for eBook reader apps # Even if you use Authelia, the OPDS feed requires a password to be set for # the user directly in Calibre-Web, as eBook reader apps don't support # form-based logins, only HTTP Basic auth. location /opds/ { auth_basic off; include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app calibre-web; set $upstream_port 8083; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_set_header X-Scheme $scheme; } EDIT: Turned out it wasn't a reverse proxy issue for a change. Was on KOReader's end. How did you fix the issue? I've been trying to get Calibre-Web OPDS to work with my Kindle+KOReader over my reverse proxy, but so far have only had luck locally. Everything I try just results in KOReader saying "Authentication required for catalog. Please add a username and password." Quote Link to comment
Sinister Posted August 23, 2023 Share Posted August 23, 2023 Has anyone successfully gotten Authentik to work with swag ?. I have it properly reverse proxied and can access authentik via my external URL the issue is when trying to put an application like sonarr behind it all i get is error 500 internal server error. I have gone over many authentik guides trying to figure out whats not working but i just cant seem to figure out what seems to me like the last part server { listen 443 ssl; listen [::]:443 ssl; server_name myservername.*; include /config/nginx/ssl.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authentik 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 the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /login; # enable for Authentik include /config/nginx/authentik-location.conf; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_sonarr binhex-sonarr; proxy_pass http://$upstream_sonarr:8989; } location ~ (/sonarr)?/api { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_sonarr binhex-sonarr; proxy_pass http://$upstream_sonarr:8989; } } Quote Link to comment
Zeze21 Posted August 24, 2023 Share Posted August 24, 2023 (edited) Swag seems to not be able to communicate outside the docker network after several problems i had initially when upgrading from 6.11.5 to 6.12.3. I have a bit of a special setup: I have a fritzbox 7590 as router with dhcp disabled. it's Ipv4 is 10.10.10.1 with the subnetmask 255.255.0.0 I have a raspberry pi with adguard home running - it acts as my dns server and has dhcp enabled. It's Ipv4 adress is 10.10.10.2 and gives out ip adresses from 10.10.100.1 to 10.10.100.255 My smart home devices have all set ip adresses in th range of 10.10.11.1 to 10.10.11.255 Home assistant runs as VM and has the ipv4 10.10.11.1 My unraid server has 10.10.10.10 I have a windows 11 VM with 10.10.10.11 I have several docker containers (nextcloud, guacamole, home assistance and others) which run all as bridge and are accessible from their respective subdomains. While nextcloud, bitwarden and others work fine, Guacamole works semi (I can load up guacamole as service but can not connect to my VM) and home assistant just gives me a 502. To my understanding the common thing here is that swag seems to be unable connecting outside the dockernetwork itself. (at least that's how i would be able to explain why guacamole loads up fine but i can not connect to a vm and home assistant does not work) This is my docker config: nextcloud.subdomain.config: ## Version 2023/06/24 # make sure that your nextcloud container is named nextcloud # make sure that your dns has a cname set for nextcloud # assuming this container is called "swag", edit your nextcloud container's config # located at /config/www/nextcloud/config/config.php and add the following lines before the ");": # 'trusted_proxies' => ['swag'], # 'overwrite.cli.url' => 'https://nextcloud.example.com/', # 'overwritehost' => 'nextcloud.example.com', # 'overwriteprotocol' => 'https', # # Also don't forget to add your domain name to the trusted domains array. It should look somewhat like this: # array ( # 0 => '192.168.0.1:444', # This line may look different on your setup, don't modify it. # 1 => 'nextcloud.example.com', # ), server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name cloud.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 10.10.10.10; set $upstream_port 1443; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; # Hide proxy response headers from Nextcloud that conflict with ssl.conf # Uncomment the Optional additional headers in SWAG's ssl.conf to pass Nextcloud's security scan proxy_hide_header Referrer-Policy; proxy_hide_header X-Content-Type-Options; proxy_hide_header X-Frame-Options; proxy_hide_header X-XSS-Protection; # Disable proxy buffering proxy_buffering off; } } guacamole.subdomain.config: ## Version 2023/05/31 # make sure that your guacamole container is named guacamole # make sure that your dns has a cname set for guacamole server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name remote.*; include /config/nginx/ssl.conf; client_max_body_size 0; # 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 10.10.10.10; set $upstream_port 8088; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_buffering off; } } homeassistant.subdomain.config ## Version 2023/05/31 # make sure that your homeassistant container is named homeassistant # make sure that your dns has a cname set for homeassistant # As of homeassistant 2021.7.0, it is now required to define the network range your proxy resides in, this is done in Homeassitants configuration.yaml # https://www.home-assistant.io/integrations/http/#trusted_proxies # Example below uses the default dockernetwork ranges, you may need to update this if you dont use defaults. # # http: # use_x_forwarded_for: true # trusted_proxies: # - 172.16.0.0/12 server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name home.*; include /config/nginx/ssl.conf; client_max_body_size 0; # 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 10.10.11.1; set $upstream_port 8123; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } location ~ ^/(api|local|media)/ { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 10.10.11.1; set $upstream_port 8123; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } The swag logs give absolutely no error: [migrations] started [migrations] 01-nginx-site-confs-default: skipped [migrations] done usermod: no changes ─────────────────────────────────────── ██╗ ███████╗██╗ ██████╗ ██║ ██╔════╝██║██╔═══██╗ ██║ ███████╗██║██║ ██║ ██║ ╚════██║██║██║ ██║ ███████╗███████║██║╚██████╔╝ ╚══════╝╚══════╝╚═╝ ╚═════╝ Brought to you by linuxserver.io ─────────────────────────────────────── To support the app dev(s) visit: Certbot: https://supporters.eff.org/donate/support-work-on-certbot To support LSIO projects visit: https://www.linuxserver.io/donate/ ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 99 User GID: 100 ─────────────────────────────────────── using keys found in /config/keys Variables set: PUID=99 PGID=100 TZ=Europe/Berlin URL=mydomain.com SUBDOMAINS=cloud,heim,home,media,remote,robot,vaultwarden,vpn EXTRA_DOMAINS= ONLY_SUBDOMAINS=true VALIDATION=http CERTPROVIDER= DNSPLUGIN=cloudflare EMAIL= STAGING=false Using Let's Encrypt as the cert provider SUBDOMAINS entered, processing Sub-domains processed are: cloud.mydomain.com,heim.mydomain.com,home.mydomain.com,media.mydomain.com,remote.mydomain.com,robot.mydomain.com,vaultwarden.mydomain.com,vpn.mydomain.com No e-mail address entered or address invalid http validation is selected Certificate exists; parameters unchanged; starting nginx The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am). [custom-init] No custom files found, skipping... [ls.io-init] done. Server ready Just to clearify the log is with the correct domain not mydomain.com. Also the VMs work fine when connecting to them within my own network or via vpn (windows can be loaded up via rdp) Home assitant can be accessed via 10.10.11.1:8123 Can someone please help me out? Thank you all so much! Edited August 24, 2023 by Zeze21 Quote Link to comment
Zeze21 Posted September 12, 2023 Share Posted September 12, 2023 On 8/24/2023 at 10:07 AM, Zeze21 said: Swag seems to not be able to communicate outside the docker network after several problems i had initially when upgrading from 6.11.5 to 6.12.3. I have a bit of a special setup: I have a fritzbox 7590 as router with dhcp disabled. it's Ipv4 is 10.10.10.1 with the subnetmask 255.255.0.0 I have a raspberry pi with adguard home running - it acts as my dns server and has dhcp enabled. It's Ipv4 adress is 10.10.10.2 and gives out ip adresses from 10.10.100.1 to 10.10.100.255 My smart home devices have all set ip adresses in th range of 10.10.11.1 to 10.10.11.255 Home assistant runs as VM and has the ipv4 10.10.11.1 My unraid server has 10.10.10.10 I have a windows 11 VM with 10.10.10.11 I have several docker containers (nextcloud, guacamole, home assistance and others) which run all as bridge and are accessible from their respective subdomains. While nextcloud, bitwarden and others work fine, Guacamole works semi (I can load up guacamole as service but can not connect to my VM) and home assistant just gives me a 502. To my understanding the common thing here is that swag seems to be unable connecting outside the dockernetwork itself. (at least that's how i would be able to explain why guacamole loads up fine but i can not connect to a vm and home assistant does not work) This is my docker config: nextcloud.subdomain.config: ## Version 2023/06/24 # make sure that your nextcloud container is named nextcloud # make sure that your dns has a cname set for nextcloud # assuming this container is called "swag", edit your nextcloud container's config # located at /config/www/nextcloud/config/config.php and add the following lines before the ");": # 'trusted_proxies' => ['swag'], # 'overwrite.cli.url' => 'https://nextcloud.example.com/', # 'overwritehost' => 'nextcloud.example.com', # 'overwriteprotocol' => 'https', # # Also don't forget to add your domain name to the trusted domains array. It should look somewhat like this: # array ( # 0 => '192.168.0.1:444', # This line may look different on your setup, don't modify it. # 1 => 'nextcloud.example.com', # ), server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name cloud.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 10.10.10.10; set $upstream_port 1443; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; # Hide proxy response headers from Nextcloud that conflict with ssl.conf # Uncomment the Optional additional headers in SWAG's ssl.conf to pass Nextcloud's security scan proxy_hide_header Referrer-Policy; proxy_hide_header X-Content-Type-Options; proxy_hide_header X-Frame-Options; proxy_hide_header X-XSS-Protection; # Disable proxy buffering proxy_buffering off; } } guacamole.subdomain.config: ## Version 2023/05/31 # make sure that your guacamole container is named guacamole # make sure that your dns has a cname set for guacamole server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name remote.*; include /config/nginx/ssl.conf; client_max_body_size 0; # 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 10.10.10.10; set $upstream_port 8088; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; proxy_buffering off; } } homeassistant.subdomain.config ## Version 2023/05/31 # make sure that your homeassistant container is named homeassistant # make sure that your dns has a cname set for homeassistant # As of homeassistant 2021.7.0, it is now required to define the network range your proxy resides in, this is done in Homeassitants configuration.yaml # https://www.home-assistant.io/integrations/http/#trusted_proxies # Example below uses the default dockernetwork ranges, you may need to update this if you dont use defaults. # # http: # use_x_forwarded_for: true # trusted_proxies: # - 172.16.0.0/12 server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name home.*; include /config/nginx/ssl.conf; client_max_body_size 0; # 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 10.10.11.1; set $upstream_port 8123; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } location ~ ^/(api|local|media)/ { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app 10.10.11.1; set $upstream_port 8123; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } The swag logs give absolutely no error: [migrations] started [migrations] 01-nginx-site-confs-default: skipped [migrations] done usermod: no changes ─────────────────────────────────────── ██╗ ███████╗██╗ ██████╗ ██║ ██╔════╝██║██╔═══██╗ ██║ ███████╗██║██║ ██║ ██║ ╚════██║██║██║ ██║ ███████╗███████║██║╚██████╔╝ ╚══════╝╚══════╝╚═╝ ╚═════╝ Brought to you by linuxserver.io ─────────────────────────────────────── To support the app dev(s) visit: Certbot: https://supporters.eff.org/donate/support-work-on-certbot To support LSIO projects visit: https://www.linuxserver.io/donate/ ─────────────────────────────────────── GID/UID ─────────────────────────────────────── User UID: 99 User GID: 100 ─────────────────────────────────────── using keys found in /config/keys Variables set: PUID=99 PGID=100 TZ=Europe/Berlin URL=mydomain.com SUBDOMAINS=cloud,heim,home,media,remote,robot,vaultwarden,vpn EXTRA_DOMAINS= ONLY_SUBDOMAINS=true VALIDATION=http CERTPROVIDER= DNSPLUGIN=cloudflare EMAIL= STAGING=false Using Let's Encrypt as the cert provider SUBDOMAINS entered, processing Sub-domains processed are: cloud.mydomain.com,heim.mydomain.com,home.mydomain.com,media.mydomain.com,remote.mydomain.com,robot.mydomain.com,vaultwarden.mydomain.com,vpn.mydomain.com No e-mail address entered or address invalid http validation is selected Certificate exists; parameters unchanged; starting nginx The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am). [custom-init] No custom files found, skipping... [ls.io-init] done. Server ready Just to clearify the log is with the correct domain not mydomain.com. Also the VMs work fine when connecting to them within my own network or via vpn (windows can be loaded up via rdp) Home assitant can be accessed via 10.10.11.1:8123 Can someone please help me out? Thank you all so much! Ok the solution was simple the dockers i wanted to connect to the rest of the Network had to be in br0 mode. Hope anybody who has the same issue finds this helpful Quote Link to comment
klingon00 Posted September 23, 2023 Share Posted September 23, 2023 I like others have used Space Invader's instructions for setting up this container and everything has been fine for years until just recently after I applied the latest update to SWAG. I can still access my sites remotely from another network but I'm unable to access them from within my network. All I receive is that the connection was refused and to check my proxy settings. (ERR_CONNECTION_REFUSED) Any assistance here would be greatly appreciated. Quote Link to comment
Zeze21 Posted September 24, 2023 Share Posted September 24, 2023 To be honest I was in the same situation. Swag was running fine for (I want to say years but at least months) and I couldn't for the life of me figure out what was wrong. I switched to nginx proxy manager (there is one with a configuration web interface and box is it easy to set it up and it gives you a nice overview what is running)So yeah... I just don't use swag anymore...Gesendet von meinem Pixel 6 Pro mit Tapatalk Quote Link to comment
klingon00 Posted September 28, 2023 Share Posted September 28, 2023 Well, I can't explain it. I tried a bunch of things and nothing worked. I got busy with other things for a couple of days and I just sat down to try and figure the issue out and I noticed it's now working after several days of not working. I'm flabbergasted. Quote Link to comment
scb147 Posted October 4, 2023 Share Posted October 4, 2023 (edited) I am using a domain name, as I already had one. So I set up swag with qbittorrent, sonarr and radarr with no issues using those containers. I am trying to get sabnzbd working, but I can't seem to access it using the subdomain (works fine if I use local IP and port). The browser is not giving an error message, just a blank white screen with the favicon in the tab. The only entry in the nginx log for the subdomain is: [04/Oct/2023:09:50:11 -0400] "GET /favicon.ico HTTP/2.0" 200 5430 "https://nzb.mydomain.com/" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0" I did remove the url_base setting from the sabnzbd config. I also added the subdomains to the host_whitelist setting to the sabnzbd config as mentioned in the sabnzbd.subdomain.conf file from nginx. This is my sabnzbd.subdomain.conf file: ## Version 2023/05/31 # make sure that your sabnzbd container is named sabnzbd # make sure that your dns has a cname set for sabnzbd # edit the sabnzbd.ini host_whitelist to avoid hostname verification issues. This format: # host_whitelist = sabnzbd.domain.com, www.sabnzbd.domain.com server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name nzb.*; include /config/nginx/ssl.conf; client_max_body_size 0; # 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 sabnzbd; set $upstream_port 8080; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } location ~ (/sabnzbd)?/api { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app sabnzbd; set $upstream_port 8080; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } } The sabnzbd container in UnRAID is using 6060 (but in the sabnzbd config, it is still using 8080), as the qBittorrent container is using 8080. I tried changing the "set $upstream_port" entry to 6060, and I see the "Bad Gateway" message from nginx. Any suggestions on what might be wrong? EDIT: After messing around with this for most of the day, I noticed that if I attempt to load via my subdomain, I get this message in the nginx access.log: [04/Oct/2023:14:02:56 -0400] "GET / HTTP/2.0" 403 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/118.0" The http_referrer is "-". Does this mean the CNAME entry for my domain is not sending the subdomain? All my CNAME entries are the same, so I'm not sure why this one is working differently than the others. Edited October 4, 2023 by scb147 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.