Search results

How about creating a new context, e.g. with exp:^.*(css|js)$, so al the CSS and js files will not hit the specified PHP context? You might want to adjust the URI and location for your needs.

Happy to help.

You can set up a virtual host for your hostname, domain map the virtual host, and apply SSL certificate like other virtual hosts. Then go to LiteSpeed web admin > WebAdmin Settings > Listeners > SSL to use the valid key & cert.

It seems like a critical issue, but there hasn't been a new OLS package update for a while. Could you let us know if anything was done before the issue occurred? Maybe you can contact support@litespeedtech.com with this forum post link appended as well. Note: just in case, please try to...

To work around this, you could use a soft link to the folder. e.g. ln -s /home/domain.com/error.html/public_html /home/domain.com/public_html/error.html

May I know if the site has cache enabled? Or are you testing pure PHP performance? Maybe the network is the bottleneck, what's the test result so far?

I don't think it works.

Correct.

For the web server, not specifically for OpenLiteSpeed, you need to update the domain name from old-website.com to new-website.com, that's it. See https://docs.openlitespeed.org/config/#map-virtual-hosts for more details.

If you create a phpinfo page, does it return a 200 status code or 503?

It looks like the load is originating from the same site. Are there any unusual traffic patterns in the access log?

Thanks for the report. The user account was likely hacked, which caused it to start posting spam messages. I've removed all the content and banned the account.

It seems there's no LiteSpeed cache rule or plugins enabled on the site, may I know which CMS you are using? Feel free to check https://docs.litespeedtech.com/lscache/ for more details.

Glad to know you have fixed the PHP version issue.

It might be a good idea to reach out to aaPanel support, as they handle the integration and are familiar with the server settings and file/folder permissions.

So, the issue you mentioned occurred during the second build? I'm not sure of the cause, it could be an issue during the build somewhere. If it's still not working, you might want to share all the build logs, or just go with the docker image, at least you don't have to build it again.

Sure.

Some similar posts here, maybe you can give it a try.

What are the steps you have OLS installed on the arm server? Is there any error during the installation?

May I know if you use a valid cert on the listener or virtual host SSL level? OLS won't touch the certificate files, it seems the site is using OLS default self-signed certificate for some reason. I can't reproduce the issue locally. If you can, please submit the issue to...