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

To run Dante safely on a Linux VPS, install the distribution’s dante-server package, bind the daemon to the intended listening and outbound interfaces, require SOCKS5 username authentication, and allow only known client IP addresses through both firewalls and Dante’s rule sets. Validate the configuration with danted -V before starting the service, then test from an authorized laptop and monitor the logs. The procedure below is written for Debian- and Ubuntu-family systems; package paths and service details can differ by release.

Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.

What Dante does and why the two rule stages matter

Dante is a SOCKS proxy daemon. It can relay TCP and UDP traffic and can sit between networks as a firewall-like control point. A client connects to Dante, asks it to reach a destination, and Dante makes the outbound connection according to its policy.

#	Preview	Product	Price
1		Mastering Online Privacy: Unlock the Secrets of VPNs, Proxies, and SOCKS5 for Ultimate Online...	$7.50	Buy on Amazon
2		The Proxy Playbook: The Complete Guide to Proxy Servers: How to Source, Test, and Scale Residential,...	$29.95	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

Every request passes two separate policy stages:

• Client rules decide whether the connecting source address may use the daemon at all.
• SOCKS rules decide which destination, protocol, and command that admitted client may request.

This separation is important when troubleshooting. A connection rejected by a client block never reaches SOCKS authorization. A client can pass the first stage and still be denied because a destination, command, or protocol is not allowed by the SOCKS rules.

The Debian danted(8) manual describes Dante as implementing the SOCKS standard and functioning as a firewall between networks. Treat an internet-facing VPS as an exposed security boundary, not as a general-purpose open relay.

#1 Best Overall

Mastering Online Privacy: Unlock the Secrets of VPNs, Proxies, and SOCKS5 for Ultimate Online Freedom and Security

$7.50

Buy on Amazon

Decide the security policy before installing

Write down these values before editing the configuration:

• The VPS address or private address on which Dante will listen.
• The public address or interface Dante will use for outbound connections.
• The TCP listening port, commonly 1080 unless another port fits your policy.
• Every client address or CIDR range that needs access.
• Whether the workload needs TCP only or UDP as well.
• The dedicated proxy username and a long, random password.

Use source-IP restrictions even when username authentication is enabled. An allowlist limits who can reach the login service and reduces password-guessing exposure. Do not use an unrestricted client pass or socks pass rule unless that exposure is intentional, monitored, and protected by another control.

Choose SOCKS5 when credentials are required. SOCKS4 has no username/password authentication capability, whereas SOCKS5 supports the username method used by Dante.

Prepare the Linux VPS

Update the operating system

Log in through your normal administrative SSH account, not through the future proxy account. Apply security updates first:

sudo apt update
sudo apt full-upgrade

Reboot if the package manager installs a kernel or another component that requires it, then reconnect over SSH.

Install the server package

On Debian- and Ubuntu-family distributions, the package is normally named dante-server:

sudo apt install dante-server

Package naming, the service-unit name, and the configuration-file path vary by distribution and release. Inspect the unit installed on your VPS instead of assuming a path:

systemctl list-unit-files | grep -i dante
sudo systemctl cat danted

Use the path shown by the unit’s ExecStart option and read the installed danted.conf(5) manual. Some packages use /etc/danted.conf; others may place an example or an alternate file elsewhere.

Find the addresses and interfaces

List addresses and routes before writing internal and external directives:

ip -br address
ip route
ip -6 route

The listening address can be a private address, a public address, or a wildcard, depending on your network design. Binding to the narrowest intended address is safer than listening on every interface. The outbound setting should identify the address or interface through which the VPS reaches the internet. Confirm the choice with your provider’s networking documentation and the installed Dante manual.

Create a least-privilege proxy identity

Keep administrative SSH credentials separate from proxy credentials. Where the package does not create a suitable account automatically, create a dedicated system user:

sudo adduser --system --group --shell /usr/sbin/nologin danteproxy
sudo passwd danteproxy

Give this account a long random password. Do not reuse the VPS root password or an SSH key passphrase. Dante’s documented username method checks the system password file, so the username must exist in the VPS account database and the password must be usable by the authentication mechanism.

A system account with a non-login shell is appropriate for the daemon’s identity, but do not confuse the daemon’s operating-system account with the account used for SOCKS authentication. If your package creates a service account, inspect its unit and documentation before creating a second one.

Build the Dante configuration in layers

Make a backup of the package’s original file, then edit the file referenced by the service unit:

sudo cp /etc/danted.conf /etc/danted.conf.backup

Replace that path if your unit uses a different file. The following is a deliberately restrictive structure. It is illustrative: interface names, address syntax, user directives, and accepted keywords are version-sensitive, so reconcile it with the manual installed on your VPS.

logoutput: syslog
internal: LISTENING_IP port = 1080
external: EGRESS_IP

method: username
clientmethod: none
socksmethod: username

client pass {
    from: TRUSTED_CLIENT_IP/32 to: 0.0.0.0/0
}
client block {
    from: 0.0.0.0/0 to: 0.0.0.0/0
}

