Need unblock IP

That definitely looks relevant! There’s also lots of other closed/open issues there of folks having problems with caddy. People are getting linked to the script from this wiki on the same repo:


Bingo. Nice find, thanks.

That’s the crux of the problem.

The latest CertMagic has a check to detect when the storage is inoperable before doing any ACME operations (do any other ACME clients do this?). It may lighten the load on LE’s servers, but it won’t fix the underlying problem.

@sydneyli Yeah, I’ve seen a few as I scoured GitHub, but strictly speaking this could happen with any ACME client: if the storage isn’t writeable, it will produce an error. And simply restarting the process endlessly in the hopes that the error goes away will naturally result in lots of network traffic.

I am not really sure where the problem originated and why so many people have read-only file systems, but that definitely needs to be addressed to fix this at large.


Maybe ? systemd’s more exotic features are a bit of a pain in the ass to use safely because Linux distros have a very wide spread of versions …


Which is exactly why we don’t have an official systemd unit. :slight_smile: (For now. v2 will have one.)

There’s a lot of history in the community-maintained systemd service file, and I’m not really up on all of it, but the Caddy docs are pretty clear as to how it should be wielded: – as are our guidelines/recommendations for automated deployments:

Anyway, yeah, systemd is kinda the worst and nobody knows how to use it properly – I know I certainly don’t – all I can do for now is do my best to document how Caddy works and how it should be handled, then leave it up to the sysadmins to know how to use their computers.

I don’t think so—your stuff is used in far more fully automated and hands-off circumstances than most other ACME clients. (This is 100% meant as a compliment!)


The idea is actually from @jsha. And unfortunately, this feature won’t be released until the next tag. I wish the current v2ray clients could have it already.

1 Like

Certbot has it somewhat accidentally - I think the lock files introduced in 0.14.0 would prevent a similar incident.


Thanks! I tried this script on a temporary host, and it was able to successfully set up Caddy and get a certificate. From the discussion at, it sounds like 233boy recently pushed a fix to the script to address the systemd interaction reported in However, it’s not clear where the code is maintained. The 233boy/v2ray repo’s codebase just says “Removed.” @sydneyli do you have any idea where the source is maintained now?

One other interesting finding: On my test install, I get this systemd unit for Caddy, which has Restart=always and RestartSec=3, both of which contribute to excessive-traffic situations. If anyone has any idea where this systemd unit originates, I’d like to get it fixed.

Description=Caddy HTTP/2 web server

ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp
ExecReload=/bin/kill -USR1 

1 Like

Change to the master branch. The (default) rm branch was last changed in May, but master is being actively maintained.

Strategy to hide from search engines? IDK.


Nice find, thanks! Looks like the script was previously getting the community-maintained Caddy config from the Caddy repo, but switched over to an inline-generated systemd unit when that stopped working:

I can try sending the author a pull request.


This one fixes Caddy’s systemd unit:

And I posted to the related V2Ray issue asking them to change their systemd unit or go back to using Caddy’s:


It works
Thanks all of you


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