Why do WinHTTP and TNetHTTPClient timeout (error 12002) on one Wi-Fi network but succeed on others?

I'm developing a Delphi application to download files using both WinHTTP (via direct API calls) and TNetHTTPClient. Everything works fine on most networks, but on one specific open Wi-Fi network, both approaches fail consistently with a timeout.

Specifically:

• WinHttpSendRequest returns error

  12002 (ERROR_WINHTTP_TIMEOUT)

• TNetHTTPClient.Get() also raises a timeout exception
• However:
  • Indy (TIdHTTP) downloads the file successfully on the same network,
  • and Chrome or IDM can also download the file immediately.

The target URL is hosted on Cloudflare R2, with no enforced bot protection, and works fine from other networks.

What I’ve already tried:

• mimicked common browser headers like User-Agent, Accept, etc.
• ensured SNI and TLS version compatibility
• tried both WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY and WINHTTP_ACCESS_TYPE_NO_PROXY, but the result is the same — still getting timeout (error 12002 in WinHTTP).
• I also inspected the traffic using Wireshark. When the download fails (using WinHTTP or TNetHTTPClient), I do not see any DNS resolution phase in the capture. However, when switching to another network or using Indy or web browsers (which successfully download the file), I can clearly observe the DNS resolution phase.

Question: Why would WinHTTP and TNetHTTPClient time out on one specific network, while Indy and browsers succeed? Is there any internal behavior in WinHTTP that makes it more sensitive to certain network environments (e.g., open Wi-Fi, captive portals, DNS behavior, SNI, etc.)?

Update:

I confirmed that WinInet also experiences the same issue on this network. The problem was resolved by enabling the WINHTTP_OPTION_IPV6_FAST_FALLBACK option in WinHTTP, which allowed the client to quickly fall back to IPv4 when IPv6 was slow or unresponsive.

The problem was resolved by enabling the WINHTTP_OPTION_IPV6_FAST_FALLBACK option in WinHTTP, which allowed the client to quickly fall back to IPv4 when IPv6 was slow or unresponsive.