I dont know why you get non local ips in your log. As long as i know this error happen if you use your local IP instead of domain. And what i dont get why you can add 172.16.0.0/12 in your config. Iam getting errors if i add IP with “/”. Do you have a static IP from your provider?
doesn’t CIDR notation with “/” work for you? I am surprised, I never had any issues with this. Answering your question. I put the whole subnet of docker IPs to avoid changing config after adding any new container (integration) in the future, but I doubt it can be related anyhow to that external addressing appearing in logs. Regarding the IP, no - I don’t have static IP (at least I am not paying extra for it and I could), although I can monitor it (thanks HA integration) and my public IP did not change since a month (with my previous provider it was changing a few times during every day, so apart from the higher price this was also a reason, why I swapped my provider 
).
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.
1 Like
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?
1 Like
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
2 Likes
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
1 Like
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
4 Likes
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
`
- 192.168.0.0 /24
`
to the list of trusted proxies and it works! I am not sure if opening the entire network might not be a security risk
1 Like
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!!
1 Like
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 the immediate caller is not in the trusted list, the request is rejected
- Beyond that, if the request went through a chain of proxy, the first proxy not in the trusted list is considered as the originating IP.
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.
1 Like
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