How To Install Varnish on Manjaro

Varnish Cache stands as one of the most powerful HTTP accelerators available for modern web applications. This open-source reverse caching proxy significantly reduces server load while delivering lightning-fast page loading times to end users. Web applications handling high traffic volumes benefit tremendously from Varnish’s ability to cache HTTP responses and serve them without hitting the backend server repeatedly.

Manjaro Linux, built on the robust Arch Linux foundation, provides an excellent platform for deploying Varnish Cache. The combination offers system administrators and DevOps engineers a cutting-edge caching solution with the stability and ease of use that Manjaro delivers. Performance improvements of 300-1000x are commonly reported when Varnish is properly configured.

This comprehensive guide walks through every step of installing and configuring Varnish Cache on Manjaro Linux. The tutorial covers installation procedures, VCL configuration, backend server setup, performance optimization, and troubleshooting strategies. By the end, a fully functional Varnish caching layer will accelerate web application delivery.

What is Varnish Cache?

Definition and Core Functionality

Varnish Cache functions as a web application accelerator specifically designed for content-heavy dynamic websites and APIs. It operates as a reverse proxy cache that sits between clients and web servers, intercepting HTTP requests before they reach the backend infrastructure. When properly configured, Varnish stores copies of HTTP responses in memory, enabling it to serve subsequent identical requests directly from cache without engaging backend resources.

The architecture differs fundamentally from traditional caching solutions. Varnish runs entirely in memory rather than relying on disk storage, which explains its exceptional speed characteristics. The software was designed from the ground up to handle modern web traffic patterns, with a focus on flexibility through the Varnish Configuration Language.

Key Features and Benefits

Varnish Cache delivers multiple powerful capabilities beyond basic HTTP caching. The reverse proxy functionality includes request anonymization, GZIP compression, and sophisticated load balancing across multiple backend servers. These features make Varnish suitable for enterprise-level deployments serving millions of requests daily.

The Varnish Configuration Language (VCL) provides unprecedented flexibility in defining caching behavior. VCL allows administrators to write custom logic for determining what gets cached, for how long, and under what conditions. This domain-specific language compiles to C code and then to binary, ensuring maximum performance without sacrificing configurability.

Edge Side Includes (ESI) support enables caching of page fragments independently, which proves invaluable for websites with mixed static and dynamic content. HTTP/2 support ensures compatibility with modern web standards. Additionally, Varnish provides inherent DDoS protection by absorbing traffic spikes through its caching layer, preventing backend servers from becoming overwhelmed.

Performance metrics demonstrate Varnish’s effectiveness. Cache hit rates above 70% are typical, with many implementations achieving 85-95% hit rates. Time To First Byte (TTFB) reductions of 90% or more are commonly observed. These improvements translate directly to reduced infrastructure costs and enhanced user experience.

Understanding Manjaro and Arch Linux Compatibility

Manjaro Linux derives from Arch Linux, maintaining full compatibility with Arch repositories and packages. This relationship proves advantageous when installing Varnish, as packages built for Arch Linux work seamlessly on Manjaro systems. The Arch User Repository (AUR) and official Extra repository both remain accessible to Manjaro users.

Varnish Cache resides in the Extra repository, ensuring easy installation through Manjaro’s package manager without requiring manual compilation or third-party repositories. The rolling release model of both distributions means access to recent Varnish versions, typically within days or weeks of upstream releases.

Pacman, the package manager shared between Arch and Manjaro, handles dependency resolution automatically during Varnish installation. This streamlined approach contrasts with distributions requiring manual dependency management or complex repository configurations. Understanding this relationship clarifies why Arch Linux documentation applies equally to Manjaro installations.

Prerequisites

System Requirements

A functional Manjaro Linux installation with sudo or root privileges forms the foundation for this tutorial. The system should run a reasonably current Manjaro release to ensure compatibility with latest Varnish packages. While Varnish can operate on minimal hardware, production deployments benefit from adequate resources.

