Squid Caching Proxy

Squid is a mature, cross-platform caching proxy that can save bandwidth, reduce latency, enforce access rules, and give an overloaded network a little more breathing room.

Today, a lot of public-site caching happens at the CDN, inside a reverse proxy such as NGINX or Varnish, or through framework-level caches that understand the application. Squid still matters, but it belongs in a specific part of the stack: explicit proxying, controlled egress, internal caching, access-control policy, and networks where the administrator wants to inspect and shape outbound HTTP traffic.

A proxy cache can postpone a hardware purchase by making repeated traffic stop hitting the origin every time. That effect is real, and it is also easy to mistake "cache hit" for "the application is healthy." The cache can hide load, and it can also hide bugs.

What Squid Is

Squid is a proxy server with caching support. In a forward-proxy setup, clients send requests through Squid on their way to the internet or another network. In a reverse-proxy or accelerator setup, Squid sits in front of origin services and serves cached responses when the rules allow it.

Those jobs look similar on a diagram, but they solve different operational problems.

Forward proxying is about clients and policy:

• which users or networks may make requests
• which destinations are allowed or blocked
• how traffic is logged
• how authentication and access-control lists work
• whether repeated external responses can be cached safely

Reverse-proxy caching is about protecting the origin:

• which responses can be reused
• how cache keys are formed
• how long content stays fresh
• what happens when the origin is unavailable
• how private, authenticated, or user-specific responses are kept out of shared cache

Squid can participate in both patterns, but modern public web stacks often choose a CDN or NGINX-style reverse proxy for origin shielding. That shift does not make Squid obsolete; it narrows the reason to choose it.

Cache Only What Is Safe to Reuse

Caching is a contract between the application, the proxy, and the client. HTTP headers such as Cache-Control, ETag, and Vary are not decoration. They describe whether a response can be reused, for whom, and under which request conditions.

Static assets are usually simple, while user-specific pages are where shared cache gets dangerous. Anything tied to a session, permission check, shopping cart, account page, admin view, or personalized API response deserves caution.

For a small PHP site, this means the app needs to be clear about response type before a proxy is allowed to help:

<?php

header("Cache-Control: public, max-age=3600");
echo renderPublicDocumentationPage($slug);

That is a very different response from this one:

<?php

header("Cache-Control: private, no-store");
echo renderAccountDashboard($userId);

The proxy cannot guess your business rules. If the application sends vague headers, the cache layer becomes another place where mistakes can survive for a long time.

ACLs Are the Serious Part

Access-control lists are the part that deserves the most attention, and the reason is auditability. A proxy that controls network traffic needs rules a human can read and check.

The audit questions are plain enough to write down:

• Which source networks may use the proxy?
• Which destinations are blocked?
• Which ports are allowed?
• Which users authenticate through it?
• Which requests are logged, and who can read those logs?

The dangerous configuration is an open proxy. If a machine on the public internet accepts proxy traffic from anyone, it can become someone else's traffic relay, so rule that out before admiring the cache.

Start with the narrowest client network that should use the proxy, then widen only with a reason. In the LAMP years, people often installed infrastructure first and wrote the policy later, and that habit aged badly.

When Squid Still Fits

Use Squid when the proxy itself is part of the requirement.

The better use cases are the ones where proxy behavior is part of the requirement:

• a lab, school, office, or internal network that needs outbound web policy
• legacy environments where client devices are configured to use a forward proxy
• bandwidth-sensitive links where repeated downloads still matter
• egress logging for servers that should not reach the internet directly
• a controlled cache for package mirrors, documentation, or internal HTTP resources

Weaker fits include ordinary public-site acceleration when a CDN or reverse proxy already handles edge caching, TLS termination, origin shielding, and purge workflows. Squid can still do the work, but it may not be the cleanest operational choice.

What to Measure

After the proxy is running, the practical question is whether it changed the system in the way you expected. Watch cache hit ratio, latency, origin request count, error responses, denied traffic, and disk pressure.

That links this page to server statistics and observability. A cache that reduces origin load while increasing user-facing latency is not a win. A proxy that saves bandwidth while hiding authentication mistakes is worse.

A Practical Checklist

Before putting Squid into a live path, check the boring parts:

1. Confirm whether this is a forward proxy, reverse proxy, or both.
2. Restrict allowed client networks before testing with real traffic.
3. Keep private and authenticated responses out of shared cache.
4. Set application cache headers deliberately.
5. Log enough to diagnose misuse without storing more personal data than needed.
6. Measure hit ratio, origin load, latency, disk use, and denied requests.
7. Document how to bypass the proxy during an incident.

The last item belongs in the server contingency plan. A proxy can make a system faster and more controllable. It can also become the single box everyone forgets until every request depends on it.

Frequently Asked Questions

What is the difference between a forward proxy and a reverse proxy?

A forward proxy sits in front of clients and fetches the internet on their behalf, which is Squid's traditional role. A reverse proxy sits in front of servers and represents them to the world. The direction of trust is what differs.

Can Squid cache HTTPS traffic?

Not the contents, unless it terminates TLS and re-encrypts, which means installing a certificate authority on every client and inspecting private traffic. Most deployments tunnel HTTPS untouched, which is why caching value has fallen as the web moved to TLS.

Is a CDN a replacement for Squid?

For public assets served to the internet, usually yes. Squid remains useful where a CDN cannot reach: outbound traffic from a private network, environments with metered links, and places where policy requires the organisation to control the egress path.

How much memory does Squid need?

Enough for the in-memory cache plus roughly ten megabytes of index per gigabyte of disk cache, so a large disk cache has a real memory cost. Size it from your working set rather than the disk you happen to have.

Is Squid still actively maintained?

Yes. It remains an actively developed open-source project with regular releases and security advisories. Track those advisories: a proxy sits in the traffic path, so a vulnerability there affects every client behind it.

Related Guides

• Ops and server administration - caching, observability, and recovery planning.
• Server statistics and observability - measuring whether the cache helped.
• Server contingency planning - bypass and recovery paths for infrastructure failures.
• PHP and MySQL with PDO - the database boundary that caching should not blur.

This page has been updated from the original CodeWalkers Squid article, written when a caching proxy was a standard answer for public-site acceleration. That role has mostly moved to CDNs and reverse proxies, so the guidance here covers the cases where an explicit forward proxy is itself the requirement.