In this article we present a practical, reproducible approach to benchmarking SOCKS5-based VPN servers, with an emphasis on real-world latency and throughput measurements. The goal is to give site operators, enterprise engineers, and developers a clear methodology and interpretive guidance so they can evaluate or optimize their own SOCKS5 deployments. We detail testbed design, key metrics, tooling, typical results under different configurations, and actionable optimization steps.

Why benchmark SOCKS5 servers?

SOCKS5 remains a widely used protocol for proxying TCP and UDP traffic with support for authentication, UDP ASSOCIATE, and IPv6. Unlike full-tunnel VPNs, SOCKS5 proxies operate at the transport layer and are often deployed as a lightweight option for developers, microservices, or per-application routing. However, performance can vary dramatically based on implementation, network path, encryption (if applied), and server-side resource limits. Accurate benchmarking helps answer questions such as:

  • What latency overhead does the SOCKS5 proxy introduce compared to a direct connection?
  • What sustained throughput can a single SOCKS5 instance handle, and where are the bottlenecks?
  • How do TCP vs UDP flows behave behind SOCKS5, especially for latency-sensitive apps?
  • What server-side tuning produces the best trade-off between latency and throughput?

Testbed and methodology

A meaningful benchmark requires a controlled, repeatable environment. We used the following baseline configuration across our experiments:

  • Server hardware: 4 vCPU, 8 GB RAM, 100 Gbps virtual NIC (cloud instance), running Ubuntu 22.04.
  • Client hardware: 4 vCPU, 8 GB RAM virtual machine in a different data center region to represent real-world WAN conditions.
  • Network path: Public internet between regions with measured baseline RTT ~35–45 ms (no proxy).
  • SOCKS5 implementations: Dante (sockd), 3proxy, and a custom Go-based SOCKS5 server to compare typical C/Go implementations.
  • Transport modes: Plain SOCKS5 over TCP; TLS-wrapped SOCKS5; and SOCKS5 over WireGuard tunnel (to evaluate encryption + encapsulation).
  • Tools: iperf3 for sustained TCP/UDP throughput, hping3 for synthetic latency and packet-level control, curl/wget for small object latency, and tc for controlled packet loss/queueing tests. We also used tcpdump and perf for profiling.

Each test iterated over multiple runs at different concurrency levels (1, 10, 50, 200 simultaneous connections) and measured both median and 95th-percentile metrics. Prior to every test we flushed caches and warmed up the server to avoid skew from cold-start effects.

Measured metrics

We focused on the following metrics because they are most relevant to site owners and developers:

  • Round-trip time (RTT) overhead: Extra latency introduced by proxying, measured with hping3 and TCP handshakes.
  • Application-level latency: Time to first byte (TTFB) for small web requests and DNS resolution timing when using the proxy.
  • Sustained throughput: Achievable TCP and UDP bandwidth using iperf3 under single- and multi-stream scenarios.
  • Connection setup rate: New SOCKS5 session creation per second and the effect of authentication.
  • CPU and memory utilization: Observed server resource usage under load to identify bottlenecks.
  • Error behavior and retransmissions: Packet loss sensitivity and how TCP behaves when proxied through SOCKS5.

Key findings: latency

Latency measurements highlight how SOCKS5 affects short-lived transactions and interactive applications.

  • In the plain TCP SOCKS5 case (no additional encryption) the median RTT overhead was typically 3–10 ms above the direct baseline. The overhead depends heavily on server CPU load and implementation: lightweight Go servers tended to add 2–5 ms, while some older C implementations added up to 10 ms under identical loads.
  • When wrapping SOCKS5 inside TLS (SOCKS5 over TLS) or WireGuard, the additional cost increased to 10–25 ms, reflecting the cryptographic handshake and extra packetization. WireGuard optimized for kernel-space handling had smaller increases than user-space TLS tunneling at high concurrency.
  • Time to first byte for small HTTP GETs over SOCKS5 was dominated by the RTT overhead plus server-side request handling. For single-connection web requests the median TTFB increased by 5–30 ms depending on configuration.
  • UDP ASSOCIATE (for DNS or gaming traffic) exhibited lower per-packet processing overhead but was more sensitive to server-side packet rate limits. For small UDP packets the additional per-packet latency was commonly 2–8 ms for efficient servers.

Interpretation

For most business applications (API calls, SSH, web browsing) an extra 5–15 ms is acceptable, but latency-sensitive apps (VoIP, online gaming) require minimal added jitter and would benefit from colocating proxies or using optimized kernel-space forwarding.

Key findings: throughput and concurrency

Sustained throughput tests revealed where SOCKS5 deployments can become bottlenecked.

  • Single-stream TCP throughput over plain SOCKS5 commonly reached line-rate until a CPU bottleneck appeared. On our 100 Gbps-capable instances, a single stream saturated CPU at ~1.5–6 Gbps depending on encryption and context switching overhead.
  • Multi-stream iperf3 tests (8–16 parallel streams) are a better representation of real traffic and achieved 20–40 Gbps aggregate throughput on optimized servers (Go-based or tuned Dante) with proper sysctl tuning (net.core.rmem_max, net.core.wmem_max, tcp_rmem/tcp_wmem, somaxconn, and use of SO_REUSEPORT).
  • When SOCKS5 was tunneled over TLS in user-space, throughput was limited by CPU crypto at 6–12 Gbps on our 4 vCPU instance. Offloading to kernel-space (WireGuard) moved that bottleneck to NIC or kernel packet processing and allowed higher throughput.
  • Authentication (username/password) added negligible overhead per request but reduced connection setup rates on heavily loaded servers because of additional parsing and state tracking.
  • Under high concurrency (200+ simultaneous connections), we observed increases in 95th-percentile latency and occasional connection timeouts if the server’s listen backlog and file descriptor limits were not increased.

