Litespeed on Plesk – Installation and Configuration Guide

Guide on how to install LiteSpeed on your Plesk server
In this guide, we’ll explore both how to install LiteSpeed on Plesk and the installation of the LiteSpeed Plesk Extension on a Plesk server. This will be based on the assumption that you’re using a fully-functional Apache-Plesk setup. You can approach the installation of the LiteSpeed web server and the Plesk Extension in a number of ways, but we’ll focus on the extension first. We’ll cover how to install the LiteSpeed web server later on in the guide.

Requirements before installation

You’ll need these before you can proceed with the installation process:

  1. An operational Apache server on Plesk

  1. Your NGINX reverse proxy should be stopped, if you have one (we’ll get to this below)

  1. A PHP handler set to FastCGI — this enables the LiteSpeed web server to follow the handler settings

How to stop the Nginx Reverse Proxy Properly

With the latest version of Plesk, NGINX may be configured as a reverse proxy server positioned between Apache and the Internet. You need to stop the NGINX reverse proxy before proceeding with the LiteSpeed web server installation, so that Apache operates as the sole web server for handling live web traffic.

The LiteSpeed process will be unable to start as required if you fail to do this.

If you don’t stop the NGINX reverse proxy, you’ll see the following notification when you attempt to access the LiteSpeed extension:

“LiteSpeed is not running. Apache is running (PID = 23136)

“NGINX reverse proxy server is currently running and must be stopped. Please go to ‘Server Management > Tools & Settings > Services Management’ and stop NGINX.”

So, to stop the reverse proxy, you’ll have to start at the Plesk Admin Console and navigate to: Server Management > Tools and Settings > Server Management > Services Management > Reverse Proxy Server (NGINX) , then hit the Stop button.

Once NGINX has come to a stop, verify that Apache has been configured to run on 80/443 like this:

netstat -lnp | grep httpd or netstat -lnp | grep apache

In the event that it hasn’t been configured that way, you’ll need to execute this command — plesk repair web — to rebuild the Apache configuration file.

Installing the LiteSpeed Plesk Extension

Follow these steps to install the LiteSpeed Plesk Extension:

  1. Download the most recent Plesk extension from the LiteSpeed site
  2. Open /usr/local/psa/admin/conf/panel.ini to be edited: if this doesn’t exist yet, create it now.
  3. Add the following content before saving the file:
    1. [ext-catalog]
    2. extensionUpload = true
  4. In Plesk: go to Extensions > My Extensions . Hit the Upload Extension button, then upload the package you downloaded in the first step.

How to Install LiteSpeed Web Server

You can use two methods for installing the LiteSpeed Web Server on Plesk: either via a script or the LiteSpeed Plesk Extension. Be aware, though, that the script won’t install the extension — it only installs LiteSpeed Web Server.

Installing LiteSpeed Web Server Via Script

Generally, this is the recommended technique if this is your first time installing LiteSpeed. We’ll explore all of the options presented throughout the installation stage in depth to help you complete it as efficiently as possible.

Installation LiteSpeed is simple. The first step is to sign into the SSH server.

Next, run this command (replace your _serial_nr with your License Key):

bash <( curl ) your_serial_nr

This script will detect your environment and ensure only the necessary dependencies and installation data is downloaded from the servers. The script will ask you to answer a number of questions, depending on the environment detected, before it starts to install LiteSpeed Web Server.

Helpful Hint:

If you want to take advantage of the script via a trial license, you’ll need to switch ‘your _serial_nr’ with the word TRIAL (written exactly like this, all in capitals) in this way:

bash <( curl ) TRIAL

When you do this, you’ll request a trial license for your server automatically before LiteSpeed Web Server is installed on it. If you notice an error when you’re utilizing the Trial License, please take a look at this helpful FAQ .

When the script starts, it will recognize the installation uses Plesk. It will then present you with the following prompts to request your input:

Could not find an lsws.options file

Could not find an lsws.options file. We will ask you for your preferred settings instead, but for automated bulk provisioning, you may want to exit and create an lsws.options file. Continue Installer(Y/N) ?

Don’t worry: this is to be expected, as this is the detailed method of installation. lsws.options is for fast/automatic installation.

Press Y then Enter to continue.


Enable PHP_SUEXEC. Run PHP processes as the account owner. Available values: 0 (off), 1 (on), and 2 (user home directory only).

This option will stipulate how your server runs a PHP process — a value of “2” is advised for shared hosting servers (this is the default).

Apache port offset

Apache port offset. Run LiteSpeed in parallel with Apache. For example, if set to 1000, Apache will listen on port 80, and LiteSpeed on 1080. If set to 0, Apache and LiteSpeed will use the same port, and LiteSpeed will not automatically start after installation.

This option defines which port the LiteSpeed Web Server will bind to when you’ve installed it. You’re recommended to set the port offset to something besides 0 (such as the default value of 1000), as this will enable LiteSpeed and Apache to run simultaneously while you’re testing if LiteSpeed works properly on your server.

You can switch the port offset to 0 once the installation has been completed and you feel sure that your sites run as they should with LiteSpeed.

If you decide to set port offset to 0, LiteSpeed will begin following the installation and Apache will then come to a stop. You’ll also need to enable the Switch to LiteSpeed Automatically option (we’ll cover further down).

Admin username

Admin username. For accessing LiteSpeed WebAdmin console.

This option defines what username you’ll utilize to gain entry to the LiteSpeed WebAdmin Console. This is valuable for getting into LiteSpeed Stats or taking control of LiteSpeed behavior following installation. It’s advised that you configure this to be fully secure. The default value is admin.

Admin email address

Admin email address. Receive important server notices, such as license expiration and server core dumps.

This option establishes the email address that you want to get warnings, errors, and notices from LiteSpeed Webserver. You’re recommended to choose an email address you monitor on a regular basis, to avoid missed updates. The default value is [email protected]

Switching PHP Handlers

Automatically switch PHP handlers for users and/or subscriptions inside of Plesk. Available values: 0 (No change), 1 (Switch just for users), 2 (Switch just for subscriptions), 3 (Switch for both users and subscriptions).

This option inquires whether you intend to switch PHP handlers for users and/or subscriptions within Plesk. The default value is 0.

Switching to LiteSpeed Web Server

Switch to LiteSpeed Web Server. Automatically switches at the end of the installation if the port offset is set to 0. Available values are 1 (enable) and 0 (disable).

This option defines if the installer should close Apache down automatically and switch to LiteSpeed Web Server after it’s been installed. You should set this to 1 if you configured Apache Port Offset to 0 earlier. The default value is 0

Quick/Automated Installation

This utilizes shortcuts to ensure LiteSpeed is installed and deployed on Plesk as quickly as it can be.

In the majority of cases, it’s sufficient to run the installer script manually. You can automate the process for bulk provisioning through the following steps: create a lsws.options file at the directory you run the script command (such as /root/) or upload to your business’s internal repo instead. This will enable the installer to pick up installation options right from the file, without requesting input from users.

So, a default lsws.options file will usually resemble the following:





admin_email="[email protected]"



admin_pass is a fresh option here, and is the password you’ll use to enter your LiteSpeed WebAdmin Console. Take care to set it as a secure password for internal usage only.

You can create lsws.options and keep it on your local network for bulk provisioning, at a URL like Then, run this command:

curl -o lsws.options && bash <( curl ) your_serial_no

Important note links to your personalized lsws.options file, which your servers should be able to access.

lsws.options is the lsws.options file’s location. It’s fine to leave it like this when the installer is being run from the directory that the lsws.options file is too.

your_serial_no is the LiteSpeed Web Server license key. If you want to request a Trial License, you can use TRIAL too, but if you encounter an error when utilizing the Trial license, check out the FAQ.

Install LiteSpeed Web Server from the LiteSpeed Plesk Extension

You’ll be able to access the LiteSpeed Plesk Extension via Server Management > Extensions > LiteSpeed Extension.

Click on Install LiteSpeed Web Server.

Once you’ve read the comprehensive License Agreement, tick the I agree box. You’ll also have to enter your license’s serial number or request a trial license instead.

Scroll down the page a little more and you’ll find Installation Options and WebAdmin Console Login .

For the Installation Options section, the default values should be fine, but it’s advised that you set a non-zero Port Offset when installing for the first time (such as 1000).

For shared hosting, **Enable PHP SuEXEC** is recommended and implemented by default. You’ll only need to input a password in the WebAdmin Console Login section, though you’re advised to utilize a different username than the default to maintain effective security.

When you feel ready to proceed, click on the Install button below the Web Admin Console Login section.

You’ll be presented with a message to confirm that LiteSpeed has been “installed successfully” . This will include details such as:

  • platform detected

  • latest stable version

  • download directory created

At the bottom of the page, hit Okay and start LiteSpeed Web Server by clicking on the Restart LiteSpeed button.

If this process completes successfully, you should see a message on your LiteSpeed Extension page: this will inform you that LiteSpeed and Apache are operating on separate ports. Apache will run on the regular port 80 and LiteSpeed on 1080 (assuming your port offset is 1000).

You don’t need to test LiteSpeed on an offset port for staging servers or test environments, and LiteSpeed is unable to be tested on an offset port for certain applications (e.g. Magento, WordPress). In this case, you can just “Switch to LiteSpeed” from the extension GUI or command line for testing (as so):

/usr/local/lsws/admin/misc/ lsws

Running Testing with a Port Offset

The major advantage of the port offset is that you’re able to run both LiteSpeed Web Server and Apache at the same time. So, you can test hosting your websites on LiteSpeed Web Server to ensure they work before you switch off Apache.

For example, we have set the port offset to 1000. Sites could be tested on ports 1080 and 1443 for HTTP and SSL requests (respectively).

When you feel satisfied that your websites run properly with Litespeed Web Server, you’ll be ready to switch to LiteSpeed Web Server as your primary server.

Switching to LiteSpeed

First, under the Switch between Apache and LiteSpeed heading, click on Switch to LiteSpeed to stop Apache and make LiteSpeed Web Server your main server ports: 80 and 443.

LiteSpeed will be running as your primary web server. You’ll be presented with a message stating that “LiteSpeed is running” and “Apache is not running”. It will also tell you that you “Switched to LiteSpeed successfully”.

Switch between LiteSpeed and Apache

You should switch between LiteSpeed and Apache via the LiteSpeed Extension.

Also, you can do this by running the switching script from this command line:

/usr/local/lsws/admin/misc/ apache

/usr/local/lsws/admin/misc/ lsws

LiteSpeed on Plesk: Configuration Process


Straight out of the box, LiteSpeed works with Plesk PHP. The only step you need to take is to set PHP handler to FastCGI, to prevent mismatched PHP settings .

By default, LiteSpeed will honor Plesk’s PHP settings with no need for further configuration, but extra handlers will be needed if CloudLinux PHP Selector is enabled and you would rather use that as your PHP manager instead. We’ll cover this in more detail further on in this guide.

Disabling PHP Override

With LiteSpeed Web Server, you can disable the PHP override in .htaccess.

php_value and php_flag may be utilized in Apache configuration, or .htaccess to override php.ini settings. But they’re only supported by Apache’s mod_php handler, which is deprecated in the majority of the control panel systems after being replaced by php-fpm, LSPHP or fastcgi.

This means Apache should return an error if you place php_value or php_flag in .htaccess. You can find details in Plesk’s documentation .

You may see one of these errors:

500 internal server error

503 Invalid command 'php_flag', perhaps misspelled or defined by a module not included in the server configuration.

The following error can be found in the domain error log in Domains > > Logs:

/var/www/vhosts/ Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration

/var/www/vhosts/ Invalid command 'php_flag', perhaps misspelled or defined by a module not included in the server configuration

/var/www/vhosts/ RewriteRule: bad flag delimiters

/var/www/vhosts/ Invalid command 'suPHP_ConfigPath', perhaps misspelled or defined by a module not included in the server configuration.

LiteSpeed Web Server utilizes LSPHP, supporting php_value and php_flag usage in .htaccess. LiteSpeed Web Server will not return a 500 error when you use these, as it tolerates these PHP overrides more than Apache does.

In certain situations, you may opt to disable such PHP overrides in .htaccess for LiteSpeed too. To achieve this, you can use a dedicated Apache directive DisablePhpOverride htaccess (which may be utilized at the server level httpd.conf.).

Let’s look at an example: on Plesk, make a file named DisablePhpOverrideLiteSpeed.conf in the following directory (depending on your system):



