-
Notifications
You must be signed in to change notification settings - Fork 361
1.13.35.2-stable suddenly stopped working #1742
Comments
Hi At a first glance I see this:
Is img.domain.com running pagespeed? If no, then you don´t need the Domain directive. For the MapProxyDomain: If the https://www.modpagespeed.com/doc/https_support#https_fetch with And I can´t see a |
Even though urls are rewritten and it seems pagespeed is attempting to serve webp I still get 404 though:
img.domain.com is pointing to another server, it does not run pagespeed indeed.
This is not correct, the https://img.domain.com/some-image.jpg will be rewritten into https://www.domain.com/img/xsome-image.jpg.SOMEHASH.jpg and if I understand correctly it's cached on the server where pagespeed is enabled (www.domain.com).
Please see the updated config at the end of the comment.
I've tried both www.domain.com and domain.com, but it doesn't seem to work.
|
Hi In other hand: |
I'm not 100% sure about uploads, as there is not too may resources loading from that dir and given its high traffic site I can only experiment early in the morning, but resources from other dirs are not processed, eg:
There is no img folder both root domain dir and webroot:
This can be added later. As I've mentioned everything worked very well for 2-3 years, even after OS migrations there was no issues whatsoever. From the previous post you can see that pagespeed actually rewrites the img.domain.com image into the www.domain.com/img/ image and its even trying to serve webp image, so I'm wondering if its possible to debug the part of pagespeed fetching the image from img.domain.com and if it's possible to inspect cached resource (download it) or at least get hash / size in bytes? |
Hi
This message comes when no You can take a look at If there is nothing in these places, some thing is blocking pagespeed fechting the resources from Can you curl a image from the server that host www.domain.com? Some like running
in the host that have |
It also downloads an image without an issue. I've looked up logs for img.domain.com, once i purge pagespeed cache i see Serf requests being made:
/dev/shm/ngx_pagespeed_cache directory contain much but /dev/shm/ngx_pagespeed_cache/v3 had domain entry : |
Hi In the log from img.domain.com I can see Try |
This did work to an extend, I could see that css/js files have pagespeed hash appended, eg.: The resources would return 200, but inspector would show net::ERR_CONTENT_DECODING_FAILED status and it wouldn't load. Quick google search lead me to this #1346, so I've added pagespeed HttpCacheCompressionLevel 0; and it solved that issue (not sure if this is the right solution?). Would a need for HttpCacheCompressionLevel indicate that LoadFromFile is not used/working? The only remaining issue is img.domain.com, those are still not loading returning 404. |
Hi For the img.domain.com issue my bet is pagespeed is requesting resources via http and store it in the http cache, client is requesting the resource via https and there is no https version in the pagespeed cache. Is So the question is why pagespeed is fechting http resources and not https? Where are the config directives, server block, location block.. ?
must be set at host or servers blocks not in location ones. What certificate is in use at img.domain.com, Is a selsigned certificate? is a valid one? |
Server block.
Let's encrypt. It is a valid one.
It also seems that pagespeed is attempting to fetch every single file with relative path (e.g. favicon.ico) over http not https. |
Hi |
Issues with pagespeed were put on hold for some time and I've just took another look at it. The issue still remains with img.domain.com. Since my last comment, I've moved img.domain.com to completely separate server (it was on the same server as www.domain.com before). Pagespeed is not setup on that server. www.domain.com the following configuration (recap):
Not sure of this of any help but this is typical with all img.domain.com files:
I understand that first log line says that pagespeed managed to download and compress the file, I can also see a file present in /dev/shm/ngx_pagespeed_cache/v3/domain.com/https,3A/,2Fwww.domain.com/img/c4cfe5b0-1373-4bbf-86d2-39921659dd9b/250x250:
The second log line is generated after subsequent page load, key observations:
It seems to me that the pagespeed downloads the file, creates webp but cached file is not loaded on subsequent requests. |
Hi A far time ago I have tried this, create the directory for the proxied assets and the directive are like:
Note the last /. But maybe the 404 comes because pagespeed search the assets in https cache and it is stored in http. And maybe you can try: pagespeed MapOriginDomain http://img.domain.com/ https://img.domain.com/ Maybe this config need pagespeed Domain http*://www.domain.com/ to set both http and https domains. |
I've tried that as well, no observable difference.
It's always with https://
With ?PageSpeedFilters=+debug I see the debug messages like this for all img.domain.com images: Uncacheable content, preventing rewriting of https://img.domain.com/0416425d-81f4-4f48-ab83-c3dc7a1a2e39/228x228/de65085msjpg.jpg Note: http traffic is always redirected:
|
Hi
Some header is preventing the resource to be cached. For example a header like What are the whole headers when you fecth the image from the nginx server? |
HTTP/1.1 200 OK |
Hi Well, these headers are ok for caching the resource, but pagespeed found some reason to don´t cache it. If you put pagespeed off and don´t rewrite img.domain.com to www.domain.com/img/ the image is loaded? Are here any CSP in www.domain.com? Have you tried this?:
This need http://img.domain.com be reachable. For me sound strange that the rewrited resource is stored in the http cache and not in the https one as you say here:
The uncacheable message comes from here In the pagespeed admin pages -> Message History there is any error related to these images? |
I've been running ngx_pagespeed 1.13.35.2-stable on Ubuntu 16.04 and now on Ubuntu 20.04 without any issues until this morning when I've noticed that every single image served from img.domain.com returns 404. Interesting bit there is that pagespeed replaced the image urls and trying to serve cached webp image, but cached image returns 404. CSS/JS optmizations stopped working too.
I've tried restarting nginx and purging the pagespeed cache through pagespeed_admin without a success.
I've enabled MessageBuffer but there is only info messages and it does not give any additional info why this might be happening. /var/log/pagespeed seems to be useless (statistics?) and I'm not aware of any additional logs for ngx_pagespeed.
I'm not sure if this in any way related, but dpkg log indicated that this morning there was some package upgrades, including ca-certificates:
ca-certificates (Unpacking ca-certificates (20210119~20.04.2) over (20210119~20.04.1) ...)
Here is the pagespeed configuration for a single site (there was no changes recently):
The text was updated successfully, but these errors were encountered: