Varnish Cache sits between the public internet and your web origin, serving eligible responses from memory instead of sending every request to Nginx, Apache, or your application. On a VPS, a reliable deployment means installing a supported package, making Varnish the public listener, pointing its backend at the origin’s private port, and writing a cache policy that never stores private or administrative responses accidentally.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
This guide uses the official Debian/Ubuntu installation flow in detail and explains the corresponding choices for Red Hat Enterprise Linux-compatible systems. Port numbers, storage sizes, package versions, and unit-file contents below are examples; verify the current repository instructions and adapt them to your distribution, VPS memory, and origin configuration.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What Varnish changes in a VPS architecture
Without Varnish, a typical VPS exposes Nginx or Apache directly on TCP port 80 (and usually 443 through TLS termination). With Varnish, the request path becomes:
- The client connects to Varnish on the public HTTP port.
- Varnish checks its in-memory object store and applies the VCL policy.
- A cache hit is delivered immediately.
- On a miss, Varnish fetches the object from the configured backend, stores it when policy permits, and returns it to the client.
The packaged configuration commonly listens on port 6081. The reverse-proxy example in the official guide changes that listener to port 80, while the origin remains on an internal port such as 8080. Those values are examples, not performance targets. Choose ports that match the services already running on your VPS.
What belongs behind Varnish
Your backend can be Nginx, Apache, a game-community application, or another HTTP origin. Bind the origin to localhost or a private interface whenever possible. If the origin remains publicly reachable on the same address, clients can bypass Varnish and defeat your cache and access-control rules.
Check the VPS before installing
- Identify the distribution and release with your provider’s console or the distribution’s release-information command. Use the official Varnish repository path for that exact release.
- Record which process currently owns ports 80 and 443. Do not move a service until you know how its TLS and virtual-host configuration is handled.
- Confirm the origin address and port. The sample backend in the standard VCL points to
127.0.0.1:8080; it is correct only when your origin actually listens there. - Reserve memory for the operating system and origin before allocating Varnish storage. A
malloc,2gstore consumes up to about 2 GiB for cache objects in the example configuration, so it should not be copied onto a small VPS without checking available RAM. - Keep an administrative path available, such as the provider console or a second SSH session, in case a listener change prevents normal access.
Choose a package source and version
Varnish’s quick-start guidance advises using Varnish Cache 6.0 LTS as a stable, supported version. Repository contents and supported operating-system releases change, so check the current official installation index before adding a repository. The index separates Debian/Ubuntu instructions from Red Hat Enterprise Linux-compatible distributions and also has separate Docker and Kubernetes guidance.
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 →| Decision | Debian or Ubuntu | RHEL-compatible distribution |
|---|---|---|
| Repository | Register the Varnish repository and its signing key for the exact release. | Use the matching official repository instructions for your RHEL-compatible release. |
| Package manager | apt-get |
Use the package manager specified by the distribution’s official instructions. |
| Trust check | Verify the repository signing-key setup before updating package metadata. | Verify the repository and signing configuration before installing. |
| Compatibility | Match the repository to the VPS codename and architecture. | Match the repository to the RHEL-compatible major release and architecture. |
| Support expectation | Prefer the supported LTS line when you need long-lived maintenance. | Confirm which Varnish stream the vendor repository currently supports. |
Do not mix packages from unrelated distributions or copy a repository entry for a different release. A package that installs successfully can still carry incompatible systemd defaults or VCL modules.
Install Varnish on Debian or Ubuntu
1. Add the official repository and signing key
Follow the current official Debian/Ubuntu repository instructions for your release to register the Varnish package source and signing key. The exact repository address and key procedure are intentionally release-specific and can change. After the key and source are present, refresh the package index:
sudo apt-get update2. Install the package
sudo apt-get install varnishThe package normally installs a systemd unit, a default VCL file at /etc/varnish/default.vcl, and a conservative listener configuration. Inspect what was installed before changing it:
systemctl status varnish --no-pager
systemctl cat varnish
sudo sed -n '1,220p' /etc/varnish/default.vcl3. Install on a Red Hat Enterprise Linux-compatible VPS
Use the current official RHEL-compatible repository path for your exact release, then install Varnish with the distribution package manager specified there. Because repository names, signing steps, and supported release combinations change, do not reuse a Debian repository entry or assume that a unit file has the same defaults. After installation, inspect the unit and locate the packaged VCL in the same way as on Debian or Ubuntu.
Recommended Free Tools
Configure the systemd listener and cache storage
The packaged unit is commonly located at /lib/systemd/system/varnish.service. Treat that file as vendor-managed: upgrades can replace it. Make local changes with a full unit copy or a drop-in under /etc/systemd/system/varnish.service.d/.
Use a full unit copy when changing the command line
- Open the complete unit with
sudo systemctl edit --full varnish. - Find the existing
ExecStartline. Preserve the package’s other flags, and change the address option from the conservative listener (often:6081) to the public HTTP port you intend to use, commonly:80. - Set the storage argument to a size appropriate for the VPS, for example
-s malloc,2g. Leave headroom for the kernel, Varnish process, origin, TLS termination, and monitoring agents. - Save the unit and exit the editor.
If your distribution’s unit already separates arguments into an environment file, edit that file instead of duplicating the entire unit. The objective is the same: one unambiguous public listener and one storage definition.
Use a drop-in for narrowly scoped settings
Create a drop-in with sudo systemctl edit varnish when the package exposes a variable or option you only need to override. If you replace ExecStart in a drop-in, systemd requires an empty ExecStart= line first, followed by the complete replacement command. Copy the existing command from systemctl cat varnish and alter only the listener and storage flags; omitting a required flag can prevent startup.
Reload and enable the service
sudo systemctl daemon-reload
sudo systemctl enable varnish
sudo systemctl restart varnish
sudo systemctl status varnish --no-pagerRun daemon-reload after every unit edit. Enabling the service makes it start at boot; restarting applies the new command line and VCL. If status reports a bind error, another process still owns the selected port.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated 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 matchPut Nginx or Apache behind Varnish
Move the origin off the public listener
Configure Nginx, Apache, or your application server to listen on an internal port, then configure its virtual host to accept requests from Varnish. The official VCL sample uses:
backend default {
.host = "127.0.0.1";
.port = "8080";
}Change both values to the actual origin endpoint. If the origin listens on a private network address rather than localhost, use that address and ensure the VPS firewall permits Varnish to reach it. Keep the origin’s administrative interfaces off the public interface.
Preserve the original host and client information
Most web servers select a site by the Host header. Varnish normally forwards it, but confirm that your VCL and backend configuration do not overwrite it. If your application creates absolute links, login redirects, or audit records, configure it to understand the forwarded scheme and client address supplied by your front-end design. TLS is commonly terminated before Varnish or at another proxy; do not expose an unencrypted administrative endpoint merely to simplify the cache path.
Prevent an origin bypass
After moving the origin, restrict its firewall rules or listener address so ordinary internet clients cannot connect directly. Test from an external network: the public address should reach Varnish, while the origin’s private port should be unreachable except from the proxy and approved administration sources.
Build a safe default.vcl
VCL controls which requests are looked up, passed directly to the backend, stored, delivered, or invalidated. Start with a conservative policy, then relax it for pages you have verified as public and cacheable.
Backend definition
Replace the sample endpoint in /etc/varnish/default.vcl with your origin:
vcl 4.1;
backend default {
.host = "127.0.0.1";
.port = "8080";
}A backend hostname is resolved when VCL is compiled. If the hostname’s DNS address changes, reload or restart Varnish so the compiled backend is rebuilt; changing DNS alone does not guarantee that an already loaded VCL uses the new address.
Pass non-cacheable traffic
Only cache responses that are safe to share between visitors. A practical starting policy passes non-idempotent methods, authenticated requests, and session traffic:
sub vcl_recv {
if (req.method != "GET" && req.method != "HEAD") {
return (pass);
}
if (req.http.Authorization) {
return (pass);
}
if (req.http.Cookie ~ "session|logged_in") {
return (pass);
}
}Adjust the cookie expression to your application’s real session names. Passing all cookie-bearing requests is safer but can reduce the hit ratio; caching every request that happens to include a cookie can leak personalized content.
Set a bounded backend lifetime
Backend response headers should remain authoritative where possible. You can impose a modest upper or lower policy only after understanding the application’s headers. For example, a five-minute TTL may suit public, frequently changing pages, while static assets can use a longer application-controlled lifetime. Do not claim a universal hit ratio or speed-up: the result depends on URL mix, object sizes, origin latency, invalidation, and available memory.
Handle cookies and private responses explicitly
Responses carrying Set-Cookie, Cache-Control: private, or Cache-Control: no-store should generally bypass shared storage. If you override those signals, document the reason and test with two independent sessions. A cache configuration that looks correct for anonymous pages can expose account data when a login cookie is ignored.
Purge cached objects safely
Purge is an administrative operation. The Varnish security guidance strongly recommends restricting PURGE requests to trusted IP addresses or networks with a VCL access-control list.
Define a purge ACL and method handler
acl purge {
"127.0.0.1";
"203.0.113.10";
}
sub vcl_recv {
if (req.method == "PURGE") {
if (!(client.ip ~ purge)) {
return (synth(403, "PURGE not allowed"));
}
return (purge);
}
if (req.method != "GET" && req.method != "HEAD") {
return (pass);
}
}The address 203.0.113.10 is a documentation example. Replace it with the fixed management address or private network that should be allowed to purge, and remove any address you do not control. Never permit PURGE from all clients.
Issue a targeted purge
curl -X PURGE http://127.0.0.1/news/latestRun the command locally or from an ACL-approved host. A successful purge removes the selected object so the next eligible request fetches a fresh response. Purging a URL does not correct a bad backend response permanently; fix the origin or VCL rule as well.
Choose purge versus short TTLs
- Use targeted purges when editors or deployments know exactly which URLs changed.
- Use short TTLs when changes are frequent and an occasional stale response is acceptable.
- Use a deployment hook to purge affected paths, not the entire cache, when the changed-object list is reliable.
- For personalized or permission-sensitive pages, bypass shared caching instead of relying on frequent purges.
Apply VCL changes without losing control
- Edit
/etc/varnish/default.vcland save a copy of the previous working version. - Check the VCL syntax using the validation option provided by your installed Varnish package before restarting. If validation reports a line and column, correct that error first.
- Reload or restart Varnish through systemd so the new VCL is compiled. A DNS change also requires this reload because backend hostnames are resolved at compile time.
- Check
systemctl status varnishand the journal immediately after the change. - Send one anonymous request and one authenticated or session-bearing request, then confirm that only the intended response is cacheable.
Keep the last known-good VCL available. If a new policy fails to compile or causes unexpected passes, restore that file and restart before investigating more deeply.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Verify that the proxy is working
Confirm listeners and processes
sudo ss -ltnp | grep -E ':80|:6081|:8080'
sudo systemctl status varnish --no-pagerYou should see Varnish on the public listener, the origin on its private port, and no unintended second service competing for the same address. Seeing Varnish still on 6081 after editing the unit usually means the unit was not reloaded or the wrong service file was changed.
Inspect response headers
curl -I http://your-public-host.example/Repeat the request and inspect the headers your VCL or backend exposes. A first request is commonly a miss and subsequent requests may be hits, but header names and hit indicators depend on your configuration. Do not infer a performance improvement from one curl command; measure representative traffic only if you have a controlled benchmark.
Follow logs when a request fails
sudo journalctl -u varnish -b --no-pager
sudo varnishlog -g request
sudo varnishstatThe journal identifies startup, bind, and compilation failures. Request logging helps reveal why a request was passed, fetched, or synthesized. Statistics expose counters such as requests and object activity, but they are operational signals rather than a guarantee of user-visible speed.
Troubleshooting common failures
Varnish will not start: address already in use
Another service owns the configured listener. Use ss -ltnp to identify it, then either move that service to the origin port or choose a different Varnish listener. Do not stop a production web server until you have confirmed its replacement path and firewall rules.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsEvery request returns a backend error
- Verify that the origin is running and listening on the host and port in
default.vcl. - Test the origin locally with a direct HTTP request from the VPS.
- Check the origin’s virtual-host requirements, firewall rules, and access logs.
- Confirm that VCL was reloaded after changing the backend address.
Pages are stale or changes do not appear
Check the response’s cache headers and your VCL TTL rules. Purge the affected URL from an ACL-approved address, or wait for the documented TTL. If the origin emits a new URL for each deployment, purge the old path and ensure clients receive the new asset references.
Logged-in users see another user’s content
Stop serving the affected URL from cache immediately, purge it, and inspect the VCL conditions for authorization headers and session cookies. Add an explicit pass rule for every authentication mechanism used by the application. Test with two separate accounts before re-enabling caching.
Varnish uses too much memory
Reduce the malloc store to a value that leaves operating-system and origin headroom, then restart during a controlled maintenance window. A larger cache is not automatically better: objects that are rarely requested can evict useful content while increasing memory pressure.
Operational practices for a Linux VPS
Keep the proxy and origin boundaries clear
Document the public listener, private origin port, TLS termination point, and the addresses permitted to purge. Recheck these boundaries after provider migrations, IPv6 changes, or a web-server package upgrade.
Review cache policy when the application changes
New login flows, shopping carts, dashboards, preview modes, and API endpoints can invalidate an old VCL assumption. Treat each new cookie, authorization header, and response-control header as a cache-policy review item.
Plan upgrades and rollback
Record the installed Varnish version, repository source, unit overrides, and VCL revision. Test upgrades on a staging VPS when possible. Keep the previous package and configuration rollback procedure documented, because repository versions and default unit contents can change over time.
Use the right invalidation model
| Situation | Safer starting choice | Main trade-off |
|---|---|---|
| Public pages change unpredictably | Short TTL with conservative caching | More origin requests and lower freshness delay |
| Deployments know changed URLs | Targeted PURGE from trusted networks | Requires reliable deployment automation and ACL maintenance |
| Personalized or authenticated pages | Pass or bypass shared storage | Lower cache coverage but reduced data-leak risk |
| Large static assets | Origin-controlled long lifetime after versioned filenames | Old files remain cached until expiry or purge |
Final deployment checklist
- The repository and signing key match the VPS distribution and release.
- The installed Varnish version is an intentionally supported stream, such as the 6.0 LTS line recommended in the quick-start guidance.
- Varnish owns the public HTTP listener, and the origin listens on a private or localhost port.
- The backend host and port in
default.vclmatch the running origin. - The malloc size leaves memory for the operating system and origin.
- Systemd was reloaded after unit edits, and the service is enabled for boot.
- Authenticated, session-bearing, and administrative requests are passed or explicitly handled.
- PURGE is restricted with an ACL to trusted addresses.
- DNS changes for backend hostnames are followed by a VCL reload.
- You have tested an anonymous request, a personalized request, an origin failure, and a rollback path.
When these checks pass, Varnish is acting as a controlled reverse proxy rather than an opaque extra layer: public traffic reaches one listener, cacheable responses are stored within a deliberate memory budget, private traffic bypasses shared storage, and invalidation remains an authenticated administrative action.
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.
Free tools Windows power users keep installed
One-click scans. No signup required.
