Fix SOCKS5 proxy connection errors on Linux and Windows

[braydos-h]

The SOCKS5 proxy functionality is consistently failing on both Linux and Windows. The following errors are repeatedly observed:

• [PROXY] <ip>:1080 target error: Connection refused by target host
• [PROXY] <ip>:1080 failure: timed out (handshake)
• [PROXY] <ip>:1080 target error: Host unreachable

Example log output:

[PROXY] 10.124.0.23:1080 target error: Connection refused by target host
[PROXY] 10.124.0.93:1080 target error: Connection refused by target host
[PROXY] 10.124.0.171:1080 target error: Connection refused by target host
[PROXY] 10.124.0.24:1080 failure: timed out (handshake)
[PROXY] 10.124.0.83:1080 failure: timed out (handshake)
[PROXY] 10.124.0.8:1080 failure: timed out (handshake)
[PROXY] 10.124.0.74:1080 failure: timed out (handshake)
[PROXY] 10.124.1.40:1080 target error: Connection refused by target host
[PROXY] 10.124.0.39:1080 failure: timed out (handshake)
[PROXY] 10.124.0.164:1080 failure: timed out (handshake)
[PROXY] 10.124.0.44:1080 failure: timed out (handshake)
[PROXY] 10.124.0.167:1080 failure: timed out (handshake)
[PROXY] 10.124.0.227:1080 target error: Host unreachable
[PROXY] 10.124.0.58:1080 failure: timed out (handshake)
[PROXY] 10.124.0.6:1080 failure: timed out (handshake)
[PROXY] 10.124.0.252:1080 target error: Connection refused by target host
[PROXY] 10.124.0.182:1080 failure: timed out (handshake)

Steps to reproduce:

1. Attempt to use the SOCKS5 proxy feature on Linux or Windows.
2. Observe repeated connection errors and timeouts in the logs.

Expected behavior:

• Proxies should connect successfully or, if unreachable, fail gracefully without spamming the log.

Actual behavior:

• Connection attempts consistently fail with the above errors.

Please investigate and fix the SOCKS5 proxy implementation so it works reliably on both Linux and Windows platforms.

[HytexLy]

[UPDATE]
We’ve shipped GUI updates that surface proxy logs directly in the app. You can now see per‑request timing and error details (connect time, handshake status, response codes, retries, and failure reasons) in real time. This visibility gives us what we need to diagnose the scanning failures with far more precision.

We’re still isolating the root cause, but the behavior strongly suggests rate limiting and connection churn when we burst to large target sets (~100 IPs) in parallel. This is amplified on slower or unstable Wi‑Fi, where cold connections and handshake overhead make timeouts more likely. Symptoms include intermittent timeouts, inconsistent latency as concurrency increases, and success rates that drop sharply under load.

Planned work:

Pre‑scan proxy health checks: Verify TCP connectivity, optional TLS/auth, and a minimal request via each proxy; record baseline RTT, success rate, and jitter.
Stable connection pool: Warm connections and reuse sockets (keep‑alive) to reduce handshake cost and flakiness before the main scan starts.
Concurrency and rate control: Cap global and per‑proxy in‑flight requests, stagger bursts, and add exponential backoff with jitter. Respect retry‑after signals to avoid tripping provider limits.
Adaptive routing: Promote healthy proxies that meet thresholds, quarantine or rotate out noisy/slow ones, and avoid overloading any single exit.
Robust retries and protections: Use bounded retries with sensible timeouts and a circuit breaker to stop hammering failing routes.
Better observability: Track connect time, TTFB, status codes, timeouts, and error categories per proxy and per target in the GUI to validate improvements.
Expected impact:

Fewer high‑ping failures and timeouts, reduced rate‑limit hits, and more consistent scan results, especially on slower Wi‑Fi and under higher concurrency.
Next steps:

Implement health checks and throttling first, validate with small batches, then roll out pooling/backoff behind a feature flag. We’ll iterate based on the new telemetry and adjust thresholds as we learn more.

[HytexLy]

[UPDATE]
we are really close to having this solved. Currently, the proxy's are in good health, with the main problem being that mullvad doesn't actually have many functioning ip's. Currently, we only have ~200 proxy's in good health and ready to run. This also means that only 200+ threads can run, since currently every thread gets a personal proxy.

Our next goal will be further improving proxy's and allowing threads to share proxy's, that way, people with beefy pc's can run fast and stay secure. Currently, proxy's aren't reliable for speed but assure maximum security while scanning.

[braydos-h]

@codex review