cPanel ships its own Nginx package, ea-nginx, that sits in front of Apache as a caching reverse proxy. It listens on ports 80 and 443, serves static files and cached dynamic responses itself, and only hands the rest to Apache. For a shared box full of WordPress sites it is the cheapest TTFB win you can deploy — no extra license, no third-party plugin like Engintron, and it's managed entirely from WHM.
This is for cPanel admins who want Nginx caching without bolting on an unsupported stack. It covers the install from WHM, how the per-user cache works, the cookie rules that keep logged-in users safe, and how to clear the cache when a site goes stale. If you're weighing this against LiteSpeed instead, read LiteSpeed vs Nginx for WordPress first — EA-Nginx is the free option, not the fastest one.
What EA-Nginx actually does
In reverse-proxy mode Nginx terminates the connection, and for each request decides:
- Static file (images, CSS, JS) — served directly by Nginx, never touching Apache.
- Cacheable dynamic response — served from the on-disk cache if a fresh copy exists.
- Everything else — proxied to Apache on a loopback port, with the response optionally stored in the cache on the way back.
The cache is stored per user at /var/cache/ea-nginx/proxy/<username>. That isolation matters on shared hosting: one account's cached pages can't be served to another, and you can wipe a single site's cache without flushing the whole server.
Install and switch to reverse-proxy mode
Install the package from the command line, then flip the mode in WHM:
yum install ea-nginx
On AlmaLinux/Rocky 8+ this pulls ea-nginx from the EasyApache repo. Then in WHM go to Home » Software » NGINX Manager. The page opens in Standalone mode after install; click Switch to Reverse Proxy (sometimes labelled Caching Reverse Proxy) to put Nginx in front of Apache.
By default, Use caching by default is enabled, so every existing account gets Nginx caching the moment you switch. Nginx generates a config file per user at /etc/nginx/conf.d/users/<username>.conf and reloads.
Confirm Nginx is now the edge server:
curl -sI https://example.com/ | grep -i server
You want Server: nginx. If you still see Apache, the switch didn't take — re-run the mode change from NGINX Manager and check systemctl status nginx.
Verify the cache is actually serving
cPanel doesn't add an X-Cache header by default, so the cleanest way to confirm a hit is to watch where the response comes from. Hit a static asset twice and a public page twice, then check Apache's access log — a cached page should stop appearing there:
tail -f /usr/local/apache/domlogs/example.com | grep wp-login
Load an anonymous page repeatedly; if Apache's log stays quiet after the first request, Nginx is serving from cache. Requests that still hit Apache every time are being bypassed — which is correct for logged-in traffic (see below) and a problem for anonymous traffic.
For a clearer signal, add a debug header via a per-user include (covered next) so curl -I shows X-Cache-Status: HIT.
The cookie rules that keep users safe
The single most important thing to understand: EA-Nginx bypasses the cache for requests carrying session cookies. Out of the box it skips caching when it sees:
- the WordPress logged-in cookie (
wordpress_logged_in_*), - the WooCommerce cart indicator (
woocommerce_items_in_cart), - comment-author and other common session cookies.
This is why a freshly cached WordPress site doesn't show one visitor the wrong dashboard — logged-in users always get a fresh, uncached page from Apache. The trade-off is the obvious one: a site where most traffic is logged in (a membership site, a busy WooCommerce store) gets little benefit, because most requests bypass the cache by design.
Customise per-user without losing it on the next sync
Never edit /etc/nginx/conf.d/users/<username>.conf directly — cPanel regenerates it and your changes vanish. Instead, drop include files that survive regeneration:
/etc/nginx/conf.d/users/<username>/*.conf— applies to all of that user's server blocks./etc/nginx/conf.d/users/<username>/<fqdn>/*.conf— applies to one domain only.
For example, to expose a cache-status header for a single site:
# /etc/nginx/conf.d/users/jsmith/shop.example.com/cache-debug.conf
add_header X-Cache-Status $upstream_cache_status always;
Then test the config and reload:
nginx -t && systemctl reload nginx
Global tweaks belong in /etc/nginx/conf.d/server-includes/ or are driven by the scripts under /etc/nginx/ea-nginx/config-scripts/global/, regenerated with /usr/local/cpanel/scripts/ea-nginx config --all.
Clear the cache
When a site shows stale content, clear just that user's cache rather than nuking the lot. The reliable, version-proof method is to remove the user's cache directory and reload:
rm -rf /var/cache/ea-nginx/proxy/jsmith/*
systemctl reload nginx
Account holders can do this themselves without root: cPanel exposes a Cache Manager interface in the user's cPanel where they clear their own Nginx cache with one click. Point clients there instead of handling purge requests by hand. For WordPress sites that change content constantly, install the Nginx Helper plugin and have it purge on publish — it writes to the same per-user cache path.
When EA-Nginx is the wrong tool
Be honest about the ceiling. EA-Nginx microcaching is excellent for high-traffic anonymous content — news sites, brochure sites, blogs. It does little for sites where users are logged in most of the time, and it is not as deeply integrated with WordPress as LSCache on LiteSpeed, which can cache for logged-in users via ESI and ships an object cache. If your bottleneck is PHP execution rather than front-end concurrency, tune your PHP-FPM pools and add a Redis object cache before reaching for more front-end caching. And if Apache itself is the constraint, check your Apache MPM and MaxRequestWorkers first — Nginx in front of a misconfigured Apache just moves the queue.
EA-Nginx needs no separate license; it's part of every cPanel & WHM license. For volume licensing across a fleet, see pricing or contact us.