I have changed my reverse proxy from nginx to Caddy due to the simpler HTTPS configuration. It worked very well out of the box however, there are times where Caddy suddenly stop listening to port 80 and all the websites being served by caddy is inaccessible from the external network(tested from the port open tool). The weird thing is that caddy serves port 80 normally in the internal network, where the most of the DNS are pointed to the Caddy web server, port 80 seems to be open.
I tried restarting the Caddy service but to no avail. A simple restart of the linux server where Caddy is solves the problem. Does anyone knows what happened and why this issue will occur?
Not working from the external network, but working from the internal one, would seem to implicate the edge firewall. But if it works again after resetting the Caddy host server itself, that points to its own firewall instead. Do you have any software on the host that interacts with the firewall?
Apparently the only firewall on the linux instance is the default UFW preinstalled. Even after disabling it, port 80 is still closed externally. Everything seems to be working fine until now since I restarted it yesterday. Not sure when this random closing of port will happen again.
I tried to look in the logs but it seems like the logs are not working. I edited default log file on the stock serviced file to be saved to /etc/caddy/access.log but seems like it doesn’t work.
Some new development, upon notification of port 80 being down I got this on the log.
That is traffic being forwarded from the firewall. Ports 80 & 443 are fully open. This only happens randomly though.
The IP of the log I posted was the external IP address, I just had another error log similar to what I posted but was the IP of the linux instance that hosted Caddy.
That log indicates that Caddy is receiving traffic on port 80 just fine.
Specifically, that message is given when a client connects to Caddy, but requests a Host for which you have no site configured (e.g., you only have example.com in the Caddyfile, but the client requests google.com or perhaps no Host at all).
When this happens, Caddy returns Status 404 with the body 404 Site [Host] is not served on this interface.
Thanks for the explanation, so that is not really useful in solving this issue.
After reading through the forums and searching on google, I found that many people are experiencing issues with this and all of them are using serviced. I ran caddy directly and it was very stable, being able to go on more than 24 hours without dropping traffic.
However, 15 mins ago traffic was dropped once again without any apparent reason with no indications on the logs or whatsoever:
This serviced? (Sorry, Googling this one was a bit difficult…)
And do you have any other monitoring services checking this particular Caddy host? Can we rule out some issue between UptimeRobot and Caddy on serviced specifically?
Does browsing to the site manually also fail while the monitor is reporting the downtime (I think you said a port testing tool shows it is closed externally when this happens)?
I apologise for the typo, it’s systemd. I followed the instruction to run caddy as a service so that it auto starts after restarts.
I am monitoring through 2 services namely pingdom & uptime robot. I have one monitoring config doing a constant ping with the external IP address and it is up when the port 80 was reported down.
For previous incidents where caddy is run through system, I suspected that there be a false positive from uptime robot side and tried accessing the websites, they are down indeed.
The latest downtime is less than 30 seconds, which is too short for me to test if it is a false positive or not. I’ll keep this thread updated should there be any more incidents of this issue.
Stapling lets Caddy retrieve an OCSP response verifying the certificate revocation status and pin it to the certificate as it’s presented, so clients won’t need to make the additional request themselves to make sure the certificate is still valid.
I don’t believe OCSP stapling can be disabled. The server resource cost of stapling is negligible in the extreme.