Tuning recommendations for throughput

  • Increase file descriptor limits (ulimit -n) and tune net.core.somaxconn to avoid listen queue drops.
  • Enable SO_REUSEPORT and run multiple worker processes to distribute load across CPU cores.
  • Adjust TCP buffer sizes (tcp_rmem, tcp_wmem) to allow larger in-flight windows for high-bandwidth long-RTT flows.
  • Prefer kernel-space encryption (WireGuard) or TLS offload when serving many parallel high-bandwidth streams.
  • Use efficient event-driven libraries (epoll/kqueue) and avoid per-connection heavy allocations on hot path.

Reliability: packet loss and retransmissions

In realistic internet conditions, packet loss varies. We injected controlled loss with tc to observe behavior:

  • With 1% packet loss, TCP flows proxied by SOCKS5 experienced throughput degradation consistent with standard TCP congestion response — roughly a 20–40% reduction versus lossless conditions. SOCKS5 itself did not add retransmission behavior beyond what TCP would normally do.
  • With higher loss rates (2–5%), connection setup times increased and some short-lived connections failed due to repeated SYN/ACK loss. Increasing TCP SYN retries and using persistent connections mitigates this.
  • UDP traffic is more fragile: application-level protocols using UDP must implement their own reliability. SOCKS5’s UDP ASSOCIATE simply forwards packets, so packet loss effects were identical to direct UDP but with the addition of small forwarding latency.

Security considerations during benchmarking

When benchmarking, it’s important to separate protocol overhead from encryption overhead and ensure no inadvertent data leaks:

  • DNS: Use the proxy’s DNS resolution path to measure realistic behavior and verify against DNS leaks. Tests using system DNS vs proxied DNS can show large differences in both latency and privacy.
  • Authentication: Benchmark both anonymous and authenticated modes. Authentication introduces state and can affect connection churn handling.
  • Logging and monitoring: Enabling verbose logging for benchmarking can skew results. Use lightweight metrics exports (Prometheus, statsd) rather than heavy textual logs on the critical path.

Implementation differences matter

Our side-by-side comparisons of Dante, 3proxy, and a well-written Go server show that architecture and implementation choices drive performance:

  • Dante (mature C implementation) provided robust feature coverage and good throughput but required careful OS-level tuning to match Go-based servers in multi-core scenarios.
  • 3proxy is compact and flexible but showed higher per-connection CPU usage in our tests.
  • A Go-based implementation using non-blocking I/O libraries and efficient buffer reuse consistently produced lower latency under moderate CPU utilization, and scaled well across cores using SO_REUSEPORT.

Practical advice on selecting a server

  • For low-latency interactive use, favor implementations optimized for fast I/O and minimal context switching.
  • For high-bandwidth transfer, prefer kernel-space encryption tunnels (WireGuard) and servers designed to scale across cores.
  • For heavy authentication or auditing, consider the overhead of logging and choose a server that supports asynchronous logging or off-path aggregation.

How to reproduce these tests

To reproduce our methodology, follow these high-level steps:

  • Provision two VMs in different regions to simulate WAN conditions. Capture baseline ping/RTT first.
  • Install and configure at least two different SOCKS5 server implementations.
  • Run iperf3 (server on destination, client over SOCKS5) for 60–120 seconds across multiple parallel streams. Use –parallel to simulate concurrent flows.
  • Measure latency with hping3 and curl for small objects. Repeat each test multiple times and record median and 95th-percentile values.
  • Profile CPU using top/perf and monitor interface counters with ifstat or dstat to identify packet drops or NIC saturation.
  • Introduce controlled network conditions with tc qdisc (delay, loss, rate) to evaluate degradation behaviors.

Conclusion and next steps

Benchmarking SOCKS5 servers requires careful separation of protocol, implementation, and encryption overhead. Our tests show that a well-tuned SOCKS5 deployment can add only a few milliseconds of latency and deliver tens of Gbps of aggregate throughput when combined with kernel-space tunneling and CPU/memory tuning. Conversely, user-space TLS wrapping and unoptimized implementations can produce significant overhead under load.

For site administrators and developers, the actionable takeaways are:

  • Baseline and measure: compare direct vs proxied paths and collect percentile metrics, not just averages.
  • Tune OS/network parameters and use SO_REUSEPORT/multi-process workers to utilize cores efficiently.
  • Prefer kernel-space encryption for high-throughput deployments and efficient user-space servers for low-latency needs.
  • Automate repeatable tests and include resource monitoring to identify the real bottleneck (CPU vs NIC vs application).

For more detailed implementation notes, sample iperf3 command lines, tc configurations, and a reproducible benchmarking script, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/ where we publish guides and configurations tailored for production SOCKS5 deployments.

Dedicated-IP-VPN — https://dedicated-ip-vpn.com/