On 09.04.2018 21:08, Maxim Dounin wrote:
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache exists: 0 e:1
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 cache file:
"/var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 add cleanup: 00005594C08CB288
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache fd: 52
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 read: 52, 00005594C08CB308,
475, 0
[...]
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record length: 74
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header:
"Content-Type: text/html; charset=UTF-8"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: "Status:
200"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header:
"Content-Length: 0"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 1
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header done
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache send:
/var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 HTTP/1.1 200
[...]
Судя по приведённому debug log'у, в кэше лежит валидный ответ
бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся
клиенту.
Очевидно, что ответ этот nginx не сам придумал, а получил от
бэкенда. Почему бэкенд прислал именно такой ответ - надо смотреть
в debug log'е в тот момент, когда это произошло.
С бэкендом все нормально. Это глюк на стороне nginx.
Такой глюк происходит в том случае, когда из интернета на сайт
отправляется запрос HEAD - есть очень много роботов, которые сначала
отправляют HEAD запрос, и потом только делают нормальный GET запрос.
Причина в том, что в документации для директивы fastcgi_cache_key
указано некорректное с точки зрения протокола HTTP значение
localhost:9000$request_uri - так оно нормально работать не будет.
Даже если добавить туда $scheme и $host, например, так:
fastcgi_cache_key "$scheme://$host$request_uri";
- этот глюк с пустыми ответами все равно останется.
Пока что существует только один workaround:
добавить $request_method в fastcgi_cache_key
Например, вот так:
fastcgi_cache_key "$request_method $scheme://$host$request_uri";
Подозреваю что сейчас в интернете есть очень много сайтов, которые
используют модуль fastcgi, на которых включено кеширование в nginx
и значение директивы fastcgi_cache_key скопировано из документации.
Идеальным вариантом решения проблемы было бы добавление директивы
fastcgi_cache_convert_head со значением "on" по умолчанию,
по аналогии с имеющейся директивой proxy_cache_convert_head.
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx-ru
