HTTP/3 (QUIC) and UDP support is now available on Infatica proxies

You can now send HTTP/3 requests over QUIC and route UDP traffic through SOCKS5 using Infatica residential, mobile, shared datacenter, and residential IPv6 proxies.

For teams working with HTTP/3-enabled websites or applications that need a SOCKS5 UDP relay, this adds another connection option to their proxy setup. Here’s where support is available, what the protocols do, and how to check an HTTP/3 request with curl.

Which Infatica proxies support HTTP/3 and UDP?

The update covers four proxy products:

Proxy product	HTTP/3 over QUIC	UDP through SOCKS5
Residential proxies	Supported	Supported
Mobile proxies	Supported	Supported
Shared datacenter proxies	Supported	Supported
Residential IPv6 proxies	Supported	Supported

Choose the product that fits your workflow, then use a client that supports the connection method you need. For HTTP/3 requests, the destination website must support HTTP/3 as well.

How HTTP/3, QUIC, and UDP fit together

The three names describe different parts of a connection.

UDP is a transport protocol for sending datagrams across a network. QUIC builds on UDP, adding features such as reliable delivery, encryption, and independent data streams, as defined in the QUIC transport standard. HTTP/3 carries HTTP requests and responses over QUIC.

That differs from HTTP/2, which uses TCP. With HTTP/2 over one TCP connection, a lost packet can delay delivery across several requests. QUIC’s independent streams let other streams continue while the affected stream recovers. The HTTP/3 standard explains how this works.

Proxy support matters here. A conventional HTTP CONNECT tunnel carries TCP traffic. Carrying QUIC traffic requires a way to relay UDP, such as CONNECT-UDP. This mechanism is defined in the UDP proxying standard developed by the IETF MASQUE working group.

Infatica supports HTTP/3 over QUIC through this proxy path. UDP traffic can also be relayed through SOCKS5.

Where HTTP/3 can help

HTTP/3 can reduce connection setup time and the delays that packet loss creates between parallel requests. Those properties can be useful when a client makes concurrent requests to an HTTP/3-enabled host, particularly on a network with noticeable latency or packet loss.

For example, a collection job retrieving several resources from the same host may benefit from QUIC’s independent streams. Packet loss affecting one stream does not require unrelated streams to wait for that stream’s missing data.

The result still depends on your client, destination, network path, and request pattern. A useful next step is to compare a representative workload with your current setup, keeping the target, proxy location, and concurrency consistent.

What UDP support through SOCKS5 adds

SOCKS5 UDP support lets compatible applications relay UDP datagrams through the proxy. The client needs to implement the SOCKS5 UDP relay mechanism.

Check this capability in the application you plan to use. An application can support SOCKS5 for TCP connections without implementing UDP relay. For UDP workloads, both the proxy and the client need to support it.

How to verify HTTP/3 with curl

The following example checks an HTTP/3 request through an Infatica HTTPS proxy using CONNECT-UDP.

1. Check the prerequisites

You’ll need:

• An active supported proxy product and credentials from a generated proxy list.
• curl 8.21.0 or later, built with HTTP/3 proxy and CONNECT-UDP support.
• An HTTPS destination that supports HTTP/3.
• A network path that permits the UDP traffic required by the connection.

Check your installed curl version with:

curl --version

Version alone is not enough. The build must include HTTP/3 proxy support. curl currently labels its HTTP/3 proxy implementation experimental, so check the capabilities of the build you’re using.

2. Send an HTTP/3 request

Infatica’s documentation notes a curl issue affecting HTTP/3 proxy authentication. Use the explicit proxy authorization header shown below.

In a Bash-compatible shell, replace LOGIN and PASS with your proxy-list credentials. The example uses pool.infatica.io:10000; use the port from the list you’re testing.

curl -v --proxy-http3 --http3-only \
  --proxy-header "Proxy-Authorization: Basic $(printf %s 'LOGIN:PASS' | base64 | tr -d '\r\n')" \
  -x 'https://pool.infatica.io:10000' \
  https://icanhazip.com/

The options control separate parts of the connection:

• --proxy-http3 uses HTTP/3 for the connection to the HTTPS proxy.
• --http3-only requires HTTP/3 for the destination request, with no fallback to an earlier HTTP version.
• --proxy-header supplies the authentication header to the proxy.

This example explicitly requests HTTP/3. Protocol selection in your application depends on that client’s capabilities and configuration.

3. Confirm the negotiated protocol

Successful output should include lines such as:

* CONNECT-UDP phase completed for HTTP proxy
...
* using HTTP/3
...
> GET / HTTP/3
...
< HTTP/3 200

The response body shows the exit IP observed by the test service. The HTTP/3 lines confirm the protocol used for the request. An IP address in the response alone does not establish that HTTP/3 was used.

If the test fails, start with the client build, proxy credentials, target support, and network permissions. Because the command uses --http3-only, it will fail rather than retry the destination request over HTTP/2 or HTTP/1.1.

Try it with a target you already use

Start with a small set of requests to an HTTP/3-enabled destination, confirm the protocol in your client’s logs, and compare the results with your existing workflow.

Use the product guides linked above for your proxy setup. If you need help, share your client version, selected proxy product, and redacted error output with Infatica support through your usual support channel.

Open the HTTP/3 setup guide.