---
type: explanation
title: Eine ganze Site am Reverse-Proxy per Gate schützen
summary: Was das Proxy-Gate ist, für wen es ist, und wie ein Besucher ein Spiel löst, um einen kurzlebigen Pass zu verdienen, der seine Anfragen freigibt, sodass du Apps schützen kannst, in die du das Widget nicht einbetten kannst.
---

Der normale Weg, Caputchin zu nutzen, ist, das [Widget](/docs/site-keys/embedding-the-widget) auf einer Seite einzubetten und das Token von deinem Backend zu verifizieren. Das braucht einen Platz für das Widget und ein Backend, das das Token prüft. Das Proxy-Gate braucht keines von beiden. Es setzt eine Ganzseiten-Verifizierung vor eine ganze Site oder Route an deinem **Reverse-Proxy**: ein Besucher löst ein Spiel, verdient einen kurzlebigen Pass, und streift durch die Site, bis der Pass abläuft. Die geschützte App wird nie angerührt.

Weil der App selbst nichts hinzugefügt wird, ist das der Weg, Hosts zu schützen, in die du kein Skript einbetten kannst, ein kompiliertes Single-Page-Login-Portal, eine Appliance, oder ein internes Werkzeug, das hinter einem Auth-Proxy sitzt.

<Callout type="info">
Das Proxy-Gate gibt es ab dem Alpha-Plan aufwärts, aktiviert pro Site-Key. Caputchin hostet die Challenge und stellt den Pass aus; du richtest deinen bestehenden Reverse-Proxy (nginx, Traefik, Caddy, oder was auch immer deiner App vorsteht) darauf.
</Callout>

## Für wen es ist

Greif zum Gate, wenn das Inline-Widget nicht passt:

- **Die App hat keinen Platz für das Widget.** Ein versiegeltes Login-Portal (wie Authelia), eine Anbieter-Appliance, oder jede UI, die du nicht bearbeiten kannst.
- **Du willst eine ganze Fläche absichern, nicht ein Formular.** "Beweise, dass du ein Mensch bist, bevor du diese Site erreichst" statt einer Prüfung bei einem einzelnen Absenden.
- **Du hast kein Backend, um ein Token zu verifizieren.** Der Proxy übernimmt die Durchsetzung; es gibt keinen `/siteverify`-Aufruf zu schreiben.

Für eine normale Seite oder ein Formular, das du kontrollierst, bette stattdessen das [Widget](/docs/site-keys/embedding-the-widget) ein, es ist leichter und leitet den Besucher nicht um. Hast du ein Formular, aber kein Backend, passt die [gehostete Verifizierung](/docs/hosted-verification/overview) besser.

## Wie es funktioniert

Ein Lösen kauft viele Anfragen. Der Besucher spielt das Spiel einmal; danach gibt ein First-Party-Cookie seine Anfragen frei, bis es abläuft.

```mermaid
sequenceDiagram
    participant V as Besucher
    participant P as Dein Reverse-Proxy
    participant C as Caputchin
    V->>P: fordert eine geschützte URL an
    P->>C: authz-Prüfung (leitet das cpt_gate-Cookie weiter)
    C-->>P: 401, noch kein gültiger Pass
    P-->>V: 302 zur gehosteten Challenge
    V->>C: spielt das Spiel
    C-->>V: Pass, Auto-POST an deinen Callback
    V->>P: POST den Pass an /__cpt/callback
    P-->>V: setzt cpt_gate-Cookie, leitet zurück
    V->>P: fordert erneut an (Cookie vorhanden)
    P->>C: authz-Prüfung
    C-->>P: 204 erlauben
    P-->>V: deine App antwortet
```

Der Proxy macht bei jeder Anfrage einen kleinen **Autorisierer**-Aufruf an Caputchin. Trägt die Anfrage keinen gültigen Pass, antwortet Caputchin `401` und der Proxy leitet den Besucher zur gehosteten Challenge um. Ist der Pass vorhanden und gültig, antwortet Caputchin `204` und der Proxy lässt die Anfrage zu deiner App durch.

## Das Freigabe-Cookie

Der Pass lebt in einem First-Party-Cookie namens `cpt_gate`, das ein kleiner Callback, den du hostest, auf deiner eigenen Domain setzt. Es ist ein signiertes, kurzlebiges Token, nicht an ein Gerät gebunden, also kommt seine Sicherheit ganz aus den Cookie-Attributen (`HttpOnly`, `Secure`, `SameSite=Lax`) und einer kurzen TTL, die du wählst. Weil es ein Cookie bei deinen Besuchern setzt, weise es in deiner Cookie-Richtlinie aus. Der [Setup-Leitfaden](/docs/proxy-page-gate/set-up) geht den Callback und die nötigen Attribute durch.

## Was bewusst weggelassen ist

- **Kein selbstgehostetes Gate.** Caputchin hostet die Challenge und verifiziert den Pass; du betreibst keinen Verifizierer. Dein Proxy leitet nur ein Cookie weiter und folgt Umleitungen.
- **Eine Prüfung pro Anfrage, keine lokale Token-Validierung.** Der Proxy fragt Caputchin bei jeder Anfrage. Der **Fail-Modus**, den du wählst (offen oder geschlossen), entscheidet, was passiert, wenn Caputchin kurz nicht erreichbar ist.
- **Freigabe pro Site-Key, cookie-gebunden.** Ein Pass gibt einen Origin frei, nicht ein ganzes Konto oder mehrere Domains, weil es ein gewöhnliches First-Party-Cookie ist.
- **Keine Session und kein Login.** Das Gate beweist, dass ein Mensch die Site erreicht hat; deine App erledigt weiterhin die Authentifizierung und ihre eigenen Rate-Limits. Die beiden stapeln sich.

## Siehe auch

- [Das Proxy-Gate einrichten](/docs/proxy-page-gate/set-up): aktiviere es und verdrahte deinen Proxy von Ende zu Ende.
- [Reverse-Proxy-Rezepte](/docs/proxy-page-gate/reverse-proxy-recipes): nginx, Traefik, Caddy, und das durchgearbeitete Authelia-Beispiel.
- [Proxy-Gate-Statistik](/docs/proxy-page-gate/statistics): lies das Verhältnis von Durchgang zu Challenge.
- [Gehostete Verifizierung](/docs/hosted-verification/overview): die Option ohne Backend, wenn du doch ein Formular hast, das du auf uns richten kannst.