Скорость ответа зависит от сети, API, PostgreSQL и размера данных. Кэш помогает при повторном чтении одинакового публичного контента; он не заменяет оптимизацию медленных запросов и не ускоряет запись.
Включите кэш там, где допустима задержка
В Generator UI откройте Content → настройки нужной persistent или virtual → Access → External READ access. Разрешите анонимный List или Get, включите Cache public responses, задайте TTL и сохраните. По умолчанию кэш выключен, начальное TTL 30 секунд; допустимо 1–3600. Затем Generate и новый релиз применят настройки к backend и Nginx.
Для сайта с виртуальными страницами включайте кэш у проекций, которые сайт реально запрашивает. Для документации отдельно учитывайте каталог и маршрут открытой статьи. Настройки исходной сущности автоматически не наследуются проекцией. Если посетителям важно видеть изменение немедленно, оставьте кэш выключенным.
Кэш работает в production/prod-local через сгенерированный Nginx, для анонимных external List/Get и успешных ответов 200. Запросы с Cookie или Authorization обходят его. Административные операции, запись и ошибки не кэшируются. Прямое обращение к Go backend не использует этот Nginx-кэш. Параметры запроса учитываются в ключе, поэтому разные фильтры и страницы не смешиваются.
Запись данных не очищает кэш автоматически. Например, при TTL 30 посетитель после изменения статьи может видеть прежний текст еще до 30 секунд. Это касается и изменения связанных данных внутри virtual. Изменение правил доступа требует согласованного выпуска backend и Nginx.
Соединения Nginx → API
Сгенерированный Nginx повторно использует HTTP/1.1-соединения с Go backend. В split-размещении frontend повторно использует HTTPS-соединения к API-серверу с проверкой сертификата и правильного имени. Эти настройки действуют автоматически после применения новых generated-файлов.
Один worker хранит до 32 свободных соединений с backend, закрывая простаивающее через 30 секунд или после 1000 запросов. Это число свободных соединений, не предел параллельных запросов. Адрес backend через Docker DNS обновляется, чтобы замена контейнера не оставляла старый IP навсегда.
Сайт рядом с CMS
Если конфигурация сайта находится в том же Nginx-контейнере, что CMS, API-прокси можно направить на http://127.0.0.1:8080, сохранив API-домен в Host. Это внутренний listener: он применяет те же правила API, кэш и maintenance, но избегает дополнительного HTTPS-соединения обратно в свой контейнер. Порт 8080 не публикуется на VPS.
Сайт из другого контейнера или с другого сервера обращается к публичному HTTPS API. Нельзя подставлять его 127.0.0.1:8080: это уже адрес другого процесса. Публичный HTTPS и проверка сертификатов остаются включенными. У внутреннего HTTP и публичного HTTPS разные записи кэша.
Как понять, где задержка
Из браузера посмотрите время запроса в Network: соединение и TLS, ожидание ответа, размер и скачивание данных. На сервере сопоставьте логи Nginx/API, нагрузку CPU и состояние БД. При нагрузочном тесте сравнивайте одинаковые маршруты, контент, число клиентов и длительность; отдельно учитывайте apt, backup и сборки на сервере.
Ни эти настройки, ни публичный кэш сами по себе не гарантируют определенное число пользователей. Если в логах Nginx есть worker_connections are not enough, это отдельный предел конфигурации; увеличение лимита в текущую доработку не входит.