nginx стоїть майже на кожному сервері, де працює веб-застосунок, і в багатьох адміністраторів уже є звичний конфіг з location і proxy_pass. Питання «чи можна тим самим nginx закрити роль API-шлюзу» виникає саме тому — ставити новий сервіс заради кількох правил маршрутизації не хочеться. У статті розібрано, що nginx закриває сам, де в нього є межа, і як зрозуміти, що межі достатньо для конкретного проєкту.
Чим API-шлюз відрізняється від звичайного проксі
Зворотний проксі приймає запит і передає його далі за одним правилом: зазвичай за доменом або за шляхом. API-шлюз додає до цього шар логіки, який стосується саме API — перевірку токена, обмеження частоти запитів для конкретного клієнта, агрегацію кількох бекендів в одну відповідь, версіонування маршрутів.
Межа між ролями розмита: частину функцій шлюзу nginx виконує штатними директивами, частина потребує стороннього модуля або окремого процесу. Тому відповідь на питання «чи підходить nginx» завжди залежить від того, які саме функції потрібні конкретному проєкту.
Що nginx вміє з коробки
Базова маршрутизація за path і за host, проксування на кілька upstream-серверів із балансуванням, обмеження кількості з’єднань і запитів директивами limit_req і limit_conn, завершення TLS, віддача статики в обхід бекенда — усе це штатні можливості, без додаткових модулів. Базове налаштування описане у статті про налаштування nginx.
Туди ж входить переписування заголовків, повернення власних кодів відповіді за умовою, базова авторизація за парою логін-пароль і обмеження доступу за IP через allow і deny. Для внутрішнього API або шлюзу з невеликою кількістю правил цього часто досить без стороннього ПЗ.
Чого бракує без сторонніх модулів
Перевірка JWT або інтеграція з OAuth2-провайдером штатними засобами не робиться — потрібен модуль на кшталт njs (вбудований JavaScript) або винесення перевірки на окремий сервіс, до якого nginx звертається через auth_request.
- перевірки й декодування JWT без написання коду на njs або lua;
- автоматичного service discovery — перелік upstream доводиться оновлювати вручну або через зовнішній генератор конфігурації;
- трансформації протоколів, наприклад перетворення REST-запиту на виклик gRPC;
- єдиної панелі метрик за маршрутами — потрібен експорт у систему моніторингу через сторонній модуль.
Таблиця нижче зводить різницю між голим nginx і спеціалізованим шлюзом за ключовими функціями:
| Можливість | nginx | Спеціалізований API-шлюз |
|---|---|---|
| Маршрутизація за path і host | є | є |
| Rate limiting на клієнта | обмежено, вручну | є за умовчанням |
| Перевірка JWT і OAuth2 | через модуль або зовнішній сервіс | є |
| Service discovery | немає | є |
| Трансформація протоколів | немає | є |
Коли голого nginx досить
Якщо за шлюзом стоїть один-два бекенди, маршрути не змінюються щотижня, а перевірка токена проста — звірка з одним секретом або список статичних ключів, — штатного nginx вистачає без сторонніх надбудов. Та сама логіка стосується внутрішніх API, які не виходять за межі однієї мережі.
На навантаженому сервері варто спершу перевірити, чи не впирається продуктивність у налаштування воркерів і буферів — це розібрано у статті про оптимізацію nginx на VPS, перш ніж додавати ще один шар інфраструктури.
Коли потрібен спеціалізований шлюз або звʼязка з Traefik
Якщо бекендів десятки і вони з’являються та зникають динамічно — у контейнерах або оркестраторі, — ручне оновлення upstream у конфізі nginx стає вузьким місцем. У такому разі логічніше дивитися на рішення з автоматичним виявленням сервісів, наприклад на Traefik як зворотний проксі, який перечитує перелік бекендів без зупинки процесу.
Те саме стосується API з різними протоколами на вході та всередині — REST зовні, gRPC усередині — і схем, де потрібна єдина автентифікація для багатьох незалежних команд розробки: спеціалізований шлюз дає для цього готові політики, а nginx вимагав би власного коду.
Як підготувати nginx до ролі шлюзу
Якщо рішення на користь nginx ухвалено, порядок дій такий:
- винести спільні директиви — ліміти, заголовки, TLS — в окремий конфігураційний файл і підключити через include;
- описати upstream-блок із переліком бекендів і способом балансування;
- додати limit_req_zone і limit_conn_zone для обмеження частоти запитів за IP або за ключем API;
- налаштувати перевірку токена через auth_request, якщо автентифікація потрібна на рівні шлюзу;
- увімкнути логування у форматі, який розбирає зовнішня система моніторингу, і перевірити конфіг командою nginx -t перед перезавантаженням.
upstream api_backend {
server 10.0.0.11:8080;
server 10.0.0.12:8080;
}
location /api/ {
limit_req zone=api_zone burst=20 nodelay;
proxy_pass http://api_backend;
}limit_req_zone $binary_remote_addr zone=api_zone:10m rate=10r/s;
location = /auth-check {
internal;
proxy_pass http://auth_service/verify;
}Часті питання
Чим nginx як API-шлюз відрізняється від Kong або Traefik?
Kong і подібні продукти від початку спроєктовані як шлюз: у них є плагіни для JWT, OAuth2, rate limiting і service discovery без написання коду. nginx дає розвʼязати ті самі задачі вручну або через модуль njs, що гнучкіше, але потребує більше налаштування і супроводу.
Чи потрібен окремий API-шлюз за невеликого трафіку?
За одного-двох бекендів і простої перевірки токена штатних директив nginx зазвичай достатньо. Окремий шлюз виправданий, коли бекендів стає багато і вони змінюються динамічно, або коли потрібна єдина політика авторизації для різних команд.
Чи можна додати rate limiting у nginx без сторонніх модулів?
Так, директиви limit_req і limit_conn входять до стандартної збірки nginx і обмежують частоту запитів за ключем — найчастіше за IP-адресою клієнта. Для тоншої логіки, наприклад ліміту за API-ключем із заголовка, знадобиться модуль njs або винесення логіки на окремий сервіс.
Чи підходить nginx для мікросервісної архітектури з gRPC?
nginx підтримує проксування gRPC через директиву grpc_pass, але перетворення REST на gRPC і назад штатно не робить. Якщо така трансформація потрібна на межі системи, для неї зазвичай ставлять окремий компонент перед nginx або використовують спеціалізований шлюз.