Memory requirements deserve careful consideration. A minimum of 2GB RAM suffices for testing and development environments, but production systems should provision 4GB or more. Varnish stores cached content in memory, so cache size directly correlates with RAM availability. Calculate required RAM by adding baseline system requirements plus desired cache size.

Disk space requirements remain modest since Varnish primarily uses memory. However, allocate sufficient space for log files, which can grow quickly on high-traffic systems. A few gigabytes typically suffice unless extensive logging is enabled.

Required Knowledge

Basic command-line proficiency proves essential for successful Varnish deployment. Comfort with editing configuration files, managing services, and interpreting log output will smooth the installation process. Familiarity with systemd service management helps when configuring Varnish startup behavior.

Understanding web server concepts provides important context. Knowledge of HTTP requests and responses, caching principles, and reverse proxy architecture helps when making configuration decisions. Prior experience with Nginx or Apache proves beneficial when integrating Varnish with backend servers.

Backend Web Server

Varnish requires a backend web server to cache responses from. Either Nginx or Apache should be installed and operational before proceeding with Varnish installation. The backend server configuration will be modified during setup to accommodate Varnish’s reverse proxy role. Alternatively, plan to install a web server as part of this tutorial.

Step 1: Updating System Packages

System package updates ensure compatibility and security before introducing new software. Manjaro’s rolling release model means regular updates deliver the latest packages and security patches. Synchronizing package databases and upgrading installed packages prevents dependency conflicts during Varnish installation.

Execute the following command to update the system:

sudo pacman -Syu

This command combines three operations. The -S flag synchronizes packages, -y refreshes package databases from repositories, and -u upgrades all installed packages to their latest versions. Pacman will display a list of packages to be updated and request confirmation before proceeding.

Download and installation times vary based on the number of updates available. Systems updated regularly complete this process quickly, while those behind on updates may require more time. Review the update list for kernel updates, which necessitate a system reboot to take effect. Reboot after updating if the kernel was upgraded:

sudo reboot

Wait for the system to restart before continuing to the next step.

Step 2: Installing Varnish Cache on Manjaro

Installation via Pacman

Varnish Cache installation on Manjaro follows the standard Pacman workflow. The package resides in the Extra repository, eliminating the need for additional repository configuration. A single command installs Varnish and all required dependencies.

Install Varnish with the following command:

sudo pacman -S varnish

Pacman resolves dependencies automatically and displays the complete installation list. Confirm the installation by pressing Enter when prompted. The installation process downloads the Varnish package and any missing dependencies, then installs them in the correct order.

The installation places Varnish binaries in system paths, creates necessary directories, and installs default configuration files. Installation typically completes within seconds on systems with adequate internet bandwidth.

Verifying Installation

Confirm successful installation by checking the Varnish version:

varnishd -V

This command displays detailed version information including the Varnish release number, VCL syntax version, and compilation details. Output similar to the following indicates successful installation:

varnishd (varnish-8.0.0 revision...)

The exact version number varies based on the current stable release in Manjaro repositories. Version 7.x or 8.x represents modern Varnish releases with full feature sets.

Understanding Varnish Directory Structure

Varnish installation creates several important directories and files. The primary configuration directory is /etc/varnish, which contains VCL configuration files and the secret key file. The main VCL file resides at /etc/varnish/default.vcl and defines caching behavior.

The Varnish daemon executable is located at /usr/sbin/varnishd. Systemd service configuration files exist in /usr/lib/systemd/system/ or /lib/systemd/system/, depending on the Manjaro release. The secret file at /etc/varnish/secret contains authentication credentials for the administrative interface.

Log files and runtime data are typically stored in /var/log/ and /var/run/, respectively. Understanding this structure helps when troubleshooting issues or customizing configurations.

Step 3: Installing and Configuring Backend Web Server

Option A: Installing and Configuring Nginx

Nginx serves as an excellent backend for Varnish due to its efficiency and low resource consumption. Install Nginx if not already present:

sudo pacman -S nginx

After installation, start and enable the Nginx service:

sudo systemctl start nginx
sudo systemctl enable nginx

The start command launches Nginx immediately, while enable configures it to start automatically on system boot. Verify Nginx is running by checking its status:

