Squid Proxy: Why Nothing is Cached After Enabling or Disabling

Squid Proxy appears to cache nothing because the cache directory lacks proper permissions, the storage size is insufficient, or the cache_dir directive is misconfigured. Additionally, HTTP headers from the origin server may explicitly forbid caching via no-store or private directives. Verifying ownership of the cache folder and reviewing squid.conf settings usually resolves this immediate performance stagnation.

Verifying Cache Directory Permissions

The most common reason for Squid failing to write cached objects is a permission error on the disk location designated for storage. If the user running the Squid process does not have read and write access to the cache directory, Squid silently fails to store data, forcing every request to hit the origin server. This results in identical download times regardless of whether the proxy is active or not. You must ensure that the cache directory is owned by the correct system user. By default, Squid often runs as the proxy or nobody user, depending on your Linux distribution configuration. To check the current ownership, use the ls -ld command on your cache path. If the owner is not set correctly, you can change it using the chown command. For example:

sudo chown -R proxy:proxy /var/spool/squid

After correcting ownership, you should restart the Squid service to apply the changes. On systems using systemd, this is done via sudo systemctl restart squid. Always verify that the directory exists and has adequate space before proceeding to other configurations.

Configuring the Cache Directory Correctly

The cache_dir directive in squid.conf defines where cached objects are stored. A misconfigured or commented-out line here will disable caching entirely. The standard syntax requires specifying the filesystem type, the absolute path, the initial size in megabytes, and the first-level and second-level directory names. A typical valid configuration looks like this:

cache_dir ufs /var/spool/squid 100 16 256

In this example, ufs is the filesystem type, /var/spool/squid is the path, 100 is the initial size, 16 is the number of first-level subdirectories, and 256 is the number of second-level subdirectories per first-level directory. If any of these parameters are missing or incorrect, Squid may fail to initialize the cache store. If you recently changed the cache path, you must run the squid -z command to create the necessary directory structure. This command initializes the cache directories according to the parameters in squid.conf. Without running squid -z, the directories will not exist, leading to silent failures during runtime.

Checking Origin Server Headers

Even with perfect Squid configuration, caching will not occur if the origin server sends headers that prohibit it. Web servers often send Cache-Control: no-store, Cache-Control: private, or Expires headers to indicate that content should not be cached. This is common for dynamic content, login pages, or sensitive data. To diagnose this, inspect the response headers of the URLs you are trying to cache. You can use browser developer tools or command-line tools like curl to view these headers. Look for the Cache-Control field. If it contains no-store, Squid is obeying the server's instructions to avoid storing the object. If you need to cache specific resources despite these headers, you can modify Squid’s behavior using acl rules and cache_control directives. However, altering these settings may expose users to stale data or security risks if applied too broadly. It is generally better to configure the origin server to allow caching for static assets rather than overriding its policies at the proxy level.

Monitoring Cache Activity

Once permissions and configuration are verified, monitor the cache to confirm it is working. Use the squidclient mgr:info command to view detailed statistics about cache hits and misses. A healthy cache will show a non-zero number of cached objects and a decreasing miss ratio over time. Another useful tool is squidclient mgr:store_object_list, which lists objects currently in the cache. If this list remains empty after browsing various sites, the issue likely persists in the configuration or permissions. You can also check the access.log file for entries indicating why specific requests were not cached. Logs often provide clear reasons such as "Not Cachable" due to header restrictions. For more granular control, consider setting up regular cache clearing intervals. While not directly related to the initial failure, maintaining a clean cache can prevent issues with corrupted objects. See our guide on Way to Clear Cache Regular Intervals without Application for best practices on maintenance.

Common Pitfalls in Multi-User Environments

In environments where multiple users share a single Squid instance, conflicts can arise if different users attempt to modify the cache directory simultaneously. Ensure that only the Squid process writes to the cache directory. User accounts should not have direct write access to /var/spool/squid or whatever path you have defined. Additionally, check for SELinux or AppArmor profiles that might block Squid from writing to new locations. If you moved the cache to a non-standard directory, you may need to update your security context labels. Use getsebool -a | grep squid to check relevant SELinux booleans and enable them if necessary.

Frequently Asked Questions

How do I force Squid to ignore cache-control headers?

You can override these headers using the always_direct and never_direct directives combined with ACLs, but this is risky. A safer approach is to use cache_replacement_policy to manage how objects are evicted when space is low. Overriding headers can lead to serving outdated or sensitive information to users.

Why does my cache size stay at zero even after restarting?

This usually indicates that the cache_dir path is incorrect or inaccessible. Verify that the directory exists and that the Squid user has full read-write-execute permissions. Also, ensure that SELinux or AppArmor is not blocking access to the directory.

Can I cache HTTPS traffic with Squid?

Squid can cache HTTPS traffic if configured as an SSL-Bump proxy, but this requires installing certificates and configuring SSL interception rules. Standard forward proxy mode does not decrypt HTTPS traffic, so it cannot cache the content inside the encrypted tunnel. This setup adds significant complexity and potential privacy concerns.

What is the best cache replacement policy for large caches?

For large caches, the heap LFUDA (Least Frequently Used with Dynamic Aging) policy is often recommended. It balances recency and frequency of access, making it suitable for diverse workloads. You can set this in squid.conf using cache_replacement_policy heap LFUDA.

How do I check if Squid is actually running?

Use systemctl status squid to check the service status. You can also use netstat -tlnp | grep :3128 to verify that Squid is listening on its default port. If the service is inactive, start it with systemctl start squid and check the error log for startup failures.