Uptime monitoring for Squid Proxy

Squid is one of the most widely deployed caching proxy and web gateway solutions in the world. It sits between your internal network and the internet, handling HTTP/HTTPS traffic, enforcing access policies, and caching responses to reduce bandwidth. When Squid goes down or becomes unresponsive, every client behind it loses internet access. The failure is often silent — users see "connection refused" without anyone knowing the proxy itself is the problem.

This tutorial covers production-grade uptime monitoring for Squid using Vigilmon. We will walk through:

• Monitoring the Squid TCP management port with a TCP check
• Monitoring the cachemgr HTTP interface for cache health
• Keyword checks on the cache hit ratio to catch degraded performance
• SSL-bump HTTPS interception health checks
• Heartbeat monitoring for scheduled cache clearing tasks
• SSL certificate alerts for the proxy server cert

Prerequisites

• Squid 4.x or 5.x running on Linux (bare metal or Docker)
• Access to the Squid configuration (/etc/squid/squid.conf)
• A free account at vigilmon.online

Part 1: Verify the Squid management port is reachable

Squid listens on port 3128 by default. Before adding Vigilmon checks, confirm the port is open and accepting connections from an external IP:

# From a machine outside your Squid host
nc -zv squid.example.com 3128

Expected output:

Connection to squid.example.com 3128 port [tcp/squid] succeeded!

If you need to allow external health-check probes, add a firewall rule scoped to the Vigilmon IP ranges. The Squid port itself should never be open to untrusted clients — use Vigilmon's monitoring IPs only.

Part 2: Enable the cachemgr HTTP interface

Squid includes a built-in cache manager interface (cachemgr) that exposes detailed statistics over HTTP. By default it is accessible on the same port Squid listens on, at the path /squid-internal-mgr/. Enable and restrict it in squid.conf:

# /etc/squid/squid.conf

# Allow cachemgr access from localhost and monitoring IPs
acl cachemgr_allowed src 127.0.0.1/32
acl cachemgr_allowed src 203.0.113.0/24   # Replace with Vigilmon IP ranges

# Deny cachemgr to everyone else
http_access deny !cachemgr_allowed manager
http_access allow cachemgr_allowed manager

# Standard proxy ACLs
acl localnet src 10.0.0.0/8
http_access allow localnet
http_access deny all

http_port 3128

After editing, reload Squid:

squid -k reconfigure

Verify the cachemgr info endpoint responds:

curl -s http://squid.example.com:3128/squid-internal-mgr/info | head -20

Expected output (partial):

Squid Object Cache: Version 5.7
Build Info: ...
Start Time:   Sat, 01 Jun 2026 08:00:00 GMT
Current Time: Sat, 12 Jul 2026 10:00:00 GMT
...

Part 3: Set up TCP monitoring in Vigilmon

The first and most critical check is a raw TCP connection to port 3128. This confirms Squid is alive and accepting connections even before you test HTTP behavior.

1. Log in to vigilmon.online and click Add Monitor.
2. Choose TCP monitor.
3. Enter host: squid.example.com, port: 3128.
4. Set interval to 1 minute.
5. Add your alert channel.
6. Click Save.

The TCP check fires as soon as Squid's listener goes down, before an HTTP-layer check would time out. This gives you faster alerting on hard crashes or OOM kills.

Part 4: Monitor the cachemgr HTTP interface

Add an HTTP monitor for the cachemgr /info endpoint. This confirms Squid is not just accepting TCP connections but is actually processing HTTP requests:

1. Click Add Monitor → HTTP(S) monitor.
2. Enter: http://squid.example.com:3128/squid-internal-mgr/info
3. Set interval to 1 minute.
4. Add a keyword check: must contain Squid Object Cache.
5. Add your alert channel.
6. Click Save.

The keyword check is important: a port open but returning a TCP reset (e.g., due to misconfigured ACLs) would not contain the expected text.

Part 5: Cache hit ratio keyword check

A healthy Squid proxy maintains a positive cache hit ratio. A ratio near zero can indicate that caching is broken, the cache disk is full, or Squid is running in pass-through mode due to a misconfiguration. Add a keyword check on the counters endpoint:

1. Click Add Monitor → HTTP(S) monitor.
2. Enter: http://squid.example.com:3128/squid-internal-mgr/counters
3. Set interval to 5 minutes.
4. Add a keyword check: must contain client_http.hits.
5. Add your alert channel.
6. Click Save.

The counters page reports cumulative request counts including client_http.hits (cache hits) and client_http.requests (total requests). The presence of the client_http.hits key confirms the counter is being tracked; you can add alerting logic in your own metrics pipeline using these values.

Part 6: SSL-bump HTTPS interception health check

