> Судя по приведённому debug log'у, в кэше лежит валидный ответ > бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся > клиенту.
> Очевидно, что ответ этот nginx не сам придумал, а получил от > бэкенда. Почему бэкенд прислал именно такой ответ - надо смотреть > в debug log'е в тот момент, когда это произошло. Понемногу картина проясняется. Ответ действительно генерирует приложение, но это не основной бэкенд, а бэкенд для SSI-вставки баннеров. У меня были подозрения, что подзапрос на фоновое обновление кэша уходит куда-то не туда и они подтвердились. Добавил метку при генерации ответа и вижу её в файле кэша, когда вместо 404 начинает отдаваться 200. Отдача баннеров производится из отдельного internal-локейшна, который вызывается только при обработке SSI. На странице 404 есть SSI баннеров. Баннеры кэшируются отдельно, у них не только своя директория кэша, но и свой ключ: fastcgi_cache_path /var/www/site/cache/banners levels= keys_zone=banner:5m inactive=1m max_size=5m; … location /banner/ { internal; fastcgi_cache banner; fastcgi_cache_valid 200 24h; fastcgi_cache_key '$uri$is_args$args'; set $handler banner.html; set $querystring $args; fastcgi_param REQUEST_URI $uri$is_args$args; fastcgi_param SCRIPT_NAME $uri$is_args$args; fastcgi_param PATH_INFO $uri$is_args$args; include parser; fastcgi_pass fcgiwrap; } Могу лишь предположить, что подзапрос фонового обновления кэша наследует fastcgi_cache_path и fastcgi_cache_key от основного запроса, а значения, указанные в соответствующем локейшне, игнорируются, что приводит к перезаписи содержимого кэша. Памятуя о сохранении request_uri в подзапросах, специально использую в ключе кэша подзапроса $uri. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279363#msg-279363 _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru