---
type: explanation
title: Поставь барьер перед целым сайтом на своём обратном прокси
summary: Что такое прокси-барьер, для кого он и как посетитель решает одну игру, чтобы заработать недолгий пропуск, который пропускает его запросы, чтобы ты защищал приложения, куда не можешь встроить виджет.
---

Обычный способ пользоваться Caputchin это встроить [виджет](/docs/site-keys/embedding-the-widget) на страницу и проверить токен на своём бэкенде. Для этого нужно место под виджет и бэкенд для проверки токена. Прокси-барьеру не нужно ни того, ни другого. Он ставит полностраничную проверку перед целым сайтом или маршрутом на твоём **обратном прокси**: посетитель решает одну игру, зарабатывает недолгий пропуск и гуляет по сайту, пока пропуск не истечёт. Защищаемое приложение не трогают вовсе.

Поскольку к самому приложению ничего не добавляется, это способ защитить хосты, куда ты не можешь встроить скрипт, скомпилированный одностраничный портал входа, аплайанс, или внутренний инструмент, сидящий за прокси аутентификации.

<Callout type="info">
Прокси-барьер доступен с плана Alpha и выше, включается на каждый ключ сайта. Caputchin размещает испытание и выдаёт пропуск; ты направляешь на него свой существующий обратный прокси (nginx, Traefik, Caddy, или что бы ни стояло перед твоим приложением).
</Callout>

## Для кого он

Тянись к барьеру, когда встроенный виджет не подходит:

- **У приложения нет места под виджет.** Запечатанный портал входа (как Authelia), аплайанс поставщика, или любой UI, который ты не можешь править.
- **Ты хочешь закрыть барьером целую поверхность, а не одну форму.** "Докажи, что ты человек, прежде чем дойти до этого сайта" вместо проверки на одной отправке.
- **У тебя нет бэкенда для проверки токена.** Обеспечивает правило прокси; нет вызова `/siteverify`, который надо писать.

Для обычной страницы или формы, которую ты контролируешь, лучше встрой [виджет](/docs/site-keys/embedding-the-widget), он легче и не перенаправляет посетителя. Если у тебя есть форма, но нет бэкенда, [размещённая проверка](/docs/hosted-verification/overview) подходит лучше.

## Как это работает

Одно решение покупает много запросов. Посетитель играет в игру один раз; после этого cookie первой стороны пропускает его запросы, пока не истечёт.

```mermaid
sequenceDiagram
    participant V as Посетитель
    participant P as Твой обратный прокси
    participant C as Caputchin
    V->>P: запрашивает закрытый URL
    P->>C: проверка authz (пересылает cookie cpt_gate)
    C-->>P: 401, ещё нет валидного пропуска
    P-->>V: 302 на размещённое испытание
    V->>C: играет в игру
    C-->>V: пропуск, авто-POST на твой callback
    V->>P: POST пропуска на /__cpt/callback
    P-->>V: ставит cookie cpt_gate, перенаправляет назад
    V->>P: запрашивает снова (cookie на месте)
    P->>C: проверка authz
    C-->>P: 204 разрешить
    P-->>V: твоё приложение отвечает
```

Прокси делает маленький вызов **авторизатора** Caputchin на каждый запрос. Когда запрос не несёт валидного пропуска, Caputchin отвечает `401` и прокси перенаправляет посетителя на размещённое испытание. Когда пропуск на месте и валиден, Caputchin отвечает `204` и прокси пропускает запрос к твоему приложению.

## Cookie пропуска

Пропуск живёт в cookie первой стороны с именем `cpt_gate`, которую на твоём собственном домене ставит маленький callback, размещённый тобой. Это подписанный недолгий токен, не привязанный к устройству, так что его безопасность целиком идёт от атрибутов cookie (`HttpOnly`, `Secure`, `SameSite=Lax`) и короткого TTL, который ты выбираешь. Поскольку он ставит cookie твоим посетителям, раскрой это в своей политике cookie. [Руководство по настройке](/docs/proxy-page-gate/set-up) проходит через callback и необходимые атрибуты.

## Что намеренно оставлено за бортом

- **Нет саморазмещаемого барьера.** Caputchin размещает испытание и проверяет пропуск; ты не запускаешь проверяльщик. Твой прокси только пересылает cookie и следует редиректам.
- **Проверка на каждый запрос, а не локальная валидация токена.** Прокси спрашивает Caputchin на каждом запросе. **Режим отказа**, который ты выбираешь (открытый или закрытый), решает, что будет, если Caputchin ненадолго недостижим.
- **Пропуск на ключ сайта, с областью cookie.** Пропуск пропускает один источник, не целый аккаунт и не несколько доменов, потому что это обычная cookie первой стороны.
- **Не сессия и не вход.** Барьер доказывает, что человек дошёл до сайта; твоё приложение по-прежнему занимается аутентификацией и своими лимитами частоты. Двое складываются.

## См. также

- [Настрой прокси-барьер](/docs/proxy-page-gate/set-up): включи его и подключи свой прокси от края до края.
- [Рецепты обратного прокси](/docs/proxy-page-gate/reverse-proxy-recipes): nginx, Traefik, Caddy, и разобранный пример Authelia.
- [Статистика прокси-барьера](/docs/proxy-page-gate/statistics): читай отношение прямого пропуска к испытаниям.
- [Размещённая проверка](/docs/hosted-verification/overview): вариант без бэкенда, когда у тебя всё же есть форма, чтобы направить её на нас.