sudo systemctl status nginx

Nginx listens on port 80 by default, which conflicts with Varnish’s intended configuration. Varnish needs to listen on port 80 to serve cached content, while Nginx must move to a different port as the backend server. Change Nginx’s listen port to 8080:

sudo nano /etc/nginx/nginx.conf

Locate the listen directive within the server block. Modify it to listen on port 8080:

server {
    listen 8080;
    server_name localhost;
    # ... rest of configuration
}

Save the file and exit the editor. Restart Nginx to apply the changes:

sudo systemctl restart nginx

Verify Nginx now listens on port 8080:

ss -antpl | grep 8080

Test backend functionality by accessing it directly:

curl http://localhost:8080

The default Nginx welcome page should display, confirming the backend server operates correctly on port 8080.

Option B: Configuring Apache

Apache serves as an alternative backend if preferred. Install Apache with:

sudo pacman -S apache

Apache’s main configuration file is /etc/httpd/conf/httpd.conf. Edit this file to change the listening port from 80 to 8080:

sudo nano /etc/httpd/conf/httpd.conf

Find the Listen directive and modify it:

Listen 8080

Save changes and restart Apache:

sudo systemctl restart httpd
sudo systemctl enable httpd

Verify Apache listens on port 8080 and responds to requests.

Step 4: Configuring Varnish Runtime Parameters

Understanding Varnish Service Configuration

Systemd manages Varnish as a service, with configuration parameters defined in the service unit file. View the current service configuration:

sudo systemctl cat varnish

This command displays the complete service definition including default runtime parameters. Key parameters control listening addresses, backend servers, cache storage, and administrative interfaces.

Key Configuration Parameters

Varnish accepts numerous command-line parameters that control its operation. The most critical parameters include:

• -a specifies the listening address and port for client connections. Default is :6081, but production deployments typically use :80
• -s defines cache storage type and size. Format is storage_type,size, such as malloc,256m for 256MB memory cache
• -T sets the administrative interface address and port, defaulting to 127.0.0.1:6082
• -f specifies the VCL configuration file to load

Threading parameters control how Varnish handles concurrent requests. Default values work well for most deployments, but high-traffic sites may require tuning.

Modifying Service Configuration

The recommended method for modifying service parameters uses systemd override files, which preserve custom configurations during package updates. Create an override file:

sudo systemctl edit varnish

This command opens an editor with a blank override file. Add custom parameters in systemd service file format. To make Varnish listen on port 80 instead of 6081 and increase cache size to 512MB, add:

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -s malloc,512m -p feature=+esi_ignore_other_elements

The empty ExecStart= line clears the default value, while the second ExecStart= line sets the new command with desired parameters. Save and exit the editor.

Adjust cache size based on available system memory. A common guideline allocates 50-75% of available RAM to Varnish cache for dedicated caching servers. Systems running other services should allocate less.

Enabling Varnish Service

Configure Varnish to start automatically on system boot:

sudo systemctl enable varnish

This command creates necessary symlinks in systemd configuration directories, ensuring Varnish launches during system initialization.

Step 5: Understanding and Configuring VCL (Varnish Configuration Language)

Introduction to VCL

The Varnish Configuration Language (VCL) provides the primary mechanism for controlling caching behavior. VCL is a domain-specific language designed specifically for HTTP request manipulation and caching decisions. Unlike simple configuration files, VCL offers programming constructs including conditionals, regular expressions, and custom logic.

VCL code compiles to C and then to binary during loading, ensuring maximum performance. This compilation approach allows flexible configuration without sacrificing execution speed. The language feels similar to C or Perl, making it accessible to administrators with programming experience.

Built-in VCL logic handles common caching scenarios automatically. Custom VCL code augments rather than replaces this built-in logic, allowing administrators to override specific behaviors while leveraging default intelligence.

VCL File Structure

VCL files consist of subroutines that execute at different stages of request processing. The most important subroutines include:

