Why does opening a socket delay for a minute with IPv6 but not with IPv4?

On my Windows 10 desktop machine, I am running the following bit of Python (3.10.9) to make an HTTP POST request:

import jsonimport requestsresponse = requests.post(    url="https://foo.bar/baz",    headers={'Content-Type': "application/json",'Authorization': "bazz",    },    data=json.dumps({"key":"value"}))

When I ran the code in PyCharm, I found that the call to the post() method consistently stalls for about 63 seconds before returning. As this is an unreasonably long time to get a response from this API, I ran the same code in the same way on a different computer and found that the call returns almost immediately with a good response.

Having profiled the code in PyCharm, I can see that it's the call to Python socket.connect() method that causes the 63-seconds delay.

Following advice I've found online, I've disabled IPv6 on the Ethernet adapter that I use to access the internet:

Once I've done that, when I run the code, it returns immediately with no delay.

My question is - Why is this happening and how can I re-enable IPv6 on the Ethernet adapter and not experience the 63 second delay?

Additional observations:

• The https://foo.bar API application seems to have both IPv6 addressed and IPv4 addresses:

❯❯ nslookup foo.barServer:  vulcan.localAddress:  192.168.1.1Non-authoritative answer:Name:    foo.barAddresses:  2606:4700:20::****:****          2606:4700:20::****:****          2606:4700:20::****:****          172.67.***.***          104.26.***.***          104.26.***.***

• When enabled, the IPv6 feature is configured to have default values (as far as I can tell).

UPDATE : I can add that when I disable the Ethernet adapter and enable a wifi adapter that has IPv6 enabled (again with default properties), the delay disappears.

Pinging the domain with -6 does not work, I think because they've disabled ping on their end. However, nslookup -type=AAAA foo.bar yields a difference in the order in which the IPv6 addresses are listed.

Ethernet:

Addresses:  2606:4700:20::****:158          2606:4700:20::****:48c5          2606:4700:20::****:58          172.67.***.***          104.26.***.***          104.26.***.***

Wifi:

Addresses:  2606:4700:20::****:48c5          2606:4700:20::****:158          2606:4700:20::****:58          172.67.***.***          104.26.***.***          104.26.***.***

Is it possible that the first address for Ethernet is faulty and causes the delay? How can I prove this to the owner of the API? Or, can I manually control the order on my end?