Proxy DNS Troubleshooting: Separate Local, Proxy, and Target Resolution Failures

A proxy request can fail before any HTTP response exists. The difficult part is identifying which name was being resolved, where resolution happened, and whether the failure occurred before or after the proxy connection.

This guide separates four stages: resolving the proxy endpoint, connecting to the proxy, resolving the target hostname, and connecting from the proxy to the target. The examples use documentation-only hostnames so you can adapt the workflow safely to an endpoint and target you are authorized to test.

The four questions to answer

1. Can the client resolve the proxy hostname? If not, the request cannot reach the proxy.
2. Can the client connect to the resolved proxy address and port? A DNS success does not prove the port is reachable.
3. Who resolves the target hostname? Depending on the proxy protocol and client option, resolution may happen locally or at the proxy.
4. Can the selected side reach the resolved target address? Resolution can succeed while routing, TLS, policy, or the target still fails.

Do not collapse these into “the proxy is down.” Record the failed stage and the exact client error first.

Start with a direct control request

Use a permitted target that you control or are authorized to test:

curl --silent --show-error --output /dev/null \
  --connect-timeout 10 --max-time 30 \
  --write-out 'code=%{http_code} remote_ip=%{remote_ip} connect=%{time_connect} total=%{time_total}\n' \
  https://example.com

A successful direct request only establishes that the client has some DNS and network access. It does not establish that the proxy endpoint, proxy credentials, requested geography, or proxy-to-target path works.

Run the control from the same client and network environment as the failing proxied request; otherwise the comparison can hide resolver, VPN, IPv4/IPv6, or trust-store differences.

Test whether the proxy hostname resolves locally

Use an operating-system resolver tool before testing authentication:

getent ahosts proxy.example.net
# or, where available:
dig +short proxy.example.net A
dig +short proxy.example.net AAAA

Record whether the answer is empty, whether IPv4 and IPv6 answers differ, and whether the result changes across the affected machine and a known-good machine. Do not publish real proxy endpoint addresses, credentials, or account-specific hostnames in a public bug report.

A local lookup failure can be caused by an incorrect hostname, resolver outage, search-domain behavior, DNS filtering, split-horizon DNS, VPN policy, or an IPv4/IPv6 mismatch. It is not evidence that the target hostname failed.

Separate proxy lookup from proxy connection

After the proxy hostname resolves, test the TCP connection without adding target-side assumptions:

nc -vz proxy.example.net 12345

Where nc is unavailable, use a client-native connection attempt and preserve the exact error. A timeout, connection refusal, TLS failure to an HTTPS proxy, and proxy authentication response describe different stages.

Do not treat an HTTP 407 Proxy Authentication Required response as DNS failure. Receiving 407 generally means the client reached a proxy that produced an HTTP response; authentication still needs diagnosis.

Understand local and proxy-side target resolution

curl documents two different SOCKS5 behaviors:

• --socks5 resolves the target hostname locally and sends an address to the proxy.
• --socks5-hostname, or the socks5h:// scheme, asks the proxy to resolve the target hostname.

Use the distinction as a controlled comparison, not as a performance benchmark:

# Local target resolution
curl --silent --show-error --output /dev/null \
  --socks5 'proxy.example.net:1080' \
  --connect-timeout 10 --max-time 30 \
  https://example.com

# Proxy-side target resolution
curl --silent --show-error --output /dev/null \
  --socks5-hostname 'proxy.example.net:1080' \
  --connect-timeout 10 --max-time 30 \
  https://example.com

Keep authentication in an approved secret-injection mechanism. Do not paste a real user:password@host proxy URL into shared logs or tickets.

Interpret the pair carefully:

• local resolution fails and proxy-side resolution succeeds: investigate the client resolver path;
• local resolution succeeds and proxy-side resolution fails: investigate proxy-side DNS, policy, or target reachability;
• both fail before an HTTP response: inspect the exact curl exit code and connection stage;
• both return an HTTP response: DNS probably completed, but the response may still reflect authentication, authorization, target policy, or application behavior.

These are diagnostic hypotheses, not universal conclusions. Client implementations, proxy protocols, cached answers, dual-stack behavior, and target configuration can change the result.

Do not misuse --resolve

curl's --resolve can pin a hostname and port to a chosen address for a test while preserving the URL hostname for TLS and application behavior:

curl --resolve 'example.com:443:192.0.2.10' https://example.com

192.0.2.10 is a documentation-only address. Do not send this command expecting a working service.

Use --resolve only when you are authorized to test a known target address. It can help determine whether a local DNS answer is the variable, but it can also bypass normal DNS load balancing, fail with the wrong address family, or produce misleading results when the target expects a different route. It does not change how the proxy endpoint hostname itself is resolved.

Capture a minimal evidence record

UTC time:
Client OS and version:
curl version and supported protocols:
Network/VPN state:
Proxy protocol:
Proxy hostname: redacted or approved test hostname
Proxy-host A/AAAA lookup result: sanitized
Proxy TCP connection result:
Target hostname: permitted hostname
Target resolution mode: local | proxy-side | unknown
Direct control result:
Proxied result:
Exact curl exit code and error text:
HTTP status, if any:
Requested geography/session mode:
Repeated on known-good client: yes | no
Credentials included in report: no
Test environment matches failing client: yes | no

An HTTP status and a curl process exit code are different fields. Preserve both. Also record whether the result came from an HTTP proxy, HTTPS proxy, SOCKS5 local resolution, or SOCKS5 proxy-side resolution.

What these tests can and cannot tell you

• DNS success does not prove the returned address is reachable.
• A successful proxy connection does not prove authentication or target access.
• Proxy routing does not grant permission to access a target or bypass its controls.
• Different DNS answers may be intentional because of geography, load balancing, split-horizon configuration, or IPv4/IPv6 selection.
• Cached answers can make two sequential tests incomparable.
• A target may block, rate-limit, redirect, or challenge a request after DNS succeeds.
• Example commands are diagnostic starting points. Validate them in your own approved environment before using the results to judge route behavior, latency, coverage, or target access.

Next step

Review the BytesFlows proxy setup guide to confirm the endpoint and credential format supplied by your account. Then use the proxy test tool as an additional connection check, while keeping the command-line stage evidence above. For account-specific endpoint or authentication questions, use the supported contact path in the BytesFlows FAQ.

References

• curl official manual↗: --socks5 performs local target resolution, while --socks5-hostname or socks5h:// delegates target hostname resolution to the proxy; --resolve changes the network address used for a host and port without replacing the URL hostname used by TLS and application protocols.
• RFC 9110↗: defines HTTP semantics including proxy authentication responses; an HTTP response should be distinguished from failures that occur before HTTP messaging.
• RFC 1928↗: defines SOCKS5 request address types, including domain names.