У меня странная проблема, о которой я действительно хотел бы узнать больше. Вчера я развертывал новый сайт на своем хостинговом сервере. За день до этого я перешел с PHP 5.2.17на PHP 5.4.10на сервере. Странно то, что версия все еще была указана как 5.2.17? Я попросил коллегу зайти на сайт, и он получил правильную версию. Наконец, я отключил свой VPN (не используемый для этого конкретного сервера) и сразу же увидел, что на сервере запущена правильная версия PHP. Теперь я действительно хотел бы узнать, почему это вообще произошло? Единственное, что я могу придумать, это то, что это, должно быть, какая-то проблема с кэшированием в сочетании с работающим туннелем VPN?
Если я создаю новый файл через SSH в корневом каталоге, я не могу получить к нему доступ через браузер, вместо этого я получаю страницу 404. Если я отключаю или перезапускаю VPN, эта ошибка исчезает.
я используюПульс Джунокак мой VPN-клиент.
Еще одна интересная вещь, которую я заметил, заключается в том, что после перезапуска VPN-клиента страница снова сообщает о правильной версии.
решение1
Мне кажется, что это проблема провайдера и DNS. В частности, я предполагаю, что у провайдера есть несколько машин, возможно, с общим веб-хранилищем, но периодически синхронизируемым системным хранилищем, и, используя/не используя VPN, вы изменили маршрутизацию на другую машину, прежде чем PHP был обновлен.
Признаки этого: 1. Это не кэш. Переименование файла info.php исключило это. 2. Это проблема, связанная с маршрутизацией — VPN меняет маршрутизацию. 3. Это была временная проблема.
решение2
Без проверки базовой настройки сложно сказать точно, в чем была проблема, однако, основываясь на предоставленной вами информации, можно сказать, что это вряд ли был кэш, учитывая, что вы создали файл info2.php и столкнулись с той же проблемой.
Что укажет, что вы перенаправлены на другой сервер при использовании VPN. Либо балансировщиком нагрузки у вашего провайдера, либо DNS (проверьте, есть ли несколько записей/циклический перебор). В вашем VPN нет кэшей, которые могли бы вызвать это (думаю, вы к этому и клоните).
Существует множество различных конфигураций балансировщика нагрузки, но одна из таких конфигураций основана на хэше IP, что объясняет, почему вы всегда застряли в одной и той же системе (которая, возможно, еще не синхронизировала ваши изменения), но при доступе с другого IP перенаправлялись в другую. Смотрите nginx'sip_хэшдля примера одной из таких конфигураций балансира. В частности,
Первые три октета IPv4-адреса клиента или весь IPv6-адрес используются в качестве ключа хеширования. Метод гарантирует, что запросы от одного и того же клиента всегда будут передаваться на один и тот же сервер, за исключением случаев, когда этот сервер недоступен.
Что касается опции DNS, проверьте, маршрутизируется ли ваш домен к нескольким записям A, возможно, с помощью такого инструмента, какmxtoolboxпоскольку это также может объяснить перенаправление в другую систему, если фактический LB отсутствует.
Что приходит на ум в случае подобной ситуации, так это недавние изменения кода, когда не отображались определенные запросы. Проблема была в том, что ENOM разрешал CNAME в корневой записи, что не разрешено в соответствии с RFC1034 в их интерфейсе. Однако на самом деле они просто ищут записи A CNAME, которая в этом случае была AWS ELB, и создают 2 записи A для двух IP-адресов, на которые разрешался ELB, а затем несколько месяцев спустя, когда AWS изменила один из IP-адресов, на который направлялся ELB, это не отражалось, поэтому некоторые запросы направлялись на старый IP-адрес ELB и, в свою очередь, отображали старый кэшированный код.