Home Solutions Knowledge Base FAQs E-mail Support Live Chat Buy Support

Disclaimer: This manual is NOT a Squid tutorial. It is only a reference material that provides detailed explanation of all configuration parameters available in Squid 3.0. The reader is expected to have prior knowledge of basic Squid installation and configuration. For Complete tutorial on Squid, please visit http://www.squid-cache.org

Squid 3.0 Configuration Manual DELAY POOL PARAMETERS Conceptually, delay pools are bandwidth limiters - "pools" of bandwidth that drain out as people browse the Web, and fill up at the rate specified - this can be thought of as a leaky bucket that is continually being filled. This is useful when bandwidth charges are in place, if we want to reduce bandwidth usage for web traffic. Delay Pools can do wonders when combined with ACLs. These tags permit us to limit the bandwidth of certain requests, based on any criteria. Delay behavior is selected by ACLs (low and high priority traffic, staff Vs students or student Vs authenticated student or so on). In ISPs, delay pools can be implemented in a particular network to improve the quality of service. To enable this, Squid needs to be configured with the --enable-delay-pools option. delay_pools delay_class delay_access delay_parameters delay_initial_bucket_level incoming_icp_average incoming_http_average incoming_dns_average min_icp_poll_cnt min_dns_poll_cnt min_http_poll_cnt max_open_disk_fds offline_mode uri_whitespace broken_posts mcast_miss_addr mcast_miss_ttl mcast_miss_port mcast_miss_encode_key nonhierarchical_direct prefer_direct strip_query_terms coredump_dir redirector_bypass ignore_unknown_nameservers digest_generation digest_bits_per_entry digest_rebuild_period digest_rewrite_period digest_swapout_chunk_size digest_rebuild_chunk_percentage chroot client_persistent_connections server_persistent_connections pipeline_prefetch extension_methods request_entities high_response_time_warning high_page_fault_warning high_memory_warning store_dir_select_algorithm ie_refresh vary_ignore_expire sleep_after_fork

