curl 8.22 Preview: Link-Local IPv6 Resolution Gets a Scope-ID Retry

curl's pending 8.22 release notes now list a resolver fix for link-local IPv6 addresses: the threaded asynchronous resolver can retry when a result is missing a scope identifier. The release remains under development and is scheduled for September 2, 2026, so production teams should treat this as a preview and test it before upgrading.

What changed

A link-local IPv6 address is valid only on a specific network interface. The address alone is not enough; the operating system also needs a scope identifier that tells it which interface should carry the traffic.

When a resolver returns a link-local address without that interface context, a connection attempt can fail even though the destination is reachable. The pending curl fix adds a retry path for this condition instead of accepting the incomplete result as final.

This is not a general IPv6 performance feature. It targets a narrow but operationally important resolver edge case.

Why proxy and data-collection teams should care

Link-local addresses are common around local gateways, containers, VPN adapters, service meshes and test networks. They may appear during proxy health checks, multi-interface routing tests or infrastructure automation.

A missing scope identifier can produce misleading symptoms:

• a proxy appears offline even though only interface selection failed;
• IPv4 succeeds while the intended IPv6 path silently breaks;
• retries move traffic to another route and hide the original fault;
• monitoring reports intermittent DNS or connection errors;
• container and host results differ because their interface indexes are different.

For teams operating regional proxy pools, this can distort availability metrics. A resolver-context failure should not be counted as proof that an IP, proxy endpoint or upstream service is unhealthy.

What the fix does not guarantee

The pending change does not make every link-local address reachable. The client still needs a valid interface, correct routing and access to the local network segment. It also does not replace application-level controls for timeouts, retries or proxy rotation.

The development notes may change before the final release. Teams should verify the behavior against the actual curl 8.22 build they plan to deploy.

A practical validation plan

1. Record the current baseline

Capture the curl version, operating system, resolver backend, active interfaces and whether the request runs on a host, virtual machine or container. Keep IPv4 and IPv6 results separate.

2. Test the direct path first

Confirm that a controlled link-local destination is reachable from the intended interface without a proxy. If the direct path fails, do not blame the proxy layer.

3. Test the proxy path independently

Use the same destination, timeout and interface conditions through the proxy. Record connection time, selected address family, exit code and whether a fallback route was used.

4. Compare missing and explicit scope behavior

Where your test environment permits it, compare a resolver result without interface context against an explicitly scoped link-local target. The goal is to distinguish resolver recovery from ordinary routing success.

5. Run the test inside each deployment boundary

Repeat on the host and inside containers or isolated network namespaces. Interface indexes are local to each environment, so a result that works on the host may not work in a container.

6. Keep rollback simple

Do not roll the pending build across an entire proxy fleet at once. Start with a small canary group, preserve the previous package and watch error distribution by address family and interface.

Monitoring signals to add

Track these fields together:

• curl version and resolver backend;
• destination address family;
• interface or network namespace;
• proxy route identifier;
• connection error and exit code;
• retry count;
• whether IPv4 fallback occurred;
• total connection time.

A drop in link-local IPv6 failures is useful only if latency, fallback traffic and proxy success rates remain stable.

Source note

Internal research source: curl project, pending release notes for the upcoming 8.22 release, reviewed August 20, 2026. The public article intentionally contains no external source link.

Compliance and safe use

Use proxy and network testing only on systems and data you are authorized to access. Respect target terms, rate limits, privacy obligations and regional laws. Do not use retries or proxy rotation to bypass access controls.

Related 98IP resources

• Test IPv6 proxy paths without confusing fallback with support
• Verify SOCKS5 remote DNS resolution across the full proxy path
• Review the pending curl 8.22 non-tunneling proxy hostname fix

FAQ

Is curl 8.22 already released?

No. The curl project lists September 2, 2026 as the planned release date. This article describes a pending development note, not a final production guarantee.

Does the retry apply to every IPv6 connection?

No. It concerns link-local IPv6 resolution when the result is missing the interface scope information needed to route the connection.

Should proxy operators upgrade immediately?

Test first. Use a canary deployment, compare IPv4 and IPv6 behavior, and keep rollback available until the final release is validated in your environment.