How to Install and Configure a Squid Proxy on Ubuntu 24.04

Proxy servers are server applications that act as intermediaries between an end user and resources on the internet. By routing requests through a proxy server, users can manage and observe their web traffic for purposes such as privacy, security, and caching. For example, a proxy can be used to send web requests through an IP address different from your own. A proxy may also help you examine how websites are delivered in different locations or reduce exposure to certain forms of monitoring and web traffic throttling.

Squid is a well-established, widely used, open-source HTTP proxy. In this tutorial, you will install and configure Squid as an HTTP proxy on an Ubuntu 24.04 LTS server. The instructions reflect current package versions, configuration locations, and recommended practices for modern Ubuntu systems.

You will also protect access to the proxy with Squid access control rules and basic authentication, limit network-level access with a firewall, and verify proxy connectivity from a client. Finally, you will examine situations where a SOCKS5 proxy such as Dante may be more appropriate, compare Squid with other commonly used proxy solutions, and review frequently asked questions about running and troubleshooting Squid.

Frontend applications stored on GitHub can also be deployed through a managed application platform, allowing the platform to handle application scaling.

Key Takeaways

• Squid is a forward proxy intended for HTTP and HTTPS traffic, making it suitable for web access management, monitoring, and optional caching across teams or networks.
• Secure Squid installations rely on multiple layers of access control. Use Squid ACLs and authentication in the configuration while also restricting incoming connections with a firewall so that the server does not become an open proxy.
• Squid processes access rules in sequence, which means the order of http_access directives matters. Place specific allow and deny rules first and keep the final deny-all rule at the end to prevent unintended access.
• Before restarting Squid, validate the configuration syntax so that errors can be detected before they cause a failed restart or service interruption.
• Testing through a client utility such as curl provides a fast way to verify proxy operation, authentication, and HTTPS CONNECT handling before configuring browsers or other applications.
• Squid is not a SOCKS proxy. If applications require SOCKS or need to proxy protocols other than HTTP, a SOCKS5 server such as Dante can be used instead or alongside Squid.
• Different proxy technologies have different purposes. Reverse proxies such as Nginx and HAProxy manage incoming traffic toward backend services, while Squid is designed to manage outgoing traffic from clients.
• Logs and service checks provide important operational visibility, so knowing where Squid stores its logs and how to verify the running service and listening port is useful for ongoing troubleshooting.

Prerequisites

To follow this guide, you will need:

• An Ubuntu 24.04 LTS server and a non-root user with sudo privileges. A standard initial Ubuntu server setup can be used to create a user with these permissions.

This tutorial uses the domain name your_domain. Replace it with your own domain name or server IP address.

Step 1 — Installing Squid Proxy

Squid can be used for considerably more than routing the outbound traffic of a single user. In larger server environments, it may operate as part of a distributed caching system, a load-balancing arrangement, or another element within a routing architecture. Some approaches that historically relied heavily on proxy servers for horizontal scaling have become less common as container orchestration platforms such as Kubernetes have made it possible to distribute more application components independently. At the same time, individuals increasingly use proxy servers to redirect web requests for privacy-related purposes. This context is useful when working with mature open-source proxy software that may expose a large number of features, including some that receive less development attention. Proxy use cases have evolved, but the underlying proxy technology remains largely the same.

Start by updating the package index and installing Squid while logged in as a non-root user:

sudo apt update
sudo apt install squid

Squid automatically creates a background service and starts it after installation. Check whether the service is running correctly with:

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 prevents external clients from connecting to the proxy. To permit selected remote clients, modify the main configuration file located at /etc/squid/squid.conf. Open the file with nano or another text editor:

sudo nano /etc/squid/squid.conf

Squid’s standard configuration file is very long and contains a large number of available settings. Many settings are disabled by placing a # character at the beginning of the corresponding line, which means that the line is commented out. Searching the file is usually the easiest way to locate settings that need modification. In nano, press Ctrl+W, enter the text you want to find, and press Enter. If the same text appears multiple times, press Alt+W repeatedly to move through the remaining matches.

First, locate the line containing http_access deny all. Nearby, you should find a section describing Squid’s default access behavior:

/etc/squid/squid.conf

. . .
#
# 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
. . .

This configuration shows the default behavior: connections from localhost are permitted, while other clients are denied. Squid evaluates these directives in order, so the deny all rule should remain at the end of the access-control section. Changing it to allow all would allow anyone to use the proxy, which is generally undesirable. Instead, define an ACL containing the IP address that should be allowed and place it above the localhost rule:

/etc/squid/squid.conf

#
# 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 stands for Access Control List, a commonly used term for defining permission policies.
• localnet is the name assigned to this particular ACL.
• src identifies the source from which a request originates under the ACL, which in this example is your IP address.

You must also add or uncomment http_access allow localnet so that the ACL you created is actually permitted to access the proxy.

If you do not know your public IP address, a service such as What’s my IP can display the address from which your connection appears to originate. After completing the changes, save and close the configuration. In nano, press Ctrl+X, then press Y when prompted, followed by Enter.

Squid could now be restarted and used for connections, but additional security measures should be configured first.

Step 2 — Securing Squid

Most proxy servers and client applications that support proxies, including web browsers, provide several authentication options. These may involve shared keys or external authentication services, but username-and-password authentication is one of the most common approaches. Squid can use username-password combinations generated with standard Linux tools. This can be used in addition to, or instead of, restricting proxy access solely by client IP address. To configure this method, create a file named /etc/squid/passwords and configure Squid to use it.

First, install the required utilities from the Apache project so that the password-generation utility supported by Squid is available:

sudo apt install apache2-utils

This package includes the htpasswd utility, which can generate credentials for a Squid user. Squid usernames are independent of operating-system user accounts, so you may use the same username as your system account if desired. The command will also prompt you to create a password:

sudo htpasswd -c /etc/squid/passwords your_squid_username

The command stores the username and a hash of the password in /etc/squid/passwords. Squid will use this file as an authentication source. You can inspect the file afterward with cat:

sudo cat /etc/squid/passwords

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

Once the credentials have been stored successfully, configure Squid to use the new /etc/squid/passwords file. Reopen the Squid configuration with nano or another editor and add the following directives:

sudo nano /etc/squid/squid.conf

/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
…

Note: On Ubuntu 24.04, Squid authentication helper programs are stored under /usr/lib/squid/. Older instructions may use /usr/lib/squid3/, which is not valid on newer systems.

These directives instruct Squid to read password hashes from the new passwords file using the basic_ncsa_auth authentication mechanism and to require authenticated users before allowing proxy access. Squid’s documentation contains additional details about this and other available authentication methods. Once these directives have been added, the service can be restarted with the updated configuration.

Because http_access allow authenticated localnet references both ACLs, a client must originate from the IP range configured in localnet and also provide valid authentication credentials.

If http_access allow localnet was enabled during the previous step, remove it or comment it out before restarting Squid. Leaving that rule active would permit unauthenticated connections from any client that matches the localnet ACL.

Before restarting the Squid service, validate the configuration for syntax problems. This reduces the risk of a restart failing because of an invalid directive.

Run:

sudo squid -k parse

If the configuration contains problems, Squid reports them in the command output. When no errors are displayed, restart the service:

sudo systemctl restart squid

The restart may require a short period to finish.

In addition to Squid’s own access-control configuration, network access to the proxy should be limited with a firewall. On Ubuntu, this is commonly handled with UFW, the Uncomplicated Firewall.

Allowing unrestricted traffic to port 3128 could turn the server into an open proxy. Unauthorized users could abuse the service, potentially causing the server’s IP address to be blacklisted.

A rule that allows unrestricted access would look like this:

sudo ufw allow 3128

Instead, restrict access to 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

Reload UFW after creating the rule:

sudo ufw reload