• vcl_recv runs when a request is received, determining whether to cache, pass, or pipe the request
• vcl_backend_fetch modifies requests before sending them to backend servers
• vcl_backend_response processes responses from backend servers before caching
• vcl_deliver handles cached responses before delivering them to clients

Each subroutine can inspect and modify request or response properties, make caching decisions, and execute custom logic.

Configuring Backend in VCL

Edit the default VCL file to define the backend server:

sudo nano /etc/varnish/default.vcl

The file begins with a VCL version declaration followed by backend definitions. Add or modify the default backend to point to Nginx on port 8080:

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .connect_timeout = 600s;
    .first_byte_timeout = 600s;
    .between_bytes_timeout = 600s;
}

This configuration tells Varnish to send cache-missed requests to localhost port 8080, where Nginx listens. Timeout values define how long Varnish waits for backend responses before considering them failed.

Add health checks to monitor backend availability:

backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .probe = {
        .url = "/";
        .interval = 5s;
        .timeout = 1s;
        .window = 5;
        .threshold = 3;
    }
}

This probe configuration checks the backend every 5 seconds by requesting the root URL. The backend is considered healthy if at least 3 of the last 5 checks succeed.

Basic VCL Configuration Examples

Customize vcl_recv to control caching behavior. For example, bypass cache for admin pages:

sub vcl_recv {
    if (req.url ~ "^/admin") {
        return (pass);
    }
}

This code checks if the request URL starts with /admin and passes those requests directly to the backend without caching.

Cache static assets aggressively:

sub vcl_backend_response {
    if (bereq.url ~ "\.(jpg|jpeg|png|gif|css|js|ico)$") {
        set beresp.ttl = 7d;
    }
}

This configuration sets a 7-day TTL for image and static asset responses.

Add custom headers for debugging:

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
    set resp.http.X-Cache-Hits = obj.hits;
}

These headers allow verification that Varnish is caching correctly by showing whether responses came from cache.

VCL Best Practices

Use return(pass) sparingly, as it bypasses cache entirely. For content that shouldn’t be cached but doesn’t need to bypass Varnish completely, consider using short TTLs instead. This approach still benefits from connection pooling and backend load balancing.

Set appropriate TTL values based on content characteristics. Static assets can cache for days or weeks, while dynamic content may require TTLs measured in seconds or minutes. Balance freshness requirements against cache efficiency.

Handle cookies carefully, as they often prevent caching. Strip unnecessary cookies in vcl_recv to improve cache hit rates:

sub vcl_recv {
    if (req.url !~ "^/(login|cart|checkout)") {
        unset req.http.Cookie;
    }
}

Test VCL changes in development environments before deploying to production. Invalid VCL syntax prevents Varnish from starting, potentially causing service outages.

Step 6: Starting and Managing Varnish Service

Starting Varnish

Launch the Varnish service with systemd:

sudo systemctl start varnish

This command initiates the Varnish daemon, which loads the VCL configuration and begins listening for connections. Check service status to confirm successful startup:

sudo systemctl status varnish

Active status with “running” indicates Varnish started successfully. The status output includes the main process ID, memory usage, and recent log entries. Review any error messages carefully if the service fails to start.

Verifying Varnish is Listening

Confirm Varnish listens on the configured port:

ss -antpl | grep varnish

Expected output shows Varnish listening on port 80 (or 6081 if using defaults). The output displays both the cache-main process and the management process. Multiple varnishd processes are normal due to Varnish’s multi-process architecture.

Alternative verification using netstat:

netstat -tulpn | grep varnish

Both commands provide similar information about listening sockets and established connections.

Service Management Commands

Stop the Varnish service when needed:

sudo systemctl stop varnish

Restart Varnish to apply configuration changes:

sudo systemctl restart varnish

Restarting clears the cache entirely, as cached content exists only in memory. For configuration changes that preserve cache, use VCL reloading instead.

View service logs for troubleshooting:

sudo journalctl -u varnish -f

The -f flag follows log output in real-time. Remove this flag to view historical logs. Logs show startup messages, configuration issues, and service state changes.

Reload VCL without restarting:

sudo varnishadm vcl.load new_config /etc/varnish/default.vcl
sudo varnishadm vcl.use new_config

These commands load a new VCL configuration and activate it without clearing the cache.

Step 7: Testing Varnish Cache

Basic Functionality Testing

Test Varnish by requesting content through it:

curl -I http://localhost

If Varnish listens on port 80, this command goes through Varnish to the backend. Examine response headers for Varnish indicators. Look for headers like X-Varnish, Age, and any custom headers added in VCL.

Test from a remote client to verify external accessibility:

curl -I http://your_server_ip

Replace your_server_ip with the actual server IP address. This test confirms firewall rules permit traffic to Varnish.

Cache Hit/Miss Testing

Understanding cache behavior requires testing multiple requests for the same resource. Make an initial request:

curl -I http://localhost/

This first request typically results in a cache miss, as Varnish hasn’t cached the response yet. Check the X-Cache header (if configured in VCL) or observe the absence of an Age header.

Make a second identical request immediately:

curl -I http://localhost/

The second request should hit cache. The Age header appears, showing how many seconds the cached object has existed. If a custom X-Cache header was configured, it displays “HIT”.

Test different content types to verify caching rules work correctly:

curl -I http://localhost/image.jpg
curl -I http://localhost/style.css

Each content type should cache according to VCL rules.

Using Varnishlog

Varnishlog provides detailed real-time logging of Varnish operations. Run varnishlog to observe traffic:

sudo varnishlog

The output shows each transaction with detailed information about requests, backend communications, and caching decisions. Varnishlog output can be overwhelming initially but provides invaluable debugging information.

Filter logs for specific URLs:

sudo varnishlog -q "ReqURL ~ '/admin'"

This command displays only transactions involving URLs containing ‘/admin’. Filtering helps isolate specific requests when troubleshooting.

Using Varnishstat

Varnishstat displays cache statistics and performance metrics:

varnishstat

The interactive display updates continuously, showing counters for cache hits, misses, backend connections, and numerous other metrics. Press q to exit.

Key metrics to monitor include:

• MAIN.cache_hit: Number of requests served from cache
• MAIN.cache_miss: Number of requests that missed cache
• MAIN.cache_hitpass: Number of requests that passed through cache
• MAIN.backend_fail: Backend connection failures

Calculate hit rate with the formula: cache_hit / (cache_hit + cache_miss) × 100. Hit rates above 70% indicate effective caching, while rates above 85% represent excellent performance.

View specific counters:

varnishstat -f MAIN.cache_hit -f MAIN.cache_miss

This command displays only hit and miss counters, simplifying monitoring.

Step 8: Performance Optimization and Tuning

Cache Size Optimization

Cache size directly impacts performance and hit rates. Insufficient cache causes premature eviction of cached objects, reducing hit rates. Excessive cache allocation wastes memory and may cause system stability issues.

Determine appropriate cache size by analyzing content size and traffic patterns. Monitor cache evictions using varnishstat:

varnishstat -f LRU.nuked_objects

Frequent evictions (nuked objects) indicate insufficient cache size. Gradually increase cache allocation until evictions decrease to acceptable levels.

Memory storage (malloc) offers excellent performance for most deployments. File storage provides larger capacity but slower access times. Production systems typically use malloc storage for optimal performance.

Modify cache size by editing the systemd override file:

sudo systemctl edit varnish

Adjust the -s malloc,size parameter appropriately.

Monitoring Cache Performance

Regular performance monitoring ensures Varnish delivers expected benefits. Cache hit rate represents the primary metric for cache effectiveness. Monitor hit rates continuously and investigate when they drop below expected levels.

Track Time To First Byte (TTFB) improvements. Measure TTFB before and after Varnish deployment:

curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\n' http://localhost/

Cached responses should show dramatically reduced TTFB compared to backend responses.

Monitor backend health and connection counts. High backend connection counts may indicate cache misses or uncacheable content.

TTL Management

Time To Live (TTL) values control how long objects remain in cache. Longer TTLs improve cache efficiency but may serve stale content. Shorter TTLs ensure freshness at the cost of more backend requests.

