Squid Proxy Server with Traffic Reporting and Access Control via Web GUI

A self hosted Squid caching proxy for teams that must control outbound web traffic and account for it afterwards. Squid 7.6 is compiled from source on Ubuntu 24.04 and paired with a management console (CloudInfra Proxy Manager), so it is run from a browser rather than by editing squid.conf.

This Squid proxy server comes with a full management console, filter and block websites, control outbound internet access, authenticate users against Active Directory or LDAP, cache repeated downloads, and see every request your network makes, with configuration changes that validate before they deploy and roll back automatically if they fail.

A caching forward proxy for HTTP and HTTPS. HTTPS is carried as CONNECT tunnels, logged by host and port. It listens on port 3128 by default, and the port is configurable. Clients are pointed at the proxy explicitly, through proxy settings or environment variables, so nothing is intercepted without your knowledge.

Caching is configurable from the console: disk cache location and size, memory cache size, and maximum object size. Cache hit rate is measured over cacheable requests only, so it is not flattered by encrypted tunnels: fifty instances pulling the same packages fetch them once. Visible hostname, DNS resolvers, connect timeout and access logging are settings, not file edits.

Rules are built from access control lists and evaluated in order, stopping at the first match, as Squid does.

Source: any client, an IP address, a network in CIDR notation, a named network group, a directory user, or a directory group. Destination: anywhere, a domain, a network in CIDR notation, or a named domain list. Action: allow or deny.

Named lists of domains and networks are reused across rules, so one edit updates every rule referring to the list, and large lists are read by Squid from disk. The console shows the evaluation order and reads each rule back as a sentence before you apply it, so a rule doing the opposite of what you meant is visible beforehand.

Proxy authentication against Active Directory, Microsoft Entra Domain Services or OpenLDAP. Connect over LDAPS on port 636, encrypted from the first byte, or StartTLS on port 389, which fails rather than continuing in clear text. Set the base DN, bind DN and user filter from the console; the bind password is stored outside the world readable configuration file. Install your directory certificate authority so the connection validates, and referrals are followed so multi domain forests resolve.

Rules can then name individual users or directory groups, including names containing spaces. Usernames are recorded alongside requests, so reports name people, not IP addresses.

Microsoft publishes the address ranges its services use and changes them regularly. The appliance retrieves that list and keeps the matching policies current, so a Microsoft 365 rule does not go stale.

Requests, allowed and blocked counts, bytes transferred and cache hit rate, all computed from Squid own access log rather than estimated. Break traffic down by destination, client, user or rule, and search the record, so a question about one host on one afternoon has an answer. A live view shows current activity and the raw logs are readable in the console.

Every change is parsed by Squid itself before installation. The running configuration is snapshotted, the new one installed, then reloaded without dropping connections where possible. The proxy is then health checked by putting a real request through it, and if that fails the snapshot is restored without being asked. Where a fault comes from one of your rules, the message names it. Configuration history, versions, an audit log, backup and restore are included.

The console runs on port 8443 behind TLS. Its certificate and the administrator password are generated on your instance at first boot, so no two instances share them, and the password must be changed at first sign in. Replace the certificate with your own: the pair is validated first, it takes effect without a restart, and the previous one is restored if the new one fails to load.

Request history stays on the appliance own disk inside your VPC. The software calls no vendor service, reports no usage and checks no licence.

The generated squid.conf is ordinary, readable Squid configuration. The file /etc/squid/local.conf is yours: never generated, never overwritten, untouched by rollback, so directives such as cache peers and refresh patterns survive every update. Access rules are the exception and belong in the console, because local.conf is read after the default deny.