Caddy stopping listening to port 80 randomly

1. The problem I’m having:

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> write: broken pipe"}

3. Caddy version:

v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=

4. How I installed and ran Caddy:

Caddy is running as a systemd service. I followed the official documentation for installing Caddy.

Website which is being served by caddy :

a. System environment:

AWS EC2 Instance
OS : Ubuntu 22.04
Using : Systemd

b. Command:

c. Service/unit/compose file:

d. My complete Caddy config: {
        # 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.

        # 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

5. Some screenshots:

I’m pretty bad at explaining things. Kindly take a look at this :

(I dont use HTTP Push, but the issue is kinda similar)

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.

1 Like

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.

1 Like

@ashton I don’t think that’s their issue, because they showed a log message from Caddy that could only be written after Caddy successfully started.

1 Like

Thanks for you explanatio.
Here’s what I got after running curl -v :

*   Trying 2a05:d016:dba:a600:2ecd:d656:86a0:e70f:80...
* Connected to (2a05:d016:dba:a600:2ecd:d656:86a0:e70f) port 80 (#0)
> GET / HTTP/1.1
> Host:
> User-Agent: curl/7.81.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location:
< Server: Caddy
< Date: Wed, 05 Apr 2023 06:09:57 GMT
< Content-Length: 0
* Closing connection 0

That tells me port 80 is working just fine. That’s Caddy serving an HTTP->HTTPS redirect, see the Location header.

1 Like

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.

Well, :man_shrugging:

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.

1 Like

You might want to take look at this ; Frequent hangs when using http/2 push · Issue #3896 · caddyserver/caddy · GitHub

Why I think this could be the issue ?

Maybe Its not related to HTTP2/Push explicitly. The actual issue is similar. Caddy hangs …

More info about api/v1/push : push API methods - Mastodon documentation

That issue is a problem in Go itself. See, which is linked from that issue.

It may or may not be the cause, but there’s nothing we can do about it right now.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.