Setting Up a Proxy with Squid on RHEL 9
Squid is a mature caching proxy for controlling and monitoring web traffic on Red Hat Enterprise Linux 9. It can restrict access by network, destination, time, or user, while providing request logs that help administrators troubleshoot connectivity and policy issues.
A proxy is useful for a small office, training lab, or internal server network where clients should use one controlled gateway to reach the internet. In Australia, this can also reduce repeated downloads across sites with limited bandwidth or variable NBN performance, particularly when staff work from regional offices.
This guide configures Squid for an internal IPv4 network. The example uses 192.168.1.0/24, permits HTTP and HTTPS proxy requests, enables the firewall service, and leaves room for stricter access rules. Test the configuration before exposing the service to production users.
Prepare The RHEL 9 Host
Update package metadata and install Squid with the firewall tools:
sudo dnf update -y
sudo dnf install -y squid firewalld
Start both services and configure them to launch during boot:
sudo systemctl enable --now firewalld
sudo systemctl enable --now squid
Confirm that Squid is active:
sudo systemctl status squid
The proxy server should have a stable address, preferably through a DHCP reservation or a static NetworkManager connection. Record its address because client browsers and command-line tools will use it as the proxy endpoint.
Configure The Access Policy
Create a backup before editing the default configuration:
sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.bak
sudo vi /etc/squid/squid.conf
Find the existing acl localnet entries and add a rule matching your internal subnet. A simple policy can look like this:
acl localnet src 192.168.1.0/24
acl Safe_ports port 80
acl Safe_ports port 443
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localnet
http_access deny all
http_port 3128
Keep http_access deny all after the permitted network rule. Access rules are evaluated from top to bottom, so placing a broad allow rule too early can create an open proxy. An internet-facing open proxy is quickly abused for spam, scanning, and fraudulent activity.
Validate And Start Squid
Check the syntax before reloading the daemon:
sudo squid -k parse
No output generally indicates that parsing succeeded. If Squid reports a line number, inspect the surrounding configuration and run the command again after correcting it.
Reload the service without interrupting existing processes:
sudo systemctl reload squid
sudo systemctl is-active squid
If the service fails, review recent systemd messages and Squid’s cache log:
sudo journalctl -u squid -xe
sudo tail -n 50 /var/log/squid/cache.log
For broader Linux monitoring work, administrators can also review this Prometheus setup guide and use metrics to track host resources alongside proxy activity.
Open The Firewall Port
RHEL 9 commonly uses firewalld zones. Identify the active zone:
sudo firewall-cmd --get-active-zones
Add TCP port 3128 to the appropriate zone, replacing public if your system uses another zone:
sudo firewall-cmd --permanent --zone=public --add-port=3128/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-ports
The firewall rule should be limited by network design where possible. If the proxy serves only a private interface, avoid publishing port 3128 on an external interface. This is especially important for Australian offices using consumer routers or managed NBN equipment with automatic port forwarding features.
| Component | Example value | Purpose |
|---|---|---|
| Proxy address | 192.168.1.10 |
RHEL 9 host running Squid |
| Listening port | 3128/tcp |
Standard Squid proxy port |
| Allowed network | 192.168.1.0/24 |
Internal client subnet |
| Access log | /var/log/squid/access.log |
Requests and response status |
| Cache log | /var/log/squid/cache.log |
Startup and runtime events |
Test From A Client
Use curl from an authorised client to send a request through the proxy:
curl -I -x http://192.168.1.10:3128 https://www.example.com
A successful response confirms that the client can reach Squid and that Squid can establish the outbound connection. On the proxy, inspect the request log:
sudo tail -f /var/log/squid/access.log
A browser can use the same address and port in its manual proxy settings. For shell sessions, define temporary variables:
export http_proxy=http://192.168.1.10:3128
export https_proxy=http://192.168.1.10:3128
export no_proxy=localhost,127.0.0.1,.internal.example
Apply Practical Security Controls
Squid should generally serve known clients rather than the entire internet. Add separate ACLs for management networks, guest Wi-Fi, or restricted workstations. You can also limit access by domain:
acl approved_sites dstdomain .example.com .redhat.com
http_access allow localnet approved_sites
Place specific rules before general rules and test after every change. Avoid inspecting sensitive banking, health, or government traffic unless there is a clear legal and organisational basis. Australian organisations should account for the Privacy Act 1988, internal privacy policies, and data-handling requirements when retaining browsing logs.
Log files may contain usernames, URLs, and client addresses. Set suitable permissions, configure rotation, and restrict administrator access. A proxy policy should be communicated clearly to staff who use services such as myGov, online banking, or workplace portals.
Maintain And Troubleshoot The Proxy
Monitor disk usage because Squid logs and cache data can grow over time:
sudo du -sh /var/spool/squid /var/log/squid
sudo journalctl -u squid --since today
If a client cannot connect, verify DNS, routing, the firewall port, and the client’s proxy address. If HTTPS requests fail, check that the client is using an HTTP proxy URL with the CONNECT method rather than expecting Squid to terminate TLS.
For non-standard listening ports, SELinux may need an explicit port label. Check the current policy before changing it:
sudo semanage port -l | grep squid_port_t
Keep RHEL and Squid updated through approved repositories, and document configuration changes in the same way as other server maintenance work. A WordPress administrator may find this child theme tutorial useful for a separate web platform task, but proxy administration should remain isolated from application-layer configuration.
Complete A Safe Deployment
Before allowing all office devices to use the proxy, test with one workstation and confirm expected entries in access.log. Verify that an unapproved subnet receives an HTTP access-denied response and that the RHEL host cannot be used from the public internet.
Record the server address, allowed subnet, firewall zone, configuration backup location, log-retention period, and maintenance owner. For a Sydney or Melbourne office, compare response times during busy periods; for a regional site, check whether caching improves repeated package or documentation downloads without creating stale-content problems.
Run the final validation now with sudo squid -k parse && sudo systemctl reload squid, then test one authorised client through curl.