Nginx Reverse Proxy Set Up Guide – Docker

Share your Projects!
264

It turns out you were quite right.
The server_names_hash error was due to too long URL path, this was fixed by setting server_names_hash_bucket_size 64 in nginx/nginx.conf.
The other error is still there but now it works fine.
Thanks!

1 Like
265

I am running home assistant in a docker container along with nginx reverse proxy + letsencrypt. I have my certs generated but I still cannot connect via the DuckDns url. Do I have to point HA container at the letsencrypt certs? I think I have external_url and internal_url set correctly. I don’t have an http section in my configuration.yaml which is how I previously pointed at the certs. Not sure where to go from here.

More generally speaking does anyone have any tips on how to debug this kind of stuff?

I have the following ports forwarded to my raspberry pi which serves as my docker server. 80->hostip:80, 443->hostip:8123, 8123->hostip:8123

266

if you’re using a proxy, 80 should point to 80 and 443 to 443. Home assistant would connect via the proxy server.

if you’re not too sure how to combine nginx and letsencrypt separately, just the docker im mentioning here and follow the guide. It works on pi as well.

267

I am using the docker image described in this thread linuxserver/letsencrypt. I made the updates to my portforwarding settings that you suggested but I still do not see home assistant when I go to my domain. My docker-compose for letsencrypt is using duckdns + duckdnstoken. I have SUBDOMAIN=wildcard. https://ha.mydomain.duckdns.org does not work. What could I be missing? My default file is setup like the guide shows as well.

268

Actually solved this today. Issue was server_name_bucket_size=32 (something like that, I’m away from my computer). Needed to change that to 64 and things started working!

269

well good to know, but this exact issue was reported by @neliss immediately before you.
forum helps, but needs to be read.

270

really thank for your example. solved my docker nginx proxy host configuration issue

1 Like
271

you are welcome.

272

Thanks for these great instructions, after trying multiple other things for days this is what actually worked to get the secure external https connection working for my homeasssistant. I have an odd setup of running HA on a macmini that dual boots into MACOS and Ubuntu, and HA runs in a docker container on Ubuntu, so typical instructions and documentation generally don’t work for me. But my mac mini, although old, is SO much faster then a PI. One thing I ran across was letsencrypt apparently was recently renamed to “swag” due to a trademark issue. I wasn’t able to get this working at first but that’s one of the things I updated and now it works. Also I couldn’t get things working on ports 180 and 1443, not sure what I was doing wrong or if it was in my router’s port forwarding settings, but since I don’t have anything used on ports 80 or 443 I just stuck with those and everything is now working with those changes. I used the config file from the top post exactly with the replacements for mydomain obtained from duckdns and the replacement of “hostip” with my computer’s actual local 192.etc IP address This was my docker-compose if anyone runs into similar problems, or wants to suggest anything else that should be updated with this “swag” name change. :

version: "2.1"
services:
  swag:
    image: linuxserver/swag
    container_name: swag
    restart: unless-stopped
    cap_add:
    - NET_ADMIN
    volumes:
    - /home/user/docker/swag/config:/config
    - /etc/localtime:/etc/localtime:ro
    environment:
    - PGID=1000 (replace with yours obtained from $ id username command)
    - PUID=1000 (replace with yours obtained from $ id username command)
    - [email protected]
    - URL=MYDOMAIN.duckdns.org
    - SUBDOMAINS=wildcard
    - VALIDATION=duckdns
    - TZ=America/New_York
    - DUCKDNSTOKEN=XXXXXXX (replace with your token from duckdns.org)
    ports:
    - "80:80"
    - "443:443"
273

Thank you for sharing with others. You are correct, the container was indeed renamed swag, but other than that I understand there’s no other significant change.
Happy to hear this guide still helps others.

1 Like
274

anyone any idea how can I resolve this issue

“Received X-Forwarded-For header from untrusted proxy 192.168.1.11, headers not processed”

275

@juan11perez, having been using this since pretty much the day you posted, I have a small suggestion for a change.

I would split out the config in the site-confs/default. Only change the line server_name _; to add whatever your url is instead of the underscore.

Then I’d (as I have done today) create more files and also put in the site-confs directory. I have created one for each service I want served on a sub-domain, but you could also add all in one new file (call it whatever you want, as long as it’s in that directory).

This makes updating MUCH easier.

I found I had a very old site-confs/default file (from 2018/08/15, now it’s from 2020/05/23) because as soon as you change anything in it, it will not update.

