Search icon CANCEL
Cart icon
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Learning Hub
Free Learning
Arrow right icon
Squid Proxy Server 3.1: Beginner's Guide
Squid Proxy Server 3.1: Beginner's Guide

Squid Proxy Server 3.1: Beginner's Guide: Reduce bandwidth use and deliver your most frequently requested web pages more quickly with Squid Proxy Server. This guide will introduce you to the fundamentals of the caching system and help you get the most from Squid.

$28.99 $19.99
Free Trial
Renews at $15.99p/m

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Table of content icon View table of contents Preview book icon Preview Book

Squid Proxy Server 3.1: Beginner's Guide

Chapter 1. Getting Started with Squid

In this chapter, we will have a look at how proxy servers and web caching works in general. We will proceed to download the correct Squid package for our operating system, based on the system requirements that we learned about in the Preface. We will learn how to compile and build additional Squid features. We will also learn the advantages of compiling Squid manually from the source over using a pre-compiled binary package.

In the final section, we will learn how to install Squid from a compiled source binary package, using popular package managers. Installation is a crucial part in getting started with Squid. Sometimes, we need to compile Squid with custom flags, depending on the environment requirements.

So let's get started with the real stuff.

Proxy server

A proxy server is a computer system sitting between the client requesting a web document and the target server (another computer system) serving the document. In its simplest form, a proxy server facilitates communication between client and target server without modifying requests or replies. When we initiate a request for a resource from the target server, the proxy server hijacks our connection and represents itself as a client to the target server, requesting the resource on our behalf. If a reply is received, the proxy server returns it to us, giving a feel that we have communicated with the target server.

In advanced forms, a proxy server can filter requests based on various rules and may allow communication only when requests can be validated against the available rules. The rules are generally based on an IP address of a client or target server, protocol, content type of web documents, web content type, and so on.

As seen in the preceding image, clients can't make direct requests to the web servers. To facilitate communication between clients and web servers, we have connected them using a proxy server which is acting as a medium of communication for clients and web servers.

Sometimes, a proxy server can modify requests or replies, or can even store the replies from the target server locally for fulfilling the same request from the same or other clients at a later stage. Storing the replies locally for use at a later time is known as caching. Caching is a popular technique used by proxy servers to save bandwidth, empowering web servers, and improving the end user's browsing experience.

Proxy servers are mostly deployed to perform the following:

  • Reduce bandwidth usage

  • Enhance the user's browsing experience by reducing page load time which, in turn, is achieved by caching web documents

  • Enforce network access policies

  • Monitoring user traffic or reporting Internet usage for individual users or groups

  • Enhance user privacy by not exposing a user's machine directly to Internet

  • Distribute load among different web servers to reduce load on a single server

  • Empower a poorly performing web server

  • Filter requests or replies using an integrated virus/malware detection system

  • Load balance network traffic across multiple Internet connections

  • Relay traffic around within a local area network

In simple terms, a proxy server is an agent between a client and target server that has a list of rules against which it validates every request or reply, and then allows or denies access accordingly.

Reverse proxy

Reverse proxying is a technique of storing the replies or resources from a web server locally so that the subsequent requests to the same resource can be satisfied from the local copy on the proxy server, sometimes without even actually contacting the web server. The proxy server or web cache checks if the locally stored copy of the web document is still valid before serving the cached copy.

The life of the locally stored web document is calculated from the additional HTTP headers received from the web server. Using HTTP headers, web servers can control whether a given document/response should be cached by a proxy server or not.

Web caching is mostly used:

  • To reduce bandwidth usage. A large number of static web documents like CSS and JavaScript files, images, videos, and so on can be cached as they don't change frequently and constitutes the major part of a response from a web server.

  • By ISPs to reduce average page load time to enhance browsing experience for their customers on Dial-Up or broadband.

  • To take a load off a very busy web server by serving static pages/documents from a proxy server's cache.

Getting Squid

Squid is available in several forms (compressed source archives, source code from a version control system, binary packages such as RPM, DEB, and so on) from Squid's official website, various Squid mirrors worldwide, and software repositories of almost all the popular operating systems. Squid is also shipped with many Linux/Unix distributions.

There are various versions and releases of Squid available for download from Squid's official website. To get the most out of a Squid installation its best to check out the latest source code from a Version Control System (VCS) so that we get the latest features and fixes. But be warned, the latest source code from a VCS is generally leading edge and may not be stable or may not even work properly. Though code from a VCS is good for learning or testing Squid's new features, you are strongly advised not to use code from a VCS for production deployments.

If we want to play safe, we should probably download the latest stable version or stable version from the older releases. Stable versions are generally tested before they are released and are supposed to work out of the box. Stable versions can directly be used in production deployments.

