[BUG] Connection refused depending on external ports

[GrgMdmn]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

My nextcloud website is:

• accessible through swag using mydomain.duckdns.org/nextcloud/ address regardless of the ports on my nextcloud docker
• accessible through 192.168.1.59:nextcloud_external_port (regardless of the ports values)

From any of my other device, running on local network (smartphone, laptop), nextcloud website is:

• not accessible through swag using 192.168.1.59:10443/nextcloud (swag docker ports are 10443:443) when my nextcloud docker ports are 1443:443. "Connection refused". However, interesting to notice that 192.168.1.59:10443/nextcloud request has been processed (at least partly) since another adress is returned : 192.168.1.59:10443/nextcloud/login :
  
  (sorry for french text). Moreover, using curl -i request seems to be honored without any issue even on my laptop.
• accessible through swag using 192.168.1.59:10443/nextcloud (swag docker ports are 10443:443) when my nextcloud docker ports are 443:443

From the server system: everything is accessible, regardless of the ports values

Since the problem is only happening through a SWAG reverse proxy local call, I suppose that I should post here.

Expected Behavior

local address + SWAG external port + nextcloud subfolder suffix should work :

• regardless of the ports values for nextcloud
• regardless of the device plugged to the local network

Steps To Reproduce

With docker:

1. Configure a nextcloud container with 1143:443 ports
2. Configure a swag container with 10443:443 port + configure dns server etc.
3. Configure nextcloud subfolder config file (~/swag/config/nginx/proxy-confs/nextcloud.subfolder.conf.sample --> remove .sample )
4. Configure ~/nextcloud/config/www/nextcloud/config/config.php as described in ~/swag/config/nginx/proxy-confs/nextcloud.subfolder.conf comments
5. Make sure nextcloud and swag are sharing a docker server.
6. Restart Swag then Nextcloud containers
7. From another device wired to the local network : browse https://myserver.duckdns.org/nextcloud/ then https://nas-ip-address:10443/nextcloud/

Environment

- OS: OpenMediaVault 7.4.7-1 (sandworm)
- How docker service was installed: using omv-compose

CPU architecture

x86-64

Docker creation

swag container yaml:

---
# https://github.com/linuxserver/docker-swag
services:
  swag:
    image: lscr.io/linuxserver/swag:latest
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - URL=myserver.duckdns.org
      - VALIDATION=http
#      - SUBDOMAINS=www, #optional
      - CERTPROVIDER= #optional
      - DNSPLUGIN=cloudflare #optional
      - PROPAGATION= #optional
      - EMAIL=#optional
      - ONLY_SUBDOMAINS=false #optional
      - EXTRA_DOMAINS= #optional
      - STAGING=false #optional
    volumes:
      - CHANGE_TO_COMPOSE_DATA_PATH/swag/config:/config
    ports:
      - 10443:443
      - 10080:80 #optional
    restart: unless-stopped
    networks:
      - common_network
networks:
  common_network:
    driver: bridge

nextcloud container yaml:

---
# https://hub.docker.com/r/linuxserver/nextcloud
# https://docs.linuxserver.io/images/docker-nextcloud
# only x86-64 and arm64 are supported
services:
  nextcloud:
    image: lscr.io/linuxserver/nextcloud:latest
    container_name: nextcloud
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - CHANGE_TO_COMPOSE_DATA_PATH/nextcloud/config:/config
      - /srv/mergerfs/Main_NAS_Volume/Nextcloud:/data
    ports:
      - 1443:443
    restart: unless-stopped
    networks:
      - swag_common_network
networks:
  swag_common_network:
    external: true

Container logs

Output of docker logs swag:

docker logs swag
[migrations] started
[migrations] 01-nginx-site-confs-default: skipped
[migrations] done
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   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:    1000
User GID:    1000
───────────────────────────────────────
Linuxserver.io version: 2.11.0-ls324
Build-date: 2024-09-14T03:24:47+00:00
───────────────────────────────────────
    
using keys found in /config/keys
Variables set:
PUID=1000
PGID=1000
TZ=Etc/UTC
URL=myserver.duckdns.org
SUBDOMAINS=
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=false
VALIDATION=http
CERTPROVIDER=
DNSPLUGIN=cloudflare
EMAIL=
STAGING=false

Using Let's Encrypt as the cert provider
E-mail address entered:
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

Output of docker logs nextcloud:

docker logs nextcloud
[migrations] started
[migrations] 01-nginx-site-confs-default: skipped
[migrations] 02-default-location: skipped
[migrations] done
───────────────────────────────────────

      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1000
User GID:    1000
───────────────────────────────────────
Linuxserver.io version: 29.0.3-ls328
Build-date: 2024-07-02T11:52:20+00:00
───────────────────────────────────────
    
using keys found in /config/keys
Initializing nextcloud 29.0.3.4 (this can take a while) ...
Setting permissions
Initializing finished
[custom-init] No custom files found, skipping...
[ls.io-init] done.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[aptalca]

SWAG/nginx is set up to serve/proxy at the domain, not IP

[GrgMdmn]

SWAG/nginx is set up to serve/proxy at the domain, not IP

Hello ! Here is the logical diagram of my understanding : requesting public_duckdns_domain/nextcloud --> public_router_ip:443/nextcloud --> nas_local_ip:external_swag_port/nextcloud --> nas_nextcloud_docker:docker_internal_port (where internal port is always 443 and set in ~/swag/config/nginx/proxy-confs/nextcloud.subfolder.conf as $upstream_port variable)

Why, when locally consulting nas_local_ip:external_swag_port/nextcloud which is part of the diagram, is there an error ?

Moreover, when the external port of nextcloud is 443, using nas_local_ip:external_swag_port/nextcloud is working !

[aptalca]

That's not an accurate diagram. Browser connecting to an IP is not the same thing as the packet getting forwarded to a different IP:port and they are not the same as SWAG reverse proxying a connection. Those are 3 different types of operation.

But in a nutshell, when the browser checks the dns records and then attempts to connect to the IP, it sends the domain/url info in headers so nginx knows what to serve/proxy. When you attempt a direct connection to an IP, you are not sending those headers so nginx uses the default server block because it doesn't know what url you're requesting.

In any case, you should read up on the reverse proxy basics as these questions are way out of scope in this issue. If you have further questions, you can ask in #other-support channel on our discord.

Closing.

[GrgMdmn]

That's not an accurate diagram. Browser connecting to an IP is not the same thing as the packet getting forwarded to a different IP:port and they are not the same as SWAG reverse proxying a connection. Those are 3 different types of operation.

But in a nutshell, when the browser checks the dns records and then attempts to connect to the IP, it sends the domain/url info in headers so nginx knows what to serve/proxy. When you attempt a direct connection to an IP, you are not sending those headers so nginx uses the default server block because it doesn't know what url you're requesting.

In any case, you should read up on the reverse proxy basics as these questions are way out of scope in this issue. If you have further questions, you can ask in #other-support channel on our discord.

Closing.

Ok, thank you for answering, I am sorry having taken your time. I will check the doc and learn :)