What is Berghain?
Think of it as the bouncer at the velvet rope, and your backend as the party on the other side.
Berghain is a stateless bot-gate that sits in front of a website. It is implemented as an HAProxy SPOE agent (Stream Processing Offload Engine) written in Go. Before a request is allowed through to the real application, Berghain checks whether the visitor is carrying a valid “clearance” — and if not, it briefly holds the request and shows a short verification screen instead.
The goal is simple: keep automated abuse out while letting real browsers in with as little friction as possible. Legitimate visitors usually pass through in a few seconds and rarely see the screen again, because their clearance is remembered by their own browser (in a cookie), not by a server-side database.
Stateless by design
There is no session store to look you up in. Your clearance travels with you in a single signed cookie, so Berghain can scale horizontally and forgets you the moment the cookie expires.
Runs at the edge
It plugs into HAProxy, a battle-tested load balancer, so the check happens before traffic reaches your application — no code changes to the protected site are required.
Why bot protection?
The modern web is crawled relentlessly. Scrapers, credential-stuffing scripts, content thieves and aggressive AI-training crawlers can generate far more traffic than real people, driving up costs and degrading the experience for everyone else.
- Stop automated scraping of content, prices and personal data.
- Blunt credential-stuffing and account-takeover attempts before they hit login forms.
- Shield fragile or expensive endpoints from floods of automated requests.
- Keep infrastructure costs down by turning away traffic that was never a customer.
Berghain asks every visitor to prove they are running a real, capable browser. That is cheap for a genuine person and their browser, but expensive to fake at scale for a bot farm.
Privacy
Berghain is built to verify you without building a profile of you.
One signed clearance cookie
Your authorization lives entirely in a single signed berghain cookie. It is an
HMAC computed over the host you
are visiting, your IP address, the challenge level and an expiry time. If any of those
change, the cookie no longer validates — and that is the whole mechanism.
No server-side store
Because verification is stateless, there is no database of visitors, sessions or fingerprints to query, leak or subpoena. The server only re-computes the signature and compares it. Nothing about your visit is retained after the cookie expires.
Your IP is bound, not stored
Your IP address is mixed into the cookie's signature so a clearance cannot be copied to another machine. It is bound cryptographically, not saved in plaintext as a record of where you were.
No third-party CDN
The verification screen and any proof-of-work run in your own browser and are served from the same site you are visiting. There are no external trackers, fonts or scripts loaded from someone else's servers — and this help page follows the same rule. The one exception: if the operator enables a captcha level, the widget script is loaded from that captcha provider (Cloudflare Turnstile, hCaptcha or Google reCAPTCHA) and the provider's own privacy policy applies to it.
Blocked? Troubleshooting
If you keep seeing the “Request on Hold” screen and the verification will not complete, it usually means your browser could not run or store the check. Work through the list below — most cases are fixed by one of the first three items.
1. Update your browser
Very old browsers may lack the features the challenge relies on. Install the latest version of your browser and try again.
2. Enable JavaScript
The verification runs a small piece of JavaScript. If scripts are disabled globally or for this site, the check can never finish. Allow JavaScript and reload.
3. Enable cookies
Your clearance is stored in a cookie. If cookies are blocked, you will be sent back to the verification screen on every request. Allow cookies for the site and reload.
4. Disable aggressive extensions
Some privacy or script-blocking extensions interfere with the challenge. Temporarily disable them (see Browser extensions) and reload.
5. Try another browser
If the verification still repeats, try a different, mainstream browser to confirm whether the problem is your current setup.
6. Still stuck?
Note the support ID shown on the verification screen (it looks like
bh@<uuid>) and report an issue so an operator can
correlate your report with its challenge logs.
Browser compatibility
The verification needs a modern browser with JavaScript and cookies enabled. The proof-of-work step hashes with the Web Crypto API when the site is served over HTTPS, and falls back to a bundled JavaScript SHA-256 implementation on plain HTTP, so it does not depend on a secure context to work.
| Browser | Supported | Notes |
|---|---|---|
| Google Chrome (current) | Yes | Recommended. Web Crypto available on HTTPS. |
| Mozilla Firefox (current) | Yes | Works with default settings. |
| Microsoft Edge (current) | Yes | Chromium-based; behaves like Chrome. |
| Apple Safari (current) | Yes | Works with default settings. |
| Opera / Brave / Vivaldi (current) | Yes | Chromium-based. Disable extra shields if the check repeats. |
| Legacy / EOL browsers (e.g. IE 11) | No | Missing modern APIs; not supported. |
| JavaScript or cookies disabled | No | The challenge cannot run or be stored. |
| Browser | Supported | Notes |
|---|---|---|
| Chrome for Android | Yes | Works with default settings. |
| Safari on iOS / iPadOS | Yes | Works with default settings. |
| Firefox for Android | Yes | Disable strict tracking blockers if the check repeats. |
| Samsung Internet | Yes | Chromium-based; works with default settings. |
| Private / incognito mode | Problematic | Fine while the tab stays open; clearance is lost when it closes. |
| In-app / embedded webviews | Problematic | May restrict cookies or scripts. Open in a full browser instead. |
Browser extensions
Most extensions are harmless. A few — specifically strict script blockers and canvas / fingerprint blockers — can break the JavaScript challenge, because they remove exactly the browser capabilities the check depends on.
| Category | Impact | What to do |
|---|---|---|
| Ad blockers (standard lists) | Usually fine | No action needed in most cases. |
| Script blockers (e.g. NoScript, uMatrix) | Breaks the challenge | Allow scripts for the site, or disable temporarily. |
| Canvas / fingerprint blockers | May break harder challenges | Whitelist the site if verification repeats. |
| Anti-fingerprinting suites (e.g. JShelter) | May block the crypto the check needs | Relax protection for the site. |
| Cookie blockers / auto-cleaners | Loses clearance | Allow cookies for the site so clearance persists. |
Open Source
Berghain is open source. Nothing about the door policy is a secret.
Because Berghain relies on cryptography (an HMAC-signed cookie) rather than on hiding how it works, the whole thing can be public. You can read the code, audit exactly what data the cookie contains, verify the privacy claims on this page for yourself, run it on your own infrastructure, and contribute improvements.
Released under the Apache License 2.0. Contributions, audits and bug reports are welcome.
Network & client restrictions
What a visitor must satisfy depends on how the operator has configured Berghain and the surrounding HAProxy setup. The list below separates what Berghain itself enforces today from optional measures an operator may add. Expand each item to learn more — no JavaScript required.
Enforced by Berghain
JavaScript is required
The verification screen runs a small script to complete the challenge and obtain your clearance cookie. With JavaScript disabled, the check cannot proceed. This is a core part of how Berghain distinguishes real browsers from simple scripts.
Cookies are required
Your clearance is a single signed cookie. If your browser will not store it, every request looks unverified and you are returned to the challenge. Cookies must be enabled for the protected site.
Progressive friction (challenge duration & countdown)
Operators define one or more levels, each with its own duration and, optionally, a short countdown before the check completes (configurable from 0 to 9 seconds). Higher levels can impose a longer or more visible wait, so protection can escalate for riskier traffic while ordinary visitors get the lightest touch.
Proof-of-work challenge
A level can require a proof-of-work: your browser must find an input whose hash begins with a run of zero bits. It is deliberately cheap for one genuine visitor but costly to repeat across a bot farm. The computation runs entirely in your browser — the server only hands out the puzzle and checks the answer.
Captcha challenge (Turnstile, hCaptcha, reCAPTCHA)
A level can require solving a captcha widget from Cloudflare Turnstile, hCaptcha or Google reCAPTCHA. The widget appears on the verification screen; once it is satisfied, its response is checked with the provider and you receive the same clearance cookie as with any other level. The widget script is loaded from the provider's servers, so a content blocker that blocks the provider will also block the verification — the screen will tell you when that happens.
May be enabled by the operator
IP reputation (CrowdSec)
An operator may consult a community threat feed such as CrowdSec and apply extra friction, or a block, to addresses with a poor reputation.
VPN & Tor exit handling
Traffic arriving from known VPN endpoints or Tor exit nodes may be treated with more caution, since these are frequently used to mask automated abuse.
Datacenter / ASN blocking
Requests originating from hosting-provider and datacenter networks (by ASN) may face stricter handling, because ordinary visitors rarely browse from server ranges.
Cloudflare WARP
Operators may choose how to treat traffic relayed through Cloudflare WARP, either allowing it or applying additional checks.
Apple Private Relay
Connections coming through Apple Private Relay may be handled with a dedicated policy so that legitimate iCloud+ users are not unduly penalized.
AI-browser handling
Automated “AI browsers” and agentic crawlers may be identified and routed to stricter challenges or a dedicated tarpit at the operator's discretion.
Rate limiting
Operators commonly add request rate limits in HAProxy so that even verified clients cannot flood an endpoint. Limits and thresholds are set per deployment.
Report an issue
If you believe you are being blocked by mistake, or the verification will not complete after working through the troubleshooting steps, please open an issue so an operator can help.
What to include
Include the per-page support ID shown on the verification screen, your browser and version, your operating system, the address you were trying to reach and what happened. The ID is randomly generated by your browser and is used only to correlate the report with challenge logs; it is not derived from your IP address.