Time for action – identifying the right version

A list of available versions of Squid is maintained at For production environments, we should use versions listed under the Stable Versions section only. If we want to test new Squid features in our environment or if we intend to provide feedback to the Squid community about the new version, then we should be using one of the Beta Versions.

As we can see in the preceding screenshot, the website contains the First Production Release Date and Latest Release Date for the stable versions. If we click on any of the versions, we are directed to a page containing a list of all the releases in that particular version. Let's have a look at the page for version 3.1:

For every release, along with a release date, there are links for downloading compressed source archives.

Different versions of Squid may have different features. For example, all the features available in Squid version 2.7 may or may not be available in newer versions such as Squid 3.x. Some features may have been deprecated or have become redundant over time and they are generally removed. On the other hand, Squid 3.x may have several new features or existing features in an improved and revised manner.

Therefore, we should always aim for the latest version, but depending on the environment, we may go for stable or beta version. Also, if we need specific features that are not available in the latest version, we may choose from the available releases in a different branch.

What just happened?

We had a brief look at the pages containing the different versions and releases of Squid, on Squid's official website. We also learned which versions and releases that we should download and use for different types of usage.

Methods of obtaining Squid

After identifying the version of Squid that we should be using for compiling and installation, let's have a look at the ways in which we can obtain Squid release 3.1.10.

Using source archives

Compressed source archives are the most popular way of getting Squid. To download the source archive, please visit Squid download page, This web page has links for downloading the different versions and releases of Squid, either from the official website or available mirrors worldwide. We can use either HTTP or FTP for getting the Squid source archive.

Time for action – downloading Squid

Now we are going to download Squid 3.1.10 from Squid's official website:

  1. Let's go to the web page

  2. Now we need to click on the link to Version 3.1, as shown in the following screenshot:

  3. We'll be taken to a page displaying the various releases in version 3.1. The link with the display text tar.gz in the Download column is a link to the compressed source archive for Squid release 3.1.10, as shown in the following screenshot:

  4. To download Squid 3.1.10 using the web browser, just click on the link.

  5. Alternatively, we can use wget to download the source archive from the command line as follows:


What just happened?

We successfully retrieved Squid version 3.1.10 from Squid's official website. The process of retrieving other stable or beta versions is very similar.

Obtaining the latest source code from Bazaar VCS

Advanced users may be interested in getting the very latest source code from the Squid code repository, using Bazaar. We can safely skip this section if we are not familiar with VCS in general. Bazaar is a popular version control system used to track project history and facilitate collaboration. From version 3.x onwards, Squid source code has been migrated to Bazaar. Therefore, we should ensure that we have Bazaar installed on our system in order to checkout the source code from repository. To find out more about Bazaar or for Bazaar installation and configuration manuals, please visit Bazaar's official website at

Once we have setup Bazaar, we should head to the Squid code repository mirrored on Launchpad at From here we can browse all the versions and branches of Squid. Let's get ourselves familiar with the page layout:

In the previous screenshot, Series: trunk represents the development branch, which contains code that is still in development and is not ready for production use. The branches with the status Mature are stable and can be used right away in production environments.

Time for action – using Bazaar to obtain source code

Now that we are familiar with the various branches, versions, and releases. Let's proceed to checking out the source code with Bazaar. To download code from any branch, the syntax for the command is as follows:

bzr branch lp:squid[/branch[/version]]

branch and version are optional parameters in the previous code. So, if we want to get branch 3.1, then the command will be as follows:

bzr branch lp:squid/3.1

The previous command will fetch source code from Launchpad and may take a considerable amount of time, depending on the Internet connection. If we are willing to download source code for Squid version 3.1.10, then the command will be as follows:

bzr branch lp:squid/3.1/3.1.10

In the previous code, 3.1 is the branch name and 3.1.10 is the specific version of Squid that we want to checkout.

What just happened?

We learned to fetch the source code for any Squid branch or release using Bazaar from Squid's source code hosted on Launchpad.

Have a go hero – fetching the source code

Using the command syntax that we learned in the previous section, fetch the source code for Squid version 3.0.stable25 from Launchpad.

  • Solution:

    bzr branch lp:squid/3.0/3.0.stable25
  • Explanation: If we browse to the particular version on Launchpad, the version number used in the command becomes obvious.

Using binary packages

Squid binary packages are pre-compiled and ready to install software bundles. Binary packages are available in the software repositories of almost all Linux/Unix-based operating systems. Depending on the operating system, only stable and sometimes well tested beta versions make it to the software repositories, so they are ready for production use.

Installing Squid

Squid can be installed using the source code we obtained in the previous section, using a package manager which, in turn, uses the binary package available for our operating system. Let's have a detailed look at the ways in which we can install Squid.

Installing Squid from source code

