I’m experiencing an odd issue ever since having to restore a long standing HA implementation. I have also since tried on a totally clean installation and I am having the same issues.
My setup is as follows:
Path 1:
External Internet → Cloudflare Tunnel → Cloudflared (on local nas 192.168.3.101) → Home Assistant (running on a different NAS with 192.168.3.100:8123)
Path 2:
Local LAN → Nginx Proxy Manager (on local nas 192.168.3.101) → Home Assistant (192.168.3.100:8123)
This is working via Path 1 with no issues however Path 2 is working sporadically. When it doesn’t work I can login but then I’m immediately put into a reload loop. I see the following error in the console of the page: socket.js:34 WebSocket connection to ‘wss://URL/api/websocket’ failed. The odd thing is that this happens only sometimes. The HA core, supervisor and host logs don’t really have anything valuable. I also don’t see anything within the nginx access or error logs that point to anything I can use to troubleshoot.
Web socket support is enabled. I also added headers within Nginx but this doesn’t seem to change the outcome so I removed it.
I have other internal only SSL urls running with 0 issue on the same LAN within the nginx proxy manager path.
I have the same setup, and I’ve been experiencing similar issues for the last few days. I haven’t done much troubleshooting so far, so next time it happens I’ll see if I’m getting the same console errors.
But for me this has worked for months and only recently broken - every now and again the page stops working and if I refresh, it displays the loading page and “trying again in 1 minute” (or however that message is worded). Then 5 minutes later it will be fine again.
I have NPM running on a separate machine under docker getting “latest”, which I don’t normally do for this very reason. I’ve changed it to “v3” which went up a day ago, to see how it goes.
There’s an open NPM issue where people are getting intermittent SSL issues, which may be related, because I think I’ve been getting the same error sometimes. I noticed “nslookup” was returning ipv6 addresses from my pihole, and there’s discussion about it in the issue, but others think this is unrelated. Anyway, the issue is still open.
I’m going to track this, thanks. I was also running latest, i’m having issues changing over to v3. this runs form a pi4 b and it looks like a hardware issue with the image and os i’m running on it; I’m going to see what I can do.
Oh yeah it looks like v3 didn’t work for me either - it started ok, but it didn’t work when NR tried to use it for something else. I’ll have to look into it when not at work.
It just happened to me again, and yes, I’m getting
WebSocket connection to ‘wss://URL/api/websocket’ failed
If I refresh while holding shift the page briefly shows an SSL name unrecognised error before the usual “retrying in x seconds” message. And an nslookup shows a couple of ipv6 addresses ahead of the ipv4 one. I followed the process suggested in the issue linked above, although modified slightly because pihole overwrites the file mentioned, so I created 06-rfc6761-michael.conf with the following content (obviously with my domain in it):
address=/ha.mydomain.com/
Once I restarted pihole an nslookup only returned the ipv4 address, so I’ll see how that goes.
@michaelblight ok took a deeper look. I don’t use piHole and I don’t think ipv6 is my issue as i do not see ipv6 addresses when running nslookup.
I disabled ipv6 from the client i’m using to access the browser to see if this does anything. My DNS is just routing via unifi so i guess I could look for that .conf file on the router itself.
I feel like this comment seems more likely. It does fit the bill of HA being my only NPM site that is both internal and external.
I don’t fully understand what is going on, but my reading of the above is it’s an issue where some sites are public+private and others are public only, where public goes Cloudflare=>cloudflared=>site and private goes NPM=>site. And the certs differ between public and private - I can understand this because NPM is getting a wildcard cert via Let’s Encrypt. But my browser is only ever at home and I’m not accessing any public-only sites on the domain, so why would Chrome be getting the public cert?
Regardless, since this was working for ages it seems to imply a change in Chrome’s behaviour. I don’t remember updating it recently, but there’s a new version, so I’m going to update while crossing my fingers.
EDIT: 5 days with no problem after updating Chrome, but today it’s back. No problems in Firefox while it’s not working in Chrome.
I don’t fully understand either but it doesn’t seem isolated to chrome for me. I’ve tried other browsers. The only constant is that HA is the only URL which I have both external and internal SSL configured. All my local only SSL configs via NPM work fine.
