curl 8.22 Fixes IPv6 Targets Through Non-Tunneling HTTP Proxies

curl 8.22.0, released September 2, 2026, fixes a failure affecting HTTP requests to IPv6 literal targets through a non-tunneling proxy. The curl project summarizes it as a correction to non-tunneling proxy hostname use. The underlying report showed a request failing with CURLE_OUT_OF_MEMORY even though the machine was not actually out of memory.

The reported path connected successfully to the proxy, then failed while curl constructed the proxied request URL. The internal IPv6 hostname lacked the brackets required when represented as a URL host, so the URL-setting operation failed and the surrounding path returned the misleading memory error. curl 8.22 corrects the hostname selection used for this forward-proxy request.

This is relevant to data collection, market research, and availability checks that access IPv6 endpoints through HTTP proxies without CONNECT. It is a narrowly defined client fix, not evidence of a general proxy outage or memory-pressure incident.

Which request shape matters

Prioritize regression testing when all of these are true:

• the target is an IPv6 literal rather than a DNS hostname;
• the client uses an HTTP forward proxy;
• the request is plain HTTP and is not tunneled with CONNECT;
• curl or libcurl constructs absolute-form request targets for the proxy;
• the application treats CURLE_OUT_OF_MEMORY as a fatal resource alert.

HTTPS proxying normally introduces a tunnel boundary and follows a different request path. IPv6 hostnames resolved from DNS are also distinct from a literal address written directly in the URL. Keep these cases separate.

Why the error could mislead operations

An out-of-memory label can trigger worker restarts, autoscaling, heap investigations, or circuit breakers. In the reported case, the proxy connection had already been established and the failure came from URL host formatting, not exhausted memory.

After an upgrade, do not merely check that the error string disappeared. Verify that the proxy receives a syntactically correct request, the intended IPv6 authority remains intact, and the final response comes from the expected controlled endpoint.

For related IPv6 retry behavior, see the curl IPv6 scope retry update. To separate address changes from session policy, use the residential proxy session stickiness test.

Build a controlled regression matrix

Use a forward proxy and endpoints your organization owns or is authorized to test. Prepare four targets:

1. an IPv4 literal over plain HTTP;
2. an IPv6 literal over plain HTTP;
3. a DNS hostname with both address families where available;
4. an HTTPS target through the normal tunnel path as a separate control.

Run each case direct and through the approved proxy. Keep proxy credentials, headers, timeouts, and response checks constant. Use a small deterministic response and low request volume.

Capture the request stages

Record non-secret evidence for each case:

• curl and libcurl runtime version;
• input target class: IPv4 literal, IPv6 literal, or hostname;
• direct, forward-proxy, or CONNECT route;
• proxy DNS and connection result;
• whether the proxy TCP connection was established;
• serialized request-target class and authority validation;
• client error code and stage;
• HTTP status and content validation;
• new or reused connection decision.

Redact proxy passwords, authorization headers, cookies, tokens, customer targets, and payload data. Do not publish raw traces containing credentials.

Expected behavior on curl 8.22

For a valid controlled IPv6 literal request through a non-tunneling HTTP proxy:

• the proxy connection should complete;
• the IPv6 authority should remain valid in the serialized URL form;
• the client should not return the misleading memory error from this path;
• the proxy should receive the intended request;
• response status and body should pass the same validation as the direct control.

Invalid URLs must still fail. The fix should not make malformed addresses acceptable or bypass proxy, TLS, or hostname policies.

Roll out without hiding the signal

Confirm the actual libcurl loaded by the serving process, especially in containers, static binaries, and language bindings. Upgrade to curl 8.22.0 or a vendor build that documents the relevant backport.

Restart or drain long-lived workers according to change policy. Run the regression with fresh connections first, then with normal pooling. Compare error codes by request stage rather than collapsing every failure into “proxy error.”

Monitor IPv6-literal success rate, forward-proxy connection success, URL-construction failures, unexpected memory alerts, retry amplification, and validated responses. Avoid rotating exits until the fixed request path has been proven on one stable route.

Acceptance checklist

• [ ] The serving process reports curl/libcurl 8.22.0 or a documented patched build.
• [ ] IPv4 literals, IPv6 literals, and DNS hostnames are separate cases.
• [ ] Forward proxy and CONNECT modes are labeled separately.
• [ ] The proxy connection stage is visible.
• [ ] The IPv6 authority remains syntactically valid.
• [ ] The specific misleading memory error is absent on the fixed path.
• [ ] Final status and response content are validated.
• [ ] Fresh and reused connections are compared.
• [ ] Retries and exit rotation do not hide the first failure.
• [ ] Logs contain no credentials or production payloads.

FAQ

Was curl really running out of memory?

Not in the reported reproduction. The error was returned after an IPv6 host representation failed during proxied request construction.

Does this affect every IPv6 request?

No. The reported case concerns an IPv6 literal target through a non-tunneling HTTP proxy. DNS hostnames, direct connections, and CONNECT tunnels are separate paths.

Should applications ignore out-of-memory errors now?

No. Real resource failures remain serious. Upgrade and classify errors by stage; do not globally suppress the code because one fixed path used it misleadingly.

Is proxy rotation a workaround?

It does not correct client-side URL construction. Test one stable authorized proxy route, upgrade the client, and verify the serialized request and response.

Source and responsible-use note

Internal research basis: curl project, curl 8.22.0 release announcement, published September 2, 2026; curl project issue “Proxied connections to IPv6 hostnames fail with CURLE_OUT_OF_MEMORY,” opened July 23, 2026. External source URLs are stored only in the internal operations record; this public article contains no external links.

Test only proxies, IPv6 endpoints, and networks you own or are authorized to assess. Respect provider limits, privacy obligations, service terms, and organizational change procedures.