Why does a requests.get(...) call hang

The following simple python script that uses requests.get to execute a GET request does not return on my computer:

import requestsprint(requests.get('https://api.openstreetmap.org/api/0.6/node/1894790125'))

However, I am able to get an "instant" response with the same url using curl.

Why is this?

Specifying a common user agent

Specifying a common user agent does not change anything:

import requestsprint(requests.get('https://api.openstreetmap.org/api/0.6/node/1894790125',    headers = { 'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36' }))

tcpdump

When trying to trace the connection with

 sudo tcpdump -v -i eno1 'host api.openstreetmap.org'

I get the following output

tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes08:17:22.463843 IP6 (flowlabel 0x69a8c, hlim 64, next-header TCP (6) payload length: 40) aaaa:bbbb:cccc:dddd:eeee:dddd:cccc:bbbb.aaaa4 > spike-06.openstreetmap.org.https: Flags [S], cksum 0xdb71 (incorrect -> 0xb5a5), seq 3910911789, win 64800, options [mss 1440,sackOK,TS val 1030348905 ecr 0,nop,wscale 7], length 008:17:23.482673 IP6 (flowlabel 0xd077e, hlim 64, next-header TCP (6) payload length: 40) aaaa:bbbb:cccc:dddd:eeee:dddd:cccc:bbbb.aaaa4 > spike-06.openstreetmap.org.https: Flags [S], cksum 0xdb71 (incorrect -> 0xb1aa), seq 3910911789, win 64800, options [mss 1440,sackOK,TS val 1030349924 ecr 0,nop,wscale 7], length 008:17:25.494643 IP6 (flowlabel 0x3cc5c, hlim 64, next-header TCP (6) payload length: 40) aaaa:bbbb:cccc:dddd:eeee:dddd:cccc:bbbb.aaaa4 > spike-06.openstreetmap.org.https: Flags [S], cksum 0xdb71 (incorrect -> 0xa9ce), seq 3910911789, win 64800, options [mss 1440,sackOK,TS val 1030351936 ecr 0,nop,wscale 7], length 008:17:29.687440 IP6 (flowlabel 0x7665b, hlim 64, next-header TCP (6) payload length: 40) aaaa:bbbb:cccc:dddd:eeee:dddd:cccc:bbbb.aaaa4 > spike-06.openstreetmap.org.https: Flags [S], cksum 0xdb71 (incorrect -> 0x996e), seq 3910911789, win 64800, options [mss 1440,sackOK,TS val 1030356128 ecr 0,nop,wscale 7], length 008:17:37.878687 IP6 (flowlabel 0xd5551, hlim 64, next-header TCP (6) payload length: 40) aaaa:bbbb:cccc:dddd:eeee:dddd:cccc:bbbb.aaaa4 > spike-06.openstreetmap.org.https: Flags [S], cksum 0xdb71 (incorrect -> 0x796e), seq 3910911789, win 64800, options [mss 1440,sackOK,TS val 1030364320 ecr 0,nop,wscale 7], length 008:17:54.010694 IP6 (flowlabel 0xbf2f2, hlim 64, next-header TCP (6) payload length: 40) aaaa:bbbb:cccc:dddd:eeee:dddd:cccc:bbbb.aaaa4 > spike-06.openstreetmap.org.https: Flags [S], cksum 0xdb71 (incorrect -> 0x3a6a), seq 3910911789, win 64800, options [mss 1440,sackOK,TS val 1030380452 ecr 0,nop,wscale 7], length 0^C6 packets captured28 packets received by filter3 packets dropped by kernel

Unfortunately, I am quite inexperienced interpreting such output, and I am not sure if the incorrect part in the output is an indication of what's going on.

Working in WSL

When executed in WSL on the same hardware, the request runs fine and the script prints <Response [200]>.