Squid Server Configuration: Secure Setup Guide

Q: Where is squid.conf located?

Package installations commonly use /etc/squid/squid.conf; source installations may use /usr/local/squid/etc/squid.conf. Check squid -v, the service definition, and squid -k parse output to confirm the file used by the running instance.

Q: Can Squid authentication be used in transparent mode?

No. Squid's official auth_param reference states that authentication is disabled on transparent, intercept, or TPROXY ports because the client believes it is communicating directly with the origin server. Use an explicit proxy configuration when authentication is required.

Q: How do I check a Squid configuration before restart?

Run sudo squid -k parse and fix every syntax or fatal configuration error before reloading. Keep a known-good copy and confirm that the running service uses the same configuration path you validated.

A Squid server is a forward proxy that accepts requests from approved clients, applies access rules, and connects to the destination on their behalf. A safe configuration begins with a small allowlist, a host firewall, an explicit final deny rule, and one test client. Do not expose port 3128 to the public internet and assume a password alone makes the service safe.

This guide builds a controlled HTTP and HTTPS-forwarding setup on Linux, validates it before reload, tests it with curl, and separates access-control, authentication, DNS, and network failures. The examples use a private network; replace every sample address with the actual subnet or individual source IP that you administer.

Authorized clients connecting through Squid ACL, authentication, and firewall controls — Authorized clients pass through access, authentication, and firewall controls before Squid reaches the web.

Quick answer

Install Squid, keep a known-good copy of squid.conf, permit only trusted client addresses, end the access list with http_access deny all, restrict the listening port in the host or cloud firewall, and run squid -k parse before reloading. Add authentication only after the IP-restricted configuration works. Then test one request and read both access.log and cache.log before expanding access.

The official Squid configuration FAQ recommends starting with a simple known-good configuration and adding complexity gradually. That approach matters: changing ACLs, authentication, firewall rules, and DNS at the same time makes a single 403 or timeout much harder to diagnose.

Decide what the Squid server should allow

Decision	Record before editing	Safe starting point
Clients	Exact source IPs or private subnet	One workstation or one controlled LAN
Listening address and port	Server interface and TCP port	Port 3128 on a private or firewalled interface
Destinations	Required HTTP/HTTPS ports or domains	Web ports only, then add exceptions deliberately
Authentication	IP allowlist, username/password, or both	Source restriction first; authentication as a second control
Logs	Retention, permissions, and review owner	Keep access and service errors available during rollout
Change recovery	Known-good file and maintenance window	Parse before reload and retain the previous configuration

Squid in this article is a forward proxy for client traffic. It is not the same deployment role as a reverse proxy placed in front of an application. Review the forward proxy vs reverse proxy guide before choosing software for an inbound web service.

Install Squid and find squid.conf

Use the package supplied by the Linux distribution so service files, log paths, and updates remain consistent with that system. On Debian and Ubuntu, the package is commonly installed with:

sudo apt update
sudo apt install squid apache2-utils

On RHEL-family systems, the package manager normally provides squid, while the utility containing htpasswd is commonly named httpd-tools. Confirm the current package names in the distribution documentation rather than copying a command for a different release.

The main file is usually /etc/squid/squid.conf. Source installations may use /usr/local/squid/etc/squid.conf; the official configuration page lists both common locations. Check the running binary and compiled paths before editing:

squid -v
sudo squid -k parse

Create a restricted backup before making a change:

sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.known-good
sudo chmod 600 /etc/squid/squid.conf.known-good

If the active configuration is elsewhere, pass it explicitly with the binary’s -f option instead of editing an unused file.

Start with a minimal secure Squid configuration

The following example allows web traffic from the private subnet 10.0.0.0/24. Replace it with the smallest client range you control. If only one workstation needs access, use its single address with a /32 prefix.

http_port 3128

acl trusted_clients src 10.0.0.0/24
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow trusted_clients
http_access deny all

Squid evaluates http_access rules in order. The first applicable decision controls the request, so broad allow rules placed too early can bypass later restrictions. The official http_access reference recommends a final deny-all rule because an unmatched request otherwise follows behavior derived from the final access line. Keep the last line explicit even when the current rules appear restrictive.

