Hi everyone, 
After 5+ years of HA is faced my first issue that I cannot solve. Also AI was not helpful. I am trying to set up funnel with Tailscale which I cannot get to run. Otherwise Tailscale is working flawlessly and I can access my HA remotely. Things like Tailscale setup, and HA setup was done according to guides. I try to summarize what I have done best I can.
Summary
use_x_forwarded_for: true is set in configuration.yaml, the config validates, HA restarts cleanly — and the running instance still behaves as if the option were false. Every proxied request is rejected. I have spent an evening eliminating the usual causes and am out of ideas.
The error
Repeating once per second in the Core log:
Logger: homeassistant.components.http.forwarded
Source: components/http/forwarded.py:100
A request from a reverse proxy was received from 127.0.0.1, but your
HTTP integration is not set-up for reverse proxies
The wording is the key detail. This is not the “untrusted proxy” message that appears when a source IP is missing from trusted_proxies — that would point at my proxy list. This is the message emitted when use_x_forwarded_for is not enabled at all.
Note also the source address: 127.0.0.1. Plain localhost, first entry in my list. So this is not an address-matching problem.
System
- Home Assistant Core 2026.8.0
- Home Assistant OS 18.1 (amd64 / generic-x86-64, Intel NUC)
- Supervisor 2026.07.5
core/inforeports"ssl": false,"port": 8123— no TLS inside HA
The config
/homeassistant/configuration.yaml, currently reduced to the documented minimum:
http:
use_x_forwarded_for: true
trusted_proxies:
- 127.0.0.1
- ::1
For completeness, the same file uses packages (homeassistant: packages: !include_dir_named Projects). No package file defines http: — verified by recursive grep.
Already ruled out
Each of these has been checked:
Is the YAML actually valid? grep -n -A8 "^http:" configuration.yaml | cat -A shows http: at column 0, consistent two-space indentation, no tabs (^I), no CRLF (^M), clean line endings throughout.
Is there a second http: key overriding it? No. grep -n "^[a-z_]*:" on the main file plus a recursive grep for http: across every file under Projects/ return exactly one match.
Is HA reading this particular file? Yes. I appended a test input_boolean: to it, restarted, and the entity appeared in Developer Tools → States.
Did you actually restart, not just reload? Yes — multiple full Core restarts plus a full host reboot. The “first occurrence” timestamp of the log error updates to match each restart, so the running instance re-read the config and still came up without the option.
Is ha core check complaining? No, it passes with no errors or warnings.
Is the block being validated at all? I inserted a nonsense key (bogus_test_option: true) inside the http: block and re-ran ha core check. It correctly failed with a schema error on http, so the block is parsed and validated — which makes the runtime behaviour harder to explain.
Is it an IP ban? No ip_bans.yaml exists.
Is the proxy at fault? No. The rejection reproduces with a plain curl carrying an X-Forwarded-For header, straight from the host, no proxy involved.
Ordering or list contents? Tried the http: block placed above the homeassistant: block, tried a longer trusted_proxies list covering the Docker and VPN ranges, tried retyping the block by hand instead of pasting. No change in any case.
I am at a complete loss why the forward is not working. I have set the system up as the guides suggests.
Questions
Does anyone has a clue what can cause that strange behaviour? Why is the proxy/http failing? Is there anything else I can check.
Many thanks!