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
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Ответить