Set default TTL in VCL:

sub vcl_backend_response {
    set beresp.ttl = 1h;
}

This configuration caches responses for 1 hour by default.

Override TTL for specific content types:

sub vcl_backend_response {
    if (bereq.url ~ "\.(jpg|png|gif)$") {
        set beresp.ttl = 7d;
    } elsif (bereq.url ~ "\.html$") {
        set beresp.ttl = 5m;
    }
}

Images cache for 7 days while HTML caches for only 5 minutes.

Advanced VCL Tuning

Implement cache purging for manual cache invalidation. Add purge ACL and subroutine:

acl purge {
    "localhost";
    "127.0.0.1";
}

sub vcl_recv {
    if (req.method == "PURGE") {
        if (!client.ip ~ purge) {
            return(synth(405, "Not allowed."));
        }
        return(purge);
    }
}

This configuration allows cache purging from localhost only. Purge specific URLs with:

curl -X PURGE http://localhost/page.html

Configure Edge Side Includes (ESI) for advanced caching of dynamic pages with static components:

sub vcl_backend_response {
    if (bereq.url == "/dynamic-page") {
        set beresp.do_esi = true;
    }
}

ESI allows caching page templates while fetching dynamic fragments separately.

Backend Health Checks

Robust health checking prevents serving errors when backends fail. Configure detailed probes in VCL:

backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .probe = {
        .request =
            "GET /health HTTP/1.1"
            "Host: localhost"
            "Connection: close";
        .interval = 5s;
        .timeout = 2s;
        .window = 10;
        .threshold = 5;
    }
}

This probe performs a dedicated health check request every 5 seconds. The backend is healthy if at least 5 of the last 10 checks succeed.

Monitor backend health:

sudo varnishadm backend.list

This command shows backend status and recent probe results.

Step 9: Troubleshooting Common Issues

Varnish Service Not Starting

Service startup failures typically result from configuration errors or port conflicts. Check service status for error messages:

sudo systemctl status varnish

View detailed logs:

sudo journalctl -xe -u varnish

The -xe flags show the most recent logs with explanatory text.

Common startup issues include:

Port conflicts occur when another service already listens on Varnish’s configured port. Identify the conflicting process:

sudo ss -antpl | grep :80

Either stop the conflicting service or configure Varnish to use a different port.

VCL syntax errors prevent service startup. Varnish refuses to start with invalid VCL, protecting against misconfigurations. Validate VCL syntax before starting:

sudo varnishd -C -f /etc/varnish/default.vcl

This command compiles VCL and displays errors without starting the service.

Permission issues may prevent Varnish from accessing configuration files or creating runtime directories. Verify file permissions:

ls -la /etc/varnish/

Configuration files should be readable by the varnish user.

Low Cache Hit Rate

Poor cache hit rates indicate caching inefficiency. Common causes include:

Cookie variations prevent caching of responses that differ only by cookies. Examine requests with varnishlog:

sudo varnishlog -g request -i ReqHeader -i Cookie

Strip unnecessary cookies in VCL to improve cachability.

Authorization headers typically make responses uncacheable. Avoid sending authorization headers for public content:

sudo varnishlog -i ReqHeader -I "Authorization"

Vary headers cause separate cache entries for different header combinations. Minimize Vary headers when possible.

Backend cache-control headers override VCL TTL settings. Check backend response headers:

curl -I http://localhost:8080/

Override backend cache directives in VCL when necessary.

Backend Connection Issues

Backend connection failures prevent Varnish from fetching content. Verify backend server accessibility:

curl http://localhost:8080/

This direct backend test bypasses Varnish entirely. If this fails, troubleshoot the backend server rather than Varnish.

Check VCL backend configuration accuracy. Verify the host and port match the actual backend configuration. Incorrect backend settings cause all requests to fail.

Timeout settings may be too restrictive for slow backends. Increase timeout values in VCL:

backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .connect_timeout = 10s;
    .first_byte_timeout = 30s;
    .between_bytes_timeout = 10s;
}

Monitor backend connections and failures:

varnishstat -f MAIN.backend_conn -f MAIN.backend_fail

