webmasterfsd

Thank you, you’ve understood the issue correctly.

I updated the hosts file as suggested, and it resolved the problem on my end. I’ll continue using this workaround and will wait for the official fix in the next release. In the meantime, could you please keep this ticket open so I can continue to track the progress?

Thanks again for your assistance.

Hello ,

Thank you for pointing me to crawler.cls.php line 945 and suggesting I log the $resolved value. What I’ve tried

1. Standard PHP error_log() error_log( '[LSCache Crawler] Domain resolved to: ' . $resolved );
2. Type-3 error_log() to a custom file error_log( '[LSCache Crawler] Domain resolved to: ' . $resolved . PHP_EOL, 3, WP_CONTENT_DIR . '/litespeed/debug/custom.log' );
3. $this->log() (plugin’s internal logger) $this->log( '[Helper] Domain resolved to: ' . $resolved );

Results

• public_html/error_log – No entries.
• wp-content/litespeed/debug/custom.log – File created but remains empty.
• /wp-content/litespeed/debug/crawler*.log (UI “Crawler Log”) – Still blank after several crawler runs.

Despite that, none of the three logging methods record anything.

Could you please take a look from your side? Here’s what I’m seeing on the latest LSCache:

• After a full Purge All and several manual crawler runs, the blue/green hit-miss counts stay exactly the same every time.
• No new log entries appear in any log (Crawler Log, debug/crawler*.log, or PHP error_log).
• It feels like the crawler is running but i think acutally isn’t running at all, or is stuck somewhere or not resolving the correct IP.

If you can trigger the crawler on your end and let me know what you observe (and any steps you take to check resolving IP), I’ll replicate them here to compare results.

Thanks in advance for your help!

Best regards,

Thank you for your assistance.

Hello,

I’ve done some debugging and identified that the plugin behaves differently when a CDN is active on the frontend. To test this, I temporarily pointed the site back to the origin server, and the plugin cralwer started working as expected.

It seems the plugin is not using the server/origin IP defined in the General Settings. Although the correct IP is already configured, the crawler appears to be hitting the CDN instead, which is likely causing the issue.

Is there a fix or recommended solution to ensure the plugin uses the origin IP as intended, even when a CDN is active?

Thank you.

If you refer to my initial message in this ticket, I clearly mentioned that I tested the issue by manually running the crawler twice. Later, I ran additional tests by manually triggering the crawler more than two times, but the issue still persists. I’ve confirmed this behavior across multiple sites. However, when I revert to the older plugin version (as noted in my first message), the issue no longer occurs — all pages are properly cached on the second run and appear under green status.

here is screenshot on latest plugin v7: https://prnt.sc/9qXPQWscrmLS

Yes, I’ve already cleared the blocklist before each crawler run.

I’ve tried it a couple of times and encountered the same issue across multiple sites—not just a single one.

However, there’s another site with the exact same settings where this issue doesn’t occur.

I didn’t encounter any issues after reverting to the older version.

I must say, something seems to have gone wrong with the recent updates.

Here is my Report number: YAIINGIN

Report date: 06/08/2021 15:01:57