> For the complete documentation index, see [llms.txt](https://docs.glesys.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.glesys.com/products/compute/guides-for-server-management/install-varnish-for-wordpress.md). # Install Varnish for WordPress *** Varnish is a front‑end cache, also known as a "web application accelerator". The software acts as a reverse proxy and caches content between the user and the web server to speed up access to your website, especially during high-traffic periods. In this guide, we'll walk you through installing Varnish, optimized for WordPress, on Debian 13. A website built with WordPress can be cached effectively when its content does not need to be updated "live" but can be delayed by 2–5 minutes before the visitor sees the new material. In this way, the page does not have to be regenerated for every page load. In this example, we'll walk you through a standard Varnish installation on a server running Debian 13 (note that Varnish does not have to run on the same server as the web server). The default configuration will cache all content for 120 seconds or for as long as your `Cache‑Control` header permits. ## Installation In Debian 13, you install Varnish using `apt`: {% code title="Command" %} ``` sudo apt install varnish ``` {% endcode %} Varnish listens by default on port 6081, but to use it as a cache for web pages, you want to change this so that it listens on port 80. This can be addressed by creating a new service in *systemd*. Be sure to verify that no other web server is running on port 80 before you make this change. {% code title="Multiple commands" %} ``` sudo cp /lib/systemd/system/varnish.service /etc/systemd/system/ sudo vim /etc/systemd/system/varnish.service ``` {% endcode %} Change the ExecStart so that you replace 6081 with 80. That is, change this section: {% code title="Snippet from /etc/systemd/system/varnish.service" %} ``` ExecStart=/usr/sbin/varnishd \ -j unix,user=vcache \ -F \ -a :6081 \ -T localhost:6082 \ -f /etc/varnish/default.vcl \ -S /etc/varnish/secret \ -s malloc,256m ``` {% endcode %} Into this: {% code title="Snippet from /etc/systemd/system/varnish.service" %} ``` ExecStart=/usr/sbin/varnishd \ -j unix,user=vcache \ -F \ -a :80 \ -T localhost:6082 \ -f /etc/varnish/default.vcl \ -S /etc/varnish/secret \ -s malloc,256m ``` {% endcode %} It’s also in this file that you can increase the amount of RAM Varnish is allowed to use for its cache. To change it, simply replace `-s malloc,256m` with `-s malloc,1024m` **to raise the limit to 1024 MB**. Then, we need to reload the systemd daemon and restart Varnish for the changes to take effect. {% code title="Multiple commands" %} ``` sudo systemctl daemon-reload sudo systemctl restart varnish ``` {% endcode %} ## Configuration Varnish has its own configuration language called VCL (Varnish Configuration Language). By default, it ships with an empty configuration where you can specify which backend server Varnish should cache. If you don’t set any caching rules, Varnish will fall back to its built‑in defaults, which cache everything except: * HTTP methods other than `GET` and `HEAD` * Users authenticated with `HTTP Authorization` * Requests or responses that contain cookies What gets cached follows the `Cache‑Control` header in the HTTP response from the application. If no header is set, Varnish will use a Time‑to‑Live (TTL) of 120 seconds. The default configuration that comes with Debian 13 looks like this, and is found at `/etc/varnish/default.vcl`: {% code title="/etc/varnish/default.vcl" %} ``` vcl 4.1; # Default backend definition. Set this to point to your content server. backend default { .host = "127.0.0.1"; .port = "80"; } sub vcl_recv { # Happens before we check if we have this in cache already. # # Typically you clean up the request here, removing cookies you don't need, # rewriting the request, etc. } sub vcl_backend_response { # Happens after we have read the response headers from the backend. # # Here you clean the response headers, removing silly Set-Cookie headers # and other mistakes your backend does. } sub vcl_deliver { # Happens when we have all the pieces we need, and are about to send the # response to the client. # # You can do accounting or modifying the final object here. } ``` {% endcode %} To ensure Varnish connects correctly to your backend, you need to update the IP address and port number in the configuration to point to your web server. The section you need to update is this: {% code title="Snippet from /etc/varnish/default.vcl" %} ``` backend default { .host = "127.0.0.1"; .port = "80"; } ``` {% endcode %} Varnish decides whether a request is already in the cache by using a hash. You can control this hash with the `vcl_hash` function. By default, the hash is based on the URL, the hostname, or the server’s IP address. Note that this hashing occurs after Varnish has determined that the request is eligible for caching. Because of this, if you are not logged into WordPress and you have no plugins that use cookies, Varnish’s default settings will provide a 120‑second cache for each page for all visitors. Remember to restart Varnish after you change the configuration. You restart Varnish with: {% code title="Command" %} ``` sudo systemctl restart varnish ``` {% endcode %} ## How do you know if the content is being cached? Varnish adds an HTTP header called `X‑Varnish`, which reveals whether the request passed through Varnish and contains the ID of the cached object. In addition, an `Age` header is set, indicating how old the cached object is. You can use cURL with the `-i` options to show all headers. For example: {% code title="Command" %} ``` curl -i example.com ``` {% endcode %} If the Varnish has served the request, you should see something similar to this: {% code title="Output" %} ``` HTTP/1.1 200 OK Date: Fri, 31 Oct 2025 17:40:41 GMT Server: Apache/2.4.65 (Debian) Last-Modified: Sat, 25 Oct 2025 17:46:19 GMT Vary: Accept-Encoding Content-Type: text/html X-Varnish: 32779 17 Age: 53 Via: 1.1 varnish (Varnish/7.1) ETag: W/"f90-641ff3e654f4b-gzip" Accept-Ranges: bytes Content-Length: 3984 Connection: keep-alive ``` {% endcode %} Here you can see that Varnish is used (`X-Varnish: 32779 17` and `Via: 1.1 varnish (Varnish/7.1)`). You also see that this page has been sitting in the cache for 53 seconds (`Age: 53`). ## Further reading Official website for Varnish HTTP Cache: . User guide for VCL: . ## Need help with Varnish? With our service, Manage Hosting, we can help you set up and manage Varnish. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.glesys.com/products/compute/guides-for-server-management/install-varnish-for-wordpress.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.