Building an honest proxy checker: states, timeouts, and concurrency
An online label should come from a reproducible chain, not one signal. A TCP port can accept connections while the relay route is broken; the proxy can be healthy while the control site is down. An honest checker retains stage-level evidence and avoids false precision in the user interface.
Key points in one minute
- TCP, authentication, relay, and destination response are separate checks.
- Checking is not the same as online or offline.
- Connection and total timeouts are configured independently.
- Concurrency uses a bounded pool and each operation has its own result.
A multi-stage check
A useful chain includes the relevant DNS resolution, connection to the proxy, authentication, CONNECT or SOCKS relay, and a request to a control endpoint you operate. Store duration and status for each stage so support can identify the failing boundary.
- Proxy unreachable: no connection to the endpoint.
- Access denied: transport works but authentication failed.
- Destination unreachable: the proxy replied but no relay was created.
- Verified: the control request completed as expected.
Four user-facing states
A practical model is checking, online, offline, and unconfirmed. A timeout or lost response first produces an uncertain result rather than unconditional offline. Show the last successful signal and offline duration separately from the current attempt.
Timeouts and cautious retries
Connection timeout limits connection establishment, while total timeout covers DNS and the complete operation. One delayed retry can be reasonable for a read-only check. Control commands must not use the same retry rule because the first command may have executed even if its response was lost.
Scaling without a request storm
The curl multi interface supports many concurrent operations, but the application still sets limits per system, server, and customer. Add jitter, batch checks, and open a circuit breaker during a site-wide incident. Transfer completion means only that it ended; success comes from each individual result.
Evidence for support
Store proxy ID, time, stage, sanitized error code, durations, and checker version. Never store passwords or control links. Report a location-wide incident separately so automatic repair does not start moving large numbers of healthy proxies.
Practical checklist
- 1Separate DNS, connect, auth, relay, and control request.
- 2Use at least four result states.
- 3Set distinct connection and total timeouts.
- 4Bound concurrency and add jitter.
- 5Pause bulk actions when a location-wide incident is suspected.
- 6Remove secrets from diagnostic events.
Sources and documentation
This material is based on primary, official, and technical sources. The article is an original summary written for this knowledge base.