If your Squid is configured for SSL-bump (HTTPS interception), add a monitor that tests the CONNECT tunnel works end-to-end. The simplest check is to confirm the Squid port accepts connections and returns the expected header for a CONNECT request:

# Test SSL-bump from outside
curl -v --proxy http://squid.example.com:3128 https://www.google.com/generate_204

Expected output: HTTP 204 No Content (Google's connectivity check URL).

For the Vigilmon check, monitor a known HTTPS endpoint through the proxy using Vigilmon's HTTP monitor pointed at a public URL. If SSL-bump breaks, the keyword check fails:

1. Click Add Monitor → HTTP(S) monitor.
2. Enter: https://www.google.com/generate_204 (or any always-up HTTPS endpoint).
3. Set the proxy field to http://squid.example.com:3128 if Vigilmon supports proxy-routed checks; otherwise use an internal health endpoint your Squid re-exports.
4. Set interval to 5 minutes.
5. Add your alert channel.
6. Click Save.

Alternatively, expose a small HTTP health endpoint on your internal network that Squid fetches via a cache_peer or ACL rule, and monitor that endpoint directly.

Part 7: Heartbeat monitoring for scheduled cache clearing

Many Squid deployments run scheduled cache clearing tasks — squid -k rotate to rotate logs, squidclient -h 127.0.0.1 mgr:shutdown for controlled restarts, or custom scripts using find /var/spool/squid -type f -delete. These scheduled jobs should send a heartbeat to Vigilmon so you know they ran successfully.

Create the heartbeat monitor

1. In Vigilmon, click Add Monitor → Heartbeat monitor.
2. Name it: Squid cache clear job.
3. Set the expected interval to match your cron schedule (e.g., 24 hours for a nightly clear).
4. Set grace period to 30 minutes.
5. Copy the heartbeat URL (format: https://vigilmon.online/api/heartbeat/YOUR_TOKEN).
6. Click Save.

Send the heartbeat from your cron job

Add a curl call at the end of your cache clearing script:

#!/usr/bin/env bash
# /usr/local/bin/squid-cache-clear.sh

set -euo pipefail

echo "[$(date)] Rotating Squid logs..."
squid -k rotate

echo "[$(date)] Clearing swap cache..."
# Only do this during maintenance windows — it interrupts service briefly
# squidclient -h 127.0.0.1 mgr:shutdown && sleep 5 && squid

echo "[$(date)] Signaling Vigilmon heartbeat..."
curl -fsS --retry 3 "https://vigilmon.online/api/heartbeat/YOUR_TOKEN" > /dev/null

echo "[$(date)] Done."

And schedule it in cron:

# /etc/cron.d/squid-cache-clear
0 3 * * * squid /usr/local/bin/squid-cache-clear.sh >> /var/log/squid-cache-clear.log 2>&1

If the cron job fails, the script exits before curl runs and Vigilmon never receives the heartbeat ping. When the interval lapses without a ping, Vigilmon fires a DOWN alert so you know the scheduled maintenance task failed.

Part 8: SSL certificate monitoring

If your Squid deployment uses a custom CA certificate for SSL-bump, or if you expose the cachemgr interface over HTTPS, add SSL certificate monitors so you get alerted before expiry causes connection failures:

1. In Vigilmon, click Add Monitor → SSL monitor.
2. Enter your Squid proxy's hostname: squid.example.com.
3. Set alert threshold to 14 days before expiry.
4. Add your alert channel.
5. Click Save.

If your SSL-bump configuration uses an internal CA that issues certificates dynamically, monitor the CA certificate itself:

# Check the CA cert expiry locally
openssl x509 -noout -dates -in /etc/squid/ssl_cert/squid-ca.pem

For the dynamic certificates Squid issues via SSL-bump, they are derived from the CA cert's validity period — monitoring the CA cert expiry catches the root of the problem.

Summary

Your Squid Proxy deployment now has five layers of monitoring:

1. TCP port 3128 check — immediate alert when Squid's listener goes down, polled every 60 seconds.
2. cachemgr /info HTTP check — confirms Squid is processing requests and the cache manager is healthy.
3. Cache counters keyword check — confirms the client_http.hits counter is being tracked (5-minute interval).
4. Heartbeat monitor — your nightly cache clear script pings Vigilmon; if it stops pinging, you get alerted.
5. SSL monitor — alerts you 14 days before the proxy cert or CA cert expires.

Vigilmon handles check scheduling, multi-region polling, alert routing, and uptime history. You get notified within 60 seconds of any failure at the TCP, HTTP, or certificate layer.

Monitor your Squid Proxy infrastructure free at vigilmon.online

#squid #proxy #networking #monitoring #devops