The two port checks prevent ordinary requests to unapproved ports and prevent the HTTP CONNECT method from tunnelling to anything except the declared TLS port. Add another destination port only when a documented application needs it. Do not copy a large permissive port list merely to make one failed request disappear.

Add username and password authentication

Get the IP-restricted configuration working before adding credentials. For a small controlled deployment, Squid’s NCSA helper can read an htpasswd file. The helper path varies by distribution, so locate the installed basic_ncsa_auth binary before placing it in the configuration.

sudo htpasswd -c /etc/squid/passwd proxyuser
sudo chown proxy:proxy /etc/squid/passwd
sudo chmod 640 /etc/squid/passwd

Use -c only when creating the file; running it again while adding a user replaces the existing file. The service account can be named differently on the installed system, so confirm it before changing ownership.

Add the helper and require both the trusted source and a valid account:

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic realm Restricted Squid proxy
acl authenticated proxy_auth REQUIRED

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow trusted_clients authenticated
http_access deny all

The official auth_param reference explains that defining a helper does not activate authentication by itself; a proxy_auth ACL must be evaluated by an access rule. It also notes that authentication is unavailable on transparent interception ports. A 407 response is therefore often an access-rule or helper problem rather than a dead proxy.

Basic proxy authentication is not a substitute for network isolation. On an untrusted path, use a private network, VPN, or appropriately secured transport architecture, and keep the host firewall restriction in place. The proxy authentication guide compares credential and source-IP authorization for client applications.

Restrict port 3128 at the firewall

An ACL decides which requests Squid serves after a connection reaches it. A firewall reduces who can reach the service at all. Apply both controls at the host and, for a cloud server, in its security group or network firewall.

For example, a UFW-managed host can allow the trusted private subnet and deny other connections to the proxy port:

sudo ufw allow from 10.0.0.0/24 to any port 3128 proto tcp
sudo ufw deny 3128/tcp
sudo ufw status numbered

Firewall order and management tools differ. Inspect the effective rules from an unauthorized network as well as the trusted client. If the proxy is reachable from the public internet, close the exposure before troubleshooting application behavior. Password prompts are not proof that the network boundary is correct.

Validate and reload the configuration

Parse the complete configuration before asking the running service to use it:

sudo squid -k parse

The official Squid installation FAQ documents -k parse as the configuration syntax check. Treat any reported syntax error or fatal misconfiguration as a stop condition. Do not reload repeatedly in the hope that a broken directive is ignored.

When parsing succeeds, use the service manager or Squid’s reconfigure signal:

sudo systemctl reload squid
sudo systemctl status squid --no-pager

If the service package does not expose a reload action, use:

sudo squid -k reconfigure

Authentication helpers can have version-specific restart behavior. If an authentication scheme was removed or materially changed and reconfiguration does not apply it, plan a controlled service restart and verify existing client impact.

Test the Squid proxy with curl

Start from one trusted client. First confirm the port is reachable, then make a simple HTTPS request through Squid. This example assumes the server has private address 10.0.0.10:

curl --proxy http://10.0.0.10:3128 https://api.ipify.org

For the authenticated configuration, provide the username separately so a password does not appear in the command itself:

curl --proxy http://10.0.0.10:3128 --proxy-user proxyuser https://api.ipify.org

curl prompts for the proxy password when it is not supplied after the username. Avoid placing real credentials in shared shell history, screenshots, tickets, or documentation. Confirm the returned address with the IP location checker, then use the Proxy Tester for a separate reachability, protocol, speed, and exit-IP check.

A successful IP-check request proves the basic route. It does not prove every destination allows the connection, and it does not validate application authorization. Test the intended approved service at a conservative request rate and keep its response separate from Squid’s own errors.

Read access.log and cache.log

access.log records client transactions, while cache.log contains service startup, configuration, helper, and runtime messages. Package installations commonly place them under /var/log/squid/, but compiled paths and configured directives can differ.

sudo tail -f /var/log/squid/access.log
sudo tail -f /var/log/squid/cache.log

The official Squid logs guide explains the roles of these files and warns against deleting active logs. Use rotation and retention instead. Protect logs because URLs, client addresses, usernames, and operational details may be sensitive.

