SOCKS5 vs SOCKS5h: Where Does DNS Resolve?

The practical difference between socks5:// and socks5h:// is where the destination hostname is resolved. In curl, socks5:// resolves the hostname locally; socks5h:// delegates hostname resolution to the SOCKS5 proxy. That choice changes what your local resolver can observe and which names the proxy must resolve. Remote DNS means the proxy receives the hostname for resolution.

It does not choose the “best” proxy, prove a route is private, or guarantee that another library uses the same resolver path. Treat it as a client setting that needs a client-specific check.

Compare the two resolver paths

SOCKS5 can carry a domain-name address in its request. curl’s scheme mapping decides whether it first resolves that name locally or sends the name to the proxy. Username/password authentication is a separate SOCKS5 method; it does not decide DNS placement. RFC 1928 defines the request and RFC 1929 defines that authentication method. TLS is still the destination protocol after the SOCKS exchange.

Run a paired check with curl

Use one harmless, permitted hostname and keep every other option the same. Put only the host and port in PROXY_URL; the loop supplies the scheme. This example assumes an IP-allowlisted or no-auth route. If the endpoint requires username and password, provide them through the client’s private credential store or secret binding supported by your runtime; do not put them in PROXY_URL, shell history, or logs.

set -u

: "${PROXY_URL:?Set PROXY_URL to host:port without credentials}"
: "${TARGET_URL:?Set TARGET_URL to one permitted HTTPS URL}"

failed=0
for scheme in socks5 socks5h; do
  if ! curl --disable --proxy "${scheme}://${PROXY_URL}" --noproxy '' \
    --connect-timeout 10 --max-time 30 \
    --silent --show-error --output /dev/null \
    --write-out "scheme=${scheme} status=%{response_code} total=%{time_total}s\n" \
    "$TARGET_URL"; then
    printf 'scheme=%s request_failed\n' "$scheme" >&2
    failed=1
  fi
done
exit "$failed"

The if keeps the paired run going when one mode fails, so you can still test the other resolver path. The per-mode line and the final exit status preserve both the individual result and the fact that at least one mode failed.

The output tells you whether curl can complete the request in each mode. It does not by itself prove where every DNS packet travelled. For a controlled test, inspect resolver events on the client and the proxy side while running one unique permitted hostname at a time, then remove the test data. A missing local event is useful evidence only when the observation point can see the relevant resolver, cache, IPv4/IPv6 path, and time window.

Understand leak-test limits

A paired curl result describes curl's resolver path for that request; it does not prove what every browser, library, extension, or operating-system service did. A browser can use its own DNS-over-HTTPS setting, a library can bypass the proxy for a second request, and a local cache can hide a lookup from a packet observer. IPv6 and prefetch traffic can also be separate from the request you intended to test.

Keep these checks separate:

If socks5h:// works and socks5:// fails, the difference may be local DNS reachability, split-horizon DNS, or a client resolver policy. If both work, that does not prove that the name is safe to resolve locally. Decide based on the target’s permitted routing and the data boundary your team accepts.

For a wider protocol comparison, read HTTP versus SOCKS5. For application-specific proxy fields, use the client settings guide. When a provider needs to reproduce the resolver path, send the redacted support packet.

Sign up to choose your workflow and traffic package during onboarding.