A slow connection is not always an internet problem. Sometimes the real issue is that every device reaches the same websites independently, without a central point for control, caching, or troubleshooting. This guide explains how to configure a Squid proxy on Ubuntu 20.04, including installation, access restrictions, user authentication, testing, and browser setup.
Ubuntu 20.04 ended standard security maintenance in May 2025. For a new deployment, use a supported Ubuntu release. If you must maintain an existing Ubuntu 20.04 server, confirm that it has appropriate Ubuntu Pro coverage and review the Ubuntu release cycle before placing it in service.
What a Squid proxy does
Squid is a Linux-based proxy server. A proxy sits between client devices and the internet: the client sends a request to Squid, and Squid makes the request on the client’s behalf. It can apply access rules, request authentication, logging, and selected caching behavior.
Think of it like a reception desk in an office. Instead of every visitor walking directly into every room, the reception desk checks who they are, where they may go, and what should happen next. The proxy does not automatically make a network safe, but it gives you a useful control point.
Squid can be useful when you need to:
- Give a group of client devices one controlled route to web services.
- Allow or deny traffic from specific IP addresses or network ranges.
- Require a username and password before proxy use.
- Review proxy activity while troubleshooting connectivity.
- Use caching where it fits your network and application requirements.
A proxy is not the same as a VPN. A VPN normally creates an encrypted tunnel for network traffic, while a Squid proxy handles requests sent through its configured proxy port. Do not expose an unauthenticated proxy to the public internet.
Prepare Ubuntu and install the Squid proxy
Before installing, connect to the server with an account that can use sudo. You should also know the private IP address or network range of the clients that will use the service. In a small office, that might be a private LAN such as 192.168.1.0/24; use the actual range in your environment rather than copying this example.
Update the package index and install Squid. The additional tools are optional, but curl is useful for testing and vim is a convenient editor.
sudo apt update
sudo apt install squid curl vim -yCheck whether the service is running, then enable it so it starts after a reboot.
sudo systemctl status squid
sudo systemctl enable squidYou can manage the service with these commands:
sudo systemctl start squid
sudo systemctl stop squid
sudo systemctl restart squidDo not restart after every small edit without checking the configuration first. Validation catches many syntax errors before they interrupt an active service.
Back up the configuration and choose a port
The main configuration file is /etc/squid/squid.conf. Create a backup before editing it. If a change causes trouble, the backup gives you a known starting point.
sudo cp -p /etc/squid/squid.conf /etc/squid/squid.conf.bak
sudo vim /etc/squid/squid.confSquid commonly listens on port 3128. You can keep that port or select another one, such as 31428, if your network design requires it. The port number is not a security boundary by itself; firewall rules and Squid access rules still matter.
http_port 31428If you change the port, update the client settings and firewall rule to match. Listening on all interfaces can be acceptable on a protected internal server, but avoid making the service reachable from untrusted networks. Where practical, bind it to the server’s private address instead of every interface.
Build an access control list
An access control list, often called an ACL, is a named rule that describes who or what may use the proxy. In this example, trusted_clients identifies the client IP range that is allowed to connect.
Squid evaluates access rules in order. Place your custom allow rules after the default safe-port and SSL-port restrictions, and keep a final deny rule. Never replace the final deny rule with an unrestricted allow rule, because that can create an open proxy.
acl trusted_clients src 192.168.1.0/24
http_access allow trusted_clients
http_access deny allReplace 192.168.1.0/24 with the correct client address or CIDR range. CIDR is a compact way to describe a group of IP addresses; for example, /24 commonly represents a range of 256 IPv4 addresses, including network and broadcast addresses.
For a server used by only one workstation, a single address is more restrictive:
acl trusted_client src 192.168.1.25
http_access allow trusted_client
http_access deny allKeep Squid’s default restrictions for ports and protocols unless you have a documented reason to change them. These rules help prevent the proxy from being used to reach services that should not be accessed through a web proxy. Review the Squid access-control documentation when adapting the rule order.
Add proxy authentication
IP-based access control works well for a trusted private network, but it does not identify individual users. Proxy authentication adds a username and password check. This is useful when several people share a network or when you need to revoke one person’s access without changing the client network rule.
Install the Apache utility package, then create a password file and its first user.
sudo apt install apache2-utils -y
sudo htpasswd -c /etc/squid/passwords testsquidThe -c option creates the password file, so use it only for the first user. To add another user later, omit -c or you may replace the existing file.
sudo htpasswd /etc/squid/passwords anotheruserNow add the authentication helper and rules to /etc/squid/squid.conf. The helper path can vary by package or platform, so confirm it before relying on the example.
dpkg -L squid | grep basic_ncsa_authOn a typical Ubuntu installation, the relevant configuration looks like this:
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm proxy
acl authenticated proxy_auth REQUIRED
acl trusted_clients src 192.168.1.0/24
http_access allow trusted_clients authenticated
http_access deny allThe rule containing both ACL names requires the request to come from the trusted network and to include valid credentials. If you want authentication to protect users across several trusted networks, define those networks carefully rather than allowing all source addresses.
Basic authentication does not encrypt credentials between the client and an ordinary HTTP proxy. Use it only on a trusted private network or protect the connection with an appropriate encrypted tunnel. Do not put passwords directly into shell commands that may be saved in command history.
Validate and test the configuration
Always test the file before restarting the service. The squid -k parse command checks the configuration syntax and reports problems that would otherwise appear during startup.
sudo squid -k parseIf the check succeeds, restart Squid and confirm its status:
sudo systemctl restart squid
sudo systemctl --no-pager status squidTest from an approved client with curl. The command below asks for the password interactively instead of placing it in the command line.
curl --proxy http://SERVER_IP:31428 --proxy-user testsquid https://example.comReplace SERVER_IP with the proxy server’s address. For example, a client on the same private network might use 192.168.1.10 as the server address. A successful response confirms that the client can reach the listening port, authenticate, and send a request through the proxy.
Test failure cases too. An untrusted client should be denied, and an incorrect password should fail. If every client succeeds without credentials, inspect the order of the http_access rules. Squid stops evaluating access rules when a matching allow or deny decision is reached.
When troubleshooting, check the service log and the system journal:
sudo tail -f /var/log/squid/access.log
sudo journalctl -u squid --no-pagerCommon problems include a wrong server IP, a blocked firewall port, a typo in the helper path, and an ACL that does not match the client’s actual address. Check one layer at a time: service status, listening port, firewall, ACL match, and credentials.
Configure browsers as proxy clients
After the server works, configure a test computer rather than changing every device at once. Record the original settings so you can undo the change easily.
Windows system proxy settings
In Chrome or another browser that uses the operating system’s proxy settings, open the browser settings and search for proxy. Open the computer’s network proxy settings, select the manual proxy option, and enter the Squid server address and port, such as 192.168.1.10 and 31428. Save the setting, then open a new page and enter the proxy username and password when prompted.
The exact menu labels can change between browser and operating system releases. Searching the settings for “proxy” is usually faster than following a screenshot from an older release.
Firefox proxy settings
Firefox may use its own proxy configuration. Open Settings, search for Network Settings, and select Settings. Choose Manual proxy configuration, enter the server address and proxy port, then save.
For a simple HTTP proxy, fill in the HTTP proxy field and port. If you use the same proxy for other protocols, enable the matching option only after confirming that the proxy and your application support that traffic. A browser may also offer a setting to bypass the proxy for local addresses; use it only when your network requires that behavior.
Example: if the proxy server is 10.0.0.5 and Squid listens on 31428, enter those values in the browser’s proxy fields. Visit a site you are authorized to test, then check /var/log/squid/access.log on the server to confirm the request arrived.
Common mistakes and safer operating habits
The most serious mistake is allowing anyone on the internet to use the proxy. Restrict the listening interface, limit the firewall to trusted client networks, use narrow ACLs, and keep http_access deny all at the end of the access rules.
- Skipping validation: Run
sudo squid -k parsebefore every restart after a configuration change. - Using the wrong address range: Check the client’s real IP address and account for NAT or multiple network interfaces.
- Overwriting the password file: Use
htpasswd -conly when creating the file for the first user. - Assuming authentication is encryption: Basic proxy authentication protects access decisions, not the credential exchange on an unencrypted connection.
- Changing too many settings at once: Start with one port, one client range, and one test user. Add complexity only after the basic path works.
- Leaving old software exposed: Ubuntu 20.04 is an older release. Keep its support status and security coverage under review.
For example, if a request works from the server but fails from a workstation, the Squid process may be healthy while the firewall or ACL blocks the workstation. If the workstation reaches the port but receives a login prompt repeatedly, check the username, password file permissions, helper path, and authentication rule order.
Frequently asked questions about Squid proxy setup
What port does Squid use by default?
Squid commonly uses port 3128. You can keep that port or configure another one, but the firewall, client settings, and any monitoring rules must use the same port.
How do I allow only one network through Squid?
Define an ACL with the network’s source address or CIDR range, then allow that ACL before the final deny rule. For example, use acl trusted_clients src 192.168.1.0/24 followed by http_access allow trusted_clients.
Why does Squid keep asking for my password?
Repeated prompts usually indicate an incorrect password, a missing user in the password file, an incorrect authentication helper path, or an access rule that does not match the request. Check the helper path, run squid -k parse, and review the Squid access log while testing.
Is a Squid proxy the same as a VPN?
No. Squid is a proxy service that handles supported requests sent through its configured port. A VPN creates a broader encrypted network tunnel, so choose the technology based on whether you need proxy control or network-wide tunneling.
Final checklist and next step
A reliable Squid deployment has a supported operating system, a backed-up configuration, a restricted client ACL, a final deny rule, a protected firewall port, and a tested authentication path when credentials are required. It also has a simple rollback plan and logs that you can review during testing.
Your next step is to configure one authorized test client, run sudo squid -k parse, restart the service, and verify both a successful authenticated request and a denied unauthorized request. Once those checks pass, document the server address, port, client range, and recovery procedure before adding more users or devices.