socks pass {
    from: TRUSTED_CLIENT_IP/32 to: 0.0.0.0/0
    command: connect
    protocol: tcp
}
socks block {
    from: 0.0.0.0/0 to: 0.0.0.0/0
}

In this example, replace the uppercase tokens with real values. If you have multiple trusted clients, add one source range per rule or use a CIDR that contains only the intended systems. Add equivalent IPv6 rules if clients will connect over IPv6; an IPv4-only rule does not automatically protect an IPv6 listener.

Global and interface directives

• logoutput selects where operational messages go. Syslog is convenient when the distribution already rotates and stores service logs.
• internal defines the listening address and port. Bind it to the interface or address that trusted clients can reach.
• external selects the address or interface used for outbound traffic. A wrong value can allow login while preventing destinations from connecting.
• method, clientmethod, and socksmethod govern authentication according to the installed Dante version. Set them deliberately and verify their exact spelling in danted.conf(5).

Dante documents the default socksmethod as no methods, which means SOCKS requests are blocked. A missing method is therefore not a safe way to obtain username authentication; it simply prevents requests. Explicitly set the method you intend to use.

Client rules: the first gate

Put ordered client pass and client block rules before relying on SOCKS authorization. The first rule that matches controls the result, so place specific trusted ranges before the catch-all block. Prefer numeric IP addresses in client rules when possible; this avoids DNS dependency and is the security and performance practice described in Dante’s documentation.

The catch-all block is valuable even when a provider firewall is configured. It protects you if a firewall rule is accidentally widened or removed.

SOCKS rules: destination and capability control

SOCKS rules can constrain source and destination addresses, commands, and protocols. The sample allows only TCP connect requests. That is a sensible starting point for web browsing and ordinary TCP applications.

Dante supports UDP, but UDP relay changes the exposure and must be enabled intentionally. Add a narrowly scoped UDP rule only when the application needs it, and confirm that the client software supports Dante’s UDP behavior. Do not broaden the rule to every command and protocol merely because a test client reports that TCP works.

Rank #2

The Proxy Playbook: The Complete Guide to Proxy Servers: How to Source, Test, and Scale Residential, Mobile, and Datacenter Proxies for Web Scraping, ... Anonymous Browsing without Getting Blocked

$29.95

Buy on Amazon

Enable username authentication

Set socksmethod: username (or the version-specific equivalent) and create the corresponding system account. Keep clientmethod separate: many deployments use no client-stage credential because source-IP filtering is the first gate, while requiring username authentication at the SOCKS stage.

After saving the file, verify that the account exists and is not locked:

getent passwd danteproxy
sudo passwd -S danteproxy

Do not print the password in shell history or place it in a world-readable configuration file. When a client stores credentials, use its protected credential store where available.

Restrict both network firewalls

Apply the same source restriction at every layer:

1. In the VPS provider’s network firewall, allow the Dante port only from the required client addresses.
2. In the VPS host firewall, allow the same addresses and port.
3. In Dante’s client pass rules, repeat the source restriction.
4. Keep SSH on its own restricted rule and do not combine SSH and proxy access into a broad source range.

For a host using UFW, a typical TCP rule is:

sudo ufw allow from TRUSTED_CLIENT_IP to any port 1080 proto tcp
sudo ufw status verbose

Replace TRUSTED_CLIENT_IP with the actual address. If you later add UDP relay, create a separate UDP firewall rule only for the sources and port that require it. On nftables or another firewall, express the same policy using that system’s native syntax and verify the active ruleset rather than assuming a configuration file was loaded.

Validate the configuration before starting Dante

Run the daemon’s verification mode and specify the file explicitly when the package does not use its default path:

sudo danted -V
sudo danted -V -f /etc/danted.conf

The exact option order is accepted by current Dante builds, but consult the installed manual if your package reports an unknown option. Fix every parse error before restarting. A successful syntax check does not prove that the address is routable or that a firewall permits the connection; it only removes configuration parsing errors from the list of possible causes.

Start the service and verify its listener

sudo systemctl enable --now danted
sudo systemctl status danted --no-pager
sudo ss -lntup | grep 1080

If your package uses a different unit name, substitute the name shown by systemctl list-unit-files. The socket listing should show Dante listening on the intended address and port, not unexpectedly on every public interface.

After any edit, validate again and restart cleanly:

sudo danted -V -f /etc/danted.conf
sudo systemctl restart danted
sudo systemctl status danted --no-pager

Test from an authorized laptop

Test a TCP connection with SOCKS5 credentials

Use a SOCKS5-aware client and explicitly select SOCKS5. With curl, keep the password out of the proxy URL so shell history is less likely to expose it:

curl --socks5-hostname VPS_PUBLIC_IP:1080 
     --proxy-user danteproxy:PROXY_PASSWORD 
     https://example.com

--socks5-hostname asks Dante to resolve the destination through the proxy, which avoids leaking DNS lookups to the laptop’s local resolver. Replace the example destination with a site or service appropriate to your test. If the password contains shell-special characters, quote the argument or use the client’s credential prompt and protected configuration facilities.

Confirm the egress address

