Tenho um problema estranho sobre o qual realmente gostaria de saber mais. Ontem eu estava implantando um novo site no meu servidor de hospedagem. Um dia antes de mudar de PHP 5.2.17para PHP 5.4.10no servidor. O estranho é que a versão ainda era considerada 5.2.17? Pedi a um colega de trabalho que fosse ao site e ele conseguiu a versão correta. Finalmente, desliguei minha VPN (não usada para este servidor específico) e instantaneamente pude ver o servidor executando a versão correta do PHP. Agora eu realmente gostaria de saber por que isso aconteceu? A única coisa que consigo pensar é que deve haver algum tipo de problema de cache em conjunto com o túnel VPN em execução.
Se eu criar um novo arquivo via SSH no webroot, não consigo acessar o arquivo pelo meu navegador; em vez disso, recebo uma página 404. Se eu desligar ou reiniciar minha VPN, esse erro desaparecerá.
estou a usarPulso Junocomo meu cliente VPN.
Outra coisa interessante que notei é que depois de reiniciar o cliente VPN a página reporta novamente a versão correta.
Responder1
Parece-me um problema de provedor + DNS - especificamente, postulo que o provedor tem várias máquinas - possivelmente com armazenamento na web compartilhado, mas armazenamento de sistema sincronizado periodicamente - e usando/não usando uma VPN você alterou o roteamento para uma máquina diferente - antes PHP - foi atualizado.
Os sinais disso são: 1. Não é um cache. Renomear o arquivo info.php descartou isso. 2. É um problema relacionado ao roteamento - a VPN altera o roteamento. 3. Foi um problema temporário.
Responder2
Sem verificar a configuração subjacente, é difícil dizer exatamente qual era o problema. No entanto, com base em algumas das informações fornecidas, é improvável que haja um cache, visto que você criou o arquivo info2.php e teve o mesmo problema.
O que indicaria onde 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 na sua VPN que possam causar isso (o que eu acho que é o que você quer dizer).
Existem muitas configurações diferentes de balanceador de carga, mas uma dessas configurações é baseada em um hash do IP, o que explicaria por que você estava sempre preso ao mesmo sistema (que possivelmente ainda não sincronizou suas alterações), mas foi roteado para outro ao acessar de outro PI. Veja o nginxip_hashpara obter um exemplo de uma dessas configurações de balanceador. Especificamente,
Os primeiros três octetos do endereço IPv4 do cliente, ou todo o endereço IPv6, são usados como chave de hashing. O método garante que as solicitações do mesmo cliente serão sempre passadas para o mesmo servidor, exceto quando este servidor estiver indisponível.
Quanto à opção DNS, verifique se o seu domínio roteia para vários registros A, talvez usando uma ferramenta comocaixa de ferramentas mxpois isso também pode explicar o roteamento para outro sistema se nenhum LB real estiver instalado.
Algo que vem à mente para uma situação semelhante a esta foram recentemente alterações de código que não foram mostradas para determinadas solicitações. O problema foi que o ENOM permitiu o CNAME para o registro raiz, o que não é permitido pela RFC1034 em sua interface. No entanto, o que realmente acontece é que eles simplesmente pesquisaram os registros A do CNAME que neste caso era um AWS ELB e criaram 2 registros A para os dois IPs para os quais o ELB resolveu e, alguns meses depois, quando a AWS alterou um dos IPs do ELB o roteamento para isso não foi refletido, portanto, algumas solicitações foram roteadas para o antigo IP do ELB e, por sua vez, exibindo o antigo código em cache.