Proxy not working: step-by-step HTTP and SOCKS5 diagnosis

Core idea

A report that a proxy is not working can describe several stages: gateway DNS, TCP connection, authentication, SOCKS command or HTTP CONNECT, TLS, and the destination response. A final error without stage timing cannot identify the failing participant.

For Proxy not working: step-by-step HTTP and SOCKS5 diagnosis, split speed into connection latency, time to first byte, and transfer throughput. A tiny response mainly measures latency; a large file may hit the client or server link. Use a series of identical requests and a direct baseline from the same time window.

What the primary source establishes

Separate DNS, TCP, authentication, CONNECT, TLS, and origin response before changing routes or credentials.

The primary source, RFC 9110 — HTTP Semantics, RFC 9112 — HTTP/1.1, RFC 1928 — SOCKS Protocol Version 5, curl — Exit codes, MDN — 407 Proxy Authentication Required, defines the technical baseline but not every client and provider configuration. Read the normative behavior with its version and then verify your implementation. Treat anything beyond the source as a product feature that needs separate confirmation.

Controlled lab

Create owned routes returning 200, 403, 429 with Retry-After, and a delayed response. Send requests through a test HTTP or SOCKS5 proxy with valid and invalid credentials while recording DNS, connect, proxy handshake, TLS, first byte, and total time. Stop only the test gateway port to prove that a TCP refusal differs from an origin status.

Step-by-step verification

Start with a small owned HTTPS endpoint and an explicit proxy protocol. Verify gateway name and port, connect with valid credentials, repeat with a deliberately invalid password, and request another owned endpoint. Compare the same URL directly and through a second authorized exit in the same geography.

Host a small latency response and a known-size file on a controlled server. Warm up once, then collect at least five direct and five proxied measurements. Use one connection for route testing and separately reproduce normal concurrency when evaluating the real application.

Record DNS, connect, TLS, first byte, total time, and bytes. Compare medians. A slow first request can indicate DNS, TLS, or a cold cache; slow large transfers point to capacity, loss, or server limits. Rotating an IP without these measurements proves nothing.

• Name the protocol and control URL
• Separate DNS, TCP, proxy, and TLS
• Compare valid and invalid authentication
• Repeat directly and through a second authorized exit

Evidence to retain

Record time, client version, protocol, sanitized gateway, exit IP, DNS, connect, TLS, TTFB, total, HTTP status, curl exit code, and a short error class. Remove Proxy-Authorization, Cookie, tokens, full query strings, and user response content.

Include file size, endpoint region, access type, raw values, and median. A 10 MiB check measures the path from the client to the WorldProxy test endpoint through that proxy, not the speed of the whole internet. Treat fast HTTP errors as failed checks, not performance successes.

Define report columns and time format before the run. A result without context becomes a guess: the address, cache state, and changed condition are unknown. Record controlled failures as well as successes so the check proves that it can distinguish states.

Interpreting the result

Do not treat 403, 407, 429, and timeout as one fault. A 407 generally requests proxy authentication, 429 asks the responding party to reduce rate, 403 can be destination policy, and a timeout must be assigned to a phase. Unbounded rotation destroys evidence and adds load.

One successful endpoint does not prove universal destination access, and ping does not test HTTP CONNECT or SOCKS. Results can depend on destination, address family, route, and time; a repeat should change only one variable.

One successful run confirms only one client, route, and moment. Repeat while changing one variable and state the limits. When observation conflicts with documentation, rule out cache, client version, and intermediaries before creating a reproducible support case.

Worked decision process

Define a measurement budget for Proxy not working: step-by-step HTTP and SOCKS5 diagnosis: warm-up, five small requests, five known-file transfers, the same direct controls, fixed concurrency, and a pause between heavy cycles. Estimate billable traffic before running the test.

Separate latency from throughput. A small response exposes DNS, connect, TLS, and first-byte cost. A 10 MB file measures the path from the client to the WorldProxy endpoint through the selected proxy, not universal internet speed. Test a browser workload separately when connection reuse matters.

Confirm anomalies against a direct route, another exit in the same geography, and a delayed repeat. Keep median, spread, and failure count. A best result hides instability, while an average can be distorted by one hang.

Common mistakes

Do not compare morning Wi-Fi with evening Ethernet, different files, or different CDN nodes. Avoid unlimited timeouts and repeated heavy checks. They consume traffic and create their own queue. Run a bounded sample, pause, and repeat only anomalies.

Stop when errors rise, a source returns a limit, the task would require bypassing protection, or secrets enter logs. Save sanitized diagnostics and correct the cause first. More concurrency or another IP can hide the fault and add load without improving evidence.

Rollout and maintenance criteria

Define the decision boundary before rollout: which observation permits continuation, which requires review, and which stops the workflow. Record acceptable error ratio, maximum wait, and the owner of every exception so a temporary failure cannot silently become permanent configuration.

Review real load, cost, and quality after the first week. Schedule a small control after client, proxy-service, or network changes. Archive outdated instructions with their replacement date and reason so operators do not follow conflicting configurations.

Operational checklist

Turn the successful experiment into a short procedure covering owner, safe configuration, limits, and stop conditions. Every run needs a terminal status. After browser, library, or network changes, run a small control before the main queue.

• A direct baseline exists
• File and endpoint match
• Phases are recorded
• Median is used
• Errors are separate
• Measured path is stated