Self-hosted SOCKS5 proxy with Dante, or buy proxies?

A self-hosted SOCKS5 proxy is the right choice when the point is to leave from addresses your organization controls: a partner API that allowlists your source IP, CI runners reaching a firewalled staging environment, or tooling that only speaks SOCKS5 inside your own network. It is the wrong choice when the point is to look like many unrelated users in many places, because a server you run has one address, or a handful, in your hosting provider's range, and every block, complaint and reputation score attaches to it and to you. Dante is the usual open-source server for the first case, and a minimal configuration takes a page.

This guide gives that configuration, tested, and then walks through the questions that decide whether running your own is cheaper than buying: reputation, abuse handling, address visibility, staffing, provenance and legal exposure. The configuration was run on Dante 1.4.4 (the Alpine dante-server package) in a two-network Docker lab and also validated with danted -V on Debian 12's 1.4.2.

What a Dante server gives you

Dante is a SOCKS server: a client opens a TCP connection, authenticates, and asks Dante to connect to a host and port on its behalf. Dante makes that connection from one of its own addresses and relays bytes. It does not cache, parse HTTP or touch TLS. Compared with an HTTP proxy such as Squid, it carries any TCP protocol, and optionally UDP, which is why it suits tools that are not web clients. SOCKS5 vs HTTP proxy covers the protocol differences.

What you get is narrow and predictable:

• The exit address is the server's address, from whichever provider hosts it.
• Every connection is attributable to your organization, through the hosting contract and the registry records for that range.
• Capacity is the server's network and CPU; geography is wherever you put servers.
• Policy, logs and accounts are entirely yours.

A minimal danted.conf that is not an open proxy

Debian 12 and Ubuntu 24.04 package the server as dante-server, with the daemon danted reading /etc/danted.conf. Alpine ships the same software as sockd reading /etc/sockd.conf, and Debian 13's archive had no dante-server package when we checked, so confirm your distribution before planning around it. The syntax is the same everywhere:

logoutput: stderr

internal: eth0 port = 1080
external: eth1

socksmethod: username
user.privileged: root
user.unprivileged: nobody

timeout.negotiate: 30
timeout.io: 3600

client pass {
    from: 10.20.0.0/24 to: 0.0.0.0/0
    log: error
}
client block {
    from: 0.0.0.0/0 to: 0.0.0.0/0
    log: connect error
}

socks block {
    from: 0.0.0.0/0 to: 10.0.0.0/8
    log: connect error
}
socks block {
    from: 0.0.0.0/0 to: 172.16.0.0/12
    log: connect error
}
socks block {
    from: 0.0.0.0/0 to: 192.168.0.0/16
    log: connect error
}
socks block {
    from: 0.0.0.0/0 to: 169.254.0.0/16
    log: connect error
}
socks block {
    from: 0.0.0.0/0 to: 127.0.0.0/8
    log: connect error
}
socks pass {
    from: 10.20.0.0/24 to: 0.0.0.0/0
    command: connect
    log: connect disconnect error
}
socks block {
    from: 0.0.0.0/0 to: 0.0.0.0/0
    log: connect error
}

How to read it:

• internal and external are where Dante listens and the interface it connects out from. On a single-interface server, both are eth0 (or whatever your interface is called); danted -V accepted that form too.
• socksmethod: username requires a username and password and checks them against the system password database, which is why user.privileged is root: reading it needs privilege. Use pam.username to authenticate through PAM instead.
• Client rules run first, at the TCP level, on the source address. Only 10.20.0.0/24, a stand-in for your office, VPN or CI range, gets past them. Use addresses here, not hostnames.
• Socks rules run on the request. The five blocks stop the server being used to reach private networks, loopback and the cloud metadata address, which matters when it runs inside a VPC. Rules are first match wins, so the blocks come before the pass.
• command: connect allows TCP connections only. bind and udpassociate stay off until something needs them.
• timeout.io: 3600 closes connections idle for an hour; the default is never.

Create one system account per consumer, with no shell and no home, then validate and start:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin pricing-scraper
sudo passwd pricing-scraper
sudo danted -V -f /etc/danted.conf
sudo systemctl restart danted

Testing it, and the errors you will see

Use socks5h:// so the hostname is resolved by Dante, not by the client:

curl -sS -x socks5h://pricing-scraper:[email protected]:1080 https://api.ipify.org; echo

That should print the server's public address. Then confirm the controls hold. Each of these was run against the configuration above:

