They finally added the last bit of data to this Session store that broke the whole application. 16MB of data being read/written from store on every http request. 50% of all http request processing was handling the Session middleware.
I hate developers who don’t spend the very minimum to understand the environment they work in.
When connected to your internal network, what is the results of:
nslookup sub.domain.tld AGH.IP.Address
This should respond authoritative with the IP you need to access NPM’s VIP IP address. If that is not the case, let us see your AGH configuration for your sub.domain.tld.
If that does return the correct IP, verify that it responds to https using curl on Linux or windows (replace curl with curl.exe)
curl -vvvI https://sub.domain.tld/
If this is not connecting or showing a cert error then there’s a misconfiguration on the NPM side. Screenshots of your site configuration for one of the sites would be helpful. The domain name should match sub.domain.tld (not your duckdns) and be bound to the let’s encrypt cert.
If I had to guess, the container station might be giving the docker container a new network/ip address, one that the NAS is not using so that port 443 works and doesn’t conflict with the NAS. If you start the container station then inspect the container you might see how they do it, but macvlan is typically how you would configure it.
services: my-lan-service: image: nginx:latest container_name: lan_container # 1. Attach the service to the custom macvlan network networks: lan_network: ipv4_address: 192.168.1.200 # The dedicated LAN IP for this container # 2. Ports are exposed directly to the LAN; do NOT use the "ports" block restart: unless-stopped networks: lan_network: driver: macvlan driver_opts: parent: eth0 # Change to your host's physical network interface name ipam: config: - subnet: 192.168.1.0/24 # Matches your physical local network setup gateway: 192.168.1.1 # Your physical router IP