ngx_pagespeed модуль полезный, но со своими "завихами". Можем получить "HTTP 404 Not found" при попытке открыть в браузере оригинальный файл изображения jpg/jpeg/png/gif в имени которого после расширения имеется суфикс ".pagespeed.", например "origin_file_name.jpg.pagespeed.ce.LJC2ixTs0v.jpg".
Оригинальные файлы с суфиксами ".pagespeed." - это файлы уже когда-то оптимизированные модулем ngx_pagespeed и загруженные с сервера на котором данный модуль установлен.
Когда такой, уже некогда оптимизированный файл с суфиксом ".pagespeed." загружается на другой сайт, где также установлен ngx_pagespeed, то при последующей попытке открыть данный файл, ngx_pagespeed видя суфикс ".pagespeed." в имени файла думает, что это уже оптимизированный файл и его нужно искать в своём кэше по адресу: pagespeed FileCachePath "/path/to/cache/dir/";
Соответственно, ненайдя его в своэм кэше ngx_pagespeed на пару с сервером выдают ошибку "HTTP 404 Not found", а в лог-файл ошибок заносится запись:
2019/11/27 22:46:10 [warn] 26722#0: [ngx_pagespeed 1.13.35.2-0] origin_file_name.jpg:0:Resource based on https://www.example.com/images/origin_file_name.jpg but cannot access the original
Теоретически, ненайдя "origin_file_name.jpg" в своём кэше модулю бы вместо выдачи ошибки "HTTP 404 Not found" стоило проверить его наличие с изначально запрошенным адресом и именем "https://www.example.com/images/origin_file_name.jpg.pagespeed.ce.LJC2ixTs0v.jpg", но увы.
Данная проблема упоминалась в аналах:
PageSpeed 404s origin files with .pagespeed. in them. · Issue #1013 · apache/incubator-pagespeed-mod · GitHub
https://github.com/apache/incubator-pagespeed-mod/issues/1013404 error on pagespeed optimized ressources · Issue #1279 · apache/incubator-pagespeed-ngx · GitHub
https://github.com/apache/incubator-pagespeed-ngx/issues/1279
Всё сходилось к настройкам типа:
pagespeed Disallow "*";pagespeed Disallow "*.pagespeed.*";pagespeed Disallow "*pagespeed*";pagespeed CombineAcrossPaths off;
Которые никак не решали проблему с 404, правда в конце темы "PageSpeed 404s origin files with .pagespeed. in them. · Issue #1013 ·" был сказ о том, что проблема в правиле mod_rewrite, о чём также упоминалось в "Frequently Asked Questions" на сайте проекта:
Frequently Asked Questions
https://www.modpagespeed.com/doc/faq#mod_rewriteI am getting 404s for rewritten resources (like example.png.pagespeed.ic.LxXAhtOwRv.png) or for the mod_pagespeed_admin console
The most common reason that the rewritten resources 404 is because of mod_rewrite RewriteCond rules. For example:
RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule ^ /404 [L,R=301]This rule causes 404 for all requests which don't exist on the filesystem, including mod_pagespeed rewritten resources and the mod_pagespeed admin console.
In order to fix this you must add an exception for mod_pagespeed URLs:
RewriteCond %{REQUEST_URI} !pagespeedThis will allow rewritten resources, the admin console and static resources necessary for some filters.
Однако, там "I am getting 404s for rewritten resources" - 404 для уже оптимизированных ресурсов и проблема с наличием некой конструкции RewriteCond. В нашем же случае 404 мы получаем не для оптимизированных ресурсов, а для любых файлов изображения в именах которых присутствует суфикс ".pagespeed.", и упомянутой конструкции RewriteCond в конфигурации нашего сервера/сайта не существует, да и модуль то у нас не для Apahe2, а для Nginx.
"Статика" не требующая дополнительной обработки/PHP/CGI/etc выдаётся напрямую из соответствующего "location". Размышляя про правила RewriteCond для Apahe2 пришли к такому решению, что с ошибками 404 в случае Nginx нам нужно создать похожие правила, которые бы дополнительно обрабатывали такие запросы, и в итоге получилось такое решение проблемы:
Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!
Обратили внимание, что в приведённой выше Nginx конфигурации в контексте "server" лог ошибок отключен "error_log /dev/null crit;" и включается только для отдельного "location" где требуется "error_log"? В противном случае в лог файл могут дублироваться записи 404, а также записи "[ngx_pagespeed ххх]...cannot access the original", даже если в конкретной "location" мы попробуем его отключить.
Вероятно таоке поведение error_log связано с особенностями наследования конфигурации верхнего уровня (top-level):
NGINX Docs | Configuring Logging
https://docs.nginx.com/nginx/admin-guide/monitoring/logging/The default setting of the error log works globally. To override it, place the error_log directive in the main (top-level) configuration context. Settings in the main context are always inherited by other configuration levels (http, server, location). The error_log directive can be also specified at the http, stream, server and location levels and overrides the setting inherited from the higher levels. In case of an error, the message is written to only one error log, the one closest to the level where the error has occurred. However, if several error_log directives are specified on the same level, the message are written to all specified logs.
Похожие случаи с "error_log":
- disable ngx_pagespeed info logs – Группы Google
https://groups.google.com/forum/#!topic/ngx-pagespeed-discuss/ohDvuKOZZck - NginX still generate error log from pagespeed · Issue #470 · apache/incubator-pagespeed-ngx · GitHub
https://github.com/apache/incubator-pagespeed-ngx/issues/470
