It looks like we have two threads, one sending from port 49290 and the other from 49292. The second one follows the first initially by 250ms, then 213ms for a while, and finally by only some microseconds. I guess this confuses the poor server.
Do you have a DNS cache installed like dnsmasq? If so, it’s possible a stale IP address has been cached. Restarting the service should fix it. Though if your PC has rebooted since this problem started, I doubt it is the cause.
It could be that one is for HTTP/1.1 and the other one is for HTTP/2. Did you use a browser, wget, or curl? You could try nc -v duckduckgo.com 443 (you need the openbsd-netcat package).
I used Palemoon browser, a FireFox clone.
Good point. With nc I only have one thread, and the timeouts are as expected: 1, 2, 4, 8, 17, 32 seconds.
I’m guessing I don’t get the double-thread syndrome with lite.duckduckgo.com because the SYN,ACK comes within 27 milliseconds.
That still leaves the question of why duckduckgo.com doesn’t respond to the SYN. Can we say for sure that the SYN,ACK response is not being tossed on my machine?
I’m not sure… you said it works on a different computer in the same house. Can you test it again? Wireshark should show all packets. Maybe it’s the firewall in the router?
Yup, it still works in Palemoon on my Windoze7 machine. nc also works on my FreeBSD machine. I looked at my router, and didn’t see anything untoward such as a filter for duckduckgo.com.
In that case please try the live session of any linux distribution and see if it works there. And then you could possibly connect that machine to your FreeBSD machine, configure static IP, routing to see (with tcpdump) if the packets are actually leaving your machine.