Limited time offer! 25% off our lifetime plans with code LMT25 at checkout. View plans →

CyberPanel

How to Set Up a Private SOCKS5 Proxy on a Linux VPS with Dante

How to Set Up a Private SOCKS5 Proxy on a Linux VPS with Dante

Commercial proxy services are the fastest way to get IP addresses in many locations, but some projects call for something different: a single dedicated address you fully control, configured exactly the way you want. If you already run a VPS, or can spin one up in a few minutes, a private SOCKS5 proxy is a small project that delivers exactly that.

This guide walks through deploying a SOCKS5 proxy with Dante on Ubuntu, securing it with authentication and firewall rules, testing it from the command line, and using it in browser profiles. The whole setup takes about 30 minutes.

Why Run Your Own SOCKS5 Proxy?

SOCKS5 is a general-purpose proxy protocol. Unlike an HTTP proxy, it doesn’t interpret the traffic it carries, so it works with any TCP application and supports UDP relaying and username/password authentication.

A self-hosted SOCKS5 server is useful in several everyday scenarios:

A stable, dedicated IP. Allowlisting access to admin panels, staging servers, or third-party APIs is easier when your team always connects from one known address.

Location-specific testing. A VPS in Frankfurt or New York lets developers and QA teams check how a site, CDN, or geo-redirect behaves for visitors in that region.

Separate browser environments. Agencies and QA teams often run several isolated browser profiles, each with its own network route. With antidetect browser proxy management in tools like Afina, you can assign a different SOCKS5 proxy to each profile, so a private server like the one in this guide becomes the dedicated exit point for a specific project or market.

Full control at a predictable cost. For a small team that needs one or two fixed addresses, a single VPS is a simple, flat monthly expense with no shared users.

Keep in mind that a VPS gives you a datacenter IP address. That’s ideal for allowlisting, testing, and team access, but some platforms treat datacenter traffic differently from home connections, so residential or mobile proxies remain the better fit when an environment needs to look like an ordinary household user.

The trade-off is responsibility: you maintain the server, keep it patched, and make sure it isn’t open to the internet for anyone to abuse.

What You’ll Need

A VPS running Ubuntu 22.04 or 24.04 in the location you want your proxy IP to be. A minimal plan with 1 vCPU and 1 GB of RAM is enough for a handful of users. If you don’t have a server yet, a CyberPanel Cloud VPS works well.

SSH access as root or a user with sudo privileges, ideally with key-based authentication.

The public IP address of the machine you’ll connect from, so you can restrict access to it.

Step 1: Prepare the Server

Connect over SSH and bring the system up to date:

sudo apt update && sudo apt upgrade -y

Dante needs to know which network interface faces the internet. Older guides assume eth0, but many providers use names like ens3 or enp1s0. Find yours with:

ip -o -4 route show to default | awk ‘{print $5}’

Note the result; you’ll use it in the configuration file.

Step 2: Install Dante

Dante is a mature, open-source SOCKS server available in Ubuntu’s official repositories:

sudo apt install dante-server -y

The service, called danted, may fail to start right after installation because the default configuration is incomplete. That’s expected; you’ll replace it in the next step.

Step 3: Configure Dante

Back up the default file and open a new one:

sudo mv /etc/danted.conf /etc/danted.conf.bak
sudo nano /etc/danted.conf

Paste the following configuration, replacing ens3 with your server’s outbound interface and 203.0.113.10 with your own public client IP address. The example includes optional UDP relay support with a limited client-side port range:

logoutput: syslog
user.privileged: root
user.unprivileged: nobody

# Accept SOCKS5 connections on TCP port 1080
internal: 0.0.0.0 port = 1080
external: ens3

# Require a local username/password for SOCKS5 requests
clientmethod: none
socksmethod: username

# Allow control connections only from your client IP
client pass {
from: 203.0.113.10/32 to: 0.0.0.0/0
log: error connect disconnect
}

# TCP connections and client-initiated UDP associations
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: connect udpassociate
user: proxyuser
udp.portrange: 40000-40099
log: error connect disconnect
}

# Permit response packets for established UDP associations
socks pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
command: udpreply
log: error connect disconnect
}

A few notes on what this does:

socksmethod: username makes Dante validate SOCKS5 credentials against the server’s local system accounts. The user: proxyuser condition restricts outgoing proxy requests to the dedicated account created in Step 4; user.privileged: root is needed to check local passwords.

The client pass rule only admits connections from your approved public IP address. To allow a trusted office range, use CIDR notation such as 198.51.100.0/24, but avoid broad ranges on an internet-facing proxy.

The connect and udpassociate commands permit TCP connections and client-initiated UDP relay; the separate udpreply rule allows return traffic. The udp.portrange directive restricts the client-facing UDP relay ports to 40000-40099, which must match your firewall. UDP relay is optional: if you only need TCP, omit udpassociate, udpreply, and udp.portrange instead of opening the UDP range.

For the distinction between UDP ASSOCIATE and UDP replies, consult the official Dante configuration documentation.

Step 4: Create a Dedicated Proxy User

Never use your root or sudo account for proxy authentication. Create a system user that can’t log in to a shell:

sudo useradd -r -s /usr/sbin/nologin proxyuser
sudo passwd proxyuser

