Веб-службы

Обратный прокси, редиректы, статические файлы и фиксированный текст по доменам — единая веб-точка входа Gately. Расположение в меню: боковая панель «Веб → Веб-службы».

Структура: слушатель, сайт и сайт по умолчанию

Конфигурация состоит из трёх уровней:

1. Слушатель: один прослушиваемый порт. Поля: сеть (tcp — двойной стек, tcp4, tcp6), адрес прослушивания (пусто — все адреса), порт, переключатель HTTPS, минимальная версия TLS (1.0 / 1.1 / 1.2 / 1.3), приём протокола PROXY.
2. Сайт: сайт внутри слушателя, выбираемый по домену. Домен может быть точным, *.example.com (любой уровень поддоменов) или * (все); приоритет сопоставления: точный домен, wildcard, *.
3. Сайт по умолчанию: используется, если ни один сайт не подошёл; если не включён, возвращает 404.

При сохранении изменений сайта или сайта по умолчанию список сайтов заменяется на месте: слушатель продолжает работать, открытые соединения (включая WebSocket) не разрываются, а статистика каждого сайта сохраняется. Если новая конфигурация недопустима, продолжают работать прежние сайты. Изменение собственных настроек слушателя (сеть, адрес, порт, HTTPS, минимальная версия TLS, HTTP/3, протокол PROXY) перезапускает этот слушатель.

Типы сайтов

Тип	Описание
Обратный прокси	Пересылает запросы на один или несколько бэкендов; адрес бэкенда имеет вид http(s)://хост:порт, поддерживается WebSocket
Редирект	Перенаправление на полный URL с кодом 301 / 302 / 307 / 308 (по умолчанию 302), можно сохранять исходный путь и строку запроса. В URL можно использовать {host}, который заменяется доменом, использованным посетителем: https://{host} вместе с «Сохранять путь» направляет все HTTP-запросы на HTTPS того же домена
Статические файлы	Каталог должен быть абсолютным путём; при выключенном «списке каталогов» запрос каталога возвращает ответ только если в нём есть index.html. «URL без расширения» пробует путь.html и путь/index.html, если файл не найден (для VitePress и подобных генераторов, аналог try_files $uri $uri.html $uri/index.html в nginx). «Страница 404» — путь внутри каталога, например 404.html, возвращается с кодом 404
Фиксированный текст	Произвольное содержимое, Content-Type (по умолчанию text/plain; charset=utf-8) и код состояния (100-599, по умолчанию 200)

Дополнительные параметры сайта с обратным прокси:

• использовать Host бэкенда: заголовок Host заменяется адресом бэкенда; при выключении сохраняется Host из запроса клиента;
• пропуск проверки сертификата бэкенда, отключение Keep-Alive;
• отправка бэкенду протокола PROXY (заголовок v2, передаёт реальный IP клиента, нужна поддержка на стороне бэкенда);
• добавление X-Forwarded-For / X-Forwarded-Proto / X-Forwarded-Host / X-Forwarded-Port и X-Real-IP;
• использовать посещаемый домен как SNI (только для HTTPS-бэкендов): при рукопожатии передаётся домен посетителя, и сертификат проверяется по нему, как в nginx proxy_ssl_server_name on; proxy_ssl_name $host. Включите, если бэкенд маршрутизирует по SNI, например vhost_https в frp. У каждого бэкенда свой пул соединений, поэтому соединения не используются повторно для разных доменов.

Для сайтов любого типа можно настроить журнал доступа, CORS, собственные заголовки запроса и ответа (по одному Key: Value в строке; пустой Value удаляет заголовок), а также подключить экземпляр брандмауэра WAF (если экземпляр не существует или отключён, запросы пропускаются).

Транспорт и протоколы

• HTTPS: используется сертификат из модуля SSL-сертификатов, покрывающий домен;
• HTTP/3 (QUIC): включается в прослушивании с HTTPS; на том же номере порта по UDP дополнительно обслуживается HTTP/3, а браузерам он объявляется заголовком ответа Alt-Svc; разрешите этот UDP-порт в брандмауэре и пробросе портов;
• WebSocket: обратный прокси поддерживает его автоматически;
• Протокол PROXY: слушатель может принимать заголовки PROXY от вышестоящих компонентов (haproxy, frp и т. п.) и доверяет только IP или подсетям из списка «Глобальные настройки → Доверенные источники PROXY»; пустой список означает, что источникам не доверяют. Обратный прокси может отправлять заголовок PROXY бэкенду.

