TTL у DNS-записей — это одна из тех настроек, про которые многие вспоминают только во время переезда сайта, смены IP или когда корпоративная почта внезапно «плавает» между старым и новым сервером. А на деле это базовая штука, которая сильно влияет и на скорость обновления DNS, и на стабильность доступа к сайту, и на то, как безболезненно проходит миграция.
Я на своей практике не раз видел, как люди ставили TTL «наугад» — либо слишком высокий, либо слишком низкий. И потом удивлялись: почему после смены хостинга сайт ещё сутки открывается на старом сервере, почему MX-записи крутятся не там, где надо, и почему после замены A-записи часть пользователей видит старую версию. Грубо говоря, TTL — это не просто число в панели регистратора. Это таймер кэша для всего DNS-мира.
Что такое TTL DNS-записей и как это работает
TTL расшифровывается как Time To Live — время жизни записи в кэше. Если совсем по-простому: DNS-серверы и резолверы у провайдеров не спрашивают авторитативный DNS каждый раз заново. Они запоминают ответ на определённое время. Вот это время и задаёт TTL.
Допустим, у вас A-запись сайта указывает на IP 203.0.113.10, а TTL выставлен 3600 секунд. Это значит, что внешний DNS-резолвер может хранить этот ответ до часа. Если вы через 5 минут поменяете IP на новый сервер, часть пользователей всё ещё будет попадать на старый адрес, пока кэш не протухнет. И это абсолютно нормальное поведение DNS, а не «сломанный интернет».
Я обычно объясняю клиентам так: TTL — это компромисс между скоростью изменений и снижением нагрузки на DNS. Чем меньше TTL, тем быстрее мир увидит новые записи. Чем больше TTL, тем реже резолверы будут спрашивать ваш DNS и тем стабильнее будет кэширование. Для сайта на обычном хостинге часто хватает 3600 или 14400. Для почты, CDN и миграций — уже нужны другие значения.
И тут есть важный момент: TTL — это не магическая кнопка ускорения сайта. Он не делает HTML быстрее, не улучшает Core Web Vitals и не влияет напрямую на PageSpeed. Но он сильно влияет на управляемость инфраструктуры. Если у вас сайт, почта, поддомены, CDN, валидация SSL и периодические переезды — TTL становится очень практичной настройкой. И игнорировать её — плохая идея.
Зачем вообще настраивать TTL в 2026 году
В 2026 году сайты всё чаще живут не на одном сервере. У меня сейчас типичная картина по клиентам такая: сам сайт на одном хостинге, почта на другом, CDN перед статиками, API на отдельном поддомене, а часть проектов ещё и в Docker или Laravel Forge. В такой схеме DNS перестаёт быть «поставил и забыл». TTL начинает играть заметную роль.
Первая причина — миграции. Когда вы переносите сайт на новый хостинг, меняете IP, поднимаете VPS на PHP 8.2 или 8.3, обновляете Nginx, переезжаете с MySQL 5.7 на 8.0, TTL помогает сократить период, когда пользователи видят старый сервер. Если запись была с TTL 86400, то сутки всё может «держаться» на старом адресе. Если заранее снизить TTL до 300–600 секунд, переезд проходит намного спокойнее.
Вторая причина — почта. Для MX-записей TTL особенно полезен при переключении между SMTP-провайдерами, при подключении корпоративной почты на домене или настройке SPF, DKIM и DMARC. Бывает, меняешь MX, а письма ещё несколько часов уходят «не туда». И вот тут низкий TTL реально экономит нервы.
Третья причина — CDN и балансировка. Если вы используете CDN, обратный прокси или несколько серверов, DNS-записи могут меняться чаще. У некоторых клиентов я настраивал отдельные записи для origin-сервера, API и статических доменов, а TTL подбирал по назначению. Для сайта — один TTL, для mail-сервера — другой, для тестового поддомена — третий.
Ещё один практический момент: TTL связан с безопасностью и восстановлением. Если вы меняете IP после инцидента, подключаете резервный сервер или переводите сайт на новый VPS, низкий TTL помогает быстрее переключить трафик. Это особенно полезно вместе с отказоустойчивостью сайта и мониторингом.
Какие значения TTL ставить для сайта, почты и поддоменов
Если говорить без лишней теории, то универсального TTL «для всего» не существует. Я обычно делю записи по сценарию использования. И это работает лучше, чем попытка подобрать одно число на все случаи жизни.
Для обычных A и AAAA-записей сайта чаще всего ставлю 3600 секунд. Это нормальный баланс. Если сайт статичен, IP меняется редко, а вы не планируете никаких переносов в ближайшие месяцы — можно и 14400 или 86400. Но для активно обслуживаемого проекта я бы не завышал TTL без причины.
Для записей, связанных с миграцией, тестами или частыми изменениями, лучше 300 или 600 секунд. Например, если вы сегодня переносите проект с одного сервера на другой, снижаете TTL хотя бы за 24 часа до работ. Тогда к моменту переключения большинство резолверов уже будет жить с коротким кэшем.
Для MX-записей я обычно использую 3600. Иногда 600, если ожидается перенос почтового сервиса. Для CNAME на CDN — тоже 300–3600, в зависимости от того, как часто меняется целевая точка. Для NS-записей и делегирования поддоменов лучше не экспериментировать без необходимости: там изменения редкие, а цена ошибки выше.
- A/AAAA — 3600 для обычного сайта, 300–600 на время миграции.
- MX — 3600, при переносе почты можно временно снизить до 600.
- CNAME — 300–3600 в зависимости от динамики сервиса.
- TXT — 3600 или 86400, если запись стабильная и не меняется часто.
- NS — лучше менять редко, TTL обычно держат выше.
На деле я часто вижу противоположную ошибку: у сайта TTL 86400, а у TXT-записи для верификации Google или почты — тоже 86400. Потом человек добавляет SPF, ждёт, а резолверы не обновляются. Честно говоря, для TXT, которые вы будете менять в ближайшее время, лучше держать TTL пониже. Особенно если вы ещё не до конца настроили почту для сайта.
Как правильно менять TTL: до, во время и после миграции
Самая частая ошибка — менять TTL в момент переезда. Это уже поздно. DNS-кэш у резолверов живёт по старому значению до окончания срока. Если у вас сейчас TTL сутки, а вы за час до миграции уменьшили его до 300, это почти ничего не даст. Старое значение уже «разлетелось» по кэшам.
Я обычно делаю так: если планируется перенос сайта, снижение TTL ставлю минимум за 24 часа, а лучше за 48 часов. У одного клиента был интернет-магазин на Bitrix с PHP 8.1, Nginx и MariaDB. Мы переносили проект на новый сервер с PHP 8.3, меняли IP и одновременно включали Redis. TTL у A-записи был 86400. Если бы мы не снизили его заранее, половина покупателей ещё день ходила бы на старый сервер. А так переключение прошло почти незаметно.
План действий обычно такой:
- Снизить TTL у нужных записей заранее.
- Подождать, пока старые кэши истекут.
- Внести изменения: IP, MX, CNAME, NS.
- Проверить распространение DNS через несколько резолверов.
- После стабилизации вернуть TTL на комфортное значение.
После завершения работ TTL часто поднимают обратно. И это нормально. Для боевого сайта 300 секунд на постоянной основе не всегда оправданы. Если вы не меняете инфраструктуру каждую неделю, однозначно стоит вернуть TTL хотя бы на 3600. Иначе вы просто увеличите количество DNS-запросов без реальной пользы.
Если нужен полноценный перенос без простоя, я обычно советую смотреть не только на DNS, но и на миграцию сайта на новый хостинг, 301 редиректы и переход на HTTPS. TTL — это только один кусок пазла.
Как проверить TTL и увидеть, что запись уже обновилась
Проверять TTL можно через любые DNS-инструменты, но я чаще всего использую командную строку. Это быстрее, точнее и без лишней воды. На сервере с Ubuntu 22.04 или 24.04 обычно хватает dig. Если вы работаете на Windows, подойдёт nslookup, но dig всё же удобнее.
dig example.com A
dig example.com MX
dig example.com TXT
dig +trace example.com
Команда dig покажет не только саму запись, но и время жизни. Правда, есть нюанс: вы увидите TTL ответа от конкретного резолвера, а не «магическое глобальное значение». Это полезно понимать. Если запрос идёт через локальный кеш или публичный DNS, цифры могут отличаться.
Для более точной проверки я часто смотрю несколько источников: локальный провайдерский DNS, Google Public DNS 8.8.8.8, Cloudflare 1.1.1.1 и авторитативный DNS. Тогда видно, как запись расходится по миру. И да, это особенно важно после смены A-записи или MX, когда хочется понять, где ещё живёт старый IP.
Если вы хотите проверить обновление DNS по конкретному домену, можно использовать такой подход:
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig @ns1.your-dns-provider.tld example.com A
У меня был случай, когда владелец проекта был уверен, что DNS «не обновился». А на деле у него на ноутбуке сидел кеширующий резолвер от VPN-клиента. Мы проверили запись через внешние резолверы — всё уже давно работало правильно. Поэтому перед паникой я всегда рекомендую проверить хотя бы 2–3 независимых источника. Иначе можно часами искать проблему там, где её нет.
TTL для сайта на Bitrix, WordPress и Laravel: есть ли разница
Сама CMS на TTL не влияет. Это чисто DNS-уровень. Но на практике разные платформы создают разные сценарии эксплуатации. И вот тут разница уже есть. Например, у WordPress чаще встречаются частые изменения домена, CDN, почта, сторонние сервисы, плагины аналитики и внешние API. У Bitrix — корпоративные порталы, интеграции с CRM, сложные переезды, тестовые и боевые контуры. У Laravel — отдельные API, микросервисы, staging и production.
Для WordPress я обычно советую внимательно относиться к CNAME для www, к записям для почты и к поддоменам, где крутится админка, API или статика. Если вы ускоряете проект, ставите CDN и делаете оптимизацию WordPress, TTL нужно держать в порядке. Иначе после замены CDN или IP часть ресурсов будет вести себя непредсказуемо.
Для Bitrix ситуация часто сложнее. Там бывают отдельные поддомены для тестового окружения, API, файлового хранилища и корпоративной почты. Если у вас ещё и кеширование в Битрикс настроено правильно, то DNS должен быть таким же аккуратным, как и серверная часть. У меня был клиент с Bitrix 24 и отдельным фронтом на Nginx. Мы меняли инфраструктуру, и TTL в 3600 секунды помог нам безболезненно перевести основной домен и поддомены.
Для Laravel часто важны staging-домены, API-адреса и webhook-поддомены. Если вы используете веб-хуки или внешние интеграции, лучше держать TTL на адекватном уровне и не делать его чрезмерно высоким. Иначе при смене IP часть интеграций начнёт «падать» просто потому, что старый адрес ещё живёт в кеше.
Типичные ошибки при настройке TTL
Первая ошибка — слишком высокий TTL на критичных записях. Это классика. Люди ставят 86400 или даже 172800, потому что «так меньше нагрузка». А потом меняют IP и ждут сутки, пока мир это заметит. Для сайта это раздражает. Для почты — может быть критично. Для интернет-магазина в пик продаж — вообще плохая идея.
Вторая ошибка — слишком низкий TTL без причины. Если TTL 60 секунд на стабильном сайте, вы не получите заметного выигрыша. Зато DNS-запросов будет больше. Это особенно бессмысленно, если у вас небольшой проект на shared-хостинге. Иногда люди ставят 60 просто потому, что им кто-то сказал, что «так правильно». Нет, не правильно. Всё зависит от задачи.
Третья ошибка — забывают про другие записи. Меняют A-запись, а CNAME для www оставляют с высоким TTL. В итоге без www сайт уже открывается на новом сервере, а с www ещё на старом. Или меняют MX, но TXT для SPF остаётся старым. Потом письма начинают попадать в спам, а владелец ищет проблему в SMTP-сервере, хотя дело всего лишь в кэше DNS.
Четвёртая ошибка — не учитывать кэширование на стороне провайдера и устройства пользователя. Даже если вы уже всё поменяли, локальный DNS-кеш ОС, роутера, браузера или VPN может ещё держать старый ответ. Поэтому при проверках я всегда советую использовать несколько резолверов и очищать локальный кеш там, где это возможно.
- Не снижайте TTL в последний момент.
- Не ставьте 60 секунд на всё подряд.
- Проверяйте A, AAAA, MX, CNAME и TXT вместе.
- Не забывайте о локальных DNS-кешах и VPN.
- После миграции возвращайте TTL к нормальному значению.
Если у вас уже начались проблемы с DNS, это часто пересекается с более широкими задачами. Например, с сайтом, который не работает, с проблемами индексации или с ошибками после переезда на новый хостинг. Тогда я бы не искал только TTL, а смотрел всю цепочку: DNS, веб-сервер, SSL, редиректы, кеши и логи.
Как настроить TTL у регистратора, в DNS-панели и в Cloudflare
В большинстве DNS-панелей TTL меняется прямо в строке записи. Где-то можно выбрать значение из списка, где-то вводится вручную. У регистраторов это обычно самый простой сценарий: открываете зону домена, находите A, MX, CNAME или TXT и задаёте TTL в секундах. На практике я чаще вижу интерфейсы, где доступны 300, 600, 3600, 14400 и 86400. Этого более чем достаточно.
Если DNS управляется через Cloudflare, там есть отдельная логика. Для обычных записей TTL может быть автоматическим, а для некоторых типов — только определённые режимы. Cloudflare часто сам оптимизирует TTL на своей стороне, и это нормально. Но если вы готовите миграцию, нужно понимать, что внешнее значение TTL — не всегда то же самое, что фактическое поведение кеширования в сети Cloudflare.
На одном проекте у меня был случай: клиент использовал Cloudflare как прокси, а DNS-панель у регистратора — отдельно. Он изменил запись у регистратора, а ожидал, что всё мгновенно переключится. Но фронт продолжал отдавать старый сервер, потому что Cloudflare кэшировал маршрут по своим правилам. И тут важно не путать DNS TTL с кешированием на уровне CDN. Это вообще разные вещи, хотя их часто смешивают.
Если у вас сложная схема, смотрите ещё и на настройку CDN и кэширование статики. DNS — это только точка входа. Дальше уже работают CDN, прокси, заголовки Cache-Control и серверные кеши.
# Пример логики для миграции
# За 48 часов до переноса:
# A: 300
# AAAA: 300
# CNAME www: 300
# MX: 600
# После стабилизации:
# A: 3600
# AAAA: 3600
# CNAME www: 3600
# MX: 3600
Практический чек-лист: как я бы настраивал TTL для реального проекта
Если ко мне приходит клиент и говорит: «Нужно безболезненно поменять хостинг, почту и ещё поддомен для CRM», я обычно делаю это по чек-листу. Сначала смотрю, какие записи есть сейчас. Потом анализирую, какие из них меняются редко, а какие — часто. После этого уже назначаю TTL. Без этого начинать настройку — это стрельба вслепую.
Для обычного сайта я бы стартовал с таких значений: A/AAAA — 3600, CNAME www — 3600, MX — 3600, TXT — 3600 или 86400, если запись статична. Если впереди миграция — заранее снижаю до 300–600 на нужные записи, жду обновления и потом перевожу. Если на проекте стоит обратный прокси Nginx или несколько серверов, я отдельно проверяю каждую точку входа.
Для интернет-магазина, особенно если он работает на PHP 8.2 или 8.3 и активно использует CRM, оплату и почтовые уведомления, я бы не стал ставить слишком агрессивные значения. Лучше 3600 и понятная стратегия обновления, чем постоянная гонка с кешами. А если у вас ещё и критично важны письма, подключите SMTP для отправки писем и проверьте SPF/DKIM/DMARC вместе с TTL.
Ниже простой ориентир, который я часто использую в работе:
- Обычный корпоративный сайт: TTL 3600 для основных записей.
- Перед переносом: 300–600 за 24–48 часов до работ.
- Почта и MX: 3600, при смене провайдера временно 600.
- Тестовый поддомен: 300, если адрес меняется часто.
- Стабильные TXT-записи: 86400 допустимо, если вы их почти не трогаете.
И ещё один нюанс, который часто забывают. Если вы меняете не только DNS, но и сам сайт — например, обновляете CMS, меняете структуру URL, переходите с WordPress на Bitrix или наоборот — TTL нужно рассматривать как часть общего плана. Он не решит SEO-вопросы, не заменит 301 редиректы и не исправит ошибки серверной конфигурации. Но он сильно помогает сделать переход менее болезненным. Поэтому я всегда включаю его в общий список работ вместе с бэкапами, редиректами, SSL и мониторингом.
Если смотреть шире, то тема DNS хорошо сочетается с бэкапами сайта, мониторингом и чек-листом ошибок на сайте. TTL сам по себе маленький, но в инфраструктуре он работает как винтик, без которого вся схема может тормозить.
Нужна помощь с настройкой TTL для сайта?
Подберём оптимальные TTL для ваших DNS-записей, чтобы ускорить обновления и снизить риск сбоев при изменениях.