Proxy Servers: Part 6 — Squid

Squid — a free HTTP proxy with caching, one of the oldest proxy servers that is still being developed. It works as a forward proxy for network users, can cache web server responses, authenticate users, filter addresses and keep detailed request logs. Squid can also operate as a reverse proxy in front of a web server, but for that task today people usually choose Nginx or HAProxy.

Versions

The current branch is Squid 7. As of September 2026 the latest release is 7.7, published on August 24, 2026. The developers only maintain the latest stable version; older branches are maintained by distributions. Debian 12 ships Squid 5.7, Debian 13 — 6.13, and the testing branch — 7.7.

Support for the Gopher protocol was removed in Squid 6: such requests are now handled as requests with an unknown protocol. Mentions of Gopher in older guides can be ignored.

Why caching is no longer the main point

Squid was created at a time when most websites used HTTP and network links were slow and expensive. A proxy that served the same image from memory to a hundred users noticeably saved traffic.

Now almost all sites use HTTPS. For such a connection the browser sends the proxy a CONNECT command with the site name and port, after which the proxy only forwards encrypted data between the browser and the server. It does not see the content and cannot cache it. In addition, many pages are generated per user and marked by the server as non-cacheable.

Squid’s cache is still useful where traffic goes over HTTP and repeats: for example, when updating packages on many servers from mirrors served over HTTP (package integrity is verified by signatures). But for this narrow task there are also specialized programs like apt-cacher-ng.

Squid’s main value today is access control, user authorization, and accounting of web traffic. Even with HTTPS the proxy sees which site a user connects to, how much data was transferred, and when.

Installation

On Debian and Ubuntu:

sudo apt install squid apache2-utils

The package apache2-utils is needed for the htpasswd utility that creates a password file. The configuration is in /etc/squid/squid.conf, logs are in /var/log/squid/.

Configuration with authentication and filtering

Below is a configuration for an office: proxy on port 3128, access only from the local network and only with a password, block some sites and a small cache.

http_port 3128

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic children 5
auth_param basic realm Proxy
auth_param basic credentialsttl 1 hour

acl localnet src 192.168.0.0/16
acl SSL_ports port 443
acl Safe_ports port 80 443
acl CONNECT method CONNECT
acl auth proxy_auth REQUIRED
acl blocked dstdomain .example.com .example.org

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny blocked
http_access allow localnet auth
http_access deny all

cache_mem 256 MB
cache_dir ufs /var/spool/squid 10000 16 256
maximum_object_size 200 MB

How it works:

• auth_param attaches the password check program basic_ncsa_auth, which reads a file in htpasswd format;
• acl defines named conditions: client addresses (src), ports, the CONNECT method, the requirement for authentication (proxy_auth REQUIRED), destination domains (dstdomain; a leading dot means “the domain and all subdomains”);
• http_access are the access rules. They are evaluated top to bottom, the first matching rule applies, so denials are placed above allows, and the last line deny all closes everything else;
• deny CONNECT !SSL_ports prevents using the proxy as a tunnel to arbitrary ports — this is standard protection from the default configuration;
• cache_mem — amount of memory cache, cache_dir — disk cache (10000 MB), maximum_object_size — the largest object that will be stored.

The dstdomain filter also works for HTTPS: in the CONNECT command the proxy receives the site name, so domains can be blocked without decrypting the traffic.

Users and authentication:

sudo htpasswd -c /etc/squid/passwords ivan
sudo htpasswd /etc/squid/passwords olga
sudo squid -k parse
sudo systemctl restart squid
curl -x http://ivan:PASSWORD@192.0.2.10:3128 https://example.net -I

The -c option creates the file, so for the second and subsequent users do not specify it. The command squid -k parse checks the configuration before restart, and after small changes instead of restarting it is enough to run squid -k reconfigure.

Client configuration

