A collection of practical advice for running the CloudSOE Squid image in production, on either cloud.
Reading the structured access log
The image replaces Squid’s terse native log format with one key=value line per request in /var/log/squid/access.log:
[04/Jul/2026:10:15:01 +0000] url="https://archive.ubuntu.com/..." status=200 http_method=GET request_protocol=HTTP/1.1 http_user_agent="Debian APT-HTTP/1.3" response_time=42 dns_lookup_time=3 src_ip=10.0.1.15 src_port=51234 dest_ip=185.125.190.36 dest_port=80 bytes=51234 ... vendor_action=TCP_MEM_HIT dest_status=HIER_NONE
The two fields worth learning: vendor_action is Squid’s result code (TCP_MISS fetched from origin, TCP_MEM_HIT/TCP_HIT served from cache, TCP_DENIED blocked by an ACL) and status is the HTTP status returned to the client. Quick triage:
sudo grep -c 'vendor_action=TCP_DENIED' /var/log/squid/access.log
sudo awk -F'src_ip=' '{print $2}' /var/log/squid/access.log | cut -d' ' -f1 | sort | uniq -c | sort -rn | head
Because the format is key=value, the log also drops straight into CloudWatch Logs, Azure Monitor or any SIEM without a custom parser.
Monitor with cache-manager pages
Squid’s cache manager is reachable from localhost only (the shipped ACLs allow localhost manager and deny everyone else):
sudo apt install squidclient
squidclient mgr:info # uptime, request rates, hit ratios
squidclient mgr:5min # rolling 5-minute averages
squidclient mgr:utilization
squidclient mgr:objects | head
mgr:info hit-ratio numbers are the fastest way to tell whether your cache is earning its keep.
Cache tuning
The shipped config caches in memory only. Two directives to add to /etc/squid/squid.conf once you’ve enabled a disk cache (see the configuration guide):
cache_mem 512 MB
maximum_object_size 512 MB
cache_mem sizes the in-memory hot-object cache (keep it well under the instance’s RAM — Squid’s total footprint is larger). Raise maximum_object_size if you want the proxy to cache OS images or large packages. The image already raises the open-file limit to 65535, so busy proxies won’t hit nofile exhaustion.
Log rotation
A cron job runs /usr/sbin/squid -k rotate at midnight, so access.log rolls over daily. Check retention on a busy proxy — rotated logs accumulate in /var/log/squid/ and a chatty fleet can fill the disk. Ship them to object storage and prune.
Re-check that you’re not an open proxy
Worth repeating from the getting-started guides: an open proxy is found and abused within hours. Verify from a machine outside your trusted ranges (e.g. your laptop on a mobile hotspot):
curl -x http://<public-ip>:3128 -sI https://www.example.com/ --max-time 10
The connection should time out (security group / NSG blocks it) or return 403 with vendor_action=TCP_DENIED in the log (Squid’s ACLs blocked it). If you ever see 200, fix your firewall rules before doing anything else. Adding basic authentication (see the configuration guide) gives you a third layer.
Point package managers at the proxy
The shipped config includes apt-aware refresh_pattern rules, so a fleet of servers doing apt upgrade through the proxy gets real cache hits. On each client:
echo 'Acquire::http::Proxy "http://<squid-private-ip>:3128";' | sudo tee /etc/apt/apt.conf.d/01proxy