I have migrated 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?
2. Error messages and/or full log output:
aborting with incomplete response","error":"write tcp 172.31.46.175:443->172.107.226.134:45398: write: broken pipe"}
Caddy is running as a systemd service. I followed the official documentation for installing Caddy.
Website which is being served by caddy : nixorigin.one
a. System environment:
AWS EC2 Instance
OS : Ubuntu 22.04
Using : Systemd
b. Command:
c. Service/unit/compose file:
d. My complete Caddy config:
nixorigin.one {
# Set this path to your site's directory.
root * /var/www/html/public
header {
X-Frame-Options "SAMEORIGIN"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
}
php_fastcgi unix//run/php/php8.1-fpm.sock
# Enable the static file server.
file_server
# Another common task is to set up a reverse proxy:
# reverse_proxy localhost:8080
# Or serve a PHP site through php-fpm:
# php_fastcgi localhost:9000
}
I don’t understand why you’re saying the problem is with port 80. That’s the HTTP port, whereas port 443 is the HTTPS port. What’s your evidence that the problem is specifically with that port?
This log message is also saying Caddy wasn’t able to write back to the client who connected on port 443. “Broken pipe” typically implies that the connecting client closed or broke off the connection, meaning the server isn’t able to write back to it. That might be “fine”.
Your config is setting up Caddy to listen on port 443 for HTTPS connections, and Automatic HTTPS implicitly enables a listener on port 80 for HTTP->HTTPS redirects and for solving the ACME HTTP challenge. No other regular traffic will happen on that port, since your users should all be redirected to use port 443 for HTTPS anyway.
What do you see when you make a request with curl -v? What else is in your logs? Please show some more evidence.
Basically, you already have a service running on port 80, so Caddy cannot start. You must figure out what is this service and stop it. In most cases, it’s either Apache or Nginx: sudo netstat -nlptu | grep 80 sudo systemctl stop nginx sudo systemctl stop apache.
Yeah. Its working fine now. But I don’t understand why caddy sometimes stops serving requests. I see only “broken pipe” error when this happens. Most of the times it automatically starts to work again after 1-5 minutes of downtime.
Without more evidence, there’s not much I can suggest. I doubt it’s a problem with Caddy, it probably has to do with other parts of your network in front of Caddy.