Debian Ubuntu:

This DisablePhpOverrideLiteSpeed.conf file should include this:

DisablePhpOverride htaccess

Customized Configuration

PHP is auto detected as of LiteSpeed Web Server v5.3. There’s no longer a need for manual PHP external app configuration, and the preferred PHP manager is Plesk.

But if you would prefer to have a customized configuration for a specific PHP version, you might be required to create and configure the external app manually. From LiteSpeed Web Server Admin Console, you can create lsphpXX (such as lsphp70, lsphp71, lsphp72) one at a time.

Just adjust the Name, Address and Command settings to align with the relevant PHP version. If you would prefer to use the command line rather than the GUI tool, though, you can edit the LiteSpeed Web Server configuration file instead. This is typically located at /usr/local/lsws/conf/httpd_config.xml. 

CloudLinux PHP Selector

When you enable CloudLinux PHP Selection alongside Plesk PHP settings, you may be uncertain which PHP Selector is actually in effect. LiteSpeed automatically honors Plesk’s PHP selection straight out of the box, with no additional configuration necessary. So, you’ll have to make a few adjustments if you would like to use CloudLinux PHP Selector:

  • Set up an extra handler for LiteSpeed: this will force Plesk PHP to point to CloudLinux for non alt-phpxx versions.

  • Select a non alt-php version in Plesk’s PHP settings.

Together, these actions will make the CloudLinux PHP Selector come into effect.

Configure Extra Handler

Go to LSWS Web Admin Console > Server > PHP > Add PHP Handlers and follow these instructions:

  • Handler ID: php

  • Command : /var/www/cgi-bin/cgi_wrapper/cloudlinux_wrapper

  • Handled Suffixes: php, php54, php55, php56, php70, php71, php72, php73, php74

These settings will cause those Plesk PHP versions listed to utilize the CloudLinux PHP selector.

You can edit LiteSpeed’s configuration directly if you would rather take this route:

vi /usr/local/lsws/conf/httpd_config.xml

Enter the following in ... tags:



    php, php54, php55, php56, php70, php71, php72, php73, php74

Select Plesk PHP

After the handler has been created, go to Plesk’s PHP settings and pick any PHP version (the PHP support dropdown) that’s not one of the alt-php versions (i.e. one of those listed in the PHP handler that has just been created). This will make sure that CloudLinux PHP selection is utilized.

LiteSpeed Cache for WordPress

The LiteSpeed Cache plugin can be mass installed in each WordPress installation on your server using the LiteSpeed Plesk Extension. Once you’ve installed the LiteSpeed Plesk Extension, you could see a No Cache Management data file found message.

Set Cache Root

Click Manage Cache Installations , and then Set Missing Cache Roots in the Cache Root Setup section.

Scan and Enable

Once you have set up the cache root successfully, navigate back to the extension main page. Then, click the Manage Cache Installations option again.

Next, you will need to scan for WordPress installations across the server and install LSCache for WordPress (LSCWP) on them. First, though, you’ll have to select the LSCache plugin version you want to install. Typically, it’s recommended that you pick the latest version.

This is a fairly simple process thanks to the user-friendly layout. Once you begin scanning, this could take some time based on the number of sites you have.

When the scan ends, you’ll get to manage those WordPress sites found. You can use the Discover New button in future: this will help to save time as only scans for sites that haven’t been discovered yet.

Now you’ll be able to activate the LiteSpeed Cache Plugin for WordPress individually or use bulk activation for a number of websites instead. You should notice a green light symbol in the Cache Status column when LSCWP has been activated successfully.

If you want to verify a site is cached, take a look at the x-litespeed-cache:hit response header, which indicates that the caching is running properly.


QUIC connections use UDP port 443. You need to make sure it’s not being blocked by your firewall.

HTTP/2 and HTTP/3 through Apache Config

You may enable and disable a number of protocols (such as HTTP/3 and HTTP/2) in httpd.conf, by utilizing the SpdyEnabled directive, as so:

    SpdyEnabled http3

Alternative parameters that are valid include:

  • spdy2

  • spdy3

  • http2

  • off

By default, all protocols are enabled, which means there’s no requirement for a SpdyEnabled directive if you want to use all SPDY, HTTP/2 and HTTP/3 protocols.

Helpful Hint

When using this directive to enable protocols, anything you don’t select will actually be disabled. So, for instance, SpdyEnabled http2 enables HTTP/2 while disabling SPDY and HTTP/3. Take care not to accidentally disable one or more protocols you need to use.


To strengthen Plesk’s security features, enable TLS 1.3 and disable weak cipher suites. TLS1.0, TLS1.1, TLS1.2 will be enabled by Plesk configuration by default, and this guide will demonstrate how to enable TLS 1.3.

This guide is created and tested on Plesk 17.8 as well as Centos 7.5. Configuration files must be in /etc/apache2/mods-available/ssl.conf for Debian/Ubuntu Plesk.

Remember: as with any changes to Apache config files, you’ll have to restart the server when making the below adjustments. Use the following command with restarts:

systemctl restart lsws

Enabling TLS1.3

Edit the file /etc/httpd/conf.d/ssl.conf.

