Hey Caddy community,
I built caddy-analyzer, a CLI tool written in Go that natively parses Caddy v2’s structured JSON logs — no config, no regex hacking.
Caddy’s JSON log format is great, but tools like goaccess, lnav, or grep/awk pipelines can’t parse it out of the box. This fills that gap.
Full analysis — aggregate stats, RPS, latency percentiles (P50/P95/P99), status breakdown, bandwidth, top paths/IPs/UAs
Security detection engine — 22 attack categories (SQLi, XSS, SSTI, SSRF, RCE, LFI, Log4j, GraphQL introspection, prototype pollution, scanner detection, etc.) with a dual-pass engine that catches double-encoded and multibyte-encoded bypass attempts
Real-time iptables guard (caddy-analyze guard) — auto-blocks offending IPs at the firewall with configurable thresholds
I’m trying your v0.3.0 and like it! Sadly I don’t have much in the way of http logs from Caddy at the moment to see all the great features of your application.
While I realize the public traffic is the main target, it would be great if your application could parse and present the global.json log also.
Wow, I didn’t expect this tool would actually interest someone!
In any case, I’ll consider this request and as soon as I have some free time, I’ll work on it. I’d just kindly ask you to open an issue on GitHub so I don’t forget and can track it properly.
Also, if you’re interested, a new version is about to be released soon!
Thanks again for the feedback!
I imagine many caddy installations are by people with all sorts of wizardry handling .json file and doing things I’ve never heard of.
My adoption of popular and common methods and tools is way behind the norm I think. I’ve peeked at jq but instead wrote some code for my editor to present .json in a more human readable format.
EG: I have never used docker, no git identity, no facebook, no twitter, and on and on.
I like the features caddy-analyze has to present the assorted stats and view of the caddy-www.json much more than the assorted stitching together of x,y & z and the complexity quickly makes me think I really don’t want to invest the time in assembling an overkill (for me) ‘solution’ to dealing with the specific bit of .json I want to look at.
The console format logs are fine for me too since I am used to text logs for decades and can manipulate them fairly well if needed in my editor… but caddy-analyze is fast and much easier, plus the identification of the various nefarious activity – can’t wait to assemble some logs to see how that works.
Thanks for the kind words! Honestly, keeping it simple is the whole point — there are already enough tools that need a PhD to use.
A sample test.json is a great idea, I’ll add one to the repo so anyone can try it right away.
Looking forward to the issue, and feel free to share what you find in your logs — especially the threat detection stuff. Always curious to see what it catches in the wild.
Looking at the github now. Circling it like a hound figuring out where/when to lay down.
Ironically, my servers are all whitelist only in and out and my primary vehicle for logs is ulogd2 (which can log in .json ) so I’ll work on making a public facing caddy server for generating logs – with all the noise on the internet shouldn’t take too long to accumulate something interesting I imagine.
Not a typo — guard, block, and unban really do exec iptables/ip6tables directly (no netlink, no nft binary). On distros where nftables is the backend, the iptables command is normally the iptables-nft compat shim, so it works out of the box. The only edge case is a minimal nftables-only install without the shim package — there you’d need to apt install iptables-nft (or equivalent) so the iptables binary is on PATH.
just pushed the sample logs to testdata/ — sample.log (68 lines, one per detection category) and large.log (~50k lines, ~27MB). both generated by testdata/generate.py, all TEST-NET IPs so nothing points at a real host.
should be enough to play with --detect and tail -d in the meantime.