What's changed: Initial version (topic 2.09, subtopics 2.09.1–2.09.4)
3.4Configuring and Managing Squid
Learn the basics of Squid, a forward proxy software: its configuration file squid.conf, the squidclient tool for testing, the http_access directive that controls access, and acl (access control lists) that define its conditions.
Squid is a leading implementation of a forward proxy, sitting between internal clients and the external web sites they access. The way acl and http_access compose conditions for "who" can access "where" is central to expressing an organization's network access policy.
3.4.1Configuration file and testing
- The main configuration file is squid.conf, where you specify the ports Squid listens on as a proxy, cache size, access control rules, and more.
- squidclient is a command-line tool that sends requests directly to Squid, used to verify behavior and manipulate the cache (e.g., purging entries).
3.4.2Access control with acl and http_access
- The acl directive names a condition such as a source network, time window, or destination domain (e.g.,
acl localnet src 192.168.1.0/24). - The http_access directive decides
allowordenyfor a defined acl, evaluated top to bottom. The first matching rule wins, so the order in which rules are written determines the outcome.
The most frequent points: http_access is evaluated top to bottom, and the first matching rule applies; acl itself does not allow or deny anything—it only defines a condition; the actual allow/deny decision is made by http_access. Forgetting a trailing http_access deny all (leaving everything unintentionally allowed) is also a classic exam scenario.
Build a typical squid.conf that allows proxy use only from the internal network and denies everything else. First, acl localnet src 192.168.1.0/24 names the internal address range localnet. Next, http_access allow localnet allows traffic matching localnet, and finally http_access deny all denies everything else. The key point is that http_access rules are evaluated in the order written, and processing stops at the first matching condition. If http_access deny all were written before http_access allow localnet, traffic from localnet would also be denied. Conversely, forgetting the trailing deny all leaves the handling of unmatched traffic ambiguous, risking an accident where external use is unintentionally allowed. After changing the configuration, reload or restart the Squid process, then send test requests with squidclient to confirm the allow/deny behavior matches expectations. Keeping in mind that acl merely "names a condition" and does not itself control access—access control is http_access's job—removes ambiguity when reading a configuration file.
| Element | Role | Example |
|---|---|---|
| squid.conf | Main configuration file | Ports, cache, rules |
| acl | Names a condition (does not itself allow/deny) | acl localnet src 192.168.1.0/24 |
| http_access | Evaluates allow/deny against acls in order | http_access allow localnet |
| squidclient | Testing and cache operations | Sends requests directly |
Trap: "the acl directive alone can deny access" is wrong—acl only names a condition; the actual allow/deny decision is made by http_access. Also wrong: "http_access prioritizes the most specific condition regardless of order"—it is evaluated top to bottom, and the first matching rule applies as-is, so placing deny all before an allow rule breaks the intended access.
3.4.3Section summary
- Configuration in squid.conf; testing via squidclient
- acl only names a condition; http_access decides allow/deny, evaluated top to bottom (ending with
deny allis standard practice)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Which Squid configuration correctly allows access only from the internal network 192.168.1.0/24 and denies everything else?
Q2. Which statement about the evaluation order of Squid's http_access directive is correct?
Q3. After changing Squid's configuration, you want to send an actual request to verify the allow/deny behavior. Which tool should you use?