High failure rates indicate backend problems.

VCL Configuration Errors

VCL syntax errors produce clear error messages during compilation. Common mistakes include:

Missing semicolons at statement ends cause syntax errors. VCL requires semicolons like C:

set beresp.ttl = 1h;  // Correct
set beresp.ttl = 1h   // Error: missing semicolon

Incorrect return statements in wrong subroutines fail compilation. Each subroutine accepts specific return values. return(hash) works in vcl_recv but fails in vcl_backend_response.

Typos in built-in variables cause errors. VCL variable names are case-sensitive and specific. beresp.ttl is correct while beresp.TTL or beresp.ttl_value fail.

Test VCL changes before deploying to production. Use a development environment or test VCL compilation without applying:

sudo varnishd -C -f /etc/varnish/default.vcl

Review compilation output for errors or warnings.

Performance Issues

Performance problems despite Varnish deployment indicate configuration issues. Identify bottlenecks systematically:

Memory exhaustion causes poor performance and high eviction rates. Monitor system memory:

free -h

Increase cache size if memory is available or reduce cache size if the system is swapping.

Thread pool exhaustion occurs under extreme load. Monitor thread statistics:

varnishstat -f MAIN.threads -f MAIN.threads_created -f MAIN.threads_failed

Adjust thread pool parameters if thread creation frequently occurs.

Backend overload causes slow responses despite effective caching. Monitor backend response times and consider scaling backend infrastructure.

Cache policy issues may prevent caching of high-traffic resources. Review VCL and identify uncached popular content:

sudo varnishtop -i ReqURL

This command shows most-requested URLs. Ensure popular URLs cache effectively.

Port Conflicts

Port conflicts prevent Varnish from binding to its configured port. Identify processes using desired ports:

sudo ss -antpl | grep :80

Common conflicts occur with web servers still listening on port 80. Ensure the backend web server moved to port 8080 successfully.

Firewall rules may block Varnish ports. Check firewall status:

sudo ufw status

Allow necessary ports if using UFW:

sudo ufw allow 80/tcp

SELinux policies (if enabled) may restrict port binding. Manjaro typically doesn’t use SELinux, but check if issues persist.

Step 10: Security Best Practices

Securing Varnish deployments protects both cached content and backend infrastructure. Restrict access to the administrative interface by binding it to localhost only. The default configuration binds to 127.0.0.1:6082, preventing remote access.

Protect the secret file containing authentication credentials:

sudo chmod 600 /etc/varnish/secret
sudo chown varnish:varnish /etc/varnish/secret

These commands restrict secret file access to the varnish user only.

VCL security considerations include validating and sanitizing input. Avoid exposing sensitive backend information in VCL or cached headers. Strip backend-generated headers that reveal server details:

sub vcl_deliver {
    unset resp.http.Server;
    unset resp.http.X-Powered-By;
}

Varnish provides inherent DDoS mitigation through caching. Cached responses serve quickly even during traffic spikes, preventing backend overload. However, implement rate limiting in VCL for additional protection against abuse.

SSL/TLS termination requires a separate component, as Varnish doesn’t handle encryption directly. Common architectures place Nginx or Apache in front of Varnish for SSL termination, or behind Varnish for SSL backend connections.

Implement access control lists (ACL) for sensitive operations:

acl admin {
    "10.0.0.0"/8;
    "192.168.0.0"/16;
}

sub vcl_recv {
    if (req.url ~ "^/admin" && !client.ip ~ admin) {
        return(synth(403, "Access denied"));
    }
}

This configuration restricts admin URLs to specific IP ranges.

Protect sensitive backend URLs from caching. Ensure authentication-required resources never cache:

sub vcl_recv {
    if (req.http.Authorization || req.http.Cookie ~ "session") {
        return(pass);
    }
}

Requests with authentication headers bypass cache entirely.

Congratulations! You have successfully installed Varnish. Thanks for using this tutorial for installing the Varnish HTTP Cache on your Manjaro Linux system. For additional help or useful information, we recommend you check the official Varnish website.