В логах nginx появляется 499, и кажется, что клиент просто закрыл соединение. Но за таким обрывом может скрываться таймаут балансировщика, медленный бэкенд и запросы, которые продолжают выполняться впустую. На примерах с Go, aiohttp и Angie разбираемся, откуда берутся 499, как они влияют на инфраструктуру и по каким признакам отличить обычную отмену запроса от проблемы на стороне сервера.

Можно ли на один VPS поставить несколько сервисов? Можно, все так делают — у меня на личном VPS крутятся таск-трекер, бот в Telegram, пара пет-проектов и Grafana, чтобы за всем этим следить. Однако немногие знают, как это сделать правильно, поэтому рассказываю под катом. 

У меня круглосуточно работают агенты мониторинга: они собирают бюллетени безопасности и сверяют их с тем, что стоит на серверах. В октябре они подняли сводку: 15 уязвимостей за месяц, все «critical» и «high» — PHP, Nginx, Node.js, Next.js, Java, GitLab. Я проверил каждую строку руками: что это на самом деле, задевает ли меня и чем это лечится.

Итог: две строки меня действительно задели — Node.js был не обновлён четыре дня, а заплатки Nginx не стояли, хотя автообновление включено. Две строки оказались не тем, чем кажутся. А PHP-уязвимости меня не задели по самой простой причине: PHP на сервере нет.

В статье — разбор всех 15 с командами проверки и лечения, почему я снял с сайта все сторонние скрипты и не оставил ни одного инлайн-скрипта, строгая CSP целиком, дыры, которые я нашёл у себя за два месяца, и чек-лист.

В прошлой статье я рассказывал, как устроен мой тренажёр инцидентов изнутри. Сегодня покажу один кейс, седьмой, про 502 Bad Gateway. Он небольшой, но на нём хорошо видно, почему рестарт nginx почти никогда не помогает.

Вводная такая: ночью выкатили релиз, утром магазин отдаёт 502. При этом systemctl status nginx показывает active (running).

502 значит, что nginx запрос принял, передал дальше и нормального ответа не получил. То есть nginx тут свидетель, и начинать надо с его лога: