By Alex Garnett and Manikandan Kurup 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. Deploy your frontend applications from GitHub using DigitalOcean App Platform. Let DigitalOcean focus on scaling your app. To complete this guide, you will need: 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: Squid will automatically set up a background service and start after being installed. You can check that the service is running properly: 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: 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: 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: 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. 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: 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: 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: Note: On Ubuntu 24.04, authentication helpers are located under /usr/lib/squid/. Older tutorials may reference /usr/lib/squid3/, which will not work on newer systems. 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: 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. 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: You should limit access to only trusted client IP addresses: After adding the rule, reload UFW to apply the changes: You can verify the active firewall rules with: 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: 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: 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: 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. Update your package index and install the Dante server package: 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. 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: Replace the default contents with the following minimal configuration: 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. Note: For security, restrict the from field to specific IP ranges instead of allowing 0.0.0.0/0. After saving your configuration file, restart the Dante service: Enable it to start automatically on boot: To verify that the service is running correctly, check its status: If the service is running properly, you’ll see output showing that it’s active (running) with no error messages. 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: You should use a more restrictive rule that only allows trusted clients: Reload the firewall to apply the changes: This is important to prevent your server from becoming an open proxy, which can be abused and potentially get your server blacklisted. You can verify that your SOCKS5 proxy is working correctly by using curl from your local machine: 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. 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. 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. Squid is a strong choice if you need: You may want to consider other tools if: 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. 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. 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. 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). 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. 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. 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). 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. 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. Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases. Learn more about our products Former Senior DevOps Technical Writer at DigitalOcean. Expertise in topics including Ubuntu 22.04, Linux, Rocky Linux, Debian 11, and more. With over 6 years of experience in tech publishing, Mani has edited and published more than 75 books covering a wide range of data science topics. Known for his strong attention to detail and technical knowledge, Mani specializes in creating clear, concise, and easy-to-understand content tailored for developers. This textbox defaults to using Markdown to format your answer. You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link! My squid active status is failed…i can’t fix it This comment has been deleted Whoever is encountering the issue restart the Squid after setting up the authentication, Please replace the line from auth_param basic program /usr/lib/squid3/basic_ncsa_auth /etc/squid/passwords to auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords based on the official documentation. How to update single Squid node without interrupting already serving/connected session? i.e Does not want long running Https session to be reset while restarting Squid or Squid server? how can i make 1 proxy server with multiple IP Inside can you give me a recommendation? Awesome. I have some code that fixes the bug for the latest versions: Please complete your information! Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation. Full documentation for every DigitalOcean product. The Wave has everything you need to know about building a business, from raising funding to marketing your product. Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter. New accounts only. By submitting your email you agree to our Privacy Policy Scale up as you grow — whether you're running one virtual machine or ten thousand. From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.