Use an IP-echo service you trust and compare its result with the VPS public address. For example, store the service URL in a shell variable rather than embedding a password in a URL:

IP_ECHO_URL='https://your-chosen-ip-echo-service.example/'
curl --socks5-hostname VPS_PUBLIC_IP:1080 
     --proxy-user danteproxy:PROXY_PASSWORD 
     "$IP_ECHO_URL"

The returned address should be the VPS egress address, not the laptop’s address. If it is not, inspect the external setting, routing table, and any provider-level egress policy.

Test the negative cases

• From a source address that is not in the allowlist, confirm that the connection is rejected or cannot reach the port.
• With an allowed source, attempt a request that your SOCKS rules intentionally deny, such as a UDP request when only TCP is allowed.
• Try an incorrect password and confirm that authentication fails without changing the client-stage result.

Run these tests from a genuinely different source network when possible. Testing a denied source from the same laptop does not exercise the client rule.

Enable logs and resource timeouts

Operational data makes Dante manageable. Configure a syslog destination or a dedicated log file according to the installed manual, and enable connection, disconnection, error, and I/O events appropriate for your environment. Avoid collecting credentials or more payload detail than your retention and privacy policy permits.

Set connection and negotiation timeouts so a stalled client cannot hold resources indefinitely. Dante documents timeout controls, but directive names and defaults can vary by version; use the installed danted.conf(5) manual rather than copying a setting from an unrelated release.

After starting the service, watch both the service journal and the firewall while making a test request:

sudo journalctl -u danted -f
sudo journalctl -k -f

Record the source address, requested destination, selected protocol, and the rule outcome in your operational notes. Logs that distinguish a client-rule denial from a SOCKS-rule denial point directly to the correct policy stage.

Troubleshoot by symptom

The laptop cannot connect to port 1080

• Confirm Dante is running with systemctl status danted.
• Check ss -lntup to ensure the daemon is listening on the expected address and port.
• Review the provider firewall and host firewall independently.
• Verify that the laptop’s current public address is the one in the client allowlist; mobile and home connections often change addresses.
• Check that DNS is not being used to resolve a hostname to an address that is not routed to the VPS.

Authentication fails

• Ensure the client is configured for SOCKS5, not SOCKS4.
• Confirm the username exists in the system account database and that its password is correct.
• Check that socksmethod is explicitly set to username in the syntax accepted by your Dante version.
• Look at Dante’s authentication log entry and distinguish a bad credential from a client rule that rejected the source first.

The proxy accepts login but destinations fail

• Inspect the external address or interface and the VPS routing table.
• Check that a socks pass rule matches the client source, destination, command, and protocol.
• Remember that a TCP-only rule will deny UDP requests by design.
• Review connect and negotiation timeouts if the connection stalls rather than failing immediately.
• Check outbound firewall and provider egress restrictions.

The service will not start after an edit

• Run danted -V with the exact configuration file used by the service.
• Compare every directive with the installed manual; configuration keywords are version-sensitive.
• Inspect journalctl -u danted for the line and token that failed.
• Restore the backup only long enough to regain service, then reapply one change at a time and validate after each edit.

Choose the right exposure model

These choices are independent. For example, several trusted offices can use SOCKS5 username authentication while retaining separate source ranges and TCP-only SOCKS rules.

Ongoing maintenance and safe changes

Review the client list whenever a laptop, office, or VPN address changes. Remove old source ranges and disable proxy accounts that are no longer needed. Rotate the proxy password if it may have been exposed, and investigate logs for unexpected destinations or repeated authentication failures.

When changing policy, use this sequence:

1. Back up the active configuration.
2. Edit one logical section, such as a single source range or protocol rule.
3. Run danted -V against the active file.
4. Restart the service and confirm its listener.
5. Run an allowed test and an intentionally denied test.
6. Watch logs during the test and record the resulting rule decision.

Keep SSH access available through a separately restricted rule while you work. Never use the proxy as your only administrative path; a bad firewall or Dante rule can otherwise lock you out of the VPS.

Quick Recap

Bestseller No. 1

Mastering Online Privacy: Unlock the Secrets of VPNs, Proxies, and SOCKS5 for Ultimate Online Freedom and Security

$7.50

Bestseller No. 2

The Proxy Playbook: The Complete Guide to Proxy Servers: How to Source, Test, and Scale Residential, Mobile, and Datacenter Proxies for Web Scraping, ... Anonymous Browsing without Getting Blocked

$29.95

Final security checklist

• Use a supported Debian- or Ubuntu-family release and keep it patched.
• Install the distribution’s dante-server package and confirm the service’s real unit and configuration path.
• Bind internal and external to the addresses your design actually uses.
• Create a dedicated system identity and a separate, random SOCKS password.
• Require SOCKS5 username authentication when credentials are needed.
• Place specific client pass rules before a catch-all client block.
• Place narrowly scoped socks pass rules before a catch-all socks block.
• Allow the listening port only from trusted sources in the provider firewall, host firewall, and Dante policy.
• Run danted -V before every restart.
• Test from an allowed source, a denied source, and a denied protocol or command.
• Enable useful logs and timeouts, then review them after deployment.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.