A versão incorreta do PHP é exibida durante a execução da VPN

Question

Eu tenho um problema estranho sobre o qual eu realmente gostaria de saber mais. Ontem eu estava implantando um novo site no meu servidor de hospedagem. No dia anterior, mudei de PHP 5.2.17 para PHP 5.4.10 no servidor. O estranho era que a versão ainda era relatada como 5.2.17 ? Eu pedi a um colega para ir ao site e ele obteve a versão correta. Finalmente, eu virei da minha VPN (não usado para este servidor específico) e instantaneamente eu pude ver o servidor executando a versão correta do PHP. Agora eu realmente gostaria de saber por que isso aconteceria? A única coisa que posso pensar é que isso deve ser algum tipo de problema de cache em conjunto com o túnel VPN em execução?

Se eu criar um novo arquivo via SSH na webroot, não posso acessar o arquivo através do meu navegador, em vez disso, recebo uma página 404. Se eu ligar ou reiniciar minha VPN, esse erro desaparece.

Estou usando o Juno Pulse como meu cliente VPN.

Outra coisa interessante que notei é que, depois que reiniciei o cliente VPN, a página relata a versão correta novamente.

    

Answer 1

Parece-me um problema provedor + dns - especificamente eu postulo que o provedor tem várias máquinas - possivelmente com armazenamento web compartilhado mas periodicamente sincronizado com armazenamento do sistema -, e usando / não usando uma VPN você mudou o roteamento para um diferente máquina - antes do PHP - foi atualizada.

Os sinais disso são: 1. Não é um cache. Renomeando o arquivo info.php descartou. 2. É um problema relacionado ao roteamento - a VPN monitora o roteamento. 3. Foi uma questão temporária.

    

Answer 2

Sem verificar a configuração subjacente, é difícil dizer exatamente qual foi o problema, porém, com base em algumas das informações que você forneceu, pois era improvável que o cache criasse o arquivo info2.php e tivesse o mesmo problema.

O que indica que você foi roteado para outro servidor ao usar a VPN. Seja por um balanceador de carga no seu provedor ou DNS (veja se há vários registros / round-robin). Não há caches em sua VPN que possam causar isso (que eu acho que é o que você está recebendo).

Existem várias configurações de balanceador de carga, mas uma configuração é baseada em um hash do IP, o que explicaria por que você estava sempre preso ao mesmo sistema (que ainda não tinha sincronizado suas alterações), mas roteado para outro quando acessando de outro IP. Veja o ip_hash do nginx para obter um exemplo de uma dessas configurações de balanceador. Especificamente,

The first three octets of the client IPv4 address, or the entire IPv6 address, are used as a hashing key. The method ensures that requests from the same client will always be passed to the same server except when this server is unavailable.

Quanto à opção DNS, verifique se o seu domínio faz roteamentos para vários registros A, talvez usando uma ferramenta como mxtoolbox , pois isso também pode Explique que está sendo roteado para outro sistema se nenhum LB real estiver no lugar.

Algo que nos vem à mente para uma situação semelhante a esta foi recentemente alterações no código, onde não foram mostradas a determinados pedidos. O problema era que o ENOM permitia o CNAME ao registro raiz que não é permitido por RFC1034 em sua interface. No entanto, o que realmente acontece é que eles simplesmente pesquisam os registros A do CNAME, que nesse caso era um AWS ELB e criaram 2 registros A para os dois IPs resolvidos pelo ELB e alguns meses depois, quando a AWS alterou um dos IPs do ELB O roteamento para isso não foi refletido, então algumas solicitações foram encaminhadas para o antigo ELB IP e, por sua vez, exibindo o antigo código em cache.