Найкращий спосіб змінити IP-адресу сайту - з точки зору кінцевого користувача?

Я прочитав купу відповідних запитань тут, але я все ще не впевнений, що найкраща відповідь.

Я переміщую пару сайтів з IP-адреси "1.abc" на "2.def". Наразі в існуючій DNS я встановив всі TTL на 300 секунд, і у мене є нова зона DNS, готова до використання (на AWS Route 53), з новими серверами імен та всіма TTL на 60 секунд. Тож я вважаю, що я готовий з точки зору DNS. Після переїзду через кілька днів я встановлю TTL на більш розумні цифри на маршруті 53.

Я попередив усіх своїх користувачів про переїзд, і у мене є визначене вікно часу для переїзду. Я сказав їм, що як тільки переїзд завершиться, і якщо 24 години минули, і вони все ще бачать старі (заблоковані) сайти, вони повинні перезавантажити комп’ютер, щоб змусити локальний кеш-пам'ять DNS.

Я не розумію, як браузер (кеш) користувача відіграє певну роль у цьому. Мої власні експерименти з локальним файлом хостів (Win7) говорять мені про те, що в браузері є щось, що не дозволяє старій IP-адресі йти - мені довелося перейти в історію-> очистити все , щоб відобразити нове місцезнаходження сайту вгору, навіть післяipconfig /flushdns

(EDIT) - У мене немає кореневого доступу до старого сервера, тому я не можу реалізувати прийняту відповідь на це питання .

Запитання: Я дійсно не хочу, щоб мої користувачі мали справу з цим, тому чи можу я щось зробити, щоб змусити всіх браузерів повторно кешувати? І якщо так, то як довго я залишати його увімкненим?

Дякую...

Ні, ти не можеш. Проблема полягає в тому, що відповідь DNS можна кешувати в будь-якому місці між користувачем та сервером DNS, і немає можливості їх визнати недійсним.

Що ви можете зробити, але як тільки у вас синхронізуються дані, і ваш другий сайт буде готовий, ви можете перенастроїти оригінальний сервер, щоб він був проксі-сервером і передавав усі запити на нове місце.

Таким чином, ви можете досягти майже 0 секунд простою вашого веб-сайту.

Оновлення

Якщо у вас немає кореневого доступу, є кілька варіантів:

• Виконуйте проксі в PHP

• Налаштуйте проксі-сервер на другому сервері (якщо у вас є кореневий доступ до нього), перемкніть DNS і коли ви готові змінити проксі-сервер на веб-сервер

• Цей метод може бути джерелом проблем. Майте 2 адреси (www.domain.tld та www2.domain.tld). Налаштуйте www2 (що таке саме як www) та встановіть правильні записи DNS. Потім підготуйте веб-версію свого веб-сайту та робіть комутацію DNS. Встановіть переадресацію всіх запитів на старому сервері на субдомен www2.

Теоретично встановлення TTL домену на щось низьке і очікування, що відбудеться зміна, а потім зміна IP-адреси, повинно призвести до майже прозорої міграції. Зрештою, у цьому вся суть TTL, яку можна налаштувати.

На практиці люди неправильно налаштовують речі та інструменти ламаються. Ось чому вам може знадобитися дати інструкції своїм користувачам, щоб очистити їх локальний кеш, якщо все не працює.

Ти нічого поганого не робиш.

Неминуче ваша стара адреса буде кешована і використовується довго - переважно ботами.

Як я це зробив:

• Створіть, наприклад www2.yourdomain.com, запис A , вказуючи на новий IP. Цей запис раніше ніколи не використовувався; тому ніколи не кешовано.
• Перенаправлення запитів на старий сервер на www2.yourdomain.com
• Відстежуйте переспрямування, і коли трафік знижується до прийнятного рівня, видаліть старий сервер.
• І нарешті, коли старий сервер буде видалений, переадресація www2.yourdomain.comна www.yourdomain.com.

Обов’язково використовуйте 301 постійні переадресації. https://en.wikipedia.org/wiki/HTTP_301

Здається, ви плануєте одночасно змінювати сервери імен? Завдяки способу виявлення серверів імен, оновлення потребує набагато більше часу, ніж звичайний запис - часто це становить приблизно 24 години або довше.

Я настійно рекомендую оновити DNS у вашого поточного постачальника перед тим, як змінити DNS, або змінити сервери імен за 7 днів до зміни IP-адреси веб-сайту.

Сучасні комп’ютери та браузери досить надійні в дотриманні TTL з DNS, але вам потрібно зрозуміти весь ланцюжок для найкращих результатів.