Installing Squid from source code is a three step process:

  1. Select the features and operating system-specific settings.

  2. Compile the source code to generate the executables.

  3. Place the generated executables and other required files in their designated locations for Squid to function properly.

We can perform some of the above steps using automated tools that make the compilation and installation process relatively easy.

Compiling Squid

Compiling Squid is a process of compiling several files containing C/C++ source code and generating executables. Compiling Squid is really easy and can be done in a few steps. For compiling Squid, we need an ANSI C/C++ compliant compiler. If we already have a GNU C/C++ Compiler (GNU Compiler Collection (GCC) and g++, which are available on almost every Linux/Unix-based operating system by default), we are ready to begin the actual compilation.

Why compile?

Compiling Squid is a bit of a painful task compared to installing Squid from the binary package. However, we recommend compiling Squid from the source instead of using pre-compiled binaries. Let's walk through a few advantages of compiling Squid from the source:

  • While compiling we can enable extra features, which may not be enabled in the pre-compiled binary package.

  • When compiling, we can also disable extra features that are not needed for a particular environment. For example, we may not need Authentication helpers or ICMP support.

  • configure probes the system for several features and enables or disables them accordingly, while pre-compiled binary packages will have the features detected for the system the source was compiled on.

  • Using configure, we can specify an alternate location for installing Squid. We can even install Squid without root or super user privileges, which may not be possible with pre-compiled binary package.

Though compiling Squid from source has a lot of advantages over installing from the binary package, the binary package has its own advantages. For example, when we are in damage control mode or a crisis situation and we need to get the proxy server up and running really quickly, using a binary package for installation will provide a quicker installation.

Uncompressing the source archive

If we obtained the Squid in a compressed archive format, we must extract it before we can proceed any further. If we obtained Squid from Launchpad using Bazaar, we don't need to perform this step.

tar -xvzf squid-3.1.10.tar.gz

tar is a popular command which is used to extract compressed archives of various types. On the other hand, it can also be used to compress many files into a single archive. The preceding command will extract the archive to a directory named squid-3.1.10.

Configure or system check

Configure or system check is the first step in the compilation process and is achieved by running ./configure from the command line. This program probes the system, making sure that the required packages are installed. This also checks the system capabilities and collects information about the system architecture and default settings such as, available file descriptors and so on. After collecting all the information, this program generates the makefiles, which are used in the next step to actually compile the Squid source code.

Running configure without any parameters uses the preset defaults. If we are willing to change the default Squid settings or if we want to disable some optional features that are enabled by default, or if we want to install Squid in an alternate location in the file system, we need to pass options to configure. Use the following the command to see the available options along with a brief description.

Let's run configure with the --help option to have a look at the available configuration options.

./configure --help | less

This will display the page containing the options and their brief description for configure. Use up and down arrow keys to navigate through the information. Now let's discuss a few of the commonly used options with configure:


The --prefix option is the most commonly used option. If we are testing a new version or if we wanted to test multiple Squid versions, we will have multiple Squid version installed on our system. To identify the different versions and to prevent interference or confusion between the versions, it's a good idea to install them in separate directories.

For example, for installing Squid version 3.1.10, we can use the directory /opt/squid/3.1.10/ and the corresponding configure command will be run as:

./configure --prefix=/opt/squid/3.1.10/

Similarly, for installing Squid version 3.1, we can use the directory /opt/squid/3.1/.


From now onwards, ${prefix} will represent the location where we have installed Squid, that is, the directory name used with the --prefix option while running configure, as shown in the previous command.

Squid provides even more control over the location of different types of files such as executables and documentation files. Their placement can be controlled with options such as --bindir, --sbindir, and so on. Please check the configure help page for further details on these options.

Now, let's check the optional features and packages. To enable any optional feature, we pass an option in the format --enable-FEATURE_NAME and to disable a feature, the option format is either --disable-FEATURE_NAME or --enable-FEATURE_NAME=no. For example, icmp is a feature name.

./configure --enable-FEATURE # FEATURE will be enabled
./configure --disable-FEATURE # FEATURE will be disabled
./configure --enable-FEATURE=no # FEATURE will be disabled

Similarly, to compile Squid with an available package, we pass an option in the format --with-PACKAGE_NAME and to compile Squid without a package, we pass the option --without-PACKAGE_NAME. openssl is an example package name.


Regular expressions are used for constructing Access Control Lists in Squid. If we are running a modern Linux/Unix-based operating system, we don't need to worry about this option. But if our system doesn't have built-in support for regular expressions, we should enable support for regular expressions using --enable-gnuregex.


Squid has a lot of code that can be inlined, which is good for production use. But inline code takes longer to compile and is useful when we need to compile a source only once for setting up Squid for production use. This option is intended to be used during development when we need to compile Squid time and again.


