Proxy operator’s field guide
A proxy changes a connection path. Everything else—DNS ownership, application scope, TLS, exit persistence, and what a test proves—depends on the client and configuration.
Reading order: route → scope → protocol → persistence → evidence. Skip directly to the uncertainty you are trying to remove.
Choose by uncertainty
Each path below ends at a guide with an original diagram, test, decision table, or evidence model. You do not need to read the whole library in sequence.
Trace the route first
Follow HTTP forwarding, CONNECT tunnels, SOCKS5 negotiation, DNS ownership, TLS, and reverse-proxy paths one connection at a time.
Five request paths · reproducible route lab
Choose traffic scope
Decide from the applications, DNS requests, and routes that must change—not from a blanket claim about anonymity or encryption.
Scope matrix · DNS and TLS checks
Choose the control protocol
Compare exact handshakes, DNS location, authentication, TLS behavior, TCP and UDP limits, and current cURL and Requests syntax.
Wire trace · captured client behavior
Design persistence
Separate address persistence, assignment, sharing, and session policy before choosing a rotation interval or sticky session.
Session vocabulary · safe-use boundaries
Model the operator risk
Treat operator identity, transport protection, logging, availability, and endpoint tampering as separate uncertainties.
Threat model · HTTPS boundary
Interpret one observation
Read the label as a limited report about observed address and header signals, never as proof of privacy, safety, or authorization.
Header evidence · limitation map
Evidence boundary
Use the left column to name the mechanism, the middle column to state the supported inference, and the final column to prevent that observation from becoming an unsupported promise.
| Term or signal | It can tell you | It cannot tell you |
|---|---|---|
| Proxy route | Can indicateWhich configured client connection reaches an intermediary before the destination.Does not establishWhether every application, DNS lookup, background service, or alternate IP family used the same route. | Whether every application, DNS lookup, background service, or alternate IP family used the same route. |
| VPN route | Can indicateWhich traffic the operating system or VPN policy placed inside its tunnel.Does not establishThat every DNS path, IPv6 route, split-tunnel exception, or application-specific connection is covered. | That every DNS path, IPv6 route, split-tunnel exception, or application-specific connection is covered. |
| HTTP proxy | Can indicateThat a client can use HTTP proxy semantics, including forwarding or CONNECT where supported.Does not establishThat the client-to-proxy hop is encrypted, that non-HTTP traffic works, or that the operator is trustworthy. | That the client-to-proxy hop is encrypted, that non-HTTP traffic works, or that the operator is trustworthy. |
| SOCKS5 | Can indicateThat a client and server can negotiate a general relay; client settings determine where name resolution occurs.Does not establishThat UDP, authentication methods, remote DNS, or every application feature is supported in a specific deployment. | That UDP, authentication methods, remote DNS, or every application feature is supported in a specific deployment. |
| Rotating or sticky | Can indicateHow the provider intends to assign or retain an exit address for a request or session.Does not establishThat rotation grants permission, avoids controls, preserves application state, or guarantees a requested region. | That rotation grants permission, avoids controls, preserves application state, or guarantees a requested region. |
| Anonymity grade | Can indicateWhat one checker path observed or inferred from relayed address and header signals.Does not establishWho operates the proxy, what it logs, whether DNS or browser traffic leaks, or what a future request will expose. | Who operates the proxy, what it logs, whether DNS or browser traffic leaks, or what a future request will expose. |
Reproducible check
The lab is deliberately small: one client, one authorized destination, one change at a time. Its job is to distinguish a verified request path from assumptions about an entire device.
Open the IP diagnostic in the same browser or client path you plan to change. Record the public address and IP version.
Open the IP diagnosticWrite down the exact client, destination, DNS behavior, and traffic family that should use the intermediary.
Use the scope matrixUse a client-specific runbook and a destination you are authorized to test. Keep credentials out of command history and screenshots.
Choose a setup runbookRepeat the IP observation through the configured client. A changed exit confirms that request path—not the whole device.
Trace ambiguous pathsSeparate syntax, DNS, authentication, tunnel, TLS, destination, and policy failures. Stop when permission or ownership is unclear.
Read the checker evidence contractContinue by task
