Aaah I see makes sense yes.
And yes 441 was a typo here.
Thanks! 
Did you ever find a resolution to this? I am having the exact same scenario happen.
As crazy as it sounds, it just started working on it’s own after 2-3 days. I wish I could help you out because it was driving me nuts…
Every hour around the same time, I am having this massive (relative) processor and memory spike:
I’ve been able to track the activity spike down to the Nginx Proxy Manager where I’m getting this error at the same time. I am not familiar with nginx at all, thus using NPM, what should I do with/to the offending “/etc/letsencrypt/renewal/npm-7.conf” and how do I do it?
[12/16/2022] [2:14:24 PM] [SSL ] › ℹ info Renewing SSL certs close to expiry...
[12/16/2022] [2:14:29 PM] [SSL ] › ✖ error Error: Command failed: certbot renew --non-interactive --quiet --config "/etc/letsencrypt.ini" --preferred-challenges "dns,http" --disable-hook-validation
Renewal configuration file /etc/letsencrypt/renewal/npm-7.conf is broken.
The error was: expected /etc/letsencrypt/live/npm-7/cert.pem to be a symlink
.
0 renew failure(s), 1 parse failure(s)
at ChildProcess.exithandler (node:child_process:400:12)
at ChildProcess.emit (node:events:513:28)
at maybeClose (node:internal/child_process:1093:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)
I am struggelin with the fail2ban settings in the proxy manager. I have:
http:
use_x_forwarded_for: true
trusted_proxies:
- 172.30.32.0/23 # In Home Assistant we need to add the Docker subnet
- 127.0.0.1 # Add the localhost IPv4 address
- ::1 # Add the localhost IPv6 address
and as per docs (Fail2Ban - Home Assistant) i should add something to:
/mnt/user/appdata/letsencrypt/nginx/site-confs/default
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
But where exactly do i have to add it in the web interface of the add-on? In advanced there is a note
that the set_header commands are ignored and if i add the two locations / and /api/websocket i am getting errors in the log [homeassistant.components.http.forwarded] Too many headers for X-Forwarded-For: ['172.30.32.1', '172.30.32.1'] and the access from outside doesn’t work anymore…
Goal is that the real ip is shown in ha logs when there is a login with invalid credentials or something like this.
Someone can shed a light?
If these are the only requirements they should go in Advanced tab, something like this:
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
However, I strongly advise against putting together parts of code for which purpose is not entirely understood.
Thank you for the answer. My problem is not that i do not understand what the code does but to tell “nginx to use it” (let me call it my small knowledge of the syntax of the nginx addon). In my understanding nginx should add the external ip from where the request came to the x_forwarded_for header of the request, so home assistant (in my case) can evaluate this. Correct me if i am wrong.
Beside that, the code you gave makes the the proxy to go offline in the webinterface, and i would guess that proxy_set_header is a set_header directive it would not be used in the advanced tab (but in the custom locations of the addon)?
You might find useful post 210 for several examples of directives that go in the Advanced tab.
First, sorry i had doubts the advanced tab is the right location and thanks for pointing in this direction.
After deleting the custom locations the proxy went online again with your code, but then it gave me a 404 error. After adding the proxy_pass with my ip the login screen appeared again but past the login there was no connect.
I tried a lot and ended now in this config:
location / {
proxy_pass http://10.10.99.88:8123;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location /api/websocket {
proxy_pass http://10.10.11.99:8123/api/websocket;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
Everything works again, but it seems to be like without the code. A failed login comes from the hassio ip on the server:
Login attempt or request with invalid authentication from 15ef4d2f-esphome.local.hass.io (172.30.32.1)
(Don’t know why it’s name is from the esphome addon, but the ip is the same as the hassio interface - shown by ip addr show on the hosting debian).
No i am - again - at the end of my knowledge. 
As I understand reverse proxy, this is proxy that allow you access to docker network from outside.
So the correct configuration should be
location / {
proxy_pass http://172.30.32.1:8123;
But maybe I’m wrong about it.
And of course configuration.yaml should have
http:
use_x_forwarded_for: true
trusted_proxies:
- 172.30.33.0/24
Thank you, but the result is the same, in the ha logs the login attemp still comes from 172.30.32.1. But it was worth a try 
The use_x_forwarded_for option and the trusted proxies i have in my config.
This is my nginx working configuration, no errors. You can try this. Save your config and try mine.
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
server_name MY_DOMAIN.com;
ssl_certificate /ssl/fullchain.pem;
ssl_certificate_key /ssl/privkey.pem;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
listen [::]:443 ssl http2 default_server ipv6only=on;
ssl_protocols TLSv1.3;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
proxy_buffering off;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://172.30.32.1:8123;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_redirect http:// https://;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# proxy_set_header Connection $connection_upgrade;
}
}
Thank you, i will try tomorrow. Just to be sure, if you have a failed login, the ha logs show the ip adress of the client and not one of the internal ips, right?
Yes, that should be the case. When I play around with docker I usually get wrong login from my laptop ip address on local network.
Please excuse my poor knowledge, but where can i paste this config (if i understand it right, i have to change it to my server_name and nothing else)? Just in the advanced tab seems not to work.
I use NGINX Home Assistant SSL proxy addon. You can have a config file with this addon. What I posted here was a nginx config file for my domain.
You have to create config file in /share/ directory and on start nginx will read this config file and set up reverse proxy.
The name of the file can be set in config menu or you can use a . ie.
nginx_proxy-.conf for the name of the file nginx_proxy-my_domain.conf
Edit:
I put asteriks sign but it doesnt show it, but I hope you understand that you can use this sign instead of any other letter.
Thanks again, but still no luck. I installed the SSL Proxy Addon and set the customize part to yours:
active: true
default: nginx_proxy_default*.conf
servers: nginx_proxy/*.conf
In the share directory i made a nginx_proxy folder and created a new config file nginx_proxy_ha_default.conf and put your config in. I changed the server_name to mine and started the addon. Access and everything works, but the logs shows again only the internal ip in the logs (see above, no change).
I am now thinking my problem is not the nginx but anything else in my configuration, my guess is some other component is changing the header after nginx (but that is only a guess). I have a home assistant supervised installation on debian bullseye, and the only networking thing i changed was the ipv6 addr-gen-mode to eui64 (to get a stable ipv6 adress, but this shouldn’t conflict anything on the network).
Any idea how to deeper search where my problem could be?
I don’t know but it seems to me that your esp home is giving you trouble. I don’t have esp home and don’t know its configuration. Check you esp home addon, I don’t know do you need this addon but try to stop it and see will error log come back.
It looks like that but the esphome addon is only the first entry the dns founds for the ip adress.
I can ping any addon and it goes to 172.30.32.1:
PING a0d7b954_chrony.local.hass.io (172.30.32.1)
PING a0d7b954_nut.local.hass.io (172.30.32.1)
Seems the host only sees the docker ip (which is normal i would say after a short search). And i stopped the esphome addon already and tried, and you can guess: message remains the same (ip and dns name) 
I tried to ping some of my docker containers ip address and it replays with container docker address not with 172.30.32.1. This should be a docker gateway address if I got things correctly.
Open ssh terminal and do ha dns info. For dns I use 8.8.8.8
Check your /etc/systemd/resolved.conf file.
I use LLMNR=yes. I’m not sure will this make any difference but it seems to me that you have resolver/network problem. Something is not configured as it should.