Problema de red muy extraño: sitios específicos que no se cargan


8

En primer lugar, me disculpo si publiqué en el intercambio incorrecto, realmente no estaba seguro de dónde encaja esta pregunta.

Durante bastante tiempo he tenido este problema muy extraño con la conexión a Internet de mi casa, que definitivamente es culpa de mi enrutador o de mi ISP, pero mi ISP está siendo bastante impotente para depurarlo.

En su mayor parte, mi conexión funciona muy bien, sin tiempo de inactividad y constantemente obtengo casi el 100% de la velocidad por la que estoy pagando.

Sin embargo, hay un problema específico: algunos sitios web tienen este comportamiento muy extraño en el que tardarán mucho tiempo en cargarse. Ejemplos de dichos sitios web son en.wikipedia.org, www.canadapost.ca y www.theweathernetwork.com. Con estos sitios web, cada vez que intento cargar una página, al principio, nada se cargará en absoluto, y la barra de estado en Chrome leerá "Estableciendo una conexión segura ..." durante mucho tiempo, y finalmente me dará un " "No se puede acceder a este sitio" error. Si vuelvo a cargar e intento de nuevo, después de varias veces, eventualmente el sitio se cargará, y una vez que se cargue ese sitio web, puedo navegar libremente por ese sitio web sin problemas durante aproximadamente 15 minutos, entonces el problema volverá.

No es un problema con mi firewall o la configuración de PC. Ya he intentado numerosas cosas para descubrir cuál es el problema y he determinado que tiene que ser mi módem-enrutador o mi conexión a Internet, porque sucede con todos los dispositivos conectados a mi red (computadora de escritorio, computadora portátil, teléfono inteligente, etc.) y con mi teléfono inteligente, cuando cambio a datos móviles, el problema desaparece.

He presentado un ticket de soporte con mi ISP y me han guiado a través de todos los pasos obvios (restablecimiento de fábrica del módem, etc.) y ahora no están siendo tan útiles.

Una cosa que he hecho para probar es ejecutar comandos curl para los sitios web que tienen este problema y he notado algo; con todos los sitios web que tienen este problema, "curl -v [url]" devuelve un HTTP 301 en lugar de un 200.

¿Alguien tiene alguna idea de qué demonios está causando esto para que pueda señalar a los técnicos de mi ISP en la dirección correcta?

EDITAR: Se señaló que no estaba incluyendo https en los comandos de curl, lo que provocó el regreso del 301. Pero ahora que estoy incluyendo https, noté algo interesante:

Cuando ejecuto curl -v contra un sitio https que no es parte del problema (como Facebook), termino con una salida normal ... pero para un sitio web que es así, se ve así:

$ curl -v https://www.canadapost.ca
* STATE: INIT => CONNECT handle 0x600057810; line 1413 (connection #-5000)
* Rebuilt URL to: https://www.canadapost.ca/
* Added connection 0. The cache now contains 1 members
*   Trying 2600:140a:0:18a::1dc5...
* TCP_NODELAY set
* STATE: CONNECT => WAITCONNECT handle 0x600057810; line 1466 (connection #0)
*   Trying 23.34.200.189...
* TCP_NODELAY set
* Connected to www.canadapost.ca (2600:140a:0:18a::1dc5) port 443 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x600057810; line 1583 (connection #0)
* Marked for [keep alive]: HTTP default
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x600057810; line 1597 (connection #0)

Luego cuelga allí, durante mucho tiempo, y finalmente continúa y termina con:

* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=CA; ST=Ontario; L=OTTAWA; O=Canada Post Corporation; OU=Akamai SAN SSL OV; CN=www.canadapost.ca
*  start date: Jan 13 00:00:00 2017 GMT
*  expire date: Jan 13 23:59:59 2018 GMT
*  subjectAltName: host "www.canadapost.ca" matched cert's "www.canadapost.ca"
*  issuer: C=US; O=GeoTrust Inc.; CN=GeoTrust SSL CA - G3
*  SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x600057810; line 1618 (connection #0)
> GET / HTTP/1.1
> Host: www.canadapost.ca
> User-Agent: curl/7.54.0
> Accept: */*
>
* STATE: DO => DO_DONE handle 0x600057810; line 1680 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x600057810; line 1807 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x600057810; line 1817 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 301 Moved Permanently
* Server AkamaiGHost is not blacklisted
< Server: AkamaiGHost
< Content-Length: 0
< Location: https://www.canadapost.ca/web/en/home.page
< Date: Mon, 22 May 2017 22:01:55 GMT
< Connection: keep-alive
< Strict-Transport-Security: max-age=31536000
<
* STATE: PERFORM => DONE handle 0x600057810; line 1991 (connection #0)
* multi_done
* Connection #0 to host www.canadapost.ca left intact
* Expire cleared

Parece que podría ser un problema de IPv6. ¿Qué obtienes cuando visitas
Moshe Katz

Además, ¿qué sucede si deshabilita IPv6 en su computadora o en su enrutador (pruebe cualquiera de los dos)?
Moshe Katz

¿En qué estado estás? Estamos viendo el mismo comportamiento y todos los sitios web, incluido el suyo, están alojados en Akamai.
Chad

@MosheKatz Lo intentaré cuando llegue a casa esta noche.
user1072692

@Chad Ontario, Canadá
usuario1072692

Respuestas:


4

Terminó siendo causado por IPv6. Lo deshabilité en mi enrutador y lo configuré solo en IPv4 y el problema ya no existe.


2

Estos tres sitios parecen ser solo HTTPS. Si está comenzando qué http://direcciones, estos sitios informan a su navegador que se han mudado permanentemente httpscon los mensajes 301. Esto será parte del mensaje 301. Es posible que obtenga redireccionamientos adicionales que agreguen una ruta para la página predeterminada. Las redirecciones 301 son probablemente un arenque rojo.

Largas demoras como esta son comunes si tiene problemas de conectividad de DNS. Sin embargo, esperaría que eso ocurra en el primer intento.

Todos estos sitios son compatibles con IPv6. Si parece que tiene la capacidad de IPv6, es probable que Chrome intente usar IPv6 en lugar de iPv4 para conectarse. Negociar HTTPS puede involucrar varias conexiones a diferentes servidores. Si alguno de estos está bloqueado o caído, puede causar demoras.

Puede ser útil usar las Herramientas para desarrolladores de Chome ( CtrlShifti. Seleccione la pestaña Red que le mostrará los tiempos de carga para los componentes de la página. Desplácese sobre la primera conexión lenta para obtener detalles sobre los tiempos.


1
Gracias por señalar el https que causa el 301, se olvidó por completo de eso. Ejecuté curl nuevamente usando https, y noté algo interesante ... Los sitios https que no tienen este problema (como Facebook) se cargan bien ... "curl facebook.com " funciona bien. Pero con los sitios web que tienen este problema, la retroalimentación de rizo se ve muy diferente. Edité mi publicación para mostrarla
usuario1072692
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.