Алексей Арх

nginx по умолчанию склеивает слэши - merge_slashes off; // on по умолчанию
Это может привести к сюрпризам.

Например если вы используете nginx кэш, ключ кэша строится от урла.
Вы зайдёте на site/page.html, а там закешированна 404, потому что кривой парсер зашёл на site//page.html, а ваш бэк nginxу отдал 404, который он закешировал в ключ md5(site/page.html)

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

Вариант лечения, который я вижу на данный момент - это добавить merge_slashes off; перед секцией server
А в начале секции server прописать две регулярки.

rewrite ^//([^/].*) /$1 permanent;
rewrite (.*)//+(.*) /404 permanent;

Первая сработает если вначале ссылки два слеша (site//page.html) и перенаправит на один слэш (site/page.html)
Это распространённая ошибка, например пользователь скопировал относительную ссылку, вставил в адресную строку, а там уже забит домен.
Или парсеры, которые криво парсят.

Вторая регулярка сработает если не сработала первая, и если два и больше слешей есть в оставшемся урле, тогда считаем это ошибкой и редиректим на подготовленную 404 страницу

Это site//page.html исправится на это site/page.html
Это site/cat//page.html на /404
Такой урл site/page.html?utm=https://site не попадает под регулярки.

Можно использовать только одну регулярку
rewrite (.*)//+(.*) $1/$2 permanent;
Тогда все двойные слэши исправятся на одинарные (кроме параметров ссылки)
Но это каждый раз новый редирект. В конечном счёте вы получите ERR_TOO_MANY_REDIRECTS

Лучше так не делать, а просто кривые ссылки считать кривыми.

Попробуй напиши
ngx.eof()
после ответа клиенту.

Что то вроде

ngx.say("привет")
ngx.eof() // тут клиент отключится
mysql:new() // всякая хрень дальше

error_page 404 /404.html;