Set Up Squid Proxy on Ubuntu: Complete Guide

Proxy servers are a type of server application that functions as a gateway between an end user and an internet resource. Through a proxy server, an end user is able to control and monitor their web traffic for a wide variety of purposes, including privacy, security, and caching. For example, you can use a proxy server to make web requests from a different IP address than your own. You can also use a proxy server to research how the web is served differently from one jurisdiction to the next, or avoid some methods of surveillance or web traffic throttling.

Squid is a stable, popular, open-source HTTP proxy. In this tutorial, you will install and configure Squid to provide an HTTP proxy on an Ubuntu 24.04 LTS server. This guide reflects current package versions, configuration paths, and best practices for modern Ubuntu environments.

You will also secure access to your proxy using Squid access control rules and basic authentication, restrict network-level access with a firewall, and test proxy connectivity from a client. Finally, you will review when you may want to use a SOCKS5 proxy instead (for example, Dante), how Squid compares to other common proxy solutions, and some frequently asked questions about operating and troubleshooting Squid.

To complete this guide, you will need:

• An Ubuntu 24.04 LTS server and a non-root user with sudo privileges. You can learn more about how to set up a user with these privileges in our Initial Server Setup with Ubuntu guide.

You will use the domain name your_domain in this tutorial, but you should substitute this with your own domain name, or IP address.

Squid has many use cases beyond routing an individual user’s outbound traffic. In the context of large-scale server deployments, it can be used as a distributed caching mechanism, a load balancer, or another component of a routing stack. However, some methods of horizontally scaling server traffic that would typically have involved a proxy server have been surpassed in popularity by containerization frameworks such as Kubernetes, which distribute more components of an application. At the same time, using proxy servers to redirect web requests as an individual user has become increasingly popular for protecting your privacy. This is helpful to keep in mind when working with open-source proxy servers which may appear to have many dozens of features in a lower-priority maintenance mode. The use cases for a proxy have changed over time, but the fundamental technology has not.

Begin by running the following commands as a non-root user to update your package listings and install Squid Proxy:

sudo apt update
sudo apt install squid

Squid will automatically set up a background service and start after being installed. You can check that the service is running properly:

systemctl status squid

