Tengo un problema extraño del que realmente me gustaría saber más. Ayer estaba implementando un nuevo sitio en mi servidor de hosting. El día anterior cambié de PHP 5.2.17a PHP 5.4.10en el servidor. Lo extraño fue que todavía se informó que la versión era 5.2.17? Le pedí a un compañero de trabajo que fuera al sitio y obtuvo la versión correcta. Finalmente, apagué mi VPN (no utilizada para este servidor específico) e instantáneamente pude ver que el servidor ejecutaba la versión PHP correcta. Ahora realmente me gustaría saber por qué sucedió esto. Lo único que se me ocurre es que debe ser algún tipo de problema de almacenamiento en caché junto con el túnel VPN en ejecución.
Si creo un nuevo archivo a través de SSH en webroot, no puedo acceder al archivo a través de mi navegador, sino que recibo una página 404. Si apago o reinicio mi VPN, este error desaparece.
Estoy usandoPulso de Junocomo mi cliente VPN.
Otra cosa interesante que noté es que después de reiniciar el cliente VPN, la página vuelve a informar la versión correcta.
Respuesta1
Me suena como un problema de proveedor + DNS; específicamente, postulo que el proveedor tiene varias máquinas, posiblemente con almacenamiento web compartido pero con almacenamiento del sistema sincronizado periódicamente, y al usar o no usar una VPN, cambió la ruta a una máquina diferente, antes. PHP - fue actualizado.
Los signos de esto son: 1. No es un caché. Cambiar el nombre del archivo info.php lo descartó. 2. Es un problema relacionado con el enrutamiento: la VPN cambia el enrutamiento. 3. Fue una cuestión temporal.
Respuesta2
Sin verificar la configuración subyacente, es difícil decir exactamente cuál fue el problema; sin embargo, según parte de la información que proporcionó, era poco probable que se tratara de un caché dado que creó el archivo info2.php y tuvo el mismo problema.
Lo que indicaría dónde se dirige a otro servidor cuando se utiliza la VPN. Ya sea mediante un equilibrador de carga en su proveedor o DNS (ver si hay varios registros/round-robin). No hay ningún caché en su VPN que pueda causar esto (que creo que es a lo que se refiere).
Hay muchas configuraciones de balanceador de carga diferentes, pero una de esas configuraciones se basa en un hash de la IP, lo que explicaría por qué siempre estaba atascado en el mismo sistema (que posiblemente aún no había sincronizado sus cambios) pero se le enrutaba a otro cuando accedía desde otro. PI. Ver nginxip_hashpara ver un ejemplo de una de esas configuraciones de equilibrador. Específicamente,
Los primeros tres octetos de la dirección IPv4 del cliente, o la dirección IPv6 completa, se utilizan como clave hash. El método garantiza que las solicitudes del mismo cliente siempre se pasarán al mismo servidor, excepto cuando este servidor no esté disponible.
En cuanto a la opción DNS, verifique si su dominio se enruta a múltiples registros A, tal vez usando una herramienta comocaja de herramientas mxya que esto también podría explicar la ruta a otro sistema si no existe un LB real.
Algo que me viene a la mente para una situación similar a esta fueron los cambios de código recientes que no se muestran en ciertas solicitudes. El problema fue que ENOM permitió el CNAME al registro raíz, lo cual no está permitido según RFC1034 en su interfaz. Sin embargo, lo que realmente sucede es que simplemente buscan los registros A del CNAME, que en este caso era un ELB de AWS y crearon 2 registros A para las dos IP que resolvió el ELB y luego, unos meses más tarde, cuando AWS cambió una de las IP, el ELB. El enrutamiento a esto no se reflejó, por lo que algunas solicitudes se enrutaron a la IP ELB anterior y, a su vez, mostraron el código almacenado en caché anterior.