When a request fails, record the client time, source IP, destination, HTTP response, Squid result code, and nearby service log lines. A browser message alone does not distinguish a denied ACL from a broken authentication helper or an outbound DNS failure.

Fix common Squid server errors

Symptom	Likely layer	Check first
Connection refused	Service, listen address, or host firewall	Confirm Squid is running, port 3128 is listening on the intended interface, and the trusted source can reach it.
HTTP 403 or `TCP_DENIED/403`	ACL or rule order	Compare the client’s real source address with `trusted_clients` and inspect the first matching `http_access` rule.
HTTP 407 Proxy Authentication Required	Authentication	Confirm the helper path, password-file permissions, username, and that the `proxy_auth` ACL is evaluated before the final deny.
HTTPS works for some sites only	CONNECT port policy or destination	Check the requested destination port and the `SSL_ports` rule; do not broadly allow every port.
Timeout after connecting	Outbound route, DNS, or destination	Test DNS and direct outbound connectivity from the server, then compare `cache.log` and the destination response.
Hostnames fail but IP requests work	Resolver configuration	Verify the server resolver, search domains, and any configured Squid DNS settings without weakening client access rules.
Parse succeeds but new rules appear inactive	Reload or wrong config path	Confirm the running process uses the edited file and that reload/reconfigure completed without service errors.

Change one layer at a time and repeat the same request. Temporarily replacing a deny rule with a broad allow can hide the cause and create a security incident. Preserve the failed log entry and the exact configuration hash when another administrator needs to reproduce the issue.

Self-hosted Squid or managed proxy endpoints?

Run Squid when you need to administer client policy, caching, access controls, or an internal forwarding gateway. Choose managed proxy endpoints when the requirement is a supplied exit IP rather than maintaining a Linux daemon, firewall, monitoring, credentials, and updates. They solve related but different operational problems.

If the second model fits the project, compare dedicated proxy plans for a Squid proxy server workflow. Start with a small package and test the required client or upstream configuration before expanding it. A purchased endpoint does not replace secure access rules on a Squid server you operate.

Squid server security checklist

Allow only exact client IPs or controlled private subnets.
End every access policy with http_access deny all.
Restrict port 3128 at both host and cloud network firewalls.
Keep password files readable only by the required service account.
Use a protected network path instead of relying on Basic authentication alone.
Run squid -k parse before every reload.
Retain and rotate access.log and cache.log securely.
Patch the operating system and Squid package through the supported distribution channel.
Test from an unauthorized network and require the connection to fail.

Squid server FAQ

Where is squid.conf located?

Package installations commonly use /etc/squid/squid.conf; source installations may use /usr/local/squid/etc/squid.conf. Check squid -v, the service definition, and squid -k parse output to confirm the file used by the running instance.

Why does Squid return HTTP 403?

A 403 usually means an access rule denied the request. Verify the client’s actual source IP, the order of http_access lines, allowed destination ports, and the final deny rule. Use access.log to identify the denied request instead of removing restrictions blindly.

Why does Squid return HTTP 407?

A 407 requests proxy authentication. Check whether the client sent credentials, the authentication helper exists at the configured path, the password file is readable by Squid, and a proxy_auth ACL is present in the applicable access rule.

Can Squid authentication be used in transparent mode?

No. Squid’s official auth_param reference states that authentication is disabled on transparent, intercept, or TPROXY ports because the client believes it is communicating directly with the origin server. Use an explicit proxy configuration when authentication is required.

How do I check a Squid configuration before restart?

Run sudo squid -k parse and fix every syntax or fatal configuration error before reloading. Keep a known-good copy and confirm that the running service uses the same configuration path you validated.

How can I prevent a Squid server from becoming publicly accessible?

Use a narrow source ACL, an explicit final deny rule, a host firewall, and a cloud or perimeter firewall. Test port 3128 from an unauthorized external network and require it to be unreachable. Authentication is an additional control, not a replacement for network restriction.

Does Squid support SOCKS5 clients?

Squid is primarily an HTTP forward proxy and handles HTTPS through the HTTP CONNECT method. A client that requires the SOCKS5 protocol needs a SOCKS-compatible service or an application-specific chain; selecting SOCKS5 in the client does not convert a standard Squid listener.