Configuring Squid Directly¶
The console manages access rules, URL lists, directory authentication, proxy settings and the apply/rollback pipeline. Squid itself can do a great deal more, and everything it supports can be configured by hand.
This section covers the capabilities people ask for most often that the console does not manage. For what is planned and what is deliberately not, see the roadmap.
Where your own directives go¶
/etc/squid/local.conf is yours. The console never generates it, never
overwrites it, and a configuration rollback never touches it. Anything you put
there survives every update.
sudo nano /etc/squid/local.conf
sudo squid -k parse # validate - prints nothing if the file is good
sudo squid -k reconfigure # apply without dropping connections
Use sudo systemctl restart squid only when reconfigure is not enough — after
changing http_port or cache_dir, for example.
Access rules do not work in local.conf
local.conf is included at the end of squid.conf, after the default
http_access deny all. Squid evaluates http_access lines in order and
stops at the first match, so an http_access allow … line placed in
local.conf is never reached.
This catches people following Squid tutorials, because almost every one of
them ends with an http_access allow line.
What works in local.conf: auth_param, acl, deny_info,
external_acl_type, cache_peer, forwarded_for, dns_v4_first, refresh
patterns, tuning — anything that is not order-sensitive.
What does not: http_access, and the other access list families
(http_reply_access, cache, adapted_http_access).
For those, either write the rule in the console — which is the supported route,
and gets you validation, history and automatic rollback — or edit
/etc/squid/squid.conf directly above the default deny, accepting that the
console will overwrite it on the next apply.
Which file is which¶
| Path | Owner | Survives an apply? |
|---|---|---|
/etc/squid/squid.conf |
Generated by the console | No — regenerated every apply |
/etc/squid/local.conf |
You | Yes |
/etc/squid/conf.d/10-localnet.conf |
First boot — detected client networks | Yes, but see below |
/usr/lib/squid/ |
The image — helper programs | Yes |
10-localnet.conf is the odd one. It is written once, at first boot, by the
cloud metadata detection — the console never regenerates it, so an edit there
does survive an apply.
The catch is that it does not survive the instance. A replacement appliance launched from the same image writes its own on first boot, and your edit is not carried over. If a client network needs to persist across instances, add it in the console as a client network instead, where it lives in the configuration and travels with a backup.
conf.d is not a drop-in directory
squid.conf includes that one file by explicit path, not
conf.d/*.conf. Another file dropped alongside it is not read. Use
local.conf for your own directives.
If you are running the image without the console, squid.conf is yours to
edit directly and none of the caveats above apply.
Before you reach for local.conf¶
Check whether the console already does it. Configuration written by hand gets no validation, no version history, and no automatic rollback if the proxy fails to start — the three things the console exists to provide.
| You want to | Use |
|---|---|
| Allow or block destinations | Access Rules |
| Maintain a list of domains | URL Filtering |
| Authenticate against AD or LDAP | Directory Authentication |
| Change the port, DNS or timeouts | Proxy Settings |
| Add client networks | Proxy Settings |
In this section¶
| Page | What it covers |
|---|---|
| HTTPS and CONNECT | What the proxy can and cannot see of encrypted traffic |
| Authentication Backends | RADIUS and local password files |
| Custom Block Page | Showing your own page when a request is denied |
| Caching | What caches, tuning it for package repositories, and sizing |
| IPv6 | Accepting IPv6 clients and reaching IPv6 destinations |
| High Availability | Running more than one proxy |