Página de prueba:https://www.beobank.be/nl/Home.aspx
Este es el resultado usando wget (o un navegador real):
# time wget https://www.beobank.be/nl/Home.aspx -O /dev/null
--2015-01-26 12:05:46-- https://www.beobank.be/nl/Home.aspx
Resolving www.beobank.be (www.beobank.be)... 62.213.211.94
Connecting to www.beobank.be (www.beobank.be)|62.213.211.94|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 33444 (33K) [text/html]
Saving to: `/dev/null'
100%[======================================================================================================================================================>] 33,444 --.-K/s in 0.05s
2015-01-26 12:05:47 (670 KB/s) - `/dev/null' saved [33444/33444]
real 0m1.327s
user 0m1.072s
sys 0m0.060s
Y este es el resultado usando curl:
# time curl https://www.beobank.be/nl/Home.aspx &>/dev/null
real 1m0.741s
user 0m0.012s
sys 0m0.012s
OS X no parece tener ese problema (cURL es rápido). Hasta donde puedo probar, esto solo sucede en Linux. Todas las máquinas (he probado varias) están basadas en Debian (ejecutan el software más reciente) y tienen IPv6 habilitado, pero ese sitio web no tiene registros de IPv6. Todas las pruebas duran poco más de 1 minuto, ¿lo que parece como si algo se estuviera agotando?
La solicitud a Google es rápida:
# time curl https://www.google.com/ &>/dev/null
real 0m0.550s
user 0m0.020s
sys 0m0.012s
Agregar el parámetro "-4" a cURL para forzar IPv4 no parece cambiar nada.
¿Qué podría ser la causa?
Respuesta1
Úselo tcpdumpen el puerto 53 UDP para examinar cómo funciona la conexión cuando busca un sitio mediante CURL y wget en la segunda pestaña.
La razón habitual es causada por un conflicto entre IPv4/IPv6 que se puede solucionar deshabilitando IPv6 en sysctl o agregando la opción de reapertura de solicitud única a /etc/resolv.conf.