Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Put Varnish in front of the WordPress web server, move Apache or Nginx to an origin-only port such as 8080, and let W3 Total Cache (W3TC) trigger cache invalidation when content changes. The setup works only when three pieces agree: the port map, the Varnish purge policy, and the rules that keep private or personalized responses out of the shared cache.
This guide shows a self-managed configuration and identifies the hosting-specific settings you must verify when Varnish is managed for you.
Understand the request path before changing settings
A browser should reach Varnish first. Varnish stores eligible responses and serves later anonymous requests without asking WordPress every time. Apache or Nginx remains the origin web server, but it listens on an internal or alternate port instead of owning the public HTTP port.
W3TC runs inside WordPress. It creates WordPress-side caches and, through its reverse-proxy integration, can request that Varnish remove URLs after a post, page, theme, or plugin changes. Varnish decides what can be stored and served; WordPress must tell it when stored content is no longer valid. WordPress Developer Resources describes the combination this way: Varnish cache is very powerful when used with a WordPress caching plugin such as W3TC.
#1 Best Overall
| Component | Primary job | What it must know |
|---|---|---|
| Varnish | Reverse proxy and shared page cache | Origin address, backend port, cache rules, purge authorization, and original request scheme |
| Apache or Nginx | Origin web server that runs PHP and serves uncached requests | Its listener and virtual hosts must use the origin port, commonly 8080 in the vendor example |
| W3 Total Cache | WordPress cache layers and purge controls | Enabled cache methods, Varnish address, and exclusions for dynamic responses |
| WordPress | Application that generates content and initiates invalidation | Correct site URL, cookies, redirects, and awareness of HTTP versus HTTPS |
Check topology and prerequisites
Varnish can run on the same machine as WordPress or on a separate proxy host. On one server, Varnish usually binds the public port and forwards to 127.0.0.1:8080. On separate machines, the VCL backend points to the origin host’s private address and port. Confirm which design your host supports before editing anything.
- Obtain administrator or root access sufficient to edit the web-server listener and Varnish configuration.
- Confirm the W3TC administrator settings and the address that Varnish exposes for purge requests.
- Back up the Apache or Nginx configuration, virtual-host files, and the active VCL before changing ports.
- Record where TLS terminates: at Varnish, a load balancer, a hosting provider, or the origin server.
- Know the actual origin port if your provider does not use 8080; the number is an example, not a protocol requirement.
Have a rollback plan. A listener typo can make the origin unreachable even when WordPress itself is healthy, so keep an existing console or out-of-band access method available.
Move Apache or Nginx behind Varnish
Varnish Software’s tutorial uses port 8080 for the origin. Adapt the same pattern to your deployment and change every relevant virtual host, not just the default site.
| Origin server | Typical change | After the edit |
|---|---|---|
| Apache | Change Listen 80 to Listen 8080 and change each <VirtualHost *:80> to <VirtualHost *:8080>. |
Validate configuration, then restart Apache. |
| Nginx | Change listen 80; to listen 8080; in each applicable server block. |
Run a configuration test, then reload or restart Nginx. |
| Varnish | Bind the public HTTP port and forward to the origin port defined in VCL. | Restart or reload Varnish after validating VCL syntax. |
- Stop or drain public traffic if your deployment procedure requires it.
- Edit the Apache or Nginx global listener and every site or virtual-host definition that currently claims port 80.
- Check that no other service still needs the public port on the same address.
- Validate the web-server configuration with the platform’s normal test command.
- Restart the origin server and request it directly on the new port from the local host or an allowed management network.
- Only after the origin responds correctly, configure Varnish to forward to that port and start Varnish on the public listener.
If the origin uses a remote machine, replace the loopback address in the backend definition with the origin’s private or routable address and allow the port through the appropriate firewall. Do not expose an administrative origin port to the internet unless your architecture explicitly requires it.
Create the Varnish backend and purge ACL
Edit /etc/varnish/default.vcl or the VCL file used by your service. The following vendor-style baseline assumes a local origin on port 8080:
backend default {
.host = "127.0.0.1";
.port = "8080";
}
acl purge {
"localhost";
"127.0.0.1";
"::1";
}Change .host and .port when the origin is remote or uses another port. The purge ACL is a security boundary: it limits which clients may submit invalidation requests. Add only trusted proxy or application addresses. Never replace it with an unrestricted network range simply to make a purge test pass.
The same VCL pattern commonly performs four normalization tasks:
- removes an empty query string so a URL with a trailing question mark does not create a needless variant;
- sorts query parameters so equivalent parameter orders can share a cache entry;
- unsets the
Proxyheader, reducing exposure to legacy proxy-header behavior; and - sets
X-Forwarded-Protoaccording to whether the client connection was HTTP or HTTPS.
Keep those behaviors unless your infrastructure documents a reason to vary them. Query normalization must not erase parameters that change content, permissions, language, or tracking behavior in a way that would mix responses.
Install a purge path that WordPress can reach
Varnish can store a response, but it does not know that an editor changed a post unless WordPress sends an invalidation request. Varnish Software’s tutorial uses the Proxy Cache Purge plugin, which sends an HTTP PURGE request; the VCL receives that method and processes it when the client matches the purge ACL.
W3TC’s reverse-proxy integration can also expose Varnish purge controls. Whichever method you choose, verify both halves:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →- WordPress must actually issue a purge after the relevant save, publish, or setting change.
- Varnish must accept the request from the sender’s address and remove the intended object or objects.
A successful WordPress save with no matching VCL rule leaves stale pages in Varnish. Conversely, a permissive VCL rule with no WordPress trigger means editors must purge manually.
Configure W3 Total Cache in WordPress
Open Performance > General Settings in the WordPress administrator. The exact controls can vary by W3TC release and hosting integration, but the decisions below are stable.
Enable page cache deliberately
Turn on Page Cache and select a storage method supported by the host. Disk: Enhanced is a common choice when no memory-backed page-cache service is available. If your host offers a compatible object or database service, configure those layers separately; do not enable a backend that is not installed or reachable.
Choose database, object, and browser cache backends
Cloudways’ documented example enables Page Cache with Disk: Enhanced, Database Cache with Memcached, Object Cache with APC/APCu, and Browser Cache. Treat this as a hosting-specific example rather than a universal recipe. Memcached, APC, and APCu availability depends on the server image, PHP version, and provider configuration.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| W3TC area | Safe decision rule | Example from a provider workflow |
|---|---|---|
| Page Cache | Enable only after confirming the storage method and the pages that may be public. | Disk: Enhanced |
| Database Cache | Use a reachable database-cache backend; measure whether it helps your workload. | Memcached |
| Object Cache | Use the object-cache extension actually installed on the server. | APC/APCu |
| Browser Cache | Enable headers appropriate to your release and asset-update process. | Enabled in the provider example |
Enable reverse-proxy purging
In W3TC’s Reverse Proxy section, enable Varnish cache purging and enter the Varnish server address. A managed host may require a provider-specific port. Cloudways documents an SSL setup in which the Varnish server entry includes port 8080; do not copy that number unless the provider confirms it for your application.
If Varnish is disabled at the hosting layer, W3TC’s reverse-proxy fields cannot make it appear. Enable the service first, then use the address and port supplied by the host.
Decide on Page Cache Compatibility mode
W3TC’s official documentation says the advanced Compatibility mode option is disabled by default and highly recommended for interoperability with WordPress. The same documentation reports that disk-enhanced page-cache performance in its load tests can decrease by about 20% at scale when Compatibility mode is enabled. That is a vendor-reported test result, not a guaranteed change on every site. Use it when compatibility problems justify the trade-off, then measure your own response times and origin load.
Exclude private and dynamic responses
Shared page caching is appropriate for an anonymous visitor receiving the same public HTML as other anonymous visitors. It is unsafe when the response contains identity, cart state, account data, a nonce, or a form result. Configure exclusions in W3TC and, where necessary, in Varnish VCL.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Logged-in users and administrators.
- Commenters whose cookies personalize the page.
- Cart, checkout, payment, order, and account pages.
- Form display pages when the form plugin creates user-specific tokens or responses.
- POST requests and endpoints that process submissions.
- Preview URLs, password-protected content, and edit or customize screens.
- REST, AJAX, webhook, and other application endpoints that return user-specific data.
- Any URL whose output varies by cookie, authorization header, geolocation, membership, or experiment assignment.
W3TC documentation specifically advises marking form pages as Never cache. Start with a conservative exclusion list and relax it only after inspecting the response body and headers for anonymous and authenticated sessions.
Make HTTPS and scheme forwarding consistent
Decide where TLS terminates and preserve that fact to the origin. When a client connects over HTTPS, the Varnish configuration should set X-Forwarded-Proto: https; for plain HTTP it should pass http. WordPress, redirects, cookies, canonical URLs, and cache keys must all agree with the forwarded scheme.
- Set WordPress Address and Site Address to the intended public scheme and hostname.
- Configure the TLS terminator or Varnish to forward the original scheme in
X-Forwarded-Proto. - Ensure the origin trusts that header only from your proxy, not from arbitrary internet clients.
- Check that HTTP-to-HTTPS redirects do not loop when the origin receives a request that was originally HTTPS.
- Verify that secure cookies remain secure and that Varnish does not serve an HTTPS-generated response to an HTTP request or vice versa.
Managed providers may use a non-obvious backend port even when visitors use standard HTTPS. Use the provider’s documented Varnish address and port in W3TC rather than assuming the public port.
Use a predictable purge and verification workflow
After changing W3TC settings, VCL, themes, plugins, or published content, clear both application-side and Varnish-side caches when the change affects generated HTML. Then test behavior, not just a button state.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors- Save the WordPress or server change and trigger the configured W3TC or purge-plugin invalidation.
- Purge any remaining W3TC page-cache entries through the Performance menu.
- Request a public URL anonymously twice. The first request may populate cache; the second should show the cache status your platform exposes.
- Open the same URL while logged in and confirm that the response is private or bypasses shared cache.
- Submit a form or exercise a cart or checkout flow in a test account. Confirm that tokens, redirects, and account data are not reused across sessions.
- Edit or publish a post, purge it, and request the exact permalink. Confirm that the new title, content, and timestamps appear.
- Inspect response headers and origin logs. Record observed cache status and timings instead of claiming a universal speed increase.
| Test | Expected result | If it fails |
|---|---|---|
| Anonymous request repeated | Second response is served from the intended cache layer, when the URL is cacheable. | Check VCL cache conditions, cookies, query normalization, and backend reachability. |
| Logged-in request | Bypasses shared page cache or receives a clearly private response. | Exclude authentication and personalization cookies in W3TC and VCL. |
| Newly edited permalink | Updated content appears immediately after purge. | Check the WordPress trigger, purge ACL, HTTP method, and Varnish logs. |
| HTTPS request | No redirect loop; scheme and secure-cookie behavior remain correct. | Inspect TLS termination and X-Forwarded-Proto handling. |
| Form or checkout | Tokens and submitted data remain session-specific. | Mark the route Never cache and bypass by method or cookie. |
Troubleshoot common failures
The site returns a 502 or connection error
Check that Apache or Nginx is listening on the port in VCL, that the address is reachable from the Varnish host, and that a firewall allows the connection. Confirm that every virtual host was moved to the origin port. A service can be running while still rejecting the hostname or port Varnish sends.
Old content remains after publishing
Determine whether W3TC sent a purge and whether Varnish accepted it. Review the purge ACL for the actual source address; a container, load balancer, or separate proxy may not appear as localhost. Confirm that the request uses the method your VCL handles and that the URL or ban expression matches the cached object.
Personalized content appears for another visitor
Immediately bypass or purge the affected objects. Then identify the cookie, authorization header, query parameter, or endpoint that caused variation. Exclude logged-in and personalized requests in both W3TC and VCL, and test with two independent browser sessions before re-enabling caching.
HTTPS redirects loop
The origin probably sees HTTP after TLS terminated upstream and redirects repeatedly. Set and trust X-Forwarded-Proto from the proxy, and make sure WordPress’s public site URL uses HTTPS.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Cache never becomes a hit
Inspect response headers and VCL conditions for cookies, authorization, non-GET methods, set-cookie responses, or a no-cache directive. A conservative rule may be working as designed. Remove exclusions one at a time only when the response is demonstrably public.
Choose self-managed or managed Varnish
The same WordPress settings can sit on very different operational foundations. Compare the responsibilities before selecting an architecture.
| Decision axis | Self-managed Varnish | Managed hosting with Varnish |
|---|---|---|
| Control | Full control of VCL, listeners, ACLs, and backend ports. | Provider controls some ports, templates, and reload procedures. |
| Invalidation | You connect W3TC or a purge plugin to your ACL and monitor failures. | Confirm that the provider exposes a reachable purge address and supports W3TC controls. |
| Dynamic-content safety | You maintain exclusions and test every application change. | Provider defaults may help, but your commerce and form routes still require testing. |
| TLS and networking | You design termination, forwarding headers, firewall rules, and certificates. | Use the provider’s documented scheme and backend-port requirements. |
| Operations | You handle upgrades, monitoring, rollback, and incident response. | The provider handles infrastructure maintenance, while application cache rules remain your responsibility. |
Maintain the configuration safely
- Keep versioned copies of VCL, web-server listeners, and W3TC settings.
- Validate configuration syntax before every reload.
- Test publishing, login, forms, checkout, and HTTPS after plugin, theme, PHP, or provider changes.
- Review purge ACL members whenever network topology changes.
- Monitor origin error rates, cache status headers, and purge failures rather than relying on cache-hit percentage alone.
- Document the exact public listener, origin port, TLS terminator, and rollback command for the next administrator.
A reliable installation is therefore more than enabling two checkboxes. Varnish must reach the correct origin, W3TC must be able to authorize invalidation, and every private response must be excluded. Once those conditions are verified, anonymous pages can be cached aggressively while authenticated and transactional traffic continues to execute in WordPress.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
