net err_spdy_protocol_error err_spdy_ping_failed nginx spdy

nginx - err_spdy_ping_failed - net::err_spdy_protocol_error laravel



¿Qué significa ERR_SPDY_PROTOCOL_ERROR en nginx? (12)

Al igual que con el OP, este fue un problema intermitente para mí y solo sucedió en solicitudes AJAX> 2mb de tamaño.

El problema comenzó a ocurrir después de que nos mudáramos de un ELB clásico de AWS a ALB.

Resolví esto mediante la desinstalación de Chrome, eliminando mi perfil de usuario (en mac, elimine el contenido de ~/Library/Application Support/Google/Chrome ), y luego reinstalé.

Yo y algunos de mis colegas obtuvimos el error net::ERR_SPDY_PROTOCOL_ERROR .

Utilizamos ngnix versión 1.8.0. El error no es estable (difícil de replicar), y el registro de errores de Ngnix no tiene este error.

¿Cómo aconsejarías que atrapemos y resolvamos esto?

Como puede ver en las otras respuestas, muchas cosas diferentes pueden causar esto. Para mí, tenía un encabezado con formato incorrecto que otros navegadores simplemente ignoraban (un extra : . La única respuesta para esto es una sugerencia de depuración, verifique los eventos internos de Chrome en la red al cargar la página rota: chrome: // net-internals / # events

Para mí, sabía que era un problema de encabezado cuando vi esta línea

t=65422 [st=53] HTTP_TRANSACTION_READ_HEADERS [dt=4] --> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR)

Después de eliminar el extra : de la respuesta del encabezado, HTTP / 2 comenzó a trabajar en Chrome. Sugiero obtener una respuesta sin formato de su servidor y hacer una inspección muy cercana para asegurarse de que no haya errores de sintaxis.

En mi caso, he resuelto esto al aumentar el tamaño del trozo:

http2_chunk_size 300k;

Encontré esta pregunta al intentar encontrar ayuda para el problema que enfrentaba con ERR_SPDY_PROTOCOL_ERROR en Chrome. Pensé que esto podría beneficiar a otros.

Nuestra situación / solución: utilizamos un equilibrador de carga de aplicaciones de AWS conectado a instancias de EC2 . Uno de los scripts que ejecutamos en solicitudes de proxies EC2 desde el navegador del cliente. Recientemente actualizamos la secuencia de comandos, sin cambios relevantes, y notamos que las solicitudes de Chrome y Safari a la secuencia de comandos proxy comenzaron a fallar. Chrome mostró el error ERR_SPDY_PROTOCOL_ERROR y, cuando lo ERR_SPDY_PROTOCOL_ERROR , pudimos ver que esta solicitud estaba usando HTTP / 2. Las solicitudes de Firefox siguieron funcionando bien.

Nuestra solución: desactivamos el soporte HTTP / 2 en ALB. Resolvió de inmediato el problema.

Comando AWS CLI:

aws elbv2 modify-load-balancer-attributes --load-balancer-arn <your_load_balancer_arn> --attributes Key=routing.http2.enabled,Value=false

Este es un problema conocido que existe entre los navegadores Chromium y ciertos programas antivirus como AVG y Avast, especialmente cuando se usa una conexión SSL. No se puede resolver en el extremo del usuario. Depende de los desarrolladores de sitios web evitar que ocurra este problema.

La documentación para desarrolladores web está aquí: http://dev.chromium.org/spdy/spdy-best-practices

Aquí hay algunos consejos útiles para los desarrolladores que no se mencionan específicamente en ese artículo:

  • Tenga mucho cuidado al usar encabezados y redirecciones, especialmente 301 y 302
  • Mantenga todos sus archivos incluidos en o bajo el mismo directorio que su acceso de nombre de dominio, no por encima del directorio en el servidor. Antivirus no puede acceder a ellos allí. Para proteger sus archivos de inclusión, cree un archivo .htaccess en el directorio de inclusión y simplemente escriba una línea: Denegar desde todos
  • Habilitar la compresión Gzip. Si usa cPanel, esto se puede hacer en la configuración de optimización de su sitio web.
  • Mantenga su archivo .htaccess simple. Cambiar las salidas del servidor para crear diferentes extensiones de archivo y redirigir a los clientes de los usuarios creará conflictos innecesarios.