• Computers of employees. The proxy is set in the system network settings, and browsers take it from there. In networks with Active Directory the proxy address is distributed by group policies. For flexible rules (which addresses go through the proxy and which go directly) a PAC (Proxy Auto-Config) file is used.
• Servers and console programs. Most utilities understand the environment variables http_proxy and https_proxy, for example https_proxy=http://ivan:PASSWORD@192.0.2.10:3128. For apt the proxy is set separately, with the line Acquire::http::Proxy "http://192.0.2.10:3128"; in a file under /etc/apt/apt.conf.d/.
• Exceptions. Internal addresses and services on the local network usually go directly, bypassing the proxy: the no_proxy variable or the corresponding field in system settings.

Traffic accounting

Each request is logged in /var/log/squid/access.log: time, duration, client address, result, response size, method, address and username. From the result field you can see what happened to the request:

• TCP_TUNNEL — HTTPS connection via CONNECT, the proxy only forwarded data;
• TCP_MISS — object was not in the cache, it was fetched from the server;
• TCP_HIT and TCP_MEM_HIT — response served from the cache;
• TCP_DENIED — request denied by rules.

Reports per users and sites are generated from the log — manually or with Squid log analyzers like SARG. Limiting bandwidth for users or groups is possible with delay pools (delay_pools).

SslBump: decrypting HTTPS

To cache and filter the content of HTTPS pages, not just site names, Squid has the SslBump mechanism. The proxy acts as a man-in-the-middle: it decrypts the connection, inspects the content, and re-encrypts it with a certificate it issues itself. To avoid browser warnings the proxy’s root certificate must be installed on all client devices. In Debian this requires the squid-openssl package.

Since version 3.5 Squid has a peek-and-splice mode. The proxy “peeks” at the start of the TLS connection, where the site name (SNI) is transmitted, and decides what to do next: decrypt the connection (bump), allow it without decryption (splice) or terminate it. The ssl::server_name rule allows, for example, skipping decryption for banks and government services.

Before enabling decryption, consider the consequences:

• Law and ethics. HTTPS exists so that a user’s communication is not read by others. Squid’s documentation explicitly warns that decrypting HTTPS without users’ knowledge and consent may violate ethical norms and the law. In a company this is only acceptable with an approved policy and notification to employees, and personal devices should not be decrypted.
• Security. A proxy holding the private key of the root certificate becomes the most valuable object in the network: its compromise exposes all traffic.
• Compatibility. Applications that strictly validate the server certificate (certificate pinning) will stop working through a decrypting proxy.

If you only need to block sites by name, decryption is not required: dstdomain in explicit proxy mode or ssl::server_name with action splice is sufficient.

Common mistakes

• Allow rule placed above a deny. Squid stops at the first matching http_access, so deny blocked below allow localnet will not work.
• Missing http_access deny all at the end. If no rule matches, Squid applies the action opposite to the last rule in the list. Behavior becomes non-obvious, so the final rule is always written explicitly.
• Open proxy. allow all without address restrictions turns the server into an open proxy, which will quickly be discovered and used by outsiders.
• Cache not initialized. After adding cache_dir the cache directories are created with squid -z; on Debian the service startup script does this, but when installing manually the step is easy to miss.
• Password sent in plaintext. Basic authentication sends the password unencrypted. Inside an office network this is usually acceptable; over the Internet — not.

Advantages and limitations

Advantages:

• flexible access rules by addresses, users, domains, time and content types;
• authentication via password file, LDAP and Active Directory;
• detailed request logs and ready-made analyzers for reports;
• bandwidth limitation via delay pools;
• mature project with extensive documentation.

Limitations:

• caching helps little with HTTPS, and full HTTPS handling requires decryption with all its consequences;
• large and not the simplest configuration file;
• as a reverse proxy and load balancer it is outperformed by Nginx and HAProxy;
• disk cache requires space and memory.

When to choose Squid

Squid is suitable when you need to let employees access the internet with a password, block certain sites and get reports about who accessed which resources and how much. If you only need a SOCKS5 proxy for applications — Dante is simpler; if you need HTTP and SOCKS proxies with traffic limits for several users — 3proxy.