Thanks for getting back to me,
Here’s an example of the kind of timings i’m seeing which are the problem (this is from the trace file on the github as well):
2026-09-07 17:10:16.2|Trace|Http|Res: 62 [GET] /928-6c5db8e039056b789d20.js.map: 200.OK (10873 ms)
That’s 10.8 seconds in radarr logs which flows through to what i’m seeing in the waterfall (that js file, another one and a css file having load times of 10, 7 and 3 seconds respectively while blocking.
Given it’s showing up in sonarr logs I was hoping there might be some clues around it - parsing the logs is beyond me. Challenging as there’s no actual error to be drawn to!
Tried forms instead of basic, with certificates on and off - no changes. NGINX logs totally clear - because ultimately the file is coming through (HTTP200) without seemingly failing, it’s just taking 10 seconds to get through.
Tried a LOT of different NGINX variables, couple of hours working through ChatGPT options for various settings but ultimately nothing changed and got to the point where it was just making circular changes.
I don’t have the time to try another reverse proxy tonight i’m afraid but may be able to tomorrow. My NGINX config is below and the location / code is a direct copy from the wiki example. I went back to that to remove any of my config issues, no change:
server {
listen 80; server_name sonarr.domain.com;
include snippets/letsencrypt.conf;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name sonarr.domain.com;
add_header Strict-Transport-Security "max-age=31536000;
includeSubDomains" always;
ssl_certificate /etc/letsencrypt/live/domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/domain.com/chain.pem;
include snippets/ssl.conf;
include snippets/letsencrypt.conf;
access_log /var/log/nginx/sonarr.comain.com.log;
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_redirect off;
proxy_http_version 1.1;
proxy_pass http://192.168.1.23:38082;
}
}
One of the other main reasons why I think this is on the server side is that i’ve changed nothing my end at all. Only automated sonarr updates and this afflicts both sonarr and radarr and both started at the same time (about 2 months ago ish?). I’m wary of some config change in the server itself that I may need to reflect/modernise in the way I run NGINX - but I can’t find this.
image of the three files afflicted in the waterfall
the waterfall breakdown for one of them - slow receiving speed?
This made me thing of various issues with keepalive, concurrent connections, headers, buffers etc etc on NGINX - nothing made a difference there. The speed of sonarr on the dashboard once past the initial loading phase is totally fine - so it’s not a global slow speed issue via NGINX for sure, just the post-login phase. The login page itself appears instantly as well on initial connection
