Introduction

If your Plesk server feels sluggish under load, it’s probably because Apache alone can’t handle hundreds of concurrent requests efficiently. That’s where Nginx and Varnish Cache come in. Together, they form a powerful reverse-proxy layer that accelerates websites, reduces CPU load, and improves response times dramatically.

In this guide, you’ll learn how to install and configure Nginx and Varnish alongside Apache on a Plesk-based server. We’ll cover architecture, installation, configuration, and best practices for stability and cache optimization.

1. Why Combine Nginx, Varnish, and Apache?

A default Plesk setup uses Apache as the main web server and Nginx as a reverse proxy. Apache handles PHP execution (through PHP-FPM or mod_php), while Nginx serves static files and buffers requests.

But when your site starts receiving heavy traffic or dynamic pages (like WordPress, Joomla, or WooCommerce), even that combination can get overwhelmed.

That’s where Varnish Cache makes a massive difference.

The request flow becomes:

Client → Varnish → Nginx → Apache → PHP-FPM → MySQL

This chain ensures that repeat requests rarely hit Apache or PHP, saving CPU and memory.

2. Prerequisites

Before starting:

• A VPS or dedicated server running Plesk Obsidian (18.x+)

• Root SSH access

• Ensure ports 80, 443, and 6081 (Varnish default) are open

• Installed modules: mod_proxy, mod_headers, php-fpm

3. Step-by-Step Installation

Step 1: Install Varnish

# For Ubuntu / Debian
apt update
apt install varnish -y

# For CentOS / AlmaLinux / Rocky
dnf install varnish -y

Check version:

varnishd -V

By default, Varnish listens on port 6081.

Step 2: Stop Apache from using Port 80

Edit Plesk’s Apache configuration to move Apache to port 8080 (since Varnish will take over port 80).

nano /etc/httpd/conf/httpd.conf
# or /etc/apache2/ports.conf

Listen 8080

Restart Apache:

systemctl restart httpd
# or
systemctl restart apache2

Step 3: Configure Varnish to Listen on Port 80

Edit /etc/varnish/default.vcl and define your backend (Apache):

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

Then update Varnish’s systemd config:

nano /etc/systemd/system/multi-user.target.wants/varnish.service

Find:

ExecStart=/usr/sbin/varnishd -a :6081

Replace with:

ExecStart=/usr/sbin/varnishd -a :80 -b 127.0.0.1:8080 -s malloc,256m

Reload systemd and restart Varnish:

systemctl daemon-reload
systemctl restart varnish

Step 4: Adjust Nginx Reverse Proxy in Plesk

Plesk’s Nginx should proxy requests to Varnish, not directly to Apache.

Edit:

/etc/nginx/plesk.conf.d/server.conf

Replace backend:

proxy_pass http://127.0.0.1:8080;

with

proxy_pass http://127.0.0.1:80;

Then reload services:

systemctl restart nginx
systemctl restart varnish

4. Verify the Setup

Run:

curl -I http://yourdomain.com

You should see a header like:

Via: 1.1 varnish
X-Cache: HIT

If it says “MISS” initially, reload the page again — a “HIT” means caching works.

You can also monitor Varnish live:

varnishstat

5. Fine-Tuning Varnish Cache for WordPress (Optional)

For WordPress or dynamic CMSs, use a VCL configuration to exclude logged-in users and admin pages:

sub vcl_recv {
    if (req.url ~ "wp-admin" || req.url ~ "wp-login") {
        return (pass);
    }
    if (req.http.Cookie ~ "wordpress_logged_in") {
        return (pass);
    }
}

This prevents caching for admins and logged-in users but keeps it active for visitors.

6. Performance Tips

• Enable HTTP/2 and Brotli compression in Plesk → Tools & Settings → Apache & Nginx Settings.

• Use Redis Object Cache for dynamic data.

• Keep Varnish memory (malloc) sized correctly — 256 MB minimum for small sites, 1–2 GB for heavy traffic.

• Use a monitoring script (like your cpumon.sh) to track real CPU/IO usage.

• If SSL is terminated at Nginx, make sure Varnish handles only HTTP (port 80).

7. Conclusion

By combining Nginx, Varnish, and Apache inside your Plesk environment, you achieve a near-CDN level of performance without relying on external caching layers.

Static requests fly through Nginx, cached pages load instantly from Varnish, and Apache only handles what’s truly dynamic — resulting in a faster, more efficient, and more scalable hosting stack.

If you manage multiple client servers or WordPress-heavy workloads, this setup is one of the best low-cost performance boosts you can implement today.