Squid is, by default, compiled with compiler optimizations that result in better performance. Again this option should be used while debugging a problem or testing different versions as it'll reduce compilation time. The --disable-inline option is automatically used if we use this option.


Squid's performance depends heavily on disk I/O performance when disk caching is enabled. The quicker Squid can read/write files from cache, the lesser time it'll take to satisfy a request, which in turn will result in smaller delays. Different storage techniques may lead to optimized performance, depending on the traffic type and usage. We can use this option to build Squid with support for various store I/O modules. Please check the src/fs/ directory in the Squid source code for available store I/O modules.

./configure --enable-storeio=ufs,aufs,coss,diskd,null

While using disk caching, we instruct Squid to use a specified disk space for caching web documents. Over a period of time, the space is consumed and Squid will still need more space to cache new documents. Squid then has to decide which old documents should be removed or purged from the cache to make space for storing the new ones. There are different policies for purging the documents to achieve maximum benefits from caching.

The policies are based on heap and list data structures. List data structure is enabled by default. Please check the src/repl/ directory in the Squid source code for available removal policies.

./configure --enable-removal-policies=heap,lru

This option is helpful in determining the distance from other cache peers and remote servers to estimate approximate latency. This is useful only if we have other cache peers in the network.


Squid uses delay pools to limit or control bandwidth that can be used by a client or a group of clients. Delay pools are like leaky buckets which leak data (web traffic) to clients and are refilled at a controlled rate. These come in handy when we need to control the bandwidth used by a group of users.


This option enables Squid to use Edge Side Includes (see for more information). If this is enabled, Squid completely ignores cache-control headers from clients. This option is only intended to be used when Squid is used in accelerator mode.


This provides the capability of logging user agent headers from HTTP requests by clients.


If we enable this option, Squid will be able to write a referer header field from HTTP requests.


This option disables support for Cisco's Web Cache Communication Protocol (WCCP). WCCP enables communication between caches, which in turn helps in localizing the traffic. By default, WCCP-support is enabled.


Similar to the previous option, this disables support Cisco's WCCP version 2. WCCPv2 is an improved version of WCCP and has built-in support for load balancing, scaling, fault-tolerance, and service assurance mechanisms. By default, WCCPv2 support is enabled.


In Squid versions 3.x, SNMP (Simple Network Management Protocol) is enabled by default. SNMP is quite popular among system administrators for monitoring servers and network devices.


Cache Manager (cachemgr.cgi) is a CGI utility to manage Squid's cache and view cache statistics using a web interface. The host name for accessing cache manager can be set using this option. By default, we can access cache manager web interface using localhost or the IP address of the Squid server.


Squid supports building Access Control Lists based on MAC (or Ethernet) addresses. This feature is disabled by default. If we want to control client access based on Ethernet addresses, we should enable this feature. Enabling this is a good idea while learning Squid.


This option will be replaced by --enable-eui which is enabled by default.


Hypertext Caching Protocol (HTCP) can be used by Squid to send and receive cache digests to neighboring caches. This option disables HTCP support.


Squid can terminate SSL connections. When Squid is configured in reverse proxy mode, Squid can terminate the SSL connections initiated by clients and handle it on behalf of the web server in the backend. This essentially means that the backend web server will not have to do any SSL work, which means significant computation savings. In this case, the communication between Squid and the backend web server will be pure HTTP, but clients will still see it as a secure connection with the web server. This is useful only when Squid is configured to work in accelerator or reverse proxy mode.


Cache digests are Squid's way of sharing information with neighboring Squid servers about the cached web documents, in a compressed format.


Whenever Squid encounters an error (for example, a page not found, access denied, or network unreachable error) that should be conveyed to the client, Squid uses default pages for showing these errors. The error pages are available in local languages. This option can be used to specify the default language for all the error pages. The default language for error pages is English.

./configure --enable-default-err-language=Spanish

By default, Squid builds support for all available languages. If we only want to build Squid with languages which we are familiar with, we can use this option. Please check the errors/ directory in the Squid source code for available languages.

./configure --enable-err-languages='English French German'

Squid has configuration options, and by using them, we can force Squid to violate HTTP protocol standards by replacing header fields in HTTP requests or responses. Tinkering with HTTP headers is against standard HTTP norms. We can disable support for all sorts of HTTP violations by using this option.


IPFIREWALL (IPFW) is a firewall application for the FreeBSD system maintained by FreeBSD staff and volunteers. This option is useful while setting up Transparent Proxy Server on systems with IPFW. If our system doesn't have IPFW, we should avoid using this option, because Squid will fail to compile. The default behavior is auto-detect, which does the job quite well.