Locate this line and comment out (using #):

SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2

SSLCipherSuite HIGH:!aNULL:!MD5

Replace this with the following:

SSLProtocol TLSv1.1 TLSv1.2 TLSv1.3

SSLCipherSuite HIGH:!aNULL:!MD5

This enables TLS1.1, TLS1.2 and TLS1.3.

Want to disable TLS1.1 too? Change the line to the following:

SSLProtocol TLSv1.2 TLSv1.3

Disabling Weak Cipher Suites (this is optional)

Plesk also includes a number of weak cipher suites by default, but you can disable them with:

SSLCipherSuite HIGH:!aNULL:!MD5

Then, replace it with the following:



Please be aware, though, this can lead to CPU load. Testing is performed through SSL Labs.

WebAdmin Console

The LiteSpeed WebAdmin Console utilizes port 7088 rather than 7080 for Plesk. Take a look at your firewall to determine if port 7088 is enabled, and then you will likely have access to WebAdmin via https://SERVER_IP:7088.

Plesk Login Page

It’s possible to set up a Plesk login page with no need for a URL port number — for instance, https://IP-or-domain:8430 may become

Make a vhost in Plesk then put this rewrite rule in its .htaccess:

RewriteRule ^(.*)$$1 [P,L]

This brings our insightful guide on how to install LiteSpeed on Plesk to a close. Thank you for reading — we hope it helps you get off to a great start!

Manage and Sign Documents on your Plesk Server with cloudplan

For secure content collaboration, cloudplan provides the software to build private clouds locally or globally. As a Plesk extension, cloudplan is integrated to allow users to host and share files directly on their server. 

Now, cloudplan has created a robust workflow and e-signature solution, and you can now use your Plesk server as private storage for documents. It focuses on the broader document management life cycle, integrating tools to collaborate on documents as well as build professional workflows for approvals, agreements and signing.

All documents that are stored on your Plesk server are available for search, analysis and further archiving. The software is designed for any size and type of business. 

Let’s take a look at the features of cloudplan:


Workflows can be created and associated with an existing document, an individual form that is filled in during a defined process, or a webform for mobile use. You can attach new documents or files or even replace documents or users while running the workflows. Define your process steps with just a few clicks in the cloudplan portal.

Cloudplan esigning Plesk


You can invite as many users as you want to sign documents electronically. The entire process is monitored automatically. Reminders are sent and at the end all users receive a log of every single step. Signing is possible on mobile and workplace devices. PDF, Office documents and web forms can be integrated.


Global Search

A powerful search engine is available to you with which you can search millions of your own documents for attributes in a split second. Regardless of which storage instance the files are on, every storage location, like your Plesk server, is included without you having to configure anything. 


Cloudplan Global Search Plesk

Workflow Design Without Coding

You can use the intuitive workflow designer to create templates for recurring tasks as well as team-wide sharing. It includes database fields that can be used for workflow automation and as tag sources for the global search.


Cloudplan esigning workflow Plesk

Common Use Cases


Order and approval processes, conclusion of contracts (rental, leasing, service, framework contracts) with electronic signature

Service / sales

Presentations, offers, drafting and processing contracts, tenders, visit reports, on-site documentation, maintenance protocols, repair reports, work slips, acceptance protocols, license agreements


Software contracts, access authorizations and access management, work orders


When Can I Use eSigning?

With cloudplan, eSigning can be used out-of-the-box without any further requirements. On Windows, MacOS, and Linux, you can immediately access the feature via your web browser, and cloudplan also has a mobile app for android and iOS. Additional collaboration features and storage options can be used once you’ve installed a local client. 


Looking for a secure file management platform? Browse the cloudplan options on Plesk here.


Litespeed vs NGINX

Comparing NGINX and LiteSpeed

In a series of benchmarking tests, LiteSpeed’s HTTP/3 implementation demonstrated higher performance than that of the hybrid NGINX/Quiche.

Overall, LiteSpeed managed to transfer resources faster, demonstrate stronger scaling, and utilized less CPU & memory in the process. LiteSpeed bettered NGINX in all of these metrics by a factor of two or above. While NGINX was unable to complete certain tests, it achieved just below TCP speed in others.

Below, we’ll delve deep into the setup process and the range of benchmarks used.

  1. LiteSpeed vs NGINX: Why it Matters
  2. What is Cloudlare’s Patch for Quiche?
  3. Benchmarking Setup
  4. NGINX vs LiteSpeed: Benchmark Testing
  5. LiteSpeed Found to be More Impressive than NGINX

LiteSpeed vs NGINX HTTP/3: Why it Matters

HTTP/3 is a new web protocol, succeeding Google QUIC and HTTP/2. With the IETF QUIC Working Group approaching a finalized version of the drafts, it’s clear that the nascent HTTP/3 implementations are becoming more mature and some are beginning to see production use.

LiteSpeed became the first to ship HTTP/3 support in LiteSpeed Web Server, and QUIC has been supported since 2017. Improvements have been made here and there. It’s on this foundation that the support for HTTP/3 stands.

Recently, Cloudflare launched a special HTTP/3 NGINX patch and encouraged users to start experimenting.

What is Cloudlare’s Patch for Quiche?

Quiche is Cloudflare’s HTTP/3 and QUIC library, written in Rust (this language is high level and new). Said library provides a C API, which is how NGINX uses it.

Benchmarking Setup

The Platform

Both the servers and load tool run on the same VM. This is an Ubuntu-14 machine featuring a 20 core Intel Xeon E7-4870 and 32GB RAM. Netem was used to modify the bandwidth and RTT.

The Servers

We leveraged OpenLiteSpeed, an open-source version of the LiteSpeed Web Server (specifically, version 1.6.4.).

With regards to NGINX, we utilized 1.16.1 with Cloudflare’s Quiche patch.

OpenLiteSpeed and NGINX had been configured to utilize a single worker process, and NGINX’s maximum requests setting was boosted to 10,000. This enabled us to issue 1,000,000 requests with 100 connections.

# OpenLiteSpeed
httpdWorkers 1
# nginx
worker_processes 1;
http {
    server {
        access_log off;
        http3_max_requests 10000;

The Website

This comprised a simple collection of static files, including a 163 byte index file with files of varied sizes (1MB, 10MB, 100MB, 1GB).

The Load Tool

Load was generated with h2load with HTTP/3 support . This is easy to build when utilizing the Dockerfile supplied.

NGINX vs LiteSpeed: Benchmark Testing

We ran three LiteSpeed or NGINX tests and took the median value to get each number (the requests per second or resource fetch time).

LiteSpeed or NGINX: small page fetching

This testing involved fetching the 163 byte index page in numerous ways, through multiple network conditions. Key h2load options:
  • -n: Overall number of requests to be sent
  • -c: Amount of connections
  • -m: Amount of concurrent requests for each connection
  • -t: Amount of of h2load threads
-n 10000 -c 100
LiteSpeed NGINX
100 mbps, 100 ms RTT 925 reqs/sec 880 reqs/sec
100 mbps, 20 ms RTT 3910 reqs/sec 2900 reqs/sec
100 mbps, 10 ms RTT 6400 reqs/sec 4150 reqs/sec
-n 100000 -c 100 -t 10 Every connection will send 1000 requests now, with this being a longer run.
LiteSpeed NGINX
100 mbps, 100 ms RTT 995 reqs/sec 975 reqs/sec
100 mbps, 20 ms RTT 4675 reqs/sec 4510 reqs/sec
100 mbps, 10 ms RTT 8410 reqs/sec 7100 reqs/sec
At 100ms, LiteSpeed is quite a bit faster. But its speed increases substantially at 20ms and 10ms RTT. -n 100000 -c 100 -m 10 -t 10
LiteSpeed NGINX
100 mbps, 100 ms RTT 9100 reqs/sec 7380 reqs/sec
100 mbps, 20 ms RTT 24550 reqs/sec 5790 reqs/sec *
100 mbps, 10 ms RTT 25120 reqs/sec 6730 reqs/sec *
* High variance It was fascinating to find in the initial test that NGINX used 100 percent CPU, when OpenLiteSpeed utilized around 45 percent CPU only. This is why NGINX’s numbers tend to not improve despite the RTT dropping. Still, OpenLiteSpeed doesn’t utilize 100 percent CPU even with 20 and 10ms RTTs. -n 1000000 -c 100 -m 10 -t 10 We had to set the NGINX http3_max_requests parameter to 10000 (from the 1000 default value) to make sure it could issue in excess of 1000 requests for each connection.
LiteSpeed NGINX
200 mbps, 10 ms RTT 29140 reqs/sec 7120 reqs/sec *
* High variance At this point, LiteSpeed was using 100 percent CPU. NGINX allocated in excess of 1GB of memory during this test, while LiteSpeed remained below 28MB. So, that equates to greater than four times the performance for approximately 1/37th of the price.

Single file fetching

In this situation, we fetched a single file using alternative network conditions and measured the length of time required to download it. 10MB
LiteSpeed NGINX
10 mbps, 100 ms RTT 9.6 sec 10.9 sec
10 mbps, 20 ms RTT 9.6 sec 10.5 sec
10 mbps, 10 ms RTT 9.4 sec 10.8 sec
It’s clear that NGINX is a little slower here. It also utilizes three to four times more CPU than LiteSpeed did in the above tests. 100MB
LiteSpeed NGINX
100 mbps, 100 ms RTT 11.9 sec 39 sec *
100 mbps, 20 ms RTT 9.2 sec 38 sec *
100 mbps, 10 ms RTT 8.9 sec 29 sec
*High variance Across all three of the NGINX vs LiteSpeed benchmarks, NGINX utilized 100 percent CPU. It’s highly likely this is the cause of its weaker performance. 1GB We attempted to download a 1GB file with NGINX at 1gbps. However, we became tired of waiting for the download to complete. We believe the contrast in LiteSpeed and NGINX’s respective performance was pronounced at this speed.

NGINX vs LiteSpeed: Shallow Queue

NGINX has struggled with high bandwidth, so we decided to see how it would fare with low bandwidth instead. We used a shallow queue with netem’s limit parameter and set it to seven. Single 10MB file fetching
limit LiteSpeed NGINX
5 mbps, 20 ms RTT 1000 * 19.5 sec 23.1 sec
5 mbps, 20 ms RTT 7 29.5 sec 47.9 sec
*netem default We found LiteSpeed’s performance decreased by around 50 percent when we introduced a shallow queue on path. However, NGINX’s performance was degraded by more than 100 percent. So, LiteSpeed was found to be substantially faster than NGINX in both situations.

Conclusion – LiteSpeed Found to be More Impressive than NGINX

In all, we used numerous LiteSpeed vs NGINX benchmarking tests, and LiteSpeed performed to a higher standard than NGINX.

Files were transferred faster and less CPU & memory were used. NGINX never reached TCP level throughput when at a low bandwidth, and its throughput was a fraction of LiteSpeed’s at a high bandwidth.

NGINX’s HTTP/3 is unprepared for production use, as it provides weak performance and consumes more memory and CPU.

We’re not surprised by this result, frankly. QUIC and HTTP/3 are complicated protocols, and new implementations will find it difficult to match LiteSpeed’s performance.

NGINX is likely to show improvement in years to come, and we’ll be interested in running further benchmark tests when that time comes. But LiteSpeed HTTP/3 can’t be beaten in the meantime.

NGINX Configuration Guide

NGINX configuration guide

NGINX is a web server designed for use cases involving high volumes of traffic. It’s a popular, lightweight, high-performance solution.

One of its many impressive features is that it can serve static content (media files, HTML) efficiently. NGINX utilizes an asynchronous event-driven model, delivering reliable performance under significant loads.

This web server hands dynamic content off to FastCGI, CGI, or alternative servers (including Apache), before it’s sent back to NGINX for delivery to clients.

In this guide on how to configure NGINX, we’ll explore the essentials of NGINX to help you understand how it works and what benefits it offers.

NGINX Configuration: Understanding Directives

Every NGINX configuration file will be found in the /etc/nginx/ directory, with the main configuration file located in /etc/nginx/nginx.conf .

NGINX configuration options are known as “directives”: these are arranged into groups, known interchangeably as blocks or contexts .

When a # appears before a line, these are comments and NGINX won’t interpret them. Lines that contain directives should end with a semicolon (;). If not, NGINX will be unable to load the configuration properly and report an error.

Below, we’ve included a shortened copy of the /etc/nginx/nginx.conf file included with installations from NGINX repositories. This file begins with four directives:

  • user

  • worker_processes

  • error_log

  • pid

These exist outside any particular context or block, and are said to be within the main context.

Additional directives are found within the events and http blocks, and these also exist within the main context.

File: /etc/nginx/nginx.conf

user nginx;

worker_processes 1;

error_log /var/log/nginx/error.log warn;

pid /var/run/;

events {

. . .


http {

. . .


What is the Http Block?

The http block includes directives for web traffic handling, which are generally known as universal . That’s because they get passed on to each website configuration served by NGINX.

File: /etc/nginx/nginx.conf

http {

include /etc/nginx/mime.types;

default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

sendfile on;

#tcp_nopush on;

keepalive_timeout 65;

#gzip on;

include /etc/nginx/conf.d/*.conf;


What are Server Blocks?

The http block shown above features an include directive. This informs NGINX where website configuration files can be found.

  • When installing from NGINX’s official repository, the line will read include /etc/nginx/conf.d/*.conf; just as you can see in the http block placed above. Every website hosted with NGINX should feature a unique configuration file in /etc/nginx/conf.d/, and the name will be formatted as sites that have been disabled — not served by NGINX — should be titled

  • When installing NGINX from the Ubuntu or Debian repositories, the line will read: include /etc/nginx/sites-enabled/*;. The ../sites-enabled/ folder will include symlinks to the site configuration files located within /etc/nginx/sites-available/. You can disable sites within sites-available if you take out the symlink to sites-enabled.

  • According to the installation source, an illustrative configuration file can be found at /etc/nginx/conf.d/default.conf or etc/nginx/sites-enabled/default.

No matter the installation source, though, server configuration files feature one or more server blocks for a site. As an example, let’s look at the below:

File: /etc/nginx/conf.d/

server {

listen 80 default_server;

listen [::]:80 default_server;


root /var/www/;

index index.html;

try_files $uri /index.html;


What are Listening Ports?

The listen directive informs NGINX of the hostname/IP and TCP port, so it recognizes where it must listen for HTTP connections.

The argument default_server means that this virtual host will be answering requests on port 80 which don’t match the listen statement of a separate virtual host. When it comes to the second statement, this will listen over IPv6 and demonstrate similar behavior.

What is Name-based Virtual Hosting?

The server_name directive enables a number of domains to be served from just one IP address, and the server will determine which domain it will serve according to the request header received.

Generally, you should create one file for each site or domain you wish to host on your server. Let’s delve into some examples:

  1. Process requests for and

  2. The server_name directive can utilize wildcards. * and tell the server to process requests for all subdomains:

File: /etc/nginx/conf.d/

server_name *;


  1. Process requests for all domain names starting with example.:

File: /etc/nginx/conf.d/

server_name example.*;

With NGINX, you can define server names that are invalid domain names: it utilizes the name from the HTTP header to answer requests regardless of whether the domain name is valid or invalid.

You may find non-domain hostnames helpful if your server is on a LAN or you know all the clients likely to make requests on the server. This encompasses front-end proxy servers with /etc/hosts entries set up for the IP address NGINX is listening on.

What are Location Blocks?

NGINX’s location setting helps you set up the way in which NGINX responds to requests for resources inside the server. As the server_name directive informs NGINX how it should process requests for the domain, location directives apply to requests for certain folders and files (e.g. .

Let’s consider a few examples:

File: /etc/nginx/sites-available/

location / { }

location /images/ { }

location /blog/ { }

location /planet/ { }

location /planet/blog/ { }

These locations are literal string matches and match any part of an HTTP request following the host segment:


Returns: Let’s assume there’s a server_name entry for In this case, the location / directive determines what occurs with this request.

With NGINX, requests are always fulfilled with the most specific match possible:

Request: or

Returns: This will be fulfilled by the location /planet/blog directive as it’s more specific, despite location /planet being a match too.

File: /etc/nginx/sites-available/

location ~ IndexPage\.php$ { }

location ~ ^/BlogPlanet(/|/index\.php)$ { }

When location directives are followed by a ~ (tilde), NGINX will perform a regular expression match, which is always case-sensitive.

For example, IndexPage.php would be a match with the first of the above examples, while indexpage.php wouldn’t.

In the second example, the regular expression ^/BlogPlanet(/|/index\.php)$ { } would match requests for /BlogPlanet/ and /BlogPlanet/index.php but not /BlogPlanet, /blogplanet/, or /blogplanet/index.php. NGINX utilizes Perl Compatible Regular Expressions (PCRE).

What if you prefer matches to be case-insensitive? Well, you should use a tilde followed closely by an asterisk: ~*. You can see the above examples define that NGINX should process requests ending in a certain file extension: the first example determines that files ending in .pl, PL, .cgi, .perl, .Perl, .prl, and .PrL (as well as others) will all be a match for the request.

File: /etc/nginx/sites-available/

location ^~ /images/IndexPage/ { }

location ^~ /blog/BlogPlanet/ { }

When you add a caret and a tilde (^~) to location directives, you’re informing NGINX that, should it match a particular string, it should stop searching for more specific matches and utilize these directives here instead.

Beyond this, these directives function as the literal string matches do in the first group. Even if a more specific match comes along at a later point, the settings will be utilized if a request is a match for one of these directives.

Now, let’s look at additional details on location directive processing.

File: /etc/nginx/sites-available/

location = / { }

Finally, adding an equals symbol to the location setting forces an exact match with the requested path and ends searching for matches that are more specific.

So, for example, the last example will be a match for only, as opposed to If you use exact matches, you can enhance the speed of request times moderately. This can prove beneficial if certain requests are especially popular.

The processing of directives will follow this sequence flow:

  1. Exact string matches will be processed first: NGINX stops searching if a match is located and will fulfill the request.
  2. Any remaining literal string directives will be processed next. NGINX will stop and fulfill a request if it finds a match using the ^~ argument. If not, NGINX will continue processing of location directives.
  3. Each location directive with a regular expression (~ and ~*) will get processed next. If a regular expression is a match for the request, NGINX will end its search and fulfill the request.
  4. Finally, if there are no matching regular expressions, that literal string match which is most specific will be used.

Be sure that every file and folder found under a domain is a match for one or more location directives.

Nested location blocks are not recommended and not supported.

How to Use Location Root and Index

The location setting is another variable with its own arguments block.

When NGINX has identified the location directive that is the best match for a specific request, its response will be based on the associated location directive block’s contents. So, for instance:

File: /etc/nginx/sites-available/

location / {

root html;

index index.html index.htm;


We can see, in this example, that the document root is based in the html/ directory. Under the NGINX default installation prefix, the location’s full path is /etc/nginx/html/.


Returns: NGINX will try to serve the file found at /etc/nginx/html/blog/includes/style.css

Please note:

Absolute paths for the root directive can be used if you wish. The index variable informs NGINX which file it should serve when or if none are specified.

So, for instance:


Returns: NGINX will try to serve the file found at /etc/nginx/html/index.html.

When a number of files are specified for the index directive, the list will be processed in order and NGINX will fulfill the request with the first file found to exist. If index.html can’t be located in the relevant directory, index.htm will be utilized instead. A 404 message will be delivered in the event that neither exists at all.

Let’s consider a more complicated example that showcases a number of location directives for a server responding to the example domain:

File: /etc/nginx/sites-available/ location directive

location / {

root /srv/www/;

index index.html index.htm;


location ~ \.pl$ {

gzip off;

include /etc/nginx/fastcgi_params;

fastcgi_pass unix:/var/run/fcgiwrap.socket;


fastcgi_param SCRIPT_FILENAME /srv/www/$fastcgi_script_name;


Here, we can see that the second location block handles all requests for resources ending in a .pl extension, and it specifies a fastcgi handler for them. NGINX will use the first location directive otherwise.

Resources are found on the file system at /srv/www/ When no exact file names are defined in the request, NGINX will search for the index.html or index.htm file and provide it. A 404 error message will be returned if zero index files are located.

Let’s consider what takes place during a number of example requests:


Returns: /srv/www/ if this exists. Otherwise, it will serve /srv/www/ And if both of these don’t exist, a 404 error will be provided.


Returns: /srv/www/ if this exists. If the file can’t be found because it doesn’t exist, a /srv/www/ will be served. If neither exists, NGINX will return a 404 error.


Returns: NGINX will take advantage of the FastCGI handler to execute the file found at /srv/www/ and return the relevant result.


Returns: NGINX will utilize the FastCGI handler to execute the file found at /srv/www/ and return the relevant result.

This ends our guide on how to configure NGINX. We hope it helps you get started and set up in next to no time!

Best Cloud Software 2021: Plesk Selected in the Top 50

G2 aware cloud software 2021 - Plesk

With innovation in web management, cloud services and eCommerce at an all-time high, it’s time to take a look at the global software front-runners. 

Over at G2 – the trusted software aggregator and review platform – users have voted on thousands of Saas, Iaas and Paas providers to unveil the best software of 2021. 

So what are the results? We are pleased to announce that here at Plesk, we have been awarded a place on G2’s Best Software list for 2021!

G2 cloud software award 2021 - Plesk

Featuring in the category of Best IT Cloud Management for 2021, the Plesk software ranked 46th in the worldwide tally. The Plesk Control Panel for easy cloud management (and more) has proved to be a winning WebOps platform. 

What makes it so great? We focus on supporting agencies, service providers and SMBs to make sure that: 

🚀 You can host in the cloud of your own choice

🚀 Servers take care of themselves like clockwork

🚀 You can charge for managed services but automate the rest 

🚀 Security and performance are built in by default 

And 2021 is just the year to be celebrating the innovative Plesk software, with brand new features aimed at online store builders and hyperscalers being released over the next few months.

You, the user, are our top priority, and your feedback helps us innovate year after year. We look forward to your votes in future, with your continued support and collaboration! So let us know your experience on our G2 profile.

Are you a web admin facing the task of scaling and running one or many websites? Then the G2 community agrees: Plesk is the place to be.

Wordfence vs Sucuri – WordPress Security Plugins Comparison

Wordfence vs Sucuri comparison - Plesk

Sucuri vs Wordfence – which plugin ensures full WordPress security? This is a question that lots of WordPress website owners find themselves pondering. In these days of state-sponsored attacks, organized crime gangs, and bedroom hacktivists, getting watertight cybersecurity for your WordPress website has never been more important. 

New and more sophisticated hacks and exploits happen every single day, around-the-clock, and after the Solar Winds breach came to light it’s apparent that even governments and multinationals are not as safe as they thought. 

So for the humble WordPress site owner, it’s important to find the most effective means of keeping malign intruders out. Any weaknesses are almost certain to be exploited by criminals (eventually), so it’s essential that you settle on the most effective security plug-in you can get your hands on to thwart nefarious actors. 

Site owners often wonder about choosing between Wordfence or Sucuri, simply because this pair is among the most well-known and prominent of plugins for comprehensive WordPress website protection, and so it’s difficult for many site owners to differentiate between the different offerings and identify the superior example. 

Sucuri or Wordfence: what do you need to consider?

Sucuri vs Wordfence is a tricky question to answer because both have the capacity to keep your WordPress site safe from data breaches, bot-net infections, and other unwanted security risks. 

Another criterion must be that it’s easy to use, because the less time you waste on activities that don’t contribute to selling your digital wares, the better. You don’t want to waste time becoming a security expert just so that you can run a plug-in that keeps your website safe. If that’s what’s required then it’s probably not worth investing in.

Sucuri vs Wordfence: user-friendliness

You shouldn’t need to know how the internal combustion engine functions just to stop your car from being stolen, so you also shouldn’t need to become an expert in cybersecurity to keep your website safe with Wordfence or Sucuri


After installation, you’ll need to confirm that you accept the terms and conditions, and then you’ll be asked for the email address where you want your security updates to be sent. 

The setup wizard that follows will walk you through the basics of the application, including where to find notifications and the results of scans.

Wordfence opens your web app firewall in learning mode and performs a scan in the background. This may take a while if you have a large website but it will let you know as soon as it’s finished.

Click the dialogue box when it’s got to the end and you’ll see what the scan discovered along with suggestions for what to do with any positive hits. If you’re lucky, it won’t find any threats, but it still might recommend useful security-related suggestions, like that you update to the newest version of your chosen theme.

The standard way that the firewall runs is as a WordPress plugin, which isn’t the ideal way of doing things in this instance. Wordfence will let you configure it to work under extended mode for enhanced security, but this requires manual configuration. 

Unfortunately, first-time users of the Wordfence UI will probably find it as difficult to understand as we did. It’s true that it doesn’t ask you to do very much in its basic configuration, so that may not be a problem, but beginners wishing to explore the different possibilities it offers may feel that it’s an uphill struggle. 


There’s no such trouble with Sucuri’s GUI. It isn’t cluttered by unnecessary notifications and your scan results will appear in the plug-in panel. It’s also worth mentioning that its website application firewall (WAF) is based in the Cloud and as a remote resource it doesn’t require any horsepower from your own server that would slow it down.

To set up your hosting server behind the firewall you’ll need to give it your API key and configure the DNS settings for your domain name. Once you’ve installed it, you’re done. It’s a case of “set it and forget it” because updates and maintenance are all taken care of. Also, when Sucuri gives you security recommendations you only need to click once to apply them all. 

The UI is certainly a step up from Wordfence’s design, but some options are still buried in the guts of it and will require some digging.

One hurdle that less technical users may find difficult to overcome when they’re configuring a Sucuri firewall is how to update a domain name server with their domain registrar. It may be helpful in this case to ask the registrar for some help.

Sucuri vs Wordfence: Web Application Firewall (WAF) 

It’s possible to run a firewall in one of two ways. You can run it as an application on your own server or use a cloud-based WAF solution. 

WAFs are useful for blocking website threats, and we believe that cloud-based ones are the superior option for reasons of efficiency and reliability. They constantly keep an eye on incoming web traffic, flagging and blocking issues as they appear. In the case of Wordfence vs Sucuri, both have this capability.


Wordfence features a WAF that keeps an eye on malicious web traffic. The fact that it’s application-based, running as a WordPress plugin, is something of a disadvantage because it means that WordPress needs to load before it can detect and respond to malicious activity. 

You’ll need to configure Wordfence’s firewall manually in expansion mode so that it can monitor traffic before it has a chance to get to your WordPress installation. 

Wordfence’s endpoint firewall only filters bad traffic once it’s reached the hosting server, and once it does, all of its resources will be stretched as it responds to the attack.


Sucuri’s firewall is a remote cloud resource. That means that it can trip up malicious traffic before it gets anywhere near your hosting server. Sucuri also has content delivery network (CDN) servers distributed across various regions, so this should also help to increase the speed of the response.

To use a firewall, you’ll need to change the DNS settings of the domain name. This will route your traffic through Sucuri’s server. 

Sucuri doesn’t have a basic or extended mode. As soon as the installation has finished, Sucuri’s WAF starts protecting your site straightaway.

When you’re choosing between Wordfence or Sucuri you might want to bear in mind that Sucuri uses highly effective machine learning algorithms to cut down on false positives, and its DDoS defences automatically block fake traffic and nefarious bot requests without slowing down bona fide traffic sources.

Security Monitoring and Notifications 

Downtime is money, so a security early warning system is essential for any website owner. To get notifications you’ll need to check that you can pick up emails from your WordPress site using SMTP. Let’s look at how well Sucuri vs Wordfence keeps you informed about attacks.


Wordfence does a decent job of telling you about any problems with elicit intrusions and the like. They show up both in the Control Panel and the Wordfence menu in the WordPress administration sidebar, with different highlights indicating their respective significance. Selecting each one will pull up options for how you deal with them, but you can only see them after logging into the WordPress dashboard. 

If you’d like to be alerted about security issues via email, then you can fairly easily do that in the Email Alert Preferences section on the Wordfence options page. You can also further explore them on this page too. 


It can be very distracting to be constantly interrupted by security alerts, so if you want to tell Sucuri to only bother you with the more serious cases, that’s easily done, and you can also tell the software to send them to your control panel as well. 

Look towards the upper right-hand part of the screen to explore the status of the main WordPress file. This includes the audit log and site status. 

To access the alert management system open the Sucuri security settings page and then the Alerts tab and enter the email address where you want to receive your notifications. 

You can tune the type of event notifications you get and also put a ceiling on their numbers. Your WAF will also send important alerts to your email address. 

Sucuri or Wordfence – Scanning for malware

Both of our contenders feature malware detection. They can also look for files that have been changed and snippets of code that may be up to no good. Out of Wordfence vs Sucuri, which will do the better job here? 


Wordfence’s malware scanner can be tweaked to meet your particular hosting and security needs. Scanning has default limitations to conserve resources.

Wordfence generates your analysis schedule automatically, but you are able to change this. With scanning, you only have access to some options if you’ve opted for advanced versions of the plug-in. Wordfence’s scanner can also check your themes and plug-ins in line with the appropriate repository version. 


Sucuri’s site check API assists the Sucuri scanner in its hunt for unwelcome code. It’s quite clever in that it uses secure browsing APIs to ensure that your WordPress site hasn’t been blacklisted. 

Sucuri has an automated way of checking that your core WordPress files haven’t been tampered with, but you can change any of your settings by clicking on the scanner tab on the security settings page.

The scanner isn’t specific to WordPress, which you’d think would make it less adept at dealing with WordPress security issues but in fact, the result is that it can scan for any kind of intruder. Another aspect in its favour is that it’s relatively lightweight and doesn’t impinge too much on your server resources. 

Cleaning Up Your Website

Getting hacked is no fun, and the cleanup operation that comes after your WordPress site has hosted unwelcome intruders is even less cause for celebration. Trojans and viruses can burrow into files, drop unwanted links, and who knows what else.

Unless you’re an expert you may find it beyond your ability to track down and eliminate every bit of damage that’s been done. Luckily, Wordfence vs Sucuri can do it for you, but which one is going to do the better job?


You’ll need to buy your cleaning solution separately from your Wordfence subscription because it isn’t something that they include in their free or paid packages. Once you’ve signed up though, it’s a fairly straightforward process to get your site analyzed and cleansed of bots and Trojans. Not only that, you’ll also get a compressive rundown of what was cleaned and advice on how you can limit the likelihood of this kind of intrusion occurring again in the future.


If you pay for a Sucuri plan then site cleaning will be included. Just open a support ticket and the service will get underway attending to blacklist removal, remedying SEO spam, cleaning the site, and WAF to avoid such occurrences in the future. 

Sucuri is pretty good at cleaning up viruses and other dodgy intrusions, spammy code injections, and backdoor access files. 

The team assisting you with the clean-up will use FTP/SSH access login details to get in, and they’ll be careful to back-up every file that they interact with to ensure that nothing is damaged or lost. 

Sucuri vs Wordfence – Who Is The Winner?

Wordfence vs Sucuri is a matchup between two seasoned and respected security heavyweights, but in our opinion, it’s Sucuri that crosses the finish line in first place. Its use of WAF in the Cloud is a definite plus point. Wordfence is a competent performer, but its server-side scanner and firewall can’t match Sucuri’s for security. 

ModSecurity Comprehensive Guide

Modsecurity guide Plesk

What is ModSecurity? It’s a toolkit designed for real-time web application monitoring, logging, and access control. If it sounds complex, don’t worry. Anyone with experience of ModSecurity will attest that it’s a flexible toolkit, with no hard and fast rules telling you how you should use it.

Generally, ModSecurity leaves you free to decide how you take advantage of the features available instead. This flexibility is a core element of ModSecurity’s identity, and complements its open source structure. In fact, you can enjoy complete access to its source code, which empowers you to customize the tool to suit your unique needs.

And that’s crucial for anyone who wants tools to enable them to achieve what they have to with minimal restrictions. Which is probably all of us, right? ModSecurity is a versatile creation ideal for numerous usage scenarios. Let’s look at some of the most important:

Security monitoring and access control for applications

ModSecurity provides you with the ability to access and inspect streams of HTTP traffic, so you can monitor application security in real-time.

ModSecurity’s persistent storage mechanism allows you to keep track of system elements and conduct event correlation over time. You can also implement blocks efficiently, if you need to, thanks to ModSecurity’s full request and response buffering.

Comprehensive logging of HTTP traffic

When logging for security reasons, web servers are generally known to do less than first-timers may expect. Actually, they tend to log little fundamentally — so you may still struggle to get all that you’re looking for even with some adjustments here and there.

But with ModSecurity, you can log whatever you need to (such as raw transaction data for forensics) and you can determine:

  • what transactions will be logged
  • which aspects of transactions will be logged
  • which elements undergo sanitization

Hardening web applications

One of the most impressive ModSecurity uses is attack surface reduction: here, you can streamline HTTP features you’re happy to accept, such as content types, request methods, etc.

ModSecurity will help you to enforce numerous similar reductions, through additional Apache modules (collaboratively or directly). This is all under the umbrella of web application hardening.

A more personal solution

ModSecurity’s immense flexibility comes to the fore when you’re faced with an unexpected problem. This could be a security issue, for example, or something entirely different.

For instance, some users utilize it as an XML web service router by blending its capabilities to parse XML and apply XPath expressions with its proxy-request abilities. That might not occur to some users, which only shows the deep flexibility at ModSecurity’s core.

Basically, it may prove helpful to you in ways you can’t predict until you start to truly explore.

Continuous passive security assessments

Traditionally, security assessment can be viewed as an active event which is scheduled in advance, involving an independent team trying to undertake a fake attack. But a continuous passive security assessment is a variation on real-time monitoring that concentrates on system behavior rather than that of outside parties.

Continuous passive security assessments serve as a form of early warning system, capable of detecting security weaknesses before attackers can take advantage.

ModSecurity’s Core Principles

ModSecurity is based on four main principles:


If you’re concerned about letting tools make decisions for you, particularly when conducting transactions, ModSecurity makes things a little easier for you.

Why? Because it’ll never initiate changes to transaction data without you instructing to do so first.

Of course, it’ll provide you with a wealth of information. But it’ll leave choices up to you, for your complete peace of mind.


As we’ve already mentioned, ModSecurity is remarkably flexible. It’s actually fairly mind-blowing in its flexibility, to be frank.

That’s because it was created by a security expert who wanted to intercept and analyze HTTP traffic for safety purposes, yet realized that everyone had to do things their own way sometimes. Not everything has to work exactly the same for each user.

So, ModSecurity offers such high flexibility by providing a rule language that enables you to achieve what you need to, along with the freedom to apply rules only where necessary.

Quality, not quantity

During the lengthy development and fine-tuning of ModSecurity, the team explored numerous ideas for what it could actually do. They chose not to act on a lot of these, and put them aside for a later time.

They did so because they knew they had fewer resources than they needed  to make those ideas a reality effectively. So, they decided to limit the functionality available to users, but to focus on making the ideas they actually implemented the best they could be.


We all know the “perfect” tool doesn’t exist, and possibly never will. But a predictable tool could be the next best thing — and that’s where ModSecurity shines yet again.

When you’re equipped with the crucial facts, you’ll be able to understand ModSecurity’s weakest areas and find workarounds yourself.

However, let’s be clear: certain aspects of ModSecurity can be considered to be beyond the scope of these guiding principles.

For instance, ModSecurity is capable of adjusting the way in which Apache identifies itself to others, keeping the ModSecurity Apache process contained, and implementing an efficient plan to deal with that well-known XSS weakness in Adobe Reader.

It’s fair to say, though, that these features could be seen as a distraction from the core intent behind ModSecurity’s creation: to serve as a predictable tool for inspecting HTTP traffic efficiently.

Choices of Deployment

Two different deployment options are supported by ModSecurity: embedded deployment and reverse proxy deployment. But there’s no single correct or incorrect approach.

Just pick the most appropriate option based on your goals, requirements, and situation.

Let’s look at the benefits and drawbacks of each:

Embedded deployment

You can add ModSecurity to any version of Apache that’s compatible, as it’s an Apache module. At the present time, this means that a fairly recent version of Apache from the 2.0x branch should suffice (though a more up-to-date 2.2x is the typical recommendation).

Embedded deployment is terrific for users who have already established their architecture and are reluctant to make changes. It’s the only option if you want to keep a high number of web servers protected, even hundreds of them.

In a situation like this, though, it’s not practical to create a separate proxy-based security layer. Not only are new failure points not introduced with embedded deployment, but ModSecurity also offers seamless scaling to match the underlying infrastructure as it scales.

With embedded ModSecurity deployment, the primary obstacle is that server resources will be shared between ModSecurity and the web server.

Reverse proxy deployment

A reverse proxy is basically an HTTP router made to sit between a web server and its clients. Installing a Apache reverse proxy with ModSecurity added will bring you an effective network web application firewall. You can implement this to safeguard any amount of web servers all running on a shared network.

A lot of security professionals opt to initiate a separate security layer, as you’ll enjoy total isolation from those systems being protected.

In terms of performance, a standalone ModSecurity has resources dedicated to it, which enables you to get more out of it (such as utilizing rules that are more complex).

However, there’s a big potential disadvantage to consider with this deployment approach: the new point of failure. This will have to be addressed using a high-availability configuration of at least two reverse proxies.

Understanding ModSecurity and Plesk

ModSecurity is switched on by default starting from the early versions of Plesk Obsidian. In the same time, if you install Plesk using the images provided by your hoster, situation may be different.

To identify and defend web applications against attacks, ModSecurity will run checks on any request to the web server and all associated responses from the server against the set of rules.

Should checks succeed, the HTTP request will be sent to the website to retrieve the relevant content. But if checks fail instead, the appropriate predefined actions will be initiated.

Both Plesk for Windows and Linux offer support for ModSecurity. This functions as a web server (IIS or Apache) module.

How to turn on ModSecurity

To activate the web application firewall, follow these steps:

  • Navigate to Tools & Settings > Web Application Firewall (ModSecurity) (located within the Security group).

Don’t see this link? Don’t panic. Just install the ModSecurity component here: Tools & Settings > Updates > Add/Remove Components > Web hosting group.

  • Switch the web application firewall mode to either On or Detection only, to make sure all incoming HTTP requests and associated responses are checked against a rule set. When checks succeed, the HTTP request will be directed to the website to retrieve the necessary content. Alternatively, the event will be logged if checks fail. When in the Detection only mode, no additional actions will be undertaken. But in the On mode, HTTP responses will be given with a suitable error code.

Firewall modes for web applications can only be set on the server and domain levels. But the domain level mode can’t be higher than that of the mode set for the web server. So, if the firewall is running in Detection only mode on the server level, you’ll be unable to switch it to On for domains — just Off and Detection only modes will be displayed.

Choose the set of rules to be checked by the firewall engine for every HTTP request incoming, or feel free to upload your own set of rules instead. You can opt for one of these rule sets:

  • Atomic Basic ModSecurity: This is a free version of the Atomic ModSecurity rules for beginners, packaged with Plesk. It includes key security features and bug fixes are released monthly.
  • OWASP ModSecurity Core Rule Set (CRS): This gives you generic defense against unknown weaknesses that can be found in many web applications. It’s shipped free, but it’s recognized as being restrictive, so much so that additional tuning is necessary for production use. When you choose this set of rules, WordPress partly won’t work, nor will webmail and fire sharing. You can take advantage of the Comodo or Atomic rule sets instead.
  • Advanced ModSecurity Rules by Atomicorp: This is the most recent version of the rules, including all the performance improvements, bug fixes, and latest security features created by Atomicorp GotRoot every day. This commercial set of rules is supported completely and advised for production use. Plesk offers the Security Core Complete by Atomicorp extra feature, which enables you to implement this set of rules in Plesk. You can access this in multiple ways:
    • Purchase the Atomicorp Advanced ModSecurity Rules available in the Plesk Online Store
    • Have a Plesk license already? You can implement the extra feature through the Plesk Partner Central UI or the Partner API.
    • If you hold a Plesk license but you can’t access the Plesk Partner Central, please contact your provider.

    If you have an account on the Atomic website already, you’ll be able to simply enter your username and password to activate this set of rules.

    Linux users please be aware: If you choose the Atomic set of rules, follow these steps to make sure your ModSecurity performs as it should. Start by running the aum -u command on the server, and the Plesk modsecurity package will be switched for that from Atomic’s repository. Next, run these commands:

    • plesk sbin modsecurity_ctl --disable
    • plesk sbin modsecurity_ctl --enable
    • service httpd restart
  • Comodo ModSecurity Rule Set (Linux): This rules-based traffic control system is easy to use and can be tailored. It offers effective protection for your web applications and combats emerging hacking methods, through a rules database that receives regular updates. This set of rules is shipped for free, and you can activate it in Plesk by following these steps: register on the Comodo site, and once there, submit the username and password you use on this website. It’s easy.
  • Custom: You have the ability to upload custom web application firewall rule sets, such as an Atomic trial package or a Comodo free package. The following formats are supported: zip; tar.gz; tgz; tar.bz2; conf.
    • Pick the Update rule set checkbox and choose the relevant update period to update your selected set of rules automatically.
    • Choose a predefined range of parameters or specify your bespoke ModSecurity directives. The following preset parameter sets are available:
    • Fast: For when the HTTP request URI and parts of the headers undergo analysis. The least CPU is required for this mode.
    • Tradeoff: For when the HTTP request URI, headers, and request POST data will be subject to analysis. This is a solid balance between performance and quality.
    • Thorough: For when full HTTP request headers, request POST data, and HTTP response body content will be analyzed. This mode does consume the biggest range of CPU resources, though it can be an effective option for websites demanding special security protections (such as online stores facilitating card transactions).


Please note: Web application firewalls need a local DNS server with request caching enabled to provide the best performance. Without this, your websites will be more likely to load slowly when the firewall is in effect.

Finding Log Files on Linux Systems

ModSecurity utilizes two locations for logging on Linux systems:

  • Modsecurity audit log, which can be found in /var/log/modsec_audit.log. This is a highly-detailed option used by the entire Plesk server. An entry in the audit log file will be generated when ModSecurity recognizes that an event has taken place. You can view the ModSecurity audit log for yourself if you navigate to Tools & Settings > Web Application Firewall (ModSecurity) > click the Logs Archive link located within the ModSecurity audit log You can explore (and download) the log files and modification dates here.
  • The Apache error log for a domain, which can be found in /var/www/vhosts/DOMAIN.TLD/logs/error_log. This offers just brief details about site errors, but you can check out the error log for specific websites in the Customer Panel on the Websites & Domains > <domain_name> > Logs > choose Apache error and nginx error rather than All logs positioned on the right.

Finding Log Files on Windows Systems

ModSecurity audit logs are domain-specific on Windows. They’re found in %plesk_dir%\ModSecurity\vhosts\<domain’s GUID>\logs ( %plesk_dir% is Plesk’s default installation directory).

How to Switch Rules Off

Once you switch the web application firewall mode from Off or Detection Only to On, a website could start functioning in an unexpected way. You can check error codes (404s, 403s, 500s) in the site error log, and they’ll stop displaying once you switch the firewall mode back to Off or Detection Only.

In this event, check the ModSecurity audit log to identify the cause. You’ll be able to deactivate excessively-restrictive rules or tweak the website as required.

Follow these steps to determine why a site’s HTTP requests can’t be completed:

  • Check the audit log file for the site.

When using Plesk for Linux systems, you can take view the log through Plesk’s UI: navigate to Tools & Settings > Web Application Firewall (ModSecurity), then click on the ModSecurity Log File link to start downloading the relevant audit log. This will open in a new window in your browser.

  • To find events for a website (domain name) that may be responsible for issues, leverage the Search function (just hit Ctrl+F in the majority of browsers) — such as your_domain.tld. Your browser will then highlight certain entries, e.g. HOST: your_domain.tld. Look for a string such as –eece3116-B– in the three lines positioned above the highlighted entry. Those symbols between the hyphens show you the ID of the event which was triggered by the HTTP request.
  • Look deeper for additional entries with the identical event ID, specifically an entry featuring a H after the event ID. This carries the ID and description of the security rule that was activated while checking the relevant HTTP request. The security rule ID is an integer number positioned with quotation marks. It will begin with a 3 and will be displayed with the prefix ID in square brackets. This may look something like [id “340003”].
  • Locate a security rule ID in the event with the substring [id “3. You can use this ID when you turn rules off.

To deactivate a rule:

  • Make your way to Tools & Settings > Web Application Firewall (ModSecurity)
  • Once you’re in the Switch off security rules area, choose the security rule based on its ID (e.g. 340003), its tag (such as CVE-2013-4589), or a standard expression (e.g. XSS) and hit OK.

Final Notes for Nginx and ModSecurity

Let’s end by covering the issue of request checks with NGINX and ModSecurity, and how it connects to ModSecurity Apache issues.

ModSecurity is an Apache module on Linux systems, and it can run checks on HTTP requests reaching Apache only. But you can supplement Apache with an alternative web server, specifically nginx.

If you switch on the ‘Process PHP by NGINX option’ of the NGINX web server for dynamic website content (in a site’s Apache and NGINX settings), the web application firewall will be unable to check any HTTP requests as they’ll never actually reach Apache.

In the case of static content, HTTP requests won’t reach Apache if the ‘serve static files directly by NGINX option’ is switched on. That means ModSecurity won’t be able to check them.

We hope this detailed guide gave you a clear answer to “what is ModSecurity?” and helps you understand how it works. Because now it’s time to explore its possibilities for yourself!

ModSecurity offers a lot of advantages, so follow the tips and steps covered above to find out what ModSecurity can do for you.

Next Level Ops: Season 1 Recap

Hello Pleskians! As we approach our second season of Next Level Ops: The Official Plesk Podcast, we’re bringing you a Season 1 Recap while you get ready for more quality content. 

The podcast was created for you, Plesky reader (and listener), to give you industry insights and tips into the world of web hosting, development and management. 

So let your curiosity fly and learn through listening to these 10 curated episodes, hosted by podcast wiz Joe Casabona.

Episode 1 

20 Years of Evolution in Web Hosting

Kicking off our first ever episode of Next Level Ops, Joe meets Lukas Hertig, veteran Pleskian and fellow hosting enthusiast, to look back on 20 years of websites and hosting.

As they re-live the early years of websites and hosting (the ‘wild wild west’, in the words of Lukas), the interview unpacks the industry evolution from 2000 to today. From the first dynamic webs, to major disrupters like WordPress, the conversation ponders the growth of web hosting, and questions the future of hosting as-we-know-it. 

Looking for a trip down memory lane? Stream the episode here:

Lukas Hertig  

Lukas is the SVP Business Development & Strategic Alliances at Plesk.

Episode 2

Partnerships and High-Level Hosting Support

In this chapter, Joe interviews Pleskian Partner wizard, Francisco Pereira Carvalho, to delve into the global nature of today’s hosting market.

With more than 32 languages supported, serving 140 countries worldwide at Plesk, Francisco describes the essence of understanding what’s important for different cultures and regions. He explains that members of the Partner Program benefit from the intuitive and easy Plesk tool with the advantages of an international team.

Enticed yet? Stream the episode to find out more about the program here:

Francisco Pereira Carvalho  

Francisco is the Head of Sales at Plesk.

Episode 3

The Power of Extensions

If you’ve ever built a website, you’ve probably installed at least one or two extensions to enhance your web management. They provide extra tools and features to make your website run smoothly or to improve user experience.

In this episode of Next Level Ops, Joe talks to Jan Loeffler about Plesk’s extensions and kits that make users and admins love the Plesk experience. Some of the so-called ‘Lighthouse extensions’ – which are the most popular ones with users – are included as standard on Plesk. Others, like the SEO Toolkit, are available for download.

But what makes them so great? Let Jan and Joe tell you in Episode 3:

Jan Loeffler  

Jan is the Chief Technical Officer at Plesk.

Episode 4

How Not to Become a Security Engineer

For the fourth instalment of the series, Joe chats with security warlock Igor Antipkin about safeguarding websites. As he explains, the need to educate and be aware of potential threats is real. Web admins need to know the software they use, and share key insights with their own communities.

Alright, so now you’re getting worried. But have no fear, this episode explains how easy security can be with Plesk (and how to avoid dedicating your life to it):

Igor Antipkin  

Igor is a Security Engineer at Plesk. 

Episode 5

Finding the Right Managed Hosting for You

As WordPress continues to grow, traditional, service-free hosts could be left behind. This is what Andrey Kugaevskiy tells us in this episode of Next Level Ops, spelling out the benefits of Managed WordPress Hosting. 

In this month’s discussion with Joe, we learn how choosing a suitable WordPress host can be tricky, and you should keep WordPress-savvy people around if you’re not sure. Andrey suggests, for a smoother, easier and safer experience, take the option of host + management, any day.

Hear the full break-down of Managed WordPress options to make your life easier:

Andrey Kugaevskiy  

Andrey is a Senior Program Manager at Plesk.

Episode 6

Competing in a Hyperscale Cloud Environment

Welcoming back Lukas Hertig, episode 6 explores the world of cloud hosting, its applications in our everyday lives, and ‘hyperscaling’. In other words, companies like Netflix and Amazon that are scaling their operations thanks to shared services in the cloud.

More and more, hosting services opt for the cloud, with its flexibility and specialist managed services. So how do you compete in that environment? Are you thirsty to know how to benefit from the cloud, from experts?

Well then listen to this episode here:

Lukas Hertig  

Lukas is the SVP Business Development & Strategic Alliances at Plesk.

Episode 7

The Downtime Checklist and Web Scaling

Jan Loeffler, tech mage at Plesk, returns for this edition of Next Level Ops to discuss scalability and hosting. 

As you grow your online presence and traffic starts streaming in, Jan talks of the necessary steps for scaling. Have you considered how you’ll avoid downtime? Does your server have the capacity to grow? How long will customers have to wait for the page to load? Jan suggests a Downtime Checklist for scaling and optimization, but you’ll have to hear the full version in the episode here:

Jan Loeffler  

Jan is the Chief Technical Officer at Plesk.

Episode 8

Solving Common WordPress Problems

“The great and terrible thing about WordPress is the amount of freedom you have.” Guest-starring to discuss common issues with WordPress, product wizard Lucas Radke explains the value of a secure hosting environment. With so much margin for error, web builders, admin and users have to be proactive in preventing risks for their WordPress.

But hope is not lost. Click play to learn how powerful hosting and plugins make your life easier and avoid the most common WordPress mishaps:

Lucas Radke

Lucas is a Product Manager at Plesk

Episode 9

The World of Email Hosting Providers

Are you searching for the best email hosting provider, and don’t know where to start? Scratching your head about enterprise options? Then put on those headphones and tune in to this edition of the Plesk Official Podcast, where Joe speaks to Christian Mollekopf from Apheleia IT to clarify the features and pitfalls of email hosting.

You’ll learn about calendar options, self-hosting, spam control and more. Click play to get the full intel:

Christian Mollekopf

Christian is a Senior Software Engineer at Apheleia IT.

Episode 10

Toolkits and Tips for Web Development

For the final episode of this season of Next Level Ops, special guest Brian Richards, Creator of WPSessions, takes us listeners through the modern tools for everyday web developers

Besides imparting useful tips about coding, Brian provides a specific list of great web dev tools and learning resources, suitable for keeping any developer in-the-know. 

Intrigued? Get your coding fix by pressing the play button:

Brian Richards

Brian is the Creator of WPsessions and an independent web developer.

Did this series leave you wanting more? To make sure that you get your regular dose of tech podcasts, Season 2 is coming soon. Watch this space, or our Spotify and Apple Podcast channels to get the latest updates.

Get to Know our Season 1 Host:

Joe Casabona

Joe is a college-accredited course developer. He is the founder of Creator Courses.

SSL Certificates and Web Security – A Guide

In today’s world, web security and SSL certificates have become mandatory. When ranking websites, Google, the largest search engine on the planet, looks for SSL certificates for better rankings and prioritizing. And they have also started the initiative of “HTTPS everywhere” to make the web a more secure place and highlight the importance of web security.

This article will discuss more on what SSL certification is, what types there are, and compare two major companies that provide SSL certificates – DigiCert and Sectigo.

What are SSL Certificates?

SSL stands for Secure Socket Layer. This layer establishes a secure connection between the web server and the web browser. When a website has an SSL certificate, a small lock symbol appears at the start of the link. And HTTPS appears in the URL instead of HTTP, which means that you are browsing securely.

SSL uses cryptographic techniques to provide safety to users. The web browser attempts to connect with the webserver and sends a message to the server to identify itself. The web server sends its SSL certificates to the web browser for verification. The browser verifies the certificate and sends a connection request to the server, and the server sends back acknowledgment, and the encrypted session gets started. The data that goes back and forth between the browser and the server is therefore encrypted.

An SSL certificate provides security to the website’s data. It’s almost impossible to breach into the data with SSL, and even if there is a breach, the data is in extreme cryptography and can’t be deciphered. Customers’ information like usernames and passwords are safe and secure when the website has an SSL certification. Important transaction information like credit and debit card details and online wallet details are highly secured with SSL certification. 

Google gives top priority to secure websites and helps them rank faster. The first thing a user notices when visiting a website is the security, i.e., SSL and HTTPS, so it is essential to have a secure website to gain credibility with the customers and indirectly generate more revenue.

Types of Certificates

Depending on the capacity and purpose at which we operate our website, there are four types of SSL certificates:

N.B. Wildcards are a handy sub-type of DV or OV certificates.

Let’s look into each certification in more detail.

Extended validation certificate (EV SSL)

EV SSL is the most trusted and most used certificate by businesses around the globe. These certifications are issued under guidelines that are proposed by the CA/Browser forum. They can only be published by the subset of CAs (Certified Authorities) and require legal verification of the certificate’s requestor. This certificate uses the same encryption techniques as the other two types. EV certificates show a green browser bar, which indicates security and credibility.

Organization Validated Certificate (OV SSL)

These certificates show that an organization is valid. The owner of the business must show proof of both the physical and legal existence of the company. The users will see a lock at the start of the address bar, which indicates that the site is secure and safe from hackers.

Domain Validated Certificate (DV SSL)

These are some of the most commonly used certificates. The verification process for DV only verifies the domain of the website (business). This verification is to check whether the requestor is the owner of the domain or not.

Wildcard Certificate (Wildcard SSL)

A useful type of certificate that secures all subdomains at once, along with the main one. It’s therefore not necessary to issue a new certificate if a new subdomain is changed or created. Only available on DV or OV certificate types, for security reasons.

Where to get SSL Certificates

There are many SSL certificate providers across the globe. This article will discuss two of the top companies that provide the certification, and those are Digicert and Sectigo.

SSL Certificate using DigiCert

DigiCert.Inc is an American based digital company that provides users with digital security. They help users across the globe to get the validation required for SSL certificates through Public Key Infrastructure. DigiCert is the world’s largest certificate authority, representing 60% of the EV certificates and 96% of the OV certificates globally.

Among its extensive range, it offers three major certifications, namely DigiCert Basic, DigiCert secure site, and DigiCert secure site pro. According to the security level users need on their website, they choose from the given options. The basic variation is cheaper, and as secure features are added, the cost also increases.

SSL Certificate using Sectigo

Formerly known as Comodo CA limited (Rebranded as Sectigo in November 2018), Sectigo company holds the authority for issuing SSL certificates. The company offers digital security to both organizations and independent consumers. With more than 20 years of experience under their belt and hundreds of thousands of customers worldwide, Sectigo is one of the leading companies that provide web security with SSL certifications.

Sectigo broadly offers six types of certificates for the customers who want their website secured from malware. They include DV SSL, OV SSL, EV SSL, WILDCARD SSL, MULTIDOMAIN SSL, and SINGLE CERTIFICATES. They are also an award-winning innovation company with excellent customer support.

DigiCert vs Sectigo – feature comparison

Now, let’s take a closer look at each metric and compare them.


Key size and encryption strength

The key size determines the number of combinations it takes to break an encryption algorithm. Both DigiCert and Sectigo offer 2048 Bit keys so their encryption is very hard to break. The encryption strength is also the same for both, which is 256-Bit.

Root Domain Support

Sectigo and Digicert now secure and cover domains both with and without www.

Validation level

Both Digicert and Sectigo support all the validation certificate types, including domain validated certifications. However, Digicert brand does not offer DV SSL – the most basic and common type – except under its sub-brands. So, Digicert itself serves more enterprise-level needs whereas many users search for DV SSL with Sectigo.

Multiple Domains and Sub-Domains

If we want to cover multiple or sub-domains with SSL certification, both Sectigo and DigiCert provide multi-domain certificates called SAN certificates. We can add up to 250 Multi-domain SANs with DigiCert and 100 SANs with Sectigo.

Issuing Authority

Comodo Ca is a well-reputed brand with more than 20 years of experience. They rebranded themselves in fall 2018 to Sectigo, but they still have the largest market share of CAs. DigiCert, formerly known as Symantec, has also been around the block for many years and has vast industry experience.

Certificate Costs

With so many free SSL certificates available in the market, it sounds like a feasible idea to settle for one. But with premium certifications, you get both customer support and value for money. On top of that, OV and EV SSLs provide a further layer of customer trust as the certificate itself lists the business or registered organization. They can’t be issued to individuals.

Both DigiCert and Sectigo offer premium customer support and services. 

Final Words

We have now seen what SSL certification is and what benefits it provides to website owners. And also, we have seen different types of SSL certificates based on usage and capacity. 

Looking at the two top SSL providers, with their powerful encryption and multiple validation options, the choice is tough. Both will secure your site robustly. Both have long-held authority and experience. The only thing to consider is whether their specific certificate types match your site. 

Looking for domain protection for your blog? DV SSL with Sectigo will be great. Maintaining a high-traffic site with multiple sub-domains? Both brands can get you a top Wildcard version of the OV SSL certificate. Know your site, think security and trust, and you’ll know what certificate works best for you.

Secure your domain now

At Plesk, safety and credibility are provided by powerful Sectigo plugins for you and your customers. Through the SSL It! extension, DV and DV Wildcard releases are among the many certificates you can easily install to secure your domain.

The next screenshot shows how SSL It!’s page looks like for a domain without a configured certificate but when the Sectigo extension is already installed:

Let’s click “Buy Now”. Purchasing a PositiveSSL certificate via

After purchasing, Sectigo (Certification Authority, CA) verifies a domain and issues a certificate. When the certificate is issued, the extension automatically installs and secures the website in Plesk. As you can see, SSL Labs rated the website secured with a Sectigo certificate on A grade.

Just four easy steps, and your site is protected. 

Want to learn more about web security? Our podcast reveals all. 

Best WordPress Caching Plugins Comparison

WordPress Caching Plugins Plesk

WordPress caching plugins is a complex topic for many people (especially newcomers), and there’s a lot to cover in any guide. A comprehensive exploration of WordPress caching might even demand a whole book — which we obviously don’t have the space or time to create here. But we can make the essentials of WordPress caching easier to understand, and that’s exactly what we’ll do below.

First, let’s start by looking at caching it as if it were a fairly straightforward math problem to be solved. Most of you reading this would have no problem multiplying, say, eight by eight to get 64. That’s a simple sum countless children learn in school every year. And they — and you — know the answer because you’ve memorized it. You might run a brief calculation in your head, but it should seem as if you can pull the solution out of your memory as naturally as recalling your own name. So, this form of memorization can be compared to website caching, even though it is a major simplification of the process. This example helps to visualize caching and illustrates why WordPress caching plugins are so important for a quality user experience.

Your website is required to present the same (or similar) content again and again, no matter how many visitors you receive per day. Even if you only attract a few dozen people, your site is still bringing the same content up repeatedly over weeks and months. Wouldn’t it be fantastic if the server was able to remember the necessary files required to present your website as it needs to every single time more efficiently, as you can when solving simple calculations?

Explaining the Caching Process

Basically, any page a visitor navigates to on your website requires a server request, and processing by that same server (along with database queries). Next, a final result will be sent from the server to the visitor’s browser, which enables them to view your website with all the elements and files essential for forming its complete design. These include menus, blog posts, images, videos, etc.

As the server is expected to process each of these requests, and to do so as quickly as possible, delivering a full web page to users can be a surprisingly time-consuming process. Particularly for bigger websites or those best described as “clunky”.

But this is where WordPress caching plugins prove helpful. The caching plugin is designed to tell the server to keep some of the files stored to RAM or disk (based on your specific configuration). That means the server can remember content it’s served in the past and duplicate it for the user. Web pages will load far faster from the cache directly, and the amount of work needed to generate a pageview is reduced significantly.

That’s the power of caching.

When You Need WordPress Caching Plugins

We’ve already covered how caching can increase the speed of web pages, but is it always essential to install WordPress caching plugins? And are there any other advantages to caching you should know about? For anyone responsible for managing their own servers or using shared hosting, caching plugins are generally a fantastic idea.

But there are times when you won’t actually need a caching plugin. If you were to work with a trustworthy managed WordPress host, for example, they would handle the caching on your behalf. This would be performed at server-level and much quicker, in a lot of cases. Server-level caching demands no knowledge, expertise, or time-intensive configuration to achieve the best speeds. It will be fast all the time — that’s it.

Often, top managed WordPress hosts don’t utilize caching plugins on their platforms as they may affect performance quality. Some things can go awry if you don’t know what you’re doing with plugins, which is where a little expert management can be a big help.

Why Some Caching Is Always Necessary

No matter if you choose server-level caching or opt for a plugin instead, you’ll always find some type of caching necessary. Here are some of the main benefits of caching to consider:

  • Deliver a faster browsing experience for users — we’ve already addressed how WordPress caching plugins can boost your site’s speed, but it’s a core advantage so deserves to be on this list!
  • Provide a better user experience overall — as your website will run more quickly, users will be more likely to stay and explore. Faster sites are known to have lower bounce rates, reducing the risk of people becoming frustrated and clicking away after waiting for more than 10 seconds or so for pages to load.
  • Servers rely on fewer resources — fewer resources contribute to a quicker website, and place less strain on servers. This is crucial for highly-dynamic websites (e.g. membership sites) and for determining what can or can’t be served from cache.
  • Potential SEO improvement — a faster speed and better user experience can inspire search engines to recognize that your website is worthy of a higher ranking. This makes caching a helpful addition to your search engine optimization strategy.
  • Lower time to first byte (TTFB) — using WordPress caching plugins is one of the simplest ways to reduce your TTFB, by as much as 90 percent in some cases.

How Does Caching Compare Against No Caching?

To show you how much difference caching versus no caching makes, we decided to run a few simple server-level caching speed tests.

First, we ran five Pingdom tests with no caching activated and measured the average, and then did the same with caching enabled. The average load time without caching was 677 ms, and the average with caching was 521 ms!

So, caching decreased our page load time by more than 23 percent, with no additional work required. We used a fairly well-optimized site for the speed tests, which means websites with less optimization will run even more quickly.

TTFB with no caching

Remember when we discussed how caching can affect your TTFB above? Well, we ran some more tests to identify how well caching can reduce TTFB.

We found that TTFB with no caching was more than 200 ms, but this dropped to under 40 ms when we enabled caching. That’s a huge difference.

It’s clear, then, that enabling WordPress caching plugins can decrease your TTFB substantially. And, again, that means better performance overall.

What Are the Best WordPress Caching Plugins Available?

Below, we’ll explore the best WordPress caching plugins to try if you plan to manage your own server or use shared hosting. While some may be more intuitive, they’ve all earned fantastic reviews from users. A lot of posts published online will attempt to compare caching plugin speeds and sell you the one they consider the best. But this is almost impossible, as plugins will perform differently depending on your choice of server, resources, configuration, and location.

Yes, we find speed tests as helpful as anyone else, but dubbing one plugin “the quickest” is frankly unfair. Why? Because what works brilliantly for one user might not be so effective for another. And that’s not to mention that there hundreds of different settings may be available to enable or disable.

With all this in mind, we feel it’s best that you always test WordPress caching plugins yourself to determine which work best for you.

We’ve collated a concise list of the top WordPress caching plugins to help you make an informed decision. You’ll find more detailed insights for each one further down, covering pricing, benefits, and more.

Our list:

We’ve found that it’s ideal to experiment with a minimum of two or three WordPress caching plugins before committing to any one option. You might find that you love the user interface and design in some caching plugins, but find others much easier to use overall.

Another recommendation from our experts is to run a speed test with a dedicated tool, such as GTMetrix or Pingdom, once you’ve implemented each plugin. This will enable you to check the impact the plugin has on your site’s performance.

But be sure to run a number of speed tests to make sure plugins are serving from cache. When you clear your WordPress website’s cache, it needs to rebuild. Helpfully, some plugins include an option to preload (or “warm”) the cache once it’s been cleared.

Be aware, though, that caching plugins can lead to issues while they’re helping your website run faster. There’s a particular error to watch out for when using caching plugins: “No update required. Your WordPress database is already up to date”. Keep that in mind, though it certainly shouldn’t put you off!

So, onto our in-depth look at the top WordPress caching plugins for your site!

WP Rocket

This is a premium WordPress caching plugin, offering three payment plans. You can pay a one-time fee, but if you keep your payments running, support and updates will be included. WP Rocket lists caching for a single website as $39, while support for three sites is just $99. For $199, you can get caching for an unlimited number of websites. Free plugins are available, but these rates are impressive considering WP Rocket is one of the market’s most feature-rich WordPress caching plugins.

There’s no free version or free trial for the WordPress caching WP Rocket plugin, but WP Rocket’s developers provide a 14-day money-back guarantee to ensure your satisfaction.

One of the main advantages of WP Rocket is its user-friendly interface and fast, hassle-free setup. This is a caching plugin for WordPress with the power to help your website run much faster, and yet any newcomer would find it easy to grasp the majority of the settings from the start.

Another top reason for WP Rocket to be worth a consideration is that it’s designed to run nicely on eCommerce sites. That’s ideal as, most often, those require better caching speed the most.

On the whole, you might ask why you should pay any cash for a WordPress caching plugin at all when there are some competitors giving theirs away for free. Well, that’s because WP Rocket offers a wealth of solid features and is simpler to use overall.

For example, WP Super Cache provides users with page caching, yet browser caching is unavailable. WP Rocket, on the other hand, delivers both.

And Hyper Cache is missing lazyload, whereas that’s just another part of the WP Rocket package.

We could go on and on like this, comparing WP Rocket with the competition, but the main point to remember is that $39 is a modest rate to pay for the sheer variety of features included.

Reasons this is one of the top WordPress caching plugins

  • WP Rocket delivers a developer-friendly package, with a great dashboard to help newcomers feel at ease. Developers rarely have so much to experiment with in caching plugins, and others can make it far too complex for first-timers too.
  • The setup process is highly accessible for users of all experience and skill levels.
  • You can use the included database optimization to clean up your WordPress database, as well as decreasing the amount of resources used.
  • You can use WP Rocket to lazyload media, so that images don’t load on your site until a user actually scrolls over them. That means the server won’t need to do the work until it’s absolutely necessary.
  • You can increase your website’s speed even more with WP Rocket’s CloudFlare compatibility.
  • Multisite compatibility is also available through this plugin.
  • You can preload your cache.
  • Tools for minification and concatenation are included.
  • One of the most distinctive features is the Google Fonts optimization. I haven’t seen this included as part of another caching plugin so far.
  • Support available for object caching.

Take a look at the official WP Rocket documentation for help when configuring and experimenting with this plugin on your WordPress website.

Cache Enabler

Cache Enabler is an open-source, free caching plugin from KeyCDN (known for powering the Kinsta CDN). The disk caching engine’s performance is quick and dependable, while the multisite support is a benefit for users operating networks of sites.

The WordPress caching Cache Enabler plugin is a quality option without a hefty price tag: you may not be receiving the comprehensive range of features you would in WP Rocket, but Cache Enabler is still a terrific alternative if you’re on a tighter budget.

Cache Enabler’s big claim to fame is that it was the first WordPress plugin designed to help you serve WebP images with no need to use JavaScript. Sounds like senseless technical jargon to you? All you need to know is that while JavaScript is an important coding language, it can disrupt website speed in some cases.

Combining Cache Enabler with ShortPixel, EWWW, or Optimus plugin enables you to utilize this more recent image format properly. That’s a fantastic option for anyone running an online business, as most websites include dozens or hundreds of images, such as eCommerce sites or blogs.

Finally, Cache Enabler’s settings are simple and concise. They ask for such things as caching behavior preferences and cache expiry behind the scenes, the settings page offers explanations, and the number of settings is fairly low overall. As a result, most people will find this a confusion-free zone.

Reasons this is one of the top WordPress caching plugins

  • Cache Enabler provides a unique way to serve WebP images: you can convert pictures to WebP format via ShortPixel, Optimus, or EWWW Cloud (the cloud version is recommended for its solid performance).
  • Cache Enabler WordPress caching plugins include a user-friendly, streamlined interface for maximum convenience. This is one of the simplest plugins to set up, and users at all levels of experience should find it a pleasure to handle.
  • Actual cache size is presented on the dashboard, to help you understand the amount of space the cache consumes. This is a fast, efficient caching program, offering manual and automated clearing options.
  • Minification for inline JavaScript and HTML is available.
  • This combines with the Autoptimize plugin to bring you additional features, such as injecting CSS into page heads.

Take a look at the official Cache Enabler documentation for help when you configure and test this plugin on your website.

WP Super Cache

WP Super Cache is a terrific example of an open-source WordPress caching plugin boasting installation numbers in the millions. When you search for caching plugins, WP Super Cache and W3 Total Cache (see below) will appear high on the list most of the time.

While it’s unfortunate that these plugins have such similar names, they are very different. It’s best to install both and try them separately to identify the right one for your site. You might prefer to install WP Super Cache first purely because it’s the work of the Automattic team, but both are worth considering.

Regardless, WP Super Cache is an open-source, free plugin with zero upgrades required once you’ve installed it. This performs efficiency by building static HTML files and serving these instead of the weighty WordPress PHP scripts.

Three caching modes are available, which is one of the WordPress caching WP Super Cache plugin’s most appealing features. One is titled Simple Mode: the average WordPress user would choose this as it poses the least risk. But another of the modes, Expert Mode, enables you to super cache files with various modifications to the .htaccess file. This is great for seasoned developers who prefer greater control over their site’s caching process.

The Simpler mode makes WP Super Cache simple to set up (as the name suggests!). This enables you to compress pages, and offers easy caching, CDN support, as well as cache rebuilding. On top of all this, you can identify known users and choose to not cache pages for them if necessary.

Additional homepage checks can be helpful too, when you want to make sure your site’s primary page is as optimized as it can be.

One of the core advantages of WP Super Cache is its garbage collecting: your cache directory fills up and can leave your site running slowly over time. WP Super Cache runs automated garbage collections regularly to clean older files out and maintain your site’s optimization.

Reasons this is one of the top WordPress caching plugins

  • WP Super Cache boasts a positive reputation and track record, so you can expect its caching services for one or more of your sites to be of a high standard (no matter how big they may be).
  • This is an open-source, free product from Automattic — this means updates are regular and WP Super Cache is unlikely to disappear without warning.
  • In WP Super Cache’s backend interface, a lot of the settings you require are already filled in. As a result, it’s fairly easy to understand and put to work, even if you’re a total novice.
  • WP Super Cache utilizes a garbage collection process, clearing your older files out of the cache to prevent slowdown. This helps your site run faster and more smoothly.
  • This is integrated with a unique CDN setup, distributing your files better.
  • You can select from three caching modes, including Simple and Super Caching. This makes WP Super Cache a top option for diverse skill levels: the Simple cache option is great for the average user, while the Super Cache mode enables more advanced users to boost their site’s speed substantially.
  • WP Super Cache includes a unique feature known as Cache Rebuilding. Your blog’s cache won’t be cleared whenever a visitor posts a comment: the cache will be rebuilt and the old page will be served to other users instead.

While WP Super Cache has no official documentation online, the repository page carries a wealth of information.


Comet Cache

Comet Cache has one of the coolest names of all the WordPress caching plugins, and it has a solid reputation too. You can choose from a free or paid version.

The paid version is available from $39 to $139, as a one-time charge. However, you can opt to pay extra fees if you would prefer more extensive customer support with the WordPress caching Comet Cache plugin.

Comet Cache includes similar features to the caching plugins we’ve explored above, but it stands out for its incredible documentation. Even the regular WordPress plugin page offers lots of FAQs and links to help you learn about caching.

The Comet Cache website is home to a complete knowledge base and insightful blog. There’s plenty of information on the free and premium versions, with comparisons to help you choose.

A key reason for upgrading is Comet Cache’s automation: you can set this up and forget about it while the plugin does the majority of the work on your behalf.

The free version is capable of accomplishing many of the same tasks, but you will need to complete them yourself manually at times.

The client-side browser caching is helpful, too, as you’re basically double caching: the server is on your end and the browser is on the user’s. Crucially, it’s fairly simple to install the Comet Cache plugin and the dashboard is easy to navigate.

Reasons this is one of the top WordPress caching plugins

  • With Comet Cache, you can take advantage of a quick setup and decent backend, so configuring the cache takes a matter of minutes.
  • You can cache on pages, posts, categories, and tags.
  • With the paid version of Comet Cache, you can try intelligent and automatic cache clearing. This allows you to establish caching preferences when you install it and forget about them for a while.
  • You can cache RSS feeds to avoid delays in your content syndication.
  • The plugin gives most of its main features away free, so you might not need to upgrade.
  • The paid version is similar to what you would receive from WP Rocket, so we’d advise that you test both to see which suits your goals best.

Browse the Comet Cache official documentation and community forum for help when configuring or testing this plugin on your website.

Hyper Cache

The WordPress caching Hyper Cache plugin runs on PHP only, so it’s simple to set up with no complicated configurations to worry about. This is also compatible with WordPress blogs of any kind.

A main benefit of Hyper Cache is that it’s aware of mobile environments. As a result, the caching continues to run when a user visits your site on their smartphone or tablet. This ensures your website remains fast and performs smoothly across devices, for total user convenience.

As Hyper Cache is open-source, there’s no need to pay or stress about future upgrades either. If you want to support the developer and compensate them for their work, though, you can make a donation.

The installation process for Hyper Cache is quick and easy. That’s ideal for newcomers and unskilled users of WordPress who might feel overwhelmed by extensive caching settings.

Furthermore, the compression caching optimizes bandwidth and boosts page speed brilliantly. This plugin is also intended to work with bbPress well, so if you want to run a forum, Hyper Cache is a fantastic option for caching its pages.

Perhaps Hyper Cache’s biggest advantage is its simple configuration. You can almost set it up and forget about it, with no reason to worry about its function following installation.

Admittedly, some of the settings have been assigned unexpected names or can seem somewhat tricky at first. But they generally include recommendations to help you understand what to enable and how they work.

Reasons this is one of the top WordPress caching plugins

  • There are no payment plans for Hyper Cache: this is a free, open-source plugin, and all features are included with initial download.
  • Hyper Cache is mobile-aware, so caching runs on mobile devices too.
  • This plugin includes CDN support, enabling you to tap into larger networks of servers and increase your website’s speed further.
  • Hyper Cache provides options for serving cached pages to visitors writing comments on your blog. You can cultivate more discussions on your posts without worrying about them affecting its speed.
  • Compression will be managed via the Hyper Cache plugin, for non-cached pages too.
  • Hyper Cache is designed to detect if a site’s theme has changed to its mobile version, for a better user experience.
  • This plugin will relocate the cache folder beyond your blog, and the cache folder won’t be included in your website backups. That means you can make smaller backup files while saving space.

Take a look at the official Hyper Cache documentation and visit the community forum to learn more when setting this plugin up on your site.

WP Fastest Cache

WP Fastest Cache’s name is obviously similar to some of the other WordPress caching plugins on this list, but don’t be fooled: this has a number of features that make it stand out.

You can get started with a free version of the WordPress caching WP Fastest Cache plugin, though a premium one is available for purchase through the settings module if you want to upgrade.

With the premium version of WP Fastest Cache, the fee is one-time only, and you’ll get access to a varied selection of tools that are unavailable in the free version. But generally, the majority of websites will be satisfied with the free plugin, as it features desktop caching, combination options for CSS and JavaScript, as well as HTML minification.

You’ll also have access to GZIP tools and browser caching in the free WP Fastest Cache plugin. Overall, this plugin can help to make websites’ performance much faster and smoother compared to sites using no caching plugin whatsoever.

The settings basically consist of a checkbox list, which makes it one of the simpler settings pages to explore. Information boxes are also included, offering clear explanations to guide your choices. You can switch between tabs for managing key items, such as imagine optimization, the CDN, and the cache timeouts.

Reasons this is one of the top WordPress caching plugins

  • The free version of WP Fastest Cache can prove useful for the majority of sites, and it appears to serve sites more quickly than a lot of the competitors.
  • The settings comprise a list of checkboxes alongside easy-to-follow information points, so it’s simple to use.
  • You can upgrade from the free to the premium version in the WordPress dashboard for maximum convenience. You don’t have to download a plugin from the developer’s site.
  • CSS and JavaScript can be combined and minified.
  • You can integrate CDN without too much configuration required.
  • Optimization of images is performed separately from the caching process, so you can see the amount of space saved with one of your biggest resource-consumers.
  • A feature is included for creating a cache for a mobile theme specifically. You can also opt to not serve a cached version for the desktop to your mobile users.

While WP Fastest Cache has no official documentation in one place, you can still find a wealth of tutorials on configuring WP Fastest Cache on your WordPress website on their blog.

W3 Total Cache

You might be aware of W3 Total Cache, as it’s one of the most popular WordPress plugins available. The WordPress caching W3 Total Cache plugin is a decent free, open-source solution, though we can’t pretend that it’s the ideal option for any website.

One of its main disadvantages is that its backend settings can be extensive and, sadly, hard to grasp. The development team can complete the proper settings for you efficiently, though newcomers may still feel confused.

Despite this issue, W3 Total Cache has managed to achieve millions of installations. It can be integrated with a CDN, and works for mobile and desktop websites nicely. It’s also recommended as a helpful companion for sites holding SSL certificates, which means eCommerce websites in particular might benefit from installing it.

The free version of the W3 Total Cache plugin includes all the features, and there are no prompts designed to push you into upgrading. The plugin can also help you make savings on bandwidth, thanks to HTTP compression, feed optimization, and minifications.

Yes, it doesn’t have the best backend configuration we’ve ever seen, but that could be down to our personal taste. Nevertheless, W3 Total Cache is still sure to help your website’s performance improve and, in turn, increase conversions.

Reasons this is one of the top WordPress caching plugins

  • W3 Total Cache is free, and most of the caching plugins you’ll need to boost your site’s speed and optimization are included.
  • Popularity can be considered an indication of a plugin’s quality,thanks to its millions of installations, though we don’t recommend you base your decisions on that alone. Take the time to browse the many positive reviews to learn more about W3 Total Cache before you commit.
  • W3 Total Cache is compatible with various hosting options, including shared hosting, clusters, and dedicated servers.
  • You can use caching for any mobile environment, so that when a user visits your site on a smartphone, they’ll still benefit from caching as they would on their computer.
  • W3 Total Cache provides SSL support, to help your online store run more quickly and efficiently. That can improve the customer experience overall.
  • As the CDN works with the media library, you can check the quality of your images’ optimization easily.
  • You’ll have access to compression and minification, as well as caching of databases, objects on your disk, and posts.
  • Object caching is supported with W3 Total Cache.

You can get started with help from the in-depth documentation for W3 Total Cache available

Alternative Approach To Caching

Instead of using caching solutions on web app level you may think about NGINX – it can proxy requests to other web servers or apps. The outcome here – performance increase for serving static files.  Another important feature – NGINX can sit ‘in front’ of web servers where it acts as a gateway to other applications or servers. Additionally, it can also cache the results of requests proxied to FastCGI and uWSGI processes, as well as to other HTTP servers.

NGINX is fully supported by Plesk and can be configured/tuned up easily via Plesk interface. And if you consider to user NGINX with Plesk for caching – think also about WordPress Toolkit, which will help you a lot to manage WordPress routine tasks.


We hope we’ve helped you understand why website caching is so important, but the functions that make caching work can be incredibly difficult for the average WordPress user to understand initially. That’s why you might struggle to determine which settings in a caching plugin will be right for you at first.

Again, if you choose managed WordPress hosting, you won’t need to organize your own plugins. The host will do that for you, and caching will take place on the server. But caching plugins are essential if you’re using shared or self-managed hosting.

Now that you’ve reached the end of this guide, we hope you’ll find picking the best plugins for your WordPress website easier. Focus on learning as much as you can about any of the WordPress plugins that appeal to you most, to help yourself make the most well-informed decision.