Plugin Support
qtwrk
(@qtwrk)
please try this
go toolbox -> debug setting, set debug log to ON , debug level to advance , debug include URI add rest_route=/litespeed
then go to toolbox -> log view -> clean up existing log
now wait for that message shows up again , then go to log view , copy paste and share the log if any , over https://pastebin.ubuntu.com/
Hello qtwrk,
Thank you for your help. The disconnection issue happened again a short while ago.
Unfortunately, when I went to the “Log View” tab, the debug log box was completely empty. The “Copy Log” button did not copy anything, so I have no log to share at this time.
I have double-checked my settings in the “Debug Settings” tab, and everything is still configured exactly as you instructed (Debug Log ON, Level Advanced, URI includes rest_route=/litespeed). I have saved the settings again and cleared the log viewer.
I will now reconnect my site to QUIC.cloud and wait for the disconnection to happen again. I will share the log with you as soon as I can capture it.
Thank you for your patience.
Hello qtwrk,
I have a very important update.
When the disconnection happens, it’s not just logging me out of QUIC.cloud. It is also completely resetting all of my LiteSpeed Cache plugin settings to their default values.
For example, Guest Mode turns OFF, Browser Cache turns OFF, all my CSS/JS settings are disabled, and my Image Optimization progress is reset to 0%. I have screenshots to prove this.
This means every time it disconnects, I have to re-import my settings from a backup file to get my site working correctly again.
The debug log is still active, and I have re-imported my settings for now. I will wait for the disconnection and reset to happen again and will capture the log for you as soon as it does. This seems to be a more serious issue than just a simple disconnection.
Thank you.
Plugin Support
qtwrk
(@qtwrk)
em , okay , in cPanel -> raw access , from there you should be able to download the access log , see if you can find any rest_route URI access records
Hello qtwrk,
Thank you for the guidance. I have downloaded the raw access log for goodhopemotors.com (SSL) from my cPanel and searched for "rest_route".
I was able to find many entries. It seems the requests from the QUIC.cloud bot are reaching my server successfully. Here are some of the lines from the log:
65.108.104.232 - - [01/Sep/2025:10:17:39 -0400] "POST /?rest_route=/litespeed/v1/notify_ucss HTTP/1.1" 200 23 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; qcbot/1.0; +http://quic.cloud/bot.html) Chrome/112.0.0.0 Safari/537.36"
65.108.104.232 - - [01/Sep/2025:10:23:21 -0400] "POST /?rest_route=/litespeed/v1/notify_ucss HTTP/1.1" 200 23 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; qcbot/1.0; +http://quic.cloud/bot.html) Chrome/112.0.0.0 Safari/537.36"
65.108.104.232 - - [01/Sep/2025:10:31:04 -0400] "POST /?rest_route=/litespeed/v1/notify_ucss HTTP/1.1" 200 23 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; qcbot/1.0; +http://quic.cloud/bot.html) Chrome/112.0.0.0 Safari/537.36"
65.108.104.232 - - [01/Sep/2025:10:33:47 -0400] "POST /?rest_route=/litespeed/v1/notify_ucss HTTP/1.1" 200 23 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; qcbot/1.0; +http://quic.cloud/bot.html) Chrome/112.0.0.0 Safari/537.36"
65.108.104.232 - - [01/Sep/2025:10:35:10 -0400] "POST /?rest_route=/litespeed/v1/notify_ucss HTTP/1.1" 200 23 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; qcbot/1.0; +http://quic.cloud/bot.html) Chrome/112.0.0.0 Safari/537.36"
103.72.163.222 - - [01/Sep/2025:10:37:01 -0400] "POST /?rest_route=/litespeed/v1/notify_ucss HTTP/1.1" 200 23 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; qcbot/1.0; +http://quic.cloud/bot.html) Chrome/112.0.0.0 Safari/537.36"
65.108.104.232 - - [01/Sep/2025:13:18:14 -0400] "POST /?rest_route=/litespeed/v1/notify_ucss HTTP/1.1" 200 23 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; qcbot/1.0; +http://quic.cloud/bot.html) Chrome/112.0.0.0 Safari/537.36"
65.108.104.232 - - [01/Sep/2025:13:28:40 -0400] "POST /?rest_route=/litespeed/v1/notify_ucss HTTP/1.1" 200 23 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; qcbot/1.0; +http://quic.cloud/bot.html) Chrome/112.0.0.0 Safari/537.36"
65.108.104.232 - - [01/Sep/2025:13:57:16 -0400] "POST /?rest_route=/litespeed/v1/notify_ucss HTTP/1.1" 200 23 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; qcbot/1.0; +http://quic.cloud/bot.html) Chrome/112.0.0.0 Safari/537.36"
As you can see, they all have a "200" status code.
Please let me know what this indicates and what our next step should be. Thank you.
Plugin Support
qtwrk
(@qtwrk)
on these timestamp , you don’t see anything from plugin debug log ?
I would expect you see same request by time , on both access log and plugin log
and please provide the report number , let me double check your setting , just in case
you can get it in toolbox -> report -> click “send to LiteSpeed”
-
This reply was modified 9 months, 1 week ago by
qtwrk.
Hello qtwrk,
I have a critical update. The disconnection and settings reset issue has happened for the third time since I enabled debug logging.
Unfortunately, the result is the same as last time: **the debug log box in “Log View” is completely empty again**.
It seems that whatever is causing the settings to reset is also preventing the debug log from being written. The server’s access log shows successful connections from your bot, but the plugin’s own log remains empty.
This strongly suggests the issue might be happening at a level outside of the plugin’s direct control, possibly related to the server environment or a database issue.
Here is a fresh report number, generated immediately after this latest reset:
**Report Number: [DDJZTRQH]**
I have not yet reconnected the site or imported my settings, so the report reflects the “reset” state.
Given that the plugin’s debug log is not working, what would you suggest as the next diagnostic step?
Thank you.
Plugin Support
qtwrk
(@qtwrk)
please try follow this guide https://docs.litespeedtech.com/lscache/lscwp/troubleshoot/#database-corruption
this will delete our plugin’s settings in database wp_options table
then reconfigure the debug setting as requested (debug log to ON , debug level to Advance, debug include URI: rest_route=/litespeed
then open in browser like https://domain.com/?rest_route=/litespeed/xxx you will get a 404 request or something
check the log again , you should see the request you just made, to rest_route=/litespeed/xxx this should confirm the debug log working or not.
then note down the time , like right now it’s UTC 3rd, Step , 05:00 , you link to QC again
at this time forward , if disconnect happens again , search the access log between noted down till the moment you notice the disconnection , see what we get from there
Hello qtwrk,
Excellent news! I have followed all your instructions, and the test was completely successful.
- I deleted the ‘litespeed.%’ options from my
wpnk_options table in phpMyAdmin.
- I reconfigured the debug settings (Log ON, Level Advanced, URI includes
rest_route=/litespeed).
- I visited the test URL (
/?rest_route=/litespeed/xxx).
- I then checked the “Log View” tab, and this time, it is full of log data! The debug log is finally working correctly.
I am ready for the next step. What should I do now? Should I reconnect to QUIC.cloud and import my backed-up settings file?
Thank you so much for your expert guidance.
Plugin Support
qtwrk
(@qtwrk)
yes, please re-connect and import , and mark the time you connect , wait for disconnect happens again , check the log on both plugin side and access log , between the marked time and disconnect time , see if there is any rest api request and their logs
Hello qtwrk,
Thank you for the confirmation. I have successfully reconnected to QUIC.cloud and have now manually reconfigured all my settings.
I have noted down the current date and time: 03 September, 2025 at 15.27
I will now monitor the site. If the disconnection happens again, I will check both the plugin’s debug log and the server’s access log for the relevant period and report back.
Thank you.
Hello qtwrk,
This is an unbelievable update. The disconnection and settings reset issue has happened again.
However, even after we successfully reset the database options and confirmed that the debug log was working with a manual test, the debug log box in “Log View” is once again completely empty.
This confirms that whatever is causing the settings to reset is also preventing the debug log from being written or is deleting it entirely. The issue seems to be happening at a level that even the plugin’s debug function cannot capture.
I am completely at a loss for what could be causing this. The problem is clearly not with the plugin’s standard functionality but with some external factor on my hosting environment that is aggressively resetting the plugin’s data in the wp_options table.
Do you have any final ideas on what could be causing this from a server-side perspective? Could it be a specific cron job from the host, a security feature, or something similar?
Thank you for your extensive help so far.
Plugin Support
qtwrk
(@qtwrk)
wait a second , you mean the plugin’s setting got reset ? like all of them ?
or the setting is still there, but log got emptied ? because these are very different cases
Hello qtwrk,
Yes, that is exactly what I mean. All of the plugin’s settings get completely reset to their default values.
To be very clear, this is what happens every time:
- The connection to QUIC.cloud is lost, and the setup pop-up appears on the dashboard.
- All my previously configured settings are gone. For example:
- Guest Mode, which I had ON, gets turned OFF.
- Browser Cache, which I had ON, gets turned OFF.
- All my CSS and JS optimization settings (Minify, Combine, etc.) are turned OFF.
- My Image Optimization progress is reset to 0%.
- And on top of all that, the debug log box is also found empty.
So, it is definitely Case #1: the entire plugin’s settings are being wiped and reset. I have to re-import my settings from a backup file every time to fix it.
I hope this clarification helps.
@faisalrony maybe because of settings being reset, the QUIC cloud connection is reset.
Do you run a database optimization script? or plugin that makes a cleanup?
