Greetings,

As the title says, Unraid behind an NGINX reverse proxy initially works, but will become unresponsive in ~30-45 seconds.

* This problem may occur on older versions, I just started using Unraid again

* I am using NGINX reverse proxy function

* NGINX lives on a system that is external to Unraid, but internal to my network

* Neither NGINX nor Unraid have exposure to the Internet

* DNS resolution is happening internally, no external influence

* The connection (unraid.domain.com) works fine - websockets enabled. But after 30-45 seconds or so, the websockets stop updating. The websocket stuff - graphs, drive rw - freezes in place

* I use many websocket-based services behind this reverse proxy, Unraid is the only one with issues

* Affects Firefox and Chrome

* Affects Windows and Linux

When this occurs, I can still navigate using the menu buttons. And when I do click one, everything works fine again for about 30-45 more seconds before the websockets die again.

My NGINX reverse proxy configuration is as follows:

server {

listen 443 ssl http2;

listen [::]:443 ssl http2;

server_name unraid.domain.com;

include ./conf.d/domain.com.sslsettings;

access_log /var/log/nginx/unraid-access.log;

error_log /var/log/nginx/unraid-error.log;

location / {

proxy_pass https://192.168.10.40:443;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection "upgrade";

proxy_read_timeout 300s;

proxy_send_timeout 300s;

proxy_connect_timeout 75s;

proxy_buffering off;

}

}

I did try disabling HTTPS, but this didn't change anything. I think the SSL errors are a red herring:

unraid-error.log:

2025/06/18 20:50:14 [crit] 4090#4090: 1259 SSL_do_handshake() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading) while SSL handshaking, client: 192.168.10.10, server: 0.0.0.0:443
2025/06/18 20:50:14 [crit] 4089#4089: 1260 SSL_do_handshake() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading) while SSL handshaking, client: 192.168.10.10, server: 0.0.0.0:443
2025/06/18 22:04:22 [crit] 4089#4089: 3583 SSL_read() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading) while processing HTTP/2 connection, client: 192.168.10.10, server: 0.0.0.0:443
2025/06/18 22:04:38 [crit] 4090#4090: 3688 SSL_do_handshake() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading) while SSL handshaking, client: 192.168.10.10, server: 0.0.0.0:443
2025/06/18 22:05:11 [crit] 4090#4090: 3584 SSL_read() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading) while processing HTTP/2 connection, client: 192.168.10.10, server: 0.0.0.0:443
2025/06/18 22:05:16 [crit] 4090#4090: 3702 SSL_read() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading) while proxying upgraded connection, client: 192.168.10.10, server: unraid.domain.com, request: "GET /sub/cpuload,update1,update2,update3 HTTP/1.1", upstream: "https://192.168.10.40:443/sub/cpuload,update1,update2,update3", host: "unraid.domain.com"
2025/06/18 22:05:16 [crit] 4089#4089: 3695 SSL_read() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading) while proxying upgraded connection, client: 192.168.10.10, server: unraid.domain.com, request: "GET /sub/wlan0 HTTP/1.1", upstream: "https://192.168.10.40:443/sub/wlan0", host: "unraid.domain.com"
2025/06/18 22:05:16 [crit] 4090#4090: 3705 SSL_read() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading) while proxying upgraded connection, client: 192.168.10.10, server: unraid.domain.com, request: "GET /sub/session,var,notify HTTP/1.1", upstream: "https://192.168.10.40:443/sub/session,var,notify", host: "unraid.domain.com"
2025/06/18 22:05:16 [crit] 4090#4090: *3752 SSL_read() failed (SSL: error:0A000126:SSL routines::unexpected eof while reading) while processing HTTP/2 connection, client: 192.168.10.10, server: 0.0.0.0:443

Anyone running a similar setup that has working websockets?

Im running SWAG (nginx revrse proxy by linuxserver)

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name nas.*;

    include /config/nginx/ssl.conf;
    include /config/nginx/access.conf;

    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 10.0.0.2;
        set $upstream_port 443;
        set $upstream_proto https;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }
}

No issues.

Edited June 20, 20251 yr by MowMdown

Interesting. Could I get a look inside those conf files? Everything you pasted is pretty boilerplate.

access.conf is my allow/deny rules for only allowing private IP ranges, so that one you can ignore entirely.

resolver.conf:

# This file is auto-generated only on first start, based on the container's /etc/resolv.conf file. Feel free to modify it as you wish.

resolver  10.0.0.1 valid=30s;

proxy.conf:

## Version 2023/02/09 - Changelog: https://github.com/linuxserver/docker-swag/commits/master/root/defaults/nginx/proxy.conf.sample
# Timeout if the real server is dead
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
# Proxy Connection Settings
proxy_buffers 32 4k;
proxy_connect_timeout 240;
proxy_headers_hash_bucket_size 128;
proxy_headers_hash_max_size 1024;
proxy_http_version 1.1;
proxy_read_timeout 240;
proxy_redirect http:// $scheme://;
proxy_send_timeout 240;
# Proxy Cache and Cookie Settings
proxy_cache_bypass $cookie_session;
#proxy_cookie_path / "/; Secure"; # enable at your own risk, may break certain apps
proxy_no_cache $cookie_session;
# Proxy Header Settings
proxy_set_header Connection $connection_upgrade;
proxy_set_header Early-Data $ssl_early_data;
proxy_set_header Host $host;
proxy_set_header Proxy "";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Method $request_method;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-Uri $request_uri;
proxy_set_header X-Original-Method $request_method;
proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
proxy_set_header X-Real-IP $remote_addr;

ssl.conf:

## Version 2024/12/06 - Changelog: https://github.com/linuxserver/docker-baseimage-alpine-nginx/commits/master/root/defaults/nginx/ssl.conf.sample

### Mozilla Recommendations
# generated 2024-12-06, Mozilla Guideline v5.7, nginx 1.26.2, OpenSSL 3.3.2, intermediate config, no OCSP
# https://ssl-config.mozilla.org/#server=nginx&version=1.26.2&config=intermediate&openssl=3.3.2&ocsp=false&guideline=5.7

ssl_certificate /config/keys/cert.crt;
ssl_certificate_key /config/keys/cert.key;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
ssl_session_tickets off;

# curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
ssl_dhparam /config/nginx/dhparams.pem;

# intermediate configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

# HSTS (ngx_http_headers_module is required) (63072000 seconds)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# Optional additional headers
#add_header Cache-Control "no-transform" always;
#add_header Content-Security-Policy "upgrade-insecure-requests; frame-ancestors 'self'" always;
#add_header Permissions-Policy "interest-cohort=()" always;
add_header Referrer-Policy "same-origin" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
#add_header X-UA-Compatible "IE=Edge" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Robots-Tag "noindex, nofollow, nosnippet, noarchive";

Edited June 20, 20251 yr by MowMdown

Thank you for pasting these. Unfortunately, none of these helped with the issue. I'm running the proxy on AlmaLinux, which uses NGINX 1.20 by default. I made some changes with DNF and got it to install 1.26 where the issue yet persists. Pretty much at a loss as to why it does this. I even took a look at the NGINX config that Unraid is using, and I didn't see anything out of the ordinary.

Did anyone solve this? I am struggling with the same, trying to use a domain internally so i dont have that nagging "error" message when i try to access the ip directly (and easier to write the domain name)

No, I never found the solution. I just gave up. I got around it by doing this:

Domain I wanted to go to Unraid: unraid.domain.com.

Domain that now goes to Unraid: unraid.dev.domain.com.

So basically my setup is as follows:

DNS: unraid.domain.com = reverse proxy IP

DNS: unraid.dev.domain.com = unraid box IP

Reverse proxy: 301 redirect unraid.domain.com TO unraid.dev.domain.com

Browsing to unraid.domain.com redirects to unraid.dev.domain.com, which points directly to Unraid.

Do you have multiple IP addresses on the box? The 30-45 second timeout can be caused asymmetric routing when your firewall kills the tcp session.

2 hours ago, striker001983 said:

Do you have multiple IP addresses on the box? The 30-45 second timeout can be caused asymmetric routing when your firewall kills the tcp session.

Yes, kind of, i have unRAID in a VM on Proxmox (yes i know i know), i have set it up to accept all my vlan's, but in unRAID i have set up my primary ip (no vlan) as main ip, and one of the vlan's for my docker containers, can give diagnostic file or screenshots of the setup it needed

2 hours ago, striker001983 said:

Do you have multiple IP addresses on the box? The 30-45 second timeout can be caused asymmetric routing when your firewall kills the tcp session.

I do not.