NAS: Create your own caching proxy

There you are, with that 1TB NAS and you surf mostly the same websites and in the process waste plenty of time waiting on downloads. So why not install your own Squid-proxy server on your NAS?

With the Synology and the pre-requisite of having ipkg installed – this takes no more than 10 minutes.

Update (2008-12-22): I have adjusted the Squid-configuration to block websites for unlisted IP-addresses. If you don’t require this (and want your kids to download several gigs of You Tube-videos) then delete the lines acl nonblockedip, acl blocksites and http_access deny blocksites.

In my example, my NAS IP is 172.16.0.97 and my IP range on my LAN is 172.16.0.0 – adjust this accordingly below:

  1. Install squid: ipkg install squid
  2. Adjust Squid’s config-file located in /opt/etc/squid/squid.conf:


     
  3. Take note from my above config, that I chose a cache-size of 20(!) GB (cache_dir).
  4. Validate your Squid configuration with squid -k parse
  5. Create the Squid cache-directories with squid -z
  6. Start Squid manually to check for errors: squid -NCd1
  7. Create a symbolic link so that Squid starts automatically: ln -s /opt/etc/init.d/S80squid /usr/syno/etc/rc.d/
  8. Once you restart the NAS, Squid should be started automatically (log files are in /opt/var/squid/logs)

Dummy error: Happened to me – if Squid starts and you don’t notice any improvements in browsing speed, make sure that you have your browser’s proxy settings adjusted 😳

IMPORTANT: As I have the caching server within a DMZ/Firewall, security-concerns are secondary. All users having access to the LAN and fall within the IP-range will automatically have access to the caching-proxy. The implementation of Squid was for improving the browsing/web-experience (speed has improved by almost 200% and average bandwidth consumption dropped by 30%).

If you get everything running, you should familiarise yourself with the statuses in Squid’s access-log:

  • TCP_HIT: A valid copy of the requested object was in the cache.
  • TCP_MEM_HIT: A valid copy of the requested object was in the cache, AND it was in memory so it did not have to be read from disk.
  • TCP_NEGATIVE_HIT: The request was for a negatively-cached object. Negative-caching refers to caching certain types of errors, such as “404 Not Found.” The amount of time these errors are cached is controlled with the negative_ttl configuration parameter.
  • TCP_MISS: The requested object was not in the cache.
  • TCP_REFRESH_HIT: The object was in the cache, but STALE. An If-Modified-Since request was made and a “304 Not Modified” reply was received.
  • TCP_REF_FAIL_HIT: The object was in the cache, but STALE. The request to validate the object failed, so the old (stale) object was returned.
  • TCP_REFRESH_MISS: The object was in the cache, but STALE. An If-Modified-Since request was made and the reply contained new content.
  • TCP_CLIENT_REFRESH: The client issued a request with the “no-cache” pragma.
  • TCP_IMS_HIT: The client issued an If-Modified-Since request and the object was in thecache and still fresh.
Print Friendly