Pregunta sobre W3 Total Cache de Wordpress:

502 Bad Gateway en scripts, imágenes, etc. de CDN triturados

Un usuario preguntó 👇

Hace unos días tuve otro plugin que solucionaba algunos problemas de soporte en mi servidor. Se hizo poco más que deshabilitar / habilitar plugins aquí y allá, pero en ese momento notamos que también había 502 errores de puerta de enlace incorrecta en la consola del navegador, y la mayoría de los estilos / imágenes habían desaparecido.

Mi entorno VPS es con Runcloud, usando Cloudfront para generar iniciativas para CDN y Let’s Encrypt SSL.

Reduje el problema al componente CDN en W3TC. No se realizaron cambios en el plugin ni en el lado del servidor / AWS. Pero cada vez que habilito la CDN obtenemos la buena página de error de Cloudfront:

502 ERROR
The request could not be satisfied.
CloudFront wasn't able to connect to the origin. 
For more information on how to troubleshoot this error, please refer to the CloudFront documentation (https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html). 
Generated by cloudfront (CloudFront)

Restauré una copia de seguridad de la base de datos unos días antes de que me diera cuenta del problema y no hay cambios. Regresé a la copia de seguridad más actual debido a otros cambios realizados desde entonces. Entonces, esto controla las opciones del plugin, y dado que borré todas las cachés y los CF no válidos para la carpeta de caché, supongo que esto también debería eliminar esto.

Los verificadores SSL en línea muestran que el sitio es bueno, el certificado no parece haber sido renovado recientemente. He desactivado el caché en CF, he probado la conectividad de CF desde las opciones de CDN, he reiniciado y recargado nginx, he reiniciado Redis, pero nada funciona.

¿Hay alguna otra idea que alguien pueda sugerir que pueda haber pasado por alto? ¡Gracias!

Lanzador de hilos

(@ tf5_bassist)

Hace 2 años, 10 meses

Tengo la pregunta. Runcloud llevó a cabo un proceso de reconstrucción de aplicaciones en todo el sistema que impactó las aplicaciones implementadas para todos los clientes. Esto significó deshabilitar TLS 1.0. Por alguna extraña razón, mi base de distribución de AWS CF estaba configurada en SSLv3 / TLS 1.0 y TLS 1.1 y 1.2 estaban deshabilitados. wtf. Al habilitar TLS 1.1 y 1.2, al eliminar 1.0 y SSLv3 en la configuración predeterminada, el problema se resolvió.

Runcloud no solo le dijo a nadie que la reconstrucción estaba deshabilitando TLS 1.0, sino que no le dijo a nadie que la reconstrucción estaba ocurriendo. Así que ahí está. Hurra por la excelente comunicación con los clientes. : /

(@gidomanders)

Hace 2 años, 10 meses

Runcloud no es el único, CloudFlare también cambió su configuración de SSL para incluir TLS <1.3 para clientes de pago, sin decírselo a nadie. Esto ha provocado que los sitios web fallen en navegadores y sistemas operativos más antiguos que no son compatibles con TLS 1.3.

Lanzador de hilos

(@ tf5_bassist)

Hace 2 años, 10 meses

…. TLS solo 1.3? La mayoría de los navegadores realmente no admiten eso … jajaja. Eso es bastante tonto jaja.

https://caniuse.com/#feat=tls1-3

¿Solucionó tu problema??

0 / 0

Deja una respuesta 0

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *