Home Assistant 400 Bad Request: Reverse Proxy Fix

Direct answer: If local access works but the proxied URL returns “400: Bad Request,” check the Home Assistant log for “A request from a reverse proxy was received … but your HTTP integration is not set-up for reverse proxies.” Configure `use_x_forwarded_for: true` and trust only the actual proxy address or the narrow network that Home Assistant sees. Then validate the configuration and restart Home Assistant. Do not trust the entire internet or disable proxy protections.

This guide addresses a Home Assistant 400 Bad Request error behind a reverse proxy. It is designed to preserve working configuration and evidence before any reset, deletion, or re-pairing. Work in order and stop when the first confirmed cause is corrected. Screens and menu labels can vary by Home Assistant release and installation method.

Symptoms and scope

Use the following signs to decide whether this guide matches your problem. Similar-looking failures can come from different layers, so record what still works as carefully as what fails.

The external hostname returns 400 while the local IP works.
Logs identify a request from a reverse proxy that is not configured.
The error began after moving NGINX, Traefik, Caddy, Cloudflare Tunnel, Docker networks, or Home Assistant.
HTTPS terminates at the proxy but Home Assistant sees the wrong scheme or client address.
Changing YAML appears to do nothing until Home Assistant is restarted.

Most likely causes, ranked

Start with the causes that fit the evidence. Do not apply every fix at once: simultaneous changes make it impossible to know what solved the problem and can create a second failure.

1. `use_x_forwarded_for` is missing or false.
2. `trusted_proxies` does not contain the source address Home Assistant actually sees.
3. A container or add-on changed its internal IP or network range.
4. YAML indentation or placement is wrong, so the `http:` configuration is not loaded.
5. The proxy is not sending valid X-Forwarded-For or X-Forwarded-Proto headers.
6. Multiple proxy hops exist, but the trusted chain is incomplete or overly broad.

Safe diagnostic procedure

Before beginning, make a current backup when the procedure could affect configuration or stored data. Record the Home Assistant version, installation type, device or app version, the first failure time, and the last known working change. Redact secrets from every screenshot and log excerpt.

Step 1: Capture the exact failure

Confirm the pattern before editing: test the local Home Assistant URL and the external hostname. Record the time and inspect Settings → System → Logs. The key message normally includes the source IP Home Assistant sees. If local access also fails, investigate a broader outage instead of assuming proxy trust.

Interpretation: if this step changes the symptom, repeat the same controlled test once before moving on. If nothing changes, restore any temporary setting and continue. Keep a short note of the time, action, and result; that record prevents circular troubleshooting.

Step 2: Protect the current state

Make a full backup and copy the existing `http:` configuration. Search configuration.yaml and included files for another `http:` block; YAML cannot safely define the same mapping twice. Note whether a proxy add-on, separate container, NAS, tunnel, or load balancer sits directly in front of Home Assistant.

Step 3: Verify the affected layer

Use the log-reported source address to identify the immediate proxy hop. In Docker, this is often a container-network address rather than the LAN address or public visitor address. Trust the narrowest stable address or CIDR justified by your design. Never add 0.0.0.0/0 or ::/0.

Step 4: Test the least-destructive cause

Configure the HTTP integration with `use_x_forwarded_for: true` and a `trusted_proxies:` list. Preserve correct YAML indentation and quote values only when appropriate. The trusted entry represents the proxy that connects to Home Assistant, not every remote client that uses the proxy.

Step 5: Inspect configuration and identity

Validate configuration before restarting. Use Developer Tools → YAML → Check configuration or the supported validation method for your installation. A syntax error can prevent startup. If validation fails, restore the previous block and correct the exact line rather than experimenting on the live system.

Step 6: Check network, power, or permissions

Restart Home Assistant fully; reloading YAML alone may not reload the HTTP integration. Keep local access available during the test so a proxy mistake does not lock you out. After restart, test the external URL in a private browser session and examine new logs.

Step 7: Apply the narrow repair

Verify the proxy forwards Host, X-Forwarded-For, X-Forwarded-Proto, and WebSocket upgrade headers correctly for your proxy product. Follow that product’s official Home Assistant example. Do not pass arbitrary client-controlled forwarding headers without sanitizing them at the trusted edge.

Step 8: Observe through a full cycle

If Cloudflare Tunnel or another layered service is involved, map every hop: client → edge → connector/proxy → Home Assistant. Home Assistant must trust its immediate source, and the trusted proxy must construct the forwarding chain safely. Avoid broad ranges copied from unrelated examples.

Installation and environment branches

Home Assistant OS or appliance-style installs

NGINX Proxy Manager or separate NGINX container: use the address or subnet of the container network Home Assistant sees, not automatically the NAS LAN address.

Container, network, or account variation

Home Assistant add-on proxy: use the add-on documentation because Supervisor-managed networks differ from standalone Docker.

Partial failure versus complete failure

Cloudflare Tunnel: determine whether cloudflared connects directly or through another proxy and retain authenticated, encrypted origin access.

