A question on the “fastcgi_pass 192.168.xxx.xxx:9000;”:
This is the default port for Portainer - is it more reasonable to change which port Portainer is using - or to change “fastcgi_pass 192.168.xxx.xxx:9000;” to another port number?
its easy enough to change the external (host) port that portainer is exposed to that I changed that instead of the NGINX port.
This is awesome, I can throw as many containers on my Pi as I want and just map the port in the Nginx config.
Why did you comment out basic_auth for hass? It seems to be working as expected when enabled. One of the main reasons I wanted this proxy was to add that extra layer of security in case of exploits specific to HA.
yes, but you need to use the RPI image, check their website.
no particular reason. Just didnt see it necessary now.
My R Pi has the standard Raspbian lite: https://www.raspberrypi.org/downloads/raspbian/
Then I installed Hassio as a Docker image: https://github.com/dale3h/hassio-installer
So I’m free add as many Docker images as I want on other ports, including the letsencrypt image on 80/443.
Thank you for posting these instructions!!!
3 B+ (specifically this with a 32 GB SD card: https://www.amazon.com/gp/product/B07BC7BMHY/)
I haven’t moved my config to confirm everything works but it does load and I’m able to install addons.
cool… i’m wondering if I can use a straight 3b
Good question, the image itself https://github.com/home-assistant/hassio-build/tree/master/install just says raspberrypi3 supported, no B’s or plusses specified.
However the helper installer https://github.com/dale3h/hassio-installer does say 3 B+
Well… There’s one way to find out…
Yeah I looked at the script as well and it looks good to me.
Maybe I should just give it a go lol!
well… it says to go to the url and wait… says it’s Preparing Hass.io… could take 20 mins…
OK we’re up and running!
1 Like
Sorry to revive, but has anyone else noticed any issues recently?
I just moved, and have been using HA only on local network for a few months. Now I have proper internet, but the duckdns/nginx access is very dodgy all of a sudden.
I got it up and running again for a few hours, but after a reboot (I just fiddled with some scripts and automations, then rebooted), I get an “403: Forbidden” error when I navigate to hass.MYSUBDOMAIN.duckdns.org. Without having changed anything in the .../site-confs/default (except adding the line suggested by Tinkerer after upgrading to 0.77.x, but that line was there when I last had external access), docker-compose.yaml or configuration.yaml.
I’m using HADashboard as well, and this works fine through nginx/letsencrypt/duckdns. It’s just home assistant itself that’s causing problems…
My nginx error logs show nothing that I helps me:
2018/09/10 14:31:50 [error] 380#380: *111 connect() failed (111: Connection refused) while connecting to upstream, client: MY.PUBLIC.IP, server: hass.MYSUBDOMAIN.duckdns.org, request: "GET /api/websocket HTTP/1.1", upstream: "http://192.168.0.100:8123/api/websocket", host: "hass.MYSUBDOMAIN.duckdns.org"
2018/09/10 14:58:31 [error] 373#373: *1 connect() failed (111: Connection refused) while connecting to upstream, client: MY.PUBLIC.IP, server: hass.MYSUBDOMAIN.duckdns.org, request: "GET / HTTP/1.1", upstream: "http://192.168.0.100:8123/", host: "hass.MYSUBDOMAIN.duckdns.org"
2018/09/10 14:58:32 [error] 373#373: *1 connect() failed (111: Connection refused) while connecting to upstream, client: MY.PUBLIC.IP, server: hass.MYSUBDOMAIN.duckdns.org, request: "GET /service_worker.js HTTP/1.1", upstream: "http://192.168.0.100:8123/service_worker.js", host: "hass.MYSUBDOMAIN.duckdns.org", referrer: "https://hass.MYSUBDOMAIN.duckdns.org/service_worker.js"
2018/09/10 14:58:33 [error] 373#373: *1 connect() failed (111: Connection refused) while connecting to upstream, client: MY.PUBLIC.IP, server: hass.MYSUBDOMAIN.duckdns.org, request: "GET /favicon.ico HTTP/1.1", upstream: "http://192.168.0.100:8123/favicon.ico", host: "hass.MYSUBDOMAIN.duckdns.org", referrer: "https://hass.MYSUBDOMAIN.duckdns.org/"
Any suggestions?
@juan11perez
Do you have any depends_on: for any of your components in your docker-compose?
When I removed
depends_on:
- duckdns
from the letsencrypt in docker.compose.yaml, it worked. Until I did a docker kill $(docker ps -q) and docker-compose up -d, then it stopped working again. But maybe it has to do with the order of startups?
I do, I have hass depending on mqtt, postgress and motioneye.
It’s been working well, so far.
Annoying 
Have you come upon anything else in your week-long endeavour that you think could have changed, or I could have messed up in the meantime?
I tried literally copy/pasting your config from the first post, doing a find & replace for any instance of mydomain and hostip, and added proxy_set_header x-ha-access "MY_OLD_API_PASSWORD"; under the location part of the HASS configuration.
Since the last time it was functional, all I can think of that I’ve changed is:
- I’ve moved the config volume (in docker-compose) from
/etc/letsencryptto/home/aephir/docker/letsencrypt/config(deleted certificates, docker containers etc., and started fresh). - I’ve upgraded HASS form whatever version was the lates docker image in early/mid July to current (issues since at least 0.76.X).
- I’ve started using the new auth system.
- I’ve started using Lovelace.
- Messed with HASS automations and components, but can’t see how that should matter…?
I don’t see errors in the docker logs for letsencrypt and duckdns. My nginx error logs just show what I posted above about 111: Connection refused. And as mentioned, HADashboard access via nginx works fine.
I havent.
It maybe unrelated but I’ve seen some other posts where people cant access the site, where they’ve been told to delete this new .storage dir and start over with the authentication
Hmmm, could be related to that the auth.
After deleting the .storage/auth, .storage/auth_provider.homeassistant and .storage/onboarding, I got to re-create my admin user, but now also browsing to the local IP shows 403: Forbidden… 
So not getting better, but might be a pointer to where the problem is…
not good.
but if you recreated it means you could see the login.so after that 403?
then in that case sounds like its not nginx. this auth change has been painful for many…
I thought I was immensely smart, having everything backed up via rsync to an external HDD. But I made a type when I tried to restore, so now I can’t even boot the OS 
I’m going to use the next few days (if I’m lucky) re-installing Ubuntu Server and go from there. Luckily I have my github that’s reasonably up to date…
One sted forward 403 steps back… And a lesson or two learned.