Output
● squid.service - Squid Web Proxy Server
     Loaded: loaded (/usr/lib/systemd/system/squid.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-04-24 02:07:21 EDT; 19s ago
       Docs: man:squid(8)
    Process: 3133998 ExecStartPre=/usr/sbin/squid --foreground -z (code=exited, status=0/SUCCESS)
   Main PID: 3134009 (squid)
      Tasks: 4 (limit: 4653)
     Memory: 17.7M (peak: 18.5M)
        CPU: 244ms
     CGroup: /system.slice/squid.service
             ├─3134009 /usr/sbin/squid --foreground -sYC
             ├─3134016 "(squid-1)" --kid squid-1 --foreground -sYC
             ├─3134017 "(logfile-daemon)" /var/log/squid/access.log
             └─3134019 "(pinger)"

By default, Squid does not allow any clients to connect to it from outside of this server. In order to enable that, you’ll need to make some changes to its configuration file, which is stored in /etc/squid/squid.conf. Open it in nano or your favorite text editor:

sudo nano /etc/squid/squid.conf

Be advised that Squid’s default configuration file is very, very long, and contains a massive number of options that have been temporarily disabled by putting a # at the start of the line they’re on, also called being commented out. You will most likely want to search through the file to find the lines you want to edit. In nano, this is done by pressing Ctrl+W, entering your search term, pressing Enter, and then repeatedly pressing Alt+W to find the next instance of that term if needed.

Begin by navigating to the line containing the phrase http_access deny all. You should see a block of text explaining Squid’s default access rules:

. . . 
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
include /etc/squid/conf.d/*

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all
. . . 

From this, you can see the current behavior – localhost is allowed; other connections are not. Note that these rules are parsed sequentially, so it’s a good idea to keep the deny all rule at the bottom of this configuration block. You could change that rule to allow all, enabling anyone to connect to your proxy server, but you probably don’t want to do that. Instead, you can add a line above http_access allow localhost that includes your own IP address, like so:

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
include /etc/squid/conf.d/*

# Example rule allowing access from your local networks.
acl localnet src your_ip_address

# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localnet
http_access allow localhost

• acl means an Access Control List, a common term for permissions policies
• localnet in this case is the name of your ACL.
• src is where the request would originate from under this ACL, i.e., your IP address.

Note that you also need to add or uncomment the line http_access allow localnet to actually allow the ACL you just defined.

If you don’t know your local IP address, it’s quickest to go to a site like What’s my IP which can tell you where you accessed it from. After making these changes, save and close the file. If you are using nano, press Ctrl+X, and then when prompted, Y and then Enter.

At this point, you could restart Squid and connect to it, but there’s more you can do in order to secure it first.

Most proxies, and most client-side apps that connect to proxies (e.g., web browsers) support multiple methods of authentication. These can include shared keys, or separate authentication servers, but most commonly entail regular username-password pairs. Squid allows you to create username-password pairs using built-in Linux functionality, as an additional or an alternative step to restricting access to your proxy by IP address. To do that, you’ll create a file called /etc/squid/passwords and point Squid’s configuration to it.

First, you’ll need to install some utilities from the Apache project in order to have access to a password generator that Squid likes.

sudo apt install apache2-utils

This package provides the htpasswd command, which you can use in order to generate a password for a new Squid user. Squid’s usernames won’t overlap with system usernames in any way, so you can use the same name you’ve logged in with if you want. You’ll be prompted to add a password as well:

sudo htpasswd -c /etc/squid/passwords your_squid_username

This will store your username along with a hash of your new password in /etc/squid/passwords, which will be used as an authentication source by Squid. You can cat the file afterward to see what that looks like:

sudo cat /etc/squid/passwords

Output
sammy:$apr1$Dgl.Mtnd$vdqLYjBGdtoWA47w4q1Td.

After verifying that your username and password have been stored, you can update Squid’s configuration to use your new /etc/squid/passwords file. Using nano or your favorite text editor, reopen the Squid configuration file and add the following highlighted lines:

sudo nano /etc/squid/squid.conf

…
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
include /etc/squid/conf.d/*
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm proxy
acl authenticated proxy_auth REQUIRED
# Example rule allowing access from your local networks.
acl localnet src your_ip_address
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access allow localhost
http_access allow authenticated localnet
# And finally deny all other access to this proxy
http_access deny all
…

These additional directives tell Squid to check in your new passwords file for password hashes that can be parsed using the basic_ncsa_auth mechanism, and to require authentication for access to your proxy. You can review Squid’s documentation for more information on this or other authentication methods. After that, you can finally restart Squid with your configuration changes.

Because the http_access allow authenticated localnet rule includes both ACLs, clients must connect from the IP range you defined and provide valid credentials.

If you added http_access allow localnet in Step 1, make sure you comment it out or remove it before you restart Squid. Otherwise, Squid will allow unauthenticated access for any client that matches the localnet ACL.

But before restarting the Squid service, it is a good idea to check your configuration for syntax errors. This helps prevent the service from failing due to invalid directives.

Run the following command:

sudo squid -k parse

If there are any issues in your configuration file, Squid will display them in the output. If no errors are reported, you can safely proceed with restarting the service.

sudo systemctl restart squid

This might take a moment to complete.

In addition to configuring access control within Squid, it is important to restrict network-level access to your proxy using a firewall. On Ubuntu, this is typically done using UFW (Uncomplicated Firewall).

By default, if you allow traffic on port 3128 without restrictions, your server may become an open proxy, which can be abused by unauthorized users and potentially lead to your IP address being blacklisted.

Instead of allowing unrestricted access:

sudo ufw allow 3128

You should limit access to only trusted client IP addresses:

sudo ufw allow from your_client_ip to any port 3128

For example:

sudo ufw allow from 203.0.113.10 to any port 3128

After adding the rule, reload UFW to apply the changes:

sudo ufw reload

You can verify the active firewall rules with:

sudo ufw status

Using UFW alongside Squid’s ACL configuration provides an additional layer of security by enforcing both network-level and application-level access control.

In the next step, you’ll connect to your proxy at last.

In order to demonstrate your Squid server, you’ll use a command line program called curl, which is popular for making different types of web requests. In general, if you want to verify whether a given connection should be working in a browser under ideal circumstances, you should always test first with curl. You’ll be using curl on your local machine in order to do this – it’s installed by default on all modern Windows, Mac, and Linux environments, so you can open any local shell to run this command:

curl -v -x http://your_squid_username:your_squid_password@your_server_ip:3128 http://www.google.com/

The -x argument passes a proxy server to curl, and in this case you’re using the http:// protocol, specifying your username and password to this server, and then connecting to a known-working website like google.com. If the command was successful, you should see the following output:

Output
*   Trying 138.197.103.77...
* TCP_NODELAY set
* Connected to 138.197.103.77 (138.197.103.77) port 3128 (#0)
* Proxy auth using Basic with user 'sammy'
> GET http://www.google.com/ HTTP/1.1

It is also possible to access https:// websites with your Squid proxy without making any further configuration changes. These make use of a separate proxy directive called CONNECT in order to preserve SSL between the client and the server:

curl -v -x http://your_squid_username:your_squid_password@your_server_ip:3128 https://www.google.com/

Output
*   Trying 138.197.103.77...
* TCP_NODELAY set
* Connected to 138.197.103.77 (138.197.103.77) port 3128 (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to www.google.com:443
* Proxy auth using Basic with user 'sammy'
> CONNECT www.google.com:443 HTTP/1.1
> Host: www.google.com:443
> Proxy-Authorization: Basic c2FtbXk6c2FtbXk=
> User-Agent: curl/7.55.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied OK to CONNECT request
* CONNECT phase completed!

The credentials that you used for curl should now work anywhere else you might want to use your new proxy server.

While Squid is designed specifically for HTTP and HTTPS proxying, some applications require a more flexible proxy protocol such as SOCKS5. Unlike HTTP proxies, SOCKS5 operates at a lower level in the network stack and can handle a wider range of traffic, including TCP and UDP connections. This makes it suitable for use cases such as SSH tunneling, torrent clients, and applications that don’t natively support HTTP proxies.

Squid doesn’t provide native SOCKS5 support. To deploy a SOCKS5 proxy on Ubuntu, you can use a dedicated proxy server such as Dante, which is lightweight, actively maintained, and widely used for SOCKS proxying.

Installing Dante SOCKS Proxy

Update your package index and install the Dante server package:

sudo apt update
sudo apt install dante-server

This installs the Dante daemon (danted), which is the core SOCKS5 proxy service, along with a default configuration file at /etc/danted.conf. Like Squid, you’ll be able to manage it using standard systemd commands.

Basic Configuration

Dante’s behavior is controlled through the /etc/danted.conf file, similar to how Squid uses /etc/squid/squid.conf. Open it in your preferred text editor:

sudo nano /etc/danted.conf

Replace the default contents with the following minimal configuration:

logoutput: syslog

internal: 0.0.0.0 port = 1080
external: eth0

method: username none

user.notprivileged: nobody

client pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
}

pass {
    from: 0.0.0.0/0 to: 0.0.0.0/0
    protocol: tcp udp
}

In this configuration:

• internal: This specifies the IP address and port that Dante listens on for incoming connections. 0.0.0.0 tells Dante to accept connections from any network interface on port 1080, which is the standard SOCKS5 port.

• external: This defines the network interface that Dante uses for outgoing traffic. You’ll need to replace eth0 with your actual interface name, such as ens3 or enp0s3. You can find your interface by running ip a and looking for the one with an active IP address.

• method: This defines the authentication methods Dante will accept. The value username none allows both authenticated connections (with username/password) and unauthenticated connections. For production, you should remove none to require authentication.

• client pass and pass: These blocks define access control rules for who can connect to your proxy and what traffic they can send through it. In this configuration, both blocks allow all clients (0.0.0.0/0) to connect and proxy traffic anywhere. This is fine for testing but should be restricted to specific IP ranges in production.

Start and Enable the Service

After saving your configuration file, restart the Dante service:

sudo systemctl restart danted

Enable it to start automatically on boot:

sudo systemctl enable danted

To verify that the service is running correctly, check its status:

systemctl status danted

If the service is running properly, you’ll see output showing that it’s active (running) with no error messages.

Allow SOCKS5 Traffic Through the Firewall

If you’re using UFW (Uncomplicated Firewall), you’ll need to allow traffic to the SOCKS5 port so clients can connect to your proxy.

Instead of allowing unrestricted access from any IP address with this command:

sudo ufw allow 1080

You should use a more restrictive rule that only allows trusted clients:

sudo ufw allow from your_client_ip to any port 1080

For example:

sudo ufw allow from 203.0.113.10 to any port 1080

Reload the firewall to apply the changes:

sudo ufw reload

This is important to prevent your server from becoming an open proxy, which can be abused and potentially get your server blacklisted.

Testing the SOCKS5 Proxy

You can verify that your SOCKS5 proxy is working correctly by using curl from your local machine:

curl -x socks5h://your_server_ip:1080 http://example.com

The socks5h scheme tells curl to perform DNS resolution through the proxy server rather than locally on your machine. This provides extra privacy by preventing local DNS queries from revealing which sites you’re accessing. If the request succeeds and returns HTML content, your proxy is working correctly.

When to Use SOCKS5 Instead of Squid

SOCKS5 is a better choice when you need more flexibility than HTTP-specific proxying can provide. You should consider SOCKS5 if you need to proxy non-HTTP protocols such as SSH, FTP, or custom application traffic that doesn’t work with HTTP proxies. It’s also the right choice when your tools explicitly require SOCKS proxy support, or when you want a protocol-agnostic proxy that operates at the transport layer without inspecting or modifying the traffic passing through it.

Squid, on the other hand, is better suited for HTTP and HTTPS traffic specifically. Squid excels at content caching and bandwidth optimization, which can significantly improve performance for frequently accessed web content. It also provides fine-grained access control using ACLs, making it ideal for controlling which users can access which websites and applying content filtering policies.

In many production environments, you can deploy both Squid and a SOCKS5 proxy together on the same server or network. This lets you support different types of traffic and use cases – HTTP/HTTPS traffic routes through Squid for caching benefits, while non-HTTP traffic goes through SOCKS5 for broader protocol support.

Squid remains a widely used forward proxy, particularly in enterprise and network-level deployments where control, caching, and traffic filtering are required. However, it is not the only option available. Depending on your use case, other proxy tools may be more suitable.

Understanding how Squid compares to alternative solutions will help you determine whether it is the right fit for your environment.

How Squid Compares to Other Proxy Solutions

Here are a few key points to keep in mind when comparing these proxy options:

• Squid is optimized for web traffic: Squid excels at HTTP and HTTPS proxying with built-in content caching that can dramatically reduce bandwidth costs. Its Access Control List (ACL) system lets you create detailed rules about who can access what, making it particularly valuable in enterprise environments where you need to enforce browsing policies and monitor bandwidth usage.

• SOCKS5 proxies (like Dante) offer broader protocol support: Unlike HTTP-specific proxies, SOCKS5 operates at the transport layer and can proxy virtually any TCP or UDP traffic without understanding the application protocol. This makes it perfect for tunneling SSH connections, routing database queries, or handling custom protocols that don’t work with HTTP proxies. However, it can’t provide caching or content filtering the way Squid can.

• Reverse proxies (Nginx, HAProxy) serve a different role: While forward proxies like Squid help clients access external resources, reverse proxies work in the opposite direction – they sit in front of your backend servers and manage incoming requests. They’re designed for load balancing, SSL termination, and routing traffic based on URL patterns. If you’re building a web application or API, you’ll want a reverse proxy, not a forward proxy.

• Lightweight proxies prioritize simplicity over features: Tools like Tinyproxy are designed for scenarios where you need basic HTTP/HTTPS proxying without Squid’s configuration complexity. They’re faster to set up and consume fewer resources, but they typically don’t offer caching, detailed logging, or the advanced ACL features that make Squid suitable for larger deployments.

When Should You Use Squid?

Squid is a strong choice if you need:

• Centralized control over outbound web traffic: Enforce consistent browsing policies across multiple users with logging and monitoring of all web requests.
• Content caching to reduce bandwidth usage: Serve cached copies of frequently accessed content like software downloads, system updates, or popular websites instead of fetching them repeatedly.
• Detailed access policies using ACLs: Fine-grained control over which users can access specific domains or URL patterns, with support for time-based rules and authentication.
• A proxy solution that scales: Handle hundreds or thousands of connections efficiently with comprehensive logging and monitoring for larger teams or networks.

When Should You Consider Alternatives?

You may want to consider other tools if:

• You need to proxy non-HTTP traffic: Squid is designed specifically for HTTP and HTTPS. For protocols like SSH, FTP, SMTP, or database connections, you’ll need a SOCKS5 proxy like Dante that operates at the transport layer.
• You’re routing traffic to backend services: Forward proxies help clients access external resources. For distributing incoming web requests across multiple backend servers or handling SSL termination, use a reverse proxy like Nginx or HAProxy instead.
• You want a simpler, lightweight setup: If you just need basic HTTP/HTTPS proxying for personal use or a small number of users without caching or detailed ACLs, a minimal proxy like Tinyproxy will be easier to configure and maintain.

Squid continues to be a relevant and powerful tool for managing web traffic in modern environments. While alternative proxy solutions exist, they typically address different use cases rather than replacing Squid entirely. Choosing the right tool depends on the type of traffic you need to handle and the level of control required.

1. How do I configure Squid proxy in Ubuntu?

After installing Squid (for example, sudo apt install squid), edit /etc/squid/squid.conf to define ACLs, set the listening port with http_port, and control access with http_access rules. Check your config with sudo squid -k parse, then apply changes with sudo systemctl restart squid.

2. How do I set up a SOCKS5 proxy on Ubuntu?

Squid does not natively support SOCKS5. For SOCKS5, use a dedicated SOCKS server like Dante (the daemon is typically danted) or SSH dynamic port forwarding (for example, ssh -D 1080 user@your_server_ip). Squid is an HTTP/HTTPS forward proxy, while SOCKS5 is a protocol-agnostic proxy.

3. How do I set a proxy in Ubuntu Linux system-wide?

Set http_proxy and https_proxy (and optionally no_proxy) in /etc/environment, or configure desktop proxy settings in GNOME under Settings -> Network -> Network Proxy. For APT, add proxy settings under /etc/apt/apt.conf.d/ (for example, /etc/apt/apt.conf.d/proxy.conf).

4. Is Squid proxy still used in 2025?

Yes. Squid is actively maintained and still widely deployed for caching, access control, and auditing in enterprise networks and automation pipelines. It also supports optional HTTPS inspection (SSL Bump), but that requires careful certificate management and a clear security policy.

5. What port does Squid proxy use by default?

Squid listens on port 3128 by default, which is set by http_port 3128 in squid.conf. If you change it, make sure your firewall rules (UFW/iptables) allow the new port.

6. How do I check if Squid proxy is running on Ubuntu?

Run sudo systemctl status squid to check the service state. You can also confirm it is listening with sudo ss -tlnp | grep squid (or by checking for port 3128).

7. How do I restrict access to specific websites using Squid?

Define a dstdomain ACL in squid.conf (for example, acl blocked_sites dstdomain .example.com), then deny it with http_access deny blocked_sites. Place the deny rule above your allow rules, then restart Squid.

8. How do I enable logging in Squid and where are the log files?

By default, Squid writes request logs to /var/log/squid/access.log and cache/service logs to /var/log/squid/cache.log. You can monitor traffic with sudo tail -f /var/log/squid/access.log or view service logs with journalctl -u squid.

In this tutorial, you installed and configured Squid, a popular open-source proxy server for managing HTTP and HTTPS traffic. You also configured access controls, validated your configuration, and tested proxy connectivity from a client. Many applications have built-in proxy support (often at the OS level) going back decades, which makes this setup broadly reusable.

If you need to proxy non-HTTP traffic or support applications that require SOCKS, you can complement Squid with a SOCKS5 proxy. Next, you may want to learn how to deploy Dante, a SOCKS proxy which can run alongside Squid for proxying different types of traffic.

Because one of the most common use cases for proxy servers is proxying traffic to and from different global regions, you may want to review how to use Ansible to automate server deployments next, especially if you plan to duplicate this configuration across multiple servers or regions.

• UFW Essentials: Common Firewall Rules and Commands for Linux Security
• How to Set Up a Firewall with UFW on Ubuntu
• How To Configure Nginx as a Web Server and Reverse Proxy for Apache
• How To Set Up SSH Tunneling on a VPS
• Initial Server Setup with Ubuntu