The hostname case matters: a request for an internal name was blocked after Dante resolved it to a 10.x address, so the private-range rules hold whether clients send names or addresses. The (2) in curl's message is the SOCKS reply code for a connection the ruleset does not allow.

IP reputation: one address, your range

This is where self-hosting and buying diverge most. Your Dante server's address sits in a hosting provider's range. The large clouds publish their ranges, and IP intelligence databases classify them as hosting. Many sites challenge or rate-limit hosting traffic more aggressively than consumer traffic, starting from the first request.

All of your traffic then shares that address. A rate limit that one job trips applies to every job on the server, and a block persists for as long as the target chooses. Adding servers adds addresses one at a time, each needing its own setup. For a partner integration that allowlists you, that concentration is the point: one stable, known address. For collection from public sites at volume, it is the bottleneck, and it is the reason proxy networks exist. Dedicated vs shared proxies covers how reputation behaves on addresses you do not operate.

Abuse handling: the complaints come to you

When someone complains about traffic from an address, the complaint goes to the abuse contact for its range. For a cloud server, that is the hosting provider, which forwards it to you and expects a response under its acceptable use policy. Repeated or unanswered complaints can end with the account suspended, and on a shared cloud account that can include unrelated production services.

So self-hosting means someone in your organization reads that inbox, can find the job that caused the complaint from Dante's logs, and can stop it. A provider puts its own abuse desk and policy between the target and you. That is not a transfer of responsibility for your traffic, which stays yours either way, but it changes who receives the first email and whose deadline applies to the answer.

Address space, ASN and what targets can see

Anyone can look up an address in the registries. RDAP and WHOIS show who holds the range, and the routing tables show which autonomous system announces it. For a rented cloud server, that is the cloud provider. If your organization holds its own allocation and announces it, it is your organization's name.

That visibility cuts both ways. For an allowlisted partner integration, it is reassuring: the partner can see the traffic is yours. For collection, it means the target knows exactly which organization is behind every request, and its response, whether a block, a letter or a support ticket to your hosting provider, is aimed precisely. What is IP provenance covers how these records are read, and why a buyer of proxies should read them for the provider's addresses too.

Staffing: what running it involves

The configuration is a page; the service is ongoing work. Before you commit, assign each of these to a named person:

• Patching the OS and Dante, and following its security notices.
• Accounts: creating one per consumer, rotating passwords, removing them when people or services leave.
• Monitoring: the process, connection counts, bandwidth against the hosting provider's limits, and authentication failures, which are the first sign of someone probing the server.
• Logs: shipping them somewhere durable and deciding how long to keep them.
• Abuse mail, as above, and the authority to stop a job.
• Capacity and geography: a new region is a new server, with its own address and its own setup.
• The pager, because a partner integration that depends on your egress address breaks when the server does.

For one or two servers carrying internal or partner traffic, that is a modest, known load. For a fleet that exists to spread collection across many addresses and countries, it is a team.

Provenance and legal exposure

Self-hosting has the simplest provenance story there is: you rented the server, you hold the contract, and the registry records match. No consent question arises, because no third party's device or connection is involved. A reviewer can verify it in minutes.

The legal exposure is also simple, and it is all yours. Your organization is the operator of the server, the account holder with the hosting provider and the party a target or a regulator will identify. A misconfiguration that turns it into an open proxy makes your address the source of someone else's abuse. Logs of who connected and where are records you hold and answer for.

Buying proxies changes the shape of the exposure rather than removing it. You take on the provider's sourcing as part of your own risk: a provider whose residential supply came from compromised devices makes its customers part of that, which is why residential proxy botnet risk and a sourcing review belong in the purchase.

Self-host or buy: a decision table

The common pattern in mature teams is both. Dante, or a small HTTP proxy, holds the organization's own egress for allowlisted integrations and internal tooling, and a provider carries public-web collection. Keep them separate: one credential and one log per path, so an incident on one never touches the other.

When buying is the better answer

If the decision table pointed to buying, ProxyForge sells residential, mobile, ISP and datacenter proxies from one account. Each line lists HTTP, HTTPS and SOCKS5, with username and password or IP allowlist authentication, and the endpoint and credentials for an order are shown on that order in the dashboard. Run the curl test above against that endpoint before moving a SOCKS-only tool across. ISP and datacenter addresses are dedicated to one customer and billed per address, for workloads that need a fixed exit without a server to operate; see ISP proxies and datacenter proxies.

The sourcing page sets out how the addresses behind those lines are acquired and audited, which is the provenance review that self-hosting lets you skip and buying does not.