Check the currently active firewall rules with:

sudo ufw status

Combining UFW restrictions with Squid ACLs adds another security layer by enforcing access limitations at both the network and application levels.

The proxy can now be tested from a client.

Step 3 — Connecting Through Squid

To demonstrate the Squid proxy, use the command-line utility curl, which is widely used for sending different kinds of web requests. When checking whether a proxy connection should work in a browser, testing it first with curl is usually an effective troubleshooting approach. Run the following command from your local computer. Modern Windows, macOS, and Linux systems generally include curl, so the command can be executed from a local terminal or shell:

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

The -x option tells curl which proxy to use. Here, the proxy uses the http:// scheme, includes the username and password required by the proxy, and forwards a request to a known working website such as google.com. A successful request should produce output similar to the following:

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

HTTPS websites can also be reached through Squid without additional configuration. HTTPS proxy requests rely on the CONNECT method, which allows SSL communication between the client and destination server to remain intact:

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 same credentials used successfully with curl can now be used by other applications that support an HTTP proxy.

Setting Up a SOCKS5 Proxy on Ubuntu as an Alternative to Squid

Squid is specifically designed to proxy HTTP and HTTPS traffic, but some applications require a more flexible protocol such as SOCKS5. Unlike an HTTP proxy, SOCKS5 operates at a lower networking layer and can process a broader range of traffic, including TCP and UDP connections. This can make SOCKS5 suitable for SSH tunneling, torrent applications, and programs that do not support HTTP proxies directly.

Squid does not include native SOCKS5 functionality. A dedicated SOCKS proxy server such as Dante can be installed on Ubuntu instead. Dante is lightweight, actively maintained, and commonly used for SOCKS proxying.

Installing Dante SOCKS Proxy

Update the package index and install the Dante server package:

sudo apt update
sudo apt install dante-server

This installs the Dante daemon, danted, which provides the SOCKS5 proxy service, together with a default configuration file at /etc/danted.conf. Like Squid, the service can be controlled with standard systemd commands.

Basic Dante Configuration

Dante is configured through /etc/danted.conf, in much the same way that Squid uses /etc/squid/squid.conf. Open the Dante configuration file with your preferred editor:

sudo nano /etc/danted.conf

Replace the existing contents with this 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
}

This configuration contains the following settings:

• internal: Defines the address and port on which Dante accepts incoming connections. The address 0.0.0.0 makes Dante listen on all network interfaces, while 1080 is the commonly used SOCKS5 port.
• external: Specifies the network interface Dante uses for outbound connections. Replace eth0 with the interface used by your server, such as ens3 or enp0s3. Run ip a and locate the interface with an active IP address to determine the correct name.
• method: Determines which authentication methods Dante permits. The value username none accepts both username/password authentication and connections without authentication. In a production environment, remove none if authentication should always be mandatory.
• client pass and pass: These blocks determine which clients may connect and which destinations and traffic types they may reach. In this example, 0.0.0.0/0 permits connections from all clients and allows proxy traffic to any destination. This may be useful for testing but should be restricted to trusted IP ranges in a production environment.

Note: For better security, replace 0.0.0.0/0 in the from field with the specific client IP ranges that should be allowed.

Starting and Enabling the Dante Service

After saving the Dante configuration, restart the service:

sudo systemctl restart danted

Configure Dante to start automatically when the server boots:

sudo systemctl enable danted

Verify that the service is running:

systemctl status danted

If Dante is operating correctly, the service status should show active (running) without error messages.

Allowing SOCKS5 Traffic Through the Firewall

When UFW is enabled, the firewall must permit connections to the SOCKS5 port before remote clients can use the proxy.

An unrestricted rule that allows connections from every IP address would be:

sudo ufw allow 1080

A safer approach is to permit only 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 UFW after changing the rules:

sudo ufw reload

Restricting access is important because an unrestricted SOCKS5 server can become an open proxy. Such a proxy may be abused by unauthorized users and could cause the server’s IP address to be blacklisted.

