Node-RED Cannot Connect to Home Assistant: Safe Fixes

Direct answer: If Node-RED reports that it cannot connect to Home Assistant, check the configured Home Assistant URL, long-lived access token or add-on authentication, WebSocket path, DNS, and TLS trust before reinstalling anything. Test whether the failure affects the Node-RED add-on, an external Node-RED server, or only one flow.

Safety first: Preserve a current Home Assistant backup and record entity IDs, device names, IP addresses, integration settings, and the exact error before changing anything. Never expose tokens, passwords, encryption keys, webhook URLs, or unredacted diagnostics. Do not factory-reset equipment, delete an integration, or open mains-powered hardware as a first troubleshooting step.

Confirm the failure boundary

Open the Home Assistant server configuration node in Node-RED and identify whether it is disconnected globally, repeatedly reconnecting, authenticated but missing entities, or failing only when a flow calls a service. Connection failures and flow-logic failures require different fixes.

Determine whether the problem affects one device, one integration, or every device using the same network path. A single-device failure usually points to power, addressing, credentials, firmware, or device-specific settings. Several failures beginning together point toward Home Assistant, DNS, routing, firewall policy, an upstream service, or a recent update.

Quick diagnostic table

Observation	Likely layer	Next safe check
Server node says disconnected	URL, DNS, TLS, or WebSocket	Test the configured base URL from Node-RED’s environment
401 or unauthorized	Token or add-on authentication	Replace the revoked token or verify add-on settings
Connected but entities missing	Cache or permissions	Deploy, refresh, and inspect user access
Only one call-service node fails	Flow configuration	Check domain, service, target, and payload

Step 1: preserve evidence

Write down when the failure began, the last known working version, recent updates, router or VLAN changes, and the full error text. Open Settings → System → Logs and the integration entry under Settings → Devices & services. Download diagnostics when available. Evidence collected before a restart is often more valuable than evidence collected afterward.

Step 2: verify the basic path

Determine where Node-RED runs. The supervised add-on may use internal connectivity and add-on authentication, while an external container or computer must resolve and reach the configured Home Assistant URL. Test from the Node-RED host or container, not only from your phone.

Use the least invasive test that separates network reachability from application authentication. A successful ping proves only that an address responds; it does not prove that the required port, protocol, credentials, certificate, or API is working. Likewise, a vendor app working through the cloud does not prove that local communication from Home Assistant is allowed.

Step 3: check configuration and credentials

For an external installation, verify the base URL and a valid long-lived access token belonging to an appropriately limited user. For the official add-on, verify the documented add-on authentication settings. Never paste a token into screenshots or public flow exports.

Prefer the integration’s Reconfigure or Reauthenticate flow over deleting it. Deletion can remove entity-registry relationships and break dashboards or automations. If credentials changed, update only the affected entry and verify one harmless entity before touching anything else.

Step 4: inspect networking without weakening security

Reverse proxies must pass WebSocket upgrades and present a certificate trusted by Node-RED. Split DNS can cause an internal client to resolve a public address that hairpin routing cannot reach. Prefer a valid internal route and trusted TLS rather than disabling certificate verification.

If Home Assistant and the device are on different VLANs, test temporarily on the same trusted network. If that works, restore the intended layout and create the narrowest required rule. Do not expose local APIs to the public internet, disable the firewall globally, or create an unrestricted route from an untrusted IoT network to the main LAN.

Step 5: read logs and reproduce once

Compare Node-RED logs with Home Assistant authentication and HTTP logs. Unauthorized errors indicate credentials; name-resolution errors indicate DNS; certificate errors indicate trust or hostname mismatch; repeated WebSocket closes point toward proxy, timeout, or network behavior.

Enable debug logging only long enough to reproduce the failure once. Then disable it and download the log. Look for the first meaningful error, not every secondary warning that follows. Match timestamps between Home Assistant, the add-on or bridge, the router, and the vendor service when applicable.

Step 6: make one reversible change

Correct the server node’s URL or authentication, deploy once, and watch the connection state. If a reverse proxy is involved, repair WebSocket forwarding and certificate trust. Do not regenerate multiple tokens without revoking and documenting obsolete ones.

After each change, wait through several normal update intervals. Changing DNS, credentials, firmware, firewall rules, and device configuration at the same time may produce a temporary success without revealing the cause. Record the old value and the test result so you can roll back cleanly.

How to verify the repair

The Home Assistant server node remains connected.
Entity autocomplete and state events refresh normally.
One harmless flow receives an event and calls a low-risk service.
The connection returns automatically after a controlled Node-RED restart.

A repair is not verified by a green icon alone. Confirm fresh state updates, send one low-risk command, verify the physical response, and make sure the returned state matches. Watch long enough to cover normal polling, sleep, or reconnect behavior.

Rollback and escalation

Before editing, export the affected flow and record server-node settings without secrets. If a new URL or proxy rule fails, restore the prior value. Revoke tokens that were exposed or created only for testing.

If escalation is necessary, provide the exact model, firmware, Home Assistant version, integration version, network layout, redacted diagnostics, timestamps, and the checks already completed. A concise evidence package gets better help than a broad statement that the integration is broken.

Prevent recurrence

Use a dedicated Home Assistant user and token for external Node-RED.
Document internal DNS and reverse-proxy WebSocket settings.
Back up flows before node or add-on updates.
Monitor repeated reconnects before they become a total outage.

Related Troubliq guides

Sources and review record

Last reviewed: September 21, 2026. Testing disclosure: This guide follows current official documentation and established diagnostic practice; exact menus can vary by release, installation type, and device firmware.