IPFilter (IPF) is also a stateful firewall for many Unix-like operating systems. It is provided by NetBSD, Solaris, and so on. If our system has IPF, then we should enable this option to be able to configure Squid in Transparent mode. Enabling this option in the absence of IPF on the system will result in compile errors.


Packet Filter (PF) is yet another stateful firewall application originally developed for OpenBSD. This option is useful on systems with PF installed to achieve Transparent Proxy mode. Do not enable this option if PF is not installed.


Netfilter is the packet filtering framework in Linux kernels in series 2.4.x and 2.6.x. This option is useful for enabling Transparent Proxy support on Linux-based operating systems.


When a HTTP request is forwarded by a proxy, the proxy writes essential information about itself and the client for which the request is being forwarded, in HTTP headers. This option enables Squid to try to lookup the IP address of the original client for which the request was forwarded through one or more proxy servers.


This prevents Squid from performing ident lookups or identifying a username for every connection. Disabling this may prevent our system from a possible Denial of Service attack by a malicious client requesting a large number of connections.


Squid has its own implementation of DNS protocol and is capable of building DNS queries. If we want to use Squid's internal DNS, then we should not disable it. Otherwise, we can disable support for Squid's internal DNS feature by using this option and can use external DNS servers.


Using this option, we can select the default location of the hosts file. On most operating systems, it's located in the /etc/hosts directory.

./configure --enable-default-hostsfile=/some/other/location/hosts

Squid supports various authentication mechanisms. This option enables support for authentication schemes. This configure option (and related enable auth options) are undergoing change.

Old Syntax

Previously, this option was used to enable authentication support and a list of authentication schemes was also passed. The authentication schemes from the list were then built during compilation.

./configure --enable-auth=basic,digest,ntlm
New Syntax

Now, this option is used only to enable global support for authentication and a list of authentication schemes is not passed along. The authentication scheme is enabled with the option --enable-auth-AUTHENTICATION_SCHEME where AUTHENTICATION_SCHEME is the name of the authentication scheme. By default, all the authentication schemes are enabled and the corresponding authentication helpers are built during compilation. Authentication helpers are external programs that can authenticate clients using various authentication mechanisms, against different user databases.

./configure --enable-auth

This option enables support for a Basic Authentication scheme and builds the list of helpers specified. If the list of helpers is not provided, this will enable all the possible helpers. A list of available helpers for this scheme can be found in the helpers/basic_auth/ directory in the Squid source code. To disable this authentication scheme, we can use --disable-auth-basic.

./configure --enable-auth-basic=PAM,NCSA,LDAP

If we want to enable this option but don't want to build any helpers, we should use "none" in place of a list of helpers.

./configure --enable-auth-basic=none

Previously, this option was known as --enable-basic-auth-helpers. The list of helpers is passed in a similar way.

./configure --enable-basic-auth-helpers=PAM,NCSA,LDAP


The old and new option syntax for all other authentication schemes are similar.


Squid support for the NTLM authentication scheme is enabled with this option. The available helpers for this scheme reside in the helpers/ntlm_auth/ directory in the Squid source code. To disable NTLM authentication scheme support, use the --disable-auth-ntlm option.

./configure --enable-auth-ntlm=smb_lm,no_check

This option enables the Negotiate Authentication scheme. Details and syntax are similar to the above authentication scheme option.

./configure --enable-auth-negotiate=kerberos

This option enables support for Digest Authentication scheme. Other details are similar to the above option.


If this option is enabled and a helper fails while authenticating a user, it can still allow Squid to authenticate the user. This option should be used with care as it may lead to security loopholes.


Squid supports external ACLs using helpers. If we are willing to use external ACLs, we should consider using this option. We can also use this option while learning. A list of external ACL helpers should be passed to build specific helpers. The default behavior is to build all the available helpers. A list of available external ACL helpers can be found in the helpers/external_acl/ directory in the Squid source code.

./configure --enable-external-acl-helpers=unix_group,ldap_group

By default, Squid tries to present error and manual pages in a local language. If we don't want this to happen, then we may use this option.


Based on a client's request headers, Squid tries to automatically provide localized error pages. We can use this option to disable the automatic localization. The error_directory tag in the Squid configuration file must be configured if we use this option.


unlinkd is an external process which is used to make unlink system calls. This option disables unlinkd support in Squid. Disabling unlinkd is not a good idea as the unlink system call can block a process for a considerable amount of time, which can cause a delay in responses.


We normally don't want to run Squid as the root user to omit any security risks. By default, Squid runs as the user nobody. However, if we have installed Squid from a pre-compiled binary, Squid may run as a 'squid' or 'proxy' user depending on the operating system we are using. Using this option, we can set the default user for running Squid. See the following example of how to use this option:

./configure --with-default-user=squid

