Как это решить? Короткий ответ - никак :) Но кое-что сделать можно.
Много раз переносил свой сайт на новый хостинг, и каждый раз была это проблемка... Перенаправляешь домен на новый IP-адрес или nameservers; в течение нескольких часов вроде всё начинает работать нормально. Но всегда находится несколько несчастных пользователей, которые продолжают попадать на старый сайт в течение дней или даже недель. Т.е. их устройства или провайдеры то ли по ошибке, то ли из экономии времени и/или трафика кэшируют DNS непозволительно долго.
Частый совет - сократить TTL, чтобы IP-адреса не кэшировались так долго. Во-первых, это надо делать заранее, после переноса уже поздно. Во-вторых, влияет только на тех клиентов, у кого всё работает правильно. В-третьих, тут палка о двух концах: если у тебя хреновый хостинг, где nameservers часто падают (у меня такое было), уж лучше пусть TTL будет подольше: тогда неполадку мало кто заметит.
Второй частый совет: стереть всё на старом хостинг и разместить сообщение вроде "извините, идет перенос на новый хостинг, попробуйте зайти позже". Я делал мягче: оставлял на старом хостинге сайт, работающий в режиме read-only. Просто при попытке залогиниться пользователь видит сообщение о временных проблемах. Но для просмотра всё работает, SEO не страдает и рекламные объявления продолжают приносить деньги. Конечно, такой вариант не для всех подходит - ведь информация на старом хостинге будет устаревать.
Есть гораздо лучшее, но и более сложное решение: использовать старый хостинг как reverse proxy. Т.е. все запросы, которые по ошибке продолжают на него переходить, мы пересылаем на новый; получаем ответ и шлем назад.
Как конкретно это сделать? Тут разные варианты, зависит от платформы. Я в Windows использую IIS URL Rewrite плюс Application Request Routing (ARR). Допустим, новый хостинг переехал на адрес 50.28.20.147. Тогда web.config на старом хостинге может быть примерно такой:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="New hosting">
<match url=".*" />
<action type="Rewrite" url="http://52.28.20.147/{R:0}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Все остальные файлы на старом хостинге можно стереть - мы же будем пересылать все запросы на новый хостинг.
Заметьте - это именно rewrite, а не redirect. Если у клиента для вашего домена уже закэширован неправильный IP-адрес, то бесполезно делать redirect - клиент опять попадет на тот же IP-адрес, и так до бесконечности.
Проблема с ARR в том, что на дешевом хостинге он может быть не установлен. А без него IIS URL Rewrite не может работать как reverse proxy, т.е. делать rewrite на другой домен. Ну, можно в таком случае самому написать или найти нужный скрипт на PHP или чем угодно - идея-то простая.
Вторая проблема: rewrite всем хорош, но он меняет HOST HTTP Header. Допустим, клиент заходит на ваш сайт mysite.com. HOST в этом запросе будет 'www.example.com'. Но после rewrite на 50.28.20.147 HOST тоже превратится в 50.28.20.147.
Обычно в этом нет ничего страшного, но может возникнуть проблема с, например, multi-site WordPress. Когда у тебя физически один сайт, но много доменов. Зашел на китайский блог - там одно, на русский - другое, хотя реально сайт тот же самый (для экономии денег). Потому что WordPress использует HOST, чтобы понять, что именно вернуть клиенту.
Чтобы решить эту проблему, можно делать rewrite на домен, а не IP-адрес:
<action type="Rewrite" url="http://www.example.com/{R:0}" />
Поскольку операция rewrite происходит не у нерадивого клиента, а на сервере, то, вероятно, www.example.com будет корректно переведен уже в новый, правильный IP-адрес.
Есть ещё гораздо более сложное решение: делать rewrite на новый IP, но сохранять старый HOST как custom HTTP header, а потом его восстанавливать. Но об этом - в следующий раз...