Multi-device or multi-hop environments

Synology or other NAS reverse proxy: confirm the NAS source address, WebSocket support, certificate path, and whether another container hop changes the source.

What not to do

Do not delete the integration, device, database, app registration, or proxy configuration merely because it is the fastest visible button. Deletion can remove evidence and create new entity identities.
Do not paste passwords, tokens, encryption keys, exact home coordinates, public URLs with credentials, or unredacted logs into a forum or support ticket.
Do not disable firewalls, TLS verification, authentication, or other security controls as a permanent workaround. A useful test must be narrow, timed, and reversed.
Do not make several network, software, and device changes together. Change one variable, observe the result, and keep the working rollback path.
Do not assume a restart is a diagnosis. A restart can temporarily hide timing, memory, radio, storage, or connectivity faults without correcting them.

Verification checklist

A successful repair has several parts: the external hostname loads without 400; login and WebSockets remain connected; the Home Assistant log no longer reports an untrusted reverse proxy; generated URLs use HTTPS; and local access still works. Check that failed login records show the real client address rather than only the proxy when your chain is designed to preserve it. Test after a proxy or container restart to ensure the trusted address remains stable.

The original symptom is gone under the same conditions that previously reproduced it.
The relevant log has no new matching error after a normal update or restart cycle.
Related entities, history, automations, or remote access still work.
The repair survives one controlled restart of the affected component.
Temporary troubleshooting exceptions have been removed or documented.

Rollback and recovery

If Home Assistant fails after editing YAML, restore the saved `http:` block through local file access or a backup, validate, and restart. If external access fails but local access works, revert only the proxy-related change. Do not expose port 8123 publicly as an emergency shortcut. Keep a local administrative path and a tested backup before changing remote access.

If the evidence points to failing hardware, a vendor outage, an upstream regression, or corrupted data that matters, stop improvising. Preserve the backup and diagnostic record, then escalate with the exact version, timestamp, error, minimal reproduction, and steps already tested. That produces a safer and faster answer than repeated resets.

Prevention

Reserve or define stable proxy networks where supported.
Keep trusted proxy ranges narrow and documented.
Validate YAML before every restart.
Test WebSockets and real client IP handling after proxy upgrades.
Maintain secure local access for recovery.
Review the proxy chain whenever containers, tunnels, or networks move.

Schedule a brief review after the next Home Assistant update or device firmware change. Confirm that the repaired path still works, remove obsolete workarounds, and update your private documentation. Prevention is most effective when it records why a setting exists, not just its value.

Diagnostic worksheet

For a Home Assistant 400 Bad Request error behind a reverse proxy, write down five facts before asking for help: the exact error, the first failure time, the last working time, the smallest action that reproduces it, and the layer that still works. Add the Home Assistant Core version, installation type, relevant device or app firmware, network path, and whether the issue survives a restart. This worksheet separates a repeatable defect from a transient outage.

If you observe: The external hostname returns 400 while the local IP works

Confirm when this began and whether it affects one entity, one device, one integration, or the whole installation. Compare the result on the same network and, when relevant, through the alternate path. Then use the matching diagnostic step above. Do not jump to recovery until the observation is repeatable or the logs identify the failing layer.

If you observe: Logs identify a request from a reverse proxy that is not configured

If you observe: The error began after moving NGINX, Traefik, Caddy, Cloudflare Tunnel, Docker networks, or Home Assistant

If you observe: HTTPS terminates at the proxy but Home Assistant sees the wrong scheme or client address

If you observe: Changing YAML appears to do nothing until Home Assistant is restarted

Frequently asked questions

Should I delete and add everything again?

Usually not. Re-adding can change entity IDs, erase evidence, and hide the original cause. Use it only after backup, documentation, and the narrower checks in this guide.

Can I ignore the error if it starts working again?

A single brief interruption may be harmless, but a recurring error deserves timestamps and logs. Repetition after the same event often reveals a network, storage, power, permission, or token lifecycle problem.

Is updating Home Assistant always the fix?

No. Updates can contain fixes, but they also change dependencies and behavior. Read release notes, back up first, and match the error to a known fix before treating an update as diagnosis.

How much log information should I share?

Share the smallest relevant window around the failure, with secrets and personal data removed. Include versions and the exact action that caused the event. Avoid uploading complete logs publicly.

When should I escalate?

Escalate when safety, important data, repeated corruption, an upstream regression, or an account-side failure is involved, or when the least-destructive checks produce a clear error you cannot resolve.

Sources and review notes

Photo: Scott Rodgerson on Unsplash. Last reviewed: September 22, 2026. Official documentation is the authority for supported configuration. Community and issue reports are useful for identifying recurring symptoms but do not prove that every installation has the same cause.

Continue with the Device Unavailable Diagnostic, the Smart-Home Diagnostic Decision Tree, or the Home Assistant Error Decoder when the symptom crosses more than one integration.

Home Assistant 400 Bad Request behind a reverse proxy: trusted proxy fix