TAG NAME                   delay_pools Description  Used to specify number of delay pools Built Option  --enable-delay-pools Usage  delay_pools number Default  delay_pools 0 Synopsis This represents the number of delay pools to be used.  For example, if you have one class 2 delay pool and one class 3 delays pool, you have a total of 2 delay pools. Arguments number  Number of delay pools Example(s)  delay_pools 5       TAG NAME                   delay_class Description  This defines the class of each delay pool Built Option  --enable-delay-pools Usage  delay_class pool-number class-number Default  none Synopsis Class of the delay pool used is defined using this tag. There must be exactly one delay_class line for each delay pool. There are five categories of delay classes. class 1  Everything is limited by a single aggregate bucket. class 2  Everything is limited by a single aggregate bucket as well as an "individual" bucket chosen from bits 25 through 32 of the IP   address. class 3  Everything is limited by a single aggregate bucket as well as a "network" bucket chosen from bits 17 through 24 of the  IP address and a "individual" bucket chosen from bits 17 through 32 of the IP address. class 4  Everything in a class 3 delay pool, with an additional limit on a per user basis. This only takes effect if the username is  established in advance - by forcing authentication in your http_access rules. class 5  Requests are grouped according their tag (see external_acl tag= reply). If an IP address is a.b.c.d -> bits 25 through 32 are "d" -> bits 17 through 24 are "c" -> bits 17 through 32 are "c * 256 + d" Arguments pool-number  Delay pool number class-number  Delay class number Example(s) delay_pools 2     delay_class 1 2    ( pool 1 is a class 2 pool) delay_class 2 3    ( pool 2 is a class 3 pool)       TAG NAME                   delay_access Description  This is used to determine which delay pool a request falls into Built Option  --enable-delay-pools Usage  delay_access delay_pool allow/deny domainname Default  none Synopsis The first matched delay pool is always used, i.e., if a request falls into delay pool number one, no more delay are checked, otherwise the rest are checked in order of their delay pool number until they have all been checked. Arguments delay_pool  Delay pool number allow/deny  Allow or deny access domainname  Domain name on which this should act Example(s) If you want some_big_clients in delay pool 1 and lotsa_little_clients in delay pool 2: delay_access 1 allow some_big_clients delay_access 1 deny all delay_access 2 allow lotsa_little_clients delay_access 2 deny all delay_access 3 allow authenticated_clients       TAG NAME                   delay_parameters Description  Defines the parameters for a delay pool Built Option  --enable-delay-pools Usage  delay_parameters pool aggregate (In general). For detailed format refer usage syntax bellow Default  none Synopsis Using this tag, delay parameters for each each delay pool has a number of "buckets" associated with it, as explained in the description of delay_class. Usage syntax for each class: class 1  delay_parameters pool aggregate class 2  delay_parameters pool aggregate individual class 3  delay_parameters pool aggregate network individual class 4  delay_parameters pool aggregate network individual user class 5  delay_parameters pool tag A pair of delay parameters is written restore/maximum, where restore is the number of bytes (not bits - modem and network speeds are usually quoted in bits) per second placed into the bucket, and maximum is the maximum number of bytes which can be in the bucket at any time. Arguments pool  Delay pool number - ie, a number between 1 and the number specified in delay_pools as used in delay_class lines. aggregate  the "delay parameters" for the aggregate bucket (class 1, 2, 3). individual  the "delay parameters" for the network buckets (class 3). user  user on which this condition is applied tag  the delay parameters for the tag buckets (class 5). Example(s) If delay pool number 1 is a class 2 delay pool is being used to strictly limit each host to 64kbps (plus overheads), with no overall limit, the usage is, delay_parameters 1 -1/-1 8000/8000 For a class 4 delay pool, each user will be limited to 128 Kbs no matter how many workstations they are logged into: delay_parameters 4 32000/32000 8000/8000 600/64000 16000/16000       TAG NAME                   delay_initial_bucket_level Description  Used to determine how much data is put in each bucket when Squid starts, is reconfigured, or first notices a host  accessing it Built Option  --enable-delay-pools Usage  delay_initial_bucket_level percent(0-100) Default  delay_initial_bucket_level 50 Synopsis The initial bucket percentage is used to determine how much is put in each bucket when Squid starts, is reconfigured, or first notices a host accessing it. In class 2 and class 3, individual hosts and networks only have buckets associated with them once they have been "seen" by Squid Arguments percent  Initial bucket level in percentage Example(s) delay_initial_bucket_level 20       TAG NAME                  incoming_icp_average, incoming_http_average,             incoming_dns_average, min_icp_poll_cnt, min_dns_poll_cnt,              min_http_poll_cnt Description  Using these tags, average number of ICP, HTTP requests, their polling rates can be specified Built Option  --enable-delay-pools Usage  Tagname number Default  incoming_icp_average 6  incoming_http_average 4  incoming_dns_average 4  min_icp_poll_cnt 8  min_dns_poll_cnt 8  min_http_poll_cnt 8 Synopsis INCOMING sockets are the ICP and HTTP ports.  Squid need to check these fairly regularly, but how often?  When the load increases, Squid want to check the incoming sockets more often.  If Squid have a lot of incoming ICP, then it needs to check these sockets more than if we just have HTTP.  These change of algorithms by Squid are decided by these tags. Arguments Number  Number to change the algorithm used by Squid Example(s) incoming_icp_average 3 incoming_http_average 2 incoming_dns_average 3 min_icp_poll_cnt 8 min_dns_poll_cnt 6 min_http_poll_cnt 6       TAG NAME                   max_open_disk_fds Description  Defines number of file descriptors to be handled directly Built Option  Default Usage  max_open_disk_fds number Default  max_open_disk_fds 0 Synopsis To avoid having disk as the I/O bottleneck Squid can optionally bypass the on-disk cache if more than this amount of disk file descriptors are open. A value of 0 indicates no limit. Arguments number  Maximum number of file descriptors Example(s) max_open_disk_fds 5       TAG NAME                   offline_mode Description  When enabled, Squid will never try to validate cached objects. Built Option  Default Usage  offline_mode on|off Default  offline_mode off Synopsis offline_mode gives access to more cached information than the proposed feature would allow (stale cached versions, where the origin server should have been contacted). Arguments on/off  Enable or disable offline_mode feature       TAG NAME                   uri_whitespace Description  Used to specify the action of Squid when the requests that have whitespace characters in the URI Built Option  Default Usage  uri_whitespace action Default  uri_whitespace strip Synopsis When the requested URL's contains whitespaces, them this tag is used to specify the action of Squid on that URL's. Actions are shown in the table below. Actions: strip  The whitespace characters are stripped out of the URL. This is the behavior recommended by RFC2396. deny  The request is denied.  The user receives an "Invalid Request" message. allow  The request is allowed and the URI is not changed.  The whitespace characters remain in the URI.  Note the whitespace is passed to  redirector processes if they are in use. encode  The request is allowed and the whitespace characters are encoded according to RFC1738.  This could be considered a violation of  the HTTP/1.1 RFC because proxies are not allowed to rewrite URI's. chop  The request is allowed and the URI is chopped at the first whitespace.  This might also be considered a violation. Arguments acion  Action of Squid on identifying the white spaces Example(s) uri_whitespace deny       TAG NAME                   broken_posts Description  A list of ACL elements which, if matched, causes Squid to send an extra CRLF pair after the body of a  PUT/POST  request Built Option  Default Usage  broken_posts allow|deny aclname ... Default  none Synopsis Squid will send an extra CLRF pair after the body of a PUT/POST request for the access list specified is matched. Some HTTP servers has broken implementations of PUT/POST, and rely on an extra CRLF pair sent by some WWW clients. Arguments allow/deny  Allow or deny access list aclname  Access list name Example(s) acl buggy_server url_regex ^http://.... broken_posts allow buggy_server       TAG NAME                   mcast_miss_addr Description  When enabled,every "cache miss" URL will be sent out on the specified multicast address Built Option  -DMULTICAST_MISS_STREAM Usage  mcast_miss_addr ip_address Default  mcast_miss_addr 255.255.255.255 Synopsis You will be needing the "cache miss" URL to be sent on a specified multicast address. This tag provides the option. Note: Do not enable this option unless you are are absolutely certain you understand what you are doing. Arguments ip_address  ip address through which the URL to be sent Example(s) mcast_miss_addr 172.16.1.255       TAG NAME                   mcast_miss_ttl Description  Defines time-to-live value for packets multicasted when multicasting off cache miss URLs is enabled Built Option  -DMULTICAST_MISS_TTL Usage  mcast_miss_ttl time-units Default  mcast_miss_ttl 16 Synopsis The value specified in this tag specifies the time-to-live period for packets multicated when multicasting off cache miss URLs is enabled. By default this is set to 'site scope', i.e. 16. Arguments time-units  Time to Live period Example(s) mcast_miss_ttl 10       TAG NAME                  mcast_miss_port Description   Used to define the port number to be used in conjunction with mcast_miss_addr. Built Option  -DMULTICAST_MISS_STREAM Usage  mcast_miss_port portnumber Default  mcast_miss_port 3135 Synopsis Port to be used for mcast_miss_addr. Note: This tag is used only when you enable mcast_miss_addr. Arguments portnumber  Port number on which Squid binds the socket Example(s) mcast_miss_port 3100       TAG NAME                  mcast_miss_encode_key Description  This is the encryption key used in the multicast miss stream Built Option  -DMULTICAST_MISS_STREAM Usage  mcast_miss_encode_key key Default  mcast_miss_encode_key XXXXXXXXXXXXXXXX Synopsis The URLs that are sent in the multicast miss stream are encrypted. This is the encryption key. Arguments key  Encription key to be used       TAG NAME                  nonhierarchical_direct Description  Enable/disable Squid  to send non-hierarchial requests to parents Built Option  Default Usage  nonhierarchical_direct on|off Default  nonhierarchical_direct on Synopsis By default, Squid will send any non-hierarchical requests (matching hierarchy_stoplist or not cacheable request type) direct to origin servers. If you set this to off, then Squid will prefer to send these requests to parents. Note that in most configurations, by turning this off you will only add latency to this request without any improvement in global hit ratio. If you are inside a firewall then see never_direct instead of this directive. Arguments on/off  Enable or disable sending non-hierarchal requests       TAG NAME                  prefer_direct Description  For enabling Squid to use parent if direct going is failed Built Option  Default Usage  prefer_direct on|off Default  prefer_direct off Synopsis Normally Squid tries to use parents for most requests. If you by some reason like it to first try going direct and only use a parent if going direct fails then set this to on. By combining nonhierarchical_direct off and prefer_direct on you can set up Squid to use a parent as a backup path if going direct fails. Arguments on/off  Enable or disable preferer_direct option       TAG NAME                  strip_query_terms Description  For tripping query items before logging Built Option  Default Usage  strip_query_terms on|off Default  strip_query_terms on Synopsis Squid by default does not log query parameters. These parameters are however forwarded to the server verbatim. If we want to enable logging of query parameters, the strip_query_terms directive can be used. By default, Squid strips query terms from requested URLs before logging. This protects your user's privacy Arguments on/off  Enable or disable query parameters from logging       TAG NAME                  coredump_dir Description  Squid leaves core files in the directory specified Built Option  Default Usage  coredump_dir directory Default  coredump_dir none Synopsis By default Squid leaves core files in the directory from where it was started. If you set coredump_dir to a directory that exists, Squid will chdir() to that directory at startup and coredump files will be left there. Arguments directory  Directory for used for core dump Example(s) coredump_dir /usr/local       TAG NAME