> Судя по приведённому 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.