By default, Squid writes all logs and error reports to designated files in ${prefix}/var/logs/. This location is different from the location used by all other processes and daemons to write their logs. In order to get quick access to the Squid logs, we may want to place them in the default system log directory, which is /var/log/ in most of the Linux-based operating systems. See the following example of the syntax to achieve this:

./configure --with-logdir=/var/log/squid/

The default location for storing the Squid PID file is ${prefix}/var/run/, which is not the standard system location for storing PID files. On most Linux-based operating systems, the PID files are stored in /var/run/. So, we may want to change the default PIDfile location using the following option:

./configure --with-pidfile=/var/run/

Using this option, we can specify the number of threads to use when the aufs storage system is used for managing the cache directories. If this option is not used, Squid automatically calculates the number of threads that should be used:

./configure --with-aufs-threads=12

Older versions of Squid were built without POSIX threads support. Now, Squid is built with pthreads support by default, therefore, if we don't want to enable pthreads support, we'll have to explicitly disable it.


If we want to build Squid with OpenSSL support, we can use this option to specify the OpenSSL installation path, if it's not installed in the default location:

./configure --with-openssl=/opt/openssl/ 

Under heavy traffic, Squid's log files (especially the access log) grow quickly and in the long run the file size may become quite large. We can use this option to enable support for large log files.


For better performance, it is good practice to rotate log files frequently instead of going with large files.


Operating systems use file descriptors (basically integers) to track the open files and sockets. By default, there is a limit on the number of file descriptors a user can use (normally 1024). Once Squid has accepted connections which have consumed all the available file descriptors to the Squid user, it can't accept more connections unless some of the file descriptors are released.

Under heavy load, Squid frequently runs out of file descriptors. We can use the following option to overcome the file descriptor shortage problem:

./configure --with-filedescriptors=8192


We also need to increase the system-wide limit on the number of file descriptors available to a user.

Have a go hero – file descriptors

Find out the maximum number of available file descriptors for your user. Also, write down the commands that will set the maximum available file descriptors limit to 8192.

Solution: To check the available file-descriptors use the following command:

ulimit -n

To set the file descriptor limit to 8192, we need to append the following lines to /etc/security/limits.conf:

username hard nofile 8192
username soft nofile 8192

The preceding action can be performed only with root or super user privileges.

Time for action – running the configure command

Now that we have had a brief look at several of the available options, we can layout the options for the environment for which we are building Squid. Now, we are ready to run the configure command with the following options:

./configure --prefix=/opt/squid/ --with-logdir=/var/log/squid/ --with-pidfile=/var/run/ --enable-storeio=ufs,aufs --enable-removal-policies=lru,heap --enable-icmp --enable-useragent-log --enable-referer-log --enable-cache-digests --with-large-files

The preceding command will run for a while, probing the system for various capabilities and making decisions on the basis of the available libraries and modules. The configure writes debugging output to the config.log file in the same directory. It is always wise to check the config.log for any errors which may have occurred while running the configure command.

If everything goes fine, configure will generate the makefiles in several directories which will be required for compiling the source code in the next step.

What just happened?

Running the configure program with the options mentioned in the previous code example, will generate the makefiles needed to compile the Squid source code and source code of the modules enabled. It will also generate the config.log and config.status files. All the messages which are generated during the running of the configure program are logged to the config.log file. The config.status file is an executable which can be run to recreate the makefiles.

Have a go hero – debugging configure errors

In the Squid source directory, run the configure command, as shown in the following code:

./configure --enable-storeio='aufs,disk'

Now try to check what went wrong and fix the errors.

Time for action – compiling the source

After specifying our environment and building the requirements, we need to do the actual compilation. Compiling source code is very easy and is a matter of just one command:


We do not need to be the root or super user to execute this command. This command may take a considerable amount of time to execute, depending on the system hardware. Running make will produce a lot of output in the terminal. It may also produce a lot of compiler warnings which can safely be ignored in most cases.

If make ends with errors, we should check Squid bugzilla for similar problems. We can update an existing bug with our error report or create a new bug report if there is no similar bug already. For details on troubleshooting and completing bug reports, please refer to Chapter 12, Troubleshooting Squid.

If make ends without any errors, we can quickly proceed to the installation phase. We can also run make again to verify that everything is compiled successfully. Running make again should produce a lot of lines similar to the following:

Making all in compat
make[1]: Entering directory '/home/user/squid-source/compat'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/user/squid-source/compat'

What just happened?

We have just run the make command that will compile the source code of Squid and related modules, to generate executables, if it finishes without errors. The generated executables are ready to be installed now.

Time for action – installing Squid

