Você tem um problema de MTU.
Testei wget -O /dev/null https://www.ekasparova.eu enquanto observava o tráfego com tcpdump . Isso é o que eu vi:
19:56:57.048361 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [S], seq 262121609, win 28800, options [mss 1440,sackOK,TS val 298423713 ecr 0,nop,wscale 7], length 0
19:56:57.087457 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [S.], seq 2396216876, ack 262121610, win 28560, options [mss 1440,sackOK,TS val 82836580 ecr 298423713,nop,wscale 7], length 0
19:56:57.087490 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 0
19:56:57.087692 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [P.], seq 1:322, ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 321
19:56:57.126190 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [.], ack 322, win 232, options [nop,nop,TS val 82836590 ecr 298423723], length 0
19:56:57.141224 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [P.], seq 2857:3678, ack 322, win 232, options [nop,nop,TS val 82836594 ecr 298423723], length 821
19:56:57.141301 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 248, options [nop,nop,TS val 298423736 ecr 82836590,nop,nop,sack 1 {2857:3678}], length 0
Os primeiros 3 pacotes são o aperto de mão. Ambas as extremidades anunciam mss 1440 , o que significa que são capazes de receber pacotes com 1440 bytes de carga TCP, contando também cabeçalhos e totalizando 1500 bytes de tráfego IP, o que é comumente suportado pela Ethernet.
Os próximos 2 pacotes são o cliente hello e o reconhecimento foi recebido pelo servidor.
Os últimos 2 pacotes são onde as coisas ficam interessantes. Por padrão, tcpdump mostra números de seqüência relativos, que neste caso tornam a captura mais fácil de ler. No pacote do servidor esta é a parte interessante seq 2857:3678 . Vemos um salto de 1 para 2857 , o que significa que há um intervalo de 2856 bytes que o cliente ainda não recebeu. 2856 bytes correspondem a dois pacotes de 1428 bytes. A diferença entre 1440 e 1428 é o tamanho de uma opção de registro de data e hora.
Assim, o servidor enviou o servidor hello dividido em 3 pacotes. Mas os dois primeiros eram grandes demais para a rede e não foram entregues ao cliente.
No pacote final do cliente para o servidor, vemos este sack 1 {2857:3678} . Esta é uma confirmação seletiva enviada pelo cliente informando ao servidor que existe uma lacuna nos dados recebidos até agora.
Provavelmente, o servidor continua enviando os dois pacotes perdidos repetidamente. Mas não importa quantas vezes ele retransmite os mesmos dois pacotes, eles permanecem grandes demais para a rede. E, provavelmente, um roteador no caminho envia uma mensagem de erro para o servidor informando que os pacotes são muito grandes e precisam ser retransmitidos em pacotes menores.
Se o servidor recebesse essas mensagens de erro, ele retransmitiria os pacotes menores conforme necessário. E se lembraria do PMTU menor, de modo que, em solicitações subsequentes, ele não precisa repetir essa etapa de descoberta.
Uma possível explicação para tudo isso é que você tem um firewall mal configurado, o qual elimina todas as mensagens de erro informando ao seu servidor que ele precisa retransmitir os dados em pacotes menores.