При запуске VPN отображается неверная версия PHP

Question

У меня странная проблема, о которой я действительно хотел бы узнать больше. Вчера я размещал новый сайт на своем хостинг-сервере. Накануне я перешел с PHP 5.2.17 на PHP 5.4.10 на сервере. Странно было то, что версия все еще была 5.2.17? Я попросил коллегу зайти на сайт, и он получил правильную версию. Наконец, я отключил VPN (не используется для этого конкретного сервера) и сразу увидел, что на сервере установлена правильная версия PHP. Теперь я действительно хотел бы знать, почему это случилось бы? Единственное, о чем я могу думать, - это что-то вроде кеширования в связи с работающим VPN-туннелем?

Если я создаю новый файл через SSH в webroot, я не могу получить доступ к файлу через мой браузер, вместо этого я получаю страницу 404. Если я выключу или перезапущу свой VPN, эта ошибка исчезнет.

Я использую Juno Pulse в качестве своего VPN-клиента.

Еще одна интересная вещь, которую я заметил, это то, что после перезапуска VPN-клиента страница снова сообщает правильную версию.

Answer 1

Для меня это звучит как проблема провайдера + DNS - в частности, я предполагаю, что у провайдера есть несколько машин - возможно, с общим веб-хранилищем, но периодически синхронизируемым системным хранилищем - и, используя / не используя VPN, вы перед этим изменили маршрутизацию на другую машину - PHP - был обновлен.

Признаки этого:1. Это не кеш. Переименование файла info.php исключило его. 2. Это проблема, связанная с маршрутизацией - через VPN выполняется маршрутизация. 3. Это была временная проблема.

Answer 2

Без проверки базовой установки трудно сказать точно, в чем проблема, однако, основываясь на некоторой информации, которую вы предоставили, вряд ли это был кэш, поскольку вы создали файл info2.php и имели ту же проблему.

Который будет указывать вам, где маршрутизируется на другой сервер при использовании VPN. Либо с помощью балансировщика нагрузки у вашего провайдера или DNS (посмотрите, есть ли несколько записей / циклический перебор). В вашей VPN нет никаких кешей, которые могли бы вызвать это (что я думаю, это то, к чему вы стремитесь).

Существует много различных конфигураций балансировщика нагрузки, но одна такая конфигурация основана на хэше IP, который объясняет, почему вы всегда были привязаны к одной и той же системе (которая, возможно, еще не синхронизировала ваши изменения), но куда перенаправлены на другую при доступе с другого IP. Посмотрите ip_hash nginx для примера одной такой конфигурации балансировщика. В частности,

Первые три октета IPv4-адреса клиента или всего IPv6-адреса используются в качестве ключа хеширования. Этот метод гарантирует, что запросы от одного и того же клиента всегда будут передаваться на один и тот же сервер, кроме случаев, когда этот сервер недоступен.

Что касается опции DNS, проверьте, направляет ли ваш домен несколько записей A, возможно, используя инструмент, такой как mxtoolbox, так как это также может объяснить маршрутизацию в другую систему, если нет действующего LB.

Кое-что, что приходит на ум в ситуации, подобной этой, это недавние изменения кода, когда они не показываются для определенных запросов. Проблема была в том, что ENOM разрешил CNAME корневую запись, что не разрешено в соответствии с RFC1034 в их интерфейсе. Однако на самом деле они просто ищут записи A CNAME, которые в данном случае были ELS AWS, и создали 2 записи A для двух IP-адресов, к которым разрешен ELB, а затем через несколько месяцев, когда AWS изменил один из IP-адресов ELB. маршрутизация на это не отражалась, поэтому некоторые запросы были направлены на старый IP-адрес ELB и, в свою очередь, отображали старый кешированный код.