Miscellaneous Options

Miscellaneous Options is just what it sounds like. A hodgepodge of options that don’t seem to fit anywhere else. Here you’ll find several memory related options, options regarding headers and user agent settings, and the powerful HTTP accelerator options.

Figure 12-17. Miscellaneous Options


Startup DNS test addresses, should point to a number of hosts that Squid can use to test if DNS service is working properly on your network. If DNS isn’t working properly, Squid will not be able to service requests, so it will refuse to start–with a brief message regarding why in the cache.log. It is recommended that you select two or more hostnames on the internet and one or two hostnames on your intranet, assuming you have one and Squid is expected to service it. By default, the dns_testnames directive checks a few well known and popular sites: netscape.com, internic.net, nlanr.net, and microsoft.com.

SIGUSR1 logfile rotations is the number of old rotated log files Squid will keep. On Red Hat systems, this option defaults to zero, as logs are rotated via the system standard logrotate program. On other systems, this defaults to 10, which means Squid will keep 10 old log files before overwriting the oldest. This option corresponds to the logfile_rotate directive.

Default domain is the domain that Squid will append to requests that are not possibly fully qualified domain names (more precisely, those that have no dots in them). This option correlates to the append_domain directive.

Error messages text provides a means to almost automatically add some extra information to Squids error pages. By adding an email address or website link to this field, and editing all of the error pages found in the errors directory in your Squid directory, this text can be added to every error message. Editing the error pages simply requires inserting a %L tag in the error template file. This option correlates to the err_html_text directive.

Per-client statistics? allows you to choose whether Squid will keep statistics regarding each individual client. This option configures the client_db directive and defaults to on.

X-Forwarded-For header? This option allows you to choose whether Squid will report the hostname of the system that originally made the request to the origin server. For example, if this option is disabled every request through your cache will be reported as originating from the cache. Usually, this should remain enabled. This correlates to the forwarded_for directive and defaults to on.

Log ICP queries? simply dictates whether Squid will log ICP requests. Disabling this can be a good idea if ICP loads are very high. This option correlates to the log_icp_queries directive and defaults to on.

Minimum direct hops. When using ICMP pinging features of Squid to determine distance to peers and origin servers, this dictates when Squid should prefer going direct over a peer. This option requires you Squid to have been compiled with the --enable-icmp, and you must be in a peering relationship with other Squid caches, also with that option compiled in. This option correlates to the minimum_direct_hops directive.

Keep memory for future use? This option turns on memory_pools and allows Squid to keep memory that it has allocated (but no longer needs), so that it will not need to reallocate memory in the future. This can improve performance by a small margin, but may need to be turned off if memory is at a premium on your system. This option defaults to on and should generally be left on, unless you know what you’re doing.

Amount of memory to keep is the amount of memory Squid will keep allocated, assuming the Keep memory for future use option is turned on. This option configures the memory_pools_limit directive, and defaults to unlimited. Any non-zero value will instruct Squid not to keep more than that amount allocated, and if Squid requires more memory than that to fulfill a request, it will use your system’s malloc library. Squid does not pre-allocate memory, so it is safe to set this reasonably high. If your Squid runs on a dedicated host, it is probably wisest to leave it to its default of unlimited. If it must share the system with other server processes (like Apache or Sendmail) then it might be appropriate to limit it somewhat.

Headers to pass through configures the anonymizing features of Squid. This option allows you to dictate what kinds of request headers are allowed to pass through Squid. For example, to prevent origin servers from being able to detect the type of browser your clients are using you would choose to allow all except User-Agent. This option has mostly obscure uses and usually doesn’t need to be changed from its default of allowing all headers to pass through. There is a relevant Squid FAQ section that describes in more detail what can be accomplished with this option. This option corresponds to the anonymize_headers directive and defaults to allow All headers.

Fake User-Agent acts as an addition to the above option, in that it allows you to configure Squid to report a faked User-Agent header. For example, using this option you could have your Squid report that every client being served is named Mozilla/42.2 (Atari 2600; 8-bit). That would be lying, but perhaps the person looking over the logs at origin servers will find it amusing. If you are using the anonymize headers features to hide your clients User-Agent headers, it is probably wise to include a fake User-Agent header because some servers will not be happy with requests without one. Further, this will cause problems with some web pages for your users, as the User-Agent header is sometimes used to decide which of a number of pages to send based on the features available within a particular browser. The server will usually end up choosing the least interesting page for your clients (i.e. text only, or no Javascript/Java/etc.).

HTTP Accel Host and Port are the options you will use to configure Squid to act as an accelerator, or as a transparent proxy. When using your Squid as an accelerator, you must configure these two options to point to the IP and port of the web server you are accelerating. If you are using Squid to accelerate a number of virtual hosts, you must choose virtual as the Accel Host. Note that this opens potential security problems, in that your Squid will then be open to users outside of your network as a proxy. This can be avoided via proper firewall rules on your router or on the Squid system itself. Finally, if you are operating your Squid transparently, you would also configure the Accel Host to be virtual and the Accel Port to be 80. Outgoing port 80 traffic will then need to be redirected to your Squid process in order for it to work. This is discussed in much greater detail in the and sections. These options configure the httpd_accel_host and httpd_accel_port directives.

HTTP Accel with Proxy allows you to operate your cache as both an accelerator and a caching proxy. This option tells Squid to accept both traditional proxy connections as well as requests intended for an origin web server. This option correlates to the httpd_accel_with_proxy.

HTTP Accel Uses Host Header configures Squid to use the host header information as described in the HTTP 1.1 specification. This option must be turned on for transparent operation, in order for virtual servers to be cached properly. This option correlates to the httpd_uses_host_header directive.