DNS, WebRTC, and IPv6 checks for an HTTP/SOCKS5 deployment

When an HTTP or SOCKS5 proxy is working, the public IPv4 address may look correct while other network signals still follow a different path. DNS, IPv6, and WebRTC are common examples, but they should be tested for what they actually represent.

DNS: where is the name resolved?

A client can resolve a hostname locally and then send the resulting IP through a proxy, or it can ask the proxy side to resolve the name. SOCKS5 applications often expose a choice such as local DNS versus proxy DNS. Browsers may also use secure DNS features that change the expected behavior.

For troubleshooting, record both the proxy configuration and the application's DNS mode. Do not infer DNS behavior from the proxy protocol alone.

IPv6: a separate path that needs a separate test

If a downstream device has working IPv6, an application may use it even when the IPv4 proxy path is correct. The right response is not to declare that IPv6 must always be disabled. First test whether the application sends IPv6 directly, proxies it, or does not use it at all.

If your current deployment requires a single controlled path and the application cannot proxy IPv6, then disabling IPv6 for that specific environment may be a temporary operational choice. Treat that as a deployment decision, not a universal NetConfiger requirement.

WebRTC: useful for browsers, irrelevant to many other apps

WebRTC can expose local or candidate addresses in browser-based real-time communication. That is worth checking for browser workflows that use WebRTC. It does not tell you how a desktop API client, database tool, or unrelated service is routed.

A repeatable test sequence

1. Verify the Windows host's intended exit.
2. Configure the downstream application to use the NetConfiger HTTP or SOCKS5 endpoint.
3. Check public IPv4 behavior.
4. Check DNS resolution in the same application.
5. If IPv6 is available, test IPv6 separately.
6. For browsers that use WebRTC, inspect WebRTC candidates.
7. Compare the results with the same application after the proxy is removed.

The goal is evidence, not a single “leak/no leak” label. Once each path is observable, you can decide whether explicit proxy distribution is sufficient or whether that workload needs a gateway-level solution.