Аутентификация

Настраивается на вкладке «Безопасность» в окне редактирования сайта:

• Веб-аутентификация: браузер показывает страницу входа;
• Базовая аутентификация: HTTP Basic;
• Пользователи: по одному имя_пользователя:пароль в строке, пароль может быть bcrypt-хешем. Для базовой аутентификации нужен хотя бы один пользователь; для веб-аутентификации нужен хотя бы один пользователь или сторонняя учётная запись;
• Вход через сторонние сервисы: поддерживаются GitHub, Google, QQ, OIDC с вашими собственными OAuth-приложениями. Разрешённые учётные записи указываются по одной в строке в формате идентификатор_провайдера:аккаунт, например github:octocat, google:me@gmail.com; в конце строки можно добавить примечание после #, а github:* разрешает любой аккаунт этого провайдера.

Провайдеры входа через сторонние сервисы настраиваются в «Глобальных настройках»: укажите собственные Client ID / Secret и включите провайдера, а также задайте адрес обратного вызова (он должен обслуживаться одним из слушателей Gately, например https://auth.example.com). URL обратного вызова, который нужно зарегистрировать в GitHub / Google / QQ:

https://auth.example.com/__gately_auth/oauth/callback

Вход через сторонние сервисы для самой панели управления настраивается отдельно в разделе «Настройки → Аккаунт и безопасность».

Внешняя аутентификация (Authelia и подобные)

Передаёт аутентификацию внешнему сервису, как auth_request в nginx или forwardAuth в Traefik. Отметьте «Внешняя аутентификация» на вкладке «Безопасность». Её нельзя сочетать с базовой или веб-аутентификацией на одном сайте.

Поле	Описание
url	Адрес проверки, например http://127.0.0.1:9091/api/authz/auth-request для Authelia
loginUrl	Куда отправить посетителя, когда сервис отвечает 401, например https://auth.example.com/?rd={url}&rm={method}. {url} — исходный адрес (с URL-кодированием), {method} — метод запроса. Если пусто, ответ сервиса возвращается как есть
copyHeaders	Заголовки личности, которые копируются из ответа сервиса в запрос к бэкенду; по умолчанию Remote-User, Remote-Groups, Remote-Email и Remote-Name

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

• каждый запрос сначала отправляется на url как GET без тела, с заголовками посетителя (cookie, Authorization и т. д.) плюс X-Original-Method, X-Original-URL, X-Forwarded-Method, X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-Uri, X-Forwarded-For и X-Real-Ip. Таймаут — 10 секунд;
• ответ 2xx пропускает запрос, добавляя заголовки личности; ответ 401 перенаправляет на loginUrl (код 302); другие ответы, например 403 или редирект, возвращаются посетителю; если сервис недоступен, возвращается 502;
• заголовки личности, присланные посетителями, всегда удаляются, поэтому их нельзя подделать;
• работает с правилами путей и «Областью аутентификации», так что вход требуется только для части путей (например, /admin), а также с временными ссылками для доступа.

Общие пользователи: TOTP и единый вход

Определите учётные записи один раз и используйте их на нескольких сайтах, при желании с двухэтапной проверкой TOTP. Это покрывает то, ради чего многие запускают Authelia.

В «Глобальные настройки → Общие пользователи»:

• добавляйте пользователей с именем и паролем. Пароли хранятся в виде хешей bcrypt и никогда не возвращаются через API. Чтобы добавить TOTP, нажмите «Включить TOTP», отсканируйте QR-код приложением-аутентификатором (Google Authenticator, 1Password и т. д.) и сохраните. Повторное создание ключа делает прежний недействительным;
• домен единого входа, например example.com: после входа на любом сайте этого домена или его поддоменов остальным сайтам повторный вход не нужен. Используется cookie родительского домена (gately_sso, действует 7 дней), которая никогда не передаётся бэкендам. Оставьте поле пустым, чтобы входить на каждом сайте отдельно.

На сайте отметьте «Использовать общих пользователей» рядом с веб- или базовой аутентификацией. Собственные пользователи сайта продолжают работать.

Поведение:

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

Контроль доступа

Белые и чёрные списки IP

В блоке «Контроль доступа по IP» на вкладке «Безопасность» сайта можно выбрать: выключено, белый список или чёрный список; в списке по одному IP или подсети в строке (например, 192.168.1.0/24); дополнительно можно ссылаться на подписные списки IP.

Подписные списки IP

Списки добавляются в «Глобальные настройки → Подписные списки IP»: укажите URL и интервал обновления (по умолчанию 24 часа). Gately периодически скачивает список и кеширует его в каталоге конфигурации, поэтому после перезапуска он доступен без сети. Содержимое — по одному IP, CIDR или диапазону начало-конец в строке; всё после #, ; или // считается комментарием. Например, для диапазонов IP провинций и городов Китая подходит metowolf/iplist: https://metowolf.github.io/iplist/data/cncity/440000.txt (провинция Гуандун).

• Белые и чёрные списки сайтов и правил путей могут ссылаться на несколько подписных списков; они проверяются вместе с введёнными вручную диапазонами, и совпадение с любым означает попадание в список;
• если скачанное содержимое не распознано (например, вместо списка пришла страница ошибки), сохраняется прежний список, причина показывается у списка, а повторная попытка выполняется через час;
• пока список не загружен, он считается пустым: белый список запрещает доступ, а чёрный ничего дополнительно не блокирует;
• список, на который ссылаются сайты, удалить нельзя.

Правила путей

В блоке «Правила путей» на вкладке «Безопасность» настройки аутентификации и IP сайта можно переопределять по префиксу пути:

Поле	Значения
prefix	Префикс пути, начинающийся с /, например /admin
auth	Как у сайта (пусто), off (аутентификация не нужна), on (аутентификация обязательна)
ipMode / ipList	Как у сайта (пусто), whitelist, blacklist, плюс список IP или подсетей

Правила сопоставления:

• приоритет у самого длинного префикса;
• сопоставление идёт по границам сегментов пути: /admin совпадает с /admin и /admin/x, но не с /administrator;
• путь запроса сначала нормализуется (убираются ., .. и повторяющиеся слэши), поэтому /public/../admin обрабатывается как /admin;
• для одного префикса можно задать только одно правило.

Параметр «Область аутентификации» (authOptional): если он включён, аутентификация действует только для путей, помеченных в правилах как «аутентификация обязательна», а остальные пути открыты. Для этого параметра сначала нужно включить базовую или веб-аутентификацию.

Временные ссылки для доступа

После включения базовой или веб-аутентификации для сайта можно создавать ссылки для доступа, чтобы гости заходили без учётной записи:

Поле	Описание
Название	Примечание, например «Для Ивана»
Срок действия	Пусто — бессрочно
Число использований maxUses	Сколько раз ссылку можно активировать, 0 — без ограничений; счётчик сбрасывается при перезапуске
Ограничение пути pathPrefix	Если задано, ссылка даёт доступ только к путям с этим префиксом; должен начинаться с /

Гость открывает https://домен/любой/путь?_gs=токен и получает сессию. После успешной активации сервер выставляет cookie для входа без пароля и перенаправляет на адрес без параметра _gs; сессия действует не более 24 часов и не дольше срока действия ссылки. Недействительный токен обрабатывается как обычный запрос, причина отказа не раскрывается. После удаления ссылки уже выданные сессии сразу становятся недействительными. Токен генерируется после сохранения (не короче 16 символов), полную ссылку можно скопировать в интерфейсе.

Ограничение попыток аутентификации и автоматическая блокировка

• Если с одного IP-адреса за 15 минут накапливается 10 неудачных попыток аутентификации, дальнейшие попытки временно отклоняются;
• в «Глобальные настройки → Автоблокировка → Блокировка при ошибках аутентификации» укажите число минут (от 0 до 43200): при 10 неудачных попытках IP-адрес источника блокируется; 0 означает отсутствие блокировки, только ограничение частоты;
• при срабатывании автоблокировки публикуется событие AuthBanned, которое можно отправить через центр уведомлений;
• IPv6-адреса учитываются и блокируются по подсетям /64.

Список блокировок

Список блокировок в «Глобальных настройках» показывает заблокированные IP, причину (повторные ошибки аутентификации или ручная блокировка) и время окончания; запись можно снять кнопкой «Разблокировать». Блокировку можно задать и вручную: укажите IP и число часов (от 1 до 720, то есть не более 30 дней); в API по умолчанию действует 24 часа.

Список блокировок общий с защитой от вторжений: когда этот модуль включён, здесь показывается только число блокировок и ссылка на его страницу для управления. Блокировки действуют и на переадресацию портов, STUN и другие службы, а при включённой синхронизации отбрасываются системным брандмауэром; при включённом «Игнорировать адреса локальной сети» такие адреса не блокируются автоматически.

Фильтрация по странам (GeoIP)

В блоке «Фильтр по странам» сайта есть три режима: выключено, только разрешённые, запрещённые; укажите двухбуквенные коды стран ISO через запятую, например CN, HK, US. При включении нужно указать хотя бы одну страну.

• Фильтрация использует базу GeoIP, которую сначала нужно импортировать в «Глобальные настройки → База GeoIP»: загрузите файл .mmdb или укажите адрес для скачивания. Поддерживаются базы стран и городов MaxMind GeoLite2, DB-IP и другие; лимит загрузки — 129 МБ;
• пока база не загружена, фильтр не действует (пропускаются все посетители), в интерфейсе отображается предупреждение;
• адреса внутренней сети пропускаются всегда;
• в режиме «запрещённые» адреса, страну которых не удалось определить по базе, пропускаются.

Бэкенды по путям

Для сайта с обратным прокси направляет запросы с определённым префиксом пути на другие бэкенды, как location /api/ { proxy_pass ...; } в nginx. Добавьте их в «Бэкенды по путям» на вкладке «Основное» окна редактирования сайта.

Поле	Описание
prefix	Префикс пути, например /api/. Сопоставление идёт по границам сегментов пути: /api и /api/ оба совпадают с /api и /api/x, но не с /apix
targets	Бэкенды для этого пути, записываются так же, как бэкенды сайта. Если пусто, используются бэкенды сайта, и добавляются только заголовки ниже
requestHeaders	Заголовки запроса, добавляемые для этого пути, по одному Key: Value в строке. Применяются после заголовков сайта, и заголовок с тем же именем переопределяет заголовок сайта

• приоритет у самого длинного префикса, путь передаётся без изменений (префикс не удаляется);
• остальные настройки сайта, такие как параметр Host, проверка сертификатов, заголовки forwarded, протокол PROXY, политика балансировки нагрузки и проверки работоспособности, действуют для каждого бэкенда по пути;
• сжатие, ограничение частоты, кеш и переписывание действуют на весь сайт.

Расширенные возможности обратного прокси

Эти параметры находятся на вкладке «Трафик» в окне редактирования сайта.

Бэкенды, веса и резервные серверы

В списке бэкендов один адрес в строке, после адреса можно указать параметры:

http://10.0.0.2:8080 weight=3
http://10.0.0.3:8080 backup

• weight=N: вес, целое число от 1 до 100, по умолчанию 1;
• backup: резервный бэкенд, включается только когда недоступны все нерезервные; если недоступны вообще все, запросы снова направляются на нерезервные бэкенды.

Политика балансировки нагрузки

Пункт интерфейса	lbPolicy	Описание
Round-robin (с учётом весов)	пусто	По умолчанию
Случайный (с учётом весов)	random
Хеш по IP (привязка сессии)	ip_hash	Один и тот же IP клиента попадает на один бэкенд
Наименьшее число соединений	least_conn	Выбирается минимум «число соединений / вес»

Проверки работоспособности

Активная проверка по умолчанию выключена. Поля после включения и их значения по умолчанию:

Поле	По умолчанию	Диапазон
Метод mode	http	http (запрос по пути проверки, код ниже 400 считается здоровым) или tcp (только проверка соединения)
Путь path	/	Начинается с /, только для метода http
Интервал interval	10 секунд	от 1 до 3600
Таймаут timeout	3 секунды	от 1 до 60
Подряд неудач fails	3 — признаётся недоступным	от 1 до 20
Подряд успехов passes	2 — восстанавливается	от 1 до 20

Если включена отправка протокола PROXY бэкенду, HTTP-проверка автоматически заменяется на TCP.

Пассивная проверка действует всегда: из нескольких бэкендов тот, на котором 3 раза подряд не удалось установить соединение, приостанавливается на 30 секунд, после чего его пробуют снова (единственный бэкенд без активной проверки из ротации не исключается). Если включена активная проверка, восстановление определяется только её результатами. При изменении состояния бэкенда публикуются события «upstream недоступен» / «восстановлен», которые можно отправить через центр уведомлений.

Сжатие

Сжатие можно включить для сайтов с обратным прокси, статическими файлами и фиксированным текстом (кроме редиректов). По Accept-Encoding предпочтение отдаётся br, затем gzip.

• Сжимается только текстовое содержимое: text/*, JSON, JavaScript, XML, XHTML, RSS / Atom, WebAssembly, SVG; text/event-stream исключён;
• ответы с объявленным Content-Length меньше 256 байт остаются без изменений;
• ответы, у которых уже есть Content-Encoding, остаются без изменений; запросы на обновление до WebSocket пропускаются напрямую;
• сильный ETag после сжатия заменяется слабым.

Ограничение частоты по IP

Ограничение по алгоритму token bucket для IP клиента; поля:

Поле	Описание
rate	Число разрешённых запросов в секунду
burst	Ёмкость всплеска; если задан rate, а burst равен 0, берётся целая часть rate плюс 1
maxConns	Максимум одновременных запросов с одного IP, 0 — без ограничений

При включённом ограничении нужно задать хотя бы одно из полей rate и maxConns.

Кеш ответов в памяти

Работает только для сайтов с обратным прокси; кеш хранится в памяти, вытеснение по LRU.

Поле	По умолчанию	Диапазон
ttl — срок по умолчанию	0	от 0 до 30 дней (в секундах). Если вышестоящий сервер не указал директив кеширования, ответ 200 кешируется на это время; 0 — кешируются только ответы, явно разрешённые вышестоящим сервером
maxMb — размер кеша	64	от 1 до 4096 МБ

Правила кеширования:

• кешируются только запросы GET, в которых нет заголовков Authorization, Cookie, Range и нет Cache-Control: no-cache;
• кешируются только ответы с кодом 200; ответы с Set-Cookie, Vary: * или Cache-Control со значением no-store / private / no-cache пропускаются;
• учитывается s-maxage, затем max-age;
• размер одной записи не больше 4 МБ и не больше четверти общего объёма;
• при попадании в кеш возвращаются заголовки X-Cache: HIT и Age, при промахе — X-Cache: MISS;
• ключ кеша включает Host, полный URI запроса и Accept-Encoding.

Переписывание путей и редиректы

Правила проверяются по порядку, срабатывает первое совпавшее.

Поле	Описание
pattern	Регулярное выражение для пути запроса, например ^/old/(.*)$
to	Результат подстановки, группы доступны как $1
redirect	Выключено — внутреннее переписывание (переписанный путь отправляется бэкенду, цель должна начинаться с /); включено — редирект
code	Код редиректа 301 / 302 / 307 / 308, по умолчанию 302

Редирект сохраняет исходные параметры запроса. Цель редиректа может содержать {host} — домен, использованный посетителем. Правила редиректа выполняются до аутентификации, как location = / { return 302 ...; } в nginx, поэтому по пути вроде / посетителей можно перенаправлять, не требуя входа.

Статистика доступа и мониторинг

Статистика сайта

Для работающего слушателя нажмите «Статистика» в строке сайта, чтобы открыть окно статистики; доступны периоды: последний 1 час, 6 часов, 24 часа:

• поминутная статистика доступа: одна точка в минуту, хранятся последние 24 часа, включает график числа запросов и график ошибок 4xx / 5xx;
• распределение кодов состояния 2xx / 3xx / 4xx / 5xx и суммарный объём трафика ответов;
• топ-10 IP-источников и топ-10 стран (для статистики по странам нужна импортированная база GeoIP);
• для сайтов с обратным прокси показываются состояние здоровья каждого бэкенда, вес, признак резервного и текущее число соединений.

Статистика хранится в памяти; при перезапуске или изменении собственных настроек слушателя подсчёт начинается заново. Изменение сайта сохраняет его счётчики. В рейтингах учитывается не более 5000 различных источников.

Метрики Prometheus

Глобальный эндпоинт метрик GET /api/metrics объединяет метрики всех модулей, см. Мониторинг. Эндпоинт модуля ниже содержит только метрики веб-служб.

Эндпоинт метрик — GET /api/webservice/metrics, формат текста Prometheus; нужны учётные данные для входа или API-токен.

curl -H "Authorization: Bearer gtl_xxxx" http://localhost:16680/api/webservice/metrics

Метрика	Тип	Описание
gately_site_requests_total	counter	Суммарное число запросов к сайту
gately_site_errors_total	counter	Число ошибок бэкенда сайта
gately_site_active_requests	gauge	Число запросов в обработке
gately_site_response_bytes_total	counter	Суммарное число байт ответов
gately_site_responses_total	counter	Число ответов по классам состояния (метка class: от 2xx до 5xx)
gately_upstream_up	gauge	Здоров ли бэкенд: 1 — здоров, 0 — недоступен (с меткой upstream)

Все метрики имеют метки listener (имя слушателя#key слушателя) и site (название сайта, а если оно не задано — первый домен).

Импорт конфигурации nginx

Кнопка «Импорт nginx» вверху страницы преобразует существующие сайты nginx в слушатели и сайты Gately. Рекомендуется выполнить nginx -T на хосте nginx и вставить весь вывод: он содержит все файлы из include, и Gately раскрывает include так же, как nginx.

• Сначала предпросмотр: сайты сгруппированы по порту прослушивания, для каждого показаны тип, бэкенд или каталог, исходный файл и номер строки, а также то, на что стоит обратить внимание (директивы с переменными, regex-location, домены без сертификата и т. п.); для сайтов, которые нельзя преобразовать, указывается причина;
• сайты на том же порту добавляются к существующему слушателю, иначе создаётся новый; уже существующие домены пропускаются, поэтому импорт можно повторять;
• по умолчанию импортированное остаётся выключенным, чтобы проверить сайты по одному параллельно с nginx и затем включить; при отмеченном «Включить сразу после импорта» всё начинает работать сразу (если nginx ещё занимает тот же порт, новый слушатель не запустится);
• что преобразуется: proxy_pass (включая веса, резервные серверы и стратегию балансировки из upstream), статические каталоги root / alias (autoindex, try_files $uri.html, error_page 404), редиректы и фиксированное содержимое через return, редиректы всего сайта через rewrite, add_header, proxy_set_header, gzip, allow / deny, бэкенды по путям, контроль доступа и редиректы на уровне location, listen ... proxy_protocol и quic;
• auth_request преобразуется во внешнюю аутентификацию: адрес проверки берётся из proxy_pass location подзапроса аутентификации (поддерживаются переменные из set), переход ко входу — из error_page 401 =302; типичные конфигурации Authelia преобразуются напрямую. Если аутентификация включена только в части location, «Область аутентификации» ограничивается отмеченными путями;
• auth_basic преобразуется в базовую аутентификацию с общими пользователями; файл пользователей nginx не читается, поэтому, пока пользователи не добавлены, пройти аутентификацию не сможет никто;
• TCP/UDP-переадресацию из stream настройте в пробросе портов; сертификаты не импортируются: если у HTTPS-сайта нет сертификата, предпросмотр показывает файлы сертификатов, которые использует nginx, и их можно добавить на странице сертификатов по пути к файлу.

Замена haproxy и nginx

Проброс портов и веб-службы вместе могут заменить пару haproxy + nginx. Типичная схема: одно правило маршрутизации по SNI на порту 443, которое отправляет VPN и другие TLS-службы прямо на их бэкенды, а всё остальное — на слушатель веб-служб, принимающий протокол PROXY, плюс слушатель веб-служб на порту 80 с сайтом-редиректом (https://{host}).

Перенос настроек nginx:

nginx	Gately
server с server_name	сайт с этими доменами
location с другим proxy_pass	бэкенды по путям
auth_request (Authelia)	внешняя аутентификация или общие пользователи с TOTP
proxy_ssl_name $host	использование посещаемого домена как SNI
return 301 https://$host$request_uri	сайт-редирект с https://{host} и «Сохранять путь»
return 302 /admin в location = /	правило переписывания с включённым «Редирект», pattern ^/$
try_files $uri $uri.html $uri/index.html и error_page 404	статические файлы с «URL без расширения» и страницей 404
add_header	заголовки ответа

Рекомендации по развёртыванию

Веб-службам нужно слушать порты хоста, такие как 80 / 443, поэтому при развёртывании в Docker рекомендуется --network host.