DEV Community

98IP Proxy
98IP Proxy

Posted on

SOCKS5 DNS Debugging: Change One Variable at a Time

A request that works by IP but fails by hostname often points to DNS placement rather than proxy authentication. With SOCKS5, the destination name may be resolved by the client or passed through the proxy route for remote resolution.

Compare the two paths

In curl, the scheme makes the choice visible:

curl --proxy "socks5://$PROXY_HOST:$PROXY_PORT" \  https://en.98ip.com/

curl --proxy "socks5h://$PROXY_HOST:$PROXY_PORT" \  https://en.98ip.com/
Enter fullscreen mode Exit fullscreen mode

Keep the target, proxy endpoint, credentials, headers, timeout, and test time unchanged. Change only the DNS mode.

What a changed result tells you

If the request changes when only the scheme changes, inspect:

  • whether local and remote resolvers returned different addresses;
  • whether one route selected IPv4 and the other IPv6;
  • whether split-horizon DNS returned a private address;
  • whether a CDN selected an edge based on lookup location;
  • whether the CI runner uses a different resolver than development;
  • whether the proxy network can reach the selected destination address.

Do not label every failure as a 407 problem. Proxy authentication occurs at a different layer. A DNS decision can change the destination before the authenticated route reaches it.

Local DNS can be intentional

Client-side resolution is useful for internal zones, hosts-file overrides, development mappings, or applications that must choose a specific address. It also makes the resolved address available before connection.

The tradeoff is that the local resolver sees the lookup, and the answer may represent the client network instead of the proxy exit.

Remote DNS has limits

Proxy-side resolution can reduce local DNS exposure and better represent the exit network. It does not guarantee anonymity, force a particular geography, or fix unrelated authentication, TLS, or destination-policy errors.

Document which mode each workload uses. Libraries do not always share the same names or defaults, so test the exact client version deployed in production.

Separate DNS mode from address family

If local resolution chooses IPv6 and remote resolution chooses IPv4, two variables changed. Run explicit IPv4 and IPv6 tests when the client supports them. Record the selected address family, connect timing, response status, and region result.

Safe observability

Logs should include a non-secret route label, client version, DNS mode, address family, timing phase, and status. Do not record proxy passwords, authorization headers, full session tokens, sensitive internal hostnames, or confidential response bodies.

Checklist

  1. Reproduce with one target and no retries.
  2. Compare local and proxy-side hostname resolution.
  3. Record IPv4 or IPv6 for each result.
  4. Test the hostname and an authorized direct IP where appropriate.
  5. Verify the actual route and destination address.
  6. Repeat in the same runtime used in production.
  7. Sanitize logs before sharing them.

Use proxy-assisted testing only for authorized systems and respect destination terms, privacy rules, and rate limits.

Disclosure: I work with 98IP. English service information: https://en.98ip.com/?k=dev

Top comments (0)