The gate sits in front of cgit, not inside it
Caddy access rules work well here because the decision is cheap and early. A request either carries a cookie that marks it as allowed, or it comes from a Git client with a User-Agent that starts with git/. Anything else gets stopped before cgit sees it.
That split matters because cloning needs a clean path. Git clients are not browsing a site in the usual sense, so they should not be forced through the same gate as a browser making ordinary page requests. A blunt rule in front of cgit keeps the service usable without baking crawler handling into the repo viewer itself.
Cookie state is the first pass
The cookie is the simplest state check. If not_a_crawler=1 is present, the request passes. If it is missing, the request falls into the challenge response.
That is low-maintenance by design. There is no session store, no external auth layer, and no shared state to keep alive. The downside is just as plain: cookie-based gating only works after the browser has executed the challenge once.
Git clients need a clean path through
Git clients should not be asked to solve a browser challenge. Matching User-Agent values that begin with git/ gives cloning and fetch traffic a direct route while keeping casual scraping on the outside.
That exemption is narrow on purpose. It does not try to classify every legitimate tool under the sun. It just leaves Git alone so the repository still behaves like a repository.
The JavaScript challenge keeps casual crawlers out
Unverified requests get a tiny HTML page that sets the cookie and reloads itself. The browser does the work once, then future requests carry the cookie and pass the gate.
This is not a serious anti-bot system. It blocks unsophisticated crawlers and scripts that do not execute JavaScript. It is also trivial to bypass for anything determined enough to imitate a browser or send the cookie directly. That is the trade-off for a setup that stays close to the reverse proxy and needs very little upkeep.
Return a tiny HTML page, set the cookie, then reload
The response body can be minimal: set document.cookie = 'not_a_crawler=1' and call window.location.reload(). A small HTML page is enough. There is no need for a full challenge flow or a heavier external service.
Using a non-200 status, such as 418, makes the response easy to separate from normal content while still letting the browser process the page. The important part is that the challenge response stays self-contained. It sets state and gets out of the way.
Send everything else to the upstream reverse proxy
Once the matcher accepts the request, Caddy passes it to the cgit upstream with reverse_proxy. That keeps the routing simple: challenge first, repository server second.
The configuration stays readable because the rules are all in one place. One matcher checks the cookie, another checks the Git client path, and the fallback response is a short HTML page. There is no maze of auth plugins or side services to keep aligned.
The rule set is simple, but the boundary is blunt
This kind of Caddy access rules setup is best described as a gate, not a shield. It is good at turning away routine crawlers and awkward enough to discourage casual scraping. It is not good at resisting anyone who already knows what they are doing.
That bluntness is part of the appeal. If the goal is to keep a cgit instance from attracting noise without running a separate anti-bot stack, cookie gating does the job with very little moving parts. If the goal is strong crawler resistance, this is the wrong tool and the bypass will be obvious.