You do have to add your server_name, so the file won’t be updated regardless, but the point is that you’ll then just delete the site-confs/default whenever you update the container, and it will recreate the newest version. Then it’s only one line you need to change back again.

I use a script to update all containers in a docker-compose.yaml file, I’ve added a few lines to take care of the site-confs/default as well (haven’t tested with the additions yet, but pretty sure it should do the trick):

#!/bin/bash

cd /mnt/data/docker
docker kill $(docker ps -q)
rm /PATH/TO/site-confs/default
docker-compose build
docker-compose pull
docker-compose up -d swag
docker kill swag
sed -i 's/server_name _;/server_name YOUR_SERVER_NAME;/g' /PATH/TO/site-confs/default
docker-compose up -d

Assuming you’ve named the container “swag”. Replace “YOUR_SERVER_NAME” with your server (e.g. something.duckdns.org), and “/PATH/TO/site-confs/default” to whereever you’ve put that file. Not sure if you’d need to run as sudo, that depends on permissions you have.

Maybe it can be done nicer (it probably can), so someone feel free to post a better version. Just thought I’d add what I finally learned after a few years :slight_smile:

276

Hey guys,
What is the correct / best practice / least confusing way to get the SSL certs out of “letsencrypt/config/etc/letsencrypt/live/domain” in the SWAG docker container and into the Home assistant SSL folder so I can get the the Supervisor add-ins working? (without using the lets encrypt add-in)

I’ve read the “Using certs in other containers” part of the SWAG guide but I’m unclear on how to implement it. I’ve also read a few guides off these forums but don’t seem to relate exactly to my situation.

In short,

  • Running Lets Encrypt/Swag and HassIO docker containers
  • Getting SSL errors trying to connect to supervisor add-ins
  • Need to pass SSL cert from swag to hassio but not sure how

Example error:
( 20-11-16 00:23:40 ERROR (MainThread) [supervisor.api.ingress] Ingress error: Cannot connect to host 172.30.32.1:62507 ssl:default [Connect call failed (‘172.30.32.1’, 62507)]
)

277

Hey there, thanks for the guide!

How would you integrate SWAG in the supervised installation method? (Installing Home Assistant Supervised on a Raspberry Pi with Debian 10)

As my setup isn’t completely starting with docker-compose, how would i provide HA with the needed config? Is modifying “http:” in configuration.yaml enough?

Do you have any experience in running additional addons like mqtt? Is it also working?

278

It will work as per the example. In the process of setting up supervised, you’ll install Dockers and therefore you can run any Dockers.

You’d only need to add docker-compose for your raspberry pi.

A quick search will offer guides on that. Once you have docker-compose installed you can add any other docker,

An alternative is to install portainer via command line and then use the built in docker-compose. Once installed you go into stacks, add your docker-compose content and hit deploy. Keep in mind it currently uses docker-compose version 2, but that’s not a hindrance at all.

Finally I’d suggest you look at this https://nginxproxymanager.com/ instead of swag.
It has a graphical interface and it’s very easy to use. It provides generic nginx config, fetches the certificate etc. It’s just easy.

279

I’m having trouble starting Nginx Proxy Manager because hassio ist already running and restarting all the time. Do I need to make any changes to the ha and hassio containers? (I’m already using portainer and set up Nginx Proxy Server as a stack)

280

if hassio is restarting then you have another problem. what’s causing to restart?

281

First of all, I appreciate your support!

It seems that the supervisor installation starts a systemd service which causes hassio to restart, no matter how you set the restart policy in docker.

So in theory i could start Nginx Proxy Manager but now i get the following errors:

From db:
standard_init_linux.go:211: exec user process caused "exec format error"

And from app:
[4:17:17 PM] [Global ] › ✖ error getaddrinfo ENOTFOUND db

Any idea? Do I have to set up MySQL myself?

282

that’s correct. hassion uses systemd to start the containers.
I just saw that there’s a community addon for nproxy manager. That may be easier.
in any case this is my compose for nproxy

  nproxy:
    container_name: nproxy
    image: jlesage/nginx-proxy-manager
    restart: unless-stopped
    hostname: UNRAID  
    volumes:
    - /mnt/cache/appdata/nproxy:/config:rw
    environment: 
    - USER_ID=99
    - GROUP_ID=100
    - TZ=Asia/Dubai
    - DISABLE_IPV6=1
    - UMASK=000
    ports:
    - "7818:8181"
    - "180:8080"
    - "1443:4443"

Im using the default sqlite, no need to create another database

1 Like
283

Thanks for sharing, you saved me A LOT of time! Cheers mate

1 Like