Testing the SOCKS5 Proxy

Use curl from your local computer to verify that the SOCKS5 proxy is operating:

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

The socks5h scheme instructs curl to resolve DNS names through the proxy instead of resolving them on the local computer. This can improve privacy because local DNS requests do not reveal which domain names are being accessed. If the command succeeds and returns HTML, the SOCKS5 proxy is functioning correctly.

When to Use SOCKS5 Instead of Squid

SOCKS5 is generally more suitable when HTTP-specific proxying does not provide enough flexibility. Consider SOCKS5 when you need to forward non-HTTP protocols such as SSH, FTP, or custom application traffic that cannot operate through an HTTP proxy. SOCKS5 is also appropriate when software explicitly requires SOCKS support or when you need a protocol-independent proxy working at the transport layer without analyzing or modifying the application data that passes through it.

Squid is more appropriate when the traffic consists primarily of HTTP and HTTPS requests. Squid provides content caching and bandwidth optimization, which can improve efficiency when the same web resources are accessed repeatedly. Its ACL system also provides detailed access control, making it useful for deciding which users can reach particular websites and for applying web access policies.

In many production networks, Squid and a SOCKS5 proxy can operate together on the same server or within the same network. HTTP and HTTPS requests can pass through Squid to benefit from its caching and policy controls, while other protocols can be routed through SOCKS5 for broader protocol compatibility.

Choosing the Right Proxy

Squid remains a common forward-proxy solution, particularly in enterprise and network environments where traffic control, caching, and filtering are required. However, several other proxy tools are available, and the most appropriate option depends on the intended use case.

Comparing Squid with alternative proxy solutions can help determine whether it matches the requirements of your environment.

How Squid Compares to Other Proxy Solutions

Consider the following differences when evaluating these proxy options:

• Squid is designed for web traffic: Squid is particularly effective for HTTP and HTTPS proxying and includes content caching that can substantially reduce bandwidth usage. Its Access Control List system supports detailed policies that determine who may access specific resources. This makes Squid useful in enterprise environments where browsing policies and bandwidth use need to be managed.
• SOCKS5 proxies such as Dante support more protocols: Instead of being limited to HTTP-aware traffic, SOCKS5 operates at the transport layer and can relay many kinds of TCP and UDP connections without interpreting the underlying application protocol. This makes it suitable for SSH connections, database traffic, and custom protocols that cannot use HTTP proxies. Unlike Squid, however, SOCKS5 does not provide HTTP content caching or equivalent content-filtering capabilities.
• Reverse proxies such as Nginx and HAProxy have a different purpose: A forward proxy such as Squid helps clients reach external resources. A reverse proxy instead sits in front of backend servers and manages incoming requests. Reverse proxies are typically used for load balancing, SSL termination, and routing requests according to URL patterns. Web applications and APIs that need inbound traffic management generally require a reverse proxy rather than a forward proxy.
• Lightweight proxies favor simplicity instead of advanced functionality: Utilities such as Tinyproxy are intended for situations where only basic HTTP or HTTPS proxying is necessary. Their configuration is generally simpler and they consume fewer system resources, but they usually provide fewer caching, logging, and advanced ACL capabilities than Squid.

When Should You Use Squid?

Squid is a suitable option when you require:

• Central management of outbound web traffic: Apply consistent web access policies across several users while logging and monitoring outgoing web requests.
• Content caching to lower bandwidth consumption: Provide cached versions of frequently requested resources such as software packages, operating-system updates, or commonly visited websites instead of downloading the same content repeatedly.
• Detailed access rules with ACLs: Control which users may reach particular domains or URL patterns, including authentication requirements and time-based policies.
• A proxy capable of handling larger deployments: Manage hundreds or thousands of connections efficiently while retaining extensive logging and monitoring for larger teams or networks.

When Should You Consider Alternatives?

Another proxy solution may be more appropriate when:

• You need to proxy traffic other than HTTP: Squid focuses on HTTP and HTTPS. Protocols such as SSH, FTP, SMTP, and database connections generally require a transport-layer solution such as a SOCKS5 proxy like Dante.
• You are directing incoming requests toward backend services: Forward proxies help clients reach outside resources. If the objective is to distribute incoming requests among several backend servers or perform SSL termination, use a reverse proxy such as Nginx or HAProxy.
• You prefer a smaller and simpler configuration: When only straightforward HTTP or HTTPS proxying is required for an individual or a small group, without caching or advanced ACL rules, a minimal proxy such as Tinyproxy may be easier to configure and maintain.

Squid remains a useful and capable option for controlling web traffic in modern environments. Alternative proxy technologies generally solve different problems rather than replacing Squid in every situation. The appropriate proxy depends on the traffic protocols involved and the amount of control the environment requires.

Frequently Asked Questions About Squid Proxy

1. How Do I Configure Squid Proxy on Ubuntu?

After installing Squid with a command such as sudo apt install squid, edit /etc/squid/squid.conf to create ACLs, configure the listening port with http_port, and manage permissions with http_access rules. Validate the configuration by running sudo squid -k parse, then apply the changes with sudo systemctl restart squid.

2. How Do I Set Up a SOCKS5 Proxy on Ubuntu?

Squid does not provide SOCKS5 support directly. For SOCKS5 connections, use a dedicated server such as Dante, whose daemon is normally called danted, or use SSH dynamic port forwarding with a command such as ssh -D 1080 user@your_server_ip. Squid functions as an HTTP and HTTPS forward proxy, whereas SOCKS5 works independently of a particular application protocol.

3. How Do I Configure a Proxy System-Wide in Ubuntu Linux?

Define http_proxy and https_proxy, along with the optional no_proxy variable, in /etc/environment. On GNOME desktops, proxy settings can also be configured under Settings -> Network -> Network Proxy. For APT, add the proxy configuration under /etc/apt/apt.conf.d/, for example in /etc/apt/apt.conf.d/proxy.conf.

4. Is Squid Proxy Still Used?

Yes. Squid remains actively maintained and continues to be deployed for caching, access management, and auditing in enterprise networks and automated environments. It can also perform optional HTTPS inspection through SSL Bump, although this requires careful handling of certificates and a clearly defined security policy.

5. Which Port Does Squid Proxy Use by Default?

Squid uses port 3128 by default. The port is normally configured with http_port 3128 in squid.conf. If the port is changed, update UFW, iptables, or other firewall rules so that the selected port is permitted.

6. How Do I Check Whether Squid Proxy Is Running on Ubuntu?

Run sudo systemctl status squid to inspect the service status. You can also confirm that Squid is listening for connections by running sudo ss -tlnp | grep squid or by checking whether port 3128 is open and listening.

7. How Do I Restrict Access to Specific Websites with Squid?

Create a dstdomain ACL in squid.conf, such as acl blocked_sites dstdomain .example.com, and block it with http_access deny blocked_sites. The deny directive should appear above applicable allow rules. Restart Squid after saving the configuration.

8. How Do I Enable Squid Logging and Where Are the Log Files?

Squid normally records requests in /var/log/squid/access.log and stores cache and service-related information in /var/log/squid/cache.log. Monitor incoming traffic with sudo tail -f /var/log/squid/access.log, or examine service messages with journalctl -u squid.

Conclusion

In this tutorial, you installed and configured Squid as an open-source proxy server for handling HTTP and HTTPS traffic. You also created access-control restrictions, checked the configuration for errors, and tested connectivity from a client system. Proxy support has been built into many applications and operating systems for decades, which makes this type of configuration useful across many different environments.

When non-HTTP traffic must be proxied or an application specifically requires SOCKS support, Squid can be combined with a SOCKS5 proxy. Dante can run alongside Squid so that different categories of network traffic can be handled through the proxy technology most appropriate for each protocol.