среда, 8 апреля 2015 г.

IP-адрес "застрял" после смены хостинга

Как это решить? Короткий ответ - никак :) Но кое-что сделать можно.

Много раз переносил свой сайт на новый хостинг, и каждый раз была это проблемка... Перенаправляешь домен на новый 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, а потом его восстанавливать. Но об этом - в следующий раз...

Комментариев нет:

Ratings by outbrain