En mi experiencia, este problema solo parece ocurrir cuando se usan sesiones para almacenar y pasar datos. Las cookies, Get y Post parecen no verse afectadas.

Espero que esto ayude.

He visto este error recientemente después de una actualización del servidor.

Lo estaba viendo para todos los usuarios en Chrome, pero solo de manera intermitente.

Pude resolverlo para todos los usuarios al hacer que usaran la función de actualización de Chrome ''Empty Cache and Hard Reload'' para el sitio. (F12 para las herramientas de Chrome, haga clic derecho en el botón de actualización)

Sospecho que está relacionado con algo guardado en caché sobre los certificados SSL que se están utilizando.

Para mí, fue la configuración de Nginx la que no permitió el método OPCIONES. Solo había incluido en la lista blanca GET | PUT | POST | DELETE, así que cuando Chrome intentó enviar el método de OPCIONES, porque Dios sabe por qué **, el error se reprodujo.

Abra Firefox y repita la solicitud, luego mire al inspector de la red para verificar si se están enviando las solicitudes de OPCIONES.

** probablemente para verificar las opciones de X-Frame o la verificación HSTS.

Parece que hay muchas causas potenciales. Uno que golpeé hoy fue la línea de cabecera

add_header X-Frame-Options: deny;

El cromo actual hará ruido en eso con ssl + http2 por alguna razón. Otros encabezados X-Frame no parecen ser un problema.

Tenía un sitio haciendo eso, resultó ser alguien que olvidó poner "Ubicación:" en un redireccionamiento de PHP en la primera línea de index.php, invalidando el encabezado. Al parecer, solo a Chrome le importaba, el resto de los navegadores todavía lo cargaban bien.

Tuve el mismo problema, verifique si tiene suficiente espacio en la partición / HDD de Nginx, agregamos algo y funcionó para nosotros.

Verifique la ubicación de la ruta de la memoria caché del proxy: verifique que exista, tenga espacio y que los permisos y el propietario permitan que el proceso nginx escriba en la ruta.

por ejemplo, nginx.conf (fragmento de código)

proxy_cache_path /proxy_cache levels=1:2 keys_zone=danger_zone:10m inactive=60m;

... luego verifique que la ruta /proxy_cache sea ​​propiedad de nginx y se /proxy_cache escribir sobre ella.

TL; DR : si está almacenando activos en caché, verifique el espacio de la unidad en su servidor nginx.

Nuestro escenario

No estoy seguro de dónde publicar mi respuesta a esta pregunta, ya que podría ser un caso de ventaja al obtener el ERR_SPDY_PROTOCOL_ERROR en Chrome (y el error equivalente de "falla al cargar el recurso" en Firefox). Pero este post me ayudó a acotar al culpable. No era encabezados, gzip, redirecciones ni adblock / ublock.

Tenemos 2 aplicaciones web desplegadas desde la máquina, y ambas funcionaban perfectamente bien. Recientemente, implementamos una de las aplicaciones con cambios en los activos en caché. Una vez que se completó la implementación, inmediatamente obtuvimos el ERR_SPDY_PROTOCOL_ERROR de Chrome. Curiosamente, estaba recibiendo un HTTP 200 y, si navegaba directamente al activo, Chrome lo representaría. Sin embargo, cargar el activo en una página podría hacer que falle.

De manera interesante, la otra aplicación web estaba perfectamente bien. Al investigar las redes internas en Chrome, descubrimos que el servidor estaba cerrando la conexión. Después de varias horas, determinamos que era porque nuestro servidor nginx había agotado el espacio en el disco. No sé por qué eso causaría que los activos se carguen correctamente cuando navegas hacia ellos directamente, pero fallan cuando cargas una página, pero despejar el espacio al instante solucionó el problema.