Trusted proxies and interface binding in Home Assistant
Home Assistant now exposes web server controls in the interface for Home Assistant OS setups. That gives you three knobs that actually affect how the instance is reached: the port, the network connection it listens on, and the trusted proxies list.
For anyone running behind a reverse proxy, that last one matters. If the proxy is not trusted, Home Assistant will treat forwarded headers with suspicion, which tends to break the bits that make the proxy useful in the first place. If it is trusted too broadly, you have opened a door you did not mean to open. Pick the proxy address range you actually use, not the whole subnet because it was convenient.
Why Home Assistant OS web server settings now matter
New Home Assistant OS installs no longer assume :8123 in the web address. The normal address works by default, so the old habit of tacking :8123 on the end is no longer the starting point.
Existing installs keep whatever port they already used until someone changes the setting. That keeps older bookmarks and app setups alive, but it also means mixed estates will behave differently for no especially noble reason. One box comes up on the plain address, another still sits on :8123, and both are technically fine.
New installs stop assuming :8123
A fresh Home Assistant OS install now starts with the standard web address. That reduces one bit of setup friction and makes the default look a lot less like a lab machine from 2019.
If you have scripts, browser shortcuts, or firewall rules built around the old port, they will not follow the new default automatically. The box will not care that a shortcut is stale.
Existing setups keep the old address until you touch them
Older installs stay where they are until the web server settings get changed. That is useful if you already have mobile apps, automations, or external services pointing at the current address.
It also means a config change is a change, not a tidy little cosmetic edit. Once the port or binding shifts, anything hardcoded to the old address may stop working straight away.
Set the port, bind the interface, and trust the right proxies
The UI now lets you change the web server port, pick the network connection Home Assistant listens on, and set trusted proxies from the same place. That is the part that matters if you run more than a single flat network with nothing in front of it.
Match the web server port to every bookmark and app endpoint
Changing the port changes the address people and apps need to use. Browser bookmarks, the mobile app, scripts, and external services all need the same port if they still talk directly to Home Assistant.
If the old address is still in use anywhere, expect odd failures rather than a clean warning. A service trying :8123 against a box moved elsewhere will not politely guess the new location.
Bind Home Assistant to the network path you actually want exposed
Interface binding controls which network connection Home Assistant listens on. That is useful when the machine has more than one route into it and you do not want every interface exposed.
Bind it to the path you intend to use, not to every interface just because the option exists. The wider the bind, the more paths can reach the service. That is not a mystery, just how sockets work.
Add trusted proxies without opening the door wider than needed
Trusted proxies belong in the same settings area for a reason. If Home Assistant sits behind a reverse proxy, it needs to know which upstream addresses to trust for forwarded headers.
Use the smallest set that matches the proxy or proxy range in front of it. A lazy trust rule can make the proxy behave, but it can also make the source of requests look far less certain than it should.
Apply the change without getting locked out
Web server changes do not land as a fire-and-forget edit. Home Assistant waits for confirmation, and the new settings can roll back if they are not confirmed or if they do not apply cleanly.
Watch the five minute confirmation window
After a web server change is applied, there is a five minute window to confirm it. Miss that window and Home Assistant rolls the change back.
That is a useful safety net, but it also means you should not wander off mid-change and assume the new address will stick. If you have altered the port, moved the bind, or changed proxy handling, test access before the timer runs out.
Check what rolls back automatically when the new settings fail
If the new settings cannot be applied, Home Assistant falls back immediately. That is the difference between a bad config and a long lockout.
The practical effect is simple: a broken port or interface choice does not get a free pass just because it was entered through the UI. Home Assistant will try the new settings, fail fast if needed, and restore the previous working state.
Update mobile app endpoints, services, and anything else still pointing at the old port
The mobile app may still point at the old port, and so may integrations, scripts, reverse proxy targets, and old bookmarks. Those do not update themselves just because the UI moved the service.
Anything that talks to the instance directly needs the new address. If there is a DNS name in front of it, that may save some of the pain. If there is not, every hardcoded endpoint gets to be wrong in its own private way.
YAML web server settings are imported into the interface on first start after an update, so older manual config does not vanish into the void. A Repairs notice may appear after that import, which is Home Assistant’s way of saying the settings have moved and somebody ought to look at them.