Advanced isolation checklist

When the basic checks do not identify the cause, build a controlled comparison. Test one known-good device, account, or client through the same path, and test the affected device through a simpler path when safe. Compare timestamps, addresses, authentication method, firmware, and permissions. The purpose is to change one boundary at a time, not to keep trying random fixes.

Review release notes for Home Assistant, the integration, add-on, device firmware, and any reverse proxy or network service updated near the failure. Confirm a reported workaround applies to the same product and version before using it. Prefer an official repair or documented reconfiguration over unsupported downgrades.

What not to do

Do not factory-reset multiple devices together.
Do not delete a working integration merely to clear a warning.
Do not expose local services or dashboards directly to the internet.
Do not post secrets or unredacted diagnostic files.
Do not assume a successful mobile-app test proves the Home Assistant path works.

Detailed evidence checklist for Node-RED cannot connect to Home Assistant

Before another change, create a short incident record. Include the exact time the symptom appeared, what the system was doing, the last successful action, and every update or network change made during the previous day. Record the Home Assistant release, installation type, integration version, device model, firmware, connection method, current address, and relevant entity IDs. Screenshots are useful for visible states, but copy the exact error text because screenshots may crop the detail needed to search logs.

Compare the failing item with one known-good item that uses the same path. If both fail, move outward toward shared services such as the integration, coordinator, add-on, DNS, router, cloud account, or Home Assistant host. If only one fails, stay close to that device: power, signal, address, credentials, firmware, permissions, and configuration. This comparison prevents a single-device problem from turning into an unnecessary system-wide rebuild.

Network tests that prove the failing layer

Use tests in layers. Confirm the address is current in the router or DHCP server. Confirm the Home Assistant host or container resolves the same name and reaches the intended address. Then test the actual documented service, port, or protocol. A dashboard loading on a phone proves only the phone’s path. A successful ping proves basic reachability, not authentication, WebSocket upgrades, multicast discovery, API encryption, event subscriptions, or application permissions.

For segmented networks, document source VLAN, destination VLAN, direction, protocol, and port before editing a firewall rule. Test the smallest temporary exception and remove it if it did not help. Discovery traffic and control traffic may use different mechanisms. Seeing a device in discovery does not prove Home Assistant can maintain a working session.

Configuration comparison procedure

Export or photograph the current configuration without exposing secrets. Compare it with official documentation field by field: host, port, account, region, project, encryption setting, device identifier, and optional switches. Watch for trailing spaces, uppercase versus lowercase account names, obsolete hostnames, restored encryption keys, or an account belonging to the wrong home or region.

Use Reconfigure or Reauthenticate before deleting an integration. Preserve entity IDs and note every automation, dashboard, script, scene, or helper that refers to them. If replacement becomes necessary, take a backup and map old entities to replacements. That makes rollback controlled rather than leaving broken references.

Power, radio, and timing checks

Do not interpret every unavailable state as software failure. Low-voltage devices may stay partly online while unstable power causes resets. Battery devices sleep and report on their own schedule. Wi-Fi and Bluetooth devices can associate yet fail at the application layer. Zigbee and Z-Wave devices depend on routes, radio conditions, and powered repeaters. Match the test to the technology instead of repeatedly pressing Reload.

Allow enough time after each test. Cloud polling, sleepy devices, retained MQTT messages, mesh repair, Bluetooth advertisements, and DHCP changes do not update instantly. Define the expected interval, then wait through at least two normal cycles. If availability returns briefly, capture the next disconnect in logs instead of declaring success.

Log-reading workflow

Synchronize clocks and reproduce the problem once. Start with the first warning or error at that timestamp; later messages may be consequences. Group errors by layer: name resolution, timeout, refused connection, TLS certificate, unauthorized account, invalid token, missing permission, unsupported capability, malformed payload, device timeout, or rate limit. Each group suggests a different next action.

Turn debug logging off after reproduction. Large files consume storage and bury the event. Redact tokens, passwords, keys, email addresses, public addresses, precise locations, and unnecessary unique identifiers. Keep the unredacted copy private for comparison with later tests.

Safe change order

Correct time, power, cabling, or an obviously stale address.
Reload only the affected integration when documentation supports it.
Use Reconfigure or Reauthenticate without deleting the entry.
Restart only the affected device or add-on during a safe window.
Restart Home Assistant when several components share the symptom or a change requires it.
Update software after reading release notes and preserving rollback.
Delete, exclude, reset, or rebuild only after safer checks prove it necessary.

Post-repair validation

Verify both directions. Confirm Home Assistant receives a fresh state, send one harmless command, and confirm the physical response. Check the returned state, logbook, history, and automation trace. Restart the affected component and verify automatic reconnection. During a maintenance window, confirm the repair survives a normal Home Assistant restart.

Monitor long enough to cover the original pattern. If failure occurred overnight, after DHCP renewal, deep sleep, or token expiry, a five-minute test is insufficient. Record the confirmed cause and exact corrective change. Remove temporary firewall rules, extra logging, duplicate test integrations, and unused credentials.

When to stop and escalate

Stop if hardware overheats, power is unstable, storage reports errors, a controller backup fails, credentials are rejected across services, or firmware may be damaged. Escalate with versions, timestamps, topology, redacted logs, the first meaningful error, and results of each safe test. Do not repeat destructive steps while waiting for help.

A strong report answers four questions: What still works? What exactly fails? What changed immediately beforehand? Which test most clearly separates the causes? Those answers help maintainers diagnose the correct layer.

Node-RED Cannot Connect to Home Assistant