The successful compilation of the source code in the previous section will generate the required programs depending on the features and packages we have enabled or disabled. However, they should be moved to their designated locations, so that they can be used. Let's perform the final steps of the installation.

  1. Depending on the ${prefix}, we may need root or super user privileges for installing Squid. If root or super user privileges are needed, we should first switch to root or super user by using the following command:

  2. Now all we need to do is to run the make command with install as the argument:

    make install

    This will install or simply move programs to their designated locations, depending on the path used with the --prefix option while running the configure program.

What just happened?

We just learned how to perform the final step in installing Squid, which is to place the generated programs and other essential files in their designated locations.

Time for action – exploring Squid files

Let's have a look at the files and directories generated during installation. The easiest way to checkout the directories and files generated is to use the tree command. If the tree command is not available, we can list files using the ls command as well.

tree ${prefix} | less

${prefix} is the directory used with the --prefix option for configure. Now let's have a brief overview at the important files generated by Squid during installation. All of the following directories and files listed, reside in ${prefix}:


This directory contains programs which can be executed or run by a user without root or super user privileges.


squidclient is a HTTP client with advanced capabilities, which allow it to tinker HTTP requests to test the Squid server. Run squidclient to checkout the available options:



This is the place where for all the configuration files related to Squid are located.


It's a good idea to use the --sysconfdir=/etc/squid/ option with configure, so that you can share the configuration across different Squid installations while testing.


This is the default location for the Squid configuration file. The squid.conf generated during installation is the bare minimum configuration required for Squid to be used. We always make changes to this file if we need to alter the Squid configuration.


Squid generates this default configuration file so that we can copy and rename it to squid.conf and start afresh.


This is a fully documented version of squid.conf, containing thousands of lines of comments. We should always refer to this file for the available configuration tags for the version of Squid when we have installed.


This directory contains helper programs built during Squid compilation.


This CGI program provides a web interface for managing the Squid cache called Cache Manager.


This directory contains programs which can only be executed by a user with root or super user privileges.


This is the actual Squid program, which is generally run as a daemon.


This is the location for error page templates, documentation, and other files used by Squid.


This directory contains localized error page templates. The templates are HTML pages and we can customize the error messages displayed by Squid, by modifying these HTML templates.


This directory contains a number of small images used for FTP or gopher directory listing.


This is the place where the man pages for squid, squidclient, and helpers are built during compilation. Man pages are manual or help pages which can be viewed using the command man (available on all Linux/Unix distributions). To view a man page located at /opt/squid/share/man/man8/squid.8, we can use the man command as follows:

man /opt/squid/share/man/man8/squid.8

For more details about man pages, please visit


A place for files that change frequently while Squid is running.


This is the default directory for storing the cached web documents on a hard disk.


This is the default home for all the log files (such as cache.log, access.log, and so on) used by Squid.

What just happened?

We have just looked at the various files and directories generated during installation and a had brief overview of what each directory contains.

Installing Squid from binary packages

Squid binary packages are available in the software repositories of most operating systems and we can install them by using the package managers provided by the respective operating systems. Next, we'll see how to use a package manager on a few operating systems to install Squid.


The latest or beta versions may not be available in software repositories of all the operating systems. In such cases, we should get the latest or beta versions from the Squid website, as explained earlier in this chapter.

Fedora, CentOS or Red Hat

Yum is a popular package manager on RPM-based operating systems. Squid RPM is available in the Fedora, CentOS, and Red Hat repositories. To install Squid, we can simply use the following command:

yum install squid

Debian or Ubuntu

We can use apt-get to install Squid on Debian or Ubuntu:

apt-get install squid3


Squid is available in the FreeBSD ports collection. The following command can be used to install Squid on FreeBSD:

pkg_add -r squid31

For more information on package management in FreeBSD, please go to

OpenBSD or NetBSD

Installing Squid on OpenBSD or NetBSD is similar to installing it on FreeBSD and can be performed using the following command:

pkd_add squid31

To learn more about the package management system in OpenBSD and NetBSD, please refer to and respectively.

Dragonfly BSD

To install Squid on Dragonfly BSD, we can use the following command:

pkg_radd squid31

For more information on installing binary packages on Dragonfly BSD, please visit


We can install Squid on Gentoo Linux using emerge, as shown next:

emerge =squid-3.1*

Arch Linux

To install Squid on Arch Linux, we can use the package manager pacman, as shown in the following command:

pacman -S squid

For more information on pacman, please visit

Pop quiz

  1. Which of the following web documents can't be cached by a proxy server?

    1. A HTML page

    2. A JPEG image

    3. A PHP script that produces output based on a client's IP Address

    4. A JavaScript file

  2. In which of the following scenarios, should we worry about the --enable-diskio option?

    1. Caching in RAM (main memory) is enabled

    2. Caching on hard disk is enabled

    3. Caching is disabled

    4. None of the above

  3. When does a removal policy selection affect the overall Squid performance?

    1. If caching is disabled

    2. If caching on the hard disk and RAM is enabled

    3. A removal policy selection is not related to caching

    4. A removal policy doesn't affect overall Squid performance


