I closed once port 80 as it seems not needed of course if you just use https only.
Later, I forgot about this fact and when I added a new integration and I tried to generate a new Let’s encrypt cert for the new subdomain, I could not do it. So, just remember that Nginx Proxy manager will work for you with port 80 closed, but for any changes you will need to open it.
Not sure why those discussions about nginx proxy for “Login attempt” errors.
This just inform about a possible break-in attempt, with the IP being the one that was put by nginx in the “X-forwarded-for” header, i.e. the public IP of the potential hacker or script-kiddie.
Agree, I understand the purpose of this added protection, but it looks like because of this, developers created some innocent causalities.
Nevertheless, it looks like, I will have to check with Cloudflare support their safe IP addressing range, and add it to the trusted proxies config.
No. The only proxy talking to your HA is nginx.
That you see a cloudflare address as the IP address in “login attempt” errors just means a hacker is using cloudflare to attempt to break-in into your system.
Went through the HA code and it does something peculiar.
Per definition, a X-Forwarded-For is
X-Forwarded-For: client, proxy1, proxy2
So the originator of the request is always the first IP.
Now, HA goes through the list of proxies in the header, and consider the first one that is not part of trusted_proxies as the originator, and uses that IP in the logs.
Quite confusing, imho. It’s documented in Improve X-Forwarded-* request headers handling by frenck · Pull Request #38696 · home-assistant/core · GitHub but I’m not sure what was the reasining behind implementing this.
Hi all, till now I never adjusted settings to work well with a reverse proxy. I use proxmox and I have a ct with Nginx, registered a duckdns domain. If I try to access to HA using on my pc the duckdns url, a warning says my pc is not allowed in trusted network, so I must login with username and password and it works; if I enter with my local HA ip, in trusted network drop menu I select my user and enter without problem. Remote connection on my phone is working after reinstalling companion app, any advice is welcome, if login with user and password is simpler than configuring trusted network and proxies I can do this way without headaches.
I am also using cloudflare, did you add the IP’s listed in the log?
I use Cloudflare with full proxy and encryption and the following worked for me
I used the following list of IP’s from IP Ranges | Cloudflare and then any others added into my log file
Copy to clipboard
use_x_forwarded_for: true
trusted_proxies:
#log reported ipv4
- 162.158.159.139
- 172.69.55.59
- 141.101.76.195
- 141.101.98.91
- 141.101.99.102
- 141.101.105.87
- 141.101.105.99
#cloudflare ipv4
- 103.21.244.0/22
- 103.22.200.0/22
- 103.31.4.0/22
- 104.16.0.0/13
- 104.24.0.0/14
- 108.162.192.0/18
- 131.0.72.0/22
- 141.101.64.0/18
- 162.158.0.0/15
- 172.64.0.0/13
- 173.245.48.0/20
- 188.114.96.0/20
- 190.93.240.0/20
- 197.234.240.0/22
- 198.41.128.0/17
#cloudflare ipv6
- 2400:cb00::/32
- 2606:4700::/32
- 2803:f800::/32
- 2405:b500::/32
- 2405:8100::/32
- 2a06:98c0::/29
- 2c0f:f248::/32
Hi all,
I have cloudflare with proxy going to my HAProxy. Set all the cloudflare ranges to trusted…
And that isn’t working, I get the following errors:
too many headers for X-Forwarded-For [client_ip, cf_proxy_ip]
Disable proxy on cloudflare and everything works fine. Anybody doing double reverse proxy? How do you get it to work?
Update: Disabled forward-for in HAProxy, re-enable proxy on CF and things are working again. Just not entirely sure if the correct IP is passed through to this stage. Will have to investigate more to continue later in the week.
This means the request has multiple X-Forwarded-For headers, which is wrong.
Assuming one is from cloudflare and another one is from HAProxy, there is something wrong in your HAProxy. It should have added itself to the already existing list of proxies in the existing header rather than creating one of its own.
EDIT: See Too many headers http 400 Error while using revers proxies · Issue #40421 · home-assistant/core · GitHub for a possible resolution
Did you read the breaking changes ? Add this to the http: section in configuration.yaml
http:
use_x_forwarded_for: true
trusted_proxies:
- 127.0.0.1
Yes, Indeed I copied & pasted your code into my configuration.yaml file
# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:
# Text to speech
tts:
- platform: google_translate
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
http:
use_x_forwarded_for: true
trusted_proxies:
- 127.0.0.1
I am running using docker and behind Apache2 as areverse proxy.It has worked fine for around a year, but stopped working recently.
I am at a loss
I solved it!
Further reading suggested that I should also add
`
Are you running Apache2 as a docker container?
Is it running on the same machine, in the same docker network?
If you have static IPs in your network you should only have to add the IP that has your reverse proxy.
If in the same docker network then the network address of that network should work; you can easily see this network if you use Portainer.
No Apache2 is running on Ubuntu, the container is running HA.
So yes, using static IPs…but they didnt work, so i added the network and bingo…I suspect it is an order thing, but that is for a time when I want to risk breaking a system that is now working
This worked for me 
Thank you!!
guys, if you are running proxy from a different machine on your local then you need to add that proxy IP or you should just put 127.0.0.1
You should not have multiple IP since you will only used single proxy server.
That’s conceptually correct, but HA is using the trusted_proxies in its own way.
See Incorrect (?) handling of X-Forwarded-For · Issue #52736 · home-assistant/core · GitHub for the discussion.
Basically:
If you’re using, e.g. cloudflare, that could lead to a cloudflare IP being listed as the caller unless you put every single known cloudflare proxy in your trusted list.
I accept and appreciate that, but it doesn’t work! I had 127.0.0.1 as my sole trusted proxy, and I got the connection refused. An examination of the logs showed the proxy request was from 192.168.0.7, so I added that…still didn’t work.
It was only when I changed the whole thing to 192.168.0.0/24 that it worked…and I am baffled (and a little concerned , since that appears to mean any machine on the network will be a trusted proxy)
I will tinker with it and see if I can get a more elegant way of doing it, but for now…it works
Cheers
Shouldn’t be. When you added 192.168.0.7, was there a message with another IP?
No the message was Still 192.168.0.7…and I have no idea why… 
I am going to have a play this morning… I will start by taking the whole network out & replacing with 192.168.0.7… And I will post the logs if it doesn’t work… I mean… What could possibly go wrong?