Choose a long, random password. These credentials travel with every connection, and a weak password on a public proxy is an open invitation to abuse.

Step 5: Open the Firewall

If your server uses UFW rather than CyberPanel’s firewall, allow SSH before enabling it, then restrict the SOCKS5 TCP port to your trusted IP. Add the UDP port range only if your client needs UDP-over-SOCKS5:

sudo ufw allow OpenSSH
sudo ufw allow from 203.0.113.10 to any port 1080 proto tcp

# Optional: only for SOCKS5 UDP relay
sudo ufw allow from 203.0.113.10 to any port 40000:40099 proto udp

sudo ufw enable
sudo ufw status

If CyberPanel is installed on the same server, manage ports through its existing firewall rather than enabling UFW alongside firewalld. In Server > Security > Firewall, allow TCP port 1080 from your client IP; if you need UDP relay, also allow the configured UDP range from that IP. See the CyberPanel firewall documentation for the panel workflow and confirm that your rule is IP-restricted.

UDP ASSOCIATE may use additional ports beyond TCP 1080. If you enable it, the configured 40000-40099 UDP relay range must be reachable from the approved client IP through the server and any provider-level firewall. This guide’s basic curl check verifies TCP connectivity; test UDP separately with an application that supports SOCKS5 UDP relay.

Step 6: Start and Test the Proxy

Restart Dante with the new configuration, enable it at boot, and confirm it’s running:

sudo systemctl restart danted
sudo systemctl enable danted
sudo systemctl status danted

The status should show active (running). If it doesn’t, the log output below the status usually names the exact line in the configuration that caused the problem.

Now test from your own computer, not from the server:

curl –proxy socks5h://SERVER_IP:1080 –proxy-user proxyuser https://ifconfig.me

The command should print your VPS’s public IP instead of your own. With socks5h, curl asks the proxy to resolve the hostname rather than performing the lookup locally. With only the proxy username on the command line, curl prompts for the password; this avoids embedding a secret in shell history. This test checks TCP proxying, not UDP relay or browser-level DNS/WebRTC behavior.

Using the Proxy in Browser Profiles

Any application that supports SOCKS5 with authentication can now use the proxy: enter the server IP, port 1080, and the proxyuser credentials.

For browser work, it’s worth keeping the proxy inside a dedicated browser profile rather than switching your whole system’s settings back and forth. Assigning one proxy per profile means the profile always uses the same IP address, sessions from different projects never share a network route, and you can still browse normally in your everyday profile. In a multi-profile browser such as Afina, the proxy is saved in the profile’s settings, so the same IP is applied every time that profile opens. When you add more VPS locations later, each one simply becomes another profile.

UDP relay depends on the client as well as the server. Standard Chrome SOCKS5 settings proxy TCP URL requests, not UDP traffic; browser platforms such as Afina offer explicit UDP-over-SOCKS5 support. Verify that your chosen client actually uses the UDP relay, and check the external IP, DNS and WebRTC behavior in the resulting profile. Test QUIC/HTTP/3 separately if your workflow requires it.

Security and Maintenance Best Practices

An open or poorly protected proxy is quickly found by scanners and abused for spam or attacks, which can get your IP address blocklisted and your VPS suspended. Keep these habits:

Restrict by source IP. Keep both the Dante client pass rule and the firewall limited to addresses you control. Authentication alone is not enough.

Use strong, unique credentials. Rotate the proxy user’s password when a team member leaves or a project ends.

Remember that SOCKS5 is not encrypted by itself. Username/password authentication and the proxy leg can be exposed to network observers. Use HTTPS for destinations and consider placing the SOCKS5 connection inside an encrypted VPN or SSH tunnel when confidentiality is important. IP restrictions reduce exposure but do not replace encryption.

Keep the system patched. Enable unattended security updates or schedule regular apt upgrade runs.

Watch the logs. Dante writes to the system journal, so sudo journalctl -u danted -f shows live connections and authentication failures.

Monitor bandwidth. A sudden traffic spike usually means someone else is using your proxy.

Follow your provider’s terms. Most VPS providers allow private proxies but prohibit abuse, and the websites you access through the proxy still have their own terms of service.

Troubleshooting Common Issues

Connection refused. Check that danted is running and that port 1080 is open in the firewall for your current IP. If your home IP changes, the rule needs updating.

Authentication failed. Confirm the username and password, and make sure user.privileged is set to root; without it, Dante can’t verify system passwords.

The service won’t start. Run sudo journalctl -u danted -n 50 and look for the line number of the error. A wrong interface name in the external setting is the most common cause.

Sites see your real location. Use socks5h in curl and enable remote DNS resolution in your client, so name lookups go through the proxy.

Conclusion

A private SOCKS5 proxy is one of the simplest useful projects you can run on a VPS: one package, one configuration file, one user, and a couple of firewall rules. In return, you get a dedicated IP address in the location you choose, full control over who can use it, and a predictable monthly cost.

Start with a single server, keep access locked to your own IP addresses, and check the logs from time to time. When you need another region, clone the setup on a new VPS, and if you work across several projects, pair each proxy with its own browser profile so every environment stays clean and separate. To get started with the server side, see Getting Started with CyberPanel.

Leave a Reply

Your email address will not be published. Required fields are marked *

Chat on WhatsApp