We learned about proxy servers and web caching in general and the ways in which they can be useful, especially for saving bandwidth and improving end user experience. Then we moved on to exploring Squid, which is a powerful caching proxy server. The following are the important things that we learned in this chapter:

  • Various ways to grab Squid for production use or development

  • Meaning of various configure options

  • Compiling Squid source code

  • Installing Squid from source and binary package

  • Pros and cons of compiling Squid from source

We also discussed about the directory structure and files generated by Squid during installation.

Now that we know how to install Squid, we are ready to learn how to configure Squid according to requirements for a given network environment. We'll learn about this with a few examples in the next chapter.

Left arrow icon Right arrow icon

Key benefits

  • Get the most out of your network connection by customizing Squid's access control lists and helpers
  • Set up and configure Squid to get your website working quicker and more efficiently
  • No previous knowledge of Squid or proxy servers is required
  • Part of Packt's Beginner's Guide series: lots of practical, easy-to-follow examples accompanied by screenshots


Squid Proxy Server enables you to cache your web content and return it quickly on subsequent requests. System administrators often struggle with delays and too much bandwidth being used, but Squid solves these problems by handling requests locally. By deploying Squid in accelerator mode, requests are handled faster than on normal web servers making your site perform quicker than everyone else's! Squid Proxy Server 3.1 Beginner's Guide will help you to install and configure Squid so that it is optimized to enhance the performance of your network. The Squid Proxy Server reduces the amount of effort that you will have to put in, saving your time to get the most out of your network. Whether you only run one site, or are in charge of a whole network, Squid is an invaluable tool that improves performance immeasurably. Caching and performance optimization usually requires a lot of work on the developer's part, but Squid does all that for you. This book will show you how to get the most out of Squid by customizing it for your network. You will learn about the different configuration options available and the transparent and accelerated modes that enable you to focus on particular areas of your network. Applying proxy servers to large networks can be a lot of work as you have to decide where to place restrictions and who should have access, but the straightforward examples in this book will guide you through step by step so that you will have a proxy server that covers all areas of your network by the time you finish the book.

What you will learn

Discover which configuration option would best suit your network Gain better control over Squid with command-line options that help you to debug Squid Devise an Access Control List (ACL) to decide which users are granted access to different ports Understand logfiles and log format and how to customize them to suit your needs Learn about Squid s Cache Manager web interface so that you can monitor your traffic in real time to prevent any problems before they happen Implement a cache hierarchy to use in a large network Use Squid in Accelerator Mode to quickly boost the performance of a very slow website Write your own URL rewriters to customize the behavior of Squid Learn how to troubleshoot Squid

Product Details

Country selected

Publication date : Feb 21, 2011
Length 332 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781849513906
Concepts :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want

Product Details

Publication date : Feb 21, 2011
Length 332 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781849513906
Concepts :

Table of Contents

20 Chapters
Squid Proxy Server 3.1 Beginner's Guide Chevron down icon Chevron up icon
Credits Chevron down icon Chevron up icon
About the Author Chevron down icon Chevron up icon
About the Reviewers Chevron down icon Chevron up icon Chevron down icon Chevron up icon
Preface Chevron down icon Chevron up icon
1. Getting Started with Squid Chevron down icon Chevron up icon
2. Configuring Squid Chevron down icon Chevron up icon
3. Running Squid Chevron down icon Chevron up icon
4. Getting Started with Squid's Powerful ACLs and Access Rules Chevron down icon Chevron up icon
5. Understanding Log Files and Log Formats Chevron down icon Chevron up icon
6. Managing Squid and Monitoring Traffic Chevron down icon Chevron up icon
7. Protecting your Squid Proxy Server with Authentication Chevron down icon Chevron up icon
8. Building a Hierarchy of Squid Caches Chevron down icon Chevron up icon
9. Squid in Reverse Proxy Mode Chevron down icon Chevron up icon
10. Squid in Intercept Mode Chevron down icon Chevron up icon
11. Writing URL Redirectors and Rewriters Chevron down icon Chevron up icon
12. Troubleshooting Squid Chevron down icon Chevron up icon
Pop Quiz Answers Chevron down icon Chevron up icon
Index Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Empty star icon Empty star icon Empty star icon Empty star icon Empty star icon 0
(0 Ratings)
5 star 0%
4 star 0%
3 star 0%
2 star 0%
1 star 0%
Top Reviews
No reviews found
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial


How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to
  • To contact us directly if a problem is not resolved, use
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.