HTTP CONNECT, SOCKS5 and MASQUE: choose a proxy protocol
Match the transport to your client before changing your proxy pool.
A residential IP does not tell you whether your client can send UDP. A proxy that carries HTTPS traffic does not necessarily encrypt the connection to the proxy. Before changing your proxy pool, check which protocol your application actually uses.
Two choices sit underneath a proxy configuration: where the exit address comes from, and how traffic reaches it. Residential, ISP and datacenter describe the first choice. HTTP CONNECT, SOCKS5 and MASQUE describe different ways to carry traffic. Treat them as separate decisions.
Start with compatibility. For an ordinary HTTPS collection job, a supported TCP tunnel may be enough. A workflow that specifically needs UDP or HTTP/3 needs a compatible path through the client, proxy and network. A different IP address cannot add a missing transport feature.
Separate the proxy connection from the destination connection
Picture a collector reaching a public catalog through a proxy. There is a client-to-proxy connection and a proxy-to-destination path. Record those separately in your configuration notes. Otherwise, a statement such as “we use HTTP/3” leaves an important question unanswered: on which connection?
Classic CONNECT requests establish a tunnel to a destination host and port. Once established, the tunnel relays bytes; an HTTPS client can conduct its destination TLS exchange through it. This does not, by itself, describe encryption between your client and the proxy. That depends on the proxy connection you configured.
That distinction matters when checking credentials and troubleshooting connection failures. Keep certificate verification enabled. If changing an endpoint scheme fixes a connection, write down which connection changed instead of describing the entire route as secure or insecure.
What each protocol carries
| Protocol | Relevant capability | What to verify |
|---|---|---|
| HTTP CONNECT | A conventional tunnel for TCP traffic to a host and port. | Client support, proxy authentication, permitted destination ports and the proxy connection scheme. |
| SOCKS5 | Defines CONNECT, BIND and UDP ASSOCIATE commands. | The exact commands supported by both your application and the endpoint. |
| MASQUE CONNECT-UDP | Proxies UDP using HTTP. | A compatible client, endpoint and network configuration, including the chosen HTTP version and datagram support. |
SOCKS5 is often used for general TCP connections, but the specification also defines UDP forwarding. A SOCKS5 setting in a browser or scraping library is not evidence that the software implements UDP ASSOCIATE. Check the feature, rather than inferring it from the protocol name.
For a simple catalog collector, the useful question is whether the client can fetch the required pages with the configured endpoint. For a UDP-dependent application, start by confirming that exact capability. These are different acceptance checks, even if they use the same exit network.
Where MASQUE and HTTP/3 fit
HTTP/3 maps HTTP onto QUIC. A conventional TCP tunnel does not carry native QUIC packets to the destination. A client may use another supported HTTP version instead, but successful fallback depends on the client and destination.
MASQUE is a family of proxying work, not a synonym for HTTP/3. CONNECT-UDP defines UDP proxying through HTTP, with mappings for HTTP/1.1, HTTP/2 and HTTP/3. HTTP Datagrams provide supporting mechanisms. An endpoint advertising MASQUE still needs to specify the actual feature and configuration it accepts.
Do not turn protocol support into an assumed speed improvement. The UDP proxying specification discusses performance tradeoffs, including interacting congestion-control layers. For your workload, compare completed, valid records under the same conditions. A faster handshake has little value if the returned page is missing the fields your application needs.
Keep two test results if HTTP/3 matters: whether the requested transport was negotiated, and whether the collection produced the expected record. A request that falls back successfully can pass the second test while failing the first.
Choose where DNS resolution happens
Proxy routing and hostname resolution deserve separate checks. In libcurl, SOCKS5 and SOCKS5-hostname are distinct proxy types: the latter asks the proxy to resolve the hostname. The corresponding curl URL schemes are socks5:// and socks5h://. These are curl conventions; another library may expose the choice differently.
If a job succeeds locally but fails in a worker environment, compare resolver behavior alongside the proxy configuration. Record the library and version used for the test. A hostname that resolves on your laptop may produce a different result elsewhere, so preserve enough context to reproduce the failure.
Use a small verification plan
Start against a destination you control or a public test endpoint intended for diagnostics. Avoid testing a new transport and a new parser at the same time. Use one known response and change one configuration choice per run.
- Write down the requirement. Ordinary HTTPS retrieval, a stable TCP connection and native UDP each imply a different test.
- Confirm endpoint details. Check the scheme, port, authentication method and supported commands. Keep credentials out of reports and screenshots.
- Inspect both connections. Distinguish client-to-proxy negotiation from the destination protocol. Do not use one as proof of the other.
- Check the returned content. Validate a known field or page marker. A successful connection is only the retrieval step.
- Repeat under comparable conditions. Keep location, request set and concurrency fixed before drawing conclusions about reliability or cost.
For example, a team collecting a public product catalog can begin with its existing HTTPS client and a supported tunnel. If a later requirement calls for native UDP, that becomes a new compatibility test. It should not silently change the meaning of an earlier “proxy working” result.
Choose for the application you run
Use the simplest supported protocol that meets the requirement you can demonstrate. Keep protocol experiments separate from changes to IP sourcing, parsing and scheduling so that failures remain explainable.
If you are still choosing the exit network, read our residential, ISP and datacenter guide. For connection syntax, check the Crawlhub integration documentation for the product and client you plan to use. The standards discussed here do not establish feature availability in an individual product.
