Port 443 stays binded after reconfiguration

1. The problem I’m having:

I already posted this problem, but found a workaround before.
Release old bindings when HTTPS redirects are disabled - Help - Caddy Community
Now the same problem appears, but the workaround is no longer effective after upgrading from caddy 2.4.7 to 2.7.5

I wanted to change the “listen”-field on a server to no longer listen on all IPs on the ports 80 and 443, but instead listen on all IPs on port 80 and one specific IP on port 443.

Previous configuration:

"listen": [
            "0.0.0.0:80",
            "0.0.0.0:443"
          ]

Target state:

"listen": [
            "0.0.0.0:80",
            "10.33.40.173:443"
          ]

But when I try to patch the config I get an error message saying the port is already binded:

-> % curl -X PATCH -H "Content-Type:application/json" --unix-socket /run/caddy-standard.sock -H "Host: localhost" http://@/config/apps/http/servers/external-interfaces/listen --data '["0.0.0.0:80", "10.33.40.173:443"]'
{"error":"loading new config: http app module: start: listening on 10.33.40.173:443: listen tcp 10.33.40.173:443: bind: cannot assign requested address"} 

On v2.4.7, I used a workaround where I first patched the config to listen only on port 80 and then add the desired IP for port 443, but this no longer seems to work anymore as it results in the same error.

The netstat output also confirms that caddy listens on 443 even when the caddy config is set to only listen to port 80:

netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 :::80                   :::*                    LISTEN      5043/caddy
tcp        0      0 :::443                  :::*                    LISTEN      5043/caddy
udp        0      0 :::443                  :::*                                5043/caddy 
...

Maybe there is a problem with unbinding the port after the caddy config is changed?

2. Error messages and/or full log output:

{"error":"loading new config: http app module: start: listening on 10.33.40.173:443: listen tcp 10.33.40.173:443: bind: cannot assign requested address"} 

3. Caddy version:

v2.7.5 h1:HoysvZkLcN2xJExEepaFHK92Qgs7xAiCFydN5x5Hs6Q=

4. How I installed and ran Caddy:

I have the binary installed on the device

a. System environment:

Debain 10 without systemd, arm64 architecture

b. Command:

/usr/bin/caddy run --pidfile /run/caddy-standard.pid --resume --environ --envfile /etc/caddy/caddy-standard.env```

d. My complete Caddy config:

{
  "admin": {
    "listen": "unix//run/caddy-standard.sock",
    "origins": [
      "localhost"
    ]
  },
  "apps": {
    "http": {
      "servers": {
        "external-interfaces": {
          "automatic_https": {
            "disable_redirects": true
          },
          "listen": [
            "0.0.0.0:80"
          ],
          "routes": [
            {
              "@id": "askendpoint",
              "handle": [
                {
                  "handler": "static_response",
                  "status_code": "200"
                }
              ],
              "match": [
                {
                  "path": [
                    "/ask*"
                  ]
                }
              ]
            },
            {
              "handle": [
                {
                  "handler": "reverse_proxy",
                  "upstreams": [
                    {
                      "dial": "localhost:7000"
                    }
                  ]
                }
              ]
            }
          ],
          "tls_connection_policies": [
            {
              "protocol_min": "tls1.2"
            }
          ]
        }
      }
    },
    "pki": {
      "certificate_authorities": {
        "device_ca": {
          "intermediate_common_name": "Test Intermediate CA",
          "root_common_name": "Test Root CA"
        }
      }
    },
    "tls": {
      "automation": {
        "on_demand": {
          "ask": "http://localhost/ask",
          "rate_limit": {
            "burst": 5,
            "interval": "1m"
          }
        },
        "policies": [
          {
            "issuers": [
              {
                "ca": "device_ca",
                "module": "internal"
              }
            ],
            "key_type": "rsa2048",
            "on_demand": true
          }
        ]
      }
    }
  }
}

5. Links to relevant resources:

https://caddy.community/t/release-old-bindings-when-https-redirects-are-disabled/21891/7

FWIW this pretty much never makes sense, you shouldn’t have one server in Caddy which serves both HTTP and HTTPS. It should be split up onto two servers, one with HTTP and the other with HTTPS.

Please use the latest version, 2.7.6.

Caddy use the SO_REUSEPORT option, so something probably didn’t get cleaned up correctly after that.

It should be just fine after a process restart. You’ll need to restart to use the new Caddy version anyway.

There’s no need to set this, the default is already tls1.2.

This means that interface is not available to your computer. Are you sure the IP address is right? It’s more about the IP address and not the port. If the port was already taken you’d see something like “already in use” error.

@francislavoie I updated caddy to

v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=

Unfortunately this didn’t fix the problem.

I’ll also try to split up the server into HTTPS and HTTP as soon as possible, but could this really be the root of the problem?

In some cases a restart fixed the problem, but it appeared again after the next restart. I think this happens because a default config is loaded when I start caddy, where the bindings are set to

This is something I cannot change.
Is there any option I can force a reload of the bindings without restarting caddy?

@matt Yes, this is the same address that appears in ifconfig and that my ssh connection uses.

We found the source of the problem and it was caused by the system environment. We did not notice that there were two caddy instances that listened on the same socket, which led to a whole bunch of problems. After fixing this, the error did no longer occur.

Sorry for the inconvenience!

1 Like

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