Is it possible to use two duckdns but different hassio (192.168.0.1 and 192.168.0.2) at same network in one caddyfile?
Or I should create two caddy for each one
@Abertil, you need to proxy the Authorization header. Caddy doesn’t do this by default. On the host that needs to receive the callback do something like:
xxx.xxx.duckdns.org {
proxy / 192.168.xxx.xxx:xxxx {
websocket
transparent
header_upstream Authorization {>Authorization}
}
}
@Rodolfo_Vieira, this addon and dnsmasq are two different animals. Caddy is a web server while dnsmasq is (mainly) an DHCP/DNS server.
@yeahh, can you explain a bit more about what you mean? Caddy can definitely proxy to multiple internal hosts.
2 Likes
would that port normally be 8123 for Home Assistant??
Correct. I was mainly just using a snippet of their code. I would actually use localhost like:
proxy / localhost:8123
1 Like
yeah… just checking lol. I tried that in mine and I’ll see what happens if I get a notification.
Hey
I’ve just done a brand new install of HA (my last SD card died), and now I’m having problems installing Caddy. I’ve added the right repo, and when trying to press the Install button it sits for a few seconds, flashes red and shows Install again.
The error in the log is:
19-03-09 17:09:37 INFO (SyncWorker_9) [hassio.docker.interface] Pull image korylprince/hassio-caddy-armv7 tag 1.4. 19-03-09 17:09:40 ERROR (SyncWorker_9) [hassio.docker.interface] Can’t install korylprince/hassio-caddy-armv7:1.4 -> 404 Client Error: Not Found (“pull access denied for korylprince/hassio-caddy-armv7, repository does not exist or may require ‘docker login’”).
I’ve installed it multiple times before, but now it doesn’t work.
The closest post I’ve seen is here: Docker pull issues: error 404 and TLS handshake timeout
It looks like they just added support for armv7. I’ve built and pushed a build for armv7 to Docker Hub. If you have any issues, please comment on the Github Issue.
Hello,
my caddy addon just died. 2 hours ago everything was working perfect and now I’m unable to log into my HA instance from outside my lan. Tried to rollback my last working backup but it changed nothing. No changes were made to my network config. It stopped working without any reason.
Config is:
{
"flags": [
"-agree",
"-email",
"[email protected]"
],
"env_vars": []
}
My Caddyfile:
xxxxxxx.duckdns.org {
header / {
Strict-Transport-Security "max-age=31536000; includeSubdomains"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "same-origin"
}
proxy / localhost:8123 {
websocket
transparent
}
}
yyyyyyyy.xxxxxxxxx.duckdns.org {
proxy / localhost:XXXX {
websocket
transparent
}
}
Do you have any idea what may be wrong?
- my IP is not in ip_bans file
- router and rpi restarted multiple times
- HA version 0.97.2
- Hass.io supervisor 179
Here is a sample of mine… only 2 slight differences to yours. Mine is still working.
I assume you have port 80-80 in your router so that SSL can be renewed?
my-domain.duckdns.org {
header / {
Strict-Transport-Security "max-age=31536000; includeSubdomains"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "SAMEORIGIN"
Referrer-Policy "same-origin"
-Server
}
proxy / localhost:8123 {
websocket
transparent
header_upstream Authorization {>Authorization}
}
}
Is the add-on still running or will it not start? If it won’t start, the Hass.io supervisor log should tell you why.
If it is running, is anything showing on the log when you try and make a request from the outside? If you do see entries then there’s likely an issue with your proxy configuration, and the log entry should help you track that down.
If there’s no log entry then your request is not making it to Caddy, which means your dynamic DNS isn’t working, or your router isn’t forwarding ports correctly.
@korylprince
Thank you for answer.
Add-on is starting and running without errors. Log:
Using built-in Caddy: Caddy 0.11.1 (unofficial)
Running Caddy: /usr/sbin/caddy -conf /share/caddy/Caddyfile -agree -email [email protected]
Activating privacy features... done.
https://xxx
https:/yyy
http://xxx
http://yyy
Nothing is showing on the log when I make request through duckdns, so there might be problem with DNS, but I’ve not changed anything since couple of days. I saw some reports about new supervisor breaking couple of addons. Do you have an idea if that may be the case?
Forwarding is set like 80->80, 443->443. Hassio is running on static ip.
Small update- I was able to get it working again by changing localhost to actual IP address of my rpi.
yyyyyyyy.xxxxxxxxx.duckdns.org {
proxy / localhost:XXXX {
websocket
transparent
}
to
yyyyyyyy.xxxxxxxxx.duckdns.org {
proxy / IP_ADDRESS:XXXX {
websocket
transparent
}
Interesting to say the least!
There is an issue a LOT of people are seeing with supervisor 179… just weird DNS stuff. There’s a nice shiny nice new hassio_dns container that seems to be the culprit. Frenck advised people to NOT edit the file /usr/share/hassio/dns/corefile but instead from the ssh addon to issue a command
hassio dns options --servers dns://x.x.x.x
where x.x.x.x is the ip address of the dns server - in my case my router.
Then to reboot…
As soon as I rebooted, I could still access everything via my ipaddress:port but my duckdns address wouldn’t work either.
I guess it stands to reason… 1.1.1.1 and 8.8.8.8 (the default dns servers in that corefile) and also the added x.x.x.x - none of them are going to resolve the localhost to the ip address of the pi.
Long story short, I edited my caddyfile with the ip address of my HA device and restarted caddy and everything roared into life again. So it’s the supervisor 179 that caused this. They are looking for a fix but most probably will continue to need to use the ipaddress instead of localhost in caddy.
I needed to do the exact same thing today after i uppgraded HA.
Another question I’ve tried to find answers to for some while, is it possible to have other addons use the certs created by caddy? For example my unifi controller addon running in hassio?
If so, how do you do it? 
I do it with sub domains in Caddy…
you can also use 127.0.0.1 instead of localhost. this should save you a lot of headache if you -for whatever reason- have to change your rpi’s ip address in the future and forgot you used it in your caddy config 
btw: caddy version 1.0.3 was released some days ago and it’s working flawlessly for me. since caddy version 1.0.2 fixed a security vulnerability you should consider using it with this add-on.
How?
Good idea about using 127.0.0.1 - I’ll try that tomorrow…
download your customized binary from caddy’s website. the latest version of a pi 3 b+ compatible binary without any plugins and disabled telemetry can be downloaded by using this link: https://caddyserver.com/download/linux/arm7?license=personal&telemetry=off
open the downloaded file, find the file caddy in the root of the archive, extract it, rename it to caddy.bin and place it next to your Caddyfile in the share folder. restart the caddy add-on and have a look at the log. it should start with “Found custom Caddy” and the version of the custom binary.
2 Likes
Good point. I’ll do that.